Problem With Autoit3-gui After A Some Hours

[Holger]

Hi,

I have a displaying-problem with an Autoit3-Gui-script.

After some hours it changes complete and the desktop is colorless and nor icons are there.

http://de.geocities.com/kotschi2002/pics.html

The first is the script after some hours...

Maybe someone had/has the same problem, maybe it's a resource-problem or a gui-refreshing-problem, I don't know...

Or maybe you have an idea what it could be.

Big picture-versions I think you can see if you enter at first the html-site and then enter in your browser-adressline directly:

http://de.geocities.com/kotschi2002/gui-problem.jpg

http://de.geocities.com/kotschi2002/virpatch_snap.jpg

Thanks Holger

P.S.: does someone know a free websapce provider?....

Edited April 14, 2004 by Holger

[joell]

Team,

I encounter the same problem. I first accuse my Notes clients, because part of my script items were replaced by Notes items when i was moving the mouse (pretty strange to have a huge Notes icon in place of the red button ), but even without Notes the problem was still there, a few minutes after power saving for example.

A few elements:

Autoit-gui.102.15 or .16

WinXP Pro US

btw JP it seems that the progress control does not work with .16 (crashes if you don't specify STYLE... but it's still a marvelous tool..)

Thanks

[jpm]

Team,

I encounter the same problem. I first accuse my Notes clients, because part of my script items were replaced by Notes items when i was moving the mouse (pretty strange to have a huge Notes icon in place of the red button  ), but even without Notes the problem was still there, a few minutes after power saving for example.

A few elements:

Autoit-gui.102.15 or .16

WinXP Pro US

btw JP it seems that the progress control does not work with .16 (crashes if you don't specify STYLE... but it's still a marvelous tool..)

Thanks

I know for the progress style the 102.17 is coming.

but for the the loose of resource I need to understand what functions are executed

[Valik]

Check the GDI count (Through task manager, add the column). Make sure no GDI's are leaking out. JP, are all HDC's properly released after they are finished being used?

[Holger]

@Valik: thanks for the info.

Yeah, you're right, the GDI-resources-count was about 9999.

With the HDC?...hmmm...maybe possible...

Thank you.

[Holger]

oooohhhh, I think there is a bigger problem then I thought !!!

Try a gui with for instance only a groupbox or combox, label, etc ;

Then check always the gdi-objects and minimize and maximize often the gui then you'll see that the used resource-objects are will be more and more... !?

Edited April 14, 2004 by Holger

[Valik]

search source for GetDC... make sure there are related ReleaseDC...

Lar.

An even better solution might be to wrap HDC's in a small class which will auto-release when the destructor is called. It should be a small, simple class. It could even be no more than just takes an HDC object as a parameter in the constructor, offers an member function to return the HDC for use in Win32 functions, and the destructor could release it.

[Valik]

oooohhhh, I think there is a bigger problem then I thought !!!

Try a gui with for instance only a groupbox or combox, label, etc ;

Then check always the gdi-objects and minimize and maximize often the gui then you'll see that the used resource-objects are will be more and more... !?

The leak is somewhere in the re-painting code, obviously. Maximizing causes a repaint to happen and so right there you have some GDI leaks if things aren't released properly. Under normal circumstances, this probably isn't an issue, but in some cases it can be. It's not really any more or less important than originally pointed out.

[jpm]

The leak is somewhere in the re-painting code, obviously.  Maximizing causes a repaint to happen and so right there you have some GDI leaks if things aren't released properly.  Under normal circumstances, this probably isn't an issue, but in some cases it can be.  It's not really any more or less important than originally pointed out.

Valik,

If you look a the whole code GetDc/ReleaseDC perfectly match. even the one of Larry which need 2 ReleaseDC.

Does other functions return hDC that should be released?

[Valik]

Then it might be something else. I don't know what all constitues classification as a "GDI object".

[jpm]

Then it might be something else.  I don't know what all constitues classification as a "GDI object".

Can the problem come from the

LRESULT AutoIt_App::GUIWndProcHandler (HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
{
    switch (iMsg)
    {
  case WM_CTLCOLORSTATIC:
     return (LONG) CreateSolidBrush(
    g_oGUI.SetColor((HDC) wParam, (HWND) lParam));

That's creating a brush for each label.

[Valik]

Yes, that might be it. I think you might need to call DeleteObject on a brush that's been created. So, make that brush static in the function so that it will only be created once, then in WM_DESTROY or something, try calling DestroyObject on it.

The same thing needs to be done for anything else that you constantly re-use. Don't just create new instances of it, use a static variable (Or create a class member if you want to take care of it in in the destructor). This might show a performance increase, too, as it won't be creating objects every time it blinks.

Edit: These are all objects of type HGDIOBJ which DeleteObject can free, might want to have a look and make sure any of the other's you may be using (font?) are properly freeing, too:

The DeleteObject function deletes a logical pen, brush, font, bitmap, region, or palette, freeing all system resources associated with the object. After the object is deleted, the specified handle is no longer valid.

Edited April 15, 2004 by Valik