| Destroy-events Updated 09 Aug 2008 | Upper levels: - QuArK Information Base - 4. The Source Code - 4.7. Known bugs in the Source ...

4.7.3. Destroy-events | [ Prev - Up - Next ]

Index

- - Destroy-events (09 Aug 2008)

Destroy-events | DanielPharos - 09 Aug 2008 | [ Top ]

To improve performance most forms in Delphi are recycled: They are closed, never destroyed. The Destroy-events of forms are triggered from Delphi's own code, when QuArK shuts down and all remaining objects are unloaded. This however means that the Destroy-event of forms are triggered when the bulk of the program has already been removed from memory! Specifically, the controls are already all gone. The Destroy-event triggers the Close-event though, and this is where the problem lies: the close-event is often not prepared for a there-are-no-controls-situation! Example: QkListview.pas, TQForm2.FormClose:
      g_Form1.AbortIdleJob(ListView1);
When this is triggered from the Destroy-event, the Destroy-event of Form1 has already run; g_Form1 is now nil! This triggers a difficult to trace access violation, that doesn't seem to make sence or do anything harmfull expect crash QuArK on shutdown. The workaround is putting in a check for g_Form1, which I have done. However, maybe this should be fixed differently and all together by running the Destroy-events on these forms BEFORE Form1/the program shuts down! Another location where this (or something very similar) was happening: Config.pas: DisableTimer (This is to indicate that parts of the Close-event shouldn't be run)

Copyright (c) 2009, GNU General Public License by The QuArK (Quake Army Knife) Community - http://quark.sourceforge.net/ | [ Prev - Top - Next ]