Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #31497 > unrolled thread

[WinAPI] Okno dialogowe jako główne

Back to article view | Back to pl.comp.programming

Contents

  [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-15 12:30 -0700
    Re: [WinAPI] Okno dialogowe jako główne "M.M." <mmarszik@gmail.com> - 2018-03-15 15:03 -0700
      Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-15 16:19 -0700
        Re: [WinAPI] Okno dialogowe jako główne "M.M." <mmarszik@gmail.com> - 2018-03-16 06:21 -0700
          Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-16 09:12 -0700
    Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-19 16:50 +0100
      Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-20 04:28 -0700
        Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-22 15:50 +0100
          Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-22 13:31 -0700
            Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-23 07:11 +0100
              Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-23 01:33 -0700
                Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-23 12:34 +0100
                  Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-23 04:51 -0700
                    Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-23 15:23 +0100
                      Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-23 07:56 -0700
                        Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-23 16:34 +0100
                        Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-23 17:07 +0100
                          Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-23 11:41 -0700
                            Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-24 08:26 +0100
                Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-24 00:11 -0700
                  Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-24 08:35 +0100
                    Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-24 00:48 -0700
                      Re: [WinAPI] Okno dialogowe jako główne slawek <fake@fakeemail.com> - 2018-03-24 10:12 +0100
                        Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-04-02 13:29 -0700
                          Re: [WinAPI] Okno dialogowe jako główne Roman Tyczka <noemail@because.no> - 2018-04-03 13:04 +0200
                          Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-04-07 12:46 -0700
              Re: [WinAPI] Okno dialogowe jako główne "Kamil" <mospam@tlen.pl> - 2018-04-02 23:50 +0200
        Re: [WinAPI] Okno dialogowe jako główne DMR <mezzogm@gmail.com> - 2018-03-23 01:40 -0700

Page 1 of 2  [1] 2  Next page →

#31497 — [WinAPI] Okno dialogowe jako główne

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ą. :-)

[toc] | [next] | [standalone]

#31501

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

[toc] | [prev] | [next] | [standalone]

#31504

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

[toc] | [prev] | [next] | [standalone]

#31505

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

[toc] | [prev] | [next] | [standalone]

#31507

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

[toc] | [prev] | [next] | [standalone]

#31508

On Thu, 15 Mar 2018 12:30:41 -0700 (PDT), DMR <mezzogm@gmail.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ę.

[toc] | [prev] | [next] | [standalone]

#31509

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

[toc] | [prev] | [next] | [standalone]

#31514

On Tue, 20 Mar 2018 04:28:25 -0700 (PDT), DMR <mezzogm@gmail.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.

[toc] | [prev] | [next] | [standalone]

#31515

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

[toc] | [prev] | [next] | [standalone]

#31516

On Thu, 22 Mar 2018 13:31:30 -0700 (PDT), DMR <mezzogm@gmail.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.

[toc] | [prev] | [next] | [standalone]

#31517

Przepraszam najmocniej, ale życie jest o wiele krótsze niż się wszystkim wydaje, a żadna minuta się w nim nie powtórzy - szkoda więc ją marnować na "debaty" z buractwem.
A niezależnie od przeświadczenia o bogactwie wewnętrznej implementacji, jeśli interfejs obiektu jest buraczany, to z mojego punktu widzenia jest to obiekt klasy burak.
I tyle. 



> W końcu nic wstydliwego, ale jak 
> widzisz Internet niczego nie zapomina.


Ależ ja się niczego nie wstydzę. Nawet gdybym chciał - to nie mam czego.
Zresztą, w moim przypadku przynajmniej ma co pamiętać.



> Podsumowując: trochę ci brakuje wiedzy. 


Zasadnicza różnica między nami jest taka, że ja o tym WIEM.
Stąd moja obecność tutaj.
Ty wyraźnie pomyliłeś wątki, o czym już wspominałem.



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


Netykieta przypadkiem nie wymaga przeczytania wpisu, na który się odpowiada?
Zresztą, jeśli ktoś nie uważa za stosowne czytać, to co za różnica - czego...



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


Akurat to był temat marginalny.
Przykład działa.
Obiekt bez destruktora albo tablica usunięta bez [] - też 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.


A wiesz, gdzie ja mam twoje projekcje? :-)

Najpierw się zdecyduj, czy "podpięta" i "skojarzona", to to samo.

Widać, że "spięcie" procedury z klasą okna dialogowego z zasobów następuje w funkcji CreateDialog/DialogBox, zwracającej uchwyt utworzonego okna.
Domyślam się, że jest to połączenie unikalne, bo przecież za chwilę mogę wywołać TEN SAM dialog, ale już ze wskaźnikiem do INNEJ procedury.

Wobec powyższego, nie od rzeczy jest pytanie o sens PONOWNEJ rejestracji dialogu za pomocą RegisterClass?
Liczę na to, że znajdzie się ktoś, kto mi jednym dobrym strzałem temat wyklaruje.

Nie będę natomiast tracił czasu na spory z "kwadratowymi" osobnikami, którym się wydaje że pozjadali wszystkie rozumy i usiłują namolnie ustawiać dyskusję pod swój "kwadratowy" poziom.

[toc] | [prev] | [next] | [standalone]

#31519

On Fri, 23 Mar 2018 01:33:12 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Liczę na to, że znajdzie się ktoś, kto mi jednym dobrym=
>  strzałem temat wyklaruje.

