Temat: Microsoft WebMatrix - kwas czy nowy Access?

Jarosław D.:

Przemysław R.:

np. MySQL, PHP

Teraz dałeś Przemek do pieca. Szykuj się na kamienowanie i darcie pasów skóry. Już wołam znajomych PHPowców. Oni będą wiedzieć co z Tobą zrobić. ;) Co do WebMatrix to chyba nie ma co biadolić nad tym tworem bo nie jesteśmy jego grupą docelową.

język programowania który przypomina śmietnik, i dopiero od niedawna ktoś sprząta ten bajzel, ale jakby to powiedzieć są pewne problemy ideologiczne z ruchem w którą kolwiek ze stron -> http://blog.wsoczynski.pl/2010/11/23/nowosci-z-php-int...

baza danych która ma kilka silników które skutecznie wykluczają wykorzystywanie pewnych funkcjonalności razem, tudzież czkawka przy bardziej zaawansowanym SQL-u

teraz fakt: to że coś jest popularne i łatwe w zastosowaniu wcale nie znaczy że jest dobre, wystarczy że jest proste w obsłudze

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
No właśnie. I tu się zgina łeb pingwina.

Bo ktoś kto projektował WinAPI był kiepskim architektem, ale gdyby nie ten ktoś - to wciąż tkwilibyśmy w informatycznej kredzie albo jurze. Dlatego czasem warto dać szansę laikom, nawet jeśli mielibyśmy się męczyć z ich kodem długie lata.

Nie zgodzę się.
Dlaczego zakładasz, że WinAPI mogła zaprojektować tylko ta jedna osoba (czy zespół) i nikt inny? Być może, gdyby ktoś inny to wtedy zrobił, WinAPI byłoby lepsze?

Gdyby nie ten ktoś - zrobiłby to ktoś inny, być może lepiej (a być może nie).

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
Bo ktoś kto projektował WinAPI był kiepskim architektem, ale gdyby nie ten ktoś - to wciąż tkwilibyśmy w informatycznej kredzie albo jurze. Dlatego czasem warto dać szansę laikom, nawet jeśli mielibyśmy się męczyć z ich kodem długie lata.

Idąc tym tokiem rozumowania można powiedzieć, że Bell* był kiepskim wynalazcą, no bo nie wynalazł telefonu komórkowego tylko stacjonarny a Edison był miernotą bo mógł od razu lampy Led’owe wynaleźć. Otóż byli to profesjonaliści w swojej epoce i wynieśli poziom ówczesnej nauki o kilka pięter. To, że po czasie udoskonalono i poprawiono ich projekty nie znaczy, że byli laikami. Podobnie z Windows’em i całą otoczką, jak na tamte czasy był to profesjonalny produkt napisany przez profesjonalistów. A co do kompatybilności w dół to znacie tą anegdotkę o wpływie szerokości końskich zadów na wielkość modułów promów kosmicznych…

*lub Meucci, będąc bliżej prawdy :)Norbert Maziarz edytował(a) ten post dnia 20.01.11 o godzinie 09:43

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Bartosz Adamczewski:
Napisz lepsze :-)

Baa dam ci łatwiejsze zadanie, napisz zwyczajny system wirtualny (t.j taki który działa jako proces w systemie ale ma swoją własną abstrakcyjną pamieć fizyczna oraz wirtualna oraz potrafi powoływać procesy i pilnuje pamięci ~2000 linijek kodu). Możesz to zrobić w swoim ulubionym języku programowania. Jeśli w ogóle ci się uda to zobaczymy czy twoje rozwiązania które zastosowałeś nie będą wołać o pomstę do nieba.

Tu nie chodzi o to, że ja nie umiem tego zakodować - bo nie umiem.
W ogóle bym tego nie musiał pisać, samo WinAPI mógłbym o wiele lepiej zaprojektować najpierw na zwykłej kartce papieru, zanim bym kazał ludziom kodować. Wystarczyłoby trochę więcej wyobraźni. To samo mógł zrobić architekt Microsoftu i jego sztab ludzi. Dał ciała i nie będę się nad nim litował. Może nie umiał lepiej, ale co mnie to właściwie obchodzi? Pieniędzy brakowało, czy co?

