Chapter 1

� an old-style program that's not structured in an MVC manner, has no model, and so
can't redraw, even if it can handle events;
� a program that takes so long to redraw that it's desirable to avoid redraws if at all
possible.
A program in an old-style interpreted language such as OPL is likely to suffer from all these
problems.
In these cases, you can ask the window server to create a backed-up window; the window
server creates a backup bitmap for the window and handles redraws from the backup bitmap
without sending a redraw event to the client application.
The backup bitmap consumes more RAM than the object required to represent a standard
window. If the system is running short on memory, it's more likely that creation of a backedup
window will fail, rather than creation of a standard window. If it does fail, the application
will also fail, because requiring a backed-up window is a fairly fundamental property of a
control. If you need backup, then you need it. If you can code proper redraw logic of
sufficient performance, then you don't need backup.
Code that is designed for drawing to backed-up windows usually won't work with standard
windows because standard windows require redraws, which code written for a backup
window won't be able to handle.
On the other hand, code that is good for writing to a standard window is usually good for
writing to a backed-up window; although the backed-up window won't call for redraws,
there's no difference to the application- initiated draw code. The only technique that won't
work for backed-up windows is to invalidate a window region in the hope of fielding a later
redraw event – but this is a bad technique anyway.
Standard controls such as the controls Uikon offers to application programmers are usually
lodger controls that are designed to work in standard windows. Such lodger controls will also
work properly in backed-up windows, unless they use invalidation in the hope of fielding a
later redraw. All Uikon stock controls are designed to work in both windows.
CCoeControl's DrawDeferred() function works on a standard window by invalidating the
window region corresponding to the control. This causes a later redraw event. On a backedup
window, this won't work, so in that case DrawDeferred() simply calls DrawNow():
void CCoeControl::DrawDeferred() const
{
...
if(IsBackedUp())
else
...
}
DrawNow();
Window().Invalidate(Rect());
11.6 CCoeControl's Support for Drawing
Now is a good time to summarize the drawing-related features of CCoeControl that we've
seen so far.