Multiple Screens Overview

Multiple screens allow an application to be displayed on more than one screen simultaneously, and also to react to a change in the active screen whilst the application is running. Prior to the implementation of this feature, applications could only display on one screen during its lifetime.

When an application creates a view it will be allowed to specify which screen that view will be displayed on. The view will be fixed to that screen, but the application can then create another view on a different screen. If the characteristics (for example, size or colour depth) of the screens are similar, the view on the second screen could just be a second instance of the original view.

Some typical uses for taking advantage of multiple screens could be:

• A clamshell device with a screen on the inside and one on the outside. The user is working on an application on one screen. The device is opened or closed and the application switches itself to the other screen.

• A clamshell device with two screens one on each side of the inside. An application shows part of its data on each screen.

• A phone application which displays itself on all screens when the user is not using them for other purposes.

The CONE component (which provides the control environment) has been extended to support multiple screens.iCoeEnv->ScreenDevice( screennumber) will return a pointer to the requested screen.

WSERV has also been extended to support multiple screens. Specifically, RWindowGroup::ConstructL() has been overloaded so that a screen device that is associated with a screen can be passed as a parameter during the construction of a window group.

The class RWsSession can be used to query WSERV about the window groups on a particular screen and the number of screens on the device.

The class CWsScreenDevice can be used to query the physical characteristics of the screen, and set the parameters of the corresponding logical screen associated with it.

The class RWindowGroup is the client side handle to the server side window group.

Both CWsScreenDevice and RWindowGroup are needed as a pair to draw on a screen.

The Cone component maintains the array of screen devices and window group pairs through its RWsSession::WsSession() method. The screen number is used to index this array in order to retrieve a particular window group and its corresponding screen device. This array can be queried in order to find out information such as:

• the window group with the current keyboard focus

• the window group with focus on a particular screen

• the maximum colour and display mode on a particular screen

• the list of colour modes for a particular screen

A control is associated with a window and a particular window group. A window group is associated with a screen device, which in turn is associated with a screen. To create a control on a particular screen, retrieve an appropriate window group on that screen and use it as the parameter in the control’s ConstructL(). The window for that control will then be created on that screen

The class CWindowGc provides the interface for the application’s window graphics context and can be activated on any window in the application. This means that it can be used on any screen on the phone

There are two focus policies supported by WSERV. The default focus policy is that it is only the focused window group on the focused screen that receives focus gained and focus lost events. The new policy is that any window group can receive focus gained and lost events and can be switched on by defining the keyword MULTIFOCUSPOLICY in the wsini.ini file.

Pointer Events

The first screen created is also the primary screen in the system. It is important to note that only the primary screen can respond to pointer events. This is due to the fact that the kernel supports only one screen digitiser.

For information about further limitations specifically related to the legacy nature of Cone, please see How To Multiple Screens.