Rozróżnijmy dwie rzeczy. Dobrze, że był pierwszy, chwała anonimowemu architektowi za to, że dał siebie światu. Źle, że był kiepskim architektem.

Norbert Maziarz:
Idąc tym tokiem rozumowania można powiedzieć, że Bell* był kiepskim wynalazcą, no bo nie wynalazł telefonu komórkowego tylko stacjonarny a Edison był miernotą bo mógł od razu lampy Led’owe wynaleźć. Otóż byli to profesjonaliści w swojej epoce i wynieśli poziom ówczesnej nauki o kilka pięter. To, że po czasie udoskonalono i poprawiono ich projekty nie znaczy, że byli laikami. Podobnie z Windows’em i całą otoczką, jak na tamte czasy był to profesjonalny produkt napisany przez profesjonalistów. A co do kompatybilności w dół to znacie tą anegdotkę o wpływie szerokości końskich zadów na wielkość modułów promów kosmicznych…

Coś w tym jest... Z tym, że telefon stacjonarny, to moim zdaniem inne urządzenie niż telefon komórkowy. I taka uwaga - telefon stacjonarny dało się udoskonalić i doprowadzić do perfekcji, czego nie można powiedzieć już o WinAPI. Nie za bardzo da się go udoskonalić... Choć w sumie można by dodać nowy sposób korzystania z WinAPI przy nieusuwaniu starego modelu. Tylko komu się to opłaca? Zwariowanemu Microsoftowi, który zamiast udoskonalać stare rzeczy woli co chwila wymyślać nowe technologie odcinając się od starych? WinForms poszło w zapomnienie, potężne WPF okazało się zbyt czasochłonne w efektownym użyciu... Teraz z platformy .NET liczy się tylko ASP.NET (i to w dodatku ASP.NET MVC, bo cała reszta ASP.NET zostanie niedługo pozbawiona wsparcia ze strony Microsoftu) oraz Silverlight, z tym że ten drugi ma 10% rynku i jak nie zdobędzie popularności to pójdzie w końcu w odstawkę.

Co się tyczy IT - jestem przekonany, że w wielu przypadkach była wiedza i możliwości, by coś zrobić lepiej, a po prostu się nie chciało, zabrakło wyobraźni, czy też czasu. Natomiast za czasów Bella, czy Edisona brakowało ogólnie wiedzy, dlatego ich można nazwać pionierami - bo oni budowali tą bazę wiedzy. Tak myślę przynajmniej.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
Tu nie chodzi o to, że ja nie umiem tego zakodować - bo nie umiem.

Teoretyk gawędziarz

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:

Źle, że był kiepskim architektem.

W ramach krótkiego ćwiczenia proponuję zajrzeć do kodu, który napisałeś powiedzmy 3 lata temu. Na pewno znajdziesz tam rzeczy, które dziś mógłbyś napisać lepiej, przejrzyściej, krócej itd… A za kolejne 3 lata w tym, co piszesz dziś także znajdziesz coś, co można było zrobić lepiej. To siła doświadczenia. Twórcy WinAPI nie mieli doświadczenia, które Ty masz dziś*, ale którego byś nie miał gdybyś tworzył wtedy, wspólnie z nimi – czy to czyni ich mało profesjonalnymi, leniwymi, partaczami…??? W mojej opinii nie.

*Zbudowanego bądź co bądź na ich błędach i osiągnięciach

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Po pierwsze, żeby być dobrym architektem oprogramowania, nie trzeba być absolutnym fachowcem od narzędzi, które zostaną użyte w procesie wytwarzania oprogramowania. To raz.

Dwa.
Irytujecie się, bo mam czelność narzekać na architekturę WinAPI? Nie rozbawiajcie mnie. Jest skopana i niestaranna. I rewolucyjna zarazem.

Mim zdaniem człowiek, który ją wymyślił miał wiele fantastycznych pomysłów, ale nie wiedział, jak je dobrze zrealizować, więc zrobił je tak tylko, żeby jakoś działały. Jego pomysłowość i kreatywność nie czyni go dobrym architektem.

