PlanetSquires Forums

Support Forums => Other Software and Code => Topic started by: Mark Strickland on May 08, 2006, 04:54:09 PM

Title: Still looking for GDI leaks
Post by: Mark Strickland on May 08, 2006, 04:54:09 PM
I thought maybe I knew where I was creating so many GDI's but it appears I don't know.  At one point I thought it was tool tips but it is not my problem (all commented out).

I have this function to calculate the number of GDI objects:


FUNCTION GetGDIcount() AS LONG
  LOCAL hProcess AS DWORD
  GETWINDOWTHREADPROCESSID HWND_FORMMAIN, hProcess
  hProcess = OPENPROCESS(%PROCESS_QUERY_INFORMATION OR %PROCESS_VM_READ, 0, hProcess)
  FUNCTION = GETGUIRESOURCES(hProcess, %GR_GDIOBJECTS)
END FUNCTION


Is there a place in the generated code that is a loop where each form is created that I could call this function and log the GDI objects with each new form created?

I know I could add it to the CREATE in every form but I have many forms and hundreds of controls and it is painful process to put this in every form.
Title: Still looking for GDI leaks
Post by: TechSupport on May 09, 2006, 02:56:47 PM
Forms are not all created at startup so there is no one place like a loop where you could easily place your code. Each Form gets created via its own function call. For example, FRMMAIN_SHOW, FORM1_SHOW, MYFORM_SHOW..... basically, the form name appended with _Show. In that function's code you could place the GDI function prior to the CreateWindowEx function as well as after it if you wanted to calculate how many GDI objects the form has consumed.
Title: What I have found
Post by: Mark Strickland on May 09, 2006, 04:59:01 PM
It appears that the structure of the program generated by FF is what creates most of the 3,100 GDI objects.

This application has over 600 controls and most are on forms that are on tabs.  The tabs are two levels deep.  Essentially almost every form in the application, 22 of them, are open at the same time.

I added some displays of the GDI count at various places in the FF generated code and compiled it in the PBWIN 8.x IDE.  The modified form is a very "vanilla" form and has no extra color painting or other "funny stuff".

The results:

One big form (approx counts)
40 Text boxes
4 Check boxes
45 Labels
5 Buttons
3 Frames


Display GDI objects at various points in the FF generated code for this form ---

Beginning of the FORM_SHOW FUNCTION = 1181
End of the FORM_SHOW FUNCTION = 1360

A total of 179 GDI objects

I commented out the call to CREATE_FUNCTIONS for this form ---
Beginning of FORM_SHOW FUNCTION = 1181
End of the FORM_SHOW FUNCTION = 1181

I re-enabled the call to CREATE_FUNCTIONS and then commented out
the first 5 controls on the form:
Beginning of FORM_SHOW FUNCTION = 1181
End of the FORM_SHOW FUNCTION = 1360

Exactly 10 GDI objects less.  Two per control.  This ties approximately with the control count and the total GDI objects for this form.

So it appears that the NORMAL behavior of FF for TABBED FORMS is to create LOTS of GDI Objects.  Since the number of objects is pretty stable during the program life I suppose it is not a problem.

There is one CreateSolidBrush per control that, if commented out, creates one less GDI object for each one commented out.

Two questions remain ---
1) Is it a problem to have 3,100 GDI Objects?
2) Do they get destroyed when the program ends?

Thanks.
Title: Still looking for GDI leaks
Post by: TechSupport on May 09, 2006, 06:12:11 PM
It is not necessarily a problem to have that many GDI objects. On older 9x systems the number of available GDI objects was much smaller than it is on more modern NT based systems. Sure, if you have a lot of large applications open then you could run out of GDI resources and the operating system would become very unstable.

FireFly3 will use a more sophisticated resource handling system allowing things like font handles to be shared amongst controls/forms throughout the project rather than having it created per control/form. In your case because you have such a large quantity of forms and controls that open all the time then you will notice a larger consumption of resources.
Title: Still looking for GDI leaks
Post by: Philipp Emanuel Weidmann on May 12, 2006, 01:22:08 PM
Two utilities that I use for identifying resource leaks:

GUI Resource Tracer by Steve McMahon (full VB source provided):
http://vbaccelerator.com/home/VB/Utilities/GUI_Resource_Tracer/article.asp

Sysinternals Process Explorer (you either have it or you need it):
http://www.sysinternals.com/Utilities/ProcessExplorer.html
Title: Thanks
Post by: Mark Strickland on May 12, 2006, 02:51:50 PM
Philipp,

Thanks for the note.  I know about the Sysinternals tools (although I have not used the process explorer much).  I will give it and the VB tool a look.

I have now determined I don't have a GDI leak but the 600+ controls in this project creates lots of GDI objects.

Thanks.