multithreading - Order of TForm creation and destruction and threads -

i have thread calls functions of form update form. when task done, thread updates form results, using synchronize , works fine while program running.

the problem happens when thread running , close program got access violation. caused thread updating form released. after rearranging order of form creation (calls application->createform) worked fine because form holds thread code created before form updated. seems order of destruction reverse creation order.

i added code in form destructor make sure thread terminated if form destroyed before form thread code. rearranging form creation order and/or code in form destructor solves problem.

but have 3 questions:

1. what order in created forms destroyed? reverse of creation order assume now?

2. is there better way above task - update form gui items after thread done processing data. right thread using synchronize experienced threads may have better idea. 1 other idea had remove bunch of createform generated compiler , create them manually, create main form using createform better control order of destruction (as suggested rob kennedy - http://pages.cs.wisc.edu/~rkennedy/createform).

3. how expensive dynamic form creation/destruction in typical application? better use form hide , keep in memory or destroy on close?

when create component owner, owner adds component list of components owns. happens in code:

procedure tcomponent.insert(acomponent: tcomponent); begin   if fcomponents = nil fcomponents := tlist<tcomponent>.create;   fcomponents.add(acomponent);   if fsortedcomponents <> nil     addsortedcomponent(acomponent);   acomponent.fowner := self; end; 

as can see component added end of list.

when owner destroyed, calls destroycomponents:

procedure tcomponent.destroycomponents; var   instance: tcomponent; begin   freeandnil(fsortedcomponents);   while fcomponents <> nil   begin     instance := fcomponents.last;     if (csfreenotification in instance.fcomponentstate)       or (fcomponentstate * [csdesigning, csinline] = [csdesigning, csinline])       removecomponent(instance)     else       remove(instance);     instance.destroy;   end; end; 

as can see, loop processes last member first. so, components destroyed in reverse order.

personally not rely on destruction order. if form needs sure thread terminated before form destroyed, write code in form's destructor enforce that.

using synchronize respectable solution many problems. whether or not it's best solution problem impossible me because have not described problem.

how expensive dynamic form creation/destruction in typical application?

not very. typically forms shown in response user interaction. programs can create forms lot faster users can process them. dynamically creating forms seldom problem. if wanted create , destroy thousands of forms second might problem. bizarre.