Dokładnie tak powstaje znakomita ilość aplikacji, których używacie codziennie. Ktoś ma rewolucyjne pomysły, fantastyczne, rewolucyjne koncepcje. I tak powstają różne wspaniałe aplikacje. Jednak liczy się również realizacja. Patrzymy i widzimy - realizacja jest skandaliczna.

Poza tym, tak teraz sobie myślę, że być może macie racje i człowiek od WinAPI był dobrym architektem. Cofam. Tego nie wiem. Jednak nawet dobry architekt może się nie starać i zrobić coś kiepskiego, tak samo jak zły architekt może się postarać i zrobić coś świetnego (mniej prawdopodobne), choć ogólnie będzie kiepskim architektem.

Trzy.
Kilka rozwiązań w platformie .NET jest dość kiepskich moim subiektywnym zdaniem (chodzi mi zwłaszcza o WinForms i niektóre rzeczy w WPF). Czy Microsoft ma złych architektów? Ma jednych z najlepszych na świecie, tak jak każda duża korporacja. Dlatego - jeśli coś, co zrobią najlepsi architekci jest do kitu, to znaczy, że architekci się nie starali lub byli leniwi.

Wolno im, bo są tylko ludźmi. "Kto z was jest bez grzechu, niech pierwszy rzuci kamień". Co nie znaczy, że mamy udawać, że nie schrzanili czegoś.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Rzucę kamieniem ale tak by nie trafić.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
Irytujecie się, bo mam czelność narzekać na architekturę WinAPI? Nie rozbawiajcie mnie.
Jest skopana i niestaranna. I rewolucyjna zarazem.

Nie wydaje mi się żeby ktokolwiek się na ciebie irytował. Ja osobiście trochę się dziwię, bo nie odważyłbym się pisać tak dosadnych rzeczy o, bądź co bądź, ekspertach z najwyższej światowej półki samemu mając jeszcze programistyczne mleko pod nosem.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław, możesz powiedzieć dlaczego uważasz, że WinAPI jest takie kiepskie?

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
Irytujecie się, bo mam czelność narzekać na architekturę WinAPI? Nie rozbawiajcie mnie. Jest skopana i niestaranna. I rewolucyjna zarazem.

Zastanow sie czy to nie jest zbyt mocne okreslenie biorac pod uwage jak niskie doswiadczenie posiadasz.

Kilka rozwiązań w platformie .NET jest dość kiepskich moim subiektywnym zdaniem (chodzi mi zwłaszcza o WinForms i niektóre rzeczy w WPF). Czy Microsoft ma złych architektów? Ma jednych z najlepszych na świecie, tak jak każda duża korporacja. Dlatego - jeśli coś, co zrobią najlepsi architekci jest do kitu, to znaczy, że architekci się nie starali lub byli leniwi.

WinForms i WPF sa bardzo mocnymi technologiami, zaprojektowanymi z glowa i cenionymi przez specjalistow. Staly sie one de facto standardem.

Proponuje "proste" cwiczenie - zaprojektuj API rozwiazujace aktualne wyzwania informatyczne - np. programowanie tabletu dotykowego. Nastepnie zaimplementuj je - pamietaj, ze wymyslona teoria niepoparta konkretna implementacja jest warta zero (np. "zaprojektuje samochod, bedzie super wygodny, spalal pol litra na 100km i bedzie skladal sie do torebki, dobra, swoja robote zrobilem, teraz dam inzynierom niech wykonaja"). Zaprezentuj efekt swojej pracy np. Googlowi, jezeli bedzie to cokolwiek warte zarobisz na tym ladne pieniadze. Jak nie beda chcieli kupic skonfrontuj to z rzeczywistoscia za 15 lat, zobaczysz jak "genialne" API wymysliles.

Z calym szacunkiem, zaloze sie, ze nie dasz rady. Super latwo jest oceniac i krytykowac produkt, a bardzo trudno jest samemu stworzyc cos dobrego.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Przeczytałem Wasze opinie i w sumie macie racje.

Łatwo jest narzekać i krytykować. Chociaż uważam, że świat się rozwija dlatego, że ludzie narzekają. Nie mówię, że niepotrzebna jest radość, że coś istnieje, ale gdyby tylko ludzie wydawali "achy" i "ochy" w zachwycie to tkwilibyśmy w miejscu. Zresztą, czy nie dość zachwytu zyskały już różnorakie produkty, choćby firmy Microsoft? Taka szkoda się im stanie i wszystkim specjalistom od branży, że ja sobie ponarzekam? Uważam, że nie robię im wcale wielkiej krzywdy.

