Why would you want to call BOTH Invalidate() and Update() when redrawing a control What does one do that the other doesn't that would justify calling them both
Repainting Controls
Hot Topic
- How to detect the mouse event in form
- Storing value from my ComboBox hosted in cell in DataGridView
- Designers and Abstract Classes
- using User Interface Process Application Block ??
- setting a tooltip for each row of a listbox
- HTML textbox
- On Application End (User Initiated)
- Multiple filters for a bindingsource. Possible? Or alternative?
- Store/load form settings with a generic Settings class?
- two-button custom cell
Windows Forms
- Transparent Panel Headaches
- Transfering files over internet using Windows Form
- No touch deployment - offline question.
- SetUp Project
- Datagrid ColumnStyle MappingName To SubClass of A Collection?
- Can I change how Publish.html looks like?
- Binding a Combo and adding an empty item...
- How to implement copy, paste, undo, redo?
- Overriding the users Regional and Language options
- Multiple tables data in dataGrid
Repainting Controls
FrankDip
Update() will cause the control to paint all of it's invalidated areas (again, set by Invalidate()). What is important about this method is it blocks until it returns. This is different from Invalidate() because after you call Invalidate(), control continues executing normally.
The reason you might see this is when acontrol designer decides that the control must be painted, he (or she) will this.Invalidate() the area that needs to be redrawn. Lets say, in this example, he wants to do some additional processing after the drawing has been completed. If the control designer says this.Update() right after the call to this.Invalidate(), he is ensuring that the control is in the "correct" state (meaing, all painting is done) after this.Update() returns. This cannot be a guarantee after a call to this.Invalidate()
In fact, a tough lesson I had to learn when designing a custom control not to long ago! I would set a variable that effected how the control painted itself AFTER a call to this.Invalidate(). My thinking was "Hey, after this.Invalidate() returns, it is safe to change the value of my variable because all painting must have been done". Sadly, I was mistaken. What was happening was I would invalidate an area, which would post a WM_PAINT message, but that message wasn't processed until after my function returned. By that time, I had already updated this variable with the NEW version when the WM_PAINT message was finally processed. During processing, it would use the NEW value of my variable when I had intended it to use the OLD value of my variable.
Hopefully, my explanation can save you a little aggrevation.