On 2012-01-27 19:09, Robert Zemła wrote:
> Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.

Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia
wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z
posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam
różne definicje.

> Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
> sporej wiedzy o systemie.

Programowanie wymagające sporej wiedzy o systemie to promil zagadnień.
Zazwyczaj dąży się aby wiedza o systemie była minimalna. Idealnie -
programy są niezależne od systemu. *Nawet* na mikrokontrolerach widać
taką tendencję.

> To są chyba główne powody dlaczego wielu go
> nie lubi.

Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym*
względem.

> No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie
> martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że
> programista nie musi mieć choćby minimum wiedzy komputerze.

I nie przekonuje. Przekonać jednak mogę że wiedza co to jest DWORD jest
*zbędnym* śmieciem wciskanym przez system operacyjny nie mającym żadnego
sensu w programowaniu ogólnym. Każdy rozsadnie napisany program
odizoluje typy WinAPI aby nie zanieczyszczały kodu. Qt jest takim
przykładem izolacji WinAPI od logiki kodu.

> Nie tylko Delphi, aczkolwiek pisząc to przypomniała mi się pewna
> sytuacja której byłem świadkiem. W wielkim skrócie człowiek nie był
> wstanie wdrożyć pewnej funkcji do programu bo komponent z którego
> korzystał nie oferował takiej funkcjonalności.

Piszesz o tym że jest wielu miernych programistów. No jest. I co z tego?
I co z tego że większość z nich programuje w onklikach w RADach?

> Zawsze można zrobić błąd. Jeżeli człowiek umie napisać kod
> wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie
> będzie mieć problemu.

Zaryzykuje że *NIGDY* nie pisałeś niczego większego, czyli przynajmniej
kilkanaście KLOCów w zespole. Nie trzeba mieć umiejętności programowania
WinAPI aby pisać wydajne, skomplikowane aplikacje. Gorzej: wydaje i
skomplikowane aplikacje nie biorą się z doskonałej wiedzy hakerskiej o
DWORD tylko z algorytmów, wzorców, technik przy których WinAPI jest na
poziomie głupawego, płaskiego interfejsu OS który tylko przeszkadza. Z
taki wlasnie płaskim, gównianym interfejsem namęczysz się kilka razy
więcej pisząc mały programik do odbierania znaków niż z byle-jakim
środowiskiem obiektowym.

>> Pomyliłeś programowanie obiektowe z RAD.
> Napisałeś "obiektowe środowiska".

Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
Comy).

> Natomiast nie widzę związku z brakiem
> możliwości połączenia programowania obiektowego i WinAPI

Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie
MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.
Pomogło dopiero solidne odizolowanie WinAPI od programisty aby mogły
powstać wygodne środowiska .NET. *SOLIDNA* izolacja od kretynizmów
WinAPI stoi u podstaw sukcesu C# - wszystko jest spójne bo wreszcie ktoś
to zaprojektował.

> Programuję w tym od lat, napisałem sporo różnych aplikacji, uzbierałem
> sobie pokaźną bibliotekę przeróżnych klas (do tego typu programów używam
> C++, dawniej MASM32), w związku z tym do pisania prostych (i brzydkich)
> programów nie potrzeba mi nic więcej.

Wpadleś w typową studnie potencjalu: to co mam jest wystarczające, a
więc jest najlepsze, nie ma sensu robić nic lepszego, przecież asm
wystarczy do wszystkiego. Porozgladaj się do okoła. Mozna napisać
program z tego wątku używają kilku linijek pod warunkiem użycia
wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
jakiegoś systemu operacyjnego. To *najgorszy* wybór ze wszystkich
innych, nawet od Delphi.

> Podsumowując nie jestem wrogiem nowocześniejszych technik programowania,
> nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać
> się na tym co robi.

Trudno. Mamy inne punkty wyjścia do dyskusji. Przy czym ja nigdzie nie
pisałem o tym że programista ma się nie znać. Problem w tym, że jeśli
programista *naprawdę* dobrze się zna na programowaniu docenia inne
rzeczy niż hakerskie zagrywki z 30-letnim WinAPI (w tym roku mamy
jubileusz ogłoszenia Win1.0 a wiele funkcji pochodzi koncepcyjnie z
tamtych lat).

Staram się przekonać tylko autora, że WinAPI jest rozwiązaniem którego
nie powinien nawet kijem dotykać ponieważ *większośc* problemów
rozwiazuje mu .NET kilka razy mniejszym nakładem środków.