Zresztą w równej mierze podzielam zachwyt jak i marudzenie.

Zrozumcie mnie dobrze. Ja podziwiam tych wszystkich programistów, którzy byli przede mną. Jednak są rzeczy, które nawet mnie (pomimo słusznie zauważalnego programistycznego mleka pod nosem) się nie podobają i są takie momenty, kiedy czuję niepohamowaną, wewnętrzną potrzebę wyżalenia się.

W WinAPI nie podoba mi się architektura, która utrudnia programowanie zorientowane obiektowo. Na przykład:

Chcę mieć projekt, gdzie całą funkcjonalność zamknę w klasy, tak żeby nic sobie nie wisiało w powietrzu poza klasą. Powiedzmy, że chcę mieć klasę tworzącą mi okienka dla mojej aplikacji. Jak mam się pozbyć np. tego:

LRESULT CALLBACK WindowProcedure(HWND hWnd, UINT message, 

                               WPARAM wParam, LPARAM lParam);

Nie za bardzo jest to jak wrzucić jako część mojej klasy Window. Będzie sobie wisiało poza klasą i będzie ogólnie dostępne. Mało tego, teraz cały interfejs graficzny użytkownika muszę zawrzeć w tej metodzie. I tak cały kod, który powinien być w mojej klasie, jest na zewnątrz niej - bo muszę zrobić całą obsługę komunikatów wewnątrz WindowProcedure. I będzie tego sporo poza klasą...

HDC hdc = GetDC(hWnd);  

switch(message)

 {

  case WM_CLOSE: ...

  case WM_DESTROY: ... itd

} 

No i w którymś momencie muszę "na sztywno" w mojej klasie Window dać wywołanie tej ściśle określonej konkretną nazwą funkcji WindowProcedure(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam), zanim zarejestruję klasę okna

  wndclassex.lpfnWndProc  = WindowProcedure;

  (...)

  RegisterClassEx(&wndclassex);

Jasne, że powinienem wszystko zamieścić w osobnym pliku, ale to też nie rozwiązuje wszystkich problemów - mój kod się rozłazi gdzieś poza klasę i trudniej jest go kontrolować.

Przykład 2:

Chcę sobie stworzyć klasę Timer, której będę "podpinał" jakąś określoną akcję, która się będzie powtarzała, co jakiś czas. Piszę sobie i piszę... I oczywiście znów WinAPI irytuje.

Co z tego, że w klasie Timer użyję metod dajmy na to takich:

SetTimer(FWindowHandle, Timer_IDEvent, FInterval, null);

KillTimer(FWindowHandle, Timer_IDEvent);

Skoro potrzebuje durnowatego uchwytu na... okno! I tak, oczywiście - wewnątrz kolejnej, zawieszonej w powietrzu metody WindowProcedure umieszczę mój kod, w którym będę przechwytywał tylko i wyłącznie jeden typ komunikatu.

Zauważcie. Jeśli skorzystam z kodu w przykładzie 1, to już mam 3 miejsca w których przechowuje dane.
1 - Klasa Timer (ustawianie Interval, ustawianie wskaźnika na metodę)
2 - Klasa Window
3 - Metoda WindowProcedure (obsługa komunikatu WM_TIMER od Timera WinAPI)

Przykład 3:
Powiedzmy, że mam klasę Timer. Teraz chcę utworzyć 10000 obiektów klasy Timer. I co? Windows mówi, że tyle okien dla jednego programu mi nie da. Porobione.

Przykład 4:
Teraz klasę Timer połączę z klasą...
I to się tak ciągnie... niemal w nieskończoność.

To właśnie mi się nie podoba w WinAPI.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Teraz WinForms, czyli kolejna martwa gałąź IT... A według niektórych "mocna technologia, zaprojektowana z głową i ceniona przez specjalistów". No, no... Mocne słowa.

