Форма в разклонение

То си е ясно, че по подразбиране проблема е в програмиста само, че в случая съвсем нищо не мога да разбера:

в модула на главната форма:

uses ...ThreadForm;

Procedure TForm1.Button1Click(Sender: TObject); // Form1 - главната
begin
FormThread := TFormThread.Create(FALSE);
end;

----------

unit ThreadForm;

interface

type TForm2 = class(TForm)
public
FDESTROY: boolean;
constructor CreateNew(AOwner: TComponent); reintroduce;
end;

TFormThread = class(TThread)
private
Form2: TForm2;
protected
procedure Execute; override;
end;

var FormThread: TFormThread;

implementation

constructor TForm2.CreateNew(AOwner: TComponent);
begin
inherited CreateNew(AOwner);
FDESTROY := FALSE;
.................
end;

procedure TFormThread.Execute;
begin
Form2 := TForm2.CreateNew(Application);
try
Form2.Show;
repeat
Application.ProcessMessages;
until Terminated or Form2.FDESTROY;
finally
Form2.Free;
end;
end;

------------

Видимо аз поне в тоя код не виждам проблем. Обаче като го пусна става много весело - тръгват едни Ацес виолатиони, от време на време някоя страна грешка като "Липсващ Канвас" или нещо такова, "Canot change Visible in SHow"??, а при повече късмет Win казва, че няма и памет. В единия случай се оказа че няма памет да отвори "Start" менюто. Още по странно ми се вижда постъпковото изпълнение, през реда:

until Terminated or Form2.FDESTROY;

си минава без проблеми макар че и двете са FALSE.
Някой мойе ли да ми го обясни това?

;-))))))
Naistina e weselo - prosto si propusnal edna malka belezka - niakade ia 4etoh - wsi4ko koeto zasiaga VCL i po specialno obnowiawaneto na ekrana triabwa da stawa sinhronno (maj ne e naj -to4nata duma) s glawnia thread na programata - ima podoben primer w tezi na Delphi - prosto pomni 4e nestata tuk zawisiat gawno ot VCL kojto lock-wa canvas -a na programata.

Pogledni primera w direktoria Threads - i obarni wnimanie na
Synchronize(DoVisualSwap); - wsi4ki 4ertania po ekrana triabwa da minawat prez tazi funcia na TThread clasa

- towa e izwadka ot helpa

Executes a method call within the main VCL thread.

type TThreadMethod = procedure of object;
procedure Synchronize(Method: TThreadMethod);

Description

Synchronize causes the call specified by Method to be executed using the main VCL thread, thereby avoiding multi-thread conflicts. If you are unsure whether a method call is thread-safe, call it from within the main VCL thread by passing it to the Synchronize method.

Execution of the thread is suspended while Method is executing in the main VCL thread.

Note: You can also protect unsafe methods using critical sections or the multi-read exclusive-write synchronizer.


---
Е т'ва е живот!

Благодаря ти - точно в това се съмнявах - синхронизацията. Мислех да наблъскам всичко в синхрон-методи, ама не остана време тогава.

Mdam... zora maj e poradi towa che windows hitree ili po skoro VCL hitree i polzwa funkcii koito karat Win da prawi SendMessage a ne PostMessage i ot tam mu se takowa onakowata! obshto wzeto izbqgwajte da pishete multi threading apps w koito edin thread da wika GUI api funkcii ako waprosniq thread nqma MessagePump i ne e registriral prozorechen klas - imache mamata mu se ebawa.
Nakratko : Ako prozoreca trqbwa da swyrshi neshto i towa se razbere w thread kojto ne e syzdal prozoreca... prawi se PostMessage () s podhodqshtiq habdle i nqkakawo specifichno syobshtenie ... a samiq prozorec trqbwa da prehwane wyprosnoto syobshtenie i da naprawi kakwoto se iska ot nego. Prozorechnata funkciq otgoworna za obrabotkata na Mesg-ovete se wika ot Win w konteksta na nishkata syzdala jama - ergo moje da si prawi s nego koto si iska.
Wajno e da se pomni: Danni mogat da se razmenqt mejdu nishkli ama s koda e malko po-trudno - naj malkoto trqbwa mnogo da se wnimawa koq api funckiq w kontekstana koj thread se wika i dali towa nqma da syzdade problem... izwoda e ako ne ste sigurni - prashtajte si syobshteniq mejdu nishkite i bydete shtastliwi.