do góry

W dniu 27-01-2012 20:35, Sebastian Biały pisze:
> On 2012-01-27 19:09, Robert Zemła wrote:
>> Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.
>
> Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia
> wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z
> posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam
> różne definicje.

Pokaż mi gdzie występują te różne wartości dla true/false. Wogóle gdzie
Ty tu widzisz POSIX'a??? Te czeluści MSDN to jedna z lepiej opracowanych
i ułożonych dokumentacji jakie widziałem.

>
>> Bywa czasem upierdliwe, wymaga użycia innych technik programowania i
>> sporej wiedzy o systemie.
>
> Programowanie wymagające sporej wiedzy o systemie to promil zagadnień.
> Zazwyczaj dąży się aby wiedza o systemie była minimalna. Idealnie -
> programy są niezależne od systemu. *Nawet* na mikrokontrolerach widać
> taką tendencję.
>
>> To są chyba główne powody dlaczego wielu go
>> nie lubi.
>
> Wielu nie lubi bo doskonale wie że można za darmo lepiej pod *każdym*
> względem.

Oczywiście że można wygodniej, ale nie koniecznie lepiej

>
>> No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie
>> martwi ten co po nim ten kod przejmie. Nie przekonasz mnie że
>> programista nie musi mieć choćby minimum wiedzy komputerze.
>
> I nie przekonuje. Przekonać jednak mogę że wiedza co to jest DWORD jest
> *zbędnym* śmieciem wciskanym przez system operacyjny nie mającym żadnego
> sensu w programowaniu ogólnym. Każdy rozsadnie napisany program
> odizoluje typy WinAPI aby nie zanieczyszczały kodu. Qt jest takim
> przykładem izolacji WinAPI od logiki kodu.

Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
na niskopoziomowe API w żadnym systemie.

>
>> Nie tylko Delphi, aczkolwiek pisząc to przypomniała mi się pewna
>> sytuacja której byłem świadkiem. W wielkim skrócie człowiek nie był
>> wstanie wdrożyć pewnej funkcji do programu bo komponent z którego
>> korzystał nie oferował takiej funkcjonalności.
>
> Piszesz o tym że jest wielu miernych programistów. No jest. I co z tego?
> I co z tego że większość z nich programuje w onklikach w RADach?

Nie koniecznie musi być miernym programistą. Brak mu podstaw żeby
rozwiązać samodzielnie problem na niższym poziomie. To nie nadmiar
wiedzy przeszkadza tylko jej brak.

>
>> Zawsze można zrobić błąd. Jeżeli człowiek umie napisać kod
>> wykorzystujący bezpośrednio WinAPI to z debugowaniem tym bardziej nie
>> będzie mieć problemu.
>
> Zaryzykuje że *NIGDY* nie pisałeś niczego większego, czyli przynajmniej
> kilkanaście KLOCów w zespole.

Nie rozmawiamy tu o mnie i niech tak zostanie.

Nie trzeba mieć umiejętności programowania
> WinAPI aby pisać wydajne, skomplikowane aplikacje. Gorzej: wydaje i
> skomplikowane aplikacje nie biorą się z doskonałej wiedzy hakerskiej o
> DWORD tylko z algorytmów, wzorców, technik przy których WinAPI jest na
> poziomie głupawego, płaskiego interfejsu OS który tylko przeszkadza.

Jak sam wcześniej zauważyłeś jest to niskopoziomowe API z przed 30 lat.
Sam się nie wiele rozwinął od tego czasu, rozwijają się za to
framweworki które się na nim opierają. Jeżeli komuś one nie wystarczają,
albo ma taki kaprys to niech sobie pisze w WinAPI.

>Z taki wlasnie płaskim, gównianym interfejsem namęczysz się kilka razy
> więcej pisząc mały programik do odbierania znaków niż z byle-jakim
> środowiskiem obiektowym.

Jeżeli nie masz doświadczenia to na pewno tak

>
>>> Pomyliłeś programowanie obiektowe z RAD.
>> Napisałeś "obiektowe środowiska".
>
> Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
> RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
> wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
> zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
> Comy).

No a cała ta funkcjonalność bierze się z WinAPI. Akurat do komunikacji z
peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI. Czym
wogóle są łątwe wątki?

>
>> Natomiast nie widzę związku z brakiem
>> możliwości połączenia programowania obiektowego i WinAPI
>
> Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie
> MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.