Nie podoba mi się:
- Brak wsparcia ze strony Microsoftu. Microsoft woli nie pamiętać, jak kilka lat temu pieniądze różnych firm przeznaczono na implementacje nowych rozwiązań w WinForms - i one poszły w błoto, z chwilą jednego widzimisie Microsoftu? Co to za mocna technologia, która nie jest wspierana?

- Dalej nie podoba mi się nadmiar w WinForms. O ile WPF jest niesamowicie oszczędne, to kontrolki WinForms są całkowitym przeciwieństwem WPF-owych. Dla przykładu - w trzech różnych miejscach w klasie jest umieszczona właściwie ta sama funkcjonalność - umożliwienie umieszczenie obrazka na przycisku: BackgroundImage, Image, ImageList. Teraz właściwości dla każdego z tych teł: BackgroundImageLayout, ImageAlign...

- To co w Delphi przy użyciu kilku komend i komponentów można zrobić, zajmuje za pomocą WinForms kilka, a czasem kilkanaście stron kodu. To też kwestia narzędzi dostarczanych do Visual Studio. W Delphi np. pola XML-a mają tak jak pola bazodanowe swoje typy (zgodnie z XSLT) nawet podczas wyświetlania można poprzez klikanie na grida "przesortować" dane, a takich sztuczek w WinFormkach chyba się nie da się równie łatwo zrobić.

To w zasadzie tyle co do WinForms

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Ok, stary, ale co Ty tak naprawdę chcesz udowodnić?
Wszstko, ale to absolutnie wszystko na naszym świecie da się zrobić lepiej.

I kiedy komuś coś, zrobione słabo, dokuczy - zostaje to zrobione lepiej.

Samochód, ubranie, narzędzia programowania - wszystko służy człowiekowi i wszystko jest zrobione na tyle dobrze, na ile w danym momencie potrzeba.

Marudzisz, że WinAPI utrudnia programowanie obiektowe. Wyobraź sobie, że doskonale pamiętam czasy (a jestem w branży prawie 20 lat), kiedy już było Windows 3.0 (nie 3.11) i miało API, a o programowaniu obiektowym mało kto słyszał (choć wiele technik, na których oparta jest idea programowania obiektowego, wykorzystywało się powszechnie).
To wcale nie jest tak, że obiekty były od zawsze, a wcześniej była tylko próżnia.

Obiekty są tylko metodologią, techniką programowania - tak naprawdę równie dobrą, jak programowanie proceduralne.

A Api powstaje zwykle pod to, co w danej chwili jest standardem.

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
W WinAPI nie podoba mi się architektura, która utrudnia programowanie zorientowane obiektowo.

Programowanie obiektowe jest świetne, ale nie wszędzie. Im niżej schodzisz w poziomach abstrakcji, tym bardziej obiektówka staję się przeszkodą niż ułatwieniem.
Jak wyobrażasz sobie obiektową implementację takich rzeczy jak np procedurę HeapAlloc?

Na przykład:
Chcę mieć projekt, gdzie całą funkcjonalność zamknę w klasy, tak żeby nic sobie nie wisiało w powietrzu poza klasą. Powiedzmy, że chcę mieć klasę tworzącą mi okienka dla mojej aplikacji. Jak mam się pozbyć np. tego:

LRESULT CALLBACK WindowProcedure(HWND hWnd, UINT message, 

                               WPARAM wParam, LPARAM lParam);

Nie za bardzo jest to jak wrzucić jako część mojej klasy Window. Będzie sobie wisiało poza klasą i będzie ogólnie dostępne. Mało tego, teraz cały interfejs graficzny użytkownika muszę zawrzeć w tej metodzie. (...)
który powinien być w mojej klasie, jest na zewnątrz niej - bo muszę zrobić całą obsługę komunikatów wewnątrz WindowProcedure. I będzie tego sporo poza klasą...

HDC hdc = GetDC(hWnd);  

switch(message)

 {

  case WM_CLOSE: ...

  case WM_DESTROY: ... itd

} 

No i w którymś momencie muszę "na sztywno" w mojej klasie Window dać wywołanie tej ściśle określonej konkretną nazwą funkcji WindowProcedure(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam), zanim zarejestruję klasę okna

  wndclassex.lpfnWndProc  = WindowProcedure;

  (...)

  RegisterClassEx(&wndclassex);

