Known issues

This section provides a list of known issues with the S60 5th Edition SDK.

CMdaAudioConvertUtility not supported

CMdaAudioConvertUtility, which is part of the Symbian's Media Client Audio API, is not supported since S60 2nd Edition SDK for Symbian OS, Supporting Feature Pack 1. When used, this API does report KErrNotSupported error code.

Highlight animations

Making highlight animations work

ColumnListBox, FormattedCellListBox, OptionsMenu and Form (in view mode) have highlight animations. Highlight animations are started only when these controls are given focus and stopped when these controls lose focus. OptionsMenu and Form are handled by the framework. Lists require more attention as they are often wrapped inside container controls. Equally often these containers will not hand focus events to contained lists. Note that simply setting the control focus to true once is not enough, you must adjust the focus dynamically. The following code should work in most cases:

void CSomeContainer::FocusChanged(TDrawNow aDrawNow)

    {

    SuperClass::FocusChanged( aDrawNow );

    if( iListBox )

        {

        iListBox->SetFocus( IsFocused(), aDrawNow );

        }

    }

Verifying that highlight animation is working:

(a) Opening and closing options menu should stop and start animations.

(b) Opening fastswap should stop and start animations.

(c) Change skins to see that resource handling chain has not been broken. Calling SuperClass::HandleResourceChange should be enough as eventually CCoeControl::HandleResourceChange will make sure child controls receive the notification as well.

In some cases making focus events work will be hard:

  • Make sure to remove focus from control that becomes invisible (for example, when switching between two different lists programmatically).

  • If a control sits on top of a control stack with high priority it will eat all focus events. In this case, consider adding a dummy control to the top of the stack which simply intercepts focus events and lets all key input fall through.

  • A misconfigured control context can cause visually broken animation. Always initialize control context with proper values. Creating a control context at an earlier phase can also help.

  • Add dialogs to a control stack with correct priority (ECoeStackPriorityDialog). Adding to a control stack without providing priority explicitly, will use the default value, which is ECoeStackPriorityDefault. The default priority is too low for dialogs.

  • In some dialog cases, increasing/decreasing factory menu priority and keeping just one dialog in the control stack might help.

Notice, that highlight animation can be defined to have finite duration. That is, an animation can stop after it has been running for a defined time. In these cases the animation can be restarted by visiting fastswap, which causes the application to lose and gain foreground.

Disabling highlight animations

You can disable a highlight animation in an application by passing the EAknDisableHighlightAnimation flag to CAknAppUiBase::BaseConstructL. The flag is available to classes deriving from CAknAppUiBase (e.g. CAknAppUi). Example:

void CSomeAppUi::ConstructL()

    {

    // Enable skinning but disable highlight animation

    BaseConstructL( EAknEnableSkin | EAknDisableHighlightAnimation );

    ...

    }

Alternatively, you can access the enable/disable functions in AknsUtils directly. Applications that disable highlight animation use normal skinned highlights. Notice, that embedded applications may still have highlight animation enabled.

Derived list data implementations

If your custom list implementation has subclassed either CColumnListBoxData or CFormattedCellListBoxData and has overridden their drawing functions to customize list drawing, you must disable highlight animation in those lists.

Currently access to highlight animation implementation is not available to 3rd parties. In these cases the derived data classes must be constructed by passing KAknsIIDNone to ConstructLD, which disables highlight animation and uses normal skinned highlight drawing. See CColumnListBoxData::ConstructLD and CFormattedCellListBoxData::ConstructLD.

New stack size

With Symbian OS v9, the default stack size was reduced from 20 kB to 8 kB to optimize memory consumption because platform security caused an increase in the number of running processes in the system.

In practice, the 8 kB stack has proven to be quite small for any larger S60 application. Even if the stack size were sufficient when the application is run on current devices, there is an increased risk of crashes due to stack overflow in future S60 3rd Edition devices as new features can cause a slight increase in stack consumption of the platform libraries. Thus, using a too small size for the stack endangers also binary compatibility.

Increasing the stack size to 20 kB is recommended for all applications written with the S60 3rd Edition SDK.

Applications need to be recompiled in order to modify the stack size.

Solution:

Stack sizes other than the default 8 kB can be configured with the epocstacksize statement in the .mmp project definition file:

epocstacksize stacksize

The size of the stack, in bytes, can be specified in decimal or hexadecimal format. Using this statement will have no effect under the WINSCW/WINS platforms.

For example, adding the following line to the .mmp file will increase the stack size to 20 kB:

epocstacksize 0x5000

Alternatively, stack size can be defined for a new thread when creating the thread.

Example:

TARGET      mce.exe

EPOCSTACKSIZE 0x5000

TARGETTYPE  exe

UID         0x0 0x100058C

...
© Nokia 2009.