A co ma MFC do obiektowości??? Albo nie rozumiesz czym jest obiektowość
albo mnie podpuszczasz.

> Pomogło dopiero solidne odizolowanie WinAPI od programisty aby mogły
> powstać wygodne środowiska .NET. *SOLIDNA* izolacja od kretynizmów
> WinAPI stoi u podstaw sukcesu C# - wszystko jest spójne bo wreszcie ktoś
> to zaprojektował.

Nic nie stoi na przeszkodzie żebyś w C# pisał pod WinAPI. Sukces C#
wynika bardziej z sukcesu .NET no i usunięciu upierdliwości związanych z
zarządzaniem pamięcią na którą narzekałeś wcześniej.

>
>> Programuję w tym od lat, napisałem sporo różnych aplikacji, uzbierałem
>> sobie pokaźną bibliotekę przeróżnych klas (do tego typu programów używam
>> C++, dawniej MASM32), w związku z tym do pisania prostych (i brzydkich)
>> programów nie potrzeba mi nic więcej.
>
> Wpadleś w typową studnie potencjalu: to co mam jest wystarczające, a
> więc jest najlepsze, nie ma sensu robić nic lepszego, przecież asm
> wystarczy do wszystkiego.

Mylisz się. Używam narzędzi i technik adekwatnych do zadania. WinAPI nie
jest jedynym co znam.
Nawet na 8 bitowych mikrokontrolerach staram się unikać asm'a o ile to
możliwe.

Porozgladaj się do okoła. Mozna napisać
> program z tego wątku używają kilku linijek pod warunkiem użycia
> wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
> jakiegoś systemu operacyjnego.

Można. W WinAPI myślisz że to zajmie więcej linijek?

To *najgorszy* wybór ze wszystkich
> innych, nawet od Delphi.
>
>> Podsumowując nie jestem wrogiem nowocześniejszych technik programowania,
>> nie zgadzam się tylko że WinAPI jest złe i że programista nie musi znać
>> się na tym co robi.
>
> Trudno. Mamy inne punkty wyjścia do dyskusji. Przy czym ja nigdzie nie
> pisałem o tym że programista ma się nie znać. Problem w tym, że jeśli
> programista *naprawdę* dobrze się zna na programowaniu docenia inne
> rzeczy niż hakerskie zagrywki z 30-letnim WinAPI (w tym roku mamy
> jubileusz ogłoszenia Win1.0 a wiele funkcji pochodzi koncepcyjnie z
> tamtych lat).
>
> Staram się przekonać tylko autora, że WinAPI jest rozwiązaniem którego
> nie powinien nawet kijem dotykać ponieważ *większośc* problemów
> rozwiazuje mu .NET kilka razy mniejszym nakładem środków.

Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
sam oceni.

pozdrawiam

do góry

On 2012-01-28 19:46, Robert Zemła wrote:
> W dniu 27-01-2012 20:35, Sebastian Biały pisze:
>> On 2012-01-27 19:09, Robert Zemła wrote:
>>> Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.
>>
>> Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia
>> wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z
>> posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam
>> różne definicje.
>
> Pokaż mi gdzie występują te różne wartości dla true/false.

Po pierwsze masz dwa typy BOOL i BOOLEAN.

http://msdn.microsoft.com/en-us/library/aa383751(v=v
s.85).aspx

Po drugie od groma funkcji ma odwrócona logike, pierwsza z brzegu:

http://msdn.microsoft.com/en-us/library/windows/desk
top/bb762164(v=vs.85).aspx

Zwracanie bledu nie tłumaczy w tym przypadku niczego bo nie należy z
niego korzytać. Mozna odczytać sobie jakieś pole dodatkowo żeby mieć
pewność. Nie można użyć GetLastError - bo nie. Spójność pełną gębą.
Przez pół MSDNa.

> Wogóle gdzie
> Ty tu widzisz POSIX'a???

http://msdn.microsoft.com/en-us/library/ms741394(v=v
s.85).aspx

hint: zwróc uwagę na wszystkie nazwy funkcji pisanych mała literą.
Niezła spójnośc, nie? Pewno im się kilku developerow zatrudniło od bsd i
jakoś tak wyszło.

Jak Cie nie przekonuje to sprawdź jakie krasnoludki zainstalowaly Ci ten
katalog:

C:\Windows\System32\drivers\etc

> Te czeluści MSDN to jedna z lepiej opracowanych
> i ułożonych dokumentacji jakie widziałem.