Teoretycznie, to cały kod aplikacji musisz zawrzeć w main(), bo to jest jedyna funkcja którą system operacyjny odpali w Twoim programie, jednak w praktyce jest tak, że w main() masz tylko odwołanie do innych części aplikacji, które robią wszystko.

Tak samo z okienkami. Nieważne ile byś nie robił poziomów abstrakcji, to zawsze musi być miejsce gdzie będziesz zapisywać aktualny komunikat a w innym miejscu stale pętlą sprawdzał czy wartość tamtej zmiennej odpowiada jakiemuś komunikatowi a następnie reagować. Inaczej się po prostu nie da :)
Oczywiście, jak nie chcesz bezpośrednio się bawić w pętle jak te, to możesz użyć innych rzeczy takich jak CWnd z MFC, Window z WinForms, i takich podobnych, ale pamiętaj, że wszystkie i tak będą opierały się właśnie na takiej pętli.

Uważam to jednak za plus, że masz możliwość (a nie jesteś zmuszony) operować w API systemu operacyjnego na tak niskim poziomie jak ręczna manipulacja pętlą okna.

C#-powe eventy, sloty w QT czy wszystkie takie abstrakcje są zbudowane na bazie najprymitywniejszych mechanizmów takich jak tablice, pętle, wskaźniki, itd... Pomyśl w ten sposób: ile musieli Ci architekci nagłowić się nad tym, żeby udostępnić tak niskopoziomowy mechanizm zachowując przy tym bezpieczeństwo.

Gdyby nie dostęp do takich rzeczy jak te pętle, to Windows byłby tak niemodyfikowalny jak Mac ;-)
A jednak, możesz zmienić nie tylko tło, ale i praktycznie zachowanie każdego elementu systemu, nie narażając go na niestabilność.

Przykład 2:
Chcę sobie stworzyć klasę Timer, której będę "podpinał" jakąś określoną akcję, która się będzie powtarzała, co jakiś czas. Piszę sobie i piszę... I oczywiście znów WinAPI irytuje.

Co z tego, że w klasie Timer użyję metod dajmy na to takich:

SetTimer(FWindowHandle, Timer_IDEvent, FInterval, null);

KillTimer(FWindowHandle, Timer_IDEvent);

Skoro potrzebuje durnowatego uchwytu na... okno! I tak, oczywiście - wewnątrz kolejnej, zawieszonej w powietrzu metody WindowProcedure umieszczę mój kod, w którym będę przechwytywał tylko i wyłącznie jeden typ komunikatu.

Zauważcie. Jeśli skorzystam z kodu w przykładzie 1, to już mam 3 miejsca w których przechowuje dane.
1 - Klasa Timer (ustawianie Interval, ustawianie wskaźnika na metodę)
2 - Klasa Window
3 - Metoda WindowProcedure (obsługa komunikatu WM_TIMER od Timera WinAPI)

A jak nie przez uchwyt to jak chcesz się odnieść do okna?
Przez CDialog->GetSafeHwnd() albo CDialog->m_hWnd? (toż to to samo ;-)) możesz, jest ładnie opakowane w MFC, ale dzięki temu, że masz API niższego poziomu, to możesz sobie napisać własne API opakowujące je, w przypadku kiedy masz bardzo specyficzne/niestandardowe wymagania.

Jeśli nie masz na jednym ze stopni abstrakcji czegoś takiego jak uchwyty po których odwołujesz się do okien, to jak chcesz zaimplementować coś, co modyfikowałoby inne okna? (np. wszystkie programy do pracy z wieloma monitorami, które dodają nowe przyciski do paska tytułu).

Przechwytujesz tylko jeden komunikat, ale możesz przechwycić też inne jak zajdzie potrzeba.
Jeśli nie odpowiada Tobie ten poziom abstrakcji, możesz przecież śmiało użyć wyższego API, albo sam przekazać wartość komunikatu do swojej HighLevelHandler::HandleMessage(KOMUNIKAT);

Przykład 3:
Powiedzmy, że mam klasę Timer. Teraz chcę utworzyć 10000 obiektów klasy Timer. I co? Windows mówi, że tyle okien dla jednego programu mi nie da. Porobione.

