Změny TForm.Handle – Delphi – Fórum – Programujte.com

Zdravím
Potřebuji poradit, a také jestli někdo může potvrdit že následující je normální nebo mám něco někde špatně. Jde o to že při změně určitých parametrů formu (např. Position, BorderStyle, FormStyle, ...) za chodu, se také změní jeho handle.
Potřebuji to protože mi na pozadí běží pár vláken které na handle daného okna posílají zprávy (pomocí PostMessage), tento handle zadám jako property daných vláken před jejich spuštěním, takže pokud se za běhu změní tyto parametry (a jakože se změní), tak vlákna dál posílají zprávy na špatný handle => nefunkční program (nemůžu si dovolit aby se "ztratila" byť jediná zpráva).
A nějak nevím jak toto vyřešit. Přemýšlel jsem o následujícím:
Změnit property daného vlákna když měním form, ale nemám jistotu že mezi tím než získám nový handle a předám ho vláknu toto vlákno nepošle zprávu blbě. A navíc nejsem takový znalec, takže nevím jestli je změna property vlákna za běhu thread-safe, pokud je definovaná jen takto:

property SendToWnd: Cardinal read thrSendToWnd write thrSendToWnd;

property SendToWnd: TForm read thrSendToWnd write thrSendToWnd;

Změna handle není nic nekalého, ale nejedná se o změnu handle, ale o vytvoření nového okna. Když se podíváš přes Spy++ třeba na vnitřní okno Notepadu a změníš styl Formát -> Zalamování řádků, tak se prostě udělá nové okno s původním obsah v jiném formátu. Ovšem mění se nějaké vnitřní okno, nikoliv hlavní okno, to jsem zatím nikde nepostřehnul :).

V podstatě se můžeš odpíchnout od ID procesu, které se snad nemění :).

Přes API funkce GetTopWindow, GetNextWindow a GetWindowThreadProcessId zjistíš, které HWND patří k tvému procesu a tak můžeš detekovat změnu.

To je taková "hardcore" možnost. Ještě bych se podíval, jestli máš ten form v moci, tak zkusit předat místo handle referenci na něj, jestli by ses nedostal vždy k platnému handle.

Za to objasnění okolo handlu díky. Nikdy jsem to nepotřeboval tak to neznám - holt jsem amatér no.

Popíšu to trochu blíže, aby bylo jasnější jak to vypadá.
Program má od počátku skryté hlavní okno (resp. Application.ShowMainForm := False), a okno o které se jedná (mění se mu handle) je SplashScreen. SplashScreen se animuje, a to pomocí jednoho vlákna běžícího na pozadí, no a tohle vlákno mu mění zmíněné vlastnosti podle potřeby pro animaci (samozřejmě používám Synchronize()). Mimo toho na pozadí běží několik (prozatím 2) vláken které načítají a zpracovávají mračna dat potřebných pro "start" programu (tj. zobrazení hl. okna). A tyhle vlákna přeposílají pomocí zpráv svůj stav splash oknu. To je zpracovává a nějak na ně reaguje - mimo jiného tím že vláknu které má na starosti animaci řekne že je vše načteno a má se animovat FadeOut (postupné zmizení splash okna) a zobrazit hlavní okno. No a pokud tyhle zprávy neobdrží tak je jasné jak to skončí - splash zůstane viset na obrazovce navěky.
A teď proč nekontroluji přímo jestli doběhly vlákna načítající data (např pomocí WaitforMultipleObjects, WaitFor, ...) - protože vlákno řídící animaci musí být na těchto "načítacích" vláknech zcela nezávislé (nesmí na ně nijak odkazovat, ani se spoléhat na nějaké příchozí údaje), a splash okno nesmí na něčem takovém zamrznout.
Pracovat s PID mi přijde opravdu už moc hardcore (ale problémy by mi to asi ani nedělalo, znám to).
Jak vyplývá z předchozího - okno mám v plné moci, ale vlákna si běží každé na svém písečku takže bych z nich nerad lezl do VCL, ale jako poslední možnost... - může být že bych tam hodil nějakou proceduru co by načítala aktuální handle a tu volal v Synchronize() pokud návratová hodnota SendMessage nebude sedět.

Jinak ať tu zbytečně nepíšu trachtáty - je změnění property a tím i nějaké vnitřní proměnné vlákna za běhu thread-safe nebo není?

Sniper napsal:je změnění property a tím i nějaké vnitřní proměnné vlákna za běhu thread-safe nebo není?

No nevim, kvůli předání jednoho čísla mezi vlákny jednoho procesu používat síťový záležitosti to se mi zdá trochu moc. Na to tu mám globální proměnné a kritické sekce, a mezi procesy se mi osvědčilo použití pojmenovaných MemoryMappedFile a mutexů (i sem si na to sepsal třídu).
Zatím to řeším tak, že v načítacích vláknech jsem nahradil PostMessage za SendMessage (posílám na splash okno), a pokud tato nevrátí očekávaný výsledek, tak znovu načtu handle splash okna (referenci na něj zadávám při vytvoření vlákna), samozřejmě uvnitř Synchronize(), a pak opakuji odeslání (resp. ho opakuji dokud není úspěšné - tady bych to možná mohl omezit na určitý počet, kdyby se něco po..., abych neodesílal donekonečna). Zní to možná blbě, ale už jsem napsal větší zvěrstva, a zatím to, zdá se, funguje.
Jináč to splash okno tam v zásadě funguje jako řídící prvek pro všechny vlákna.

Ale pokud má kdokoliv jiný návrh řešení, rád se přiučím.

Jsou lidi, co předávají jakákoliv data přes soket. Ono to má totiž jednu výhodu, a to tu, že je to buď zabezpečený přenos (zpráva vždy dorazí - TCP) nebo "nezávislý" přenos a klidně i z více míst najednou bez potvrzení (UDP). Z určitého pohledu je to i lepší než globální proměnná, sdílená paměť apod. Ale jinak je to pořád to samé (soket, pipe, paměť ....).

V podstatě to řešíš dobře, jenom pozor na to, že SendMessage je blokující. Možná by bylo lepší nejdříve handle testovat (IsWindow), jestli je to pořád ještě okno.

A další možností je, aby si splash screen chodil pro ty data do těch oken sám - těm se asi handle nemění .... ;)