-
August 10th, 2005, 05:00 PM
#1
GDI leak with WM_SETTEXT
Somehow I am creating lots and lots of GDI objects when the code
SendMessage(radius->handle(), WM_SETTEXT, 0, (LPARAM) (LPCSTR) double_to_string(radius->value()));
is run. For clarity,
char * double_to_string_static(double number_to_convert)
uses for the most part
_fcvt(number_to_convert, 1 /*decimal places*/, &decimal_offset, &sign_offset)
for it's work. Somehow the pointer that is sent as a message to my control, a static, creates a new GDI object. And eventually it becomes unstable and the controls start to get grey backgrounds and the contents are blanked out. This is where I've currently narrowed down the bug. If this isn't the cause of the grey craziness then at least it's one less potential bug.
Thannks in advance.
-
August 10th, 2005, 06:27 PM
#2
Re: GDI leak with WM_SETTEXT
What function are you calling SendMessage from.
It may be a reentrancy problem.
What is the type of the radius object (CStatic?)
Dave Mclelland.
-
August 10th, 2005, 08:55 PM
#3
Re: GDI leak with WM_SETTEXT
I'm sending it from WndProc(...) when I click a button. Radius is a Static control yes. But I'm not using ATL, I'm using plain Win32 so I call CreateWindowEx(...) with it's type as "STATIC". I think you're right, it does create two GDI objects so maybe it's calling WndProc(...) a second time.
Have you ever had the window suddenly turn grey? This may not be the cause despite it being a concern.
Thanks.
-
August 11th, 2005, 03:34 AM
#4
Re: GDI leak with WM_SETTEXT
Are you using GDI objects yourself to draw something?
Its possible that the problem you are seeing with the static control are a symptom of the problem of consuming the available GDI objects and the control itself is not at fault.
Its more likely that you are creating a gdi object (pen or brush or something) and not releasing it when you are through.
Dave Mclelland.
-
August 11th, 2005, 03:49 PM
#5
Re: GDI leak with WM_SETTEXT
I've already looked into that. I actually did have GDI leaks with my HBRUSH object.
I apparently also have a bug here because I create one new GDI object for each WM_SETTEXT message I send. I am very sure it is from this code.
When I narrow it down I'll be sure to post it here.
-
August 11th, 2005, 03:53 PM
#6
Re: GDI leak with WM_SETTEXT
If you dont send the WM_SETTEXT do you still have the leak?
Dave Mclelland.
-
August 12th, 2005, 08:45 AM
#7
Re: GDI leak with WM_SETTEXT
Originally Posted by richard-aggragant
Somehow I am creating lots and lots of GDI objects when the code
SendMessage(radius->handle(), WM_SETTEXT, 0, (LPARAM) (LPCSTR)
<snip>
Somehow the pointer that is sent as a message to my control, a static, creates a new GDI object. And eventually it becomes unstable and the controls start to get grey backgrounds and the contents are blanked out. This is where I've currently narrowed down the bug. If this isn't the cause of the grey craziness then at least it's one less potential bug.
Thannks in advance.
Well, I think the bug is somewhere else and sending a WM_SETTEXT just triggers that buggy part of code to get executed, probably sending it sends a WM_PAINT as a result to the control or dialog. And there (WM_PAINT handler) I think lies the problem. Just a test, try to resize the Dialog/Window of your application and check if the GDI objects count raise (use Task Manager to view the GDI Object count) and stays there. If it does raise everytime, then check all the WM_PAINT handlers for your main Window/Dialog and also for controls for GDI object not being disposed off properly.
HTH,
Regards,
Usman.
-
August 12th, 2005, 03:24 PM
#8
Re: GDI leak with WM_SETTEXT
I found the bug. When I commented out the SendMessage(...) my GDI count did go up when I minimized and resized the window. I hadn't noticed that before. I did use Task Manager to see my GDI Object count. And the bug wasn't in WM_PAINT, it was in WM_CTLCOLORSTATIC which I'm using to give my controls a custom colour, I have some controls that are blue, others that are grey. The problem was that when I use CreateSolidBrush(...) to set the colour I need to return my HBRUSH object, so I can't use DeleteObject(...) on it. That HBRUSH flies off into memory without any references the next time I run the same code.
The solution that works? Save an HBRUSH with my control and create that HBRUSH once and if I ever need to change the colour I can safely delete the old one.
That was annoying.
Thanks for the help everyone.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|