Dokumentacja != API.

> Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
> na niskopoziomowe API w żadnym systemie.

Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
watku ma napisać wysokopoziomową aplikację. Zonk.

> Jeżeli komuś one nie wystarczają,
> albo ma taki kaprys to niech sobie pisze w WinAPI.

Autorowi wątku wystarczają. Tylko jeszcze o tym nie wie.

>> Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
>> RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
>> wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
>> zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
>> Comy).
> No a cała ta funkcjonalność bierze się z WinAPI.

Bzdura. *Wiekszość* ficzerów bierze się z cieżkich KLOCow napisanych
przez ich autorów. Zapoznaj się z kodem Qt. To nie jest tylko wrapper na
winapi. To jest coś o rzędy wielkości większe.

> Akurat do komunikacji z
> peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI.

Mylisz pojęcia. WinAPI dostarcza wszystkie narzedzia. Framework składa
je do kupy i wystawia za fasadą/abstrakcją która powoduje że programista
nie musi babrac się w g...

Dodatkowo dostajesz za friko zupelnie nowe ficzery jak np. signal-slot
na porcie COM co powoduje że pisanie staje się trywialne.

> Czym
> wogóle są łątwe wątki?

Dwulinijkowym ich wytworzeniem. Są tak proste, wygodne i oczywiste że
nie znam lepszego słowa niż "latwe" do okreslenia ich konstrukcji.

>> Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie
>> MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.
> A co ma MFC do obiektowości???

O bosz... nawet na głupiej wikipedii jest od razu w drugim zdaniu:

"MFC ... Jest to biblioteka napisana w języku C++, która stanowi
obiektową (i uproszczoną) wersję Microsoft Windows API."

> Albo nie rozumiesz czym jest obiektowość

To możliwe, jeszcze nie nauczylem się smalltalka.

> Porozgladaj się do okoła. Mozna napisać
>> program z tego wątku używają kilku linijek pod warunkiem użycia
>> wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
>> jakiegoś systemu operacyjnego.
> Można. W WinAPI myślisz że to zajmie więcej linijek?

Tak. Sama inicjacja portu com zajmuje kilkadziesiąt.

> Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
> sam oceni.

Aby poprawnie to ocenić musiał by mieć rozeznanie. Jak wynika z maila ma
słabe. Szkoda więc by było żeby sobie samodzielnie wybił zęby na tym
cudzie techniki.

do góry

W dniu 28-01-2012 22:57, Sebastian Biały pisze:
> On 2012-01-28 19:46, Robert Zemła wrote:
>> W dniu 27-01-2012 20:35, Sebastian Biały pisze:
>>> On 2012-01-27 19:09, Robert Zemła wrote:
>>>> Przesadzasz :-) WinAPI nie jest złe a już na pewno nie jest niespójne.
>>>
>>> Bzdura. WinAPI to wpływ wielu koncepcji posklejanych gumą do zucia
>>> wliczając w to różne wartości true/false czy funkcje żywcem wyrwane z
>>> posixa/unixa wstydliwie chowane w czeluściach msdn. Spójne? Może mam
>>> różne definicje.
>>
>> Pokaż mi gdzie występują te różne wartości dla true/false.
>
> Po pierwsze masz dwa typy BOOL i BOOLEAN.

Różnią się tylko rozmiarem. Wartości dla true/false przyjmują takie same.

>
> http://msdn.microsoft.com/en-us/library/aa383751(v=v
s.85).aspx
>
> Po drugie od groma funkcji ma odwrócona logike, pierwsza z brzegu:
>
> http://msdn.microsoft.com/en-us/library/windows/desk
top/bb762164(v=vs.85).aspx
>
>
> Zwracanie bledu nie tłumaczy w tym przypadku niczego bo nie należy z
> niego korzytać. Mozna odczytać sobie jakieś pole dodatkowo żeby mieć
> pewność. Nie można użyć GetLastError - bo nie. Spójność pełną gębą.
> Przez pół MSDNa.

No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
Z tego co piszą niema tego od Visty.

>
>> Wogóle gdzie
>> Ty tu widzisz POSIX'a???
>
> http://msdn.microsoft.com/en-us/library/ms741394(v=v
s.85).aspx
>
> hint: zwróc uwagę na wszystkie nazwy funkcji pisanych mała literą.
> Niezła spójnośc, nie? Pewno im się kilku developerow zatrudniło od bsd i
> jakoś tak wyszło.

