No więc... Są zasadniczo dwie opcje: odpalenie z WinMain jako modalne, albo
niemodalne.

Pytanie pierwsze: Czy jest w przypadku okna głównego jakaś różnica, poza tym, że przy
modalnym odpadają dodatkowe aktywne dialogi?


Druga sprawa:
O ile tutaj oba dialogi wywołane są w sposób analogiczny:
http://forums.codeguru.com/showthread.php?306103-how
-to-create-a-win32-dialog-based-application

to częściej trafić można tego typu konstrukcje:

http://eduinf.waw.pl/inf/prg/002_winasm/0011.php
https://www-user.tu-chemnitz.de/~heha/petzold/ch11b.
htm
(niepokoi mnie brak DestroyWindow...)

Po co tutaj RegisterClass?
Co to faktycznie daje, jeśli program ma wyświetlić tylko jedno takie okno?

Jedyne, co mi przychodzi do głowy, to możliwość wyszukania uruchomionej wcześniej
instancji po klasie okna.
Ale w takim wypadku, powinno się zarejestrować klasę dialogu niezależnie od typu
wywołania?

Czy coś jeszcze?
Jakaś mała śrubka, której brak da o sobie znać w najmniej oczekiwanym momencie? ;-)

Szacun dla osobników, którzy ten majdan ogarniają. :-)

do góry

On Thursday, March 15, 2018 at 8:30:43 PM UTC+1, DMR wrote:
> No więc... Są zasadniczo dwie opcje: odpalenie z WinMain jako modalne, albo
niemodalne.
>
> Pytanie pierwsze: Czy jest w przypadku okna głównego jakaś różnica, poza tym, że
przy modalnym odpadają dodatkowe aktywne dialogi?
>
>
> Druga sprawa:
> O ile tutaj oba dialogi wywołane są w sposób analogiczny:
> http://forums.codeguru.com/showthread.php?306103-how
-to-create-a-win32-dialog-based-application
>
> to częściej trafić można tego typu konstrukcje:
>
> http://eduinf.waw.pl/inf/prg/002_winasm/0011.php
> https://www-user.tu-chemnitz.de/~heha/petzold/ch11b.
htm
> (niepokoi mnie brak DestroyWindow...)
>
> Po co tutaj RegisterClass?
> Co to faktycznie daje, jeśli program ma wyświetlić tylko jedno takie okno?
>
> Jedyne, co mi przychodzi do głowy, to możliwość wyszukania uruchomionej wcześniej
instancji po klasie okna.
> Ale w takim wypadku, powinno się zarejestrować klasę dialogu niezależnie od typu
wywołania?
>
> Czy coś jeszcze?
> Jakaś mała śrubka, której brak da o sobie znać w najmniej oczekiwanym momencie? ;-)
>
> Szacun dla osobników, którzy ten majdan ogarniają. :-)

Ja to powoli już zapominam. Dlaczego nadal programujesz w WinAPI?
Pozdrawiam

do góry

> Dlaczego nadal programujesz w WinAPI?


Bo lubię. :-)


A tak na serio - zdeterminowany jestem platformą i narzędziem.
Muszę przerobić jedno starocie działające na ARM, napisane w C (Pelles), więc
wielkiego ruchu nie mam.
Temat mam w zasadzie ogarnięty, ale męczą mnie właśnie takie niuanse.

Zresztą ja naprawdę to lubię.
Tylko nie zawsze umiem... ;-)

do góry

On Friday, March 16, 2018 at 12:19:57 AM UTC+1, DMR wrote:
> > Dlaczego nadal programujesz w WinAPI?
>
>
> Bo lubię. :-)

Z tym co kto lubi, ciężko dyskutować, a nawet ciężko zadawać pytania :)

>
>
> A tak na serio - zdeterminowany jestem platformą i narzędziem.
> Muszę przerobić jedno starocie działające na ARM, napisane w C (Pelles), więc
wielkiego ruchu nie mam.
> Temat mam w zasadzie ogarnięty, ale męczą mnie właśnie takie niuanse.
>
> Zresztą ja naprawdę to lubię.
> Tylko nie zawsze umiem... ;-)

