FAQ-0690 What are redraws for?


FAQ-0690 What are redraws for?

» Symbian OS » Developer Knowledgebase » FAQ-0690

Classification:	C++	Category:	Window Server
Created:	12/15/2000	Modified:	04/09/2002
Number:	FAQ-0690
Platform:	ER5, Symbian OS v6.0, Symbian OS v6.1

Question:
I want to make some other application updates it's content. How can I get it to do a redraw?

Answer:
Getting it to do a redraw is the wrong thing. This is an abuse of what redraws are for. Redraws are to tell an application to draw (again) the current content of that window and not to get them to draw new updated content. Examples of situations where you have a redraw are:
1. A window that was obscured by another window is moved in front of that window or that window is deleted.
2. A window that was partially off the screen is dragged back on to the screen.

Examples of when you want a draw:
1. Your window is showing the current entries in your agenda for a particular day. Somehow another entry for that day is created and you need to change the content of your window to show this entry as well.
2. Your program to calculate successive terms in the decimal expansion of PI has just calculated another one. You want your window that is showing the currently calculated values to show this one as well.

Another way to think of this difference is to think of backup content windows. A backup content window is one where WSERV keeps a bitmap copy of the whole of the display of a window. When that window needs a redraw WSERV will do it automatically using its bitmap copy. But when that window needs a draw then the window and the bitmap both need updating.

In practice programs are often written so that the drawing for a redraw and draw are done by the same function. If a programmer wants to write his program like that then this is fine, but it is wrong to assume that some other programmer has written their program like that. The fact that the control framework is set up so that drawing and redrawing are done by the same function is not an excuse to assume that forcing an app to redraw will correctly update its content.

Let's look at an example of how things can go wrong in programs that do redraw and draws in the same function. Suppose that you have a window where you are displaying text that is changing periodically. When the content changes you set a timer going and only display the updated text when the timer goes off (this may be a bit of an artificial situation, but a bug where a draw is not done will give rise to the same effect). Before the timer goes off, a redraw happens and this only causes you to draw part of your window. While redrawing WSERV clips the drawing to the area that needs the redraw. Thus you will have the new content in the part of the window that has been redrawn and the old content in the rest of the window. In extreme cases this can give rise to the following:

where the top of a line of text says one thing and the bottom half says another.

Ways to avoid this problem:

1. Always (with absolutely no chance of there being a bug which misses one case) do draws, as soon as the content has changed.
2. Always invalidate the area that has had its content changed, as soon as it has had its content changed.
3. Make your draw/redraw routine always have an idea of what data is being displayed by the window as opposed to the latest values of this data. (For the PI program this would mean that you know you have only displayed the first 10 dp. while you have actually calculated the first 15dp.)
4. One way to do 3. is to use a backup content window.