To o czym piszesz nazywa się "Berkeley sockets" - taki standard API do
komunikacji w sieci co by łatwiej było kod przenosić. Jest nawet
implementacje pod Amigę. Niektóre języki wysokiego poziomu jak na
przykład python mają to zaimplementowane w formie wrapperów. W każdym
razie Windows oferuje też swoje mechanizmy, nieco ciekawsze.

>
> Jak Cie nie przekonuje to sprawdź jakie krasnoludki zainstalowaly Ci ten
> katalog:
>
> C:\Windows\System32\drivers\etc

To tylko katalog. Jest sobie od Windowsów NT

>
>> Te czeluści MSDN to jedna z lepiej opracowanych
>> i ułożonych dokumentacji jakie widziałem.
>
> Dokumentacja != API.

Zgadza się, ale nie rozumiem o co chodzi.

>
>> Bo ideą Qt jest wieloplatformowość i przenoszalność. Tam nie ma miejsca
>> na niskopoziomowe API w żadnym systemie.
>
> Przyznałeś wreszcie ze to niskopoziomowa API. A tu się okazuje ze autor
> watku ma napisać wysokopoziomową aplikację. Zonk.
>
> > Jeżeli komuś one nie wystarczają,
>> albo ma taki kaprys to niech sobie pisze w WinAPI.
>
> Autorowi wątku wystarczają. Tylko jeszcze o tym nie wie.
>
>>> Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
>>> RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
>>> wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
>>> zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
>>> Comy).
>> No a cała ta funkcjonalność bierze się z WinAPI.
>
> Bzdura. *Wiekszość* ficzerów bierze się z cieżkich KLOCow napisanych
> przez ich autorów. Zapoznaj się z kodem Qt. To nie jest tylko wrapper na
> winapi. To jest coś o rzędy wielkości większe.
>
>> Akurat do komunikacji z
>> peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI.
>
> Mylisz pojęcia. WinAPI dostarcza wszystkie narzedzia. Framework składa
> je do kupy i wystawia za fasadą/abstrakcją która powoduje że programista
> nie musi babrac się w g...
>
> Dodatkowo dostajesz za friko zupelnie nowe ficzery jak np. signal-slot
> na porcie COM co powoduje że pisanie staje się trywialne.

To też masz w WinAPI. Tryb OVERLAPPED i wywołanie event'a plus jeden
wątek. Utworzony za pomocą jednej linijki.

>
>> Czym
>> wogóle są łątwe wątki?
>
> Dwulinijkowym ich wytworzeniem. Są tak proste, wygodne i oczywiste że
> nie znam lepszego słowa niż "latwe" do okreslenia ich konstrukcji.

Zupełnie tak jak w WinAPI :-)

>
>>> Oczywiście że nie widzisz. MS tez nie widział i powstalo g... o nazwie
>>> MFC. Jesli masz zacięcie do archeologii to możesz dalej tego używać.
>> A co ma MFC do obiektowości???
>
> O bosz... nawet na głupiej wikipedii jest od razu w drugim zdaniu:
>
> "MFC ... Jest to biblioteka napisana w języku C++, która stanowi
> obiektową (i uproszczoną) wersję Microsoft Windows API."

MFC to tylko wrapper minimalizujący kilka upierdliwości no i miał na
celu ułatwić tą nieszczęsną obiektowość. Ale nawet w javie da się
napisać nie obiektowy program i równie dobrze w asemblerze można napisać
obiektowy program.

>
>> Albo nie rozumiesz czym jest obiektowość
>
> To możliwe, jeszcze nie nauczylem się smalltalka.
>
>> Porozgladaj się do okoła. Mozna napisać
>>> program z tego wątku używają kilku linijek pod warunkiem użycia
>>> wlaściwego narzedzia. Nie jest nim niskopoziomowy zestaw funkcji OS
>>> jakiegoś systemu operacyjnego.
>> Można. W WinAPI myślisz że to zajmie więcej linijek?
>
> Tak. Sama inicjacja portu com zajmuje kilkadziesiąt.

No gdzieś trzeba wpisać choćby podstawowe parametry.

>
>> Zgadzam się, natomiast to czy WinAPI nie powinien dotykać kijem niech
>> sam oceni.
>
> Aby poprawnie to ocenić musiał by mieć rozeznanie. Jak wynika z maila ma
> słabe. Szkoda więc by było żeby sobie samodzielnie wybił zęby na tym
> cudzie techniki.

