C# drawing disappears (actually more system question)

Question

Hi, OK, I am sure some of you already know whats happening just by my title, since I get this is very common question. But my question is in fact little deeper, so please be patient wíth me.

All my programing I have done in past years were in Assembler, mainly 8051 and AVR as weel as in C, but also for microcontrollers. I was more fascinated by HW than SW. But I am also fascinated with function of OS, its APIs and so on. Few days later I told my friend that to create a very simple program to plot a function graph should be very easy, if you had math parser. He doesent believed me so I tried to make one.

I decided to go with C#, even I have no knowledge of OOP. But I thought that if I get everything done in one buttons action it would be like good old C.

So I get math parser to work, and than started to draw using Pen object. My first attempt was to draw simple line. After reading one tutorial a managed to do so, and I created simple axis for my plot.

But than I noticed something strange, when I minimalised my program, drawing dissapears. This made me think a bit about how this all drawing is done on system level.

I thought that system hold image of active window untill its changed. So when you move your windows it just changes its position in famebuffer. And when you minimase it, it just skips it during drawind to framebuffer.

But I saw its not like this. So, please, could you tell me why is this happening? I can read how to prevent it in many tutorials, but I would want to know more why. More, wheather this is becouse of how system API works, or becouse how C# drawing class works.

Also, this made me think what in C# and .NET libraries is function thats just a call for WinAPI function that works exactly the same way, and how many libraries and function do something more. Like if there was no function to draw line in GDI, and you could only draw dot, than C# would add function to draw line from this dots. I hope you understand me.

Thank you.

Answer 1

If you want to plot, use microsoft chart controls. http://www.microsoft.com/downloads/en/details.aspx?FamilyId=130F7986-BF49-4FE5-9CA8-910AE6EA442C&displaylang=en

or ZedGraph http://zedgraph.org/

If you want to plot yourself: The window is redrawn when you resize.
You need to redraw your plot on the redraw event, or whatever it is called.
That is perfectly normal.

Also, use .NET 4.0, because else, you have no possibility of removing anything you drawed programatically, unless you remove (repaint) everything.

Answer 2

This is how it works in the Win32 API. When the window is minimized, the area which it occupied gets "invalidated" so the windows system knows that this area of the screen needs to be redrawn. This leads to a WM_PAINT message being sent to the windows program(s) responsible of drawing that area. You can read more about invalidating the client area (the area of which your program is responsible) here.

If you're truly interested in this stuff and want to get deeper understanding on how the system handles drawing (and other things, like windows messages), I recommend reading more on the Win32 API, e.g. beginning on Charles Petzold's classic, Programming Windows.

Answer 3

In Windows (prior to Vista / DWM and MIL) the application is responsible for drawing its own GUI. That is, the application has to paint its own GUI When the operating system tells the application to do so. Resizing or moving a form will trigger the paint event. This is how it works in User32+GDI. That is, the application draws its own pixels.

A WPF application will however use the Media Integration Layer (Vista and Windows 7) and the "mil core" is responsible for drawing the visual tree of the application. In this case the operating system is responsible for the rendering, but the application is responsbile for what it wants to be rendered.

Answer 4

Your drawing didn't disappear, it simply isn't there. Bare with me:

• to draw on the windows window, you have to respond to the callback indicated by the WM_PAINT message. It was in Win 3.11 and it is so NOW.
• to draw on button click is a waste of time, because next form/control/window repainting will draw background color there
• move the same code from button event handler to OnPaint - of course, handle the differences in semantics
• windows don't save the copy of your screen buffer - your drawing - so you have to save it somewhere or draw it on-the-fly