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

Started byDMR <mezzogm@gmail.com>
First post2018-03-15 12:30 -0700
Last post2018-03-23 01:40 -0700
Articles 8 on this page of 28 — 5 participants

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 2 of 2 — ← Prev page 1 [2]

#31529

Fromslawek <fake@fakeemail.com>
Date2018-03-24 08:35 +0100
Message-ID<almarsoft.7158707336028361174@news.v.pl>
In reply to#31527
On Sat, 24 Mar 2018 00:11:01 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> A jak wiadomo, takie spięcie można w każdej chwili rozpi�=
> �ć... :-)

Nie.

Nie można, tak samo jak nie można (nie powinno się) ubijać wątku.

Po prostu nie wiadomo co zrobić z komunikatami wysłanymi do wndproc1, 
które odbierze wndproc2.

Innymi słowy wysyłasz msg do guzika, a dostaje go pasek postępu.

To da się zrobić, ale nie "w każdej chwili".

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

#31530

FromDMR <mezzogm@gmail.com>
Date2018-03-24 00:48 -0700
Message-ID<538386de-c023-439a-a2d1-e5d5e147b76d@googlegroups.com>
In reply to#31529
Głupio ci teraz, nie...? ;-)


> Po prostu nie wiadomo co zrobić z komunikatami wysłanymi do wndproc1, 
> które odbierze wndproc2.


Komunikaty będą wysłane do tej funkcji, która znajdzie się pod wskaźnikiem lpfnWndProc - więc czego nie wiadomo?



> To da się zrobić, ale nie "w każdej chwili".


Miałem na myśli aspekt czysto techniczny, bez rozstrzygania o jego sensowności.

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

#31531

Fromslawek <fake@fakeemail.com>
Date2018-03-24 10:12 +0100
Message-ID<almarsoft.3562598879087596987@news.v.pl>
In reply to#31530
On Sat, 24 Mar 2018 00:48:24 -0700 (PDT), DMR <mezzogm@gmail.com> 
wrote:
> Miałem na myśli aspekt czysto techniczny, bez rozstrzygania o jeg=
> o sensowności.

Jeżeli coś jest bezsensowne to nie jest to technika, ale partactwo.

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

#31539

FromDMR <mezzogm@gmail.com>
Date2018-04-02 13:29 -0700
Message-ID<ef189ae7-130d-4583-996a-c6d771417d3d@googlegroups.com>
In reply to#31531
Tak jest. Subclassing to jest partactwo, dokowanie okien to też jest partactwo, jeszcze większe nawet.
Skoro już nie możesz powstrzymać się od kompulsywnego bębnienia w klawiaturę, to wpisz sobie w googlach "Efekt Dunninga-Krugera" i poczytaj... ;-)



Wracając do tematu zasadniczego - odpuściłem sobie te zabawy z dialogami, użyłem "czystego" CreateWindow i program śmiga.
Śmiga nawet za dobrze, więc nawiedziły mnie kolejne wątpliwości.

Generalnie działa to tak, że osobny wątek roboczy pobiera dane z portu szeregowego i obrabia je, a wątek z GUI ma zasadniczo tylko wyświetlić kilka wartości liczbowych (w kontrolkach STATIC), striggerowany za pomocą komunikatów WM_USER wysłanych z wątku roboczego.
Cały problem w tym, że te wyświetlone wartości mają sens jedynie ŁĄCZNIE.
To znaczy - chciałbym uniknąć hipotetycznej sytuacji, w której wątek GUI zmienia mi tekst tylko w części kontrolek, a potem idzie sobie... gdzieś, zostawiając mnie z bezsensownymi wynikami.
W tej chwili ostatnim krokiem aktualizacji zawartości kontrolek jest wywołanie systemowego brzęczyka - i tak to zostanie, ale przecież nie o to chodzi.

Reasumując: Czy istnieje jakiś w miarę prosty patent na wymuszenie skompletowania rozpoczętej operacji złożonej, w tym przypadku zmiany tekstu w sześciu kontrolkach?

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

#31543

FromRoman Tyczka <noemail@because.no>
Date2018-04-03 13:04 +0200
Message-ID<2nimjsvijfmx.dlg@tyczka.com>
In reply to#31539
On Mon, 2 Apr 2018 13:29:55 -0700 (PDT), DMR wrote:

> Reasumując: Czy istnieje jakiś w miarę prosty patent na wymuszenie skompletowania rozpoczętej operacji złożonej, w tym przypadku zmiany tekstu w sześciu kontrolkach?

Przekaż komunikatem adres struktury, która zawiera wszystkie wartości
jednocześnie.

-- 
pozdrawiam
Roman Tyczka

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

#31545

FromDMR <mezzogm@gmail.com>
Date2018-04-07 12:46 -0700
Message-ID<cb739bfc-d1a2-4bb3-8d66-d7b785cfab21@googlegroups.com>
In reply to#31539
> Wracając do tematu zasadniczego - odpuściłem sobie te zabawy z dialogami,
> użyłem "czystego" CreateWindow i program śmiga.


Do czasu... Właśnie user mi się spruł, że mu popsułem komputer.

Okazało się, że "zamknął" sobie aplikację przyciskiem "X", a ten - jak wiadomo - w Windows Mobile wcale nie służy do zamknięcia czegokolwiek.
Aplikacja pozostała więc w uśpieniu, z wątkiem "wgryzionym" w port szeregowy funkcją WaitCommEvent - nic dziwnego, że port "przestał działać".

Co ciekawe, kiedy głównym oknem był dialog, tapnięcie przycisku "ok" skutkowało wysłaniem komunikatu WM_COMMAND z parametrem wParam IDOK, pod który można było podpiąć DestroyWindow. A "X"... Nie mogę się doszukać, co i gdzie wysyła.

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

#31540

From"Kamil" <mospam@tlen.pl>
Date2018-04-02 23:50 +0200
Message-ID<p9u8io$ltm$1@node1.news.atman.pl>
In reply to#31516
Użytkownik "slawek" napisał:

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

Co rozumiesz przez "funkcję obsługi okna"? Jego tworzenie? Na to wskazuje
przywołana przez Ciebie CreateWindow, zresztą trochę obok bo wistujący pisał 
o oknach dialogowych, a te tworzone są inną funkcją CreateDialogParam. 
Wątkotwórca mógłby się zapoznać z argumentami wywołania tych funkcji, co by 
wiele wyjaśniło.

http://cpp0x.pl/dokumentacja/WinAPI/CreateWindow/1367

https://stackoverflow.com/questions/18870752/win32-createdialogparam-not-works

https://www.codeproject.com/Questions/497704/DialogBoxParamplus-plusCreateDialogParam

http://eduinf.waw.pl/inf/prg/002_winasm/0004.php

Pierwszym argumentem jest właśnie nazwa klasy. To jeśli chodzi o tworzenie
okna. natomiast jeśli przez obsługę rozumielibyśmy np. wpisywanie danych do
kontrolki, czy podobne działanie, to wtedy ma znaczenie uchwyt okna
wywoływany w tle przez ID okna. Zresztą i klasa i uchyt są związane z oknem, 
tyle, że w różny sposób.

Pzdr

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

#31518

FromDMR <mezzogm@gmail.com>
Date2018-03-23 01:40 -0700
Message-ID<41f4a6dd-612d-4a03-81c2-f423d1ca8878@googlegroups.com>
In reply to#31509
> 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? :-)


Właśnie odpaliłem przykład i mam na ekranie sześć "modalnych" okienek, które mogę sobie swobodnie klikać... :-)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web