How to +- Multiple screens

How to create +multiple screens

Configuration

The +first screen is indexed as zero and the nth screen is indexed as n-1. The +changes below should be made to the wsini.ini file which +resides under \epoc32\data\z\system\data.

[screen 0] +[screen 1] +[screen n-1]

Building +the ROM image

The secondary screen is supported through TV-OUT +on H4 board. The H4 base port only supports landscape mode with 16 bpp resolution. +The ROM image must be built with -DWITH_TVOUT as a parameter.

Example Code

Setup example code

The +following code is the basis for the examples that follow.

This is a wsini.ini file +used to create two fixed screens:

AUTOCLEAR 1 +STARTUP \SYS\BIN\Start +WINDOWMODE COLOR64K +KEYCLICKPLUGIN KeyClickRef +TRANSPARENCY +MULTIFOCUSPOLICY +[screen 0] +[screen 1]

This is a class CTRedControl, which +draws a rectangle on the second screen:

const TInt KSndScreenNo = 1; + +class CTRedControl : public CCoeControl + { +public: + CTRedControl(){}; + ~CTRedControl(){}; + void ConstructL(RWindowGroup* aWinGp); + +private: // From CCoeControl + void Draw(const TRect& aRect) const; + }; + +void CTRedControl::ConstructL(RWindowGroup* aWinGp) + { + CreateWindowL(aWinGp); + SetExtent(TPoint(20,20),TSize(100,100)); + SetFocus(ETrue); + ActivateL(); + } + +void CTRedControl::Draw(const TRect& aRect) const + { + CWindowGc& gc=SystemGc(); + if (IsFocused()) + { + gc.SetPenColor(KRgbRed); + } + + gc.DrawRect(aRect); + }

Windows +on multiple screens

Using the above example code as a basis, the +following methods can be used to facilitate access to multiple screens:

Class RWsSession provides +the interface to query WSERV about window groups on a particular screen and +the number of screens in the system. The application calls the function below +to get the number of screens supported on the phone:

iCoeEnv->WsSession().NumberOfScreens();

The class CWsScreenDevice provides the interface to +query the physical limitations of the screen and set the parameters of the +corresponding logical screen. The class RWindowGroup is the +client side handle to the server side window group. A pair of screen device +and window group is required to draw on a screen.

CONE maintains an +array of screen devices and window groups. The screen number is used to index +this array to retrieve a particular window group and its corresponding screen +device.

The application calls ScreenDevice() to get +the second screen device:

iCoeEnv->ScreenDevice(KSndScreenNo);

The +application calls RootWin() to get the window group on the +second screen:

iCoeEnv->RootWin(KSndScreenNo);

The +application calls NumWindowGroups( ) to +get the number of window groups with EAllPriorities on the +second screen:

iCoeEnv->WsSession().NumWindowGroups(KSndScreenNo,EAllPriorities);

The application creates a new list and then populates it with WindowGroupList() to +get the list of window groups with EAllPriorities on the +second screen:

CArrayFixFlat<TInt>* list = new(ELeave) CArrayFixFlat<TInt>(1); +iCoeEnv->WsSession().WindowGroupList(list,KSndScreenNo,EAllPriorities);

The +application calls GetFocusWindowGroup() to get the window +group that has the keyboard focus on the second screen:

iCoeEnv->WsSession().GetFocusWindowGroup(KSndScreenNo);

Each screen has a default owning window group. The application calls GetDefaultOwningWindow() to +get the default owning window group on the second screen:

iCoeEnv ->WsSession().GetDefaultOwningWindow(KSndScreenNo);

The application calls GetDefModeMaxNumColors() to get +the maximum colour and display mode supported on the second screen:

TInt colour, grey; +iCoeEnv->WsSession().GetDefModeMaxNumColors(KSndScreenNo,colour,grey);

The +application calls GetColorModeList() to get the list of colour +modes supported on the second screen:

CArrayFixFlat<TInt>* list = new(Eleave) CArrayFixFlat<TInt>(1); +iCoeEnv ->WsSession().GetColorModeList(KSndScreenNo, list);

Creating a control on a +particular screen

A window group is associated with a screen device, +which in turn is associated to a screen. A control is associated with a window +group. Therefore a control is constructed on the second screen using the function +below, in the control’s ConstructL():

CTRedControl redControl=new(Eleave) CTRedControl(); +redControl->ConstructL(CCoeEnv::Static()->RootWin(KSndScreenNo));

Graphics Context

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. The function call +below is used to find the screen device on which the graphics context was +last activated.

CCoeEnv::Static()->SystemGc().Device();

Window Group Focus Policy

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

Limitations

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.

Cone-Based UI

Due +to limitations in the legacy implementation of Cone and the control sets implemented +on top of it (for example, Eikon, Avkon or Qikon), it is nearly impossible +to make the same application draw Cone-based UI on two different screens at +the same time. However, a secondary screen can be used to draw non-Cone-based +graphics (for example, a picture or PowerPoint slide-show, or a UI not using +Cone for its widgets). If it must appear as if an application supports displaying +itself on the secondary screen, then this can be done by moving that UI into +a second application instance. This second instance could be a server application +that only acts as a slave UI of the main application. In any case, that secondary +application instance would have to set the secondary screen as its default +screen. There are two main problems:

All controls have to +be associated with a window, and window owning controls do not currently try +to make sure that the window they create is associated with the screen that +they should appear on. This means, for example, that a pop-out window created +by a choice list widget will always appear on the application's primary screen, +rather than on the screen on which the choice list itself is located.
None of the legacy +widget implementations referencing the screen device take into consideration +that there might be more than one screen on the device. These include CCoeControl's SetExtentToWholeScreen(), SetCornerAndSize(), AccumulatedZoom(), PositionRelativeToScreen(), +and CEikAppUi's ClientRect() and ApplicationRect()).

Neither of these problems can be solved currently.