Nie porobione. Te informacje są przechowywane w innej przestrzeni pamięci - w przestrzeni kernela. Jeśli nie miałbyś takich ograniczeń, albo miałbyś bezpośredni dostęp do tamtej pamięci lub nie byłoby tylu ograniczeń, to co chwilę byś miał bluescreeny. Wtedy dopiero ludzie by jechali po Windows-ie i jego stabilności :)

To właśnie mi się nie podoba w WinAPI.

Nie musisz bezpośrednio używać WinApi, dobrze tylko, żebyś wiedział, że jak kiedyś będziesz chciał zrealizować jakiś egzotyczny fetysz programistyczny, wykraczający po za to co przewidzieli projektanci API wyższego levelu, to masz świadomość, że możesz zejść niżej i to zrobić.

Kolejną radę jaką bym Ci dał, to jest to, żeby zanim coś nie skrytykować w taki sposób, to najpierw zastanowić się nad mechanizmem który tym rządzi, jak to jest zrobione, jak to by było można zrobić lepiej (mając na myśli wszystko - od A do Z).

Takie myślenie, że jedynym słusznym paradygmatem programowania to programowanie obiektowe, wszystko powinno być ładnie opakowane a najlepiej wyklikiwalne świadczy tylko o tym, że myślisz bardzo powierzchownie o tym - a to jest trochę sprzeczne, bo krytykujesz coś o poziomie abstrakcji WinApi argumentami które byłyby słuszne dla Silverlight ;-)Karim A. edytował(a) ten post dnia 22.01.11 o godzinie 07:07

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Borysław Bobulski:
Teraz WinForms, czyli kolejna martwa gałąź IT... A według niektórych "mocna technologia, zaprojektowana z głową i ceniona przez specjalistów". No, no... Mocne słowa.

Nie podoba mi się:
- Brak wsparcia ze strony Microsoftu. Microsoft woli nie pamiętać, jak kilka lat temu pieniądze różnych firm przeznaczono na implementacje nowych rozwiązań w WinForms - i one poszły w błoto, z chwilą jednego widzimisie Microsoftu? Co to za mocna technologia, która nie jest wspierana?

Fakt, dopiero teraz zauważyłem, że z .NET 4.0 usunięty jest namespace System.Windows.Forms a z Visual Studio 2010 wywalony designer Windows Forms i template do tych projektów ;-)

- Dalej nie podoba mi się nadmiar w WinForms. O ile WPF jest niesamowicie oszczędne, to kontrolki WinForms są całkowitym przeciwieństwem WPF-owych. Dla przykładu - w trzech różnych miejscach w klasie jest umieszczona właściwie ta sama funkcjonalność - umożliwienie umieszczenie obrazka na przycisku: BackgroundImage, Image, ImageList. Teraz właściwości dla każdego z tych teł: BackgroundImageLayout, ImageAlign...

Uważasz, że image, imagelist i backgroundimage robią to samo? super ;-)

- To co w Delphi przy użyciu kilku komend i komponentów można zrobić, zajmuje za pomocą WinForms kilka, a czasem kilkanaście stron kodu. To też kwestia narzędzi dostarczanych do Visual Studio. W Delphi np. pola XML-a mają tak jak pola bazodanowe swoje typy (zgodnie z XSLT) nawet podczas wyświetlania można poprzez klikanie na grida "przesortować" dane, a takich sztuczek w WinFormkach chyba się nie da się równie łatwo zrobić.

W MS Access stworzenie sorotwanego grida z paginacją, szukaniem i bazą danych to kilka kliknięć myszką a w "niechlubnym" WinApi nie mniej niż 1000 linii kodu. Wytłumaczyć dlaczego czy rozumiesz przekaz? :-)

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Myślałem, że już nic mnie nie zaskoczy w IT, ale nie wpadłbym na to, że ktoś będzie żądał od Windows API wspierania OOP *_*

Windows API miało być dostępne z każdego języka programowania, także z tego, który nie zna pojęcia klasy, obiektu, w tym z Assemblera, w którym nawet nie było typu zmiennej, a po prostu bajt (i jego wielokrotności).

