Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 82
Текст из файла (страница 82)
Traditionally, no memory is set aside for the drawn content ofthe window, which is why the window server has to ask the applicationto redraw when a region is invalid. (An exception to this is redraw storing,described in Chapter 17.)However, in some cases it is impractical for the application to redrawthe window, for instance if it is:• a program that is not structured for event handling and so cannotredraw• a program that is not structured in an MVC manner (see Chapter 17),has no model, and so cannot redraw, even if it can handle events• a program that takes so long to redraw that it’s desirable to avoidredraws if at all possible.A program in an old-style interpreted language, such as OPL, is likelyto suffer from all of these problems.In these cases, you can ask the window server to create a backedup window of class RBackedUpWindow.
The window server createsa backup bitmap for each such window, and uses application-initiateddrawing to update the bitmap as well as to draw to the screen. Theadvantage of this type of window is that the window server can handleredraws by drawing from the bitmap, without having to send a redrawevent to the application.452CONTROLSA control that uses a backed-up window should create it by usingCreateBackedUpWindowL() rather than CreateWindowL(), andaccess it via BackedUpWindow() rather than Window(). Both windowclasses are derived from RDrawableWindow, so if you are not surewhich type of window the control owns, you should access the windowvia DrawableWindow().An obvious disadvantage is that a backed-up window uses much morememory than a standard window, and memory is a scarce resource onmobile phones.
If there is insufficient memory for a control to create abacked-up window, this will usually have severe consequences for thewhole application. It follows that you should only make the decision touse a backed-up window if there is no realistic alternative.Code designed for drawing to backed-up windows usually doesn’twork with standard windows, because standard windows require redraws,which code written for a backed-up window won’t be able to handle.On the other hand, code that is good for writing to a standard window isusually good for writing to a backed-up window: although the backed-upwindow won’t call for redraws, there’s no difference to the applicationinitiated draw code.
The only technique that won’t work for backed-upwindows is to invalidate a window region in the hope of receiving a laterredraw.Standard controls are lodger controls that are designed to work instandard windows. Such controls will, in general, also work properly inbacked-up windows. All Uikon stock controls, for example, are designedto work in windows of both types.On a standard window, CCoeControl’s DrawDeferred() functionworks by invalidating the window region corresponding to the control,causing a later redraw event. This won’t work on a backed-up window,so in that case DrawDeferred() simply calls DrawNow():void CCoeControl::DrawDeferred() const{...if(IsBackedUp())DrawNow();elseWindow().Invalidate(Rect());...}DrawNow() itself is, of course, coded to behave correctly for a controlassociated with a backed-up window.15.8Backed-up-Behind WindowsBacked-up-behind windows provide an optimization that is particularlyuseful for controls that are displayed for only a short time, such as menuBACKED-UP-BEHIND WINDOWS453panes, pop-ups and dialogs.
As with backed-up windows, the windowserver creates a bitmap, but the image that it contains is of the area behindthe window, not the content of the window itself. When the backed-upbehind window disappears, the window server can use the bitmap torestore the underlying image, without needing to generate redraw events.A backed-up-behind window is not a separate window class. Either anRWindow or an RBackedUpWindow may be converted to a backed-upbehind window by calling the window’s EnableBackup() function.This function is declared in the class definition of RDrawableWindow,in w32std.h, as follows:IMPORT_C void EnableBackup(TUint aBackupType=EWindowBackupAreaBehind);There are two values associated with the TUint parameter:• EWindowBackupAreaBehind creates a backed-up-behind bitmapto store the image for just the area behind the window• EWindowBackupFullScreen creates a backed-up-behind bitmapfor the whole underlying screen image.The first of these is frequently used for an overlying window that can bemoved around the screen.
As the window moves, the exposed underlyingarea is restored from the bitmap, and the bitmap content is updated tothe image behind the window’s new position.The second value is typically used in cases where the underlying screenimage is faded – that is, drawn in a less bright range of colors – when theoverlying window appears. In this case, the bitmap stores the unfadedimage.A window-owning control may set its window to be one of these twotypes, for example:DrawableWindow()->EnableBackup(EWindowBackupAreaBehind);Alternatively, it may set its window to own both types of bitmapsimultaneously, as follows:DrawableWindow()->EnableBackup(EWindowBackupAreaBehind |EWindowBackupFullScreen) ;This option is useful if you need to display a moveable window on afaded background.
In this case, the full screen bitmap stores the unfadedimage, but the bitmap of the area behind the window stores the fadedimage.The bitmap is created at the time the window becomes visible, notwhen the call to EnableBackup() is made. When backing up the454CONTROLSwhole screen, you need to call EnableBackup() before the windowis activated, and before you fade the background by calling RWindowBase::FadeBehind().Backed-up-behind windows are supported for purposes of optimization, and any call to EnableBackup() is not guaranteed to result in thecreation of the requested bitmap. It may, for example, fail if there is insufficient memory available to create the necessary backup bitmap. Unlikein the case of an RBackedUpWindow, such a failure is not catastrophicfor the application; the only consequence is that the application will besent redraw events that would not otherwise have been received.In addition, the usage of such windows is subject to a number oflimitations, designed to minimize the amount of memory consumed.• A window isn’t given the backup when it requests it, but only when itbecomes visible – and it will only keep the backup for the period thatit is visible.
A window that is repeatedly made visible and invisiblemay receive and lose the backup many times.• An application may own only one window of each type at any onetime. The application may therefore have a maximum of two backedup-behind windows, one of each type, or it may have one windowset to own both types of bitmap, as described earlier.• If a window-owning control requests a backup of type EWindowBackupAreaBehind, any window that has already claimed a backupof this type will lose it, even if that window is in another application.• If a window-owning control requests a backup of type EWindowBackupFullScreen, this request will fail if another window hasalready claimed a backup of this type, even if that window is inanother application.15.9Dimmed and Invisible ControlsThe control framework provides support for dimming controls or makingthem invisible, as a means of indicating the controls with which the useris or is not allowed to interact.A control is set to be visible or invisible by calling MakeVisible(ETrue) or MakeVisible(EFalse), and its visibility is tested bycalling IsVisible().
By default, a control’s components do not inheritthe containing control’s visibility, but this behavior can be changedby calling the container’s SetComponentsToInheritVisibility()function, which also takes an ETrue or EFalse parameter. The effectof this call only extends to the immediate component controls, so thisfunction must also be called on any components which are themselvescompound controls.SUMMARY455A control’s Draw() function is only called while the control is visible.A compound control must take the responsibility for drawing any areathat is occupied by any invisible component control.A dimmed control is conventionally displayed in a subdued paletteof colors. Dimming can be added by calling SetDimmed(ETrue),removed by calling SetDimmed(EFalse), and checked by callingIsDimmed().
A control should be dimmed if you want to indicate thatit is temporarily unavailable, but still want the user to be able to see itscontent.There is no explicit support for displaying a dimmed control. Thecontrol’s Draw() function is responsible for testing, by means ofIsDimmed(), the state of the control and then drawing the contentin the appropriate colors. The standard way of dimming a control variesfrom UI to UI, so you need to follow the examples and style guidelinesprovided in the appropriate SDK. However, the CWindowGC class provides the following two functions that may be useful when you need todraw in a dimmed state:void SetFaded(TBool aFaded);void SetFadingParameters(TUint8 aBlackMap, TUint8 aWhiteMap);The first function instructs the window server to map all the colors ituses for drawing to a less colorful range, so other windows can standout. For example, a window is less colorful when a dialog is displayedin front of it.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
