Olivier Sannier wrote:
> In my own section, I'm freeing, indirectly, a class that contains a 
> TWSocketServer which not active.
> I know this comes from the indirect nature of my usage of the class, but 
> still, the order of finalization clauses should not be relied upon, as 
> it was always indicated by the Delphi team. In particular, it will be 
> different and changing when using packages.
Ok, to make it clearer, here is the organization of source files:

- MainUnit
uses ConfigUnit, SocketActionUnit
adds a TSocketAction to the list held by ConfigUnit

- ConfigUnit
define TBaseAction
contains unit variable FActions which owns a list of instances of 
classes derived from TBaseAction
finalization section frees FActions and thus frees the actions it contains

- SocketActionUnit
uses ConfigUnit, OverbyteIcsWSocketServer
define TSocketAction, deriving from TBaseAction
TSocketAction has a private member of type TWSocketServer which is 
created in the constructor and destroyed in the destructor.

Now, when shutting down the application, the finalization order will be 
as such:


As you see, the destruction of the TSocketAction instance occurs after 
the finalization section of OverbyteIcsWSocketServer has been called 
because it is destroyed from ConfigUnit, one of the last to be finalized.
To me, this is not an uncommon situation, and I think my patch proposes 
an efficient and transparent solution to this problem. Maybe it should 
be amended to include a few more changes, but the principle is here: do 
not rely on the finalization order.

Hope this helps clarify the situation a bit more.

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to