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: SocketActionUnit OverbyteIcsWSocketServer MainUnit ConfigUnit 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. Cheers Olivier -- 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