Ano szkoda, z drugiej strony jak mu się uda to może za kilka lat
zatrudni go jakaś korporacja i będzie pisał na przykład sterowniki za
niezłą kasę :-)

pozdrawiam,

do góry

On 2012-01-29 18:33, Robert Zemła wrote:
> [ciach]

Znudziło mi się, EOT. Mam nadzieje że autor wątku widząc przydługie
dyskusje nie na temat *przynajmniej* dwa razy zastanowi się zanim ruszy
w kierunku dziobania w 30-letnim API mając pod ręką kilka razy
łatwiejsze języki i frameworki. Ide cos polutowac, żeby nie było aż
takie OT.

do góry

Sebastian Biały <h...@p...onet.pl> napisał(a):
> On 2012-01-29 18:33, Robert Zemła wrote:
>> [ciach]
> Znudziło mi się, EOT. Mam nadzieje że autor wątku widząc przydługie
> dyskusje nie na temat *przynajmniej* dwa razy zastanowi się zanim ruszy w
> kierunku dziobania w 30-letnim API mając pod ręką kilka razy łatwiejsze
> języki i frameworki. Ide cos polutowac, żeby nie było aż takie OT.

Tylko niech uważa na popsute frameworki. Może się okazać, że trzeba coś
dorzeźbić w WinAPI.
http://zachsaw.blogspot.com/2010/07/net-serialport-w
oes.html

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 4 days, 18 hours, 38 minutes and 41 seconds

do góry

W dniu 29.01.2012 18:33, Robert Zemła pisze:
> W dniu 28-01-2012 22:57, Sebastian Biały pisze:
>>
>> Zwracanie bledu nie tłumaczy w tym przypadku niczego bo nie należy z
>> niego korzytać. Mozna odczytać sobie jakieś pole dodatkowo żeby mieć
>> pewność. Nie można użyć GetLastError - bo nie. Spójność pełną gębą.
>> Przez pół MSDNa.
>
> No dobra, występuje kilka dziwadeł. Ten uchował się conajmniej od Win95.
> Z tego co piszą niema tego od Visty.
Ja bardzo lubię "WinExec":
Note This function is provided only for compatibility with 16-bit Windows.

--
Pozdrawiam
Michoo

do góry

W dniu 2012-01-29 21:52, Grzegorz Niemirowski pisze:
>
> Tylko niech uważa na popsute frameworki. Może się okazać, że trzeba coś
> dorzeźbić w WinAPI.
> http://zachsaw.blogspot.com/2010/07/net-serialport-w
oes.html
>

MASZ U MNIE BROWARA!!!!!!!!! Po nocach nie śpie myśląc czemu mi się
jeden projekt (w sumie już wdrożony) losowo wysypuje, co spie..lem i jak
naprawic!!! A tu juz wszystko jasne... DZIĘKI!!!

--
venioo -> GG:198909
Sprzedam AUDI 100 C4 '91 AAR 2.3 LPG
http://tablica.pl/oferta/audi-100-c4-czarna-gaz-lpg-
mafia-look-IDvheh.html

do góry

v...@i...pl <v...@i...pl> napisał(a):
> MASZ U MNIE BROWARA!!!!!!!!! Po nocach nie śpie myśląc czemu mi się jeden
> projekt (w sumie już wdrożony) losowo wysypuje, co spie..lem i jak
> naprawic!!! A tu juz wszystko jasne... DZIĘKI!!!

Proszę :)

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 4 days, 20 hours, 8 minutes and 38 seconds

do góry

Użytkownik "Robert Zemła" <m...@g...com>

>>
>>>> Pomyliłeś programowanie obiektowe z RAD.
>>> Napisałeś "obiektowe środowiska".
>>
>> Obiektowe środowiska to Qt, .NET, Java. Żadne z nich nie wymaga używania
>> RADów. Za to każde wymaga używania obiektów. Dostarczają kilka rzędów
>> wielkości więcej funkcjonalności niż WinAPI. W tym również taką jaką
>> zainteresowany jest autor wątku (łatwe thready, signal-slot, wrapowane
>> Comy).
>
> No a cała ta funkcjonalność bierze się z WinAPI. Akurat do komunikacji z
> peryferiami jak naprzykład COM nie ma nic lepszego od WinAPI. Czym wogóle
> są łątwe wątki?

Za chwilę nie będzie WinAPI

do góry