Screen deteriorating....

[gummibaer]

Hi,

while running my program (using win32API and OpenGL) after some time the screen begins to deteriorate: Objects are drawn to wrong places, wrong colors used, objects missing and such).

I know that this can be triggered by not properly deleting device contexts after using them and the system eventually messes them up. At least the effect on my screen looks pretty much like it as I know from prior experiance.

So I checked on the usual suspects - which are quite numerous in my prog of 40,000 lines up to now - but without any real success. My question now is, if such a messing up of my display could be caused by other effects ?

I am still quite new at windows programming and for all the pain I took on clean programming there still might be some problem hidden in my code. Do GDI-objects, if forgotten to delete and created again and again yield the same problem ? Passing processed messages to DefWindowProc ? Any other issues like this ?

Just looking for input on where to search.
Thanks in advance

Norbert

[Igor Vartanov]

Do GDI-objects, if forgotten to delete and created again and again yield the same problem ?

Never. To draw to wrong places with wrong colors your objects must be corrupted in memory.

Passing processed messages to DefWindowProc ?

Again, never. If that would be the case, your program had to fail immediately.

[gummibaer]

Thanks Igor.

I think I found it. In some procedures I did write

EndPaint (hDC, tPS)

instead of

EndPaint (hWnd, tPS).

which left the device context undeleted apparently. This function seems the only one that you use in painting that carries the window handle as argument rather than the device context.

After I corrected this, my prog shows more endurance in keeping its screen, in fact my problem did not occur again as yet, but I will have to see the result for longer operation.

I wonder why the rectangles got validated with the wrong handle passed to EndPaint though, but it did work.

Norbert

[12oclocker]

One thing to also check for is GDI object leaks, many people check for mem leaks, but if your leak GDI it is just as bad, and can cause the problem you are describing as well. Process Explorer from SysInternals can track GDI Handles, I use it for checking GDI leaks.

[MikeAThon]

...I think I found it. In some procedures I did write

EndPaint (hDC, tPS) ...

Your program would not have compiled if you wrote EndPaint (hDC, tPS).

There perhaps is more to this story than you are telling us. Did you cast the hDC to an (HWND) in order to get the program to compile? If so, are there any other casts that you inserted in order to get your program to compile? Such casts are sometimes a clue signalling an incorrect program.

[MikeAThon]

One thing to also check for is GDI object leaks, many people check for mem leaks, but if your leak GDI it is just as bad, and can cause the problem you are describing as well. Process Explorer from SysInternals can track GDI Handles, I use it for checking GDI leaks.

In addition to SysInternals (which is very good), ordinary TaskManager can be configured to display columns for GDI objects and for USER objects.

Mike

[gummibaer]

Sorry for the delay in answering:

MikeAthon:
I did not mention that this is FORTRAN code not C or C++. Type declarations are very different there and you use interfaces to call the corresponding C-routines of the Windows API. I use Fortran because I am working on a numbercruncher that should offer some comfortable user surface and I am useing this forum as there is no living forum for Fortran and Windows Api that I know about.

12oClocker
That is what I was wondering about, if undeleted GDI-objects would cause problems like I did encounter. Igor said no. (which limited my search considerably). Do you have any other experience ?

Norbert