> Najpierw tworzysz klasę, potem okno mające (zarejestrowaną) klasę.
> Teoretycznie można użyć już istniejącej, ale w praktyce nie ma to
> sensu, bo funkcja obsługi okna jest podpięta pod klasę.


Nie pod klasę, tylko pod UCHWYT okna.
A ten dostanę jako rezultat funkcji DialogBox/CreateDialog.
Widać to pod pierwszym linkiem.
Klasę do tych funkcji wrzuca się makrem MAKEINTRESOURCE - pewnie można też w razie
potrzeby wydłubać z tego nazwę klasy dialogu.

Więc? Po co te zbytki z RegisterClass? :-)



> Jeżeli Main Window jest przypadkiem dialogiem to przyda się
> IsDialogMessage i nieco inna pompa komunikatów - szczegóły zna Google
> i Petzold.

No, nie wiem. Petzoldowi się zapomniało odpalić w kodzie DestroyWindow.
Szczegół. Ale właśnie o szczegóły pytam. ;-)

Przydałaby się jakaś kontynuacja typu: Programming Windows In Depth, ale ta kanalia w
siszarpy poszła i lansuje się gdzie indziej...

A propos szczegółów - modalność okna nie jest jego stanem bezwzględnym, tylko
sposobem zachowania wobec okna-rodzica, którego uchwyt przekazuje się w wywołaniu
DialogBox[Param]. A jeśli i tak wstawiam tam NULL-a, to... kto mi zabroni odpalić
kilka takich "modalnych" dialogów naraz? :-)

Wobec tego, moje pierwsze pytanie też mocno zmienia sens.

Nachodzi mnie zresztą generalne przeczucie, że używanie dialogów w ten sposób jest
niejako jazdą do Sieradza przez Mediolan i wszelkie moje rozterki mają źródło właśnie
tutaj.