On Fri, 23 Mar 2018 11:41:57 -0700 (PDT), DMR <m...@g...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.

do góry

On Sat, 24 Mar 2018 00:11:01 -0700 (PDT), DMR <m...@g...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".

do góry

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.

do góry

On Sat, 24 Mar 2018 00:48:24 -0700 (PDT), DMR <m...@g...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.

do góry

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?

do góry

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/136
7

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

https://www.codeproject.com/Questions/497704/DialogB
oxParamplus-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

do góry

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

do góry

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

do góry