Czytaj książki. To pomaga lepiej niż walenie się w mordę lub udawanie 
tarczy na strzelnicy. Pisz programy. Jeżeli nie idzie ci to zbyt 
dobrze, to zajmij się czymś innym - może lepieniem z plasteliny?

[toc] | [prev] | [next] | [standalone]

#31520

> Czytaj książki.


Jesteś w stanie wymienić kilka wartościowych pozycji - czy potrafisz tylko obszczekiwać, internetowa przybłędo?

[toc] | [prev] | [next] | [standalone]

#31521

On Fri, 23 Mar 2018 04:51:27 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Jesteś w stanie wymienić kilka wartościowych pozycji - czy p=
> otrafisz tylko obszczekiwać, internetowa przybłędo?

Jestem: Norton, Petzold plus MSDN, plus parę jeszcze (rozmaite Art of 
i Black Book-i, coś Practical etc.)

A co do ciebie to mam dwie, wykluczające się, hipotezy. Albo jesteś 
ciamajdą pozującym na twardziela, albo jesteś chamem udającym 
inteligenta.  W każdym razie brakuje ci umiejętności miękkich, tzn. 
nie potrafisz współpracować w zespole. Postawa roszczeniowa, 
nieumiejętność prowadzenia dialogu, ble ble ble...

Tak czy siak nudzisz. I jest zero sensu ci pomagać.

[toc] | [prev] | [next] | [standalone]

#31522

> Jestem: ... plus parę jeszcze ... rozmaite ... coś ... etc.


Tak właśnie myślałem.



> mam dwie, wykluczające się, hipotezy.


Pisałem już trzy razy... NTG.



> nie potrafisz współpracować w zespole


W jakim zespole? Piłeś coś? :-)
Jak twoje umiejętności obserwacji i wnioskowania właśnie tak wyglądają, to mam propozycję - trzymaj się jak najdalej z "pomaganiem" komukolwiek... :-)



> nieumiejętność prowadzenia dialogu


Z zakutymi pałami się nie da z definicji.
i nie mam na to żadnego wpływu.



> Tak czy siak nudzisz. I jest zero sensu ci pomagać.


Jak zaczniesz, to będziesz miał tytuł do wypowiadania się.
Na razie gęba ci się nie zamyka od frazesów, a od konkretów się wyraźnie migasz.
Niech twój szef ocenia, czy twoje zalety są aż tak wielkie, żeby coś takiego kompensowały. Nie wydaje mi się.
W moim "zespole" dla takich nie ma miejsca. EOT.

[toc] | [prev] | [next] | [standalone]

#31523

On Fri, 23 Mar 2018 07:56:23 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Z zakutymi pałami się nie da z definicji.

Bardzo bolało jak ci zakuwali?

[toc] | [prev] | [next] | [standalone]

#31524

On Fri, 23 Mar 2018 07:56:23 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Jak zaczniesz, to będziesz miał tytuł do wypowiadania si�=

Misiu, czasy PZPR skończyły się jeszcze zanim ty nauczyłeś się 
tabliczki mnożenia. Nie ty jesteś moderatorem tego forum, nie ty 
"udzielasz głosu".

> Na razie gęba ci się nie zamyka od frazesów, a od konkret�=
> �w się wyraźnie migasz.

Jesteś głupi, chamski i próbujesz brykać niczym młody kuc. A ja nie 
mam ani obowiązku, ani ochoty pomagać. Zwłaszcza nieujeżdżonym kucom. 
A ujeżdżać cię nie chcę. Witaj w realnym świecie. W którym pomaga się 
tym którzy PROSZĄ o pomoc.

> W moim "zespole" dla takich nie ma miejsca. EOT.

Nie ma żadnego zespołu. Gdyby był, to właśnie tam szukałbyś pomocy.

[toc] | [prev] | [next] | [standalone]

#31526

Kontakty z hejterem-niedojdą nie mają żadnego sensu, forma nie ma tu nic do rzeczy.

[toc] | [prev] | [next] | [standalone]

#31528

On Fri, 23 Mar 2018 11:41:57 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Kontakty z hejterem-niedojdą nie mają żadnego sensu, forma n=
> ie ma tu nic do rzeczy.

Oczywiście. Dlatego nie kontaktuje się z jakimś tam DMR, tylko piszę 
na otwartym forum: chcecie pomocy? To poproście o nią. A jak ją 
otrzymujecie - nie hejtujcie. I wypadałoby podziękować. Pamiętając że 
wszyscy dyskutanci są równi - nie mają znaczenia płeć, wiek, 
wykształcenie, pochodzenie, wielkość firmy ani kolor lakieru 
samochodu. To są elementarne zasady. Kto ich nie chce zrozumieć - 
dobrym programistą nie będzie - zepsuje współpracę w zespole. Bo 
programowanie - dziś - to także umiejętności społeczne.

[toc] | [prev] | [next] | [standalone]

#31527

> Widać, że "spięcie" procedury z klasą okna dialogowego z zasobów następuje
> w funkcji CreateDialog/DialogBox, zwracającej uchwyt utworzonego okna.
> Domyślam się, że jest to połączenie unikalne, bo przecież za chwilę mogę
> wywołać TEN SAM dialog, ale już ze wskaźnikiem do INNEJ procedury.


Nie koniecznie unikalne - w chwili rejestracji klasy może być znany tylko prototyp procedury okna, a więc jest to "spięcie" jedynie ze wskaźnikiem do funkcji.
A jak wiadomo, takie spięcie można w każdej chwili rozpiąć... :-)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pl.comp.programming

csiph-web