Karim, piątka i piwo za przypomnienie "wnętrza" tego, co dla wielu dziś to "klocki i puzzle". Coraz częściej stykam się z tym, że kto nie przeszedł drogi od starego DOSa i C/CPP/ASM/TP, potem nie poznał Win3.x i początków WinAPI, a potem nie "zanurzył" się w MFC, nie bardzo ma pojęcie o tym, co krytykuje. No, ale dziś mamy "singularity" i nawet 10latek, który zaczyna naukę programowania, widzi od początku OOP, nie wiedząc, że wszystko tłumaczy się podstawowe, "prymitywne" konstrukcje, tylko daleko pod maską OSa.

Ciekaw jestem, czy na studiach jeszcze uczą, co to są v_tables...





PS: TYSIĄCE TIMERÓW?! Ja chyba śnię... To już nie można w jednym timerze zrobić instrukcji warunkowych? Wszystkie timery mają mieć różny czasy co milisekundę? I to w klasycznej aplikacji biznesowej? Że też ludzie pisali wtedy gry pod Windows i to takie z wypasioną dynamiką... I po co do każdego timera osobne okno, skoro były identyfikatory timerów?

Poza tym przypominam, że liczba okien mogła być ograniczona, ponieważ w Windows oknem jest wszystko, nawet ramka grupująca radiobuttony, menu, ikonka, pasek zadań. Tak naprawdę w danej chwili patrzymy na setki okien.

Paranoja, jak ci programiści z czasów Win16 (w tym ja, chociaż wtedy ledwie nieopierzony programistycznie licealista...) mogli pisać jakiekolwiek programy? Nawet wybór modelu pamięci był istotny.


A przypominam, że to są właśnie czasy początków WinAPI (czyli początków Windowsa), dość podobnego do tego, jakie znamy z Win32.

Aha, dla przypomnienia - tak się generalnie pisało wtedy programy pod Windows - w czystym C. Potem przyszły dopiero "opakowania" obiektowe.



A skoro podejście obiektowe nie było wtedy powszechne (a to ono umożliwiało pozbycie się uchwytów, ukrywając je jako zmienne chronione/prywatne), to jak inaczej wskazywać funkcjom, na czym mają pracować? o_OAdrian Olszewski edytował(a) ten post dnia 22.01.11 o godzinie 10:52

Temat: Microsoft WebMatrix - kwas czy nowy Access?

No, Adrian, pojechałeś :) Zaraz Cię zakrzyczą, że po co to wszystko wiedzieć, teraz to jest niepotrzebne i wogóle co to kogo obchodzi? :) :)
Po to przecież są rozmaite frameworki, żeby NIE MUSIEĆ tego wiedzieć :) :)
I pewnie zaraz ktoś Ci będzie chciał udowodnić, że teraz to WYSZYSTKO jest zrobione inaczej (pewnie krasnoludki ciągną za sznurki), i dlatego taka wiedza jest kompletnie bezużyteczna.

A najgorsze w tym jest to, że niektórzy naprawdę wierzą, że nie muszą tego wiedzieć...

Temat: Microsoft WebMatrix - kwas czy nowy Access?

A ja się tam nie boję, właśnie dlatego, że programować uczyłem się 15 lat temu, jeszcze w oparciu o kilka grubych, znanych większości z Was cegieł (nie miałem wtedy internetu) z "ANSI", "Turbo", "BIOS", "Pasja", "efektywny", "czarna księga", "MFC" w tytule i Stroustrup, Petzold, Meyers, Grębosz wśród autorów. A dziś programuję zawodowo i projektuję soft w oparciu o te najnowsze klocki, więc widzę dokładnie, co jak i w co wyewoluowało. I nie dam sobie kitów pociskać :)Adrian Olszewski edytował(a) ten post dnia 22.01.11 o godzinie 11:23

Temat: Microsoft WebMatrix - kwas czy nowy Access?

Panowie, ale chyba każdy z nas miał za sobą taki okres kiedy czuł się Guru, wymiatał we wszystkim czego się dotkną (pomimo tego, że prawie niczego nie dotkną) a Dava Cutlera wcinał na śniadanie ;-)

Jest to mniej więcej okres 1-2 roku od kiedy zacznie się programować. Dajmy chłopakowi trochę czasu i też nabierze pokory ;-)