JEDI Windows API
If you include Forms and SvcMgr (Service classes) in the same project (in any sub unit) you may get a memory leak. It happens only if you call the Free method directly.
To make it work, you have to check for a side effect that I describe here.
The memory leak results from the SvcMgr.TServiceApplication.Destroy destructor which uses the global instance Forms.Application. In detail, it creates a memory block that is maintained by a list in TApplication. If you free the TApplication instance, the internal list is also freed, but the memory block is not! As a remedy you have to free the service object first and then recreate the TApplication instance (and if you need also the TServiceApplication).
The Forms and SvcMgr units creates their objects in the initialization section of the units. So you have to play around them.
Go through your units and check if you include SvcMgr and Forms.
Search
Paypal donation (EUR)
Categories
Archives
Tags
Recent Posts
Recent Comments
- Random Active Directory Notes | RemkoWeijnen.nl on Security Library
- Wouter van Nifterick on Programming Habits
- Christian Wimmer on JWSCL and FreeAndNil Second Attempt
- Ritsaert Hornstra on JWSCL and FreeAndNil Second Attempt
- Oliver on JWSCL and FreeAndNil Second Attempt
2 Responses
Joe White
11|May|2008 1Just curious… why would you explicitly free TApplication? I can’t think of a circumstance where that would make sense (though obviously you know of one).
Christian Wimmer
11|May|2008 2The main reason would be: Desktop handling
You can only use SetThreadDesktops, if there aren’t any window and hook handles on the current desktop. TApplication from Forms and SvcMgr creates such hooks on initialization.
Since the variable Application is created in the initialization section of the corresponding unit, we have to free it first and then recreate.
I also suspect, that it maybe a problem if Application should be used in a different thread than the main thread. I didn’t test or prove it yet.
However I experienced a problem with VCL that prevented me from switch the current thread back to the previous desktop (winsta0\default). Since there are no window handles (proved by process explorer), I consider a abandoned hook handle as the problem.
That is the reason why I created a new thread that holds the VCL Application object. As soon as the 2nd thread exits, I can show other forms or messageboxes on the default desktop because the main thread was always connected to the original desktop (default).
Leave a reply