Sometimes you need a console window for debugging, sometimes you need the debugger, and sometimes you need both.
Agreed. Here code uses low-level Microsoft Windows calls, which can be quite difficult to manipulate correctly. I donāt suggest switching to GTK or anything āhigher-levelā as that would mean re-writing the whole application, but for future projects I would strongly recommand it.
Also, why are there DEC preprocessor instructions in the DN_DiagrammWndProc function ? Has this code ran on OpenVMS at some point ?
Good catch.
I wonder if all calls to EndPaint have been failing. The EndPaint documentation page Iāve seen says:
āThe return value is always nonzero.ā
so itās not clear if thereās any way to tell if EndPaint succeeded or not.
Probably. Each call to BeginPaint has created an additional context, until something was saturated (a counter? a memory zone?..) after more than 1200 cycles.
Wow. thanks a lot. This is what went wrong. I do not know how I could fail to spot this glitch. Thank you all.
Strange that this did not show in an increase of memory usage.
My next beer is to your health and all the others.
Norbert
3 Likes
Prosit Norbert! 
If the library was open source, we could look the internals of contexts and understand more deeply the problem.
Looking for the error āInvalid device context (DC) handleā, I have found another post with a similar problem:
1 Like