A nuż... zadam pytanie, z jakich powodów ściśle użytkowych zastanawiasz się
nad modalnością głównego okienka dialogowego?

Pozdrawiam

do góry

> Z tym co kto lubi, ciężko dyskutować, a nawet ciężko zadawać pytania :)


E... Ja tam ogólnie jestem otwarty. :-)
Ale otwarty, to znaczy otwarty na RÓŻNE opcje, a nie zamknięty na ich zestawy dobrane
według doraźnego klucza... ;-)



> A nuż... zadam pytanie, z jakich powodów ściśle użytkowych zastanawiasz się
> nad modalnością głównego okienka dialogowego?


Użytkowych? Żadnych. :-)
Aplikacja ma wyświetlać jedno okno i może ze dwa-trzy inne, otwierane tylko do
wprowadzania konkretnych zestawów danych, a ponieważ ma funkcjonować w systemie
Windows Mobile, gdzie i tak zasadniczo widać tylko jedno okno, to mi to tito, czy to
będzie okno modal, czy modeless... Chodzi mi tylko o aspekt techniczno-metodyczny.

Ja wiem, że to muzeum, ale bebechy aplikacji są w C i działają, więc wolałbym tego
nie zmieniać, a ponadto handheldy nie są tanimi zabawkami i propozycja wymiany całej
stajni hardware'u na nowszy raczej nie spotkałaby się z entuzjazmem... ;-)

Oczywiście, zawsze można zassać jakiś SharpDevelop (VS w podstawowych wersjach
platformy Mobile zdaje się nie obsługuje), a na komputerkach zaszczepić Compact
Framework i problem by zniknął, ale zniknąłby tylko pozornie - bo powyższe pytania i
tak pozostałyby bez odpowiedzi... :-)

do góry

On Thu, 15 Mar 2018 12:30:41 -0700 (PDT), DMR <m...@g...com>
wrote:
> Po co tutaj RegisterClass?

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ę. A zwykle
chcesz mieć własną.

> Czy coś jeszcze?

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

Myk w tym że Visual Studio może nie dać rady skompilować: nowe wersje
nie obsługują starych Windows (XP jeszcze chyba). Na szczęście GCC
daje radę.

do góry

> 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.

do góry

On Tue, 20 Mar 2018 04:28:25 -0700 (PDT), DMR <m...@g...com>
wrote:
> Nie pod klasę, tylko pod UCHWYT okna.

Wyruszyła mnie twoja historia.

No cóż, skoro bidulku nie wiesz po co jest niepotrzebne
MAKEPROCINSTANCE, skoro nie rozumiesz różnicy pomiędzy oknem a jego
klasą... to kim ja jestem, aby ostrzegać cię przed twoimi własnymi
pomysłami? Przeczytaj kilka książek, napisz kilkadziesiąt aplikacji,
sam dojdziesz do wszystkiego.

do góry

> to kim ja jestem, aby ostrzegać cię przed twoimi własnymi pomysłami?


No właśnie, pomyliłeś wątki.
Zjeżdżaj do tych z Caps Lockiem.

do góry

On Thu, 22 Mar 2018 13:31:30 -0700 (PDT), DMR <m...@g...com>
wrote:
> No właśnie, pomyliłeś wątki.

A jak tam z długością łuku paraboli? W końcu nic wstydliwego, ale jak
widzisz Internet niczego nie zapomina.

W tym wątku też nie zapomniał: pytałeś o potencjalne problemy jakie
mogą powstać przy pisaniu programu w którym główne okno jest
dialogiem. Windows API, jakieś starsze Windows CE, prawdopodobnie C.

Męczył cię problem dlaczego w książkowym przykładzie nie ma
DestroyWindow. (A tak na marginesie: skompiluj ten przykład, sprawdź
jak działa.)

Co patologiczne: upierasz się że funkcja obsługi okna jest skojarzona
z uchwytem okna, a nie z klasą okna. Choć nie podaje się jej w
CreateWindow (CreateWindowEx), ale przekazuje przy rejestracji klasy
okna.

Podsumowując: trochę ci brakuje wiedzy.

do góry