Can you believe the MessageBox can show even when the program stopped and the project returned to the design mode after clicking on "Stop debugging"?
I couldn't believe that until I tried inserting a command executing MessageBox.Show(...) into the body of the method Paint(...).
That's for I want to know when this method is called. I realized that it will be called whenever the DataGridView is redrawn, even when the project in design mode.
Could you please explain me how it works? As far as I know, the method will be called directly or indirectly when some event occurs. But I don't see any events associating with that method in the properties window, and even when there's one event for it (for example Paint event) how can it be called when all debugging or compiling or running stopped? Yes, if you do like me, you can't continue designing and coding your project because whenever the main form containing the datagridview with that "playful" method called Paint is redrawn or repainted, it will show a message box, clicking on the OK button will repaint the datagridview anew and a new message box will appear, that makes a loop of calling Paint.
Is there any other method of the same kind to that Paint?
Thank you so much!
Putting a MsgBox in the Paint event handler is a HORRIBLE idea! When the messagebox is dismissed, guess what happens? The Paint event is probably going to fire again! Well, that is if the messagebox covered any part of the control/form your Paint handler code is servicing.
Replace it with Debug.WriteLine or something else so you can monitor it in the debugger without screwing up your painting code.
The code is never actually stopped. For example, when you create a custom control and it's being displayed in the designer, your controls code is actually RUNNING, even if you haven't started your app in the debugger. Think about it. How else is the designed going to show your control if it doesn't run the code behind it?
Dave is right, but you need some explanation.—SA
Yes, you need to understand it to write other programs.
The mechanism is not simple at all. First of all,
OnPaint is triggered in response of the Windows message
WM_PAINT. The triggering of this message is quite a complex thing. You can see that you method will be fired when any part of your window covered by any other window exposes part of the previously covered surface. So it happens on motion of some windows, on Alt+TAB, on refresh &many; cases.
Now, how to trigger it automatically? This is very important for any kind of animation. No, this is not
Refresh or anything. Ultimately, this is only one thing:
Control.Invalidate. You animate (or otherwise modify) the rendered picture by changing some instance data which is used by
OnPaint and the call
Invalidate. For better performance, you can use Invalidate with parameter: a
Region. Most powerfull thing is
Region: it supports all kind of set-theory operations to build any subset of the rendering rectangle.
Now, what's so special about
WM_PAINT? The processing of this event is very cunning. It does not go through a regular Windows message queue. Instead, it is higly optimized. Imagine you have two invalidates coming one after another, with second one called before your re-rendering (through
OnPaint) is not yet complete. Do you think
OnPaint is called twice? No way! The messages will be merged together in one in the optimization process, and there invalidated regions will be ORed together. Interesting mechanism, isn't it?
There are cases when this technique should be reproduces on application level. With
Invalidate you don't have to worry about it.
This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)