# HG changeset patch # User Dominic Pinkman # Date 1279623649 -3600 # Node ID 48780e181b38fcdd8bcc5f683a9f51b2748a2c55 # Parent 80ef3a20677267274926b513266603a8729fb389 Week 28 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 1897 and Bug 1522. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/92_201008_S60.52_apidocsA_sf.zip Binary file Symbian3/SDK/Source/92_201008_S60.52_apidocsA_sf.zip has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-000ACB11-EDD0-5160-BC5E-4593F1BAF293.dita --- a/Symbian3/SDK/Source/GUID-000ACB11-EDD0-5160-BC5E-4593F1BAF293.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-000ACB11-EDD0-5160-BC5E-4593F1BAF293.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,7 +39,7 @@ to it is closed. The queue itself is simply a block of memory divided into slots, managed by the DMsgQueue object.

- +
Handle to a message queue

A message queue is created, opened, written to and @@ -50,7 +50,7 @@ the implementation, while RMsgQueue provides type safety. An RMsgQueueBase object is a valid message queue handle, but does not offer the type safety that RMsgQueue does.

- +

Message queues are used for one-way, one to one communications only. The message queue is therefore unicast. If there are multiple readers of the message queue only one will receive the message.

diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-006C503D-1E52-450D-A4DA-8C19B141E09F.dita --- a/Symbian3/SDK/Source/GUID-006C503D-1E52-450D-A4DA-8C19B141E09F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-006C503D-1E52-450D-A4DA-8C19B141E09F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ where C and C++ (and Symbian C++ as well) codes will be used together. The open source community implements a vast number of libraries that export C APIs to the user of such libraries. -
When +<section id="GUID-88635D46-AEF6-4E8E-969D-D3E56941F289-GENID-1-10-1-13-1-1-5-1-3-1-7-1-4-1-4-1-3-1"> <title>When and why to use C linkage

While porting such applications, if developers have to intermix C and C++ code, they then have to depend on C++ language features like extern "C" for giving C linkage to some set of @@ -32,7 +32,7 @@ It applies when the developer tries to use C APIs by including corresponding headers. To avoid name mangling, the developer should mention explicitly that those APIs are C APIs, by using the extern "C" keyword.

-
Syntax +<section id="GUID-88635D46-AEF6-4E8E-969D-D3E56941F289-GENID-1-10-1-13-1-1-5-1-3-1-7-1-4-1-4-1-3-2"> <title>Syntax of extern C

The syntax of extern "C" is shown below:

extern "C" declaration ;

The declaration (or definition) that immediately follows extern "C" has the C linkage.

extern "C" { @@ -41,7 +41,7 @@ ... }

Everything between the curly braces has C linkage, unless declared otherwise.

-
How +<section id="GUID-88635D46-AEF6-4E8E-969D-D3E56941F289-GENID-1-10-1-13-1-1-5-1-3-1-7-1-4-1-4-1-3-3"> <title>How to use extern C

While writing header files with C functions which will be included by both C and C++ source files, the user must use extern "C" properly. See the example below:

/*File: GoodCHeader.h */ @@ -83,7 +83,7 @@ int ret = Function2(10); }
-
Mixing +<section id="GUID-88635D46-AEF6-4E8E-969D-D3E56941F289-GENID-1-10-1-13-1-1-5-1-3-1-7-1-4-1-4-1-3-4"> <title>Mixing C and C++ features using extern "C"

The developer can use all the features of C++ except templates within C by giving those functions extern "C" linkage. See the example below:

#include <iostream> diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita --- a/Symbian3/SDK/Source/GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> What are LayersThis topic describes the concept of a Layer in the Communications Framework.

A Layer is a horizontal division of functionality in a stack.

A Layer matches the concept of the Layer in the seven-layer International Organization for Standardization's OSI Model. A Layer also matches the concept of the Layer in the five layer model used to describe TCP/IP.

A Layer can contain a single Communications Protocol. A Layer can also contain a number of related protocols collected into a single unit. TLS, TCP, IP, Ethernet are examples of the protocols.

The concept of a Layer allows device creators to have different implementations in a given Layer. When a data connection starts or when the environment changes, the best protocol can be selected.

The following diagram shows the concept. The diagram also shows the position of the Sockets Server Client APIs.

Layers in the Communications Framework -

Although each Layer contains a different protocol, the Communications Framework allows separate protocols to make a single Layer. For example: NCP, LCP and HDLC together make the PPP protocol. TCP, UDP, ICMP, IP together make the TCP/IP group of protocols. Each of these groups of protocols can be put together into a single Layer.

The number of Layers only depends on the configuration of the Communications Stack. The top Layer has the Sockets Server. The bottom Layer has the drivers for the communication hardware . Each Layer interacts only with the Layer immediately above and the Layer immediately below.

The framework APIs that connect the protocols in each Layer are consistent across the Communications Framework. All protocols share a common method of communication that is independent of protocol behaviour. A common method of communication allows protocols to be stacked. The Communications Framework provides flexibility in the configuration of the protocol stacks for each device. The following diagram shows a number of protocols at each Layer.

+

Although each Layer contains a different protocol, the Communications Framework allows separate protocols to make a single Layer. For example: NCP, LCP and HDLC together make the PPP protocol. TCP, UDP, ICMP, IP together make the TCP/IP group of protocols. Each of these groups of protocols can be put together into a single Layer.

The number of Layers only depends on the configuration of the Communications Stack. The top Layer has the Sockets Server. The bottom Layer has the drivers for the communication hardware . Each Layer interacts only with the Layer immediately above and the Layer immediately below.

The framework APIs that connect the protocols in each Layer are consistent across the Communications Framework. All protocols share a common method of communication that is independent of protocol behaviour. A common method of communication allows protocols to be stacked. The Communications Framework provides flexibility in the configuration of the protocol stacks for each device. The following diagram shows a number of protocols at each Layer.

Protocols arranged in Layers in the Communications Framework - Socket Server \ No newline at end of file + Socket Server \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0142B290-DA6C-5574-83D7-7555D804D9B5.dita --- a/Symbian3/SDK/Source/GUID-0142B290-DA6C-5574-83D7-7555D804D9B5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,75 +0,0 @@ - - - - - -How -to initialise array RESOURCE members -

<array-initialiser>

-

array-initialiser ::=

-

{ <array-initialiser-item-comma-list> } <array-initialiser-item>

-

array-initialiser-item ::=

-

<initialiser>

-

Fixed-length arrays

-

If a member is declared as a fixed-length array in the STRUCT or RESOURCE definition, -for example,

-WORD elements[10] -

then you must not specify any more items than were given in the length.

-

If fewer items are specified in the default initialisation (i.e. in the STRUCT definition), -then an error also results.

-

Note that no values will be given to unspecified elements at the end of -the array, even if they have been default initialised in the STRUCT definition. -Take the following example:

-STRUCT SAMPLE - { - BYTE bts[3]={1,2,3}; - } -

In the following resource:

-RESOURCE SAMPLE default - {} -

the output will be the whole default array

-0x01 0x02 0x03 -

but in this resource:

-RESOURCE SAMPLE first_specified - { - bts={5}; - } -

the output is:

-0x05 -

with the second and third elements lost.

-

If you specify only the second element in the RESOURCE definition, -then the first element is taken from the default initialisation, the second -from the explicit initialisation and the third element is lost. The following -resource:

-RESOURCE SAMPLE second_specified - { - bts[1]=5; - } -

results in the 2-byte output:

-0x01 0x05 -

If, however, you explicitly initialise an element in the middle of an array -without having supplied default values for array members before it, then an -error will result.

-
Using expressions to initialise array elements

You -may initialise array elements with expressions. You must explicitly initialise -each member component of the array otherwise the expressions will be evaluated -incorrectly. The following resource:

RESOURCE SAMPLE correct_expression - { - bts[0]=3+1; - bts[1]=2; - bts[2]=3; - }

will generate the correct output 0x04 0x02 0x03. -However, if you use the following syntax:

RESOURCE SAMPLE incorrect_expression - { - bts={3+1,2,3}; - }

the output will be 0x03 0x02 0x03. This -is because the pre-processor treats 3+1 as a literal string -that is then interpreted by the compiler as 3. In the resource correct_expression above -the ‘=‘ sign forces the pre-processor to evaluate the expression.

- \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-016704BE-DC2B-5AD3-B9BE-76A327678B38_d0e255924_href.jpg Binary file Symbian3/SDK/Source/GUID-016704BE-DC2B-5AD3-B9BE-76A327678B38_d0e255924_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-016704BE-DC2B-5AD3-B9BE-76A327678B38_d0e260809_href.jpg Binary file Symbian3/SDK/Source/GUID-016704BE-DC2B-5AD3-B9BE-76A327678B38_d0e260809_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0181F4BD-51A2-49AF-9DAC-517F8BAD8DBC_d0e52617_href.png Binary file Symbian3/SDK/Source/GUID-0181F4BD-51A2-49AF-9DAC-517F8BAD8DBC_d0e52617_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0181F4BD-51A2-49AF-9DAC-517F8BAD8DBC_d0e52760_href.png Binary file Symbian3/SDK/Source/GUID-0181F4BD-51A2-49AF-9DAC-517F8BAD8DBC_d0e52760_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0185D5DC-5142-42C3-8FFB-8EB76D49AB06.dita --- a/Symbian3/SDK/Source/GUID-0185D5DC-5142-42C3-8FFB-8EB76D49AB06.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0185D5DC-5142-42C3-8FFB-8EB76D49AB06.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,8 +21,8 @@ for the request to complete. This approach is not recommended in case of a server, as synchronous call blocks the server and it cannot serve its clients during synchronous wait.

- -Request free memory. + +Request free memory. User::LeaveIfError(iOomMonitorSession.RequestFreeMemory(KLargeValueToAllocate)); DoFunctionRequiring_KLargeValueToAllocate_Bytes(); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-018A685B-5C9D-5C7C-8615-D413ABBF7CFB_d0e242288_href.png Binary file Symbian3/SDK/Source/GUID-018A685B-5C9D-5C7C-8615-D413ABBF7CFB_d0e242288_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-018A685B-5C9D-5C7C-8615-D413ABBF7CFB_d0e247247_href.png Binary file Symbian3/SDK/Source/GUID-018A685B-5C9D-5C7C-8615-D413ABBF7CFB_d0e247247_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-01943C50-E3AB-5D5B-BC3D-B399C6BFD155.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-01943C50-E3AB-5D5B-BC3D-B399C6BFD155.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Secure Sockets ArchitectureThis section describes the architectural relationships of the Secure Sockets.
Architectural relationships

The Secure sockets architecture provides a client interface and a server. Protocol modules are plugged into the client. The client uses protocol modules to supply protocol-specific parameters to the Secure Socket API functions.

The ssl.dll plug-in supports the Transport Layer Security (TLS) v1.0 and Secure Sockets Layer (SSL) v3.0. The protocols use the socket methods to pass data between a client and a server. This method prevents the security violations.

The following diagram shows the relationship between an application and the secure sockets.

See also

Sockets Server

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-01979029-C009-5FD3-9925-2B7945FB96A6.dita --- a/Symbian3/SDK/Source/GUID-01979029-C009-5FD3-9925-2B7945FB96A6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-01979029-C009-5FD3-9925-2B7945FB96A6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Restarting a Network Connection TutorialThis section describes the steps used to start a network connection that was stopped due to contention.
Introduction

A low priority connection is terminated when a contention issue occurs and the incoming connection has a higher priority. The low priority connection can be restarted when the higher priority connection is complete. For example, if an always-on Internet connection is terminated to enable the user to send an MMS, the Internet connection is restarted when the message is sent.

Introduction

  1. To terminate the high priority connection on of the following occurs:

    1. The Connection Provider (CPR) receives a TStopNormal message to terminate the process.

    2. The connection remains idle and is automatically terminated.

  2. The PDP Tier Manager does the following:

    1. Indicates to the PDP Meta-Connection Provider (MCPR) of the low priority connection that it can restore the connection.

    2. The PDP MCPR sends an availability notification to the CConnection of the low priority connection.

  3. CConnection of the low priority connection receives the availability notification and uses RConnection::Start(TConnPrefList) to establish the connection.

Restoring a connection

Use the following code to ensure a stopped connection is restored when the higher priority connection has completed.

+Restarting a Network Connection TutorialThis section describes the steps used to start a network connection that was stopped due to contention.
Introduction

A low priority connection is terminated when a contention issue occurs and the incoming connection has a higher priority. The low priority connection can be restarted when the higher priority connection is complete. For example, if an always-on Internet connection is terminated to enable the user to send an MMS, the Internet connection is restarted when the message is sent.

Introduction

  1. To terminate the high priority connection on of the following occurs:

    1. The Connection Provider (CPR) receives a TStopNormal message to terminate the process.

    2. The connection remains idle and is automatically terminated.

  2. The PDP Tier Manager does the following:

    1. Indicates to the PDP Meta-Connection Provider (MCPR) of the low priority connection that it can restore the connection.

    2. The PDP MCPR sends an availability notification to the CConnection of the low priority connection.

  3. CConnection of the low priority connection receives the availability notification and uses RConnection::Start(TConnPrefList) to establish the connection.

Restoring a connection

Use the following code to ensure a stopped connection is restored when the higher priority connection has completed.

TConnPrefList* prefs = TConnPrefList::NewL(); CleanupStack::PushL(prefs); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e62220_href.png Binary file Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e62220_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e62363_href.png Binary file Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e62363_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e68994_href.png Binary file Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e68994_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e69018_href.png Binary file Symbian3/SDK/Source/GUID-02072A1B-6F60-457B-8F26-2B25A6EA7C5F_d0e69018_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-023268BB-8C52-51A1-9E3B-4C7E265DFDAB.dita --- a/Symbian3/SDK/Source/GUID-023268BB-8C52-51A1-9E3B-4C7E265DFDAB.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --wrap-wrap[=<value>]

A static analysis tool can be invoked if [=<value>] is not specified. For example, -wrap.

The name of the static analysis tool executable is set using the environment variable ABLD_COMPWRAP. For more information, see How to invoke a static analysis tool using abld.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-023D30F0-C1E8-5E09-92AD-C5A7963DCF70_d0e304438_href.jpg Binary file Symbian3/SDK/Source/GUID-023D30F0-C1E8-5E09-92AD-C5A7963DCF70_d0e304438_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-023D30F0-C1E8-5E09-92AD-C5A7963DCF70_d0e310910_href.jpg Binary file Symbian3/SDK/Source/GUID-023D30F0-C1E8-5E09-92AD-C5A7963DCF70_d0e310910_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02521DB0-53C4-55D5-856F-BD478E134B73_d0e333616_href.png Binary file Symbian3/SDK/Source/GUID-02521DB0-53C4-55D5-856F-BD478E134B73_d0e333616_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02521DB0-53C4-55D5-856F-BD478E134B73_d0e340082_href.png Binary file Symbian3/SDK/Source/GUID-02521DB0-53C4-55D5-856F-BD478E134B73_d0e340082_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0259868F-8F88-5D9D-A9DE-9309C3BFBA85_d0e277562_href.png Binary file Symbian3/SDK/Source/GUID-0259868F-8F88-5D9D-A9DE-9309C3BFBA85_d0e277562_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0259868F-8F88-5D9D-A9DE-9309C3BFBA85_d0e282401_href.png Binary file Symbian3/SDK/Source/GUID-0259868F-8F88-5D9D-A9DE-9309C3BFBA85_d0e282401_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02659624-4C27-573C-BE2E-0250D860BEA3.dita --- a/Symbian3/SDK/Source/GUID-02659624-4C27-573C-BE2E-0250D860BEA3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-02659624-4C27-573C-BE2E-0250D860BEA3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,6 +9,6 @@ --> -Media Client Video Display OverviewThis document provides an overview of the Media Client Video Display library that is used by the Video Client library in the Multimedia Framework component.
Purpose

The Media Client Video Display library allows you to display video in a window and to support a graphic surface.

Media Client Video Display library details

The DLL that provides the functionality and the library to which your code must link is identified below.

DLL LIB Short description

mediaclientvideodisplay.dll

mediaclientvideodisplay.lib

These files are used to implement the display video functionality and support graphics surfaces.

Architecture

Media Client Video Display is a standalone library used by the Video Client library to support video display. This allows you to use video display functionality separately from the client utilities. The class diagram forCMediaClientVideoDisplay is as follows:

Description

The Media Client Video Display library is a client interface to access display functions. The display functions are as follows:

  • Adding a new window

  • Redrawing the window

  • Setting the video data for automatic and specified dimension scaling

  • Rotating the video image

  • Clipping the window

  • Setting the video extension on the screen that is relative to the window.

The Media Client Video Display library allows you to perform rendering of video to graphics surfaces. It provides APIs to:

  • Create the graphic surface

  • Update the graphic surface

  • Surface parameters changed during video play back

  • Remove the graphic surface.

APIs

The key class of Media Client Video Display is as follows:

API Description

CMediaClientVideoDisplay

This class is an interface to add or remove video display windows. The CMediaClientVideoDisplay class supports graphics surfaces and provides display handling functions like video extension, scaling and rotation.

Using Media Client Video Display

Clients use CMediaClientVideoDisplay to:

  • Display video in a window

  • Support graphics surfaces.

Media Client Video Display +Media Client Video Display OverviewThis document provides an overview of the Media Client Video Display library that is used by the Video Client library in the Multimedia Framework component.
Purpose

The Media Client Video Display library allows you to display video in a window and to support a graphic surface.

Media Client Video Display library details

The DLL that provides the functionality and the library to which your code must link is identified below.

DLL LIB Short description

mediaclientvideodisplay.dll

mediaclientvideodisplay.lib

These files are used to implement the display video functionality and support graphics surfaces.

Architecture

Media Client Video Display is a standalone library used by the Video Client library to support video display. This allows you to use video display functionality separately from the client utilities. The class diagram forCMediaClientVideoDisplay is as follows:

Description

The Media Client Video Display library is a client interface to access display functions. The display functions are as follows:

  • Adding a new window

  • Redrawing the window

  • Setting the video data for automatic and specified dimension scaling

  • Rotating the video image

  • Clipping the window

  • Setting the video extension on the screen that is relative to the window.

The Media Client Video Display library allows you to perform rendering of video to graphics surfaces. It provides APIs to:

  • Create the graphic surface

  • Update the graphic surface

  • Surface parameters changed during video play back

  • Remove the graphic surface.

APIs

The key class of Media Client Video Display is as follows:

API Description

CMediaClientVideoDisplay

This class is an interface to add or remove video display windows. The CMediaClientVideoDisplay class supports graphics surfaces and provides display handling functions like video extension, scaling and rotation.

Using Media Client Video Display

Clients use CMediaClientVideoDisplay to:

  • Display video in a window

  • Support graphics surfaces.

Media Client Video Display Tutorial Video Client Overview Graphics Composition Surfaces \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0268102D-D238-5C5E-818F-6ACC4A85B022_d0e8285_href.png Binary file Symbian3/SDK/Source/GUID-0268102D-D238-5C5E-818F-6ACC4A85B022_d0e8285_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0268102D-D238-5C5E-818F-6ACC4A85B022_d0e8407_href.png Binary file Symbian3/SDK/Source/GUID-0268102D-D238-5C5E-818F-6ACC4A85B022_d0e8407_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-026E865E-12FA-59A9-B923-309B65790E23.dita --- a/Symbian3/SDK/Source/GUID-026E865E-12FA-59A9-B923-309B65790E23.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-026E865E-12FA-59A9-B923-309B65790E23.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@

The flowchart below shows the steps to create a Fat Filename Conversion plug-in DLL.

- +

Note: To create the plug-in DLL, the unicodeconv.cpp file is needed. It provides the functions to convert text between Unicode and a foreign encoding. It is available on the Symbian Foundation web site.

This tutorial diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02970C7B-5B98-50C7-A324-0DDD71120DEB_d0e185592_href.png Binary file Symbian3/SDK/Source/GUID-02970C7B-5B98-50C7-A324-0DDD71120DEB_d0e185592_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02970C7B-5B98-50C7-A324-0DDD71120DEB_d0e190588_href.png Binary file Symbian3/SDK/Source/GUID-02970C7B-5B98-50C7-A324-0DDD71120DEB_d0e190588_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02F4AA24-283A-503D-8BA9-7C926DC7E306_d0e393621_href.png Binary file Symbian3/SDK/Source/GUID-02F4AA24-283A-503D-8BA9-7C926DC7E306_d0e393621_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-02F4AA24-283A-503D-8BA9-7C926DC7E306_d0e397416_href.png Binary file Symbian3/SDK/Source/GUID-02F4AA24-283A-503D-8BA9-7C926DC7E306_d0e397416_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0348B62D-1AE0-45F5-B06E-9EE2D83326E8.dita --- a/Symbian3/SDK/Source/GUID-0348B62D-1AE0-45F5-B06E-9EE2D83326E8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0348B62D-1AE0-45F5-B06E-9EE2D83326E8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ general, only the most important status indicators are displayed.

Universal status indicators displayed in the top-right corner - +
Using universal indicators in applications

The universal diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03671C88-6911-5184-A9D4-A2D2FD69A2B9_d0e413283_href.png Binary file Symbian3/SDK/Source/GUID-03671C88-6911-5184-A9D4-A2D2FD69A2B9_d0e413283_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03671C88-6911-5184-A9D4-A2D2FD69A2B9_d0e417083_href.png Binary file Symbian3/SDK/Source/GUID-03671C88-6911-5184-A9D4-A2D2FD69A2B9_d0e417083_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-038747F2-E5A2-5739-BFF5-69B6BD0DCEB2.dita --- a/Symbian3/SDK/Source/GUID-038747F2-E5A2-5739-BFF5-69B6BD0DCEB2.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -abld command syntax \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e52515_href.png Binary file Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e52515_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e52658_href.png Binary file Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e52658_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e67355_href.png Binary file Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e67355_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e67496_href.png Binary file Symbian3/SDK/Source/GUID-03A3E872-8183-4F56-976E-A6AF435742C6_d0e67496_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e214249_href.png Binary file Symbian3/SDK/Source/GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e214249_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e219247_href.png Binary file Symbian3/SDK/Source/GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e219247_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-03BBEA31-3266-5B1C-9017-4EE7EA4AF1A8.dita --- a/Symbian3/SDK/Source/GUID-03BBEA31-3266-5B1C-9017-4EE7EA4AF1A8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-03BBEA31-3266-5B1C-9017-4EE7EA4AF1A8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -44,7 +44,7 @@ example: createsis create -cert trustedchain.pem -key eecertkey.key mypackage.pkg

The process of creating an installation file can be understood using the following illustration:

- +
Notes

While creating a SIS file using the CreateSIS tool, if you do not specify the key or certificate on the command line the create method diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-043A9408-1A97-4122-9364-965ECC08B40F.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-043A9408-1A97-4122-9364-965ECC08B40F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,31 @@ + + + + + +Converting +from any local time to UTC + +To convert the local +time of a non-system time zone to UTC, use CTzConverter::ConvertToUniversalTime(), +specifying the time zone to convert from: +

TInt errCode = myConverter->ConvertToUniversalTime(myTime, myZoneId); +

+

These time conversions internally do the following:

    +

  • fetch a number of 'actualized' rules applicable to the years around +the supplied time and zone, where an 'actualized' rule defines a single and +specific time of year when local time changes. It is derived from the encoded +day rule defined in the Olson’s TZ database RULE.

    • +

  • cache these rules for subsequent use.

    • +

  • identify which rule immediately precedes the time supplied.

    • +

  • apply the appropriate offsets defined by this rule.

    • +

 + + + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-043CFB8D-8780-478C-A3B2-FE5838795665_d0e53370_href.png Binary file Symbian3/SDK/Source/GUID-043CFB8D-8780-478C-A3B2-FE5838795665_d0e53370_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-043CFB8D-8780-478C-A3B2-FE5838795665_d0e53513_href.png Binary file Symbian3/SDK/Source/GUID-043CFB8D-8780-478C-A3B2-FE5838795665_d0e53513_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-045F3455-2B5A-5B20-ABCE-ED202DC5078A_d0e7121_href.png Binary file Symbian3/SDK/Source/GUID-045F3455-2B5A-5B20-ABCE-ED202DC5078A_d0e7121_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-045F3455-2B5A-5B20-ABCE-ED202DC5078A_d0e7243_href.png Binary file Symbian3/SDK/Source/GUID-045F3455-2B5A-5B20-ABCE-ED202DC5078A_d0e7243_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-049A089E-FF08-5706-8485-8C9A5A0BCF6F.dita --- a/Symbian3/SDK/Source/GUID-049A089E-FF08-5706-8485-8C9A5A0BCF6F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,15 +0,0 @@ - - - - - -Symbian Emulator build output locations

In versions of the OS from v9.0, all executable files (exes and libraries) are built on the Symbian emulator to epoc32\release\winscw\udeb\ (or urel\ for release builds). This location is the equivalent to \sys\bin\ on target devices.

Resource files and other non-executable files are built to the location specified in the mmp file below epoc32\release\winscw\ udeb or - urel \z\, for example, epoc32\release\winscw\ udeb or - urel \z\resource\apps\ for GUI application resources.

A copy of the built resources etc. is also put under epoc32\data\Z\, which is used when building for any target, Symbian emulator or ARM. Because the same resource files apply to all build targets, it makes sense for them to be located in a common directory.

To run an executable file, start the Symbian emulator epoc32\release\winscw\ udeb or - urel \epoc.exe, and run the program from whatever shell program the UI being used provides.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-04D917A1-E1A0-5149-9660-80A1146D0984.dita --- a/Symbian3/SDK/Source/GUID-04D917A1-E1A0-5149-9660-80A1146D0984.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-04D917A1-E1A0-5149-9660-80A1146D0984.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ (shown in green).

OpenGLES component relationships - +

It is possible for the OpenGL ES and EGL implementations to communicate through a private interface that is not standardized by Symbian.

diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0504B740-FB22-4399-B16D-BE6030B512B3.dita --- a/Symbian3/SDK/Source/GUID-0504B740-FB22-4399-B16D-BE6030B512B3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0504B740-FB22-4399-B16D-BE6030B512B3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,11 +21,11 @@ button present within the input.

Split view ITU-T - + Split view QWERTY - +

In hybrid devices, when the hardware keyboard is opened, the virtual keyboard (full screen or split view) disappears.

diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0522B178-0FD5-4416-B7FE-390749F7A13D.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-0522B178-0FD5-4416-B7FE-390749F7A13D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,15 @@ + + + + + +Contacts Guide +

The Contacts package offers services for managing contacts-related +data. Contacts package includes Phonebook and Logs applications.

+ \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e190203_href.png Binary file Symbian3/SDK/Source/GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e190203_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e195174_href.png Binary file Symbian3/SDK/Source/GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e195174_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-053FFF2B-6FB1-5065-B9D1-047477F3DE01.dita --- a/Symbian3/SDK/Source/GUID-053FFF2B-6FB1-5065-B9D1-047477F3DE01.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-053FFF2B-6FB1-5065-B9D1-047477F3DE01.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@

The following diagram illustrates the concept of the dictionary store.

Dictionary store - +

The interface to a dictionary store is provided by the CDictionaryStore abstract class. The classes for concrete dictionary stores are derived from this abstract diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-055E42B2-27E7-45F2-8450-5CCF4E1DEB15_d0e63611_href.png Binary file Symbian3/SDK/Source/GUID-055E42B2-27E7-45F2-8450-5CCF4E1DEB15_d0e63611_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-055E42B2-27E7-45F2-8450-5CCF4E1DEB15_d0e63754_href.png Binary file Symbian3/SDK/Source/GUID-055E42B2-27E7-45F2-8450-5CCF4E1DEB15_d0e63754_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-056165A7-E8A1-4868-8051-9EC58C5A3342.dita --- a/Symbian3/SDK/Source/GUID-056165A7-E8A1-4868-8051-9EC58C5A3342.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-056165A7-E8A1-4868-8051-9EC58C5A3342.dita Tue Jul 20 12:00:49 2010 +0100 @@ -54,7 +54,7 @@ this case, scrollbars are used as navigation indicators.

- +

Direct taps and strokes are far easier for the user to understand and pick up than abstract, indirect ones. A single view must always employ only a few diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-056B9A65-EC59-4B2E-9F10-E487343B5F5F.dita --- a/Symbian3/SDK/Source/GUID-056B9A65-EC59-4B2E-9F10-E487343B5F5F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-056B9A65-EC59-4B2E-9F10-E487343B5F5F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,66 +1,66 @@ - - - - - -SemaphoreExample: -thread synchronisation using semaphoresExplains how to use Semaphores to achieve thread synchronization. -

It is recommended to use semaphores instead of thread priorities for the -following reasons:

    -

  • In a uniprocessor environment, setting the thread priorities does -not guarantee prioritized or serialized execution.

    • -

  • In a multiprocessor or SMP environment, thread priorities are irrelevant -as multiple threads can run simultaneously.

    • -

-
Download

Click on the following link to download -the example: SemaphoreExample.zip

Click: browse to view the example code.

-
Description:

The example creates a database containing -a table of three columns with integer entries.

The example creates -two threads:

    -

  • WriterThread: This thread calls a periodic function -at an interval of one second, and in each iteration it inserts one row of -integers in the table.

    • -

  • ReaderThread: This thread also calls a periodic function -at an interval of one second, and in each iteration it reads one row of integers -following the last row read.

    • -

The example uses a macro USE_SEMAPHORE to show the -difference between the code using semaphores and the code which doesn't use -semaphores. When not using semaphores, it is not guaranteed that the ReaderThread will -be able to read the database because in an SMP environment, data may not yet -have been written by the WriterThread.

Using a semaphore -serializes the thread execution. The read operation waits on the semaphore -until it gets a signal from the write operation. This ensures that the ReaderThread only -reads a row from the database after the WriterThread has -written it.

-
Class summary
    -

  • RThread - A handle to a thread.

    • -

  • RDbStoreDatabase - DBMS Store database implementation

    • -

  • RSemaphore - Used for thread synchronization.

    • -
-
Building and configuring

To build the example:

    -

  • The example builds an -executable called semaphoreexample.exe in the standard -location.

    • -

  • You can build the example -from your IDE or the command line.

    If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

    If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

    bldmake -bldfiles

    abld build

    How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

    • -
-
Running the example

The example code contains a -macroUSE_SEMAPHORE in the mmp file. -By default it is commented out and on execution the example runs without using -semaphores; the macro should be uncommented to use semaphores. The console -output will generally look the same whether using semaphores or not if there -is a single processor, but differences will occur in an SMP environment. Run -the example following the instructions provided in the console.

+ + + + + +SemaphoreExample: thread synchronisation using semaphoresExplains how to use Semaphores to achieve thread synchronization. +

It is recommended to use semaphores instead of thread priorities +for the following reasons:

    +

  • In a uniprocessor environment, setting the thread priorities +does not guarantee prioritized or serialized execution.

    • +

  • In a multiprocessor or SMP environment, thread priorities are +irrelevant as multiple threads can run simultaneously.

    • +

+
Download

Click on the following link to download the example: SemaphoreExample.zip

Click: browse to view the example code.

+
Description:

The example creates a database containing a table of three columns +with integer entries.

The example creates two threads:

    +

  • WriterThread: This thread calls a periodic +function at an interval of one second, and in each iteration it inserts +one row of integers in the table.

    • +

  • ReaderThread: This thread also calls a periodic +function at an interval of one second, and in each iteration it reads +one row of integers following the last row read.

    • +

The example uses a macro USE_SEMAPHORE to +show the difference between the code using semaphores and the code +which doesn't use semaphores. When not using semaphores, it is not +guaranteed that the ReaderThread will be able to +read the database because in an SMP environment, data may not yet +have been written by the WriterThread.

Using +a semaphore serializes the thread execution. The read operation waits +on the semaphore until it gets a signal from the write operation. +This ensures that the ReaderThread only reads a row +from the database after the WriterThread has written +it.

+
Class +summary
    +

  • RThread - A handle to a thread.

    • +

  • RDbStoreDatabase - DBMS Store database implementation

    • +

  • RSemaphore - Used for thread synchronization.

    • +
+
Building +and configuring

To build the example:

    +

  • The example +builds an executable called semaphoreexample.exe in the standard location.

    • +

  • You can build +the example from your IDE or the command line.

    If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

    If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

    bldmake bldfiles

    abld +build .

    • +
+
Running +the example

The example code contains a macroUSE_SEMAPHORE in the mmp file. By default it is commented +out and on execution the example runs without using semaphores; the +macro should be uncommented to use semaphores. The console output +will generally look the same whether using semaphores or not if there +is a single processor, but differences will occur in an SMP environment. +Run the example following the instructions provided in the console.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-057891A5-2394-489E-9323-91BE256F2188_d0e64300_href.png Binary file Symbian3/SDK/Source/GUID-057891A5-2394-489E-9323-91BE256F2188_d0e64300_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-057891A5-2394-489E-9323-91BE256F2188_d0e64443_href.png Binary file Symbian3/SDK/Source/GUID-057891A5-2394-489E-9323-91BE256F2188_d0e64443_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-05C87497-738B-473C-B5B2-BE46D32225F5_d0e66467_href.png Binary file Symbian3/SDK/Source/GUID-05C87497-738B-473C-B5B2-BE46D32225F5_d0e66467_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-05C87497-738B-473C-B5B2-BE46D32225F5_d0e66610_href.png Binary file Symbian3/SDK/Source/GUID-05C87497-738B-473C-B5B2-BE46D32225F5_d0e66610_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-063020E5-51C0-45C3-8B8B-015385FA0928.dita --- a/Symbian3/SDK/Source/GUID-063020E5-51C0-45C3-8B8B-015385FA0928.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-063020E5-51C0-45C3-8B8B-015385FA0928.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,14 +18,14 @@ Calling freopen() once more, the user can change the filename during execution. This helps to redirect application printf() messages into a log file.

-
Download

Click +

Download

Click on the following link to download the example: redirectprintf.zip

Click: browse to view the example code.

-
Design and +<section id="GUID-7E7C4564-B10E-41F9-8A9D-D8A6C5E9C51C-GENID-1-10-1-13-1-1-5-1-3-1-11-1-15-1-3-3"><title>Design and Implementation

The following sections provide information about the implementation of the example.

Capabilities

The program capabilities are defined in redirectprintf.mmp : CAPABILITY NONE.
-
Building and +<section id="GUID-67A72761-1D92-46D1-B1C9-7455978BDE4E-GENID-1-10-1-13-1-1-5-1-3-1-11-1-15-1-3-4"><title>Building and Using To build the example application, go to the redirectprintf\group directory and build the application. The definition for the whole application can be found in the bld.inf file in the group subdirectory of the applications diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-067BC702-4F66-5CAF-952D-7CFA35F5EB1E.dita --- a/Symbian3/SDK/Source/GUID-067BC702-4F66-5CAF-952D-7CFA35F5EB1E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-067BC702-4F66-5CAF-952D-7CFA35F5EB1E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,5 +9,5 @@ --> -Twip to Pixel Mapping

This topic provides an introduction to two classes that embody the important GUI features of device independence and the ability to zoom.

Two desirable facilities of a GUI are:

  • device independence

  • zooming to reveal greater levels of detail or, conversely, more of a document

These two facilities are embodied in the two classes MGraphicsDeviceMap and TZoomFactor.

Device independence is facilitated by storing drawings and text in device-independent form and then converting the device-independent units (twips) into device-dependent units (pixels) for different devices such as screens and printers. The conversion interface is MGraphicsDeviceMap, and it is implemented by graphics devices.

TZoomFactor also implements this interface. It takes a mapping between twips and pixels, and then also applies a zooming factor: the larger the zooming factor, the more pixels per twip. The relationship between the classes is shown below:

Note that TZoomFactor not only implements MGraphicsDeviceMap but also uses it. The point is that the MGraphicsDeviceMap -supporting object used can either be a graphics device, or another TZoomFactor. This allows zooming to be applied to an already zoomed mapping.

Using TZoomFactor and +Twip to Pixel Mapping

This topic provides an introduction to two classes that embody the important GUI features of device independence and the ability to zoom.

Two desirable facilities of a GUI are:

  • device independence

  • zooming to reveal greater levels of detail or, conversely, more of a document

These two facilities are embodied in the two classes MGraphicsDeviceMap and TZoomFactor.

Device independence is facilitated by storing drawings and text in device-independent form and then converting the device-independent units (twips) into device-dependent units (pixels) for different devices such as screens and printers. The conversion interface is MGraphicsDeviceMap, and it is implemented by graphics devices.

TZoomFactor also implements this interface. It takes a mapping between twips and pixels, and then also applies a zooming factor: the larger the zooming factor, the more pixels per twip. The relationship between the classes is shown below:

Note that TZoomFactor not only implements MGraphicsDeviceMap but also uses it. The point is that the MGraphicsDeviceMap -supporting object used can either be a graphics device, or another TZoomFactor. This allows zooming to be applied to an already zoomed mapping.

Using TZoomFactor and MGraphicsDeviceMap Graphics Device Interface Concepts \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-06B287CD-C19A-4CAC-8378-5563C552448B_d0e58084_href.png Binary file Symbian3/SDK/Source/GUID-06B287CD-C19A-4CAC-8378-5563C552448B_d0e58084_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-06B287CD-C19A-4CAC-8378-5563C552448B_d0e58227_href.png Binary file Symbian3/SDK/Source/GUID-06B287CD-C19A-4CAC-8378-5563C552448B_d0e58227_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-074F3499-54FE-58BC-A0F4-D8EA632AF76B.dita --- a/Symbian3/SDK/Source/GUID-074F3499-54FE-58BC-A0F4-D8EA632AF76B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-074F3499-54FE-58BC-A0F4-D8EA632AF76B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Externalising a Swizzle

Typically, externalizing a Swizzle is a two stage process which involves:

  • externalizing the in-memory object which the Swizzle represents, to its own stream

  • externalizing the resulting stream ID.

For example, given a container type object, CClassABC, with a data member TSwizzle<CClassB> iB representing a CClassB object in memory, the diagram below illustrates the result of storing the container object.

The following code fragments illustrates the process.

iB is a CClassB type component of a class CClassABC, and is represented by a Swizzle. The data member is defined as:

class CCClassABC : public CBase +Externalising a Swizzle

Typically, externalizing a Swizzle is a two stage process which involves:

  • externalizing the in-memory object which the Swizzle represents, to its own stream

  • externalizing the resulting stream ID.

For example, given a container type object, CClassABC, with a data member TSwizzle<CClassB> iB representing a CClassB object in memory, the diagram below illustrates the result of storing the container object.

The following code fragments illustrates the process.

iB is a CClassB type component of a class CClassABC, and is represented by a Swizzle. The data member is defined as:

class CCClassABC : public CBase { ... TSwizzle<CClassB> iB; @@ -45,4 +45,4 @@ aStream << iB ... } -

At this point, the Swizzle still represents the CClassB object as a pointer, and the object itself is still in memory.

The mechanism underlying the implementation of the stream operator<<, assumes that the stream ID associated with the Swizzle has been placed in the store map. It also assumes that the RStoreWriteStream object has been constructed, specifying the store map as an externalizer.

The end result of the operation aStream << iB;, is to externalise, to the stream, the stream ID associated with the Swizzle iB. The following diagram shows this:

 \ No newline at end of file +

At this point, the Swizzle still represents the CClassB object as a pointer, and the object itself is still in memory.

The mechanism underlying the implementation of the stream operator<<, assumes that the stream ID associated with the Swizzle has been placed in the store map. It also assumes that the RStoreWriteStream object has been constructed, specifying the store map as an externalizer.

The end result of the operation aStream << iB;, is to externalise, to the stream, the stream ID associated with the Swizzle iB. The following diagram shows this:

 \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07791D92-4B0F-5D11-9874-4C03FA1A2C02.dita --- a/Symbian3/SDK/Source/GUID-07791D92-4B0F-5D11-9874-4C03FA1A2C02.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-07791D92-4B0F-5D11-9874-4C03FA1A2C02.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,35 +1,36 @@ - - - - - -MClasses1-3: -abstract interface classes -
Description

The three examples show the use of -‘M’ (abstract interface) classes, the only type of multiple inheritance used -on the Symbian platform.

They show how interfaces can be used to define -a protocol. The interface is implemented by a protocol provider, and called -by a protocol user. The user is not supposed to know anything about the provider's -implementation, only about the protocol it's interested in.

-
Download

Click on the following links to download -the examples:

MClasses1.zip

MClasses2.zip

MClasses3.zip

Click on the following link to -download additional files: CommonFramework.zip.

Click the following links -to view the example code.

MClasses1

MClasses2

MClasses3

Click browse CommonFramework to view the additional -files.

-
Build

The examples each include the two project -files needed for building: bld.inf and the .mmp file.

The Symbian platform build -process describes how to build these applications. They results in -executables called:

\epoc32\release\<target>\<urel -or udeb>\MCLASSES1.EXE.

\epoc32\release\<target>\<urel -or udeb>\MCLASSES2.EXE.

\epoc32\release\<target>\<urel -or udeb>\MCLASSES3.EXE.

-
Usage

Run the executables MCLASSES1.EXE, MCLASSES2.EXE and MCLASSES3.EXE.

Executables for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

+ + + + + +MClasses1-3: abstract interface classes +
Description

The three examples show the +use of ‘M’ (abstract interface) classes, the only type of multiple +inheritance used on the Symbian platform.

They show how interfaces +can be used to define a protocol. The interface is implemented by +a protocol provider, and called by a protocol user. The user is not +supposed to know anything about the provider's implementation, only +about the protocol it's interested in.

+
Download

Click on the following links to +download the examples:

MClasses1.zip

MClasses2.zip

MClasses3.zip

Click on the following +link to download additional files: CommonFramework.zip.

Click the following +links to view the example code.

MClasses1

MClasses2

MClasses3

Click browse CommonFramework to view the additional +files.

+
Build

The examples each include the two +project files needed for building: bld.inf and +the .mmp file.

The Symbian platform +build process describes how to build these applications. They result +in executables called:

\epoc32\release\<target>\<urel +or udeb>\MCLASSES1.EXE.

\epoc32\release\<target>\<urel +or udeb>\MCLASSES2.EXE.

\epoc32\release\<target>\<urel +or udeb>\MCLASSES3.EXE.

+
Usage

Run the executables MCLASSES1.EXE, MCLASSES2.EXE and MCLASSES3.EXE.

Executables for the emulator targets wins and winscw can be run on your PC. Executables +for ARM targets must be copied to your target platform before being +run.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07A42662-87A1-4537-89B9-F87DFC8481E8.dita --- a/Symbian3/SDK/Source/GUID-07A42662-87A1-4537-89B9-F87DFC8481E8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-07A42662-87A1-4537-89B9-F87DFC8481E8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ indicator, and the corresponding top-right area for the battery level indicator.

Signal and battery indicators on the sides of the status pane. - +

The signal indicator is a part of the Status pane, and it is displayed in all states where the Status pane exists. Indicators consist of a bar graph diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07B6D7EE-575A-5E8E-A2BB-8893F84F7F6D_d0e323166_href.jpg Binary file Symbian3/SDK/Source/GUID-07B6D7EE-575A-5E8E-A2BB-8893F84F7F6D_d0e323166_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07B6D7EE-575A-5E8E-A2BB-8893F84F7F6D_d0e329636_href.jpg Binary file Symbian3/SDK/Source/GUID-07B6D7EE-575A-5E8E-A2BB-8893F84F7F6D_d0e329636_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07C031C2-7FFC-5B0E-9691-E6E678E65C4B.dita --- a/Symbian3/SDK/Source/GUID-07C031C2-7FFC-5B0E-9691-E6E678E65C4B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Resource file source format \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07D2ED79-90B2-4ABC-A61F-108DAEE21955.dita --- a/Symbian3/SDK/Source/GUID-07D2ED79-90B2-4ABC-A61F-108DAEE21955.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-07D2ED79-90B2-4ABC-A61F-108DAEE21955.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,12 +11,12 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Implementing framework requirements -Application Menu +Application Menu

In the Symbian platform, mobile device users start applications from the application menu. When the mobile device user selects an application, the application framework calls the application's entry point to launch the application. In some cases, applications can also be started by other executables.

-Application launch +Application launch

When an application starts, objects are created in the following order:

  1. application diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07F65EEA-5969-5E56-9570-245712FB3EE3_d0e240067_href.png Binary file Symbian3/SDK/Source/GUID-07F65EEA-5969-5E56-9570-245712FB3EE3_d0e240067_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-07F65EEA-5969-5E56-9570-245712FB3EE3_d0e245026_href.png Binary file Symbian3/SDK/Source/GUID-07F65EEA-5969-5E56-9570-245712FB3EE3_d0e245026_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08152DC3-2A5D-42AC-B722-3D49275FE548_d0e12976_href.png Binary file Symbian3/SDK/Source/GUID-08152DC3-2A5D-42AC-B722-3D49275FE548_d0e12976_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08152DC3-2A5D-42AC-B722-3D49275FE548_d0e13076_href.png Binary file Symbian3/SDK/Source/GUID-08152DC3-2A5D-42AC-B722-3D49275FE548_d0e13076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0817AD1D-58CF-5108-ACBF-26DFD4BA395E.dita --- a/Symbian3/SDK/Source/GUID-0817AD1D-58CF-5108-ACBF-26DFD4BA395E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0817AD1D-58CF-5108-ACBF-26DFD4BA395E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,86 +1,80 @@ - - - - - -Descriptors -OverviewThis document provides an overview of descriptors. -

    Purpose

    Manipulates -string and data buffers.

    -
    Description

    Descriptors -are a family of classes that are used in Symbian platform for string handling. -They are used in preference to NULL-terminated C strings. The same classes -are used for general binary data.

    The basic classification of descriptor -types is given below. Concrete descriptor classes implement variations on -these basic types for different data widths and for different abilities to -modify the data. The names of the concrete classes follow certain naming conventions -that modify the basic name given in the table.

    Basic -classification

    - - - -

    Type

    -

    Description

    -

    Basic name

    -     - -

    abstract

    -

    Base interface: allows descriptors of different types to be use -polymorphically

    -

    TDes

    -     - -

    buffer

    -

    Stack based: contains the data as part of itself. Buffer descriptors -have a maximum length set at compile time.

    -

    TBuf

    -     - -

    pointer

    -

    Refer to data stored elsewhere that is not owned by the descriptor

    -

    TPtr

    -     - -

    heap

    -

    Refers to data stored on the heap that is owned by the descriptor. -The maximum length of this data can be set and changed dynamically.

    -

    HBufC

    RBuf

    -     - - -

    Width

    Descriptor -types can store 8-bit or 16-bit data. These types are indicated by the convention -of appending 8 or 16 on the basic name, e.g. TDes16. In -practice, the basic names correspond to 16-bit types, for example TBuf is -defined to be TBuf16.

    Modifiable and non-modifiable

    Modifiable descriptor types -have an interface that allows callers to alter their contents, such as appending -characters.

    Non-modifiable descriptor types can have their contents -reset, but not modified. The convention is for non-modifiable types to append -a C on the basic name, e.g. TBufC.

    Heap type descriptors -are an exceptional case: they are available only in the non-modifiable form, -but can, nevertheless, be modified through use of a pointer: see HBufC::Des(). -Alternatively, you can use the RBuf descriptor, which is -simpler to use than HBufC. The general rule is:

      -

    • use HBufC for -data that rarely changes.

      • -

    • Use RBuf for -data that changes frequently.

      • -

    Example code

    For -examples, see:

      -

    • Descriptor Example -Code

      • -

    • Descriptors -Cookbook at the Symbian Foundation.

      • -

    • S60 Platform: Descriptor Example v2.1 on Forum Nokia.

      • -
    -
    See also

    Character Representation -Of Real Numbers Overview

    Dynamic -Buffers Overview

    Literals -Overview

    + + + + + +Descriptors OverviewThis document provides an overview of descriptors. +
    Purpose

    Manipulates string and data buffers.

    +
    Description

    Descriptors are a family of classes that are used in Symbian +platform for string handling. They are used in preference to NULL-terminated +C strings. The same classes are used for general binary data.

    The basic classification of descriptor types is given below. +Concrete descriptor classes implement variations on these basic types +for different data widths and for different abilities to modify the +data. The names of the concrete classes follow certain naming conventions +that modify the basic name given in the table.

    Basic classification

    + + + + +

    Type

    +

    Description

    +

    Basic name

    +     + +

    abstract

    +

    Base interface: allows descriptors of different types to +be use polymorphically

    +

    TDes

    +     + +

    buffer

    +

    Stack based: contains the data as part of itself. Buffer +descriptors have a maximum length set at compile time.

    +

    TBuf

    +     + +

    pointer

    +

    Refer to data stored elsewhere that is not owned by the +descriptor

    +

    TPtr

    +     + +

    heap

    +

    Refers to data stored on the heap that is owned by the descriptor. +The maximum length of this data can be set and changed dynamically.

    +

    HBufC

    RBuf

    +     + + +

    Width

    Descriptor types can store 8-bit or 16-bit data. +These types are indicated by the convention of appending 8 or 16 on +the basic name, e.g. TDes16. In practice, the basic +names correspond to 16-bit types, for example TBuf is defined to be TBuf16.

    Modifiable and non-modifiable

    Modifiable descriptor +types have an interface that allows callers to alter their contents, +such as appending characters.

    Non-modifiable descriptor types +can have their contents reset, but not modified. The convention is +for non-modifiable types to append a C on the basic name, e.g. TBufC.

    Heap type descriptors are an exceptional +case: they are available only in the non-modifiable form, but can, +nevertheless, be modified through use of a pointer: see HBufC::Des(). Alternatively, you can use the RBuf descriptor, +which is simpler to use than HBufC. The general rule +is:

      +

    • Use HBufC for data that rarely changes.

      • +

    • Use RBuf for data that changes frequently.

      • +

    Example code

    For +examples, see:

      +

    • Descriptor +Example Code

      • +

    • Descriptors Cookbook at the Symbian Foundation.

      • +

    • S60 Platform: Descriptor Example v2.1 on Forum +Nokia.

      • +
    +
    See +also

    Character Representation Of Real Numbers Overview

    Dynamic Buffers +Overview

    Literals Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0822B030-E776-4BD5-B9C9-23D3821BCE1F.dita --- a/Symbian3/SDK/Source/GUID-0822B030-E776-4BD5-B9C9-23D3821BCE1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0822B030-E776-4BD5-B9C9-23D3821BCE1F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -38,15 +38,15 @@ one or the other should happen for every item in the list.

    Select action opens a view - + Select action performs a command - + Context sensitive Options menu opened with the Selection key - +

    The keypad functions for selection lists are as follows:

    Default key events @@ -103,7 +103,7 @@ </table> <p/> <p>The following table lists the default touch events for selection list:</p> -<table id="GUID-5B8DA500-4092-4E1A-A035-308C4D352138-GENID-1-10-1-6-1-1-5-1-8-1-1-9-1-10-1-2-13"><title>Default touch +<table id="GUID-5B8DA500-4092-4E1A-A035-308C4D352138-GENID-1-10-1-7-1-1-5-1-8-1-1-9-1-10-1-2-13"><title>Default touch events for Selection list. @@ -146,7 +146,7 @@
    Selection lists - +
    Using selection lists in applications

    The API to use for selection lists diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-084C5F8F-3310-5BDE-BB4B-110361D45AB0_d0e220093_href.png Binary file Symbian3/SDK/Source/GUID-084C5F8F-3310-5BDE-BB4B-110361D45AB0_d0e220093_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-084C5F8F-3310-5BDE-BB4B-110361D45AB0_d0e225087_href.png Binary file Symbian3/SDK/Source/GUID-084C5F8F-3310-5BDE-BB4B-110361D45AB0_d0e225087_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-085CD9C3-706F-51E7-A1D5-95483D3C9254_d0e117334_href.png Binary file Symbian3/SDK/Source/GUID-085CD9C3-706F-51E7-A1D5-95483D3C9254_d0e117334_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-085CD9C3-706F-51E7-A1D5-95483D3C9254_d0e117574_href.png Binary file Symbian3/SDK/Source/GUID-085CD9C3-706F-51E7-A1D5-95483D3C9254_d0e117574_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08A6B93F-92CD-5182-B142-D353E78016F3_d0e406599_href.png Binary file Symbian3/SDK/Source/GUID-08A6B93F-92CD-5182-B142-D353E78016F3_d0e406599_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08A6B93F-92CD-5182-B142-D353E78016F3_d0e410399_href.png Binary file Symbian3/SDK/Source/GUID-08A6B93F-92CD-5182-B142-D353E78016F3_d0e410399_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08E31D57-A84D-5B6B-B16F-3F7025A763E9_d0e236873_href.png Binary file Symbian3/SDK/Source/GUID-08E31D57-A84D-5B6B-B16F-3F7025A763E9_d0e236873_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-08E31D57-A84D-5B6B-B16F-3F7025A763E9_d0e241853_href.png Binary file Symbian3/SDK/Source/GUID-08E31D57-A84D-5B6B-B16F-3F7025A763E9_d0e241853_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09044578-9ADB-540F-A854-A818EA3970B7_d0e240374_href.png Binary file Symbian3/SDK/Source/GUID-09044578-9ADB-540F-A854-A818EA3970B7_d0e240374_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09044578-9ADB-540F-A854-A818EA3970B7_d0e245333_href.png Binary file Symbian3/SDK/Source/GUID-09044578-9ADB-540F-A854-A818EA3970B7_d0e245333_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09142C26-0AFA-510E-836D-010EE07A1549_d0e188596_href.png Binary file Symbian3/SDK/Source/GUID-09142C26-0AFA-510E-836D-010EE07A1549_d0e188596_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09142C26-0AFA-510E-836D-010EE07A1549_d0e193567_href.png Binary file Symbian3/SDK/Source/GUID-09142C26-0AFA-510E-836D-010EE07A1549_d0e193567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09263C33-EE63-530C-A6B9-70806F0BC16D-master.png Binary file Symbian3/SDK/Source/GUID-09263C33-EE63-530C-A6B9-70806F0BC16D-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e469457_href.png Binary file Symbian3/SDK/Source/GUID-09263C33-EE63-530C-A6B9-70806F0BC16D_d0e469457_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-092C18D4-A525-5562-9BF6-41435E400290.dita --- a/Symbian3/SDK/Source/GUID-092C18D4-A525-5562-9BF6-41435E400290.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-092C18D4-A525-5562-9BF6-41435E400290.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,19 +16,20 @@

    The purpose is to create a basic multithreading example showing the usage of the LibpThread APIs. This example also shows how multi-threading is used to achieve concurrency in tasks and sharing of resources.

    -
    Download

    Click on the following link to download the example: LibpThreadExample.zip

    Click: browse to view the example code.

    -
    Description

    The following sections provide more information about the steps -that the example performs.

    Thread Synchronisation

    The example creates three threads named ThreadOne, -ThreadTwo and ThreadThree. The threads write "One", "Two" and "Three" -five times in a text file. The text file, located in epoc32\winscw\c\newfile.txt, is used as a shared resource for all three threads. A mutex is +

    Download

    Click on the following link to download the example: LibpThreadExample.zip

    Click: browse to view the example code.

    +
    Description

    The following sections provide more information about the steps +that the example performs.

    Thread Synchronisation

    The example creates three threads named ThreadOne, ThreadTwo +and ThreadThree. The threads write "One", "Two" and "Three" five times +in a text file. The text file, located in epoc32\winscw\c\newfile.txt, is used as a shared resource for all three threads. A mutex is used to ensure that first ThreadOne writes in the file, then ThreadTwo and then ThreadThree. If the mutex is not used all the threads can simultaneously write in the file. This can be seen by commenting out pthread_mutex_lock and pthread_mutex_unlock in the code.

    Related APIs

    pthread_mutex_lock(pthread_mutex_t *)

    pthread_mutex_unlock(pthread_mutex_t *)

    pthread_join(pthread_t,void **)

    pthread_mutex_t

    -
    Build

    The Symbian -build process describes how to build this example application.

    The example builds an executable called LibpThreadExample.exe in the standard locations.

    To run the example, start LibpThreadExample.exe from the file system or from your -IDE. After launching the executable, depending on the emulator you -are using, you may need to navigate away from the application launcher -or shell screen to view the console.

    +
    Build

    The Symbian build process describes how to build this example +application.

    The example builds an executable +called LibpThreadExample.exe in the standard +locations.

    To run the example, start LibpThreadExample.exe from the file system or from your IDE. After launching the executable, +depending on the emulator you are using, you may need to navigate +away from the application launcher or shell screen to view the console.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0991E536-97B2-4EAA-9448-A090BD073140_d0e71768_href.png Binary file Symbian3/SDK/Source/GUID-0991E536-97B2-4EAA-9448-A090BD073140_d0e71768_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0991E536-97B2-4EAA-9448-A090BD073140_d0e71795_href.png Binary file Symbian3/SDK/Source/GUID-0991E536-97B2-4EAA-9448-A090BD073140_d0e71795_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09A58B23-68EA-58D7-BBC9-E7F4C4BF55D7_d0e354144_href.png Binary file Symbian3/SDK/Source/GUID-09A58B23-68EA-58D7-BBC9-E7F4C4BF55D7_d0e354144_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09A58B23-68EA-58D7-BBC9-E7F4C4BF55D7_d0e383137_href.png Binary file Symbian3/SDK/Source/GUID-09A58B23-68EA-58D7-BBC9-E7F4C4BF55D7_d0e383137_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-09E44FE5-6BEE-49FF-8BBF-CBB3C066EE10.dita --- a/Symbian3/SDK/Source/GUID-09E44FE5-6BEE-49FF-8BBF-CBB3C066EE10.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-09E44FE5-6BEE-49FF-8BBF-CBB3C066EE10.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@

    Before listening for channel changes, you must open the sensor channel.

     - + Create a channel listener implementation for the MSensrvChannelListener interface. class ChannelListener:public MSensrvChannelListener diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0A13A931-016C-5325-97AF-2DE0B210DF2F.dita --- a/Symbian3/SDK/Source/GUID-0A13A931-016C-5325-97AF-2DE0B210DF2F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0A13A931-016C-5325-97AF-2DE0B210DF2F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -53,7 +53,7 @@ Window Server

    The Window Server controls access by many client applications, to the machine’s screen, keyboard and pointer.

    - +

    The Window Server thread runs at a higher priority than any application; only the kernel runs at a higher priority. Therefore, all applications' requests for screen updates, and all handling of @@ -79,7 +79,7 @@ we provide a summary of the key concepts.

    Window Server client-side API classes - + @@ -178,18 +178,12 @@ the Window Server and write to the screen directly. This avoids client-server communication and as a result is faster. However, some interaction with the Window Server is needed to prevent the application from drawing -over other application's data.

    In ScreenPlay, Symbian recommends -the use of external surfaces in preference to DSA. However, support for -DSA is maintained for backward compatibility reasons, although there -are some subtle changes in the support offered.

    ScreenPlay does -not support the mixing of CWindowGc and DSA rendering -to the same window. When DSA rendering is present, any CWindowGc rendering to the same window is ignored. For example, an application -that uses CWindowGC rendering in one part of a window -and DSA rendering in another part will not work as expected in a ScreenPlay -environment. Similarly, CWindowGc rendering can no -longer be used to seed the DSA content as it could previously. However, CWindowGc rendering can be provided but it is not rendered -until the DSA rendering finishes. It is therefore best to avoid mixing -the rendering types in the same window.

    +over other application's data.

    On ScreenPlay, support for +direct screen access (DSA) is maintained for backward compatibility +reasons, although Symbian recommends the use of external surfaces in preference to DSA. However, whereas on some earlier devices, +applications might work without fully conforming to the rules of DSA, +these rules are now necessarily enforced. See DSA Migration Guide for information about the guidelines applications must follow in +order to be able to run correctly on a ScreenPlay device.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0A61CB48-B8EA-5516-B24E-65898CDF2566.dita --- a/Symbian3/SDK/Source/GUID-0A61CB48-B8EA-5516-B24E-65898CDF2566.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0A61CB48-B8EA-5516-B24E-65898CDF2566.dita Tue Jul 20 12:00:49 2010 +0100 @@ -541,7 +541,7 @@ the C32 server. Each of these configurations is explained in more detail below.

    Figure 1 - No CSYs in main thread: RootServer with 4 C32 CPMs - +

    Referring to Figure 1, the following can be observed:

    1. The Main Thread has WorkerId=0, Role as Dealer and is configured to load no CSY

      2. @@ -573,7 +573,7 @@ Figure 2 - All CSYs in main thread: RootServer with single C32 CPM - +

      In Figure 2 the CPM loads any CSYs, and so should contain CSYList tag in the IniData section.

      The Main Thread has WorkerId=0, Role as Dealer and is configured to load any CSY. In this configuration @@ -585,7 +585,7 @@ Figure 3 - Some CSYs in main thread: RootServer with 3 CPMs - +

      From Figure 3, the following can be observed.

      1. The Main Thread has WorkerId=0, Role as Dealer and is configured to load HSDPA csy

        2. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0A932926-281D-5465-9F38-E5FA8AA7EBD4.dita --- a/Symbian3/SDK/Source/GUID-0A932926-281D-5465-9F38-E5FA8AA7EBD4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0A932926-281D-5465-9F38-E5FA8AA7EBD4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ following illustration shows the steps for creating a CSIPContactHeader instance.

        Creating a Contact Header - +
        Error handling

        If an error occurs during a synchronous operation initiated by the client, the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0AD34BA6-D0C5-5AD7-B8E1-F737BB5FC0AC.dita --- a/Symbian3/SDK/Source/GUID-0AD34BA6-D0C5-5AD7-B8E1-F737BB5FC0AC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0AD34BA6-D0C5-5AD7-B8E1-F737BB5FC0AC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@

        The classes involved with redraw stores are as follows:

        Redraw stores class diagram - +

        CWsRedrawMsgWindow is the class representing a redraw store. Draw commands are stored in a number of segments, stored in the nested diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B0EF90E-45A4-467F-8CD9-33FBC612B3BD_d0e5428_href.png Binary file Symbian3/SDK/Source/GUID-0B0EF90E-45A4-467F-8CD9-33FBC612B3BD_d0e5428_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B0EF90E-45A4-467F-8CD9-33FBC612B3BD_d0e5549_href.png Binary file Symbian3/SDK/Source/GUID-0B0EF90E-45A4-467F-8CD9-33FBC612B3BD_d0e5549_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B151FE8-21E1-58A1-BEB3-5502EDF052C0_d0e79218_href.png Binary file Symbian3/SDK/Source/GUID-0B151FE8-21E1-58A1-BEB3-5502EDF052C0_d0e79218_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B151FE8-21E1-58A1-BEB3-5502EDF052C0_d0e79276_href.png Binary file Symbian3/SDK/Source/GUID-0B151FE8-21E1-58A1-BEB3-5502EDF052C0_d0e79276_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B1A4D73-AB81-586C-9D95-A0F5EE1F4BC7_d0e327379_href.png Binary file Symbian3/SDK/Source/GUID-0B1A4D73-AB81-586C-9D95-A0F5EE1F4BC7_d0e327379_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0B1A4D73-AB81-586C-9D95-A0F5EE1F4BC7_d0e333849_href.png Binary file Symbian3/SDK/Source/GUID-0B1A4D73-AB81-586C-9D95-A0F5EE1F4BC7_d0e333849_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0BF25E2A-99B9-5558-B805-019430409518.dita --- a/Symbian3/SDK/Source/GUID-0BF25E2A-99B9-5558-B805-019430409518.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -SBSv1 and SBSv2 Build Systems

        Symbian provides two command line build systems, called SBSv1 and SBSv2, to build Symbian platform and applications developed for Symbian platform.

        SBSv1 is the name that is now given to the bldmake and abld build tools that have been provided on Symbian platform kits since Symbian OS v6. In SBSv1 , bldmake first generates top-level makefiles for a component, then abld builds the component. The bldmake and the abld commands must be run from the directory containing the bld.inf file. The documentation for the these tools is provided in the Symbian Developer Library. For more information, see How to use bldmake and How to use abld.

        SBSv2 is a newer build system. Its advantages over SBSv1 include:

        • It can run on both Microsoft Windows and Linux operating systems.

        • It can use third-party make engine to run parallel builds.

        • It can build the entire Symbian platform from a system definition file.

        • It generates and builds the makefiles in a single step.

        • It can be used from any directory location.

        Though SBSv2 uses the same build metadata files (bld.inf and .mmp) as SBSv1 for building Symbian platform, SBSv2 can help achieve improved build speed over SBSv1.

        For more information about SBSv2, see the Symbian Build System v2 documentation that is provided with the Platform Developer Toolkit.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0C01305E-9E73-4E44-BD13-361C93CC5E79_d0e265510_href.png Binary file Symbian3/SDK/Source/GUID-0C01305E-9E73-4E44-BD13-361C93CC5E79_d0e265510_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0C01305E-9E73-4E44-BD13-361C93CC5E79_d0e270373_href.png Binary file Symbian3/SDK/Source/GUID-0C01305E-9E73-4E44-BD13-361C93CC5E79_d0e270373_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0C7CDC47-6B42-5A20-BED8-086DA81D272E.dita --- a/Symbian3/SDK/Source/GUID-0C7CDC47-6B42-5A20-BED8-086DA81D272E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0C7CDC47-6B42-5A20-BED8-086DA81D272E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -60,10 +60,10 @@ material.

        The inheritance diagram above shows the <codeph>CPBEncryptionBase</codeph> abstract base class. Also shown are the following classes from the Cryptography API: <codeph>CPBEncryptElement</codeph>, <codeph>CPBEncryptSet</codeph>, <codeph>CPBAuthData</codeph>, <codeph>CPBEncryptionData</codeph>, and <codeph>CPBEncryptParams</codeph>. - + The inheritance diagram above shows the <codeph>CPBEncryptor</codeph> abstract base class. Also shown are the following classes from the Cryptography API: <codeph>CPBDecryptor</codeph>, <codeph>CPBDecryptorElement</codeph>, <codeph>CPBDecryptorSet</codeph>, <codeph>CSymmetricCipher</codeph>, <codeph>CPBEncryptorElement</codeph>, <codeph>CPBEncryptorSet</codeph>. - +
        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0C814ED6-3F64-4E0E-9C47-654AEDADBA90.dita --- a/Symbian3/SDK/Source/GUID-0C814ED6-3F64-4E0E-9C47-654AEDADBA90.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0C814ED6-3F64-4E0E-9C47-654AEDADBA90.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,238 +9,225 @@ --> -Going -Beyond Hello: A Tutorial for Symbian C++ ApplicationsThis tutorial shows how you can extend that basic example to create -a small paint application, along the way learning more about the application -frameworks (e.g. defining menus, how to handle touch-screen events, drawing -to the screen etc.). -

        In the Symbian C++ -Quick Start you learned how to create a basic example application using -Carbide.c++, and how to build and run it on the Windows emulator and on a -device.

        -

        Comes with Code: File: -HelloSymbianWorld Example Code.zip

        -
        Application -Structure

        Carbide.c++ offers two ways of exploring your project. -The traditional Project Explorer window, which can also be found in -Eclipse, lists the files belonging to the project in the same directory structure -as in the file system.

        The Symbian Project Navigator contains -the same contents, but displays them in a logical hierarchy according to Symbian -Conventions.

        You might wonder why a basic "Hello World" application -contains so many files. The answer is straightforward - a much simpler Hello -World wouldn’t be a very good starting point for real-world applications. -

        Instead the wizard generates the project for a complete and readily -extensible application. The project separates code and data, and uses a form -of the model -view controller pattern for structuring your code. The application -already reacts to system events and contains everything that is required for -localization.

        What are the directories of a project? - +Going Beyond Hello: A Tutorial for Symbian C++ ApplicationsThis tutorial shows how you can extend that basic example +to create a small paint application, along the way learning more about +the application frameworks (e.g. defining menus, how to handle touch-screen +events, drawing to the screen etc.). +

        In the Symbian +C++ Quick Start you learned how to create a basic example application +using Carbide.c++, and how to build and run it on the Windows emulator +and on a device.

        +

        Comes with Code: File: HelloSymbianWorld Example Code.zip

        +
        Application Structure

        Carbide.c++ offers two ways +of exploring your project. The traditional Project Explorer window, which can also be found in Eclipse, lists the files belonging +to the project in the same directory structure as in the file system. +

        The Symbian Project Navigator contains the same contents, +but displays them in a logical hierarchy according to Symbian Conventions.

        You might wonder +why a basic "Hello World" application contains so many files. The +answer is straightforward - a much simpler Hello World wouldn’t be +a very good starting point for real-world applications.

        Instead +the wizard generates the project for a complete and readily extensible +application. The project separates code and data, and uses a form +of the model view controller pattern for structuring +your code. The application already reacts to system events and contains +everything that is required for localization.

        What +are the directories of a project? +

        \group

          -

        • bld.inf: Component-definition file. This specifies the mmp files -that belong to your component, any shared header files that it exports, and -the default build targets (e.g. GCCE, WINSCW).

            -

          • Bld.inf is used to generate the makefiles and abld.bat used -to build for the command-line (see Symbian -C++ Quick Start).

            • -

          • This file is the starting point when you want to import a Symbian C++ -project into Carbide.c++, because it contains references to all executables -in your project (see the section on Importing Other Examples).

            • +

          • bld.inf: Component-definition file. This specifies the mmp files that belong to your component, any shared header +files that it exports, and the default build targets (e.g. GCCE, WINSCW).

              +

            • Bld.inf is used to generate the makefiles +and abld.bat used to build for the command-line (see Symbian C++ Quick +Start).

              • +

            • This file is the starting point when you want to import a Symbian +C++ project into Carbide.c++, because it contains references to all +executables in your project (see the section on Importing Other Examples).

            • -

          • HelloWorld.mmp: Project-definition file. This specifies how -to build an executable (in this case HelloWorld.exe) in a -platform- and compiler-independent way. It contains information such as resource -files to be compiled, source files to include when compiling, and the libraries -to include when linking.

            • -

          • Icons_aif_scalable_dc.mk: Makefile used to create the application's -icon from the *.svg file in the /gfx folder.

            • +

          • HelloWorld.mmp: Project-definition file. This specifies +how to build an executable (in this case HelloWorld.exe) in a platform- and compiler-independent way. It contains information +such as resource files to be compiled, source files to include when +compiling, and the libraries to include when linking.

            • +

          • Icons_aif_scalable_dc.mk: Makefile used to create the +application's icon from the *.svg file in the /gfx folder.

          \src

            -

          • HelloWorldApplication.cpp: This file contains the entry point -for the EXE file (E32Main()) as well as the implementation -of the Application class (which provides some basic functionality for the -GUI framework). Normally this is "boilerplate" code and you do not need to -make any changes.

            • -

          • HelloWorldDocument.cpp: This class is supposed to take care -of the persistent data model of your application and therefore provides some -functions to load and save .ini files. This mechanism is -disabled by default - for most applications you may treat this as "boilerplate" -code.

            • -

          • HelloWorldAppUi.cpp: This is the main controller of your application. -It contains the logic for handling application-wide events (so you don’t have -to handle, for example, the exit event in every view). It owns all the views -that you use.

            • -

          • HelloWorldContainerView.cpp: This is a kind of controller, which -is responsible for handling events and the UI elements of the currently visible -view. It’s not visible itself, but owns and manages the Container (below), -which corresponds to the view in the traditional model view controller pattern.

            • -

          • HelloWorldContainer.cpp: Contains the UI elements that should -be displayed by the view. Therefore, the ContainerView and the Container usually -have a very strong relationship.

            • +

          • HelloWorldApplication.cpp: This file contains the entry +point for the EXE file (E32Main()) as well as the +implementation of the Application class (which provides some basic +functionality for the GUI framework). Normally this is "boilerplate" +code and you do not need to make any changes.

            • +

          • HelloWorldDocument.cpp: This class is supposed to take +care of the persistent data model of your application and therefore +provides some functions to load and save .ini files. +This mechanism is disabled by default - for most applications you +may treat this as "boilerplate" code.

            • +

          • HelloWorldAppUi.cpp: This is the main controller of +your application. It contains the logic for handling application-wide +events (so you don’t have to handle, for example, the exit event in +every view). It owns all the views that you use.

            • +

          • HelloWorldContainerView.cpp: This is a kind of controller, +which is responsible for handling events and the UI elements of the +currently visible view. It’s not visible itself, but owns and manages +the Container (below), which corresponds to the view in the +traditional model view controller pattern.

            • +

          • HelloWorldContainer.cpp: Contains the UI elements that +should be displayed by the view. Therefore, the ContainerView and +the Container usually have a very strong relationship.

          During start-up, one class instance creates the next:

          - +

          \inc

            -

          • HelloWorldApplication.h, HelloWorldDocument.h, HelloWorldAppUi.h, HelloWorldContainerView.h, HelloWorldContainer.h: Header files corresponding to each of the main source files above.

            • -

          • HelloWorld.hrh: UIDs/identifiers for UI elements including views. -These are shared between the resource file definitions for UI elements and -the source code command handlers.

            • +

          • HelloWorldApplication.h, HelloWorldDocument.h, HelloWorldAppUi.h, HelloWorldContainerView.h, HelloWorldContainer.h: Header files corresponding to each of +the main source files above.

            • +

          • HelloWorld.hrh: UIDs/identifiers for UI elements including +views. These are shared between the resource file definitions for +UI elements and the source code command handlers.

          • HelloWorld.pan: Panic code and method definitions.

          \data

            -

          • HelloWorld_reg.rss: Contains registration information about -the application, such as its title.

            • -

          • HelloWorld.rss: Main resource file. Contains additional information -about the application, as well as user interface and text resource definitions. -

            • -

          • HelloWorld.loc, HelloWorld.l01: Localization files. Strings -used by UI are defined in separate localization resource files. Each file -has the format .lxx, where xx is a language specific -numeric file extension - e.g. UK English is ‘01’, French ‘02’ and German ‘03’. -The .loc file is a kind of junction that #includes the -language specific files. The languages are compiled into separate resource -files (extension .rxx; the resource file for the current -language is loaded by the UI framework at runtime

            • +

          • HelloWorld_reg.rss: Contains registration information +about the application, such as its title.

            • +

          • HelloWorld.rss: Main resource file. Contains additional +information about the application, as well as user interface and text +resource definitions.

            • +

          • HelloWorld.loc, HelloWorld.l01: Localization +files. Strings used by UI are defined in separate localization resource +files. Each file has the format .lxx, where xx is a language specific numeric file extension - e.g. UK English +is ‘01’, French ‘02’ and German ‘03’. The .loc file +is a kind of junction that #includes the language +specific files. The languages are compiled into separate resource +files (extension .rxx; the resource file for the +current language is loaded by the UI framework at runtime

          \gfx

            -

          • list_icon.bmp, list_icon_mask.bmp, mark_icon.bmp, mark_icon_mask.bmp: -Bitmap and bitmap masks. These are compiled into the MultiBitMap (mbm) -format for display in the application.

            • -

          • qgn_menu_HelloWorld.svg: SVG-T image that gets compiled into -the HelloWorld_aif.mif MultiImageFile (mif) -used for the application icon.

            • +

          • list_icon.bmp, list_icon_mask.bmp, mark_icon.bmp, mark_icon_mask.bmp: Bitmap and bitmap masks. These are compiled +into the MultiBitMap (mbm) format for display in +the application.

            • +

          • qgn_menu_HelloWorld.svg: SVG-T image that gets compiled +into the HelloWorld_aif.mif MultiImageFile (mif) used for the application icon.

          \sis

            -

          • HelloWorld.pkg: Defines the contents that should be packaged -into the installable .sis file for the device. This includes -the executable as well as all resources required by the application (graphics -and so on).

            • -

          • HelloWorld.sis: Compressed and self-contained installation file -for the device. Compiled based on the package file.

            • -

          • HelloWorld.sisx: .sis file which has been signed -with a certificate (in this case self-signed).

            • +

          • HelloWorld.pkg: Defines the contents that should be +packaged into the installable .sis file for the device. +This includes the executable as well as all resources required by +the application (graphics and so on).

            • +

          • HelloWorld.sis: Compressed and self-contained installation +file for the device. Compiled based on the package file.

            • +

          • HelloWorld.sisx: .sis file which has +been signed with a certificate (in this case self-signed).

        Extending -Hello World – Drawing

        To make our application a little bit more -interactive, we are going to implement a simple paint tool, allowing the user -to draw lines by touching the screen.

        We could draw the lines directly -on the screen, but then everything would get lost when something caused our -application to redraw the screen – for example, a telephone call that came -through while our application was running. Therefore, we have to draw the -lines to a bitmap, which is simply copied to the screen whenever required. -

        Another solution (more difficult but also more flexible!) would be -to store all lines in a list and to iterate over the list each time the application +Hello World – Drawing

        To make our application a little bit +more interactive, we are going to implement a simple paint tool, allowing +the user to draw lines by touching the screen.

        We could +draw the lines directly on the screen, but then everything would get +lost when something caused our application to redraw the screen – +for example, a telephone call that came through while our application +was running. Therefore, we have to draw the lines to a bitmap, which +is simply copied to the screen whenever required.

        Another +solution (more difficult but also more flexible!) would be to store +all lines in a list and to iterate over the list each time the application needs to draw the contents of the screen.

        -
        Using the -SDK Documentation

        The class that can handle bitmap data is called CFbsBitmap. -Let’s take a look at the documentation for this class to find out more about -the required header files, libraries and available methods.

        Search the -online documentation for the class you're interested in, in this case CFbsBitmap. CFbsBitmap -in Os Font_and_Bitmap_Server should be (one of the) first topics you -find.

        If you're working offline you can also search for documentation -in the SDK. Start menu: Start - S60 Developer Tools - 5th Edition -SDK, v1.0 - SDK Documentation

        Right at the top of the -reference page you will see that the header file we need to use is FBS.H and -the library we need to link against is called fbscli.lib.

        - -

        This class is capable of storing a bitmap. It's also possible to -get direct access to the bitmap data. However for more convenient methods -of drawing we will work through a drawing device and context.

        To -find out more about bitmaps, contexts and drawing functions, Search for ‘bitmaps’ in the documentation, and go to the page Bitmaps -in Using Bitmaps, or Using Bitmaps in Using Graphics Device Interfaces. - Symbian provides several different device and context classes. For our -application we’re going to use CFbsBitmapDevice (header file: bitdev.h, -library: bitgdi.lib) and CFbsBitGc (header -file: bitstd.h, library: bitgdi.lib).

        -
        Adding Libraries -To a Project

        In the previous step, we determined that we need two -libraries in order to use all three bitmap-related classes: fbscli.lib and bitgdi.lib. -To add them to our project, open the HelloWorld.mmp project -file (in the /group/ folder if you’re using the Project -Explorer window). Switch to the Libraries tab. At the top of -this page, you will see a list of included libraries. fbscli.lib is -already in the list, so we don’t need to add it. However bitgdi.lib is -missing.

        There are more libraries in the list than are used by our -project (added by the wizard!). These cause no harm so we choose not to remove -them.

        Click on the Add button. Search for bitgdi.lib in -the list and add it to the Libraries list.

        - -

        When you’re finished, make sure that both libraries are in the Libraries list. -

        When you compile your application again, Carbide.c++ will detect -the changes in the .mmp file and ask you what to do. Click on Compile and -Link to update the project with the changes we have made to the .mmp file. - +

        Using +the SDK Documentation

        The class that can handle bitmap data +is called CFbsBitmap. Let’s take a look at the documentation +for this class to find out more about the required header files, libraries +and available methods.

        Search the online documentation for the class you're interested +in, in this case CFbsBitmap. CFbsBitmap in Os Font_and_Bitmap_Server should +be (one of the) first topics you find.

        If you're +working offline you can also search for documentation in the SDK. Start menu: Start - S60 Developer Tools - 5th Edition SDK, +v1.0 - SDK Documentation

        Right at the top of the +reference page you will see that the header file we need to use is FBS.H and the library we need to link against is called fbscli.lib.

        + +

        This class is capable of storing a bitmap. It's also possible +to get direct access to the bitmap data. However for more convenient +methods of drawing we will work through a drawing device and context. +

        To find out more about bitmaps, contexts and drawing functions, Search for ‘bitmaps’ in the documentation, +and go to the page Bitmaps in Using Bitmaps, or Using Bitmaps +in Using Graphics Device Interfaces. Symbian provides several +different device and context classes. For our application we’re going +to use CFbsBitmapDevice (header file: bitdev.h, library: bitgdi.lib) and CFbsBitGc (header file: bitstd.h, library: bitgdi.lib).

        +
        Adding +Libraries To a Project

        In the previous step, we determined +that we need two libraries in order to use all three bitmap-related +classes: fbscli.lib and bitgdi.lib. To add them to our project, open the HelloWorld.mmp project file (in the /group/ folder if you’re using +the Project Explorer window). Switch to the Libraries tab. At the top of this page, you will see a list of included +libraries. fbscli.lib is already in the list, so +we don’t need to add it. However bitgdi.lib is missing.

        There are more libraries in the list than are used by our project +(added by the wizard!). These cause no harm so we choose not to remove +them.

        Click on the Add button. Search for bitgdi.lib in the list and add it to the Libraries list.

        + +

        When you’re finished, make sure that both libraries are in +the Libraries list.

        When you compile your application +again, Carbide.c++ will detect the changes in the .mmp file and ask +you what to do. Click on Compile and Link to update the project +with the changes we have made to the .mmp file. +

        -
        Creating Bitmaps

        Now -the libraries have been added, we can use the bitmap classes in our project. -Open the file HelloWorldContainer.h and add the following -include statements:

        #include <fbs.h> +
        Creating +Bitmaps

        Now the libraries have been added, we can use the +bitmap classes in our project. Open the file HelloWorldContainer.h and add the following include statements:

        #include <fbs.h> #include <bitdev.h> #include <bitstd.h> -

        We also need to store the bitmap objects as instance (member) -variables. Add the following definitions to a private section of the CHelloWorldContainer class. -Be careful not to write anything into areas managed by the UI designer, because -your changes could be overwritten. These areas are marked by comments. -

        private: +

        We also need to store the bitmap objects as instance +(member) variables. Add the following definitions to a private section +of the CHelloWorldContainer class. Be careful not +to write anything into areas managed by the UI designer, because your +changes could be overwritten. These areas are marked by comments. +

        private: CFbsBitmap* iBitmap; CFbsBitmapDevice* iBmpDevice; -CFbsBitGc* iBmpGc;

        Symbian C++ uses some naming conventions. Instance variables should have a lowercase i at -the beginning of the variable name (iBitmap). Arguments should -be marked by an a (aBitmap). Normal local variables that -you create inside a function do not need any prefix. That way, you instantly -know where the variable is coming from – this is very important when deleting -objects. Next, we want to create the bitmap. Define and implement a new -method:

        void CHelloWorldContainer::CreateBitmapsL()

        Let’s -go line by line through the required code for this method: First, we have -to make sure that any previous objects are deleted if they already exist. -This would be required (for example) if the running application needs to re-create -the bitmap because the screen layout changes. You don’t need to add an if -statement to check if the pointer is NULL beforehand – the C++ delete statement -only deletes the object if the pointer is not NULL. You do however need to -ensure that the objects are set to NULL after deletion to avoid possible "double -deletion" in the destructor.

        delete iBitmap; iBitmap = NULL; +CFbsBitGc* iBmpGc;

        Symbian C++ uses some naming conventions. Instance variables should +have a lowercase i at the beginning of the variable +name (iBitmap). Arguments should be marked by an +a (aBitmap). Normal local variables that you create +inside a function do not need any prefix. That way, you instantly +know where the variable is coming from – this is very important when +deleting objects. Next, we want to create the bitmap. Define and +implement a new method:

        void CHelloWorldContainer::CreateBitmapsL()

        Let’s go line by line through the required code for this method: + First, we have to make sure that any previous objects are deleted +if they already exist. This would be required (for example) if the +running application needs to re-create the bitmap because the screen +layout changes. You don’t need to add an if statement to check if +the pointer is NULL beforehand – the C++ delete statement +only deletes the object if the pointer is not NULL. You do however +need to ensure that the objects are set to NULL after deletion to +avoid possible "double deletion" in the destructor.

        delete iBitmap; iBitmap = NULL; delete iBmpDevice; iBmpDevice = NULL; -delete iBmpGc; iBmpGc = NULL;

        This following line of code should -look familiar – it simply creates an instance of the CFbsBitmap class: -

        iBitmap = new (ELeave) CFbsBitmap();

        The -(ELeave) parameter is Symbian C++ specific. This causes a leave (the -Symbian C++ equivalent of standard exceptions) if allocating the object fails -– for example, because there is not enough free memory. With the (ELeave), -you don’t have to manually check if the pointer is actually pointing to a -valid object after creating the object instance. You can find out more about -leaves in Fundamentals -of C++.

        We do not handle the potential leave here; that’s -why the method name (CreateBitmapL()) has a trailing L to -show that it can also leave. More on this topic in a moment.

        Now, -it’s time to let the CFbsBitmap class allocate the memory -for the bitmap it is going to manage. The available drawing size for our container -can be queried by the method Size() from its base class. EColor16MU specifies -the color depth – in this case, it’s a true color display mode with 32 bits -per pixel; the top byte is unused. The color mode EColor16MA would -use the top byte for the alpha channel, several other modes are available -as well.

        iBitmap->Create(Size(), EColor16MU); -

        The next line creates a graphics device based on the bitmap. A graphics -device represents the medium being drawn to and is needed to create a graphics -context. The use of a NewL() method is common in Symbian -C++; it is a static factory function which returns a fully constructed object -of the desired type.

        iBmpDevice = CFbsBitmapDevice::NewL(iBitmap); -

        A graphics context provides a large number of drawing operations, -along with state settings defining how the drawing is performed. The bitmap -graphics context used here is a specialization of the generic graphics context -and adds some methods that can be used for bitmaps only – such as clearing -and copying rectangular areas.

        iBmpDevice->CreateContext(iBmpGc); -

        Whenever you create objects, it’s best to think about where and when -they are going to be deleted right away. Memory leaks are a serious issue -on a mobile device where no virtual memory is available and the main memory -is limited to 30-80 MB. Therefore, go to the destructor of CHelloWorldContainer and -add the required statements for deleting the three objects:

        delete iBmpGc; +delete iBmpGc; iBmpGc = NULL;

        This following line of +code should look familiar – it simply creates an instance of the CFbsBitmap class:

        iBitmap = new (ELeave) +CFbsBitmap();

        The (ELeave) +parameter is Symbian C++ specific. This causes a leave (the Symbian C++ equivalent of standard +exceptions) if allocating the object fails – for example, because +there is not enough free memory. With the (ELeave), you don’t have to manually check if the pointer is actually pointing +to a valid object after creating the object instance. You can find +out more about leaves in Fundamentals of C++.

        We do not handle +the potential leave here; that’s why the method name (CreateBitmapL()) has a trailing L to show that it can also leave. More on this topic +in a moment.

        Now, it’s time to let the CFbsBitmap class allocate the memory for the bitmap it is going to manage. +The available drawing size for our container can be queried by the +method Size() from its base class. EColor16MU specifies the color depth – in this case, it’s a true color display +mode with 32 bits per pixel; the top byte is unused. The color mode EColor16MA would use the top byte for the alpha channel, +several other modes are available as well.

        iBitmap->Create(Size(), +EColor16MU);

        The next line creates a graphics device +based on the bitmap. A graphics device represents the medium being +drawn to and is needed to create a graphics context. The use of a NewL() method is common in Symbian C++; it is a static factory +function which returns a fully constructed object of the desired type. +

        iBmpDevice = CFbsBitmapDevice::NewL(iBitmap);

        A graphics context provides a large number of drawing +operations, along with state settings defining how the drawing is +performed. The bitmap graphics context used here is a specialization +of the generic graphics context and adds some methods that can be +used for bitmaps only – such as clearing and copying rectangular areas. +

        iBmpDevice->CreateContext(iBmpGc);

        Whenever you create objects, it’s best to think about where and +when they are going to be deleted right away. Memory leaks are a serious +issue on a mobile device where no virtual memory is available and +the main memory is limited to 30-80 MB. Therefore, go to the destructor +of CHelloWorldContainer and add the required statements +for deleting the three objects:

        delete iBmpGc; delete iBmpDevice; -delete iBitmap;

        The next step addresses the remaining -question: where to call the CreateBitmapsL() method. Of course, -you could do this from the construction methods of the class. But what if, -while your application is running, the user physically turns the phone, causing -it to switch from portrait to landscape mode? Because the bitmap was created -with the portrait size in mind, the user would no longer be able to use the -full screen for drawing.

        Therefore, we have to react to events that -inform us when the screen size is changed. In those situations, SizeChanged() is -executed. When the container is first constructed, its size changes as well. -Because of this, we can simply call our CreateBitmapsL() method -from within SizeChanged():

        void CHelloWorldContainer::SizeChanged() +delete iBitmap;

        The next step addresses the +remaining question: where to call the CreateBitmapsL() method. Of course, you could do this from the construction methods +of the class. But what if, while your application is running, the +user physically turns the phone, causing it to switch from portrait +to landscape mode? Because the bitmap was created with the portrait +size in mind, the user would no longer be able to use the full screen +for drawing.

        Therefore, we have to react to events that +inform us when the screen size is changed. In those situations, SizeChanged() is executed. When the container is first constructed, +its size changes as well. Because of this, we can simply call our CreateBitmapsL() method from within SizeChanged():

        void CHelloWorldContainer::SizeChanged() { CCoeControl::SizeChanged(); LayoutControls(); @@ -250,70 +237,62 @@ { TRAPD(err, CreateBitmapsL()); } - }

        In the source code above, an additional check ensures -that the bitmap is only re-created if the size available for the container -is really different to the existing bitmap size – the SizeChanged() method -is also called, for example, when the option menu obscures part of our view. -This does not affect the available space for our drawing area and therefore -should not lead to re-creating the bitmap.

        But what is the TRAPD() statement -doing here? Let’s use this to take a closer look at the concept of leaves.

        Leaves

        When -programming using Symbian C++, an L is appended to the name of methods that -can leave (usually because it contains other methods that can leave and does -not choose to "TRAP" them). Note: this is a helpful convention, but is not -checked or required by the compiler.

        Our CreateBitmapsL() method -contains two methods that can leave: the (ELeave) parameter -causes a leave if there is not enough memory to allocate the object. The NewL() method -from the graphics device also has a trailing L – meaning -that this method can also leave. We did not catch any (all) of those leaves -in the CreateBitmapsL() method so it was named with a trailing L. -

        Any leaves are passed up in the call stack until caught by a TRAPD macro. -The SizeChanged() method traps any leaves from CreateBitmapsL() and -consequently does not need to have a trailing L. -

        The error code of the leave is stored in the err variable, which -is declared as a normal integer by this macro. It would be a good idea to -take a look at the contents of this variable and to handle errors instead -of ignoring them as we’re doing here. But for the sake of simplicity, we do -not handle any errors that might occur in this situation.

        Tip

        A -good way to automatically check your code for potential problems is to use -the CodeScanner tool that comes with Carbide.c++. It is a static code-analysis -tool looking at Symbian coding rules and standards. Find out more at: http://carbidehelp.nokia.com/help/topic/com.nokia.carbide.cpp.codescanner/html/codescanner.htm

        -
        Handling Touch -Events

        Before we start handling the touch events, we need one more -instance variable in our code. To draw a line from one touch position to the -next, it’s necessary to save the first position. Therefore, add the following -private instance variable to CHelloWorldContainer: TPoint iLastPos;

        TPoint is -a convenience class that stores two integers that can be used as co-ordinates. -Additionally, it provides some methods to modify the point. We do not need -to initialize the variable in the constructor of the CHelloWorldContainer class -– the container class is indirectly derived from the class CBase, -which automatically zero-initializes all member variables. Touch events -are delivered to the container class, which is responsible for managing the -visible UI content in the main pane of your application. To handle the events -ourselves, we have to override the following method in CHelloWorldContainer:

        void -CHelloWorldContainer::HandlePointerEventL(const TPointerEvent& aPointerEvent)

        Define -this method in the header file (can be private or protected) and add its implementation -in the .cpp file. The information about the new event -is sent through the argument aPointerEvent. We are interested -in the up event for the first button (there is only one in current touch devices; -you can’t click with a right button as you would with a mouse). Whenever the -user releases the stylus or finger from the touch screen, we want to draw -a line to this position. Put the following code into this if statement: if (aPointerEvent.iType == TPointerEvent::EButton1Up) + }

        In the source code above, an additional +check ensures that the bitmap is only re-created if the size available +for the container is really different to the existing bitmap size +– the SizeChanged() method is also called, for example, +when the option menu obscures part of our view. This does not affect +the available space for our drawing area and therefore should not +lead to re-creating the bitmap.

        But what is the TRAPD() statement doing here? Let’s use this to take a closer +look at the concept of leaves.

        Leaves

        When +programming using Symbian C++, an L is appended to the name of methods +that can leave (usually because it contains other methods that can +leave and does not choose to "TRAP" them). Note: this is a helpful +convention, but is not checked or required by the compiler.

        Our CreateBitmapsL() method contains two methods +that can leave: the (ELeave) parameter causes a leave +if there is not enough memory to allocate the object. The NewL() method from the graphics device also has a trailing L – meaning that this method can also leave. We did not +catch any (all) of those leaves in the CreateBitmapsL() method so it was named with a trailing L.

        Any leaves are passed up in the call stack until caught by a TRAPD macro. The SizeChanged() method traps +any leaves from CreateBitmapsL() and consequently +does not need to have a trailing L.

        The error code of the leave is stored in the err variable, which +is declared as a normal integer by this macro. It would be a good +idea to take a look at the contents of this variable and to handle +errors instead of ignoring them as we’re doing here. But for the sake +of simplicity, we do not handle any errors that might occur in this +situation.

        Tip

        A good way to automatically +check your code for potential problems is to use the CodeScanner tool that comes with Carbide.c++. It is a static code-analysis tool +looking at Symbian coding rules and standards. Find out more at: http://carbidehelp.nokia.com/help/topic/com.nokia.carbide.cpp.codescanner/html/codescanner.htm

        +
        Handling +Touch Events

        Before we start handling the touch events, +we need one more instance variable in our code. To draw a line from +one touch position to the next, it’s necessary to save the first position. +Therefore, add the following private instance variable to CHelloWorldContainer: TPoint iLastPos;

        TPoint is a convenience class that stores +two integers that can be used as co-ordinates. Additionally, it provides +some methods to modify the point. We do not need to initialize the +variable in the constructor of the CHelloWorldContainer class – the container class is indirectly derived from the class CBase, which automatically zero-initializes all member variables. + Touch events are delivered to the container class, which is responsible +for managing the visible UI content in the main pane of your application. +To handle the events ourselves, we have to override the following +method in CHelloWorldContainer:

        void +CHelloWorldContainer::HandlePointerEventL(const TPointerEvent& +aPointerEvent)

        Define this method in the header file +(can be private or protected) and add its implementation in the .cpp file. The information about the new event is sent +through the argument aPointerEvent. We are interested +in the up event for the first button (there is only one in current +touch devices; you can’t click with a right button as you would with +a mouse). Whenever the user releases the stylus or finger from the +touch screen, we want to draw a line to this position. Put the following +code into this if statement: if (aPointerEvent.iType == TPointerEvent::EButton1Up) { - }

        Drawing the line itself is rather simple. First, define -the color and style that should be used for drawing, then call the function -for drawing the line. Note that the settings concerning the color and style -stay active until they are changed again in this graphics context – you do -not need to set them every time when executing consecutive drawing operations.

        iBmpGc->SetPenColor(KRgbRed); + }

        Drawing the line itself is rather simple. First, +define the color and style that should be used for drawing, then call +the function for drawing the line. Note that the settings concerning +the color and style stay active until they are changed again in this +graphics context – you do not need to set them every time when executing +consecutive drawing operations.

        iBmpGc->SetPenColor(KRgbRed); iBmpGc->SetPenSize(TSize(2,2)); -iBmpGc->DrawLine(iLastPos, aPointerEvent.iPosition);

        Next, we -have to save the new position, because it will be required as the starting -point for the next line.

        iLastPos = aPointerEvent.iPosition;

        Finally, -issue a request to the framework to redraw the screen. Otherwise, the user -won’t see the new line!

        DrawDeferred();

        At the end -of the method, also call the HandlePointerEventL() method -of the base class (the container is derived from CCoeControl, -because it is a normal UI control by itself):

        CCoeControl::HandlePointerEventL(aPointerEvent);

        To -sum it up, this is the final code for the HandlePointerEvent() method:

        void CHelloWorldContainer::HandlePointerEventL(const TPointerEvent& aPointerEvent) +iBmpGc->DrawLine(iLastPos, aPointerEvent.iPosition);

        Next, we have to save the new position, because it will be required +as the starting point for the next line.

        iLastPos = aPointerEvent.iPosition;

        Finally, issue a request to the framework to redraw the screen. +Otherwise, the user won’t see the new line!

        DrawDeferred();

        At the end of the method, also call the HandlePointerEventL() method of the base class (the container is derived from CCoeControl, because it is a normal UI control by itself):

        CCoeControl::HandlePointerEventL(aPointerEvent);

        To sum it up, this is the final code for the HandlePointerEvent() method:

        void CHelloWorldContainer::HandlePointerEventL(const TPointerEvent& aPointerEvent) { if (aPointerEvent.iType == TPointerEvent::EButton1Up) { @@ -324,132 +303,127 @@ DrawDeferred(); } CCoeControl::HandlePointerEventL(aPointerEvent); - }

        We’ve already added all the code required for drawing -to the bitmap, but this bitmap still has to be transferred to the screen. -The CHelloWorldContainer::Draw() method is called when the -system wants the contents of the container to be redrawn. Therefore, we need -to add the following line of code to the end of the Draw() method, -which copies the bitmap to the top left of the graphics context of the screen:

        gc.BitBlt(TPoint(0, -0), iBitmap);

        Now compile the project. It should already work – -you can draw red lines by just clicking inside the main pane of the emulator!

        - + }

        We’ve already added all the code required for +drawing to the bitmap, but this bitmap still has to be transferred +to the screen. The CHelloWorldContainer::Draw() method +is called when the system wants the contents of the container to be +redrawn. Therefore, we need to add the following line of code to the +end of the Draw() method, which copies the bitmap +to the top left of the graphics context of the screen:

        gc.BitBlt(TPoint(0, 0), iBitmap);

        Now compile the project. +It should already work – you can draw red lines by just clicking inside +the main pane of the emulator!

        +
        Defining -a Menu

        The application would be improved if the user could clear -the drawing during use, rather than having to restart it. This section shows -how you add and handle menu items to provide this functionality, and to exit -the application Open the HelloWorldContainer.uidesign document. -You can find it in the root folder of your project in the Project Explorer or -in the UI Designs folder of the Symbian Project Navigator.

        Click -on the Options menu item below the UI design to reveal the menu. As -indicated, you simply need to click on the empty menu item and start typing.

        - -

        Add two menu items – Clear (for clearing the image) and Exit (for -closing the application).

        Then click once on the Exit menu item -to select it. Go to the Behavior group of the Properties window -and change the command ID to EAknCmdExit (this is available -in the drop-down list). This command will also be sent to your application -if the operating system wants to shut it down, for example, when the phone -does not have enough memory left. Therefore, it is necessary that every application -always responds to this event and instantly shuts the application down. It -is already handled by the basic application that the Carbide.c++ wizard generated -for you; you don’t need to implement the command handling for this event yourself.

        - -

        If you try your application now, you will see that the Exit menu -item already works.

        Tip

        When testing the application, -always quit your application using the Exit command (rather than just -closing the emulator). The application environment will then automatically -check for memory leaks. If you just shut down the emulator you may not discover -the leak until much later, making it a lot more difficult to find the cause.

        -
        Clearing the -Drawing

        Whenever the Clear menu item is selected the view -class method CHelloWorldContainerView::HandleCommandL() is -called with the command ID of the menu item as a parameter.

        If we -want to handle the menu item, the UI designer can create the necessary code -for us. Right-click on the menu item and choose Handle ‘selected’ Event. -The UI designer will ask you to save the design – choose Yes. The code -will then be generated and you will jump into the code view to a new method -called HandleClearMenuItemSelectedL() – a more convenient -place to put your command-handling code than directly in a big HandleCommandL() method -that receives all commands. The auto-generated source code therefore calls -the new extra method from within HandleCommandL() (take a +a Menu

        The application would be improved if the user could +clear the drawing during use, rather than having to restart it. This +section shows how you add and handle menu items to provide this functionality, +and to exit the application Open the HelloWorldContainer.uidesign document. You can find it in the root folder of your project in +the Project Explorer or in the UI Designs folder of +the Symbian Project Navigator.

        Click on the Options menu item below the UI design to reveal the menu. As indicated, +you simply need to click on the empty menu item and start typing.

        + +

        Add two menu items – Clear (for clearing the image) +and Exit (for closing the application).

        Then click +once on the Exit menu item to select it. Go to the Behavior group of the Properties window and change the command ID +to EAknCmdExit (this is available in the drop-down +list). This command will also be sent to your application if the operating +system wants to shut it down, for example, when the phone does not +have enough memory left. Therefore, it is necessary that every application +always responds to this event and instantly shuts the application +down. It is already handled by the basic application that the Carbide.c++ +wizard generated for you; you don’t need to implement the command +handling for this event yourself.

        + +

        If you try your application now, you will see that the Exit +menu item already works.

        Tip

        When testing +the application, always quit your application using the Exit command (rather than just closing the emulator). The application +environment will then automatically check for memory leaks. If you +just shut down the emulator you may not discover the leak until much +later, making it a lot more difficult to find the cause.

        +
        Clearing +the Drawing

        Whenever the Clear menu item is selected +the view class method CHelloWorldContainerView::HandleCommandL() is called with the command ID of the menu item as a parameter. +

        If we want to handle the menu item, the UI designer can create +the necessary code for us. Right-click on the menu item and choose Handle ‘selected’ Event. The UI designer will ask you to save +the design – choose Yes. The code will then be generated and +you will jump into the code view to a new method called HandleClearMenuItemSelectedL() – a more convenient place to put your command-handling code than +directly in a big HandleCommandL() method that receives +all commands. The auto-generated source code therefore calls the new +extra method from within HandleCommandL() (take a look at that method to see what really happens).

        - -

        Now, we only need to tell the container that it should clear its -bitmap buffer. To do this, create a new public method in the container:

        void CHelloWorldContainer::ClearDrawing() + +

        Now, we only need to tell the container that it should clear +its bitmap buffer. To do this, create a new public method in the container:

        void CHelloWorldContainer::ClearDrawing() { iBmpGc->Clear(); DrawDeferred(); - }

        Now, call this method from the menu item handler method. -As explained in the section about the application architecture, the view class -(CHelloWorldContainerView) is the controller and owner for/of -the container class (CHelloWorldContainer). Therefore, this -class has a pointer to the container as an instance variable, which you can -use to clear the drawing.

        TBool CHelloWorldContainerView::HandleClearMenuItemSelectedL(TInt aCommand) + }

        Now, call this method from the menu item handler +method. As explained in the section about the application architecture, +the view class (CHelloWorldContainerView) is the +controller and owner for/of the container class (CHelloWorldContainer). Therefore, this class has a pointer to the container as an instance +variable, which you can use to clear the drawing.

        TBool CHelloWorldContainerView::HandleClearMenuItemSelectedL(TInt aCommand) { iHelloWorldContainer->ClearDrawing(); return ETrue; - }

        The menu command should now clear the image.

        Congratulations, -you have completed the tutorial and have created your own small mobile painting -application!

        -
        Further Exercises

        As -an exercise, it’s a good idea to extend the application by yourself – for -example, you could add some menu items that allow the end user to change the -color of the pen.

        Tip

        It’s a good idea to learn -keyboard shortcuts as early as possible, because they can significantly increase -the efficiency of your work. For example, you can press Ctrl + B to -build the project, instead of using the icon or the menu commands. Also very -helpful: Ctrl + Shift + F automatically formats and indents your code. -You can get a full list of commands by pressing Ctrl + 3. A hot keys -list appears when you press Ctrl + Shift + L.

        Importing -Other Examples

        The S60 SDK itself installs many examples; additional -applications can be downloaded from the developer.symbian.org and Forum Nokia -(see the Related Info section for more information). To import ready-made + }

        The menu command should now clear the image.

        Congratulations, you have completed the tutorial and have created +your own small mobile painting application!

        +
        Further +Exercises

        As an exercise, it’s a good idea to extend the +application by yourself – for example, you could add some menu items +that allow the end user to change the color of the pen.

        Tip

        It’s a good idea to learn keyboard shortcuts +as early as possible, because they can significantly increase the +efficiency of your work. For example, you can press Ctrl + B to build the project, instead of using the icon or the menu commands. +Also very helpful: Ctrl + Shift + F automatically formats and +indents your code. You can get a full list of commands by pressing Ctrl + 3. A hot keys list appears when you press Ctrl + Shift ++ L.

        Importing Other Examples

        The S60 +SDK itself installs many examples; additional applications can be +downloaded from the developer.symbian.org and Forum Nokia (see the +Related Info section for more information). To import ready-made applications in Carbide.c++, go to File | Import. In the following dialog, select Symbian OS Bld.inf file and click Next.

        - -

        Now, click Browse and navigate to the bld.inf file -of the project you want to import. It’s usually stored in the /group/ subfolder -of the project.

        - -

        In the following step, select which SDKs you would like to use. The -same considerations as those explained when creating your Hello World application -apply.

        - -

        You can usually accept the default values for the next step and let -the wizard import everything.

        In the last step, you have to define -the Project Properties. In most cases, you can leave the default values.

        - -

        Afterwards, the project is imported and you can start working. The -project contents will not be copied to the current Carbide.c++ workspace, -so you will work directly on the original directory and the original files. -Copy the project to a different directory first if you want to keep the original -project or example in its original state – for example, into the workspace -directory.

        Troubleshooting: If importing the -project fails, take special care of the last step of the import process: the -root directory should be set correctly to the root directory of the project -and not one level above it. Also, the project name should be the same as the -last part of the root directory. From time to time, the default values are -not configured properly, causing problems in the import process.

        Warning

        Do -not use the standard (Eclipse) project import! The reason is that this import -method would also import all build configuration settings, including references -to installed SDKs and paths on the original system. Therefore, if you import -a project from somebody else but don’t have the SDK installed in exactly the -same directory, the build configurations will no longer work. The bld.inf import -method recreates the SDK bindings and only imports the real contents of the -project.

        -
        Summary

        This -part of the tutorial has shown how we can extend the basic skeleton from the Symbian C++ Quick Start to -create a small paint application. The tutorial explains the application framework, -including how you define menus, how to handle touch-screen events, drawing -to the screen etc.

        -
        Related Info
          -

        • Symbian C++ -Quick Start

          • -

        • Getting -Started with Debugging on the Device

          • -

        • File: -HelloSymbianWorld Example Code.zip (code example associated with this -article)

          • + +

          Now, click Browse and navigate to the bld.inf file of the project you want to import. It’s usually +stored in the /group/ subfolder of the project.

          + +

          In the following step, select which SDKs you would like to +use. The same considerations as those explained when creating your +Hello World application apply.

          + +

          You can usually accept the default values for the next step +and let the wizard import everything.

          In the last step, +you have to define the Project Properties. In most cases, you +can leave the default values.

          + +

          Afterwards, the project is imported and you can start working. +The project contents will not be copied to the current Carbide.c++ +workspace, so you will work directly on the original directory and +the original files. Copy the project to a different directory first +if you want to keep the original project or example in its original +state – for example, into the workspace directory.

          Troubleshooting: If importing the project fails, take special +care of the last step of the import process: the root directory should +be set correctly to the root directory of the project and not one +level above it. Also, the project name should be the same as the last +part of the root directory. From time to time, the default values +are not configured properly, causing problems in the import process.

          Warning

          Do not use the standard (Eclipse) +project import! The reason is that this import method would also import +all build configuration settings, including references to installed +SDKs and paths on the original system. Therefore, if you import a +project from somebody else but don’t have the SDK installed in exactly +the same directory, the build configurations will no longer work. +The bld.inf import method recreates the SDK bindings +and only imports the real contents of the project.

        +
        Summary

        This part of the tutorial has shown how we can extend the basic +skeleton from the Symbian C++ Quick Start to create a small paint application. +The tutorial explains the application framework, including how you +define menus, how to handle touch-screen events, drawing to the screen +etc.

        +
        Related +Info
          +

        • Symbian +C++ Quick Start

          • +

        • Getting Started with Debugging on the Device

          • +

        • File: HelloSymbianWorld Example Code.zip +(code example associated with this article)

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CA7F22E-59D7-4D65-9D6C-735E4E0F0454.dita --- a/Symbian3/SDK/Source/GUID-0CA7F22E-59D7-4D65-9D6C-735E4E0F0454.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0CA7F22E-59D7-4D65-9D6C-735E4E0F0454.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,8 +14,8 @@

        Before setting channel properties, you must open the sensor channel.

         - -Create a TSensrvProperty property + +Create a TSensrvProperty property object for setting the KSensrvPropIdDataRate property using the TSensrvProperty(const TSensrvPropertyId,const TInt,const TInt) constructor. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CA8B17D-92D7-4293-B611-E0DDA05A6579_d0e36090_href.png Binary file Symbian3/SDK/Source/GUID-0CA8B17D-92D7-4293-B611-E0DDA05A6579_d0e36090_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CA8B17D-92D7-4293-B611-E0DDA05A6579_d0e36257_href.png Binary file Symbian3/SDK/Source/GUID-0CA8B17D-92D7-4293-B611-E0DDA05A6579_d0e36257_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CBD2728-DB7E-55FF-929A-E5BF279A1B66.dita --- a/Symbian3/SDK/Source/GUID-0CBD2728-DB7E-55FF-929A-E5BF279A1B66.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0CBD2728-DB7E-55FF-929A-E5BF279A1B66.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,67 +9,57 @@ --> -BIOMessageMgr: -BIO Message manager using the message server +BIOMessageMgr: BIO Message manager using the message server

        The BIO Message manager example comprises two projects BIOMessage.exe and BIOParser.dll. -The BIOMessage.exe example connects to the message server, -creates a BIO message and sends the registered parser DLL and message entry -to BIOParser.dll.

        -
        Download

        Click -on the following link to download the example: Biomsgexample.zip

        Click: browse to view the example code.

        -
        BIOMessage: BIO messaging using the message server

        Description

        This -example code demonstrates BIO messaging using RSendAs and RSendAsMessage and -other supporting classes as mentioned in the Class -Summary below.

        The BIOMessage example -code provides the following functionality:

        Creating a session

        void CBioMessage::Connect();

        Creates -a session with the message server using RSendAs.

        The -generated console output looks like this:

        - +The BIOMessage.exe example connects to the message +server, creates a BIO message and sends the registered parser DLL +and message entry to BIOParser.dll.

        +
        Download

        Click on the following link to download the example: Biomsgexample.zip

        Click: browse to view the example code.

        +
        BIOMessage: +BIO messaging using the message server

        Description

        This example code demonstrates BIO messaging using RSendAs and RSendAsMessage and other +supporting classes as mentioned in the Class Summary below.

        The BIOMessage example code provides the following functionality:

        Creating +a session

        void CBioMessage::Connect();

        Creates a session with the message server using RSendAs.

        The generated console output looks like this:

        +

        Creating a BIO message

        void CBioMessage::Create(RSendAsMessage& aMessage);

        This function does the following:

          -

        • creates a BIO message -of VCard type

          • -

        • sets the message body -text

          • -

        • adds the message recipients -for the message to be sent.

          • +

        • creates a BIO +message of VCard type

          • +

        • sets the message +body text

          • +

        • adds the message +recipients for the message to be sent.

        The generated console output looks like this:

        - -

        Sending the BIO message

        void CBioMessage::Send(RSendAsMessage& aMessage);

        Sends the message to the recipients.

        The generated console output -looks like this:

        - -

        Creating the parser

        CBioParser::NewL(CMsvEntry* aEntry);

        Creates a CBioParser object based on the message entry.

        Parsing -the BIO message

        CBioParser::ParserL();

        This -function does the following:

          -

        • calls ExtractMessageBodyL() to -extract the message body text from CMsvStore, the message -store

          • -

        • finds, loads and maintains -a reference count of client processes for a BIO parser DLL

          • -

        • parses the message body -text.

          • + +

          Sending the BIO message

          void CBioMessage::Send(RSendAsMessage& aMessage);

          Sends the message to the recipients.

          The generated console +output looks like this:

          + +

          Creating the parser

          CBioParser::NewL(CMsvEntry* aEntry);

          Creates a CBioParser object based on the message +entry.

          Parsing the BIO message

          CBioParser::ParserL();

          This function does the following:

            +

          • calls ExtractMessageBodyL() to extract the message body text from CMsvStore, the message store

            • +

          • finds, loads +and maintains a reference count of client processes for a BIO parser +DLL

            • +

          • parses the message +body text.

          The generated console output looks like this:

          - +

          Class Summary

          RSendAs

          RSendAsMessage

          CSendAsMessageTypes

          CSendAsAccounts

          CRegisteredParserDll

          CBIODatabase

          CMsvStore

        -
        BIOParser: BIO message parsing

        Description

        This -example code demonstrates the parsing of the message. CBIOExampleParser is -the wrapper class which uses CBaseScriptParser2 and other -supporting classes mentioned in the Class -Summary below.

        The BIOParser example code -provides the following functionality:

        Creating the parser

        CBIOExampleParser* CBIOExampleParser::NewL(CRegisteredParserDll& aRegisteredParserDll, CMsvEntry& aEntry, RFs& aFs);

        Creates a CBIOExampleParser object based on the registered -parser DLL and the message entry.

        Parsing the BIO message

        void CBIOExampleParser::ParseL();

        Parses -the BIO message.

        Processing the BIO message

        CBIOExampleParser::ProcessL();

        Processes -the parsed data.

        Class -Summary

        CBaseScriptParser2

        -
        Build

        The BIOMessageMgr example -code includes the following project files for building the application: BIOParser.mmp, BIOMessage.mmp and bld.inf.

        The Symbian -build process describes how to build this application.

        In CodeWarrior: -firstly, 'make' the BIOParser.mcp which creates BIOParser.dll and BIOParser.lib in \epoc32\release\winscw\ <build_variant>, then secondly, -make BIOMessage.exe in the same directory. Run BIOMessage.mcp, -which runs BIOMessage.exe thus launching the emulator.

        -
        Usage

        Launch the target. For emulator targets, -run: \epoc32\release\<wins or winscw>\<urel or udeb>\BIOMessage.exe. -If TechView emulator is used, to run the application go to System menu and -click on Open files / programs window. Start the "BIO Messaging Example" application.

        Step -through each phase of the example by pressing the space bar or by tapping -on the window drawn by the example.

        +
        BIOParser: +BIO message parsing

        Description

        This example +code demonstrates the parsing of the message. CBIOExampleParser is the wrapper class which uses CBaseScriptParser2 and other supporting classes mentioned in the Class Summary below.

        The BIOParser example code provides the following functionality:

        Creating +the parser

        CBIOExampleParser* CBIOExampleParser::NewL(CRegisteredParserDll& aRegisteredParserDll, CMsvEntry& aEntry, RFs& aFs);

        Creates a CBIOExampleParser object based on +the registered parser DLL and the message entry.

        Parsing +the BIO message

        void CBIOExampleParser::ParseL();

        Parses the BIO message.

        Processing the BIO message

        CBIOExampleParser::ProcessL();

        Processes the parsed data.

        Class Summary

        CBaseScriptParser2

        +
        Build

        The BIOMessageMgr example code includes +the following project files for building the application: BIOParser.mmp, BIOMessage.mmp and bld.inf.

        The Symbian build process describes how +to build this application.

        In CodeWarrior: +firstly, 'make' the BIOParser.mcp which creates BIOParser.dll and BIOParser.lib in \epoc32\release\winscw\ <build_variant>, then +secondly, make BIOMessage.exe in the same directory. +Run BIOMessage.mcp, which runs BIOMessage.exe thus launching the emulator.

        +
        Usage

        Launch the target. For emulator targets, run: \epoc32\release\<wins +or winscw>\<urel or udeb>\BIOMessage.exe. +If TechView emulator is used, to run the application go to System +menu and click on Open files / programs window. Start the "BIO Messaging +Example" application.

        Step through each phase of the example +by pressing the space bar or by tapping on the window drawn by the +example.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CCCF088-E636-4C12-AA5E-3E2CB04424AD_d0e265567_href.png Binary file Symbian3/SDK/Source/GUID-0CCCF088-E636-4C12-AA5E-3E2CB04424AD_d0e265567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CCCF088-E636-4C12-AA5E-3E2CB04424AD_d0e270430_href.png Binary file Symbian3/SDK/Source/GUID-0CCCF088-E636-4C12-AA5E-3E2CB04424AD_d0e270430_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0CD18555-07EB-545D-9D47-D69A6BE6D2C8.dita --- a/Symbian3/SDK/Source/GUID-0CD18555-07EB-545D-9D47-D69A6BE6D2C8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0CD18555-07EB-545D-9D47-D69A6BE6D2C8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Standard SMS Converter

        This section describes the Standard SMS Converter and the alphabet it supports.

        Introduction

        The Standard SMS Converter is a built-in converter based on the GSM 7-bit encoding. This converter is identified by the KCharacterSetIdentifierSms7Bit UID, which is defined in the charconv.h header file. To better understand the different character set of each SMS converter, the Standard SMS Converter is set as the baseline. Any differences or additions to the character set of Standard SMS Converter are listed.

        For all of the converters, any undefined Unicode is converted to a question mark (?)–GSM code 0x37. Any code outside GSM 0x00 ~0x7F is converted to the Unicode replacement character 0xFFFD.

        Alphabet

        The highlighted boxes in Figure 1 illustrate the alphabet of the standard SMS converter:

        • GSM 7-bit default alphabet

        • GSM 7-bit default alphabet extension table

        • Extra lossy conversions–shown as Lossy Characters 1 in Figure 4.

        Figure 1

        Alphabet of the Standard SMS Converter -

        For information about the GSM 7-bit default alphabet and extension table, see 3GPP TS 23.038 V8.1.0. The table below lists the extra lossy conversions supported by the standard converter.

    Character

    Unicode

    GSM

    Converted Character

    ç LATIN SMALL LETTER C WITH CEDILLA

    0x00E7

    0x09

    Ç LATIN CAPITAL LETTER C WITH CEDILLA

    δ GREEK SMALL LETTER DELTA

    0x03B4

    0x10

    Δ GREEK CAPITAL LETTER DELTA

    φ GREEK SMALL LETTER PHI

    0x03C6

    0x12

    Φ GREEK CAPITAL LETTER PHI

    ϕ GREEK PHI SYMBOL

    0x03D5

    0x12

    Φ GREEK CAPITAL LETTER PHI

    γ GREEK SMALL LETTER GAMMA

    0x03B3

    0x13

    Γ GREEK CAPITAL LETTER GAMMA

    λ GREEK SMALL LETTER LAMDA

    0x03BB

    0x14

    Λ GREEK CAPITAL LETTER LAMDA

    Ω GREEK CAPITAL LETTER OMEGA

    0x03A9

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ω GREEK SMALL LETTER OMEGA

    0x03C9

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ώ GREEK SMALL LETTER OMEGA WITH TONOS

    0x03CE

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    Ω OHM SIGN

    0x2126

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    π GREEK SMALL LETTER PI

    0x03C0

    0x16

    Π GREEK CAPITAL LETTER PI

    ∏ N-ARY PRODUCT

    0x220F

    0x16

    Π GREEK CAPITAL LETTER PI

    ψ GREEK SMALL LETTER PSI

    0x03C8

    0x17

    Ψ GREEK CAPITAL LETTER PSI

    ς GREEK SMALL LETTER FINAL SIGMA

    0x03C2

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    σ GREEK SMALL LETTER SIGMA

    0x03C3

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    ∑ N-ARY SUMMATION

    0x2211

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    θ GREEK SMALL LETTER THETA

    0x03B8

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ϑ GREEK THETA SYMBOL

    0x03D1

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ξ GREEK SMALL LETTER XI

    0x03BE

    0x1A

    Ξ GREEK CAPITAL LETTER XI

    (FORM FEED)

    0x000C

    0x1B0A

    (PAGE BREAK)

    À LATIN CAPITAL LETTER A WITH GRAVE

    0x00C0

    0x41

    A LATIN CAPITAL LETTER A

    Á LATIN CAPITAL LETTER A WITH ACUTE

    0x00C1

    0x41

    A LATIN CAPITAL LETTER A

    Â LATIN CAPITAL LETTER A WITH CIRCUMFLEX

    0x00C2

    0x41

    A LATIN CAPITAL LETTER A

    Ã LATIN CAPITAL LETTER A WITH TILDE

    0x00C3

    0x41

    A LATIN CAPITAL LETTER A

    Ά GREEK CAPITAL LETTER ALPHA WITH TONOS

    0x0386

    0x41

    A LATIN CAPITAL LETTER A

    Α GREEK CAPITAL LETTER ALPHA

    0x0391

    0x41

    A LATIN CAPITAL LETTER A

    ά GREEK SMALL LETTER ALPHA WITH TONOS

    0x03AC

    0x41

    A LATIN CAPITAL LETTER A

    α GREEK SMALL LETTER ALPHA

    0x03B1

    0x41

    A LATIN CAPITAL LETTER A

    Β GREEK CAPITAL LETTER BETA

    0x0392

    0x42

    B LATIN CAPITAL LETTER B

    β GREEK SMALL LETTER BETA

    0x03B2

    0x42

    B LATIN CAPITAL LETTER B

    ϐ GREEK BETA SYMBOL

    0x03D0

    0x42

    B LATIN CAPITAL LETTER B

    È LATIN CAPITAL LETTER E WITH GRAVE

    0x00C8

    0x45

    E LATIN CAPITAL LETTER E

    Ê LATIN CAPITAL LETTER E WITH CIRCUMFLEX

    0x00CA

    0x45

    E LATIN CAPITAL LETTER E

    Ë LATIN CAPITAL LETTER E WITH DIAERESIS

    0x00CB

    0x45

    E LATIN CAPITAL LETTER E

    Έ GREEK CAPITAL LETTER EPSILON WITH TONOS

    0x0388

    0x45

    E LATIN CAPITAL LETTER E

    Ε GREEK CAPITAL LETTER EPSILON

    0x0395

    0x45

    E LATIN CAPITAL LETTER E

    έ GREEK SMALL LETTER EPSILON WITH TONOS

    0x03AD

    0x45

    E LATIN CAPITAL LETTER E

    ε GREEK SMALL LETTER EPSILON

    0x03B5

    0x45

    E LATIN CAPITAL LETTER E

    Ή GREEK CAPITAL LETTER ETA WITH TONOS

    0x0389

    0x48

    H LATIN CAPITAL LETTER H

    Η GREEK CAPITAL LETTER ETA

    0x0397

    0x48

    H LATIN CAPITAL LETTER H

    ή GREEK SMALL LETTER ETA WITH TONOS

    0x03AE

    0x48

    H LATIN CAPITAL LETTER H

    η GREEK SMALL LETTER ETA

    0x03B7

    0x48

    H LATIN CAPITAL LETTER H

    Ì LATIN CAPITAL LETTER I WITH GRAVE

    0x00CC

    0x49

    I LATIN CAPITAL LETTER I

    Í LATIN CAPITAL LETTER I WITH ACUTE

    0x00CD

    0x49

    I LATIN CAPITAL LETTER I

    Î LATIN CAPITAL LETTER I WITH CIRCUMFLEX

    0x00CE

    0x49

    I LATIN CAPITAL LETTER I

    Ï LATIN CAPITAL LETTER I WITH DIAERESIS

    0x00CF

    0x49

    I LATIN CAPITAL LETTER I

    Ί GREEK CAPITAL LETTER IOTA WITH TONOS

    0x038A

    0x49

    I LATIN CAPITAL LETTER I

    ΐ GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS

    0x0390

    0x49

    I LATIN CAPITAL LETTER I

    Ι GREEK CAPITAL LETTER IOTA

    0x0399

    0x49

    I LATIN CAPITAL LETTER I

    Ϊ GREEK CAPITAL LETTER IOTA WITH DIALYTIKA

    0x03AA

    0x49

    I LATIN CAPITAL LETTER I

    ί GREEK SMALL LETTER IOTA WITH TONOS

    0x03AF

    0x49

    I LATIN CAPITAL LETTER I

    ι GREEK SMALL LETTER IOTA

    0x03B9

    0x49

    I LATIN CAPITAL LETTER I

    ϊ GREEK SMALL LETTER IOTA WITH DIALYTIKA

    0x03CA

    0x49

    I LATIN CAPITAL LETTER I

    Κ GREEK CAPITAL LETTER KAPPA

    0x039A

    0x4B

    K LATIN CAPITAL LETTER K

    κ GREEK SMALL LETTER KAPPA

    0x03BA

    0x4B

    K LATIN CAPITAL LETTER K

    Μ GREEK CAPITAL LETTER MU

    0x039C

    0x4D

    M LATIN CAPITAL LETTER M

    μ GREEK SMALL LETTER MU

    0x03BC

    0x4D

    M LATIN CAPITAL LETTER M

    Ν GREEK CAPITAL LETTER NU

    0x039D

    0x4E

    N LATIN CAPITAL LETTER N

    ν GREEK SMALL LETTER NU

    0x03BD

    0x4E

    N LATIN CAPITAL LETTER N

    Ò LATIN CAPITAL LETTER O WITH GRAVE

    0x00D2

    0x4F

    O LATIN CAPITAL LETTER O

    Ó LATIN CAPITAL LETTER O WITH ACUTE

    0x00D3

    0x4F

    O LATIN CAPITAL LETTER O

    Ô LATIN CAPITAL LETTER O WITH CIRCUMFLEX

    0x00D4

    0x4F

    O LATIN CAPITAL LETTER O

    Õ LATIN CAPITAL LETTER O WITH TILDE

    0x00D5

    0x4F

    O LATIN CAPITAL LETTER O

    Ό GREEK CAPITAL LETTER OMICRON WITH TONOS

    0x038C

    0x4F

    O LATIN CAPITAL LETTER O

    Ο GREEK CAPITAL LETTER OMICRON

    0x039F

    0x4F

    O LATIN CAPITAL LETTER O

    ο GREEK SMALL LETTER OMICRON

    0x03BF

    0x4F

    O LATIN CAPITAL LETTER O

    ό GREEK SMALL LETTER OMICRON WITH TONOS

    0x03CC

    0x4F

    O LATIN CAPITAL LETTER O

    Ρ GREEK CAPITAL LETTER RHO

    0x03A1

    0x50

    P LATIN CAPITAL LETTER P

    ρ GREEK SMALL LETTER RHO

    0x03C1

    0x50

    P LATIN CAPITAL LETTER P

    Τ GREEK CAPITAL LETTER TAU

    0x03A4

    0x54

    T LATIN CAPITAL LETTER T

    τ GREEK SMALL LETTER TAU

    0x03C4

    0x54

    T LATIN CAPITAL LETTER T

    Ù LATIN CAPITAL LETTER U WITH GRAVE

    0x00D9

    0x55

    U LATIN CAPITAL LETTER U

    Ú LATIN CAPITAL LETTER U WITH ACUTE

    0x00DA

    0x55

    U LATIN CAPITAL LETTER U

    Û LATIN CAPITAL LETTER U WITH CIRCUMFLEX

    0x00DB

    0x55

    U LATIN CAPITAL LETTER U

    Χ GREEK CAPITAL LETTER CHI

    0x03A7

    0x58

    X LATIN CAPITAL LETTER X

    χ GREEK SMALL LETTER CHI

    0x03C7

    0x58

    X LATIN CAPITAL LETTER X

    Ý LATIN CAPITAL LETTER Y WITH ACUTE

    0x00DD

    0x59

    Y LATIN CAPITAL LETTER Y

    Ύ GREEK CAPITAL LETTER UPSILON WITH TONOS

    0x038E

    0x59

    Y LATIN CAPITAL LETTER Y

    Υ GREEK CAPITAL LETTER UPSILON

    0x03A5

    0x59

    Y LATIN CAPITAL LETTER Y

    Ϋ GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA

    0x03AB

    0x59

    Y LATIN CAPITAL LETTER Y

    ΰ GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS

    0x03B0

    0x59

    Y LATIN CAPITAL LETTER Y

    υ GREEK SMALL LETTER UPSILON

    0x03C5

    0x59

    Y LATIN CAPITAL LETTER Y

    ϋ GREEK SMALL LETTER UPSILON WITH DIALYTIKA

    0x03CB

    0x59

    Y LATIN CAPITAL LETTER Y

    ύ GREEK SMALL LETTER UPSILON WITH TONOS

    0x03CD

    0x59

    Y LATIN CAPITAL LETTER Y

    ϒ GREEK UPSILON WITH HOOK SYMBOL

    0x03D2

    0x59

    Y LATIN CAPITAL LETTER Y

    ϓ GREEK UPSILON WITH ACUTE AND HOOK SYMBOL

    0x03D3

    0x59

    Y LATIN CAPITAL LETTER Y

    ϔ GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL

    0x03D4

    0x59

    Y LATIN CAPITAL LETTER Y

    Ζ GREEK CAPITAL LETTER ZETA

    0x0396

    0x5A

    Z LATIN CAPITAL LETTER Z

    ζ GREEK SMALL LETTER ZETA

    0x03b6

    0x5A

    Z LATIN CAPITAL LETTER Z

    á LATIN SMALL LETTER A WITH ACUTE

    0x00E1

    0x61

    a LATIN SMALL LETTER A

    â LATIN SMALL LETTER A WITH CIRCUMFLEX

    0x00E2

    0x61

    a LATIN SMALL LETTER A

    ã LATIN SMALL LETTER A WITH TILDE

    0x00E3

    0x61

    a LATIN SMALL LETTER A

    ê LATIN SMALL LETTER E WITH CIRCUMFLEX

    0x00EA

    0x65

    e LATIN SMALL LETTER E

    ë LATIN SMALL LETTER E WITH DIAERESIS

    0x00EB

    0x65

    e LATIN SMALL LETTER E

    í LATIN SMALL LETTER I WITH ACUTE

    0x00ED

    0x69

    i LATIN SMALL LETTER I

    î LATIN SMALL LETTER I WITH CIRCUMFLEX

    0x00EE

    0x69

    i LATIN SMALL LETTER I

    ï LATIN SMALL LETTER I WITH DIAERESIS

    0x00EF

    0x69

    i LATIN SMALL LETTER I

    ó LATIN SMALL LETTER O WITH ACUTE

    0x00f3

    0x6F

    o LATIN SMALL LETTER O

    ô LATIN SMALL LETTER O WITH CIRCUMFLEX

    0x00F4

    0x6F

    o LATIN SMALL LETTER O

    õ LATIN SMALL LETTER O WITH TILDE

    0x00F5

    0x6F

    o LATIN SMALL LETTER O

    ú LATIN SMALL LETTER U WITH ACUTE

    0x00FA

    0x75

    u LATIN SMALL LETTER U

    û LATIN SMALL LETTER U WITH CIRCUMFLEX

    0x00FB

    0x75

    u LATIN SMALL LETTER U

    ý LATIN SMALL LETTER Y WITH ACUTE

    0x00FD

    0x79

    y LATIN SMALL LETTER Y

    ÿ LATIN SMALL LETTER Y WITH DIAERESIS

    0x00FF

    0x79

    y LATIN SMALL LETTER Y

    See also

    SMS Encodings and Converters Overview

    \ No newline at end of file +

    For information about the GSM 7-bit default alphabet and extension table, see 3GPP TS 23.038 V8.1.0. The table below lists the extra lossy conversions supported by the standard converter.

    Character

    Unicode

    GSM

    Converted Character

    ç LATIN SMALL LETTER C WITH CEDILLA

    0x00E7

    0x09

    Ç LATIN CAPITAL LETTER C WITH CEDILLA

    δ GREEK SMALL LETTER DELTA

    0x03B4

    0x10

    Δ GREEK CAPITAL LETTER DELTA

    φ GREEK SMALL LETTER PHI

    0x03C6

    0x12

    Φ GREEK CAPITAL LETTER PHI

    ϕ GREEK PHI SYMBOL

    0x03D5

    0x12

    Φ GREEK CAPITAL LETTER PHI

    γ GREEK SMALL LETTER GAMMA

    0x03B3

    0x13

    Γ GREEK CAPITAL LETTER GAMMA

    λ GREEK SMALL LETTER LAMDA

    0x03BB

    0x14

    Λ GREEK CAPITAL LETTER LAMDA

    Ω GREEK CAPITAL LETTER OMEGA

    0x03A9

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ω GREEK SMALL LETTER OMEGA

    0x03C9

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ώ GREEK SMALL LETTER OMEGA WITH TONOS

    0x03CE

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    Ω OHM SIGN

    0x2126

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    π GREEK SMALL LETTER PI

    0x03C0

    0x16

    Π GREEK CAPITAL LETTER PI

    ∏ N-ARY PRODUCT

    0x220F

    0x16

    Π GREEK CAPITAL LETTER PI

    ψ GREEK SMALL LETTER PSI

    0x03C8

    0x17

    Ψ GREEK CAPITAL LETTER PSI

    ς GREEK SMALL LETTER FINAL SIGMA

    0x03C2

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    σ GREEK SMALL LETTER SIGMA

    0x03C3

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    ∑ N-ARY SUMMATION

    0x2211

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    θ GREEK SMALL LETTER THETA

    0x03B8

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ϑ GREEK THETA SYMBOL

    0x03D1

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ξ GREEK SMALL LETTER XI

    0x03BE

    0x1A

    Ξ GREEK CAPITAL LETTER XI

    (FORM FEED)

    0x000C

    0x1B0A

    (PAGE BREAK)

    À LATIN CAPITAL LETTER A WITH GRAVE

    0x00C0

    0x41

    A LATIN CAPITAL LETTER A

    Á LATIN CAPITAL LETTER A WITH ACUTE

    0x00C1

    0x41

    A LATIN CAPITAL LETTER A

    Â LATIN CAPITAL LETTER A WITH CIRCUMFLEX

    0x00C2

    0x41

    A LATIN CAPITAL LETTER A

    Ã LATIN CAPITAL LETTER A WITH TILDE

    0x00C3

    0x41

    A LATIN CAPITAL LETTER A

    Ά GREEK CAPITAL LETTER ALPHA WITH TONOS

    0x0386

    0x41

    A LATIN CAPITAL LETTER A

    Α GREEK CAPITAL LETTER ALPHA

    0x0391

    0x41

    A LATIN CAPITAL LETTER A

    ά GREEK SMALL LETTER ALPHA WITH TONOS

    0x03AC

    0x41

    A LATIN CAPITAL LETTER A

    α GREEK SMALL LETTER ALPHA

    0x03B1

    0x41

    A LATIN CAPITAL LETTER A

    Β GREEK CAPITAL LETTER BETA

    0x0392

    0x42

    B LATIN CAPITAL LETTER B

    β GREEK SMALL LETTER BETA

    0x03B2

    0x42

    B LATIN CAPITAL LETTER B

    ϐ GREEK BETA SYMBOL

    0x03D0

    0x42

    B LATIN CAPITAL LETTER B

    È LATIN CAPITAL LETTER E WITH GRAVE

    0x00C8

    0x45

    E LATIN CAPITAL LETTER E

    Ê LATIN CAPITAL LETTER E WITH CIRCUMFLEX

    0x00CA

    0x45

    E LATIN CAPITAL LETTER E

    Ë LATIN CAPITAL LETTER E WITH DIAERESIS

    0x00CB

    0x45

    E LATIN CAPITAL LETTER E

    Έ GREEK CAPITAL LETTER EPSILON WITH TONOS

    0x0388

    0x45

    E LATIN CAPITAL LETTER E

    Ε GREEK CAPITAL LETTER EPSILON

    0x0395

    0x45

    E LATIN CAPITAL LETTER E

    έ GREEK SMALL LETTER EPSILON WITH TONOS

    0x03AD

    0x45

    E LATIN CAPITAL LETTER E

    ε GREEK SMALL LETTER EPSILON

    0x03B5

    0x45

    E LATIN CAPITAL LETTER E

    Ή GREEK CAPITAL LETTER ETA WITH TONOS

    0x0389

    0x48

    H LATIN CAPITAL LETTER H

    Η GREEK CAPITAL LETTER ETA

    0x0397

    0x48

    H LATIN CAPITAL LETTER H

    ή GREEK SMALL LETTER ETA WITH TONOS

    0x03AE

    0x48

    H LATIN CAPITAL LETTER H

    η GREEK SMALL LETTER ETA

    0x03B7

    0x48

    H LATIN CAPITAL LETTER H

    Ì LATIN CAPITAL LETTER I WITH GRAVE

    0x00CC

    0x49

    I LATIN CAPITAL LETTER I

    Í LATIN CAPITAL LETTER I WITH ACUTE

    0x00CD

    0x49

    I LATIN CAPITAL LETTER I

    Î LATIN CAPITAL LETTER I WITH CIRCUMFLEX

    0x00CE

    0x49

    I LATIN CAPITAL LETTER I

    Ï LATIN CAPITAL LETTER I WITH DIAERESIS

    0x00CF

    0x49

    I LATIN CAPITAL LETTER I

    Ί GREEK CAPITAL LETTER IOTA WITH TONOS

    0x038A

    0x49

    I LATIN CAPITAL LETTER I

    ΐ GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS

    0x0390

    0x49

    I LATIN CAPITAL LETTER I

    Ι GREEK CAPITAL LETTER IOTA

    0x0399

    0x49

    I LATIN CAPITAL LETTER I

    Ϊ GREEK CAPITAL LETTER IOTA WITH DIALYTIKA

    0x03AA

    0x49

    I LATIN CAPITAL LETTER I

    ί GREEK SMALL LETTER IOTA WITH TONOS

    0x03AF

    0x49

    I LATIN CAPITAL LETTER I

    ι GREEK SMALL LETTER IOTA

    0x03B9

    0x49

    I LATIN CAPITAL LETTER I

    ϊ GREEK SMALL LETTER IOTA WITH DIALYTIKA

    0x03CA

    0x49

    I LATIN CAPITAL LETTER I

    Κ GREEK CAPITAL LETTER KAPPA

    0x039A

    0x4B

    K LATIN CAPITAL LETTER K

    κ GREEK SMALL LETTER KAPPA

    0x03BA

    0x4B

    K LATIN CAPITAL LETTER K

    Μ GREEK CAPITAL LETTER MU

    0x039C

    0x4D

    M LATIN CAPITAL LETTER M

    μ GREEK SMALL LETTER MU

    0x03BC

    0x4D

    M LATIN CAPITAL LETTER M

    Ν GREEK CAPITAL LETTER NU

    0x039D

    0x4E

    N LATIN CAPITAL LETTER N

    ν GREEK SMALL LETTER NU

    0x03BD

    0x4E

    N LATIN CAPITAL LETTER N

    Ò LATIN CAPITAL LETTER O WITH GRAVE

    0x00D2

    0x4F

    O LATIN CAPITAL LETTER O

    Ó LATIN CAPITAL LETTER O WITH ACUTE

    0x00D3

    0x4F

    O LATIN CAPITAL LETTER O

    Ô LATIN CAPITAL LETTER O WITH CIRCUMFLEX

    0x00D4

    0x4F

    O LATIN CAPITAL LETTER O

    Õ LATIN CAPITAL LETTER O WITH TILDE

    0x00D5

    0x4F

    O LATIN CAPITAL LETTER O

    Ό GREEK CAPITAL LETTER OMICRON WITH TONOS

    0x038C

    0x4F

    O LATIN CAPITAL LETTER O

    Ο GREEK CAPITAL LETTER OMICRON

    0x039F

    0x4F

    O LATIN CAPITAL LETTER O

    ο GREEK SMALL LETTER OMICRON

    0x03BF

    0x4F

    O LATIN CAPITAL LETTER O

    ό GREEK SMALL LETTER OMICRON WITH TONOS

    0x03CC

    0x4F

    O LATIN CAPITAL LETTER O

    Ρ GREEK CAPITAL LETTER RHO

    0x03A1

    0x50

    P LATIN CAPITAL LETTER P

    ρ GREEK SMALL LETTER RHO

    0x03C1

    0x50

    P LATIN CAPITAL LETTER P

    Τ GREEK CAPITAL LETTER TAU

    0x03A4

    0x54

    T LATIN CAPITAL LETTER T

    τ GREEK SMALL LETTER TAU

    0x03C4

    0x54

    T LATIN CAPITAL LETTER T

    Ù LATIN CAPITAL LETTER U WITH GRAVE

    0x00D9

    0x55

    U LATIN CAPITAL LETTER U

    Ú LATIN CAPITAL LETTER U WITH ACUTE

    0x00DA

    0x55

    U LATIN CAPITAL LETTER U

    Û LATIN CAPITAL LETTER U WITH CIRCUMFLEX

    0x00DB

    0x55

    U LATIN CAPITAL LETTER U

    Χ GREEK CAPITAL LETTER CHI

    0x03A7

    0x58

    X LATIN CAPITAL LETTER X

    χ GREEK SMALL LETTER CHI

    0x03C7

    0x58

    X LATIN CAPITAL LETTER X

    Ý LATIN CAPITAL LETTER Y WITH ACUTE

    0x00DD

    0x59

    Y LATIN CAPITAL LETTER Y

    Ύ GREEK CAPITAL LETTER UPSILON WITH TONOS

    0x038E

    0x59

    Y LATIN CAPITAL LETTER Y

    Υ GREEK CAPITAL LETTER UPSILON

    0x03A5

    0x59

    Y LATIN CAPITAL LETTER Y

    Ϋ GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA

    0x03AB

    0x59

    Y LATIN CAPITAL LETTER Y

    ΰ GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS

    0x03B0

    0x59

    Y LATIN CAPITAL LETTER Y

    υ GREEK SMALL LETTER UPSILON

    0x03C5

    0x59

    Y LATIN CAPITAL LETTER Y

    ϋ GREEK SMALL LETTER UPSILON WITH DIALYTIKA

    0x03CB

    0x59

    Y LATIN CAPITAL LETTER Y

    ύ GREEK SMALL LETTER UPSILON WITH TONOS

    0x03CD

    0x59

    Y LATIN CAPITAL LETTER Y

    ϒ GREEK UPSILON WITH HOOK SYMBOL

    0x03D2

    0x59

    Y LATIN CAPITAL LETTER Y

    ϓ GREEK UPSILON WITH ACUTE AND HOOK SYMBOL

    0x03D3

    0x59

    Y LATIN CAPITAL LETTER Y

    ϔ GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL

    0x03D4

    0x59

    Y LATIN CAPITAL LETTER Y

    Ζ GREEK CAPITAL LETTER ZETA

    0x0396

    0x5A

    Z LATIN CAPITAL LETTER Z

    ζ GREEK SMALL LETTER ZETA

    0x03b6

    0x5A

    Z LATIN CAPITAL LETTER Z

    á LATIN SMALL LETTER A WITH ACUTE

    0x00E1

    0x61

    a LATIN SMALL LETTER A

    â LATIN SMALL LETTER A WITH CIRCUMFLEX

    0x00E2

    0x61

    a LATIN SMALL LETTER A

    ã LATIN SMALL LETTER A WITH TILDE

    0x00E3

    0x61

    a LATIN SMALL LETTER A

    ê LATIN SMALL LETTER E WITH CIRCUMFLEX

    0x00EA

    0x65

    e LATIN SMALL LETTER E

    ë LATIN SMALL LETTER E WITH DIAERESIS

    0x00EB

    0x65

    e LATIN SMALL LETTER E

    í LATIN SMALL LETTER I WITH ACUTE

    0x00ED

    0x69

    i LATIN SMALL LETTER I

    î LATIN SMALL LETTER I WITH CIRCUMFLEX

    0x00EE

    0x69

    i LATIN SMALL LETTER I

    ï LATIN SMALL LETTER I WITH DIAERESIS

    0x00EF

    0x69

    i LATIN SMALL LETTER I

    ó LATIN SMALL LETTER O WITH ACUTE

    0x00f3

    0x6F

    o LATIN SMALL LETTER O

    ô LATIN SMALL LETTER O WITH CIRCUMFLEX

    0x00F4

    0x6F

    o LATIN SMALL LETTER O

    õ LATIN SMALL LETTER O WITH TILDE

    0x00F5

    0x6F

    o LATIN SMALL LETTER O

    ú LATIN SMALL LETTER U WITH ACUTE

    0x00FA

    0x75

    u LATIN SMALL LETTER U

    û LATIN SMALL LETTER U WITH CIRCUMFLEX

    0x00FB

    0x75

    u LATIN SMALL LETTER U

    ý LATIN SMALL LETTER Y WITH ACUTE

    0x00FD

    0x79

    y LATIN SMALL LETTER Y

    ÿ LATIN SMALL LETTER Y WITH DIAERESIS

    0x00FF

    0x79

    y LATIN SMALL LETTER Y

    See also

    SMS Encodings and Converters Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0D093559-793F-5CDC-BB66-8FE1C8A3850E.dita --- a/Symbian3/SDK/Source/GUID-0D093559-793F-5CDC-BB66-8FE1C8A3850E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0D093559-793F-5CDC-BB66-8FE1C8A3850E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,13 +19,13 @@ other techniques.

    Transient tables

    Transient tables are created by the database engine to compute intermediate results.

    Transient tables are stored on disk by default, which may result in unexpected I/O calls -that will probably have a negative impact on database performance.

    Prevent datafile corruption

    Datafile +that will probably have a negative impact on database performance.

    Prevent datafile corruption

    Datafile corruption is corruption of the file containing a database with invalid data.

    Datafile corruption can occur after a system crash or loss of power. SQLite maintains files called rollback journals from which the last valid state of a database can be reconstructed. However, if a rollback journal is removed or renamed during recovery from a crash, for instance in the course of application recovery -the database will remain corrupted.

    SQL index tips

    Indexes +the database will remain corrupted.

    SQL index tips

    Indexes are added either manually or automatically to columns of a data table to speed up SELECT operations.

    Indexes greatly speed up the performance of SELECT statements but can impact on insertions, updates and deletions and diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0D1E30D8-D900-5FD9-BD1F-1B93BAD8AEF5.dita --- a/Symbian3/SDK/Source/GUID-0D1E30D8-D900-5FD9-BD1F-1B93BAD8AEF5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0D1E30D8-D900-5FD9-BD1F-1B93BAD8AEF5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -What are fieldsThis topic describes the structure of a field. A field is an item that can be stored in the Comms Database.

    A field is a container and an element. A field is the basic unit of information in the Comms Database.

    A field is represented by the templated class CMDBField <T>. The template parameter defines the type of data that the field contains. For example TInt, TDesC, TBool

    Fields are collected into records.

    Getting data from a field

    An overloaded conversion operator converts the data value in a CMDBField <T> object to the template type. The template type is the type defined by the characters T. The operator allows you to use a CMDBField<T> object on the right-hand side of an assignment call. The operator also allows you to pass a CMDBField<T> object into a function that requires items of the template type.

    The value of a field in memory is NULL:

    • if the caller has not set the value

    • if the field as not been loaded from the Comms Database

    If the value of a field is NULL after the field has been successfully loaded from the Comms Database, the field has been explicitly set to NULL by the writer of the record.

    Setting data into a field

    A field has an assignment operator. A type T field accepts a type T item on the right-hand side of an assignment.

    A descriptor has variable length data. You need to set the size of the buffer that the field uses to store data. You must call SetMaxLengthL() on the CMDBField <T> object and pass the length of the data to be added. You then use the assignment operator. The length that you set must be enough or the assignment operator does not work. The SetL() function is an alternative method. This function calculates the length of a descriptor parameter for a descriptor field type and performs the allocation and assignment.

    \ No newline at end of file +What are fieldsThis topic describes the structure of a field. A field is an item that can be stored in the Comms Database.

    A field is a container and an element. A field is the basic unit of information in the Comms Database.

    A field is represented by the templated class CMDBField <T>. The template parameter defines the type of data that the field contains. For example TInt, TDesC, TBool

    Fields are collected into records.

    Getting data from a field

    An overloaded conversion operator converts the data value in a CMDBField <T> object to the template type. The template type is the type defined by the characters T. The operator allows you to use a CMDBField<T> object on the right-hand side of an assignment call. The operator also allows you to pass a CMDBField<T> object into a function that requires items of the template type.

    The value of a field in memory is NULL:

    • if the caller has not set the value

    • if the field as not been loaded from the Comms Database

    If the value of a field is NULL after the field has been successfully loaded from the Comms Database, the field has been explicitly set to NULL by the writer of the record.

    Setting data into a field

    A field has an assignment operator. A type T field accepts a type T item on the right-hand side of an assignment.

    A descriptor has variable length data. You need to set the size of the buffer that the field uses to store data. You must call SetMaxLengthL() on the CMDBField <T> object and pass the length of the data to be added. You then use the assignment operator. The length that you set must be enough or the assignment operator does not work. The SetL() function is an alternative method. This function calculates the length of a descriptor parameter for a descriptor field type and performs the allocation and assignment.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0D3060BE-8C0F-564A-8979-C9A88C49C5E8_d0e78377_href.png Binary file Symbian3/SDK/Source/GUID-0D3060BE-8C0F-564A-8979-C9A88C49C5E8_d0e78377_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0D3060BE-8C0F-564A-8979-C9A88C49C5E8_d0e78415_href.png Binary file Symbian3/SDK/Source/GUID-0D3060BE-8C0F-564A-8979-C9A88C49C5E8_d0e78415_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0D619063-F2DB-53FC-A5E6-BC09AD915FA4.dita --- a/Symbian3/SDK/Source/GUID-0D619063-F2DB-53FC-A5E6-BC09AD915FA4.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,56 +0,0 @@ - - - - - -Resource -member initialisation overview -

    The resource initialiser has different forms depending on whether a single, -simple, member is being initialised, or whether a struct or an array is being -initialised:

    -<resource-initialiser> -resource-initialiser ::= - <member-name> [ (<length-limit>) ] = <initialiser><initialiser> -initialiser ::= - <simple-initialiser> | <struct-initialiser> | <array-initialiser> -

    Resource members may be initialised by default (in the struct definition) -or explicitly initialised (in the resource definition).

    -

    In general,

    -
      -

    • If a member is initialised -in a RESOURCE statement, then that is its value.

      • -

    • If a member is initialised -in a STRUCT statement, then that is its value for all resources -which do not explicitly initialise it.

      • -

    • If a member is neither initialised -in a RESOURCE statement nor a STRUCT statement, -then: BYTE, WORD and DOUBLE members -contain zero; TEXT, LTEXT and BUF members -contain an empty string.

      • -

    • It is an error for LINK and LLINK members -to have no explicit value, so they must be initialised, either by default -(in the STRUCT statement) or explicitly (in the RESOURCE statement).

      • -

    • SRLINK members -may not be initialised (either in the STRUCT statement or -a RESOURCE statement) since they are automatically assigned -the resource id of the resource in which they appear.

      • -

    • Members which are themselves STRUCT s -may not be default initialised. They can only be initialised in the RESOURCE definition. -If they are not explicitly initialised, they will take up zero bytes in the -resource file. For example, given the following STRUCT definition:

      STRUCT TEST2 - { - WORD value; - STRUCT tester; - }

      The following RESOURCE statement only generates -the two bytes 0xFF 0x00.

      RESOURCE TEST2 item - { - value=255; - }
      • -
    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0DD1EBC4-6068-5FE7-B649-CABA57E86195.dita --- a/Symbian3/SDK/Source/GUID-0DD1EBC4-6068-5FE7-B649-CABA57E86195.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0DD1EBC4-6068-5FE7-B649-CABA57E86195.dita Tue Jul 20 12:00:49 2010 +0100 @@ -33,7 +33,7 @@ gc.DrawPolyLine(mypoints); ...
Drawing a polygon

The following example code illustrates how to draw a filled polygon from an array of points. The polygon is self-crossing. Self-crossing polygons can be filled according to one of two rules, TFillRule::EAlternate (the default), or TFillRule::EWinding. These rules work with the concept of a winding number, as shown in the following figure:

Winding numbers -

EWinding fills all areas, while EAlternate only fills areas with odd winding numbers.

Drawing a polygon using the EWinding fill rule

  1. Use SetBrushStyle() to set a cross-hatched brush style.

  2. Use DrawPolygon() to draw the polygon with the EWinding fill rule.

... +

EWinding fills all areas, while EAlternate only fills areas with odd winding numbers.

Drawing a polygon using the EWinding fill rule

  1. Use SetBrushStyle() to set a cross-hatched brush style.

  2. Use DrawPolygon() to draw the polygon with the EWinding fill rule.

... // draw self-crossing polygon using the winding fill rule gc.SetBrushStyle(CGraphicsContext::ESquareCrossHatchBrush); gc.SetBrushColor(black); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0DEDC917-05C9-5D43-B839-73C043624BE9.dita --- a/Symbian3/SDK/Source/GUID-0DEDC917-05C9-5D43-B839-73C043624BE9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0DEDC917-05C9-5D43-B839-73C043624BE9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,51 +9,51 @@ --> - circularbuffer: -Circular Buffer ExampleThis example demonstrates the how to use the circular buffer classes CCirBuf and CCirBuffer. -
Purpose

This -example application shows how to construct and make use of circular buffers -containing integers, objects of user defined classes and objects of an R class.

-
Download

Click on the following link to download -the example: circularbuffer .zip

Click browse to view the example code.

-
class summary

CCirBuffer CCirBuf

-
Design and -implementation

Class diagram:

- Circular buffers example class diagram - -

The example creates a circular buffer of integers using CCirBuffer::Put() to -add elements and CCirBuffer::Get() to remove an element. -To demonstrate the circular nature of the buffer, the example:

    -

  • adds four elements until -the buffer is full,

    • -

  • tries to adds another -element to the buffer, which fails with a buffer full error message,

    • -

  • removes elements 1 and -2 from the buffer, leaving elements 3 and 4,

    • -

  • adds two new elements -(5 and 6) to the buffer,

    • -

  • removes all elements -(3, 4, 5 and 6) from the buffer.

    • -

Similar steps are performed using CCirBuf to add -(CCirBuf::Add()) and remove (CCirBuf::Remove()) -user-defined objects, and objects of an R class to and from -the buffer.

After removing R class objects from the circular buffer, -they must be closed in order to release the resource held by the R Class objects.

-
Building and -configuring

To build the example:

    -

  • You can build the example -from your IDE or the command line.

    If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

    If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

    bldmake -bldfiles

    abld build

    How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

    • -

  • For the emulator, the -example builds an executable called circularbuffer.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

    • + circularbuffer: Circular Buffer ExampleThis example demonstrates the how to use the circular buffer +classes CCirBuf and CCirBuffer. +
    Purpose

    This example application shows how to construct and make use +of circular buffers containing integers, objects of user defined classes +and objects of an R class.

    +
    Download

    Click on the following link to download the example: circularbuffer .zip

    Click browse to view the example code.

    +
    class +summary

    CCirBuffer CCirBuf

    +
    Design +and implementation

    Class diagram:

    + Circular buffers example class diagram + + +

    The example creates a circular buffer of integers using CCirBuffer::Put() to add elements and CCirBuffer::Get() to remove an element. To demonstrate the circular nature of the +buffer, the example:

      +

    • adds four elements +until the buffer is full,

      • +

    • tries to adds +another element to the buffer, which fails with a buffer full error +message,

      • +

    • removes elements +1 and 2 from the buffer, leaving elements 3 and 4,

      • +

    • adds two new +elements (5 and 6) to the buffer,

      • +

    • removes all +elements (3, 4, 5 and 6) from the buffer.

      • +

    Similar steps are performed using CCirBuf to add (CCirBuf::Add()) and remove (CCirBuf::Remove()) user-defined objects, and objects of +an R class to and from the buffer.

    After +removing R class objects from the circular buffer, they must be closed +in order to release the resource held by the R Class objects.

    +
    Building +and configuring

    To build the example:

      +

    • You can build +the example from your IDE or the command line.

      If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

      If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld +build .

      • +

    • For the emulator, +the example builds an executable called circularbuffer.exe in the epoc32\release\winscw\<udeb or + urel>\ folder.

    -
    Running the -example

    The user is prompted to press a key in order to progress -from one function to the next.

    +
    Running +the example

    The user is prompted to press a key in order +to progress from one function to the next.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E21EAE4-BF71-55FD-9561-EA5530696627_d0e338735_href.png Binary file Symbian3/SDK/Source/GUID-0E21EAE4-BF71-55FD-9561-EA5530696627_d0e338735_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E21EAE4-BF71-55FD-9561-EA5530696627_d0e345201_href.png Binary file Symbian3/SDK/Source/GUID-0E21EAE4-BF71-55FD-9561-EA5530696627_d0e345201_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E3E2FAD-FC85-5995-8B5C-8F1C1A4186D0.dita --- a/Symbian3/SDK/Source/GUID-0E3E2FAD-FC85-5995-8B5C-8F1C1A4186D0.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -Troubleshooting Tips for RVCT v3.1

    This section is intended to help you troubleshoot the errors that may occur after migrating to RealView Compilation Tools (RVCT) v3.1. It provides a list of common problems that you may face while building your component using RVCT v3.1, with possible causes and ways to troubleshoot the problems.

    Problem Possible cause Possible solution

    Error: L6410W: Symbol <symbol_name > with non STV_DEFAULT visibility STV_HIDDEN should be resolved statically, cannot use definition in <dso_file_name >

    The linker is aware that the symbol (function) is present in another DLL, but in at least one of the source files of your component the symbol (function) has been declared without the IMPORT_C modifier.

    Identify such source files and prefix the symbol declaration with the IMPORT_C modifier.

    elf2e32 : Error: E1036: Symbol <symbol_name > Missing from ELF file: <file_name >

    The symbol (function) is present in the generated ELF DLL, but it is not visible externally. This is because the symbol (function) definition is not annotated with EXPORT_C, or when callers within the DLL does not prefix the function declaration with the IMPORT_C modifier.

    Identify such symbol definitions and annotate them with the EXPORT_C modifier. Prefix the function declaration with the IMPORT_C modifier if you are trying to call a function in another DLL.

    If you are unable to troubleshoot the problems listed in this table, perform the following steps:

    1. Browse to the directory where the object files of your component are stored.

    2. Create a dump of the symbol table for each object file using the command, fromelf -s <object_filename> and locate the problematic function. If the function does not have the STV_DEFAULT visibility, then you have found the cause, or at least have identified the source file that is causing the problem.

    3. If you are still unable to identify the cause of the problem, check the pre-processed source file to find out the cause. Perform the following steps to pre-process the source file:

      1. Identify the armcc command (copy from the log file) that compiled the object.

      2. Run the command after replacing -c with -E and specifying the output file as an argument to the -o option.

      3. Check whether the function has been annotated with __declspec(dllimport), which is the expansion of IMPORT_C.

        Note: If the function declaration is incorrect in more than one place, then repeat this whole procedure until all instances are identified.

    Overview of the - native build targets     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E55E007-913C-56DA-8BEF-7EC00FFCCE51_d0e304358_href.jpg Binary file Symbian3/SDK/Source/GUID-0E55E007-913C-56DA-8BEF-7EC00FFCCE51_d0e304358_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E55E007-913C-56DA-8BEF-7EC00FFCCE51_d0e310830_href.jpg Binary file Symbian3/SDK/Source/GUID-0E55E007-913C-56DA-8BEF-7EC00FFCCE51_d0e310830_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E695106-4139-4335-A11F-BD04418DD583.dita --- a/Symbian3/SDK/Source/GUID-0E695106-4139-4335-A11F-BD04418DD583.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0E695106-4139-4335-A11F-BD04418DD583.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,7 +27,7 @@ Multi-selection lists: in the main pane (left) and in a setting editor (right) - +

    The keypad functions for multi-selection lists are as follows:

    Default key event @@ -76,7 +76,7 @@ </tgroup> </table> <p/> -<table id="GUID-4F77253E-5688-4642-98DD-04CB7FCF38E1-GENID-1-10-1-6-1-1-5-1-8-1-1-9-1-9-1-2-8"><title>The default touch +<table id="GUID-4F77253E-5688-4642-98DD-04CB7FCF38E1-GENID-1-10-1-7-1-1-5-1-8-1-1-9-1-9-1-2-8"><title>The default touch events for multi-selection list diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E91173A-BA80-5817-866A-7A284573EBCE_d0e281521_href.png Binary file Symbian3/SDK/Source/GUID-0E91173A-BA80-5817-866A-7A284573EBCE_d0e281521_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0E91173A-BA80-5817-866A-7A284573EBCE_d0e286360_href.png Binary file Symbian3/SDK/Source/GUID-0E91173A-BA80-5817-866A-7A284573EBCE_d0e286360_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0EBE5733-A267-5F4A-85AD-87C3ECF80731.dita --- a/Symbian3/SDK/Source/GUID-0EBE5733-A267-5F4A-85AD-87C3ECF80731.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0EBE5733-A267-5F4A-85AD-87C3ECF80731.dita Tue Jul 20 12:00:49 2010 +0100 @@ -38,7 +38,7 @@ variant.

    The screen mode enables old applications to run on new phones with higher resolutions - +

    There are several similar use cases, such as swapping between portrait and landscape orientations and flip phones that have a flap that, when closed, partially obscures the main screen. The Window Server uses the screen mode @@ -70,7 +70,7 @@ area. The application's area (which corresponds to the screen mode) is referred to as the application extent in ScreenPlay.

    Coordinate spaces in ScreenPlay - +

    ScreenPlay handles application sizing and positioning in a fundamentally different way from the non-ScreenPlay variant. Using a fixed offset to position the application within the screen is inadequate when connecting to an external @@ -80,7 +80,7 @@ diagram, where the red cross indicates the offset for a QVGA display.

    A fixed offset and several display resolutions (not drawn to scale) - +

    In ScreenPlay there is no scaling of the application extent relative to the full UI area—there is always a 1:1 pixel correspondence between them. In addition, although supported, the screen mode offset is not necessarily diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0EBE8B44-1F42-4654-AC4D-A5F242FA49EB_d0e52114_href.png Binary file Symbian3/SDK/Source/GUID-0EBE8B44-1F42-4654-AC4D-A5F242FA49EB_d0e52114_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0EBE8B44-1F42-4654-AC4D-A5F242FA49EB_d0e52257_href.png Binary file Symbian3/SDK/Source/GUID-0EBE8B44-1F42-4654-AC4D-A5F242FA49EB_d0e52257_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0EF25CCA-1E6B-5B62-8E77-9A670986C5EF.dita --- a/Symbian3/SDK/Source/GUID-0EF25CCA-1E6B-5B62-8E77-9A670986C5EF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0EF25CCA-1E6B-5B62-8E77-9A670986C5EF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,9 +12,9 @@ Textual LoggingThis topic describes the textual logging mechanisms available to help debugging the Communication-related components.

    Most Comms components can output debugging information. These components must be configured to output information, with the configuration procedure dependent on the logging mechanism used by the component. The following mechanisms are used to log the information:

    • Flogger - This logging mechanism is a file logger. It used to be the standard mechanism for Comms logging, but it is being replaced by CDU (below).

    • Comms Debug Utility (CDU) - This logging mechanism is currently used for the majority of Comms logging. It is the successor to Flogger and adds a two-phase logging system to give flexibility in debugging problems which are difficult to reproduce in debug binary files. It unifies Comms logging into one text file and allows the output to be redirected to RDebug for easier on-target debugging, or on emulator to the fast Windows Debug port. For more information see Post-processing CDU log files, Default CDU and Interpreting the log files.

      Note: The CDU API is not published and so its APIs cannot be used for adding new logging.

    • Unified Trace/UTrace/ULogger - This logging mechanism is currently used for a small amount of Comms logging. For more information see How to Use ULogger with Comms

    • Proprietary - This logging mechanism belongs to the component itself. A few components still use their own logging mechanisms, but these usually behave similarly to Flogger in that to obtain the logs the appropriate folder needs to exist while the component is running.

    Note: When you enable logging for a component, the component may run significantly slower as it performs the logging. This could make reproducing a problem more difficult if the reduced component execution performance changes the sequence of events leading to the problem.

    Post-processing CDU log files

    The CDU log file format is designed to be viewed unprocessed. However, in some cases post-processing is required. Two post-processing tools are available:

    • Splitlog - is supplied in epoc32\tools and splits the single log.txt file into multiple files by each unique tag combination. This tool is used to extract embedded binary logging such as that for PPP described below in Component-Specific Debugging Help.

    • Networking Message Sequence Display Tool - processes a standard log.txt file to extract the Comms Framework messages and generates HTML/SVG output files for display on a suitable SVG-enabled browser.

      Figure 1 - Example SVG output from the Message Sequence Display Tool -
    Default CDU

    CDU provides a default configuration file which lists all the known components which use it, and also provides a reference listing of iby files and their respective component source code and log tags. Figure 2 provides a snapshot of the configuration file:

    +
    Default CDU

    CDU provides a default configuration file which lists all the known components which use it, and also provides a reference listing of iby files and their respective component source code and log tags. Figure 2 provides a snapshot of the configuration file:

    Figure 2 - The default commsdbg.ini file -

    The default CDU file is located at ..\comms-infras\commsdebugutility\group\commsdbgdefault.ini and is available for the emulator in epoc32\<data|release\winscw\<udeb|urel>>\z\resource\commsdbg.ini.

    Interpreting the log files

    Comms components have specific log file schemes with some similarities. The following are guidelines for interpreting the files:

    • Errors are logged - when a panic or other serious error condition is encountered. Often the last few log lines includes where the critical condition was reached, since usually the panic code or error code alone is not enough. If not, then often searching for "warning" or "error" in the earlier logging will identify where the problem began.

    • Multi-threaded module output prefixes thread number - ESock and the C32 Serial Server prefix the log lines with the thread number within the specific thread numbering scheme. For example:

      esock esock a 2e W0: CWorkerThread::ConstructL Init RS ChannelHandler +

      The default CDU file is located at ..\comms-infras\commsdebugutility\group\commsdbgdefault.ini and is available for the emulator in epoc32\<data|release\winscw\<udeb|urel>>\z\resource\commsdbg.ini.

    Interpreting the log files

    Comms components have specific log file schemes with some similarities. The following are guidelines for interpreting the files:

    • Errors are logged - when a panic or other serious error condition is encountered. Often the last few log lines includes where the critical condition was reached, since usually the panic code or error code alone is not enough. If not, then often searching for "warning" or "error" in the earlier logging will identify where the problem began.

    • Multi-threaded module output prefixes thread number - ESock and the C32 Serial Server prefix the log lines with the thread number within the specific thread numbering scheme. For example:

      esock esock a 2e W0: CWorkerThread::ConstructL Init RS ChannelHandler esock esock a 32 W4: SocketServer::InitL() Done! esock Booting a 32 W4: CWorkerThread::ConstructL Init ProtocolManager

      The log lines indicate that ESock's Worker zero - the main thread - has initiated construction of its Rootserver (RS) communications channel, while Worker four has started constructing the Protocol Manager.

      Note: The "2e" and "32" numbers are the kernel's own numbers for these threads.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0F09110F-3C4C-57D9-BA7D-19DD9A06B33B.dita --- a/Symbian3/SDK/Source/GUID-0F09110F-3C4C-57D9-BA7D-19DD9A06B33B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0F09110F-3C4C-57D9-BA7D-19DD9A06B33B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Editing media files

    You can use the MVS to edit media files (or "clips"). You can either crop a newly recorded file before saving it, or specify that only a portion of a saved file should play.

    Cropping a file

    You can crop a file - remove a specified number of seconds from the beginning or end of a file open for record - before saving it.

    Note: The audio or video cropped is deleted from the file and cannot be retrieved.

    To crop a file:

    1. In the Edit menu, click SetCropWindow. The Crop This Clip dialog box is displayed.

    2. Select the position of the Crop: offset from either the beginning or the end of the clip.

    3. Enter the Cropping Point: the offset in seconds.

    4. Click Crop! to crop the clip.

    Selecting a portion of a file to play

    Before you play a media file you can specify that you want to play only a portion of it.

    To select a portion of clip for playing:

    1. In the Edit menu, click Set PlayWindow. This displays the Set PlayWindow dialog box.

    2. Enter the Start and End times of the portion in milliseconds.

    3. Click OK to confirm the clip length.

      When you play the clip, only the selected portion is played.

    Clearing a selected portion

    To set the portion to play back to its original value (entire clip): from the Edit menu, click ClearPlayWindow.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Recording media files

    Playing media files

    Configuring and clearing files

    \ No newline at end of file +Editing media files

    You can use the MVS to edit media files (or "clips"). You can either crop a newly recorded file before saving it, or specify that only a portion of a saved file should play.

    Cropping a file

    You can crop a file - remove a specified number of seconds from the beginning or end of a file open for record - before saving it.

    Note: The audio or video cropped is deleted from the file and cannot be retrieved.

    To crop a file:

    1. In the Edit menu, click SetCropWindow. The Crop This Clip dialog box is displayed.

    2. Select the position of the Crop: offset from either the beginning or the end of the clip.

    3. Enter the Cropping Point: the offset in seconds.

    4. Click Crop! to crop the clip.

    Selecting a portion of a file to play

    Before you play a media file you can specify that you want to play only a portion of it.

    To select a portion of clip for playing:

    1. In the Edit menu, click Set PlayWindow. This displays the Set PlayWindow dialog box.

    2. Enter the Start and End times of the portion in milliseconds.

    3. Click OK to confirm the clip length.

      When you play the clip, only the selected portion is played.

    Clearing a selected portion

    To set the portion to play back to its original value (entire clip): from the Edit menu, click ClearPlayWindow.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Recording media files

    Playing media files

    Configuring and clearing files

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0F593BE1-1220-4403-B04E-B8E8A9A49701.dita --- a/Symbian3/SDK/Source/GUID-0F593BE1-1220-4403-B04E-B8E8A9A49701.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0F593BE1-1220-4403-B04E-B8E8A9A49701.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ of displays varies among legacy S60 devices and devices based on the Symbian platform, as do the keys available for input.

    -Device display and keypad controls +Device display and keypad controls

    The display consists of the following elements:

    • Window - An area on the display. There are windows @@ -31,7 +31,7 @@

    Windows

    The following figure illustrates a typical window for an application:

    -Symbian UI window +Symbian UI window

    Typically, a window contains a status pane, a main pane, and a control pane.

    @@ -62,17 +62,17 @@ tree structure forms the basis for navigation, with mobile device users moving from one node, which represents a state, to another.

    The figure below illustrates an example of a basic state hierarchy.

    -Example of a basic state hierarchy in an application +Example of a basic state hierarchy in an application
    Tabs

    The Symbian UI supports tabs, which allow you to collect information for a state onto different pages. These tabs exist in the same node of the navigation hierarchy. The concept of tabs is related to the term view.

    The following figure illustrates the use of tabs in an application.

    -Windows with tabs +Windows with tabs

    The following figures illustrates how tabs appear in the navigation hierarchy.

    -Example of a hierarchy with tabs +Example of a hierarchy with tabs

    See also:

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0F784804-8452-4C92-ABB3-56B81BAED744.dita --- a/Symbian3/SDK/Source/GUID-0F784804-8452-4C92-ABB3-56B81BAED744.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0F784804-8452-4C92-ABB3-56B81BAED744.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@
    Architecture Sensor Services Architecture - +

    The Sensor Services collection consists of the following components:

    • Sensor Framework, which provides sensor server and plug-in interfaces for adding any new sensor plug-in as required. The framework also provides diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0F8D0399-58CD-4EB6-82DF-75D6BE5B0A84.dita --- a/Symbian3/SDK/Source/GUID-0F8D0399-58CD-4EB6-82DF-75D6BE5B0A84.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0F8D0399-58CD-4EB6-82DF-75D6BE5B0A84.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,35 +1,30 @@ - - - - - -Application -framework concepts -

      The application framework contains a set of libraries and components -provided by the Symbian platform to make common functions available to applications. -Examples of the available functions include:

      -
        -

      • application -launching

        • -

      • event -handling

        • -

      • internationalization -and localization

        • -

      • keyboard and pointer support

        -
        • -
      -

      All GUI-based applications use the application framework architecture. -You must derive the application classes from base classes provided by AVKON. -For more information on the classes involved in the application framework, -see Framework -requirements for GUI applications. For more -information on the UI, see UI concepts.

      -

      In addition, the following concepts are relevant in the context of the -application framework:

      + + + + + +Application framework concepts +

      The application framework contains a set of libraries and components +provided by the Symbian platform to make common functions available +to applications. Examples of the available functions include:

      +
        +

      • application launching

        • +

      • event handling

        • +

      • internationalization and localization

        • +

      • keyboard and pointer support

        +
        • +
      +

      All GUI-based applications use the application framework architecture. +You must derive the application classes from base classes provided +by AVKON. For more information on the classes involved in the application +framework, see Framework +requirements for GUI applications. For more information on the UI, see UI concepts.

      +

      In addition, the following concepts are relevant in the context +of the application framework:

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0FB60233-993A-4BF2-9E8C-E03AD092359B.dita --- a/Symbian3/SDK/Source/GUID-0FB60233-993A-4BF2-9E8C-E03AD092359B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-0FB60233-993A-4BF2-9E8C-E03AD092359B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,35 +1,33 @@ - - - - - -Managing -resource files -

      In the Symbian platform, resource files -are used to define UI components such as status panes, CBA -(Control Button Area) buttons, menu -bars, views, -dialogs, strings, and constants used in applications. The UI components consist -of data structures that are defined in resource files. These data structures -are then invoked from the classes controlling the UI implementation. When -UI component implementation is split into these two approaches, it means that -resources can be recompiled, for example for new languages, without having -to recompile the application code (unless you change the resource identifiers).

      -

      This section includes the following:

      - -

      For demonstration purposes, the sections on resources contain examples -with arbitrary values. In your own code, it is recommend that you use a system -of easy to remember value names.

      -       -

      For an introduction to the UI, see UI concepts.

      -

      For more information on resources, resource files, and their use in -the Symbian platform, see Resource -Files.

      -

      This section explains the following:

      + + + + + +Managing resource files +

      In the Symbian platform, resource files +are used to define UI components such as status panes, CBA (Control Button +Area) buttons, menu bars, views, dialogs, +strings, and constants used in applications. The UI components consist +of data structures that are defined in resource files. These data +structures are then invoked from the classes controlling the UI implementation. +When UI component implementation is split into these two approaches, +it means that resources can be recompiled, for example for new languages, +without having to recompile the application code (unless you change +the resource identifiers).

      +

      This section includes the following:

      + +

      For demonstration purposes, the sections on resources contain +examples with arbitrary values. In your own code, it is recommend +that you use a system of easy to remember value names.

      +       +

      For an introduction to the UI, see UI concepts.

      +

      For more information on resources, resource files, and their +use in the Symbian platform, see Resource Files.

      +

      This section explains the following:

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0FD02CAD-B687-50C0-8E44-74ED9B4A936E_d0e363580_href.png Binary file Symbian3/SDK/Source/GUID-0FD02CAD-B687-50C0-8E44-74ED9B4A936E_d0e363580_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0FD02CAD-B687-50C0-8E44-74ED9B4A936E_d0e382729_href.png Binary file Symbian3/SDK/Source/GUID-0FD02CAD-B687-50C0-8E44-74ED9B4A936E_d0e382729_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0FF61B9C-8B0D-5369-B0DA-29AA169B4308_d0e79670_href.png Binary file Symbian3/SDK/Source/GUID-0FF61B9C-8B0D-5369-B0DA-29AA169B4308_d0e79670_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-0FF61B9C-8B0D-5369-B0DA-29AA169B4308_d0e79728_href.png Binary file Symbian3/SDK/Source/GUID-0FF61B9C-8B0D-5369-B0DA-29AA169B4308_d0e79728_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10540A35-7E8E-40F0-BF93-CBC01884550C_d0e5523_href.png Binary file Symbian3/SDK/Source/GUID-10540A35-7E8E-40F0-BF93-CBC01884550C_d0e5523_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10540A35-7E8E-40F0-BF93-CBC01884550C_d0e5644_href.png Binary file Symbian3/SDK/Source/GUID-10540A35-7E8E-40F0-BF93-CBC01884550C_d0e5644_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-107AE89E-901E-535F-8D1A-EE347D7822B1.dita --- a/Symbian3/SDK/Source/GUID-107AE89E-901E-535F-8D1A-EE347D7822B1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-107AE89E-901E-535F-8D1A-EE347D7822B1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,12 +40,12 @@ Figure 1 - The architecture and the appropriate APIs at each level - + Figure 2 - The architecture with three CSYs loaded - +

      Each serial port has a limited availability when multiple clients attempt to use the port. The Serial Communications Server provides some functionality diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-107F7BC4-F776-512D-AD6F-1674B7ED19B5_d0e281237_href.png Binary file Symbian3/SDK/Source/GUID-107F7BC4-F776-512D-AD6F-1674B7ED19B5_d0e281237_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-107F7BC4-F776-512D-AD6F-1674B7ED19B5_d0e286076_href.png Binary file Symbian3/SDK/Source/GUID-107F7BC4-F776-512D-AD6F-1674B7ED19B5_d0e286076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10C32642-CF1C-5C60-A81B-9D65F03A45C4_d0e220786_href.png Binary file Symbian3/SDK/Source/GUID-10C32642-CF1C-5C60-A81B-9D65F03A45C4_d0e220786_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10C32642-CF1C-5C60-A81B-9D65F03A45C4_d0e225780_href.png Binary file Symbian3/SDK/Source/GUID-10C32642-CF1C-5C60-A81B-9D65F03A45C4_d0e225780_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10CF321F-3298-4527-BFF5-0351085C7C8C.dita --- a/Symbian3/SDK/Source/GUID-10CF321F-3298-4527-BFF5-0351085C7C8C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-10CF321F-3298-4527-BFF5-0351085C7C8C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,6 +19,6 @@ other double item types, too.

      Setting list containing a non-setting item to access another view - +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-10F1D390-2CB6-584B-B760-E6A6E1D8FDDA.dita --- a/Symbian3/SDK/Source/GUID-10F1D390-2CB6-584B-B760-E6A6E1D8FDDA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,18 +0,0 @@ - - - - - -C++ pre-processor statements

      The following pre-processor statements are supported by the resource compiler:

      • #define

      • #undef

      • #line

      • #include

      • #ifdef

      • #ifndef

      • #if

      • #else

      • #endif

      The following sections give more detail on the use of the #ifdef and #include statements.

      Conditional compilation in resource files

      The resource compiler supports conditional compilation such as

      #ifdef SOMETHING -// do something -#else -// do something else -#endif

      or

      #ifndef WHATEVER -// do something -#endif
      Include files within a source file

      You can include files within the source file by using a #include directive, for example:

      #include <eikdef.rh>

      or

      #include "eikdef.hrh"

      The searching algorithm used by the resource compiler depends on whether the item to be included is enclosed in double-quotes or angled brackets.

      If the filename is enclosed in double-quotes, the resource compiler searches for that file through the following directories in the following order:

      • the current directory

      • the relative directory ..\inc

      • the absolute directory epocroot \epoc32\include

      If the filename is enclosed in angled brackets, the resource compiler searches for that file through the following directories in the following order:

      • the relative directory ..\inc

      • the absolute directory epocroot \epoc32\include

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1158BDD3-69F7-5892-9887-FAE30110E33C_d0e333499_href.png Binary file Symbian3/SDK/Source/GUID-1158BDD3-69F7-5892-9887-FAE30110E33C_d0e333499_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1158BDD3-69F7-5892-9887-FAE30110E33C_d0e339965_href.png Binary file Symbian3/SDK/Source/GUID-1158BDD3-69F7-5892-9887-FAE30110E33C_d0e339965_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e51581_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e51581_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e51724_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e51724_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e56285_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e56285_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e56428_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e56428_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e68838_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e68838_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e68862_href.png Binary file Symbian3/SDK/Source/GUID-11A79174-485E-425C-9653-193B670A3F03_d0e68862_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11BF98BD-814A-5CB8-B83E-6D14F38F1783.dita --- a/Symbian3/SDK/Source/GUID-11BF98BD-814A-5CB8-B83E-6D14F38F1783.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,70 +0,0 @@ - - - - - -ENUM -statement -<enum-statement> -enum-statement ::= -enum [<enum-label> ] { <enum-list> }; -

      Use an enum (or an ENUM) statement to -define a set of integer values. The values are associated with symbols defined -in the enum-list; the syntax and the semantics are compatible -with those of C++ enumerations. Note that the final semi-colon in an enum may -be omitted; however, to retain compatibility with the C++ compiler, it is -advisable to retain it.

      -

      Each member of the enum-list is followed by a comma except -for the last one. The syntax of a member is defined as:

      -<enum-member> -enum-member ::= -<member-name> [ = <initialiser> ] -

      The defined enumerator symbols can be used in both C++ code and resource -scripts and are commonly defined in files which have the conventional file -extension hrh. The .hrh files are -included in both C++ files and resource source files.

      -

      In general, each enumerator can be assigned a specific value. If no value -is explicitly assigned, the value generated by the resource compiler is the -value of the previous enumerator plus one. If the first enumerator is not -assigned an explicit value, it defaults to 0.

      -

      The assigned value can be coded in either hexadecimal or plain decimal -notation.

      -

      The enum definition:

      enum - { - EExampleCmdIdFirst=0x100, - EExampleCmdIdSecond, - EExampleCmdIdThird, - EExampleCmdIdFourth - };

      defines the enumerators EExampleCmdIdFirst, EExampleCmdIdSecond etc. -and assigns values to them. EExampleCmdIdFirst is assigned -the value 0x100 (decimal 256), EExampleCmdIdSecond is -assigned the value 0x101 (decimal 257) etc.

      enum { - testvalue1=10, - testvalue2, - testvalue3=20, - testvalue4 - }; - -STRUCT TEST1 - { - BYTE b1; - BYTE b2; - BYTE b3; - BYTE b4; - } - -RESOURCE TEST1 test - { - b1=testvalue1; - b2=testvalue2; - b3=testvalue3; - b4=testvalue4; - }

      In this example the resource generated is: 0x0A 0x0B -0x14 0x15

      -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11C24609-3B6D-4B44-B003-FB0C07444A9E.dita --- a/Symbian3/SDK/Source/GUID-11C24609-3B6D-4B44-B003-FB0C07444A9E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-11C24609-3B6D-4B44-B003-FB0C07444A9E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ is displayed also on pop-up components.

      Scroll pane with scrollbar - +

      • The placement of the scroll handle on the scrollbar reflects the position diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11CBC0BA-3683-584A-9DC9-8BD3C9573F01_d0e107251_href.png Binary file Symbian3/SDK/Source/GUID-11CBC0BA-3683-584A-9DC9-8BD3C9573F01_d0e107251_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11CBC0BA-3683-584A-9DC9-8BD3C9573F01_d0e107483_href.png Binary file Symbian3/SDK/Source/GUID-11CBC0BA-3683-584A-9DC9-8BD3C9573F01_d0e107483_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11E35C60-12DF-4014-AB3F-0314D8536AC0_d0e14831_href.png Binary file Symbian3/SDK/Source/GUID-11E35C60-12DF-4014-AB3F-0314D8536AC0_d0e14831_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-11E35C60-12DF-4014-AB3F-0314D8536AC0_d0e14925_href.png Binary file Symbian3/SDK/Source/GUID-11E35C60-12DF-4014-AB3F-0314D8536AC0_d0e14925_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1277D793-4A0A-50A7-9414-AEE93E906E80.dita --- a/Symbian3/SDK/Source/GUID-1277D793-4A0A-50A7-9414-AEE93E906E80.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1277D793-4A0A-50A7-9414-AEE93E906E80.dita Tue Jul 20 12:00:49 2010 +0100 @@ -51,7 +51,7 @@ API functions.

        Figure 1 - The Socket Server's position in the Communications Framework Architecture. - +

        The TCP/IP API enables clients to use sockets for TCP/IP, including UDP, TCP, ICMP, IPv4, IPv6, ARP, and DNS.

        The IrDA Sockets API enables clients to use sockets for IrDA infra-red.

        The Bluetooth Sockets API diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1293DE8C-E803-4ADF-9FA8-862519337331.dita --- a/Symbian3/SDK/Source/GUID-1293DE8C-E803-4ADF-9FA8-862519337331.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1293DE8C-E803-4ADF-9FA8-862519337331.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,40 +9,38 @@ --> -Software -installer -

        End users can install new software from a variety of sources: through -e-mail, Internet downloads, multimedia messaging service (MMS) and WAP push -messages, infrared and Bluetooth connections, PC Suite, and removable memory -cards. The diversity of software vendors and delivery channels requires a -sophisticated system for managing installed software.

        -

        The Symbian Software Installer uses digital signatures and certificates to -authenticate that the application being installed on a mobile device is from -a known vendor. The signature can be obtained through the Symbian -Signed process, and the default certificates installed in the mobile -device act as root certificates. During installation the signature is validated -against the certificates. If they match, the application is installed and -the requested capabilities are -stored in the executable, assuming that the root certificate can grant the -capabilities. Only user capabilities can be granted to unsigned or -self-signed applications, and these are always confirmed by the user.

        +Software installer +

        End users can install new software from a variety of sources: +through e-mail, Internet downloads, multimedia messaging service (MMS) +and WAP push messages, infrared and Bluetooth connections, PC Suite, +and removable memory cards. The diversity of software vendors and +delivery channels requires a sophisticated system for managing installed +software.

        +

        The Symbian Software Installer uses digital signatures and certificates to authenticate that the application being +installed on a mobile device is from a known vendor. The signature +can be obtained through the Symbian Signed process, and the default certificates installed in the mobile device +act as root certificates. During installation the signature is validated +against the certificates. If they match, the application is installed +and the requested capabilities are stored in the executable, assuming that the +root certificate can grant the capabilities. Only user capabilities can be granted to unsigned or self-signed applications, and these +are always confirmed by the user.

        -

        The end users have an option to cancel the installation if they detect -that the vendor of the software package and certificate authority are not -trustworthy. This is especially important when installing security-related -components (for example, VPN clients, firewalls and virus scanners) or other -business-related software.

        +

        The end users have an option to cancel the installation if they +detect that the vendor of the software package and certificate authority +are not trustworthy. This is especially important when installing +security-related components (for example, VPN clients, firewalls and +virus scanners) or other business-related software.

         -

        The Software Installer ensures that no two applications have the same SID value -on a particular target device. The Software Installer has the TCB capability -to read and modify content in the \sys folder -and all its subfolders, which means that you can write to third-party application -executables in the \sys\bin folder when they are installed -through the Software Installer.

        -

        For more information on the Software Installer, see Secure -Software Install Tools.

        +

        The Software Installer ensures that no two applications have +the same SID value on a particular target device. The Software Installer +has the TCB capability to read and modify content +in the \sys folder and all its subfolders, which means +that you can write to third-party application executables in the \sys\bin folder when they are installed through the Software +Installer.

        +

        For more information on the Software Installer, see Secure Software Install +Tools.

        The following figure illustrates the steps of software installation:

        -Installation process for signed packages +Installation process for signed packages

        The Software Installer can install the following types of packages:

        • signed sis packages

          • @@ -50,9 +48,10 @@

        • Web Runtime widgets

        -

        The Software Installer recognizes different devices, which allows you -to define the platforms and devices to which the software can be installed.

        +

        The Software Installer recognizes different devices, which allows +you to define the platforms and devices to which the software can +be installed.

        -

        If you receive an error message when using the Software Installer, see Troubleshooting -Installation Errors at the Symbian Foundation.

        +

        If you receive an error message when using the Software Installer, +see Troubleshooting Installation Errors at the Symbian Foundation.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280.dita --- a/Symbian3/SDK/Source/GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280.dita Tue Jul 20 12:00:49 2010 +0100 @@ -120,7 +120,7 @@

        How APIs related to the 3-Plane Comms Architecture.

        Figure 1 - How ESock APIs related to the 3-Plane Comms Architecture - +

        The Sockets Client API also defines a number of support classes used in conjunction with the above interfaces. These encapsulate:

        • Addresses: a diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-12D8C373-5199-5B89-9910-00F769AC164A.dita --- a/Symbian3/SDK/Source/GUID-12D8C373-5199-5B89-9910-00F769AC164A.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,42 +0,0 @@ - - - - - -How -to build EXEs -

          An .EXE program typically has a single executable component. Unlike GUI -application targets there is no application information file, and in most -cases a resource file will not be needed.

          -

          Under WINS/WINSCW, the C++ source is compiled to object files in the build -directory; these are then linked, together with standard libraries, into the -release directory. You may run the program directly from the release directory.

          -

          Under ARM targets, the C++ source is compiled using a native compiler, -and then linked into a .exe in the release directory. -You may then transfer the program to the target machine and execute it.

          -
          mmp project specification

          For an EXE -target, only a minimum of essential information need be specified:

            -

          • Specify the TARGETTYPE line -as:

            TARGETTYPE exe
            • -

          • Specify the UID as -zero in a UID line:

            UID 0

            EXEs -do not strictly speaking need a UID value. However specifying zero suppresses -a build tools warning.

            • -
          -

          An example of the project file for a console program is given -below

          TARGET HelloWorld.exe -TARGETTYPE exe -UID 0 -SOURCEPATH . -SOURCE HelloWorld.cpp -USERINCLUDE . -USERINCLUDE ..\CommonFramework -SYSTEMINCLUDE \Epoc32\include -LIBRARY euser.lib           - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-130C21D7-0A39-5A54-8545-C82B2ED4398C.dita --- a/Symbian3/SDK/Source/GUID-130C21D7-0A39-5A54-8545-C82B2ED4398C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-130C21D7-0A39-5A54-8545-C82B2ED4398C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@

          This state diagram shows how to dial or answer one or two calls at a time.

          Simultaneous Call State Diagram - +

          The boxes are states. The enumeration value in each box is the status of the voice line. Voice line status describes these states and their meaning. The arrows show diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1319CEA4-56D7-45DF-9C22-45291017992E_d0e4709_href.png Binary file Symbian3/SDK/Source/GUID-1319CEA4-56D7-45DF-9C22-45291017992E_d0e4709_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1319CEA4-56D7-45DF-9C22-45291017992E_d0e4835_href.png Binary file Symbian3/SDK/Source/GUID-1319CEA4-56D7-45DF-9C22-45291017992E_d0e4835_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1376F42B-1B1E-431E-8E60-4FDBAD34EA15.ditamap --- a/Symbian3/SDK/Source/GUID-1376F42B-1B1E-431E-8E60-4FDBAD34EA15.ditamap Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1376F42B-1B1E-431E-8E60-4FDBAD34EA15.ditamap Tue Jul 20 12:00:49 2010 +0100 @@ -3,8 +3,8 @@ -Symbian Developer Library for Application -Developers + +Symbian Developer Library for Application Developers Symbian Developer Library for Application Developers @@ -72,6 +72,8 @@ + @@ -223,7 +225,7 @@ @@ -663,7 +665,7 @@ href="GUID-88917386-AD48-4C76-A1C7-46F0B1E85A18.dita"> @@ -1407,8 +1409,6 @@ id="GUID-07673129-E9CE-4FBB-A75C-9330BB6D8F88"> - + + + + + + + + + + + + + + + + + + + + + + + + @@ -2097,7 +2140,45 @@ +id="GUID-20FB2AB8-1C26-44AB-8703-F376D7F55724"> + + + + + + + + + + + + + + + + + + + + @@ -4589,6 +4670,17 @@ id="GUID-3B581533-5C58-450A-B3DD-AF5487478BFB"> + + + + + + - - @@ -5345,6 +5433,35 @@ id="GUID-2E36F0F5-AE57-4E43-B20A-F43B100A8713"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -5397,12 +5823,12 @@ @@ -5855,337 +6281,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -6332,9 +6427,9 @@ +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1-1-3"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1-1-3-1-7"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1-1-4-1-5"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1-1-4-1-6"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-29-1-1-4-1-7"> +id="GUID-4EA3767E-BC4E-4CFC-A371-BC1CC73AD6E9-GENID-1-10-1-30-1-1-3"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13987218-9427-455E-AC77-ADE6B0E9CD7E.dita --- a/Symbian3/SDK/Source/GUID-13987218-9427-455E-AC77-ADE6B0E9CD7E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-13987218-9427-455E-AC77-ADE6B0E9CD7E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,7 +40,7 @@

        For more information about layers of the Symbian platform and the packages contained within it, see the Package view of the current Symbian Foundation platform.

        Architecture of the Symbian platform - +

        A layer can have packages from any technology domain. Technology domains are a group of packages, each of which is a collection of components. To understand more about the architecture, what the platform offers, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-139E7235-4F23-5F0E-A969-6D7165AE5298.dita --- a/Symbian3/SDK/Source/GUID-139E7235-4F23-5F0E-A969-6D7165AE5298.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --inv or -invariant

        By default all DLLs are considered to be variant across all feature variant builds.

        To disable considering all DLLs as variants, use -inv or -invariant option.

        abld -inv build armv5.myvar

        A DLL marked as FEATUREVARIANT in its .mmp file remains variant, even if -invariant or -inv option is specified in the abld command.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13AA46F9-7D5E-5BBE-8021-C9326121E605.dita --- a/Symbian3/SDK/Source/GUID-13AA46F9-7D5E-5BBE-8021-C9326121E605.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -srcdbg

        srcdbg

        Use the srcdbg statement to disable the use of optimisation in debug builds. This makes it significantly easier to step through the execution of code with a source-level debugger.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13C95985-D16F-5A9E-A7F8-CAB637C4C6ED.dita --- a/Symbian3/SDK/Source/GUID-13C95985-D16F-5A9E-A7F8-CAB637C4C6ED.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-13C95985-D16F-5A9E-A7F8-CAB637C4C6ED.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,7 +39,7 @@ entries in a file to be modified. The database implementations use these stores for the underlying data storage.

        DBMS Class Diagrams - +
        DBMS Summary

        DBMS provides the following:

        • Database Management diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13D48922-4DEF-56A6-8ADE-DD1DB280627B_d0e396107_href.png Binary file Symbian3/SDK/Source/GUID-13D48922-4DEF-56A6-8ADE-DD1DB280627B_d0e396107_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13D48922-4DEF-56A6-8ADE-DD1DB280627B_d0e399902_href.png Binary file Symbian3/SDK/Source/GUID-13D48922-4DEF-56A6-8ADE-DD1DB280627B_d0e399902_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13DEE42F-3EAB-4EB7-9CE1-C4930BCACE01.dita --- a/Symbian3/SDK/Source/GUID-13DEE42F-3EAB-4EB7-9CE1-C4930BCACE01.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-13DEE42F-3EAB-4EB7-9CE1-C4930BCACE01.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ layouts.

          List query - +

          The number of items in the list should be kept low, so that all items can be seen without scrolling.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13F10D4C-BA0C-5B46-804D-191A70C36324_d0e287313_href.png Binary file Symbian3/SDK/Source/GUID-13F10D4C-BA0C-5B46-804D-191A70C36324_d0e287313_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-13F10D4C-BA0C-5B46-804D-191A70C36324_d0e292144_href.png Binary file Symbian3/SDK/Source/GUID-13F10D4C-BA0C-5B46-804D-191A70C36324_d0e292144_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-141633B8-A3D4-5BBB-97C5-3D928746ECE7.dita --- a/Symbian3/SDK/Source/GUID-141633B8-A3D4-5BBB-97C5-3D928746ECE7.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,303 +0,0 @@ - - - - - -Resource -localisable strings -

          Resource localisable strings (RLS) are defined in the resource files. Each -RLS item definition is a new-line separated entry in the resource file, using -literals to define a localisable string, number or character.

          -

          Defining RLS items

          -

          The following literals can be used to define an RLS item:

          -
    - - - -Name -Description - - - - -

    rls_string

    -

    Use this literal to define a 16-bit Unicode string

    -     - -

    rls_string8

    -

    Use this literal to define an 8-bit Unicode string

    -     - -

    rls_byte

    -

    Use this literal to define an 8-bit number

    -     - -

    rls_word

    -

    Use this literal to define a 16-bit number

    -     - -

    rls_long

    -

    Use this literal to define a long number

    -     - -

    rls_double

    -

    Use this literal to define a decimal number

    -     -     - -
    -

    BNF description

    -

    <rls-file> -

    -

    rls-file ::= -

    -

    <rls-entry>* <rls-entry> -

    -

    rls-entry ::= -

    -

    <rls-item> <rls-item> -

    -

    rls-item ::= -

    -

    <type>[<length> <cardinality>] <symbolic-identifier> -<value> <type> -

    -

    type ::= -

    -

    rls_string | rls_string8 | rls_byte | rls_word | rls_long | -rls_double <value> -

    -

    value ::= -

    -

    <text> | <number>

    -

    where,

    - - - - -

    length

    -

    The optional maximum length of the text applicable -to rls_string or rls_string8 types only

    -     - -

    cardinality

    -

    You can use the optional keyword qualifier "multi", which indicates -that the localisable item may be used by more than one resource

    -     - -

    symbolic-identifier

    -

    A unique ID for the localisable string or number

    -     - -

    text

    -

    This is a string expression, which may include a string enclosed -in double quotes (") and a character code enclosed in angle brackets (<>)

    -     - -

    number

    -

    A numeric value for the literals rls_byte, rls_word, rls_long and rls_double

    -     - - -
    -

    The following example shows how to define an RLS string and number:

    -rls_string<32> STRING_1 "Example menu item"<0x2026> -rls_byte multi NUMBER_1 17 - -

    Characters are declared using the RLS type identifiers rls_byte, rls_word or rls_long. -The type identifier to be used depends on the type of the structure member -they will be included into. However, the value can be declared within single -quotes. For example:

    - - rls_long hotkey_zoomin 'M' -

    Commenting RLS items

    -

    RLS items can be tagged with appropriate comments, which are placed just -before each RLS item declaration. Optionally, if a RESOURCE declaration -contains localisable data, a comment can precede the RESOURCE declaration.

    -

    These comments save time and cost in localisation, and improve quality -of localised text. If you supply more context information to the translators -(maximum string length allowed, the details of the GUI in which their text -will be displayed), the quality of the localised text is better. This will -also reduce the need for re-translating the text.

    -

    The localisation comments must be enclosed within the comment brackets -/*&...*/. These comment brackets include a set of tags to provide more -details about the RLS item.

    -

    The resource compiler (epocrc) can warn if comments are -missing. A Symbian platform licensee can configure the epocrc tool -to emit warnings for missing comments through the epocrc configuration file.

    -

    The following is a list of tags used within the comment brackets:

    -
      -

    • @localize: -This is an optional tag used to specify whether to allow the translator to -change the string or not. The translator is allowed to change the RLS item, -only if the tag is set to 'yes'. To disallow any change to -the RLS item, set it to 'no'. By default, the translator -is allowed to change an RLS item, if the corresponding localisation comment -does not include this tag.

      For example:

      /*& -@localize yes -*/ -rls_string STRING_1 "Device locked" -
      • -

    • @description: -This is mandatory tag used to provide a description about the RLS item. This -tag is used to provide the following information to the translator:

        -

      • The context in which -the string is used and the purpose of the dialog or views using the string.

        • -

      • Its relationships with -other strings.

        • -

      • If the localisable strings -represent file names or URIs that must point to existing objects, describe -those objects briefly.

        • -

      • If the RLS items are -tagged with @restriction other, describe the restriction.

        • -
      • -

    • @restriction: -This is an optional tag used to specify the scope of the RLS item. The possible -values for this tag are:

        -

      • uri to -specify that the localisable item is an URI. If the URI changes, the resulting -URI should be a valid URI pointing to the correct object. The description -in the comment bracket can be used to give more details about the URI.

        • -

      • file to -specify that the localisable item is a file name. If the file changes, the -ROM must be rebuilt to accommodate the change. If the full path of the file -is not given, the description for the localisable item can be used to provide -more details.

        • -

      • trademark to -specify that the localisable item is a trademark. The trademark differs from -country to country, but any change to it must be subject to trademark owner's -rules. The description for the localisable item can be used to provide more -details.

        • -

      • other to -specify that the localisable item is none of the above. In such a case, the -description should include the effects of changing the localisable item and -the constraints.

        • -

      For example:

      /*& @description Must point to the happy bugle wave file, used as a ring tone and displayed to the user in the ring-tone selection dialog. -@localize yes -@restriction file -*/ -rls_string STRING_2 "happy bugle.wav" -
      • -

    • @uicontext: -This is a mandatory tag for RLS items defined using rls_string and rls_string8. -It is used to specify the type of widget in which the localisable item is -used. There is a list of UI contexts for Symbian developers, which are extended -by the platform suppliers. The Symbian developers must use the values defined -for the platforms on which they are developing.

      The possible values -for this tag are:

        -

      • notvisible to -specify that the item does not appear in the UI.

        • -

      • pluginname to -specify that the string is the name of an ECOM (or other) plug-in.

        • -

      • system to -specify that the item may appear in the UI, but the component that supplies -the UI does not mandate where.

        • -

      • errortext to -specify that the string is used by the error resolver.

        • -

      • fragment to -specify that the item is part of a string that appears in the UI. For example, -a list separator.

        • -

      • appname to -specify the application name in the APP_REGISTRATION_INFO structure.

        • -

      • appgroup to -specify the application group in the APP_REGISTRATION_INFO structure.

        • -

      For example:

      /*& -@uicontext pluginname -*/ -rls_string STRING_1 "Device locked" -
      • -

    • @group: -This is an optional tag used to group strings together. For example, you can -group all strings that appear in the same view together. To group strings -under a group, you have to define a group using the following syntax:

      @tagvalue group <your-group-name> [group-description]

      Where, your-group-name is a name for the group, and group-description is an -optional description about the group.

      For example,

      /*& -@tagvalue group lock_dialog -*/ -

      You can use the group defined above as follows:

      /*& -@localize yes -@group lock_dialog -*/ -rls_string STRING_1 "Device locked" -
      • -

    • @uispec: -This is an optional tag used to specify where in the specifications document -the RLS item appears.

      For example:

      /*& -@uispec UIQ/ringtones-specification.doc/4.31 -*/ -rls_string STRING_2 "happy bugle.wav" -
      • -
    -

    Creating new RLS comment tags

    -

    Apart from the pre-defined set of tags listed above, you can also declare -a new tag and use it in the localisation comments. Tags are declared in resource -header files (.rh). You can configure the epocrc tool -to recognise the comment definitions from such files through the epocrc.config configuration -file. For more information, refer to epocrc -configuration file format.

    -

    The following is the BNF description for declaring a new tag:

    -

    <tag-declaration> -

    -

    tag-declaration ::= -

    -

    @declaretag <tag-type> <new-tag-name> -[<description>] <tag-type> -

    -

    tag-type ::= -

    -

    single | multiple | text | void

    -

    Where, tag-type is used to specify the type value the -tag can take. If you want the tag to take a single value, use "single " -as the tag type. If you want the tag to take a single value from a set of -values, use "multiple " as the tag type. For example, the @uicontext tag -is of multiple type. If you want the tag not to take any -value, use "void " as the tag type. If you want the tag to -take free text, use "text " as the tag type. For example, -the @description tag is of text type.

    -

    For example, the following declares a tag called “visible” of type single:

    -@declaretag single visible -

    If you had declared the tag as single or multiple, -you must declare its values. Value declaration is not required for other tag -types.

    -

    The following is the BNF description for declaring values for a tag:

    -

    <tag-value-declaration>

    -

    -tag-value-declaration ::=

    -

    - @tagvalue <tag-name> <list-of-values>

    -

    Where, tag-name is the name of the tag declared earlier. -If the tag is of multiple type, the list-of-values lists -a set of values for the tag, otherwise a single value must be specified.

    -

    For example, the following declares that the permitted value for the visible -tag is "yes":

    -@tagvalue visible yes -

    After declaring the values for the tag, you must specify whether the tag -is required or optional for an RLS item. The BNF description for this is as -follows:

    -

    <tag-required-statement>

    -

    -tag-required-statement ::=

    -

    - @tagrequired <tag-name> <rls-type-identifier> -<tag-optional-statement> -

    -

    tag-optional-statement ::=

    -

    - @tagoptional <tag-name>=[<default-value>] <rls-type-identifier> -<rls-type-identifier> -

    -

    rls-type-identifier ::=

    -

    - rls_string | rls_string8 | rls_byte | rls_word | rls_long | -rls_double

    -

    Where, tag-name is the name of the declared tag, default-value is -the default value used for optional tags.

    -

    For example, the following declares that the visible tag is optional, and -has a default value of “yes” for rls_string items:

    -@tagoptional visible=yes rls_string - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-141D8786-9987-4E5E-9395-484C87B323FB_d0e290621_href.png Binary file Symbian3/SDK/Source/GUID-141D8786-9987-4E5E-9395-484C87B323FB_d0e290621_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-141D8786-9987-4E5E-9395-484C87B323FB_d0e297093_href.png Binary file Symbian3/SDK/Source/GUID-141D8786-9987-4E5E-9395-484C87B323FB_d0e297093_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-14A0FC93-2AD9-5B33-B423-2CCAD3C96B5F.dita --- a/Symbian3/SDK/Source/GUID-14A0FC93-2AD9-5B33-B423-2CCAD3C96B5F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -clean

    abld [ test ] clean ( ( [-c] | [-w] ) | ( [-k] [-v] ) ) [ platform ] [ build [ program ] ]

    This command will erase all the files created by the corresponding abld - target command.

    abld clean makes use of the clean targets provided in makefiles generated by makmake.

    The files that are removed by this command include all the intermediate files created during compilation and all the executables and import libraries created by the linker.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15591211-58D3-56B6-868F-D34C30ED7A7A_d0e176040_href.png Binary file Symbian3/SDK/Source/GUID-15591211-58D3-56B6-868F-D34C30ED7A7A_d0e176040_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15591211-58D3-56B6-868F-D34C30ED7A7A_d0e181065_href.png Binary file Symbian3/SDK/Source/GUID-15591211-58D3-56B6-868F-D34C30ED7A7A_d0e181065_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-155C5B39-CB9B-5405-B9BB-EB34CA7C43BC_d0e338662_href.png Binary file Symbian3/SDK/Source/GUID-155C5B39-CB9B-5405-B9BB-EB34CA7C43BC_d0e338662_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-155C5B39-CB9B-5405-B9BB-EB34CA7C43BC_d0e345128_href.png Binary file Symbian3/SDK/Source/GUID-155C5B39-CB9B-5405-B9BB-EB34CA7C43BC_d0e345128_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15CAB5AF-CAA5-5D1B-9236-7874BF944484_d0e333212_href.png Binary file Symbian3/SDK/Source/GUID-15CAB5AF-CAA5-5D1B-9236-7874BF944484_d0e333212_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15CAB5AF-CAA5-5D1B-9236-7874BF944484_d0e339678_href.png Binary file Symbian3/SDK/Source/GUID-15CAB5AF-CAA5-5D1B-9236-7874BF944484_d0e339678_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15D5E0D3-B643-5C72-A3D4-03E2480890EF_d0e15332_href.png Binary file Symbian3/SDK/Source/GUID-15D5E0D3-B643-5C72-A3D4-03E2480890EF_d0e15332_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15D5E0D3-B643-5C72-A3D4-03E2480890EF_d0e15514_href.png Binary file Symbian3/SDK/Source/GUID-15D5E0D3-B643-5C72-A3D4-03E2480890EF_d0e15514_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15F209D1-6BC6-5207-B443-25306C232CFC_d0e109548_href.png Binary file Symbian3/SDK/Source/GUID-15F209D1-6BC6-5207-B443-25306C232CFC_d0e109548_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-15F209D1-6BC6-5207-B443-25306C232CFC_d0e109780_href.png Binary file Symbian3/SDK/Source/GUID-15F209D1-6BC6-5207-B443-25306C232CFC_d0e109780_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1635E243-BDC9-55D8-8913-0D2DB622B22C_d0e186764_href.png Binary file Symbian3/SDK/Source/GUID-1635E243-BDC9-55D8-8913-0D2DB622B22C_d0e186764_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1635E243-BDC9-55D8-8913-0D2DB622B22C_d0e191752_href.png Binary file Symbian3/SDK/Source/GUID-1635E243-BDC9-55D8-8913-0D2DB622B22C_d0e191752_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-165EE4DD-C9CA-430B-8377-068A4194716E.dita --- a/Symbian3/SDK/Source/GUID-165EE4DD-C9CA-430B-8377-068A4194716E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-165EE4DD-C9CA-430B-8377-068A4194716E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -46,10 +46,10 @@

    The following illustrations show how applications behave before and after the single-tap changes are made:

    Double-tap enabled: By default, UI component is highlighted. - + Single-tap enabled: By default, no UI component is highlighted. - +     Hide item-specific diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16781448-75CB-5C11-B9E6-288BA3C0B43E.dita --- a/Symbian3/SDK/Source/GUID-16781448-75CB-5C11-B9E6-288BA3C0B43E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -staticlibrary

    staticibrary filename-list

    Use the staticlibrary statement to specify static libraries.

    The staticibrary statement may specify any number of files, and there may be many library statements. Specify the entire filename, e.g. euser.lib.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16950F22-F5DE-4D52-8414-544105BA3200.dita --- a/Symbian3/SDK/Source/GUID-16950F22-F5DE-4D52-8414-544105BA3200.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-16950F22-F5DE-4D52-8414-544105BA3200.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,7 +31,7 @@ and as pop-ups.

    Hierarchical list component - +

    Owing to the need for horizontal scrolling, it is not possible to use tabs in the Navi pane. Typically the hierarchical list component is capable of diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16A1C613-288D-471C-8551-51B61290E28F.dita --- a/Symbian3/SDK/Source/GUID-16A1C613-288D-471C-8551-51B61290E28F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-16A1C613-288D-471C-8551-51B61290E28F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,184 +1,188 @@ - - - - - -Application -Start-Up Time OptimizationIt is important that phone users do not have to wait long for applications -to start. This document summarizes the techniques for optimizing application -start-up time. -

    Introduction -

    The techniques discussed in this document are limited in scope to -application programming. In other words, they do not require modification -of any core OS components or servers. Some of the techniques are general good -practice and are useful to developers at all levels.

    The techniques -can be summarized as follows:

      -

    • Avoid causing unnecessary code to be executed as an effect of your -code.

      • -

    • Defer construction of objects, loading of dynamic libraries (for example, -the application model), and starting servers until you need to use them.

      • -

    • Write efficient code!

      • -
    There is an inevitable trade-off between shortening the start-up -time and introducing latency elsewhere in the application. For example, if -you don’t connect to a server at start-up, you will have to do it later on, -when the application needs to use the server. This may be overcome by a central -component that coordinates background connections, or construction, such as -the view server.
    -
    Measure start-up -time before you start optimizing

    Do not assume you know which methods -take the most time. Pay close attention to iterative and recursive operations. -Many useful tools and techniques are available to help identify poorly performing -code:

      -

    • Software analysis tools, for instance GlowCode and -MetroWerks CodeTEST

      • -

    • The Symbian profiling tool, profiler.exe, which is supplied on DevKits

      • -

    • The RDebug class provides some profiling functions

      • -

    • The TTime class can be used to time blocks of code, but beware of context -switches, otherwise you may end up timing other threads!

      • -

    • Deliberately slowing down suspect blocks of code can reveal whether -or not optimizing it would bring a significant performance improvement.

      • -
    -
    Defer construction -of the application model and other data members

    Many applications -instantiate their components, for instance error handlers, dialogs and menus, -during start-up. In turn, each of these components may instantiate other components, -for instance menu resources and icons. This can bring some benefits, for instance -reducing application complexity, revealing memory allocation problems at start-up -rather than after the application has been running for some time and improving -the runtime performance of the application. However, to minimize application -start-up time, it is recommended to avoid this behavior. Your goal should -be to only do what is immediately necessary during start-up.

    -
    Draw the application -as quickly as possible

    During application start-up, only construct -UI components that appear in the application’s initial view. This applies -especially to the application's implementations of CXxxApplication::CreateDocumentL(), CXxxDocument::ConstructL() and CXxxDocument::CreateAppUiL(), all of which are called -before CXxxAppUi::ConstructL(). Do not read bitmaps, resources, -or any other data associated with the UI from files unless it is necessary.

    In CXxxAppUi::ConstructL(), -make sure CCoeControl::ActivateL() and CCoeControl::DrawNow() are -called on all controls that must be drawn when the application is launched. -Also ensure that the client-side window server command buffer is flushed by -calling Flush() on the application's window server session. -This ensures that there aren't any drawing commands left in the client-side -buffer, after CCoeControl::DrawNow() has completed.

    -
    Minimize the -number of bitmaps used by GUI components

    Often, when a large number -of small images are required by an application, the overhead associated with -loading each bitmap outweighs any benefit associated with their size. Some -possible ways to avoid this are:

      -

    • use text instead,

      • -

    • for very simple graphics, draw directly using drawing primitives rather -than loading a bitmap,

      • -

    • concatenate many small bitmaps into one large bitmap file to reduce -the need to search for and load multiple files.

      • -
    -
    Reduce the -number of redraws

    Some GUI components redraw themselves every time -their data changes. This may not always be necessary. Complicated GUI components -should implement theirDraw() method to only update the area -of the screen that has changed. For example, there is no point in redrawing -a whole list box every time a new item is appended to it. In such cases, a -GUI API should allow you to switch off redrawing. Beware of GUI methods that -cause the object they are called upon to redraw itself.

    Use CCoeControl::DrawDeferred() in -preference to CCoeControl::DrawNow() if possible, because -excessive use of CCoeControl::DrawNow() can cause GUI flicker. -For an explanation, see the documentation for CCoeControl::DrawDeferred().

    -
    Use ROM-based -bitmaps rather than filestore bitmaps

    Uncompressed ROM-based bitmaps -that can be used in place from ROM are approximately three times faster to -use than filestore bitmaps. Using them can bring a significant reduction in -application start-up time.

    Specifying bitmap= instead of file= in the -.OBY and .IBY files when building the ROM causes bitmaps to be uncompressed -before inclusion in the ROM. Other bitmaps need to be uncompressed at runtime, -which impacts performance.

    The drawback of such bitmaps is that they -are large (up to 3 times larger than file based) and cannot be compressed, -although decompressing bitmaps should probably be avoided during start-up -anyway due to the extra processing required.

    If ROM space is limited, -consider using such ROM-based bitmaps only if they are displayed during application -start-up.

    -
    Color depth -matching

    When bitmaps are drawn to the screen, optimum performance -is achieved by ensuring that:

    Bitmap color depth = Window color -depth = Screen device color depth

    If this is the case, no palette -mapping between the different color depths is needed. On real hardware, this -optimization has been found to improve drawing speed by up to ten times. However, -in order to match the screen and window color depth, bitmaps may need to increase -in size and so this optimization is only possible if the increase in ROM or -RAM usage is acceptable.

    -
    Minimize access -to the file system

    The file server can be a major bottleneck during -start-up when virtually all threads are searching for and loading data, libraries -and plug-ins. Therefore reducing file access is one of the most effective -ways to improve performance.

    -
    Minimize the -use of resource files

    Resource files are used for localization and -allow modifications to be made to an application without the need to rebuild -it, but they are expensive to use because they require access to the file -system.

    -
    Do not specify -a default document filename for non document-based applications

    Many -applications on a smartphone do not need to use documents, for example Telephony, -Contacts (this uses the contacts database), Browser and Messaging.

    By -not specifying a default document filename, hundreds of milliseconds can potentially -be saved from such applications' start-up time.

    If an application -uses a document file, application start-up may involve the following steps:

      -

    • reading the name of the last used document file from the application’s -.ini file,

      • -

    • opening the document file, or if one doesn't exist, creating a default -document file, after reading its name from the application's resource file,

      • -

    • writing the name of the last used file to the application’s .ini file -(which is created if it doesn’t exist),

      • -

    • writing an entry to the most recently used file list (mru.dat),

      • -

    • additional document-related processing within CEikonEnv::ConstructAppFromCommandLineL().

      • -

    The default document's name is read from the application's resource -file by CEikAppUi::ProcessCommandParametersL(). There are -two ways of preventing the application from using a default document file:

      -

    • Give the default document a NULL name in the resource file:

      RESOURCE -TBUF { buf=""; }
      • -

    • Override CEikAppUi::ProcessCommandParametersL() to -zero the document name and return EFalse. This method is slightly more efficient -because it avoids reading the default document name from the resource file -altogether:

      TBool CMyAppUi::ProcessCommandParametersL(TApaCommand /*aCommand*/, TFileName& aDocumentName, const TDesC8& /*aTail*/){aDocumentName.Zero();return EFalse;}
      • -
    -
    Drive scanning

    This -can be a cause of unnecessary file server use.

    To prevent excessive -drive access and scanning, always specify a drive letter in file paths, if -known. The omission of a drive letter will cause all available drives to be -searched in the standard Symbian platform order, in which Z: is always searched -last.

    -
    Only make server -requests if you need to

    Server requests involve context switching -and may cause the server to run instead of the application. In the worse case -if you make a request to a server that has not yet been started you may cause -the server to start. This will involve creating a new thread -(and possibly process) and running any server initialization code.

    -
    Use asynchronous -server requests instead of synchronous server requests

    Synchronous -operations or methods (particularly for server requests) can cause general -application slowness, and in particular, a significant reduction in responsiveness. -Synchronous requests to servers mean your thread is waiting, so that no start-up -progress is being made.

    No 'Golden Rule' exists about when to avoid -synchronous requests. However, if an asynchronous version of a method exists, -it is a good indication that the synchronous method could potentially take -some time. Whilst it may take a little extra effort to handle asynchronous -versions of method calls, you should consider very carefully any decision -to use the synchronous version. It’s often easier to change from using an -asynchronous version to synchronous than vice versa.

    Note that in -some situations, you might know that the server is implementing your asynchronous -request synchronously. If this is the case, and the server runs with a higher -priority than your application, then both versions of the API may have the -same performance. However, using the synchronous version in this case has -the drawback that it relies upon knowledge of the server's implementation, -which could potentially change.

    -
    Do not repeatedly -open and close connections to the same server

    Opening a connection -to a server is an expensive operation. If an application uses a server frequently -then it should create one connection and leave it open until the application -is destroyed. R classes declared as temporaries (on the stack, in other words) -within a method may be a sign of this behavior.

    + + + + + +Application Start-Up Time OptimizationIt is important that phone users do not have to wait long +for applications to start. This document summarizes the techniques +for optimizing application start-up time. +
    Introduction

    The techniques discussed in this document +are limited in scope to application programming. In other words, they +do not require modification of any core OS components or servers. +Some of the techniques are general good practice and are useful to +developers at all levels.

    The techniques can be summarized +as follows:

      +

    • Avoid causing unnecessary code to be executed as an effect +of your code.

      • +

    • Defer construction of objects, loading of dynamic libraries +(for example, the application model), and starting servers until you +need to use them.

      • +

    • Write efficient code!

      • +
    There is an inevitable trade-off between shortening the +start-up time and introducing latency elsewhere in the application. +For example, if you don’t connect to a server at start-up, you will +have to do it later on, when the application needs to use the server. +This may be overcome by a central component that coordinates background +connections, or construction, such as the view server.
    +
    Measure +start-up time before you start optimizing

    Do not assume +you know which methods take the most time. Pay close attention to +iterative and recursive operations. Many useful tools and techniques +are available to help identify poorly performing code:

      +

    • Software analysis tools, for instance GlowCode and +MetroWerks CodeTEST

      • +

    • The Symbian profiling tool, profiler.exe, which is supplied +on DevKits

      • +

    • The RDebug class provides some profiling functions

      • +

    • The TTime class can be used to time blocks of code, but beware +of context switches, otherwise you may end up timing other threads!

      • +

    • Deliberately slowing down suspect blocks of code can reveal +whether or not optimizing it would bring a significant performance +improvement.

      • +
    +
    Defer +construction of the application model and other data members

    Many applications instantiate their components, for instance error +handlers, dialogs and menus, during start-up. In turn, each of these +components may instantiate other components, for instance menu resources +and icons. This can bring some benefits, for instance reducing application +complexity, revealing memory allocation problems at start-up rather +than after the application has been running for some time and improving +the runtime performance of the application. However, to minimize application +start-up time, it is recommended to avoid this behavior. Your goal +should be to only do what is immediately necessary during start-up.

    +
    Draw +the application as quickly as possible

    During application +start-up, only construct UI components that appear in the application’s +initial view. This applies especially to the application's implementations +of CXxxApplication::CreateDocumentL(), CXxxDocument::ConstructL() and CXxxDocument::CreateAppUiL(), all of which +are called before CXxxAppUi::ConstructL(). Do not +read bitmaps, resources, or any other data associated with the UI +from files unless it is necessary.

    In CXxxAppUi::ConstructL(), make sure CCoeControl::ActivateL() and CCoeControl::DrawNow() are called on all controls that +must be drawn when the application is launched. Also ensure that the +client-side window server command buffer is flushed by calling Flush() on the application's window server session. This +ensures that there aren't any drawing commands left in the client-side +buffer, after CCoeControl::DrawNow() has completed.

    +
    Minimize +the number of bitmaps used by GUI components

    Often, when +a large number of small images are required by an application, the +overhead associated with loading each bitmap outweighs any benefit +associated with their size. Some possible ways to avoid this are:

      +

    • use text instead,

      • +

    • for very simple graphics, draw directly using drawing primitives +rather than loading a bitmap,

      • +

    • concatenate many small bitmaps into one large bitmap file to +reduce the need to search for and load multiple files.

      • +
    +
    Reduce +the number of redraws

    Some GUI components redraw themselves +every time their data changes. This may not always be necessary. Complicated +GUI components should implement theirDraw() method +to only update the area of the screen that has changed. For example, +there is no point in redrawing a whole list box every time a new item +is appended to it. In such cases, a GUI API should allow you to switch +off redrawing. Beware of GUI methods that cause the object they are +called upon to redraw itself.

    Use CCoeControl::DrawDeferred() in preference to CCoeControl::DrawNow() if possible, +because excessive use of CCoeControl::DrawNow() can cause GUI flicker. For an explanation, see the documentation +for CCoeControl::DrawDeferred().

    +
    Use +ROM-based bitmaps rather than filestore bitmaps

    Uncompressed +ROM-based bitmaps that can be used in place from ROM are approximately +three times faster to use than filestore bitmaps. Using them can bring +a significant reduction in application start-up time.

    Specifying +bitmap= instead of file= in the .OBY and .IBY files when building +the ROM causes bitmaps to be uncompressed before inclusion in the +ROM. Other bitmaps need to be uncompressed at runtime, which impacts +performance.

    The drawback of such bitmaps is that they are +large (up to 3 times larger than file based) and cannot be compressed, +although decompressing bitmaps should probably be avoided during start-up +anyway due to the extra processing required.

    If ROM space +is limited, consider using such ROM-based bitmaps only if they are +displayed during application start-up.

    +
    Color +depth matching

    When bitmaps are drawn to the screen, optimum +performance is achieved by ensuring that:

    Bitmap color +depth = Window color depth = Screen device color depth

    If this is the case, no palette mapping between the different color +depths is needed. On real hardware, this optimization has been found +to improve drawing speed by up to ten times. However, in order to +match the screen and window color depth, bitmaps may need to increase +in size and so this optimization is only possible if the increase +in ROM or RAM usage is acceptable.

    +
    Minimize +access to the file system

    The file server can be a major +bottleneck during start-up when virtually all threads are searching +for and loading data, libraries and plug-ins. Therefore reducing file +access is one of the most effective ways to improve performance.

    +
    Minimize +the use of resource files

    Resource files are used for localization +and allow modifications to be made to an application without the need +to rebuild it, but they are expensive to use because they require +access to the file system.

    +
    Do +not specify a default document filename for non document-based applications

    Many applications on a smartphone do not need to use documents, +for example Telephony, Contacts (this uses the contacts database), +Browser and Messaging.

    By not specifying a default document +filename, hundreds of milliseconds can potentially be saved from such +applications' start-up time.

    If an application uses a document +file, application start-up may involve the following steps:

      +

    • reading the name of the last used document file from the application’s +.ini file,

      • +

    • opening the document file, or if one doesn't exist, creating +a default document file, after reading its name from the application's +resource file,

      • +

    • writing the name of the last used file to the application’s +.ini file (which is created if it doesn’t exist),

      • +

    • writing an entry to the most recently used file list (mru.dat),

      • +

    • additional document-related processing within CEikonEnv::ConstructAppFromCommandLineL().

      • +

    The default document's name is read from the application's +resource file by CEikAppUi::ProcessCommandParametersL(). There are two ways of preventing the application from using a default +document file:

      +

    • Give the default document a NULL name in the resource file:

      RESOURCE TBUF { buf=""; }
      • +

    • Override CEikAppUi::ProcessCommandParametersL() to zero the document name and return EFalse. This method is slightly +more efficient because it avoids reading the default document name +from the resource file altogether:

      TBool CMyAppUi::ProcessCommandParametersL(TApaCommand /*aCommand*/, TFileName& aDocumentName, const TDesC8& /*aTail*/){aDocumentName.Zero();return EFalse;}
      • +
    +
    Drive +scanning

    This can be a cause of unnecessary file server +use.

    To prevent excessive drive access and scanning, always +specify a drive letter in file paths, if known. The omission of a +drive letter will cause all available drives to be searched in the +standard Symbian platform order, in which Z: is always searched last.

    +
    Only +make server requests if you need to

    Server requests involve +context switching and may cause the server to run instead of the application. +In the worse case if you make a request to a server that has not yet +been started you may cause the server to start. This will involve +creating a new thread (and possibly process) and running any server +initialization code.

    +
    Use +asynchronous server requests instead of synchronous server requests

    Synchronous operations or methods (particularly for server requests) +can cause general application slowness, and in particular, a significant +reduction in responsiveness. Synchronous requests to servers mean +your thread is waiting, so that no start-up progress is being made. +

    No 'Golden Rule' exists about when to avoid synchronous requests. +However, if an asynchronous version of a method exists, it is a good +indication that the synchronous method could potentially take some +time. Whilst it may take a little extra effort to handle asynchronous +versions of method calls, you should consider very carefully any decision +to use the synchronous version. It’s often easier to change from using +an asynchronous version to synchronous than vice versa.

    Note +that in some situations, you might know that the server is implementing +your asynchronous request synchronously. If this is the case, and +the server runs with a higher priority than your application, then +both versions of the API may have the same performance. However, using +the synchronous version in this case has the drawback that it relies +upon knowledge of the server's implementation, which could potentially +change.

    +
    Do +not repeatedly open and close connections to the same server

    Opening a connection to a server is an expensive operation. If +an application uses a server frequently then it should create one +connection and leave it open until the application is destroyed. R +classes declared as temporaries (on the stack, in other words) within +a method may be a sign of this behavior.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e355905_href.png Binary file Symbian3/SDK/Source/GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e355905_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e375093_href.png Binary file Symbian3/SDK/Source/GUID-16B42854-F27D-5CB3-BCFE-8F711793EE60_d0e375093_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16C323DC-B43F-5621-B617-C31FBB25379B_d0e123389_href.png Binary file Symbian3/SDK/Source/GUID-16C323DC-B43F-5621-B617-C31FBB25379B_d0e123389_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16C323DC-B43F-5621-B617-C31FBB25379B_d0e371844_href.png Binary file Symbian3/SDK/Source/GUID-16C323DC-B43F-5621-B617-C31FBB25379B_d0e371844_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-16D0854D-55EF-4E22-B7D2-72603699BC59.dita --- a/Symbian3/SDK/Source/GUID-16D0854D-55EF-4E22-B7D2-72603699BC59.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-16D0854D-55EF-4E22-B7D2-72603699BC59.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ Empty list: the primary font is used to inform about an empty list and provide the user with further information (used only in cases when genuinely useful additional information is available). - +

    Depending on the case, the text may be aligned to prompt the user to create the first item for an empty list.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1704898B-7836-53C2-8743-F733836EDE7B_d0e332834_href.png Binary file Symbian3/SDK/Source/GUID-1704898B-7836-53C2-8743-F733836EDE7B_d0e332834_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1704898B-7836-53C2-8743-F733836EDE7B_d0e339300_href.png Binary file Symbian3/SDK/Source/GUID-1704898B-7836-53C2-8743-F733836EDE7B_d0e339300_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-170EDC68-77C7-4FD9-A81E-C9F75698F7A3.dita --- a/Symbian3/SDK/Source/GUID-170EDC68-77C7-4FD9-A81E-C9F75698F7A3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-170EDC68-77C7-4FD9-A81E-C9F75698F7A3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,11 +24,11 @@ events.

    Scalable UI implementation in control - + Scalable UI implementation in UI controller - +

    For further implementation information, see Handling layout change events.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e62371_href.png Binary file Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e62371_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e62514_href.png Binary file Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e62514_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e63892_href.png Binary file Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e63892_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e64035_href.png Binary file Symbian3/SDK/Source/GUID-173D7E50-92FA-42D7-A01B-47A39216E98D_d0e64035_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1742B2A1-6EC1-5368-919B-362516A5D452_d0e352306_href.png Binary file Symbian3/SDK/Source/GUID-1742B2A1-6EC1-5368-919B-362516A5D452_d0e352306_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1742B2A1-6EC1-5368-919B-362516A5D452_d0e368182_href.png Binary file Symbian3/SDK/Source/GUID-1742B2A1-6EC1-5368-919B-362516A5D452_d0e368182_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1747534D-063A-45B0-8636-E7767F984BB0.dita --- a/Symbian3/SDK/Source/GUID-1747534D-063A-45B0-8636-E7767F984BB0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1747534D-063A-45B0-8636-E7767F984BB0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@

    Create a private key and a self signed certificate as explained in the Creating a Private Key and Self Signed Certificate.

    - + Run MakeKeys at the command prompt using the -req option.

    The following is the syntax:

    > makekeys -req [-v] [-password <password>] -dname <distinguished-name-string> <private-key-file> <public-key-cert><cert-request-file>The <cert-request-file> must specify diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-176FD8C9-B4A9-5B50-B683-AB5DA7D5D6F4.dita --- a/Symbian3/SDK/Source/GUID-176FD8C9-B4A9-5B50-B683-AB5DA7D5D6F4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-176FD8C9-B4A9-5B50-B683-AB5DA7D5D6F4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,39 +1,32 @@ - - - - - -CreateStaticDLL -and UseStaticDLL: using a statically linked DLL -
    Description

    The example shows how a class implemented -in a statically linked DLL is used. The DLL is built by CreateStaticDLL and -is used by UseStaticDLL.

    -
    Download

    Click on the following link -to download the example: StaticDLL.zip

    Click on the following link to -download additional files: CommonFramework.zip.

    Click browse StaticDLL to view the example code.

    Click browse CommonFramework to view additional files.

    -
    Build and Usage

    The example may be in the directory -in which you installed the Symbian platform, or it may be in src\common\developerlibrary\. -The example includes the project files needed for building: bld.inf and -two .mmp files.

    The -Symbian platform build process describes how to build Symbian programs. -To run this example:

      -

    1. Build CreateStaticDLL project, -which results in the following:

      \epoc32\release\<target>\<urel -or udeb>\CREATESTATICDLL.DLL.

      \epoc32\release\<target>\<urel -or udeb>\CREATESTATICDLL.lib.

      They are -needed by the UseStaticDLL project.

      2. -

    2. Build UseStaticDLL, -which results in:

      \epoc32\release\<target>\<urel -or udeb>\USESTATICDLL.EXE.

      This project -use the DLL created in the previous steps.

      3. -

    3. Run the executable USESTATICDLL.EXE.

      Executables -for the winscw target can be run on your PC. Executables -for ARM targets must be copied to a phone before being run.

      4. -
    + + + + + +CreateStaticDLL and UseStaticDLL: using a statically linked +DLL +
    Description

    The example shows how a class implemented in a statically linked +DLL is used. The DLL is built by CreateStaticDLL and is used by UseStaticDLL.

    +
    Download

    Click on the following link to download the example: StaticDLL.zip

    Click on the following +link to download additional files: CommonFramework.zip.

    Click browse StaticDLL to view the example code.

    Click browse CommonFramework to view additional files.

    +
    Build +and Usage

    The example may be in the directory in which +you installed the Symbian platform, or it may be in src\common\developerlibrary\. The example includes the project files needed for building: bld.inf and two .mmp files.

    The Symbian platform build process describes how to build Symbian +programs. To run this example:

      +

    1. Build CreateStaticDLL project, which results in the following:

      \epoc32\release\<target>\<urel or + udeb>\CREATESTATICDLL.DLL.

      \epoc32\release\<target>\<urel +or udeb>\CREATESTATICDLL.lib.

      They +are needed by the UseStaticDLL project.

      2. +

    2. Build UseStaticDLL, which results in:

      \epoc32\release\<target>\<urel +or udeb>\USESTATICDLL.EXE.

      This +project use the DLL created in the previous steps.

      3. +

    3. Run the executable USESTATICDLL.EXE.

      Executables for the winscw target can be run on your PC. Executables for ARM +targets must be copied to a phone before being run.

      4. +
     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-17C64C2F-9426-4B41-9F0A-23060289D644.dita --- a/Symbian3/SDK/Source/GUID-17C64C2F-9426-4B41-9F0A-23060289D644.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-17C64C2F-9426-4B41-9F0A-23060289D644.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,99 +1,88 @@ - - - - -Multiple touch - - - - -

    Multiple touch is an enhancement to the touch screen, which provides -the user with the ability to apply elaborate finger gestures onto -the display as commands to the device.

    -

    Multiple touch is implemented based on the size and type of interfaces. -When a finger or an object touches the display causing the light to -scatter, the reflection is caught by the sensors. The response for -the touch is sent back based on the type of reflection measured.

    -

    Only the devices with multiple touch support have 'Pinch Stroke' -as a touch stroke.

    -
    Pinch -StrokePinch stroke is invoked by two separate but simultaneously -active touch down events and dragging movements along the line that -goes through both touch down points. On release, the pinch in or pinch -out state is maintained. Pinch stroke can be utilized, for example, -in Photo viewer to zoom in and zoom out.

    The following table lists the -default touch-events for pinch-stroke:

    -Default touch events for pinch-stroke - - - -

    User action

     -

    State change

     -

    Feedback

     -     - - - -

    First touch down

     -

    No action.

     -

    Tactile:

      -

    • First touch down tactile feedback follows the context-based -feedback.

      • -

    • Audio feedback is provided with touch down.

      • -

     -     - -

    Second simultaneous touch down

     -

    Activates multiple touch mode for the content defined.

     -

    Tactile:

      -

    • When the second finger is touched down, two sensitive pulses -effect is provided.

      • -

    • Audio feedback is provided with touch down.

      • -

     -     - -

    Pinch in

     -

    Moving the touch points (directly) closer to each other -is recognized as pinch in. Application can use it, for example, for -zooming out a picture. The behavior should be in relation to the speed -and size of the stroke.

     -

    Tactile: Smooth pinch effect is provided while moving the -fingers.

    No audio feedback is provided.

     -     - -

    Pinch out

     -

    Moving the touch points (directly) away from each other -is recognized as pinch out. Application can use it, for example, for -zooming in a picture. The behavior should be in relation to the speed -and size of the stroke.

     -

    Tactile: Smooth pinch effect is provided while moving the -fingers.

    No audio feedback is provided.

     -     - -

    Touch release

     -

    Releasing one or both fingers stops the pinch.

     -

    No tactile or audio feedback given.

     -     - - -
    -
    Using -multiple touch in applicationsFor multiple touch, use classes TRawEvent and TAdvancedPointerEvent (which extends TPointerEvent). For more information, see Advanced pointers section.
    -     -     - + + + + + +Multiple touch +

    Multiple touch is an enhancement to the touch screen, which provides +the user with the ability to apply elaborate finger gestures onto +the display as commands to the device.

    +

    Multiple touch is implemented based on the size and type of interfaces. +When a finger or an object touches the display causing the light to +scatter, the reflection is caught by the sensors. The response for +the touch is sent back based on the type of reflection measured.

    +

    Only the devices with multiple touch support have 'Pinch Stroke' +as a touch stroke.

    +
    Pinch +StrokePinch stroke is invoked by two separate but simultaneously +active touch down events and dragging movements along the line that +goes through both touch down points. On release, the pinch in or pinch +out state is maintained. Pinch stroke can be utilized, for example, +in Photo viewer to zoom in and zoom out. + +

    The following table lists the default touch-events for pinch-stroke:

    Default +touch events for pinch-stroke + + + +

    User action

     +

    State change

     +

    Feedback

     +     + + + +

    First touch down

     +

    No action.

     +

    Tactile:

      +

    • First touch down tactile feedback follows the context-based +feedback.

      • +

    • Audio feedback is provided with touch down.

      • +

     +     + +

    Second simultaneous touch down

     +

    Activates multiple touch mode for the content +defined.

     +

    Tactile:

      +

    • When second finger is touched down multiple touch recognition, +two sensitive pulses effect is provided.

      • +

    • Audio feedback is provided with touch down.

      • +

     +     + +

    Pinch in

     +

    Moving the touch points (directly) closer to each other +is recognized as pinch in. Application can use it, for example, for +zooming out a picture. The behavior should be in relation to the speed +and size of the stroke.

     +

    Tactile: Smooth pinch effect is provided while moving the +fingers.

    No audio feedback is provided.

     +     + +

    Pinch out

     +

    Moving the touch points (directly) away from each other +is recognized as pinch out. Application can use it, for example, for +zooming in a picture. The behavior should be in relation to the speed +and size of the stroke.

     +

    Tactile: Smooth pinch effect is provided while moving the +fingers.

    No audio feedback is provided.

     +     + +

    Touch release

     +

    Releasing one or both fingers stops the pinch.

     +

    No tactile or audio feedback given.

     +     + + +
    +
    Using +multiple touch in applicationsFor multiple touch, use classes TRawEvent and TAdvancedPointerEvent (which +extends TPointerEvent). For more information, see Advanced pointers section.
    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-17D1489B-F7F7-5CA7-9F81-850AA9ACEFEB_d0e332498_href.png Binary file Symbian3/SDK/Source/GUID-17D1489B-F7F7-5CA7-9F81-850AA9ACEFEB_d0e332498_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-17D1489B-F7F7-5CA7-9F81-850AA9ACEFEB_d0e338964_href.png Binary file Symbian3/SDK/Source/GUID-17D1489B-F7F7-5CA7-9F81-850AA9ACEFEB_d0e338964_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-17DE7D55-00C9-5D40-8AE4-39BDB20FCC5B.dita --- a/Symbian3/SDK/Source/GUID-17DE7D55-00C9-5D40-8AE4-39BDB20FCC5B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-17DE7D55-00C9-5D40-8AE4-39BDB20FCC5B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -48,7 +48,7 @@ Framework to tag the messages with the correct BIO ID.

    The following figure illustrates the BIO Messaging Framework architecture:

    BIO Messaging Framework architecture - +

    BIO database

    The BIO database is used to identify the type of BIO messages. It maps message attributes, such as port number, MIME type, or leading string to a BIO type. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-184E301D-78BF-5324-98F6-AD583A875D6E_d0e403005_href.png Binary file Symbian3/SDK/Source/GUID-184E301D-78BF-5324-98F6-AD583A875D6E_d0e403005_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-184E301D-78BF-5324-98F6-AD583A875D6E_d0e406805_href.png Binary file Symbian3/SDK/Source/GUID-184E301D-78BF-5324-98F6-AD583A875D6E_d0e406805_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e207449_href.png Binary file Symbian3/SDK/Source/GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e207449_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e212456_href.png Binary file Symbian3/SDK/Source/GUID-18547A2C-7425-5478-8235-EC6D3848B404_d0e212456_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1879BEEB-9945-55F4-817E-8D6117055B1D.dita --- a/Symbian3/SDK/Source/GUID-1879BEEB-9945-55F4-817E-8D6117055B1D.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -nocompresstarget

    nocompresstarget

    Use the nocompresstarget statement to specify that the target executable should not be compressed (see compresstarget for details of the compression option).

    If neither nocompresstarget nor compresstarget is specified, then the default for the platform is selected.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-188F9462-F805-522A-84FF-770EAB045504.dita --- a/Symbian3/SDK/Source/GUID-188F9462-F805-522A-84FF-770EAB045504.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,111 +0,0 @@ - - - - - -An -example registration file and icon/caption file -
    Introduction

    This document describes two methods -of defining application registration information. In both cases, a minimal -example registration file called HelloWorld_reg.rss is -used. In the first method, the icon/caption information is defined in its -own file. In the second, it is defined in the application's UI resource file. -The registration file is largely the same in both cases.

    -
    Registration file with an icon/caption definition file

    The -registration file

    A registration file is a resource file that -is compiled by the resource compiler in the standard way, by including lines -like the following in the application's mmp file:

    START RESOURCE HelloWorld_reg.rss -TARGETPATH \private\10003a3f\apps -END

    This will cause HelloWorld_reg.rss to -be compiled, creating HelloWorld_reg.rsc. On the Symbian -emulator, all registration files should be located in \private\10003a3f\apps. -This is also true on real hardware for registration files built into the ROM. -For applications installed onto a phone using the standard software installation -method, their registration files should be installed into \private\10003a3f\import\apps. -In all cases, the registration file must be located on the same drive as the -application.

    A minimal registration file looks like this:

    #include <appinfo.rh> - -UID2 KUidAppRegistrationResourceFile -UID3 0x10004299 // application UID -RESOURCE APP_REGISTRATION_INFO - { - app_file = "HelloWorld"; - localisable_resource_file = "\\resource\\apps\\HelloWorld_loc"; - }

    All registration files must define UID2, -which is always KUidAppRegistrationResourceFile, and UID3, -which is the application's UID, and an APP_REGISTRATION_INFO resource -that minimally needs to provide the name of the application binary (using -the app_file statement). All registration files need to #include appinfo.rh.

    If -a localisable icon/caption definition file is provided, as in this example, -its full path and filename must be specified, excluding the drive letter and -file extension.

    The localisable icon/caption definition -file

    This file defines the application's captions and the name -of the icon file. It is built to the \resource\apps\ directory -on the same drive as the registration file; this applies both on the Symbian -emulator and target phone. By convention it has the same filename as the application, -but with a _loc suffix.

    It is a standard localisable -Symbian resource file, so it is compiled by the resource compiler by including -lines like the following in the application's mmp file:

    start resource HelloWorld_loc.rss -targetpath \resource\apps -lang 01 02 -end

    These lines cause two versions of the file to be compiled, -called HelloWorld_loc.r01 and HelloWorld_loc.r02. HelloWorld_loc.rss looks -like this:

    #include <appinfo.rh> -#ifdef LANGUAGE_01 -#include "HelloWorld01.rls" -#elif defined LANGUAGE_02 -#include "HelloWorld02.rls" -#endif -RESOURCE LOCALISABLE_APP_INFO - { - short_caption = STRING_r_short_caption; - caption_and_icon = - { - CAPTION_AND_ICON_INFO - { - caption = STRING_r_caption; - number_of_icons = 3; // each icon must be a bitmap/mask pair - icon_file = STRING_r_icon_file; - } - }; - }

    Unlike most resource files, because there is only one -resource defined in the file, it does not need to include a four character NAME or -an RSS_SIGNATURE resource, and the LOCALISABLE_APP_INFO resource -does not need an ID.

    The captions and the icon filename are referred -to by symbolic identifiers rather than by the strings themselves. The strings -are defined in .rls files (resource localisable string -files), as shown below and conditional compilation statements are used to -include the appropriate .rls file. For more information, -on localising strings in resource files, see How -to localise resources.

    HelloWorld01.rls contains:

    rls_string STRING_r_short_caption "Hello" -rls_string STRING_r_caption "Hello World" -rls_string STRING_r_icon_file "z:\\resource\\apps\\Hello.mbm"

    HelloWorld02.rls contains:

    rls_string STRING_r_short_caption "Bonjour" -rls_string STRING_r_caption "Bonjour tout le monde" -rls_string STRING_r_icon_file "z:\\resource\\apps\\Bonjour.mbm"

    The -mbm icon files are built by adding start -bitmap statements to the mmp file, for instance:

    START BITMAP Hello.mbm -TARGETPATH \Resource\Apps -SOURCE c8,1 icon24.bmp icon24m.bmp icon32.bmp icon32m.bmp icon48.bmp icon48m.bmp -END
    -
    Registration file without an icon/caption definition file

    As -an alternative to defining the icon/caption information in an icon/caption -definition file, it can be defined in the application's existing UI resource -definition file. In this case, the LOCALISABLE_APP_INFO resource -must be given an ID, because it is no longer the only resource defined in -the file. The registration file is as before, except that it must now specify -the ID of the LOCALISABLE_APP_INFO resource as well as the -name and location of the UI resource file. In other words, the line:

    localisable_resource_file = "\\resource\\apps\\HelloWorld_loc";

    needs -to be changed to:

    localisable_resource_file = "\\resource\\apps\\HelloWorld"; -localisable_resource_id = R_LAI;

    where R_LAI is -the ID of the LOCALISABLE_APP_INFO resource. Because the -registration file needs to give the resource ID, it must #include the -application's generated resource header file, HelloWorld.rsg. -Also, the UI resource file needs to #include AppInfo.rh for -the LOCALISABLE_APP_INFO definition.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-18D7228F-A1E5-594A-B654-EF5D74CE17D2.dita --- a/Symbian3/SDK/Source/GUID-18D7228F-A1E5-594A-B654-EF5D74CE17D2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-18D7228F-A1E5-594A-B654-EF5D74CE17D2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Recording Video Data

    This tutorial describes how to record video data.

    Purpose

    The purpose of this tutorial is to show you how to use the video recorder to control video recording.

    Required Background

    The Video Client Overview introduces the video client utilities.

    Introduction

    The video recorder utility is used to record video clips to files, descriptors or URLs and manipulate embedded meta data. This functionality is implemented by the CVideoRecorderUtility class.

    The sequence diagram below explains the different functionalities of the video recorder utility:

    Video recorder sequence diagram -
    Using Video Recording

    The following tasks will be covered in this tutorial:

    • Record Video Data

    Basic Procedure

    The high level steps to record video data are shown here:

    1. If you are using an audio clip, the recording gain must be set using the CVideoRecorderUtility::SetGainL() function before recording because the initial gain is undefined or may also have been modified by another client application.

    2. The specific functions to record and perform related tasks are as follows:

      • To start recording video data to the specified file, descriptor or URL, use the CVideoRecorderUtility::Record() function.

        void CRecordVideo::Record() +
    Using Video Recording

    The following tasks will be covered in this tutorial:

    • Record Video Data

    Basic Procedure

    The high level steps to record video data are shown here:

    1. If you are using an audio clip, the recording gain must be set using the CVideoRecorderUtility::SetGainL() function before recording because the initial gain is undefined or may also have been modified by another client application.

    2. The specific functions to record and perform related tasks are as follows:

      • To start recording video data to the specified file, descriptor or URL, use the CVideoRecorderUtility::Record() function.

        void CRecordVideo::Record() { iVideoRecordUtility->Record(); }

      • To pause recording, use the CVideoRecorderUtility::PauseL() function. The position within the video clip is maintained in case a subsequent CVideoRecorderUtility::Record() is called.

        void CRecordVideo::PauseL() diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-18D92465-3F62-55CF-8229-EE811FD5F568.dita --- a/Symbian3/SDK/Source/GUID-18D92465-3F62-55CF-8229-EE811FD5F568.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-18D92465-3F62-55CF-8229-EE811FD5F568.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Stream networks

        When a store stream is created, a stream ID is generated. This ID can be used to open the stream later. Stream IDs can be externalised into another stream, and this allows streams in a store to be built into a network.

        An object that is saved to a store may use a network of streams, typically starting with a single head stream.

        An object stores itself using a function of the form:

        streamId=object.StoreL(store);

        Given the correct stream ID, the object may be restored using a function of the form:

        object.RestoreL(store,streamId)

        where store is a reference or pointer to a store.

        The function names StoreL() and RestoreL() are conventional for this purpose.

        The following diagram shows the idea of stream networks:

         \ No newline at end of file +Stream networks

        When a store stream is created, a stream ID is generated. This ID can be used to open the stream later. Stream IDs can be externalised into another stream, and this allows streams in a store to be built into a network.

        An object that is saved to a store may use a network of streams, typically starting with a single head stream.

        An object stores itself using a function of the form:

        streamId=object.StoreL(store);

        Given the correct stream ID, the object may be restored using a function of the form:

        object.RestoreL(store,streamId)

        where store is a reference or pointer to a store.

        The function names StoreL() and RestoreL() are conventional for this purpose.

        The following diagram shows the idea of stream networks:

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1910C54E-44E0-4D36-820A-BCD5FFCDA719.dita --- a/Symbian3/SDK/Source/GUID-1910C54E-44E0-4D36-820A-BCD5FFCDA719.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1910C54E-44E0-4D36-820A-BCD5FFCDA719.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,12 +21,12 @@

        To migrate from STLport v4 to v5, perform the following steps:

         - - + +

        Replace the LIBRARY entry in the .MMP file from libstdcpp.lib to libstdcppv5.lib.

                 - +

        Replace the SYSTEMINCLUDE path in the .MMP file from \epoc32\include\stdapis\stlport to \epoc32\include\stdapis\stlportv5.

                 diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-192C7AC8-DCBD-5AA8-984A-35D9602C0ADB_d0e272145_href.jpg Binary file Symbian3/SDK/Source/GUID-192C7AC8-DCBD-5AA8-984A-35D9602C0ADB_d0e272145_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-192C7AC8-DCBD-5AA8-984A-35D9602C0ADB_d0e276991_href.jpg Binary file Symbian3/SDK/Source/GUID-192C7AC8-DCBD-5AA8-984A-35D9602C0ADB_d0e276991_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1969956D-CDA0-5DA0-ACF8-69AFBBEC1408.dita --- a/Symbian3/SDK/Source/GUID-1969956D-CDA0-5DA0-ACF8-69AFBBEC1408.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1969956D-CDA0-5DA0-ACF8-69AFBBEC1408.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Light APILight API is a library API that provides the ability to control various light targets of the device. It also provides methods to retrieve the current light status and the supported light targets of the device.

        It uses synchronous method calls which block the client application until a response is received from the plug-in. The API consists of CHWRMLight and MHWRMLightObserver classes.

        Light API Interfaces -

        The client creates an instance of CHWRMLight using NewL(). If the client requires status information, it must also provide a callback pointer of the MHWRMLightObserver implementing class for the NewL() method.

        Usually HWRM Light interface supports restoring the previous or default light state (ON/OFF/BLINK). The already supported (reservation controller) functionality in existing HWRM light APIs is extended to restore the previous or default color of the LED as well.

        HWRM also supports automatic reserve and release the targets depends on the client application foreground observer notification through an UI plugin. During these states the light state with color value would be stored and restored automatically. This means if the client application window comes on the foreground then the reserved target’s state will be restored.

        Definitions

        Term

        Description

        Light target

        A separate entity that can be lighted in the device. For example, the primary display of the device is a light target.

        Lights frozen state

        Whenever lights are released, their current state is stored as frozen state. On next reserve, the user can specify that frozen state be restored.

        Lights default state

        Lights default state is determined by device inactivity time and relevant general settings.

        Lights base state

        It is the state of the light target set for infinite duration (after all the time-based operation is completed).

        Light API Tutorial         \ No newline at end of file +

        The client creates an instance of CHWRMLight using NewL(). If the client requires status information, it must also provide a callback pointer of the MHWRMLightObserver implementing class for the NewL() method.

        Usually HWRM Light interface supports restoring the previous or default light state (ON/OFF/BLINK). The already supported (reservation controller) functionality in existing HWRM light APIs is extended to restore the previous or default color of the LED as well.

        HWRM also supports automatic reserve and release the targets depends on the client application foreground observer notification through an UI plugin. During these states the light state with color value would be stored and restored automatically. This means if the client application window comes on the foreground then the reserved target’s state will be restored.

        Definitions

        Term

        Description

        Light target

        A separate entity that can be lighted in the device. For example, the primary display of the device is a light target.

        Lights frozen state

        Whenever lights are released, their current state is stored as frozen state. On next reserve, the user can specify that frozen state be restored.

        Lights default state

        Lights default state is determined by device inactivity time and relevant general settings.

        Lights base state

        It is the state of the light target set for infinite duration (after all the time-based operation is completed).

        Light API Tutorial \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-198A417F-EA4D-58A0-A928-A78FCE1BB772.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-198A417F-EA4D-58A0-A928-A78FCE1BB772.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,15 @@ + + + + + +Network SecurityNetwork Security is the set of components that provide security +protocols for an IP connection. +

        The set of components includes IPSec, SSL, and TLS.

        +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-19B2E0BF-9766-55C6-A37F-188A9EDAFF39_d0e277923_href.png Binary file Symbian3/SDK/Source/GUID-19B2E0BF-9766-55C6-A37F-188A9EDAFF39_d0e277923_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-19B2E0BF-9766-55C6-A37F-188A9EDAFF39_d0e282762_href.png Binary file Symbian3/SDK/Source/GUID-19B2E0BF-9766-55C6-A37F-188A9EDAFF39_d0e282762_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-19E5720A-2B50-4515-AE90-A40C1BEDF4BA_d0e60568_href.png Binary file Symbian3/SDK/Source/GUID-19E5720A-2B50-4515-AE90-A40C1BEDF4BA_d0e60568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-19E5720A-2B50-4515-AE90-A40C1BEDF4BA_d0e60711_href.png Binary file Symbian3/SDK/Source/GUID-19E5720A-2B50-4515-AE90-A40C1BEDF4BA_d0e60711_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e192246_href.png Binary file Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e192246_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e193926_href.png Binary file Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e193926_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e197239_href.png Binary file Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e197239_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e198935_href.png Binary file Symbian3/SDK/Source/GUID-1A0FB98B-8DB3-5067-9B71-FF838F6AE402_d0e198935_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A3E282E-ACC0-5F88-A759-3ED6106B02B4.dita --- a/Symbian3/SDK/Source/GUID-1A3E282E-ACC0-5F88-A759-3ED6106B02B4.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -win32_library

        win32_library filename-list

        Use win32_library to specify Win32 libraries in the same way that other libraries are specified with the library statement.

        If any Win32 system libraries are specified, directories specified by the INCLUDE environmental variable will be searched for system-included header files that are not found in the system include paths specified for the project.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A488C86-C0D7-49DE-A32B-6AFEDDC9E89F_d0e70772_href.png Binary file Symbian3/SDK/Source/GUID-1A488C86-C0D7-49DE-A32B-6AFEDDC9E89F_d0e70772_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A488C86-C0D7-49DE-A32B-6AFEDDC9E89F_d0e70797_href.png Binary file Symbian3/SDK/Source/GUID-1A488C86-C0D7-49DE-A32B-6AFEDDC9E89F_d0e70797_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A5C7320-B017-5CD9-B3EA-1301CC08A762.dita --- a/Symbian3/SDK/Source/GUID-1A5C7320-B017-5CD9-B3EA-1301CC08A762.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1A5C7320-B017-5CD9-B3EA-1301CC08A762.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,8 +11,8 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> User Prompt Service Overview

        User Prompt Service (UPS) allows device creators to specify whether requests made by applications to access services, such as a request to make a telephone call, are processed silently or whether they require the user to be prompted.

        Purpose

        An application requests a service. The service provider (a system server) requests a decision from the UPS. The UPS searches for a matching policy file and policy. Based on the policy for the service, the service request may be immediately accepted or denied or it may need to receive a decision from the user, in which case it is accepted or denied after several further steps are carried out.

        Device creators can customize the circumstances under which prompts are generated by configuring policies. Policies are made up of details about the service being requested as well as information about whether to accept or deny silently or to ask the user. They are defined in policy lists. Each service has one policy list defining any number of policies. In cases where the policy specifies that a user prompt is required, ECom plug-ins called Policy Evaluators and Dialog Creators, written by device creators.

        Key concepts

        The component has the following key concepts:

        Policy

        Policies specify whether application requests to access services should be processed silently or whether the user should be prompted for a decision. Policies may be general or specific – for example a policy may be specific to a single application, a group of applications or a class of applications (For example, those with unprotected secure ids). Policies are defined in policy lists. Device creators define policies.

        UPS policy file

        A UPS policy file is a compiled resource file containing all of the policies for a given service. The policies are ordered from most specific to least specific.

        Because policies are matched in order, each service may have only one policy file. To define a policy safely, you need to know which other policies have been defined. If you place a general policy near the beginning of the list of policies, you prevent other policies from being evaluated.

        Policy evaluator

        Policy evaluators are Ecom plug-ins, which are responsible for generating fingerprints (see below) used to locate previous decision records related to the request. Device creators define policy evaluators.

        Dialog creator

        Dialog creators are Ecom plug-ins, which display and generate dialog prompts. Device creators define dialog creators.

        Fingerprint

        A fingerprint is a collection of data to do with the service being requested. The fingerprint usually includes the destination string supplied by the service that is matched to the destination string of a policy in the policy file. It might be a phone number, domain name, access point etc. A fingerprint is used to search the decision database for a match and to add a record to the decision database if a match was not found in the initial search. Device creators define the GenerateFingerprints() function in the Policy Evaluator plug-in.

        A fingerprint serves two purposes:

        • The UPS uses it to search the decision database for a match.

        • If the UPS finds no record of a previous user decision and the user selects "always" or "never" in response to the UPS prompt, it uses the fingerprint to create a new record in the decision database.

        It is possible to specify one or many policy evaluators. It is also possible not to specify a policy evaluator and to depend on the default policy evaluator.

        Decision database

        A decision database stores the phone user's choice of whether a request is always granted or never granted. Decisions stored in the decision database persist across reboots of the device. The decision database is provided by Symbian.

        The decision database may not be accessed directly. However, records may be retrieved and deleted via the management APIs. This might be used by a control-panel application.

        Architectural relationships

        The UPS provides CDialogCreator and CPolicyEvaluator interfaces for device creators to implement.

        UPS components -
        API summary

        The following diagram shows the relationships between some of the key classes in the UPS.

        +
        API summary

        The following diagram shows the relationships between some of the key classes in the UPS.

        Class diagram of key classes in UPS - Class Name Description

        UserPromptService::CClientEntity

        Class representing an entity executing within a client process. For example, a script.

        UserPromptService::CDialogCreator

        Abstract base class for dialog creator Ecom plug-ins. Dialog creators are responsible for generating and displaying prompt dialogs.

        UserPromptService::CFingerprint

        Class that represents the fingerprint data for a stored decision.

        UserPromptService::CPolicy

        Class for a single policy record.

        UserPromptService::CPolicyEvaluator

        Abstract base class for a policy evaluator Ecom plug-in. Policy evaluators are primarily responsible for generating the fingerprints used to locate previous decision records related to the current request.

        Typical uses

        The following diagram shows the sequence of activities performed by the UPS after it receives a request from a server:

        + Class Name Description

        UserPromptService::CClientEntity

        Class representing an entity executing within a client process. For example, a script.

        UserPromptService::CDialogCreator

        Abstract base class for dialog creator Ecom plug-ins. Dialog creators are responsible for generating and displaying prompt dialogs.

        UserPromptService::CFingerprint

        Class that represents the fingerprint data for a stored decision.

        UserPromptService::CPolicy

        Class for a single policy record.

        UserPromptService::CPolicyEvaluator

        Abstract base class for a policy evaluator Ecom plug-in. Policy evaluators are primarily responsible for generating the fingerprints used to locate previous decision records related to the current request.

        Typical uses

        The following diagram shows the sequence of activities performed by the UPS after it receives a request from a server:

        Diagram showing activities for a single request -

        As is shown in the above diagram, the UPS returns a decision to the system server as in the following use cases:

        • processing silently

        • finding a stored decision in the decision database

        • prompting the user in a dialog and resulting in a "one-shot" or "session" (non-persistent) decision by the user

        • prompting the user in a dialog and resulting in an "always" or "never" (persistent) decision by the user

        The Policy Evaluator allows device creators to customize the behaviour of the UPS at run-time. Policy Evaluators may:

        • Allow security decisions to be specific to the data on which the service acts instead of simply granting full access to the service, for example "Allow application X to send SMS messages to 01234567". This is supported via the fingerprint functionality.

        • Allow a security decision to be specific to an individual script executing within a scripting host. This is supported via the client entity field.

        • Allow a prompt to be displayed even if the user selected "Always" or "Never". This could be based on a usage threshold or simply as additional confirmation if the user selected "Never". This is supported via the force prompt functionality.

        Typical uses

        The UPS component provides interfaces to perform the following tasks:

        • Integrating a System Server with UPS

        • Writing a UPS Policy File

        • Writing a UPS Policy Evaluator

        • Writing a UPS Dialog Creator

        • Using UPS management APIs

        • Example code at \sf\os\security\authorisation\userpromptservice\examples\ location.

        See also

        For related information, see UPS Configuration.

        \ No newline at end of file +

        As is shown in the above diagram, the UPS returns a decision to the system server as in the following use cases:

        • processing silently

        • finding a stored decision in the decision database

        • prompting the user in a dialog and resulting in a "one-shot" or "session" (non-persistent) decision by the user

        • prompting the user in a dialog and resulting in an "always" or "never" (persistent) decision by the user

        The Policy Evaluator allows device creators to customize the behaviour of the UPS at run-time. Policy Evaluators may:

        • Allow security decisions to be specific to the data on which the service acts instead of simply granting full access to the service, for example "Allow application X to send SMS messages to 01234567". This is supported via the fingerprint functionality.

        • Allow a security decision to be specific to an individual script executing within a scripting host. This is supported via the client entity field.

        • Allow a prompt to be displayed even if the user selected "Always" or "Never". This could be based on a usage threshold or simply as additional confirmation if the user selected "Never". This is supported via the force prompt functionality.

    Typical uses

    The UPS component provides interfaces to perform the following tasks:

    • Integrating a System Server with UPS

    • Writing a UPS Policy File

    • Writing a UPS Policy Evaluator

    • Writing a UPS Dialog Creator

    • Using UPS management APIs

    • Example code at \sf\os\security\authorisation\userpromptservice\examples\ location.

    See also

    For related information, see UPS Configuration.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A7183EC-B55E-5B61-8965-89C939ECB395_d0e240382_href.png Binary file Symbian3/SDK/Source/GUID-1A7183EC-B55E-5B61-8965-89C939ECB395_d0e240382_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A7183EC-B55E-5B61-8965-89C939ECB395_d0e245341_href.png Binary file Symbian3/SDK/Source/GUID-1A7183EC-B55E-5B61-8965-89C939ECB395_d0e245341_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A8ED0EB-B3B7-553F-95E3-2120D877966B.dita --- a/Symbian3/SDK/Source/GUID-1A8ED0EB-B3B7-553F-95E3-2120D877966B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1A8ED0EB-B3B7-553F-95E3-2120D877966B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,5 +11,5 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> OpenVG Collection OverviewOpenVG is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG. OpenVG is targeted primarily at handheld devices that require portable acceleration of high-quality vector graphics for user interfaces and text on small screen devices—while enabling hardware acceleration to provide fluidly interactive performance at very low power levels.

    Variant: ScreenPlay and non-ScreenPlay.

    OpenVG is an open standard developed by the Khronos Group (www.khronos.org). OpenVG features include:

    • Coordinate systems and transformations (image drawing uses a 3x3 perspective transformation matrix)

    • Viewport clipping, scissoring and alpha masking

    • Paths

    • Images and image filters

    • Paint (gradient and pattern)

    • Blending.

    In addition, the associated VGU utility library provides features such as higher-level geometric primitives and image warping.

    Architecture

    OpenVG only defines rendering functionality and therefore cannot be used in isolation. It requires EGL to establish an environment in which OpenVG can be used. For example, EGL tells OpenVG where its rendered output should go. OpenVG depends on a standalone implementation of EGL.

    The following diagram shows the direct use of OpenVG by an application through the public OpenVG interface together with EGL. On the Symbian platform, both OpenVG and EGL have a component (shown in blue) that declares the interface, and both require an implementation that implements that interface (shown in green).

    OpenVG external relationships -

    It is possible for the OpenVG and EGL implementations to communicate through a private interface that is not standardized by Symbian.

    The OpenVG Interface provides a consistent interface to OpenVG on the Symbian platform, enabling cross-device compatibility. The component includes the Khronos-released header files (which incorporate some minor changes, such as to the comments). It also provides some Symbian-specific header files and some other files (such as LIB, DEF and MMP files) and UIDs. It does not provide any implementations of the APIs.

    Description

    OpenVG is designed to be the primary 2D and vector graphics API for use by mobile devices. By providing a consistent interface to OpenVG, the Symbian platform allows OpenVG applications and middleware (such as an SVG engine) to automatically benefit from hardware acceleration when it is present without losing compatibility when it is not available. In addition device and hardware manufacturers benefit from a standard Hardware Adaptation Interface (HAI) to plug into. This means that OpenVG has the potential to provide end users with improved quality and responsiveness of graphics features.

    OpenVG Collection EGL +

    It is possible for the OpenVG and EGL implementations to communicate through a private interface that is not standardized by Symbian.

    The OpenVG Interface provides a consistent interface to OpenVG on the Symbian platform, enabling cross-device compatibility. The component includes the Khronos-released header files (which incorporate some minor changes, such as to the comments). It also provides some Symbian-specific header files and some other files (such as LIB, DEF and MMP files) and UIDs. It does not provide any implementations of the APIs.

Description

OpenVG is designed to be the primary 2D and vector graphics API for use by mobile devices. By providing a consistent interface to OpenVG, the Symbian platform allows OpenVG applications and middleware (such as an SVG engine) to automatically benefit from hardware acceleration when it is present without losing compatibility when it is not available. In addition device and hardware manufacturers benefit from a standard Hardware Adaptation Interface (HAI) to plug into. This means that OpenVG has the potential to provide end users with improved quality and responsiveness of graphics features.

OpenVG Collection EGL Collection \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A905563-EF60-4A01-BC55-5B35904F96AB_d0e63486_href.png Binary file Symbian3/SDK/Source/GUID-1A905563-EF60-4A01-BC55-5B35904F96AB_d0e63486_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1A905563-EF60-4A01-BC55-5B35904F96AB_d0e63629_href.png Binary file Symbian3/SDK/Source/GUID-1A905563-EF60-4A01-BC55-5B35904F96AB_d0e63629_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1AA32C40-CDE0-4627-A634-7C07BB1ED67B.dita --- a/Symbian3/SDK/Source/GUID-1AA32C40-CDE0-4627-A634-7C07BB1ED67B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1AA32C40-CDE0-4627-A634-7C07BB1ED67B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ The form then returns to the View state.

An example form - +

The following table lists the default touch events for forms:

Default diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1AAA88BB-19AD-5B8E-993C-11F4B7CD90EB.dita --- a/Symbian3/SDK/Source/GUID-1AAA88BB-19AD-5B8E-993C-11F4B7CD90EB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1AAA88BB-19AD-5B8E-993C-11F4B7CD90EB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ to the <xref href="GUID-1578590A-FC00-5C3B-8BF9-F6E43CA9D9A0.dita">Application Architecture </xref> (AppArc). AppArc launches the application that best handles the identified data type. </p></abstract><prolog><metadata><keywords/></metadata></prolog><taskbody> -<context id="GUID-6799E3F3-353E-5C00-A38C-D32F888392AA-GENID-1-10-1-11-1-1-6-1-6-1-4-1-3-1-3-1"><p>Symbian OS v9.1 +<context id="GUID-6799E3F3-353E-5C00-A38C-D32F888392AA-GENID-1-10-1-13-1-1-6-1-6-1-4-1-3-1-3-1"><p>Symbian OS v9.1 and onwards, MIME recognizers are <xref href="GUID-9E92EE30-F2E2-5F28-BB2A-391C09EC69D2.dita">ECOM</xref> plug-ins. They are located in <b>\sys\bin\</b>. </p> <p>Each MIME recognizer is loaded by the <xref href="GUID-1578590A-FC00-5C3B-8BF9-F6E43CA9D9A0.dita">Application diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1AF99DF6-C5BE-5713-940D-5E9FBD43F123.dita --- a/Symbian3/SDK/Source/GUID-1AF99DF6-C5BE-5713-940D-5E9FBD43F123.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1AF99DF6-C5BE-5713-940D-5E9FBD43F123.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,33 +9,31 @@ --> <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept id="GUID-1AF99DF6-C5BE-5713-940D-5E9FBD43F123" xml:lang="en"><title>Animation -example -
Description

This example is a UI application, which -demonstrates how to create and play basic and sprite animations. It implements -all the standard classes required by any application using UI controls such -as an application, a document, an application UI and a view.

The application +Animation example +

Description

This example is a UI application, which demonstrates how to create +and play basic and sprite animations. It implements all the standard +classes required by any application using UI controls such as an application, +a document, an application UI and a view.

The application provides UI controls to create a sprite animation and a basic client-side -animation. It also provides UI controls to control the behavior -of an animation such as, start, stop, pause, resume and move.

The -application plays an animated .gif file both as a basic -client-side animation and a server-side sprite animation. It performs the -following tasks in the order they are listed to create the basic and sprite -animations:

    -

  1. Creates an object of -the CICLAnimationDataProvider class.

    2. -

  2. Loads the animated .gif file -into the object.

    3. -

  3. Configures the animation -to play in an infinite loop using TAnimationConfig.

    4. -

  4. Creates objects of CBasicAnimation and CSpriteAnimation classes by passing the data provider object as an argument.

    5. -

  5. Starts animations with -the TAnimationConfig object as an argument.

    6. -

Once both the animations are started, the window server will automatically -draw the animations onto the window by calling the Draw() method.

-
Download

Click on the following link to download -the example: AnimExample.zip

Click: browse to view the example code.

-
Class summary
    +animation. It also provides UI controls to control the behavior of +an animation such as, start, stop, pause, resume and move.

    The application plays an animated .gif file +both as a basic client-side animation and a server-side sprite animation. +It performs the following tasks in the order they are listed to create +the basic and sprite animations:

      +

    1. Creates an object +of the CICLAnimationDataProvider class.

      2. +

    2. Loads the animated .gif file into the object.

      3. +

    3. Configures the +animation to play in an infinite loop using TAnimationConfig.

      4. +

    4. Creates objects +of CBasicAnimation and CSpriteAnimation classes by passing the data provider object as an argument.

      5. +

    5. Starts animations +with the TAnimationConfig object as an argument.

      6. +

    Once both the animations are started, the window server will +automatically draw the animations onto the window by calling the Draw() method.

+
Download

Click on the following link to download the example: AnimExample.zip

Click: browse to view the example code.

+
Class +summary

  • CEikApplication

  • CEikDocument

  • CEikAppUi

    • @@ -46,14 +44,10 @@

  • CICLAnimationDataProvider

  • TAnimationConfig

-
Build

The Symbian -platform build process describes how to build an application. But, -use abld export command before abld build to -copy the animated .gif file to RAM (C:\ drive) -of the target platform.

The AnimExample builds an executable called AnimExample.exe in -the standard location (\epoc32\release\winscw\ udeb -or urel for CodeWarrior). Either launch the executable or launch the emulator -and then select the AnimExample application from the Emulator's extras bar.

-
See also

Using -Animation

+
Build

The Symbian platform build process describes how to build an +application. But, use abld export command before abld build to copy the animated .gif file to RAM (C:\ drive) of the target platform.

The AnimExample builds an executable called AnimExample.exe in the standard location (\epoc32\release\winscw\ udeb or urel for CodeWarrior). Either launch the executable +or launch the emulator and then select the AnimExample application +from the Emulator's extras bar.

+
See +also

Using Animation

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1AFDDD6F-CB99-587D-A0B5-D3F5B27F7135.dita --- a/Symbian3/SDK/Source/GUID-1AFDDD6F-CB99-587D-A0B5-D3F5B27F7135.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1AFDDD6F-CB99-587D-A0B5-D3F5B27F7135.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ Database in the Central Repository.

The Comms Database is available on all Symbian platforms.

- + Configuring diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1B64E1D9-33AB-4C28-A471-22D4C51FEC43.dita --- a/Symbian3/SDK/Source/GUID-1B64E1D9-33AB-4C28-A471-22D4C51FEC43.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1B64E1D9-33AB-4C28-A471-22D4C51FEC43.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@

The API to use for the information pop-up is the Info pop-up API.

Example of tooltip - +

Design recommendation: Tooltips must not be used for items that might open a stylus pop-up menu with touch down and hold.

diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1B93FFF8-5DDD-491F-86F5-5246B321D3C2-GENID-1-10-1-12-1-1-7-1-5-1-5-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-1B93FFF8-5DDD-491F-86F5-5246B321D3C2-GENID-1-10-1-12-1-1-7-1-5-1-5-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,67 @@ + + + + + +Updating +System TZ Data Using Software Installation +

This tutorial +describes how to update System TZ Data.

A client may need to update +the system time zone database as changes in existing time zone rules are introduced. +An example is the recent change in DST (daylight saving time) start and end +times in North America.

If there are new time zones in the updated +TZ database, the update also needs to include localization data for these +time zones.

There may also be a need to make changes to existing +time zones’ localization data. Examples of this include the correction of +typographic errors and reflecting city name changes. Notable city name changes +include Peking to Beijing and Leningrad to Saint Petersburg.

To update +system TZ data a client must create a SIS (Symbian installation) file that +contains the updated TZ database.

Create a Symbian Installation (SIS) +file that contains the updated TZ database. The SIS file may also contain +TZ localization resources. To create a SIS file you need to write a PKG (package) +file, which is a normal text file with the extension .pkg. +Example content of this file is given in the following steps:

 + +Specify a language. +An example is English. +

&EN

 + +Set a header. +

#{"System TZ Data Update"}, (0x200020B0), 1, 1, 0, TYPE=SP

 + +Specify the vendor. (This is Symbian): +

%{"Symbian Software Ltd."} +:"Symbian Software Ltd." +

 + +Define local files and the target location to be updated (eclipsed). +

"..\data\tzdb.dbz"-"$:\private\1020383E\tzdb.dbz" +"..\data\tz.r01 "-"$:\resource\timezonelocalization\timezones.r01" +"..\data\tzg.r01"-"$:\resource\timezonelocalization\timezonegroups.r01" +"..\data\tz.r02 "-"$:\resource\timezonelocalization\timezones.r02" +"..\data\tzg.r02"-"$:\resource\timezonelocalization\timezonegroups.r02"

 +

The sample includes the TZ database and two sets of TZ localization +resources files, one for English (*.r01) and one for French +(*.r02).

The PKG file can reference one TZ database. +The TZ database may be omitted if the update does not require any changes +to the TZ rules within the TZ database.

The PKG file can reference +any number of sets of TZ localization resources. These resources may be omitted +if the update does not require any changes to the TZ localization strings. +

For information on building SIS files from PKG files see Secure +Software Install SIS Tools.

+ + + + +Secure Software +Install SIS Tools Reference +Package file +format + + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1B93FFF8-5DDD-491F-86F5-5246B321D3C2-GENID-1-10-1-12-1-1-7-1-5-1-8-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-1B93FFF8-5DDD-491F-86F5-5246B321D3C2-GENID-1-10-1-12-1-1-7-1-5-1-8-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,67 @@ + + + + + +Updating +System TZ Data Using Software Installation +

This tutorial +describes how to update System TZ Data.

A client may need to update +the system time zone database as changes in existing time zone rules are introduced. +An example is the recent change in DST (daylight saving time) start and end +times in North America.

If there are new time zones in the updated +TZ database, the update also needs to include localization data for these +time zones.

There may also be a need to make changes to existing +time zones’ localization data. Examples of this include the correction of +typographic errors and reflecting city name changes. Notable city name changes +include Peking to Beijing and Leningrad to Saint Petersburg.

To update +system TZ data a client must create a SIS (Symbian installation) file that +contains the updated TZ database.

Create a Symbian Installation (SIS) +file that contains the updated TZ database. The SIS file may also contain +TZ localization resources. To create a SIS file you need to write a PKG (package) +file, which is a normal text file with the extension .pkg. +Example content of this file is given in the following steps:

 + +Specify a language. +An example is English. +

&EN

 + +Set a header. +

#{"System TZ Data Update"}, (0x200020B0), 1, 1, 0, TYPE=SP

 + +Specify the vendor. (This is Symbian): +

%{"Symbian Software Ltd."} +:"Symbian Software Ltd." +

 + +Define local files and the target location to be updated (eclipsed). +

"..\data\tzdb.dbz"-"$:\private\1020383E\tzdb.dbz" +"..\data\tz.r01 "-"$:\resource\timezonelocalization\timezones.r01" +"..\data\tzg.r01"-"$:\resource\timezonelocalization\timezonegroups.r01" +"..\data\tz.r02 "-"$:\resource\timezonelocalization\timezones.r02" +"..\data\tzg.r02"-"$:\resource\timezonelocalization\timezonegroups.r02"

 +

The sample includes the TZ database and two sets of TZ localization +resources files, one for English (*.r01) and one for French +(*.r02).

The PKG file can reference one TZ database. +The TZ database may be omitted if the update does not require any changes +to the TZ rules within the TZ database.

The PKG file can reference +any number of sets of TZ localization resources. These resources may be omitted +if the update does not require any changes to the TZ localization strings. +

For information on building SIS files from PKG files see Secure +Software Install SIS Tools.

+ + + + +Secure Software +Install SIS Tools Reference +Package file +format + + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1BA6BC6E-0B77-5B8A-AEF6-9E5DBAB36254.dita --- a/Symbian3/SDK/Source/GUID-1BA6BC6E-0B77-5B8A-AEF6-9E5DBAB36254.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Overview of the native build targets

Symbian platform natively runs on ARM processors that use the standard Application Binary Interface (ABI) to run the binary code. This standard interface enable the binaries created by different compilers (that meet the ABI standard) to operate together. For more information about the ABI specification, see http://www.arm.com/products/DevTools/ABI.html.

The Symbian platform build tools define native build targets that use either the ARM's RealView Compilation Tools (RVCT), or the GNU Compiler Collection (GCC), known as GCCE. Where, ARM RVCT (http://www.arm.com/products/DevTools/RealViewDevSuite.html) is particularly intended for licensees building ROMs for phones. GCCE is delivered on Symbian platform kits, and is also freely available from http://www.codesourcery.com.

There are two versions of the ARM ABI, referred to as v1 and v2 respectively. RVCT can be used to build for either of these ABI versions, and GCCE can only be used to build for ARM ABI v2.

In addition, the toolchain supports building to three versions of the ARM architecture; v5, v6, and v7. See http://www.arm.com/products/CPUs/architecture.html for details of the ARM architectures.

The build targets are intended to generate generic code suitable for execution on processors based on these architectures. The toolchain allows customisation by licensees, for example, in order to target a specific processor more closely: see ARMV5 build customisation.

A summary of the available targets is shown below:

Target name

Instruction set

Compiler

ABI

ARMV5

v5

RVCT 2.2

v1

ARMV5_ABIv2

v5

RVCT 2.2

v2

ARMV6

v6

RVCT 2.2

v1

ARMV6_ABIv2

v6

RVCT 2.2

v2

ARMV6t2

v6

RVCT 2.2

v2

ARMV7

v7

RVCT 3.1

v2

GCCE

v5

GCCE 3.4

v2

GCCEV6

v6

GCCE 3.4

v2

GCCEv6t2

v6

GCCE 3.4

v2

GCCEv7

v7

GCCE 4.2

v2

Notes:

  • The Symbian platform that you build using RVCT 4.0 provides run-time support for executables built using the RVCT 2.2, RVCT 3.1 and RVCT 4.0 toolchains.

  • From Symbian OS v9.4 onwards, the target names to build a binary conforming to ABIv2 are ARMV5 and ARMV6, and for ABIv1 they are ARMV5_ABIv1 and ARMV6_ABIv1. You can switch back to the conventional approach described in the table above. For more details, refer to Switching between ABI modes.

For details of these targets, see:

  • ARMV5 build targets

  • ARMV6 build targets

  • ARMV7 build target

  • GCCE build targets

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1BDADA7A-D517-49F4-AF46-AFC2B7758571.dita --- a/Symbian3/SDK/Source/GUID-1BDADA7A-D517-49F4-AF46-AFC2B7758571.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1BDADA7A-D517-49F4-AF46-AFC2B7758571.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,10 +16,10 @@ item is same as that of the scrollbar.

Slider setting item - +

The actual slider item usage is specified in applications.

-Default touch +<table id="GUID-4F77253E-5688-4642-98DD-04CB7FCF38E1-GENID-1-10-1-7-1-1-5-1-15-1-5-1-2-4"><title>Default touch events for slider setting item diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1BDBFC07-A8E8-5150-953D-CA9CFE1CBF16_d0e249822_href.jpg Binary file Symbian3/SDK/Source/GUID-1BDBFC07-A8E8-5150-953D-CA9CFE1CBF16_d0e249822_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1BDBFC07-A8E8-5150-953D-CA9CFE1CBF16_d0e254768_href.jpg Binary file Symbian3/SDK/Source/GUID-1BDBFC07-A8E8-5150-953D-CA9CFE1CBF16_d0e254768_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1BEA00A2-7934-5CF6-A838-44CCA4A28F35.dita --- a/Symbian3/SDK/Source/GUID-1BEA00A2-7934-5CF6-A838-44CCA4A28F35.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -Application registration files
Introduction

An application registration file defines information about an application that is required by the application launcher or system shell. This includes the application’s name, UID and properties. Other information required by the shell, for instance the icons and captions, is defined separately; the location of the icon/caption definitions is provided in the registration file. Before v8.1, all of this information was provided by aif files. In v8.1, both aif files and registration files are supported, but from v9.0 onwards, only registration files are supported.

- Registration files -

This diagram shows:

A registration file is required by every application, even if it has default properties, icons and caption. Minimally, it must specify the application's UID and the name of the application’s executable.

For an example, see An example registration file and icon/caption file.

Registration information

A registration file defines the following non-localisable application information; in other words, information that never varies according to the phone’s language setting:

  • the application’s properties, such as whether it is embeddable or hidden,

  • a group name; this may be used to categorize applications. Note that a group name may also be defined in the localisable file. If so, the localisable version will take precedence.

  • a number which identifies the screen on which the application is displayed (if the phone has multiple screens).

  • the MIME types supported by the application, and the priority of support for each,

  • a list of files owned by the application,

  • a flag that identifies non-standard types of application,

  • for server applications only, a list of the services provided.

All of these properties are defined using an APP_REGISTRATION_INFO resource struct. See its declaration in AppInfo.rh for the default values. For more information about these properties, see Defining application icons, captions and properties.

Most applications also need to define localisable information, for instance non-default captions and icons and possibly a group name (described above). The registration file specifies its location. This can be done in one of two ways:

  • as the name and path (excluding drive letter and extension) of a localisable icon/caption definition file,

  • as the ID of a LOCALISABLE_APP_INFO resource struct defined in the application’s UI resource file. In this case, the name and path of the application’s UI resource file (excluding drive letter and extension) must also be provided.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1C14ECA4-057B-5591-A8E3-F7DB0325E5AE_d0e215643_href.png Binary file Symbian3/SDK/Source/GUID-1C14ECA4-057B-5591-A8E3-F7DB0325E5AE_d0e215643_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1C14ECA4-057B-5591-A8E3-F7DB0325E5AE_d0e220641_href.png Binary file Symbian3/SDK/Source/GUID-1C14ECA4-057B-5591-A8E3-F7DB0325E5AE_d0e220641_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1C499E7D-8099-5BE4-AE46-6143388E6ACB.dita --- a/Symbian3/SDK/Source/GUID-1C499E7D-8099-5BE4-AE46-6143388E6ACB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1C499E7D-8099-5BE4-AE46-6143388E6ACB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Audio Input Streaming Tutorial

This tutorial describes how to use Audio Input Streaming.

Purpose

The purpose of this tutorial is to show you how to open, read and then close an audio input stream.

Required Background

The Audio Input Streaming Overview provides an introduction to Audio Input Streaming.

Introduction

The audio input stream interface class, CMdaAudioInputStream, enables MMF client applications to:

  • stream audio data from the low level audio controller (which has collected it from a hardware device, such as a microphone) to specified buffers (record audio).

  • specify the priority of the audio stream relative to other clients trying to use the same audio hardware

  • set the sample rate and the number of channels to use for recording.

  • change the gain and channel balance of the input stream.

The low level audio controller stores the audio data in buffers. CMdaAudioInputStream reads these buffers incrementally and does not have to wait until capture is complete.

Using Audio Input Streaming

Typically, using an audio input stream involves the following steps as shown in the sequence diagram below:

The following tasks will be covered in this tutorial:

  • Constructing an audio input stream

  • Opening an audio input stream

  • Getting and setting the stream properties

  • Reading an audio input stream

  • Stopping an audio input stream

Basic Procedure to Construct an Audio Input Stream

The high level step to construct an audio input stream is shown here:

  • The client application creates an audio input stream object using the static function CMdaAudioInputStream::NewL(). The input stream class provides two versions of the constructor: one with the default priority and preferences, and another with specified priority and preferences. The client application must also implement the observer class MMdaAudioInputStreamCallback to notify it about audio input streaming progress.

    The following code constructs an audio input stream:

    CMdaAudioInputStream* aInputStream; +Audio Input Streaming Tutorial

    This tutorial describes how to use Audio Input Streaming.

    Purpose

    The purpose of this tutorial is to show you how to open, read and then close an audio input stream.

    Required Background

    The Audio Input Streaming Overview provides an introduction to Audio Input Streaming.

    Introduction

    The audio input stream interface class, CMdaAudioInputStream, enables MMF client applications to:

    • stream audio data from the low level audio controller (which has collected it from a hardware device, such as a microphone) to specified buffers (record audio).

    • specify the priority of the audio stream relative to other clients trying to use the same audio hardware

    • set the sample rate and the number of channels to use for recording.

    • change the gain and channel balance of the input stream.

    The low level audio controller stores the audio data in buffers. CMdaAudioInputStream reads these buffers incrementally and does not have to wait until capture is complete.

    Using Audio Input Streaming

    Typically, using an audio input stream involves the following steps as shown in the sequence diagram below:

    The following tasks will be covered in this tutorial:

    • Constructing an audio input stream

    • Opening an audio input stream

    • Getting and setting the stream properties

    • Reading an audio input stream

    • Stopping an audio input stream

    Basic Procedure to Construct an Audio Input Stream

    The high level step to construct an audio input stream is shown here:

    • The client application creates an audio input stream object using the static function CMdaAudioInputStream::NewL(). The input stream class provides two versions of the constructor: one with the default priority and preferences, and another with specified priority and preferences. The client application must also implement the observer class MMdaAudioInputStreamCallback to notify it about audio input streaming progress.

      The following code constructs an audio input stream:

      CMdaAudioInputStream* aInputStream; aInputStream = CMdaAudioInputStream::NewL(aCallback, EMdaPriorityNormal, EMdaPriorityPreferenceTimeAndQuality);

      where, aCallback is an MMdaAudioInputStreamCallback object.

    Basic Procedure to Open an Audio Input Stream

    The high level steps to open an audio input stream are shown here:

    1. To open an input stream, use the Open() member function, which provides a pointer to the TMdaPackage object with the required audio settings. You can also open the stream without the audio settings. For example:

      aInputStream->Open(NULL);

    2. Once the stream is open, a MMdaAudioInputStreamCallback::MaiscOpenComplete() is issued to indicate that the stream is ready for use.

      void CIOStreamAudio::MaiscOpenComplete(TInt aError) { ASSERT(iState==EStateOpeningInput); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1CB7491C-1207-5C2E-979F-8ABEB95EE9D9.dita --- a/Symbian3/SDK/Source/GUID-1CB7491C-1207-5C2E-979F-8ABEB95EE9D9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1CB7491C-1207-5C2E-979F-8ABEB95EE9D9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@

      The following diagram describes all the node classes of the XML DOM Engine. Refer to the links below for more information about each class.

      XML DOM Engine classes - +

      • RXmlEngDocument

      • TXmlEngElement

        • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1CC6FEF0-7D1E-5329-8276-22ACFE3DE362.dita --- a/Symbian3/SDK/Source/GUID-1CC6FEF0-7D1E-5329-8276-22ACFE3DE362.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1CC6FEF0-7D1E-5329-8276-22ACFE3DE362.dita Tue Jul 20 12:00:49 2010 +0100 @@ -47,7 +47,7 @@ construct and maintain a CObjectIx object.

        The handle number is a combination of a unique id assigned to the object's container and a number generated by the object index.

        - +

        Subsession within a session
      Note
        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1D35F788-A470-5269-93E0-7C33A0013489.dita --- a/Symbian3/SDK/Source/GUID-1D35F788-A470-5269-93E0-7C33A0013489.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1D35F788-A470-5269-93E0-7C33A0013489.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Creating a Table This tutorial shows you how to create a Symbian SQL table.

        This tutorial uses code from the Basic SQL example application.

        Assumptions

        You have a database. The database has no tables and therefore no data.

        SQL statements

        The following SQL statements are used for this example:

        CREATE TABLE Pets( person TEXT, cat SMALLINT, dog SMALLINT, rodent SMALLINT, bird SMALLINT)

        The RSqlDatabase::Exec function provides a mechanism for executing Symbian SQL statements.

        Create a table The steps required to create a table are shown here: Declare a constant to hold the table handle: _LIT(KTabCreate,"CREATE TABLE Pets( person TEXT, cat SMALLINT, dog SMALLINT, rodent SMALLINT, bird SMALLINT);"); KTabCreate will be used later by the SQL EXECUTE command. Instantiate the required objects: RSqlDatabase db; +Creating a Table This tutorial shows you how to create a Symbian SQL table.

        This tutorial uses code from the Basic SQL example application.

        Assumptions

        You have a database. The database has no tables and therefore no data.

        SQL statements

        The following SQL statements are used for this example:

        CREATE TABLE Pets( person TEXT, cat SMALLINT, dog SMALLINT, rodent SMALLINT, bird SMALLINT)

        The RSqlDatabase::Exec function provides a mechanism for executing Symbian SQL statements.

        Create a table The steps required to create a table are shown here: Declare a constant to hold the table handle: _LIT(KTabCreate,"CREATE TABLE Pets( person TEXT, cat SMALLINT, dog SMALLINT, rodent SMALLINT, bird SMALLINT);"); KTabCreate will be used later by the SQL EXECUTE command. Instantiate the required objects: RSqlDatabase db; CConsoleBase* iConsole; This creates an RSqlDatabase object, which is needed to execute the SQL statement. Execute the SQL statement: db.Exec(KTabCreate) This will execute the SQL statement to create the table. The table now exists and you can begin adding data to it.

        Your database now has at least one table. You can begin to add data to the table and you can query and edit it.

        Create table example

        The following code snippet is from the example used for this tutorial:

        _LIT(KTabCreate,"CREATE TABLE Pets( person TEXT, cat SMALLINT, dog SMALLINT, rodent SMALLINT, bird SMALLINT);"); _LIT(KCreateTable,"\nCreating a table\n"); ... diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1D399C05-6CC0-4781-A6E1-1C94CFF8995B_d0e63101_href.png Binary file Symbian3/SDK/Source/GUID-1D399C05-6CC0-4781-A6E1-1C94CFF8995B_d0e63101_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1D399C05-6CC0-4781-A6E1-1C94CFF8995B_d0e63244_href.png Binary file Symbian3/SDK/Source/GUID-1D399C05-6CC0-4781-A6E1-1C94CFF8995B_d0e63244_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1DDFFB60-BBA8-500E-A9B1-F048EE5BFBD0_d0e189660_href.png Binary file Symbian3/SDK/Source/GUID-1DDFFB60-BBA8-500E-A9B1-F048EE5BFBD0_d0e189660_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1DDFFB60-BBA8-500E-A9B1-F048EE5BFBD0_d0e194631_href.png Binary file Symbian3/SDK/Source/GUID-1DDFFB60-BBA8-500E-A9B1-F048EE5BFBD0_d0e194631_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E25EE44-9421-549C-B79E-AEFE87308011_d0e311449_href.png Binary file Symbian3/SDK/Source/GUID-1E25EE44-9421-549C-B79E-AEFE87308011_d0e311449_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E25EE44-9421-549C-B79E-AEFE87308011_d0e317919_href.png Binary file Symbian3/SDK/Source/GUID-1E25EE44-9421-549C-B79E-AEFE87308011_d0e317919_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E446762-AFE2-4198-8CD7-8C4466392543.dita --- a/Symbian3/SDK/Source/GUID-1E446762-AFE2-4198-8CD7-8C4466392543.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1E446762-AFE2-4198-8CD7-8C4466392543.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ is depicted in the figure below.

        Choice list API classes - +

        The CAknChoiceList class provides an interface for controlling the choice list. You need to create separate instances of this class for each diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E4D4D69-E94F-5ABF-8DC7-063A37EF816F-master.png Binary file Symbian3/SDK/Source/GUID-1E4D4D69-E94F-5ABF-8DC7-063A37EF816F-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E4D4D69-E94F-5ABF-8DC7-063A37EF816F_d0e349910_href.png Binary file Symbian3/SDK/Source/GUID-1E4D4D69-E94F-5ABF-8DC7-063A37EF816F_d0e349910_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E4FFC56-8473-4E0A-B2E2-4E8DE8B1D00F.dita --- a/Symbian3/SDK/Source/GUID-1E4FFC56-8473-4E0A-B2E2-4E8DE8B1D00F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1E4FFC56-8473-4E0A-B2E2-4E8DE8B1D00F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Increasing the Priority of a Third-Party ApplicationThis section describes how a third-party application can increase its OOM priority by using OOM Monitor APIs. -

        Third-party applications +

        Third-party applications that needs to be running all the time can increase their priority to High from the default level (Normal). By increasing the priority, applications can protect itself from being closed by the OOM Monitor. For example:

          @@ -20,21 +20,21 @@

        • Instant Messaging application receiving messages

        are applications which listens for events from the network all the time.

        - -Create an OOM Monitor + +Create an OOM Monitor session ROomMonitorSession ioomMonitorSession; CleanUpClosePushL(ioomMonitorSession); User::LeaveIfError(ioomMonitorSession.Connect()); -Set the priority +Set the priority for the application to High . iOomMonitorSession.SetOomPriority(ROomMonitorSession::EOomPriorityHigh); DoCriticalBackgroundProcessingL(); -Close the session. +Close the session. iOomMonitorSession.Close(); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1E87CA7A-9733-58A1-A747-F5F3DE9B64D7.dita --- a/Symbian3/SDK/Source/GUID-1E87CA7A-9733-58A1-A747-F5F3DE9B64D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1E87CA7A-9733-58A1-A747-F5F3DE9B64D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,11 +30,11 @@

      • CEikAppUi

      • CCoeControl

      -
      Build

      The Symbian -build process describes how to build an application.

      The ControlFramework example builds an executable called ControlFramework.exe in the standard location (\epoc32\release\winscw\ <build_variant> for -CodeWarrior). Either launch the executable itself, or launch the emulator -and then select the ControlFramework application from the Emulator's -extras bar.

      +
      Build

      The Symbian build process describes how to build an application.

      The ControlFramework example builds an executable +called ControlFramework.exe in the standard location +(\epoc32\release\winscw\ <build_variant> for CodeWarrior). Either launch the executable itself, or launch +the emulator and then select the ControlFramework application from +the Emulator's extras bar.

      See also

      Using UI Control Framework (CONE)

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1EC68F99-C383-5D3A-BAE9-52AF530F8445_d0e184889_href.png Binary file Symbian3/SDK/Source/GUID-1EC68F99-C383-5D3A-BAE9-52AF530F8445_d0e184889_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1EC68F99-C383-5D3A-BAE9-52AF530F8445_d0e189886_href.png Binary file Symbian3/SDK/Source/GUID-1EC68F99-C383-5D3A-BAE9-52AF530F8445_d0e189886_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1F1A6FCD-DA06-5F8B-8F2C-0BAA08DE0041.dita --- a/Symbian3/SDK/Source/GUID-1F1A6FCD-DA06-5F8B-8F2C-0BAA08DE0041.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1F1A6FCD-DA06-5F8B-8F2C-0BAA08DE0041.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,56 +1,55 @@ - - - - - -How to -allocate buffersExplains the functions to create and allocate flat and segmented -buffers. -

      Allocating buffers is simple: use the desired class’s static NewL() function. -You must specify a granularity, whose meaning is particular to the -buffer type.

      -
      Flat buffer

      To allocate a flat buffer, use CFlatBuf::NewL(). -The granularity in this case means the number of bytes by which the buffer -will be re-allocated, whenever expansion is necessary. If expansion by a greater -amount than this is required, the next highest multiple of the granularity -will be used.

      In this example, the buffer pointer is pushed to the -cleanup stack for the lifetime of the buffer. If any operation involving the -buffer should leave, the buffer will be destroyed. In real use, the buffer -pointer would be stored as member data, and care should be taken to ensure -that the consequences of a leave are not fatal to the application. For example, -if the buffer is being used to store a word processor document, an attempt -to add a character may fail due to lack of memory. This should never cause -the entire document to be destroyed! Instead, the editing code should function -in such a way that the update is either implemented successfully, or no change -is made to the document.

      The function StandardBufferStuffL() is -one which takes a CBufBase type.

      // do flat buffer tests - CBufFlat* flatBuf=CBufFlat::NewL(4); - CleanupStack::PushL(flatBuf); - StandardBufferStuffL(flatBuf); - CleanupStack::PopAndDestroy();
      -
      Segmented buffer

      A segmented buffer is allocated -in a similar way to a flat buffer. The granularity in this case specifies -the size of each segment. During buffer operations, each segment may contain -less data than the granularity. After a compress, data is optimally distributed -to segments, so that all segments except possibly the last one are full.

      During -their lifetime, all standard buffer operations can be performed on either -flat or segmented buffers. This is shown in the examples above by calling standardBufferStuffL() with -both a flat and a segmented buffer pointer. The argument to this function -is a CBufBase*.

      The granularities chosen for these -examples are much smaller than would be used in most real applications.

      // do segmented buffer tests - CBufSeg* segBuf=CBufSeg::NewL(4); - CleanupStack::PushL(segBuf); - standardBufferStuffL(segBuf); - CleanupStack::PopAndDestroy();
      -       - -Space management -and granularity - + + + + + +How to allocate buffersExplains the functions to create and allocate flat and +segmented buffers. +

      Allocating buffers is simple: use the desired class’s static NewL() function. You must specify a granularity, +whose meaning is particular to the buffer type.

      +
      Flat +buffer

      To allocate a flat buffer, use CFlatBuf::NewL(). The granularity in this case means the number of bytes by which +the buffer will be re-allocated, whenever expansion is necessary. +If expansion by a greater amount than this is required, the next highest +multiple of the granularity will be used.

      In this example, +the buffer pointer is pushed to the cleanup stack for the lifetime +of the buffer. If any operation involving the buffer should leave, +the buffer will be destroyed. In real use, the buffer pointer would +be stored as member data, and care should be taken to ensure that +the consequences of a leave are not fatal to the application. For +example, if the buffer is being used to store a word processor document, +an attempt to add a character may fail due to lack of memory. This +should never cause the entire document to be destroyed! Instead, the +editing code should function in such a way that the update is either +implemented successfully, or no change is made to the document.

      The function StandardBufferStuffL() is one which +takes a CBufBase type.

      // do flat buffer tests + CBufFlat* flatBuf=CBufFlat::NewL(4); + CleanupStack::PushL(flatBuf); + StandardBufferStuffL(flatBuf); + CleanupStack::PopAndDestroy();
      +
      Segmented +buffer

      A segmented buffer is allocated in a similar way +to a flat buffer. The granularity in this case specifies the size +of each segment. During buffer operations, each segment may contain +less data than the granularity. After a compress, data is optimally +distributed to segments, so that all segments except possibly the +last one are full.

      During their lifetime, all standard buffer +operations can be performed on either flat or segmented buffers. This +is shown in the examples above by calling standardBufferStuffL() with both a flat and a segmented buffer pointer. The argument to +this function is a CBufBase*.

      The granularities +chosen for these examples are much smaller than would be used in most +real applications.

      // do segmented buffer tests + CBufSeg* segBuf=CBufSeg::NewL(4); + CleanupStack::PushL(segBuf); + standardBufferStuffL(segBuf); + CleanupStack::PopAndDestroy();
      +       + +Space management and granularity       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1F6DA049-AC03-5122-8B91-32C007A41526.dita --- a/Symbian3/SDK/Source/GUID-1F6DA049-AC03-5122-8B91-32C007A41526.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1F6DA049-AC03-5122-8B91-32C007A41526.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,91 +1,83 @@ - - - - - -SecureServerExample: -Implementing the Policy Server FrameworkThis example demonstrates the use of the policy server framework. -

      The example shows you how a server checks messages from a client against -a security policy. It also shows you how to deal with the result of a security -check.

      -

      The following sections provide more information about this example application:

      -
      Download

      Click -on the following link to download the example: SecureServer.zip

      Click: browse to view the example code.

      -
      Description

      The -server contains a simple counter. It can change the value of the counter. -It can also write the value of the counter to a file. The server offers the -following services to a client:

        -

      • Increase the value of -the counter by any number greater than 1.

        • -

      • Decrease the value of -the counter by any number greater than 1.

        • -

      • Increase the value of -the counter by 1.

        • -

      • Decrease the value of -the counter by 1.

        • -

      • Reset the counter to -its default value.

        • -

      • Reset the counter to -the value in the file counter.dat.

        • -

      • Save the counter value -in the file counter.dat.

        • -

      • Send the current value -of the counter to a client.

        • -

      • Create, initialise and -close a subsession.

        • -

      • Send the current number -of open subsessions to a client.

        • -

      The client sends a message to the server to request one of these -services. The server checks each request against its security policy. If the -request fails the security check, the request is rejected.

      The security -policy has the following rules:

        -

      • If a client asks the -server to increase the counter value by more than 10, the client ‘s SID value -must be less than or equal to 0x70fffff5.

        • -

      • If a client asks the -server to decrease the counter value by more than 10, the client ‘s SID value -must be less than or equal to 0x70fffff5.

        • -

      • If a client asks the -server for the number of open subsessions, the client’s SID value must be -0x70fffff0.

        • -

      • If a client asks the -server to save the counter value to the file counter.dat, -the client must have both ReadDeviceData and WriteDeviceData capabilities.

        • -

      • If a client asks the -server to reset the counter value from the file counter.dat, -the client must have both ReadDeviceData and WriteDeviceData capabilities.

        • -

      The example application shows how you to code security policies. -It also shows you the constants and classes that you must define to use the -policy server framework.

      -
      Class summary

      This -example demonstrates the following classes:

        -

      • CPolicyServer

        • -

      • CSession2

        • -

      • TVersion

        • -

      • RMessage2

        • -

      • CObject

        • -

      • CObjectCon

        • -

      • CObjectConIx

        • -

      • CObjectIx

        • -

      • RSessionBase

        • -

      • RThread

        • -

      • RSubSessionBase

        • -

      -
      Build

      The Symbian build process describes -how to build this example.

      The SecureServer example -builds the following binaries in the standard location (\epoc32\release\winscw\<build_variant>) -for Carbide.c++.

        -

      • secureclient.exe: -This is the client executable file. It starts the server and shows the behaviour -of the client.

        • -

      • secureserver.dll: -This is the DLL that contains the code for the server. This executable file -must be built before secureclient.exe file.

        • -
      + + + + + +SecureServerExample: Implementing the Policy Server FrameworkThis example demonstrates the use of the policy server +framework. +

      The example shows you how a server checks messages from a client +against a security policy. It also shows you how to deal with the +result of a security check.

      +

      The following sections provide more information about this example +application:

      +
      Download

      Click on the following link to download the example: SecureServer.zip

      Click: browse to view the example code.

      +
      Description

      The server contains a simple counter. It can change the value +of the counter. It can also write the value of the counter to a file. +The server offers the following services to a client:

        +

      • Increase the +value of the counter by any number greater than 1.

        • +

      • Decrease the +value of the counter by any number greater than 1.

        • +

      • Increase the +value of the counter by 1.

        • +

      • Decrease the +value of the counter by 1.

        • +

      • Reset the counter +to its default value.

        • +

      • Reset the counter +to the value in the file counter.dat.

        • +

      • Save the counter +value in the file counter.dat.

        • +

      • Send the current +value of the counter to a client.

        • +

      • Create, initialise +and close a subsession.

        • +

      • Send the current +number of open subsessions to a client.

        • +

      The client sends a message to the server to request one of +these services. The server checks each request against its security +policy. If the request fails the security check, the request is rejected.

      The security policy has the following rules:

        +

      • If a client +asks the server to increase the counter value by more than 10, the +client ‘s SID value must be less than or equal to 0x70fffff5.

        • +

      • If a client +asks the server to decrease the counter value by more than 10, the +client ‘s SID value must be less than or equal to 0x70fffff5.

        • +

      • If a client +asks the server for the number of open subsessions, the client’s SID +value must be 0x70fffff0.

        • +

      • If a client +asks the server to save the counter value to the file counter.dat, the client must have both ReadDeviceData and WriteDeviceData capabilities.

        • +

      • If a client +asks the server to reset the counter value from the file counter.dat, the client must have both ReadDeviceData and WriteDeviceData capabilities.

        • +

      The example application shows how you to code security policies. +It also shows you the constants and classes that you must define to +use the policy server framework.

      +
      Class +summary

      This example demonstrates the following classes:

        +

      • CPolicyServer

        • +

      • CSession2

        • +

      • TVersion

        • +

      • RMessage2

        • +

      • CObject

        • +

      • CObjectCon

        • +

      • CObjectConIx

        • +

      • CObjectIx

        • +

      • RSessionBase

        • +

      • RThread

        • +

      • RSubSessionBase

        • +

      +
      Build

      The Symbian build process describes how to build this example.

      The SecureServer example builds +the following binaries in the standard location (\epoc32\release\winscw\<build_variant>) for Carbide.c++.

        +

      • secureclient.exe: This is the client executable file. It starts the server and shows +the behaviour of the client.

        • +

      • secureserver.dll: This is the DLL that contains the code for the server. This executable +file must be built before secureclient.exe file.

        • +
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1FC88405-616F-5ED1-A136-9FE1E9226F0E.dita --- a/Symbian3/SDK/Source/GUID-1FC88405-616F-5ED1-A136-9FE1E9226F0E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1FC88405-616F-5ED1-A136-9FE1E9226F0E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Exif Utility Library Guide

      Exif (Exchangeable image file format) is a standard specifying rules for storing metadata in digital image files, mainly those using JPEG compression.

      Purpose

      Exif enhances the JPEG and TIFF specifications with the addition of metadata tags to hold information such as the camera settings used to take the picture.

      Exif Overview

      The Exif standard defines a wide range of metadata tags, some of which are listed below:

      • Date and time information of the image captured.

      • Camera settings like camera model and make, and information that varies with each image such as orientation, aperture, shutter speed, focal length, metering mode, and film speed information.

      • A thumbnail for previewing the picture on camera LCD.

      • Copyright information.

      Accessing Exif Metadata

      Access to Exif metadata is provided through an abstract interface available in all the main ICL APIs. This interface can be implemented and managed through an ICL plugin, exhibiting the functionality to the client through the plugin extension mechanism.

      The MExifMetaData class is a generic interface for accessing the Exif metadata. To access a specific item of a metadata, both tag ID and the primary Image File Directory [IFD] number must be provided in the MExifMetaData access method, as some tags may appear in more than one IFD. The primary IFD number may either be 0 or 1. The main image tags are grouped together under IFD 0 and the tags for the thumbnail images are grouped under IFD 1 in the Exif metadata. The tags under these IFD can be further classified into sub IFD:

      For example : Tags related to the GPS can be sorted to form a group.

      The MExifMetaData is compounded by two classes as mentioned below:

      • MExifMetadataReader : This provides more generic functionalitites to read the tags from the Exif Metadata. The user is expected to provide the tag id and the primary IFD for the tags that needs to be read.

      • MExifMetadataWriter : This is a generic way to write or set the tags of the Exif metadata. Here also the user is expected to render the key inputs like tag id and IFD for the data that needs to be written or modified.

      The access provided by MExifMetaData is quite low level. The users are expected to know the tag IDs defined in the Exif specification in order to use it. Hence more user friendly classes as listed below are made available to access these tags.

      Examples

      This section contains code snippets showing how Exif metadata is accessed in several situations.

      JPEG Exif Plugin

      • TExifReaderUtility : This class provides a user friendly interface for reading the metadata in Exif encoded image files. The following example code illustrates its use:

        void CIclExample::AccessToEXIFMetadataL(const TDesC& aFileName) +Exif Utility Library Guide

        Exif (Exchangeable image file format) is a standard specifying rules for storing metadata in digital image files, mainly those using JPEG compression.

        Purpose

        Exif enhances the JPEG and TIFF specifications with the addition of metadata tags to hold information such as the camera settings used to take the picture.

        Exif Overview

        The Exif standard defines a wide range of metadata tags, some of which are listed below:

        • Date and time information of the image captured.

        • Camera settings like camera model and make, and information that varies with each image such as orientation, aperture, shutter speed, focal length, metering mode, and film speed information.

        • A thumbnail for previewing the picture on camera LCD.

        • Copyright information.

        Accessing Exif Metadata

        Access to Exif metadata is provided through an abstract interface available in all the main ICL APIs. This interface can be implemented and managed through an ICL plugin, exhibiting the functionality to the client through the plugin extension mechanism.

        The MExifMetaData class is a generic interface for accessing the Exif metadata. To access a specific item of a metadata, both tag ID and the primary Image File Directory [IFD] number must be provided in the MExifMetaData access method, as some tags may appear in more than one IFD. The primary IFD number may either be 0 or 1. The main image tags are grouped together under IFD 0 and the tags for the thumbnail images are grouped under IFD 1 in the Exif metadata. The tags under these IFD can be further classified into sub IFD:

        For example : Tags related to the GPS can be sorted to form a group.

        The MExifMetaData is compounded by two classes as mentioned below:

        • MExifMetadataReader : This provides more generic functionalitites to read the tags from the Exif Metadata. The user is expected to provide the tag id and the primary IFD for the tags that needs to be read.

        • MExifMetadataWriter : This is a generic way to write or set the tags of the Exif metadata. Here also the user is expected to render the key inputs like tag id and IFD for the data that needs to be written or modified.

        The access provided by MExifMetaData is quite low level. The users are expected to know the tag IDs defined in the Exif specification in order to use it. Hence more user friendly classes as listed below are made available to access these tags.

        Examples

        This section contains code snippets showing how Exif metadata is accessed in several situations.

        JPEG Exif Plugin

        • TExifReaderUtility : This class provides a user friendly interface for reading the metadata in Exif encoded image files. The following example code illustrates its use:

          void CIclExample::AccessToEXIFMetadataL(const TDesC& aFileName) { HBufC8* buffer8Bit=NULL; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1FCD0312-7B28-47F9-BE54-822B74A8934C.dita --- a/Symbian3/SDK/Source/GUID-1FCD0312-7B28-47F9-BE54-822B74A8934C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1FCD0312-7B28-47F9-BE54-822B74A8934C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,84 +1,81 @@ - - - - -Designing applications for touch UI - - - - -

          Both touch screens and hybrid devices are supported by Symbian -platform. Touch screen enables direct manipulation of content and -objects, allowing for far more natural interaction with the device. -This means a completely different user experience and interaction -style compared to using a hardware keypad.

          - -

          All applications must be touch-enabled, which means that they can -be used with the touch screen alone, regardless of the presence of -a keypad. In Symbian platform-based touch devices, the important hardware -keys are Send, End, Multi-tasking and Power key.

          -

          The application features must follow the platform support for different -hardware. When designing a touch-enabled Symbian application, the -UI must be designed so that everything can be accomplished by using -the touch screen interface, as the potential target devices may or -may not have a hardware keyboard.

          -

          The touch UI in the Symbian platform is based on the use of resistive -and capacitive touch screens. In resistive touch screen technology, -two conductive and resistive layers are separated by a thin space. -When an object touches this kind of touch panel, the layers are connected -at a certain point, and a touch event is registered. This allows efficient -stylus control, in addition to finger touch - unlike capacitive panels, -which usually register only finger touch. Additionally, resistive -touch screen offers a higher resolution and more durability. In capacitive touch screen technology, the panel consists of an -insulator such as glass, coated with a transparent conductor (such -as indium tin oxide (ITO)). When an object touches the surface of -the screen, it results in a distortion of the local electrostatic -field, measurable as a change in capacitance. Then a touch controller -measures the frequency variations to ascertain the co-ordinates of -the object's touch. Capacitive touch screen supports multiple touch.

          -

          The hardware is supported by various:

          -
            -

          • touch-specific components (see Touch support -for common UI components)

            • -

          • component and UI behavior changes

            • -

          • layout changes, and

            • -

          • additions to the interaction style.

            • -
          -

          The touch UI is designed to enable full task flow with touch, with -minimal need to switch to hardware keys. Thus, the design ensures -that users can complete a task with the chosen interaction method -from start to finish.

          -

          While designing and implementing applications for touch screen -devices based on the Symbian platform, consider interactions that -benefit the most from the touch UI.

          -

          If you can apply direct manipulation of the UI, for example when -moving items from one place to another, or scrolling a page, do not -confine the user with unnecessary scrollbars or have the user resort -to options list commands.

          -

          Instead, enable the user to view pages larger than a screen by -panning them directly, and dragging and dropping items rather than -marking them and using menu options.

          -
            -

          • Remember that the most intuitive touch screen interactions -that can be performed using a finger are tapping, stroking up/down/left/right, -and the long tap.

            • -

          • Utilize strokes that are easily discovered to the users in -the given context. It should be explicit to the user where strokes -can be performed.

            • -

          • Design to ensure that users can complete a task with the same -interaction method from start to finish - touch or hardware keys, -stylus, or finger, and using one hand or both hands.

            • -

          • Aim to optimize system performance and battery consumption -to provide a fluid and reliable touch user experience.

            • -
          -

          See Also:

          -           -           - + + + + + +Designing applications for touch UI +

          Both touch screens and hybrid devices are supported by Symbian +platform. Touch screen enables direct manipulation of content and +objects, allowing for far more natural interaction with the device. +This means a completely different user experience and interaction +style compared to using a hardware keypad.

          + + + + +

          All applications must be touch-enabled, which means that they can +be used with the touch screen alone, regardless of the presence of +a keypad. In Symbian platform-based touch devices, the important hardware +keys are Send, End, Multi-tasking and Power key.

          +

          The application features must follow the platform support for different +hardware. When designing a touch-enabled Symbian application, the +UI must be designed so that everything can be accomplished by using +the touch screen interface, as the potential target devices may or +may not have a hardware keyboard.

          +

          The touch UI in the Symbian platform is based on the use of resistive +and capacitive touch screens. In resistive touch screen technology, +two conductive and resistive layers are separated by a thin space. +When an object touches this kind of touch panel, the layers are connected +at a certain point, and a touch event is registered. This allows efficient +stylus control, in addition to finger touch - unlike capacitive panels, +which usually register only finger touch. Additionally, resistive +touch screen offers a higher resolution and more durability. In capacitive touch screen technology, the panel consists of an +insulator such as glass, coated with a transparent conductor (such +as indium tin oxide (ITO)). When an object touches the surface of +the screen, it results in a distortion of the local electrostatic +field, measurable as a change in capacitance. Then a touch controller +measures the frequency variations to ascertain the co-ordinates of +the object's touch. Capacitive touch screen supports multiple touch.

          +

          The hardware is supported by various:

          +
            +

          • touch-specific components (see Touch support for +common UI components)

            • +

          • component and UI behavior changes

            • +

          • layout changes, and

            • +

          • additions to the interaction style.

            • +
          +

          The touch UI is designed to enable full task flow with touch, with +minimal need to switch to hardware keys. Thus, the design ensures +that users can complete a task with the chosen interaction method +from start to finish.

          +

          While designing and implementing applications for touch screen +devices based on the Symbian platform, consider interactions that +benefit the most from the touch UI.

          +

          If you can apply direct manipulation of the UI, for example when +moving items from one place to another, or scrolling a page, do not +confine the user with unnecessary scrollbars or have the user resort +to options list commands.

          +

          Instead, enable the user to view pages larger than a screen by +panning them directly, and dragging and dropping items rather than +marking them and using menu options.

          +
            +

          • Remember that the most intuitive touch screen interactions +that can be performed using a finger are tapping, stroking up/down/left/right, +and the long tap.

            • +

          • Utilize strokes that are easily discovered to the users in +the given context. It should be explicit to the user where strokes +can be performed.

            • +

          • Design to ensure that users can complete a task with the same +interaction method from start to finish - touch or hardware keys, +stylus, or finger, and using one hand or both hands.

            • +

          • Aim to optimize system performance and battery consumption +to provide a fluid and reliable touch user experience.

            • +
          +

          See Also:

          +           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-1FE5D4D5-B2BF-4090-9F69-D538B2220DA3.dita --- a/Symbian3/SDK/Source/GUID-1FE5D4D5-B2BF-4090-9F69-D538B2220DA3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-1FE5D4D5-B2BF-4090-9F69-D538B2220DA3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,9 +13,9 @@ Global Variable ExampleThis example demonstrates:

          How to handle global variables within the library code

          How to use WSD (Writable Static Data) in dll

          -
          Download

          Click +

          Download

          Click on the following link to download the example: handleglobalvar.zip

          Click: browse to view the example code.

          -
          Design and +<section id="GUID-7E7C4564-B10E-41F9-8A9D-D8A6C5E9C51C-GENID-1-10-1-13-1-1-5-1-3-1-11-1-10-1-3-4"><title>Design and Implementation

          The following sections provide information about the implementation of the example.

          Capabilities

          The program capabilities are defined in globalvarex.mmp: CAPABILITY @@ -28,7 +28,7 @@ it's required. For target release, use global variables and add EPOCALLOWDLLDATA in the library mmp file. wsddll.h and wsddll.cpp implement the concept of how to handle WSD data in Dll.
          -
          Building and +<section id="GUID-67A72761-1D92-46D1-B1C9-7455978BDE4E-GENID-1-10-1-13-1-1-5-1-3-1-11-1-10-1-3-5"><title>Building and Using To build the handleglobalvar example application, go to the handleglobalvar\group directory and build the application. The definition for the whole application can be found in the bld.inf file in the group subdirectory diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-201E6D4C-5F0F-5AA2-BC79-91E3C62C8971.dita --- a/Symbian3/SDK/Source/GUID-201E6D4C-5F0F-5AA2-BC79-91E3C62C8971.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -How to write a meta file

          A meta file is an additional information file associated with each template extension makefile. It is used to set values to attributes to specify the build platform, makefile type and default option values for the extension. The meta file name is same as that of the associated template extension makefile, except the .mk suffix is replaced with .meta.

          The following provides a step-by-step explanation to write a meta file:

          1. Specify whether the makefile is of type gnumake (GCC make format) or nmake (Microsoft make format) using the keyword makefile. It is recommended to use gnumake, as most of the templates are based on GNU make format. The value nmake is not recommended as use of nmake is deprecated.

          2. Specify the platform using the keyword platform which is optional. it is useful to specify the platform, if you want to build for a specific platform such as WINSCW, ARMV5 and so on.

          3. Specify the default values for options specific to the extension, using the keyword option which is optional. These default values can be changed in the bld.inf file within the START - EXTENSION ... END block. For more information on START - EXTENSION, refer to prj_extensions.

          For more information on meta file syntax, refer to Meta Files.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20B2C96A-9742-4CB0-A37F-19B65765E826.dita --- a/Symbian3/SDK/Source/GUID-20B2C96A-9742-4CB0-A37F-19B65765E826.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-20B2C96A-9742-4CB0-A37F-19B65765E826.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ virtual void DecodeL(const TDesC8& aData, HBufC8*& aHTTPData, TBool& aTransFail) = 0; }; -
          The EncodeL() +<section id="GUID-6E64E5BA-0FA7-5B9D-987E-09F2D5F53AE8-GENID-1-10-1-15-1-1-3-1-3-1-13-1-4-1-4-1-2-3"> <title>The EncodeL() method

          This method converts HTTP request data (to your selected network optimisation protocol format) before it is sent across the TCP connection. This method has the following parameters:

            @@ -36,7 +36,7 @@ format.

          Note: It is assumed that you define a custom optimisation mechanism to encode the HTTP request data by implementing the EncodeL() method.

          -
          The DecodeL() +<section id="GUID-6E64E5BA-0FA7-5B9D-987E-09F2D5F53AE8-GENID-1-10-1-15-1-1-3-1-3-1-13-1-4-1-4-1-2-4"> <title>The DecodeL() method

          This method converts the HTTP response data in your selected network optimisation protocol format back to the standard HTTP response data format. This method has the following parameters:

            diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20B364FB-FC12-5EF1-B0EC-1A845693EFFD_d0e202333_href.png Binary file Symbian3/SDK/Source/GUID-20B364FB-FC12-5EF1-B0EC-1A845693EFFD_d0e202333_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20B364FB-FC12-5EF1-B0EC-1A845693EFFD_d0e207340_href.png Binary file Symbian3/SDK/Source/GUID-20B364FB-FC12-5EF1-B0EC-1A845693EFFD_d0e207340_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20FECB77-2E1D-4104-948F-8E878DAFE1B8_d0e67767_href.png Binary file Symbian3/SDK/Source/GUID-20FECB77-2E1D-4104-948F-8E878DAFE1B8_d0e67767_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20FECB77-2E1D-4104-948F-8E878DAFE1B8_d0e67831_href.png Binary file Symbian3/SDK/Source/GUID-20FECB77-2E1D-4104-948F-8E878DAFE1B8_d0e67831_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20FEEF54-23CB-4D30-B846-11B4ACE8E772_d0e5827_href.png Binary file Symbian3/SDK/Source/GUID-20FEEF54-23CB-4D30-B846-11B4ACE8E772_d0e5827_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-20FEEF54-23CB-4D30-B846-11B4ACE8E772_d0e5948_href.png Binary file Symbian3/SDK/Source/GUID-20FEEF54-23CB-4D30-B846-11B4ACE8E772_d0e5948_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e237328_href.png Binary file Symbian3/SDK/Source/GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e237328_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e242308_href.png Binary file Symbian3/SDK/Source/GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e242308_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-215528EA-E12E-590A-9C17-394F36F2C268.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-215528EA-E12E-590A-9C17-394F36F2C268.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,35 @@ + + + + + +Data Compatibility
            Database File Format

            The database file format is unchanged from previous versions of the Contacts Model.

            Database Files Stored on Removable Media

            Databases stored on removable media using a device with the previous version of the Contacts Model are not accessible by a device using the new version of the Contacts Model. Similarly, databases stored on removable media using devices with the new version of the Contacts Model are not accessible by a device using the previous version.

            Database Restore

            Databases restored from a backup made using a device with the previous version of the Contacts Model are not accessible by a device using the new version of the Contacts Model. Similarly, databases restored from a backup using a device with the new version of the Contacts Model are not accessible by a device using the previous version.

            Database File Locations

            The previous version of the Contacts Model stored database files in the secure DBMS directory:

            c:\private\100012a5\DBS_100065FF_ <dbname>.cdb

            This directory is no longer used since the new Contacts Model does not use the secure DBMS directory. The new version of the Contacts Model stores database files in:

            c:\private\10003a73\<dbname>.cdb

            Backup Registration Files

            Backup registration files remain in the C:\private\10003a73 directory.

            In the previous version of the Contacts Model there was one pre-created file for backup/restore of the initialisation file and contacts databases:

            <?xml version="1.0" standalone="yes"?> + +<!-- + Copyright (c) Symbian Software Ltd 2004-2005. All Rights Reserved +--> + +<backup_registration> + <passive_backup base_backup_only="yes"> + <include_file name = "cntmodel.ini"/> + </passive_backup> + <dbms_backup database="contacts.cdb" policy="100065FF"/> +</backup_registration>

            A separate backup registration file was created at run time for each additional contacts database, for example:

            <backup_registration> + <dbms_backup database="anotherdb.cdb" policy="100065FF"/> +</backup_registration>

            In the new Contacts Model there is a separate file automatically generated for each data file (initialisation file and each contacts database, including the default database).

            For example, the backup registration file (backup_registration_CntModel_ini.xml) for the initialisation file would have the following contents:

            <?xml version="1.0" standalone="yes"?> +<backup_registration> + <passive_backup base_backup_only="yes"> + <include_file name="CntModel.ini"/> + </passive_backup> +</backup_registration>

            The backup registration file (backup_registration_default_cdb.xml) for the default database default.cdb would have the following contents:

            <?xml version="1.0" standalone="yes"?> +<backup_registration> + <passive_backup base_backup_only="yes"> + <include_file name="default.cdb"/> + </passive_backup> +</backup_registration>

            Note that there is no reference to DBMS in the new file since we do not use the secure DBMS directory in the new Contacts Model.

            \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2161BD64-889B-5EAB-B023-1162FE9619DB.dita --- a/Symbian3/SDK/Source/GUID-2161BD64-889B-5EAB-B023-1162FE9619DB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2161BD64-889B-5EAB-B023-1162FE9619DB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,7 +39,7 @@ object is not relevant to the example and is not shown.

            The following diagram shows the relationship between the classes.

            - +
            Encapsulating the service provider

            The class CActiveConsole encapsulates the provision of basic keyboard services. Its iConsole data diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-217C992B-AC56-42A7-9920-DEC891D233A5.dita --- a/Symbian3/SDK/Source/GUID-217C992B-AC56-42A7-9920-DEC891D233A5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-217C992B-AC56-42A7-9920-DEC891D233A5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,20 +19,20 @@ as soon as it is not needed anymore. An application can also keep the optional RAM allocation until OOM Monitor requests to release it.

            - -Create an OOM Monitor + +Create an OOM Monitor session. ROomMonitorSession ioomMonitorSession; CleanUpClosePushL(ioomMonitorSession); User::LeaveIfError(ioomMonitorSession.Connect()); -Request for optional +Request for optional RAM. iOomMonitorSession.RequestOptionalRam(aBytesRequested,aMinimumBytesNeeded,aPluginId,aBytesAvailable);

            -Close the session. +Close the session. iOomMonitorSession.Close(); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21A1D1D2-524E-560E-88C8-16E2E49E2B7F_d0e252674_href.jpg Binary file Symbian3/SDK/Source/GUID-21A1D1D2-524E-560E-88C8-16E2E49E2B7F_d0e252674_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21A1D1D2-524E-560E-88C8-16E2E49E2B7F_d0e257599_href.jpg Binary file Symbian3/SDK/Source/GUID-21A1D1D2-524E-560E-88C8-16E2E49E2B7F_d0e257599_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21E43B0E-85C7-536E-83A5-E829820775BF_d0e283471_href.png Binary file Symbian3/SDK/Source/GUID-21E43B0E-85C7-536E-83A5-E829820775BF_d0e283471_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21E43B0E-85C7-536E-83A5-E829820775BF_d0e288310_href.png Binary file Symbian3/SDK/Source/GUID-21E43B0E-85C7-536E-83A5-E829820775BF_d0e288310_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e190335_href.png Binary file Symbian3/SDK/Source/GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e190335_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e195306_href.png Binary file Symbian3/SDK/Source/GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e195306_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21F0EE0E-6CC6-44E7-9FED-FB8911E3C3A2_d0e211670_href.jpg Binary file Symbian3/SDK/Source/GUID-21F0EE0E-6CC6-44E7-9FED-FB8911E3C3A2_d0e211670_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-21F0EE0E-6CC6-44E7-9FED-FB8911E3C3A2_d0e216668_href.jpg Binary file Symbian3/SDK/Source/GUID-21F0EE0E-6CC6-44E7-9FED-FB8911E3C3A2_d0e216668_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita --- a/Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ and lower loops.

            The Window Server's upper and lower rendering loops - +

            The upper loop is the process by which the Window Server’s scene @@ -43,7 +43,7 @@

          The main participants in the ScreenPlay Window Server rendering loop - +

          On the client side, RWindow and CWindowGc commands are converted to opcodes that are stored in a command buffer. When the command @@ -101,7 +101,7 @@ window on the screen.

          A transition effect temporarily obscures a window on the screen - +

          In this and similar scenarios, the Window Server does not know whether a window is obscured or visible. Therefore dirty-rectangle tracking is not diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-220D3B2F-7A88-55AB-942F-1735A6E9E420_d0e323992_href.png Binary file Symbian3/SDK/Source/GUID-220D3B2F-7A88-55AB-942F-1735A6E9E420_d0e323992_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-220D3B2F-7A88-55AB-942F-1735A6E9E420_d0e330462_href.png Binary file Symbian3/SDK/Source/GUID-220D3B2F-7A88-55AB-942F-1735A6E9E420_d0e330462_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-220D7D10-5571-46C4-BA2B-B4FBAE4153F1_d0e36193_href.png Binary file Symbian3/SDK/Source/GUID-220D7D10-5571-46C4-BA2B-B4FBAE4153F1_d0e36193_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-220D7D10-5571-46C4-BA2B-B4FBAE4153F1_d0e36360_href.png Binary file Symbian3/SDK/Source/GUID-220D7D10-5571-46C4-BA2B-B4FBAE4153F1_d0e36360_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22498580-E902-4024-921C-F756A8CD58DF_d0e70545_href.png Binary file Symbian3/SDK/Source/GUID-22498580-E902-4024-921C-F756A8CD58DF_d0e70545_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22498580-E902-4024-921C-F756A8CD58DF_d0e70568_href.png Binary file Symbian3/SDK/Source/GUID-22498580-E902-4024-921C-F756A8CD58DF_d0e70568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22699952-D032-5B69-B38A-43347A40A420_d0e355499_href.png Binary file Symbian3/SDK/Source/GUID-22699952-D032-5B69-B38A-43347A40A420_d0e355499_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22699952-D032-5B69-B38A-43347A40A420_d0e384492_href.png Binary file Symbian3/SDK/Source/GUID-22699952-D032-5B69-B38A-43347A40A420_d0e384492_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2273C35F-C8FD-5321-BAE8-4995C5B374E5.dita --- a/Symbian3/SDK/Source/GUID-2273C35F-C8FD-5321-BAE8-4995C5B374E5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --what

          This option creates a list of files in exactly the same way as option -check. The list of files is then piped to STDOUT.

          The option could be useful to find out where a particular build step is creating files, or for creating a zip file containing the releasables for a component by piping the list of files to a file and then having a zip utility process this file.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22844C28-AB5B-5A6F-8863-7269464684B4.dita --- a/Symbian3/SDK/Source/GUID-22844C28-AB5B-5A6F-8863-7269464684B4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-22844C28-AB5B-5A6F-8863-7269464684B4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -36,7 +36,7 @@ It can only be reached via the client-side interface.

          This image depicts the client / server nature of Symbian SQL - +
          API summary

          The SQL component client consists of three APIs which are used to access, query and secure a database.

          SQL APIs

            diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-22F4D9EA-9912-466E-B729-7706BC17BDA1.dita --- a/Symbian3/SDK/Source/GUID-22F4D9EA-9912-466E-B729-7706BC17BDA1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-22F4D9EA-9912-466E-B729-7706BC17BDA1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,45 +1,44 @@ - - - - - -Write -a converter DLL project file -

            Project file defines the location of the source files that -required are to build a plug-in.

            To write a converter DLL project file, -specify the following in the .mmp file:

              -

            • The extension of the target file as .dll.

              • -

            • The TARGETTYPE as plugin.

              • -

            • The second UID as 0x10009d8d. This value identifies -the DLL as an ECom plug-in. The third UID (0xE800009B in -this example) must be unique and properly allocated. See the Symbian -SignedSymbian Signed web site for information on how to allocate UIDs.

              • -

            • The library section must include conarc.lib.

              • -

            The following is an example of an .mmp file that -builds a converter DLL called EXAMPLECONV.dll:

            // ExampleConv.MMP -target exampleconv.dll -targettype plugin -UID 0x10009d8d 0xE800009B -VENDORID 0x70000001 -CAPABILITY All -Tcb -sourcepath . -start resource E800009B.rss -target exampleconv.rsc -end -start resource E80000AC.rss -targetpath /resource/convert -end -userinclude . -systeminclude . /epoc32/include -systeminclude /epoc32/include/ecom -source ExampleConv.CPP -library euser.lib -library conarc.lib estor.lib -             + + + + + +Write a converter DLL project file +

            Project file defines the location of the source +files that required are to build a plug-in.

            To write a converter +DLL project file, specify the following in the .mmp file:

              +

            • The extension of the target file as .dll.

              • +

            • The TARGETTYPE as plugin.

              • +

            • The second UID as 0x10009d8d. This value identifies +the DLL as an ECom plug-in. The third UID (0xE800009B in this example) must be unique and properly allocated. See the Symbian +Signed Symbian Signed web site for information on how to allocate +UIDs.

              • +

            • The library section must include conarc.lib.

              • +

            The following is an example of an .mmp file +that builds a converter DLL called EXAMPLECONV.dll:

            // ExampleConv.MMP +target exampleconv.dll +targettype plugin +UID 0x10009d8d 0xE800009B +VENDORID 0x70000001 +CAPABILITY All -Tcb +sourcepath . +start resource E800009B.rss +target exampleconv.rsc +end +start resource E80000AC.rss +targetpath /resource/convert +end +userinclude . +systeminclude . /epoc32/include +systeminclude /epoc32/include/ecom +source ExampleConv.CPP +library euser.lib +library conarc.lib estor.lib +                         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-231840A2-255B-5200-8AD1-1D7667FCB448.dita --- a/Symbian3/SDK/Source/GUID-231840A2-255B-5200-8AD1-1D7667FCB448.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-231840A2-255B-5200-8AD1-1D7667FCB448.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ is built.

            The class defines a schema for the record. A schema is a pattern for the record that all records of this type follow. The class contains a set of fields and links to other records.

            - +

            For example, Symbian platform defines the class CCDIAPRecord. The class represents an Internet Access Point (IAP) record. A set of IAP records form an IAP table. Symbian platform assigns the unique numeric Id KCDTIdIAPRecord to a record of this type.

            The @@ -71,7 +71,7 @@ to initialise a record in memory. Tools and Applications can also get use the LoadL() and FindL() functions to get the the table schema from the Comms Database.

            - +

            You use the same methods to create, store and access user defined records that Symbian platform defined records use. Symbian platform backs up user defined data and secures user defined data with Platform Security. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-231E58F2-7935-462A-B048-51729D8245D4_d0e12307_href.png Binary file Symbian3/SDK/Source/GUID-231E58F2-7935-462A-B048-51729D8245D4_d0e12307_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-231E58F2-7935-462A-B048-51729D8245D4_d0e12411_href.png Binary file Symbian3/SDK/Source/GUID-231E58F2-7935-462A-B048-51729D8245D4_d0e12411_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-236C0D1D-AC4C-5C08-9089-1AC59881CD39_d0e169182_href.jpg Binary file Symbian3/SDK/Source/GUID-236C0D1D-AC4C-5C08-9089-1AC59881CD39_d0e169182_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-236C0D1D-AC4C-5C08-9089-1AC59881CD39_d0e174196_href.jpg Binary file Symbian3/SDK/Source/GUID-236C0D1D-AC4C-5C08-9089-1AC59881CD39_d0e174196_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-237E0861-EC1B-41DA-BDB0-1DEB50620CC8.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-237E0861-EC1B-41DA-BDB0-1DEB50620CC8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,34 @@ + + + + + +Converting +from UTC to local time in a non-system time zone + +The following code fragment converts a randomly chosen UTC time +to local time for London: +

            _LIT8( KEuropeLondon,"Europe/London" ); +// Create a pointer to the time zone id. +// This is the time zone for the local time to which you wish to convert. +CTzId* myZoneId = CTzId::NewL( KEuropeLondon ); +CleanupStack::PushL( myZoneId );// Create a client interface object to the time zone server +RTz myTZoneServer; +// Connect to the time zone server, leaves if fails to connect +User::LeaveIfError( myTZoneServer.Connect() ); +CleanupClosePushL( myTZoneServer );// Create a converter object. +CTzConverter* myConverter = CTzConverter::NewL( myTZoneServer ); +CleanupStack::PushL( myConverter );_LIT8( KMyTime,"20050328:185600.00" ); // UTC time to convert (28 March 2005 18:56 hrs). +TTime myTime( KMyTime ); // Create the time as a TTime object// Convert UTC to local time in Europe/London time zone. +myConverter->ConvertToLocalTime( myTime, *myZoneId ); +// myTime is updated to hold the local time value.// Clean up +CleanupStack::PopAndDestroy(3);// causes myTZoneServer.Close() to be called

            + + +             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2393237A-E60F-5556-8657-B0AA6470225C.dita --- a/Symbian3/SDK/Source/GUID-2393237A-E60F-5556-8657-B0AA6470225C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,21 +0,0 @@ - - - - - -option -

            option keyword compiler-options

            -

            Use the option statement to specify additional compiler -options.

            -

            keyword specifies the compiler. Possible values are ARMCC for -ARM RVCT, CW for CodeWarrior, GCC for GCC, GCCE for -GCCE, and MSVC for MS Visual C++.

            -

            The following statement turns warnings off in CodeWarrior -builds.

            OPTION CW -w off             -             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-239B8B32-5816-575E-97B1-FF7B68BC7575_d0e114068_href.png Binary file Symbian3/SDK/Source/GUID-239B8B32-5816-575E-97B1-FF7B68BC7575_d0e114068_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-239B8B32-5816-575E-97B1-FF7B68BC7575_d0e114300_href.png Binary file Symbian3/SDK/Source/GUID-239B8B32-5816-575E-97B1-FF7B68BC7575_d0e114300_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-23A60DE7-B72D-41BD-9F1E-882D31A7E3C7.dita --- a/Symbian3/SDK/Source/GUID-23A60DE7-B72D-41BD-9F1E-882D31A7E3C7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-23A60DE7-B72D-41BD-9F1E-882D31A7E3C7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,96 +1,92 @@ - - - - - -Required -resource file statements -

            As noted in Resource -file structure, -if the NAME is given, it must be the first statement -in the resource file.

            -

            After the NAME statement, resource files must begin -with the following three RESOURCE statements:

            -
              -

            • RESOURCE RSS_SIGNATURE

              • -

            • RESOURCE TBUF

              • -

            • RESOURCE TBUF RESOURCE EIK_APP_INFO

              -
              • -
            -
            RESOURCE RSS_SIGNATURE -

            The RSS_SIGNATURE resource is used to declare the -version number of the resource file. Leave this blank. The syntax is as follows:

            -RESOURCE RSS_SIGNATURE - { - signature = value - } -

            where signature is a LONG value.

            -

            By default the signature is set to 0.

            -

            For an example, see helloworldbasic.rss.

            -

            For more information on RSS_STRUCTURE, see BA_RSS_SIGNATURE.

            -
            -
            RESOURCE TBUF -

            The TBUF resource may be used to declare a file -name for use by the document class if it is stated that the StoreL and RestoreL of -the document class is called. Otherwise, it may be left blank. The syntax -is as follows:

            -RESOURCE TBUF - { - buf="NAME"; - } -

            where buf is one non-zero terminating string.

            -

            For an example, see helloworldbasic.rss.

            - -

            The TBUF structure is declared in badef.rh, which -is included in the uikon.rh file. For more information -on the TBUF resource, see TBUF.

            -             -
            -
            RESOURCE EIK_APP_INFO -

            The EIK_APP_INFO resource defines the objects -used in the application GUI.

            - -

            Not all possible objects need to be declared.

            -             -

            The syntax is as follows:

            -RESOURCE EIK_APP_INFO - { - menubar = value2; - cba = value5; - status_pane = value6; - } -

            where:

            -
              -

            • menubar defines the menubar resource.

              -
              • -

            • cba defines the softkeys resource.

              -
              • -

            • status_pane defines the status pane -resource.

              • -
            -

            All values refer to resources defined either in the resource file or -in a generated resource header file (.rsg) included in -the resource file.

            - -

            If an element is not defined, then it is not used. For example:

            -             -RESOURCE EIK_APP_INFO - { - menubar=r_name4; - cba=R_AVKON_SOFTKEYS_OPTIONS_EXIT; - } -

            sets the application to use the menu bar defined by the RESOURCE statement -with the namer_name4, and creates the softkey options Options and Exit in -the control button area.

            -

            For an example, see helloworldbasic.rss.

            -

            For more information on the control button area softkeys provided by -the Symbian platform, see Precompiled -resource values available from the Symbian platform.

            -
            + + + + + +Required resource file statements +

            As noted in Resource file structure, if the NAME is given, it must be the +first statement in the resource file.

            +

            After the NAME statement, resource files +must begin with the following three RESOURCE statements:

            +
              +

            • RESOURCE RSS_SIGNATURE

              +
              • +

            • RESOURCE TBUF

              • +

            • RESOURCE TBUF RESOURCE EIK_APP_INFO

              • +
            +
            RESOURCE +RSS_SIGNATURE +

            The RSS_SIGNATURE resource is used to declare +the version number of the resource file. Leave this blank. The syntax +is as follows:

            +RESOURCE RSS_SIGNATURE + { + signature = value + } +

            where signature is a LONG value.

            +

            By default the signature is set to 0.

            +

            For an example, see helloworldbasic.rss.

            +

            For more information on RSS_STRUCTURE, see BA_RSS_SIGNATURE.

            +
            +
            RESOURCE +TBUF +

            The TBUF resource may be used to declare +a file name for use by the document class if it is stated that the StoreL and RestoreL of the document +class is called. Otherwise, it may be left blank. The syntax is as +follows:

            +RESOURCE TBUF + { + buf="NAME"; + } +

            where buf is one non-zero terminating string.

            +

            For an example, see helloworldbasic.rss.

            + +

            The TBUF structure is declared in badef.rh, which is included in the uikon.rh file. For +more information on the TBUF resource, see TBUF.

            +             +
            +
            RESOURCE +EIK_APP_INFO +

            The EIK_APP_INFO resource defines the +objects used in the application GUI.

            + +

            Not all possible objects need to be declared.

            +             +

            The syntax is as follows:

            +RESOURCE EIK_APP_INFO + { + menubar = value2; + cba = value5; + status_pane = value6; + } +

            where:

            +
              +

            • menubar defines the menubar +resource.

              • +

            • cba defines the softkeys resource.

              +
              • +

            • status_pane defines the status +pane resource.

              • +
            +

            All values refer to resources defined either in the resource +file or in a generated resource header file (.rsg) included in the resource file.

            + +

            If an element is not defined, then it is not used. For example:

            +             +RESOURCE EIK_APP_INFO + { + menubar=r_name4; + cba=R_AVKON_SOFTKEYS_OPTIONS_EXIT; + } +

            sets the application to use the menu bar defined by the RESOURCE statement with the namer_name4, and creates the softkey options Options and Exit in the control button area.

            +

            For an example, see helloworldbasic.rss.

            +

            For more information on the control button area softkeys provided +by the Symbian platform, see Precompiled resource values available from the Symbian platform.

            +
             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24039DCE-B5C4-46CB-9E02-AB421C64FB87.dita --- a/Symbian3/SDK/Source/GUID-24039DCE-B5C4-46CB-9E02-AB421C64FB87.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24039DCE-B5C4-46CB-9E02-AB421C64FB87.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ words, it uses the physical coordinates of the display.

            The following figure illustrates this relationship.

            Relative positions of three controls where the top-level parent owns -the window +the window

            Consider three controls, A, B, and C (shown in the figure above):

              @@ -42,7 +42,7 @@ of its own, it is a child window of A's window (as shown in the following figure). Then if C is a child of B and sets its window by calling CCoeControl::SetContainerWindowL(B), the position of C (p') is relative to B's window.

              -Relative positions of three controls where a child owns a window +Relative positions of three controls where a child owns a window

              As the example illustrates, a control position depends on the window in which it is drawn. Therefore, you need to know the drawing window for each control. It is an important issue when designing a UI layout. There are some diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-244631CF-03F9-4C48-9802-682A76E9ECCC.dita --- a/Symbian3/SDK/Source/GUID-244631CF-03F9-4C48-9802-682A76E9ECCC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-244631CF-03F9-4C48-9802-682A76E9ECCC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -48,10 +48,10 @@ item-specific submenu item (Delete) is hidden in the options menu and displayed in the stylus pop-up menu by setting the EEikMenuItemSpecific flag.

              Before setting the EEikMenuItemSpecific flag - + After setting the EEikMenuItemSpecific flag - +

              Add the EEikMenuItemSpecificListQuery flag to submenu resource definitions. As a result, the submenu items are displayed @@ -79,7 +79,7 @@ is displayed in the list query dialog box under option by setting the EEikMenuItemSpecificListQuery flag.

              After setting the EEikMenuItemSpecificListQuery flag - +               diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24508C2D-31B9-5CC2-9EB8-F00AD39D8AA0.dita --- a/Symbian3/SDK/Source/GUID-24508C2D-31B9-5CC2-9EB8-F00AD39D8AA0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24508C2D-31B9-5CC2-9EB8-F00AD39D8AA0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ allows either a single line message or a simple dialog box to be displayed on the screen. It is typically used for debug messages.

              The simple screen output service interface is provided by RNotifier, -which also provides access to the UI-specific plug-in notifiers, via the Extended Notifier Framework.

          +which also provides access to the UI-specific plug-in notifiers, via the Extended Notifier Framework.

          See also

          Environment Change Notifier Overview

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-245FC4CA-EB57-5745-AD2E-79E33D43D912_d0e220109_href.png Binary file Symbian3/SDK/Source/GUID-245FC4CA-EB57-5745-AD2E-79E33D43D912_d0e220109_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-245FC4CA-EB57-5745-AD2E-79E33D43D912_d0e225103_href.png Binary file Symbian3/SDK/Source/GUID-245FC4CA-EB57-5745-AD2E-79E33D43D912_d0e225103_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2468821F-6C66-5761-AE56-CEC942A2EE95_d0e194954_href.png Binary file Symbian3/SDK/Source/GUID-2468821F-6C66-5761-AE56-CEC942A2EE95_d0e194954_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2468821F-6C66-5761-AE56-CEC942A2EE95_d0e199963_href.png Binary file Symbian3/SDK/Source/GUID-2468821F-6C66-5761-AE56-CEC942A2EE95_d0e199963_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2472E5E0-C33A-51B4-8210-89D7DEFA87C8_d0e215812_href.png Binary file Symbian3/SDK/Source/GUID-2472E5E0-C33A-51B4-8210-89D7DEFA87C8_d0e215812_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2472E5E0-C33A-51B4-8210-89D7DEFA87C8_d0e220810_href.png Binary file Symbian3/SDK/Source/GUID-2472E5E0-C33A-51B4-8210-89D7DEFA87C8_d0e220810_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24860917-0FE2-5C8F-B436-96928350996E.dita --- a/Symbian3/SDK/Source/GUID-24860917-0FE2-5C8F-B436-96928350996E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24860917-0FE2-5C8F-B436-96928350996E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ get notifications. The following illustration shows the architecture of the bearer mobility implementation in the Messaging Application module.

          Architecture of Bearer Mobility - +
          Settings

          The email client MTM CEmailAccounts interfaces are enhanced to configure the email account settings. These settings modify diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24B8686D-727A-47A8-B01D-1BA1FBC8F771_d0e129360_href.png Binary file Symbian3/SDK/Source/GUID-24B8686D-727A-47A8-B01D-1BA1FBC8F771_d0e129360_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24B8686D-727A-47A8-B01D-1BA1FBC8F771_d0e132980_href.png Binary file Symbian3/SDK/Source/GUID-24B8686D-727A-47A8-B01D-1BA1FBC8F771_d0e132980_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24D16BF8-7BF1-5FF2-BCA8-E5200A9E8431.dita --- a/Symbian3/SDK/Source/GUID-24D16BF8-7BF1-5FF2-BCA8-E5200A9E8431.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24D16BF8-7BF1-5FF2-BCA8-E5200A9E8431.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ }; Two elements in a linked list - +

          Although any kind of object can be an element of a linked list, most lists consist of elements which are all of the same type.

          @@ -39,7 +39,7 @@ An example of two elements, in two lists where they are consecutive elements in both lists - +

          Elements can also be objects constructed from a variety of classes, all ultimately derived from the same base class, where that base class includes @@ -64,7 +64,7 @@ Example of a linked list of different element types - +

          Note that the link object is at the same offset in each element in this list.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24D51B0B-7EBE-49AE-84CF-098096BE0A1C.dita --- a/Symbian3/SDK/Source/GUID-24D51B0B-7EBE-49AE-84CF-098096BE0A1C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24D51B0B-7EBE-49AE-84CF-098096BE0A1C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,14 +20,14 @@ Confirmation note - + Information note - + @@ -37,7 +37,7 @@ Error note - + @@ -48,13 +48,13 @@ Wait note - + Progress note - + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24EFD1EC-333C-537C-89FF-A77627D962C3.dita --- a/Symbian3/SDK/Source/GUID-24EFD1EC-333C-537C-89FF-A77627D962C3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-24EFD1EC-333C-537C-89FF-A77627D962C3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,48 +1,48 @@ - - - - - -LocaleUpdateExample: -Using the Locale FunctionalityThis example demonstrates how to get different locale settings -from the locale DLLs in the system. -
          Download

          Click -on the following link to download the example: localeupdate.zip.

          Click: browse to view the example code.

          -
          Description

          An -object of the TExtendedLocale class is used to load a number -of locale DLLs from the system. For each locale DLL, it gets the following -locale settings:

            -

          • Calendar settings

            • -

          • Country code

            • -

          • Collation method

            • -

          • Currency format

            • -

          • Date and time format

            • -

          • Numeric value settings

            • -

          • Time zone information

            • -

          • Units of measurement.

            • -

          See also

          Locale Settings

          -
          Class summary
            -

          • TExtendedLocale - Extended locale class.

            • -

          • TLocale - Sets and gets the system's locale settings.

            • -

          • TDay - Defines the days of the week.

            • -

          • TCollationMethod - Defines a collation method.

            • -

          • TDateFormat - Defines the date formats.

            • -

          • TTimeFormat - Defines the time formats as either -12 hour or 24 hour.

            • -

          • TDaylightSavingZone - Defines the daylight -saving zones.

            • -

          • TUnitsFormat - Enumerates the units of measurement -as either Imperial or Metric.

            • -
          -
          Build

          The Symbian build process describes -how to build this example.

          The localeupdate example -builds the localeupdate.exe executable file in the standard -location (\epoc32\release\winscw\ <build_variant>) -for Carbide.c++.

          + + + + + +LocaleUpdateExample: Using the Locale FunctionalityThis example demonstrates how to get different locale settings +from the locale DLLs in the system. +
          Download

          Click on the following link to download the example: localeupdate.zip.

          Click: browse to view the example code.

          +
          Description

          An object of the TExtendedLocale class is +used to load a number of locale DLLs from the system. For each locale +DLL, it gets the following locale settings:

            +

          • Calendar settings

            • +

          • Country code

            • +

          • Collation method

            • +

          • Currency format

            • +

          • Date and time +format

            • +

          • Numeric value +settings

            • +

          • Time zone information

            • +

          • Units of measurement.

            • +

          See also

          Locale +Settings

          +
          Class +summary
            +

          • TExtendedLocale - Extended locale class.

            • +

          • TLocale - Sets and gets the system's locale +settings.

            • +

          • TDay - Defines the days of the week.

            • +

          • TCollationMethod - Defines a collation method.

            • +

          • TDateFormat - Defines the date formats.

            • +

          • TTimeFormat - Defines the time formats as +either 12 hour or 24 hour.

            • +

          • TDaylightSavingZone - Defines the daylight +saving zones.

            • +

          • TUnitsFormat - Enumerates the units of measurement +as either Imperial or Metric.

            • +
          +
          Build

          The Symbian build process describes how to build this example.

          The localeupdate example builds +the localeupdate.exe executable file in the standard +location (\epoc32\release\winscw\ <build_variant>) for Carbide.c++.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24F464D8-36C1-592A-9BDB-673E771A5707_d0e266785_href.png Binary file Symbian3/SDK/Source/GUID-24F464D8-36C1-592A-9BDB-673E771A5707_d0e266785_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-24F464D8-36C1-592A-9BDB-673E771A5707_d0e271640_href.png Binary file Symbian3/SDK/Source/GUID-24F464D8-36C1-592A-9BDB-673E771A5707_d0e271640_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-25035286-5134-51F6-A3B6-C0DF0E802719.dita --- a/Symbian3/SDK/Source/GUID-25035286-5134-51F6-A3B6-C0DF0E802719.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-25035286-5134-51F6-A3B6-C0DF0E802719.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,5 +9,5 @@ --> -The Linear DDA

          Linear Digital Differential Analyzers (DDAs) are used by various functions to construct straight lines and to calculate bitmap stretching and compression.

          Line construction

          The linear DDA constructs a pixel line between the start point and end point, using the straight geometric line between these points.

          In the example below Line A has a start point (3,10) and end point (22,6). The x-delta is therefore 22-3+1=20. The y-delta is 10-6+1=5. 5 goes into 20 exactly four times, so each step of the pixel line has four pixels in it.

          The distribution of pixels is fairly straightforward if the x-delta is an exact multiple of the y-delta, or vice versa. In this case there are the same number of pixels in each pixel line step (as in the case of line A). When the x-delta is not an exact multiple of the y-delta, (or vice versa) the pixels in the pixel line cannot be distributed evenly so the pixel line steps each have differing numbers of pixels (as in the case of line B).

          Scaling bitmaps

          When a bitmap is to be displayed it often has to be stretched or compressed to fit the desired display area.

          The linear DDA constructs an imaginary pixel line between the start point and end point, using the straight geometric line between these points. This is then used to stretch or compress the original bitmap prior to display.

          The example below uses linear DDA to do a 400% horizontal scaling of a bitmapped "6" character. In most situations two linear DDAs would be needed, one for horizontal and one for vertical scaling.

          Drawing +The Linear DDA

          Linear Digital Differential Analyzers (DDAs) are used by various functions to construct straight lines and to calculate bitmap stretching and compression.

          Line construction

          The linear DDA constructs a pixel line between the start point and end point, using the straight geometric line between these points.

          In the example below Line A has a start point (3,10) and end point (22,6). The x-delta is therefore 22-3+1=20. The y-delta is 10-6+1=5. 5 goes into 20 exactly four times, so each step of the pixel line has four pixels in it.

          The distribution of pixels is fairly straightforward if the x-delta is an exact multiple of the y-delta, or vice versa. In this case there are the same number of pixels in each pixel line step (as in the case of line A). When the x-delta is not an exact multiple of the y-delta, (or vice versa) the pixels in the pixel line cannot be distributed evenly so the pixel line steps each have differing numbers of pixels (as in the case of line B).

          Scaling bitmaps

          When a bitmap is to be displayed it often has to be stretched or compressed to fit the desired display area.

          The linear DDA constructs an imaginary pixel line between the start point and end point, using the straight geometric line between these points. This is then used to stretch or compress the original bitmap prior to display.

          The example below uses linear DDA to do a 400% horizontal scaling of a bitmapped "6" character. In most situations two linear DDAs would be needed, one for horizontal and one for vertical scaling.

          Drawing to a Graphics Context Tutorials Drawing and Graphics Contexts           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-257212F5-A414-4F17-A786-DB3168218139_d0e67378_href.png Binary file Symbian3/SDK/Source/GUID-257212F5-A414-4F17-A786-DB3168218139_d0e67378_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-257212F5-A414-4F17-A786-DB3168218139_d0e67519_href.png Binary file Symbian3/SDK/Source/GUID-257212F5-A414-4F17-A786-DB3168218139_d0e67519_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-25CBA151-ED8E-5A88-A9FD-F20810371B4D_d0e214312_href.png Binary file Symbian3/SDK/Source/GUID-25CBA151-ED8E-5A88-A9FD-F20810371B4D_d0e214312_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-25CBA151-ED8E-5A88-A9FD-F20810371B4D_d0e219310_href.png Binary file Symbian3/SDK/Source/GUID-25CBA151-ED8E-5A88-A9FD-F20810371B4D_d0e219310_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-260C7ACD-0024-59DE-B1C6-0C852E44C457.dita --- a/Symbian3/SDK/Source/GUID-260C7ACD-0024-59DE-B1C6-0C852E44C457.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-260C7ACD-0024-59DE-B1C6-0C852E44C457.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,52 +1,54 @@ - - - - - -Dynamically -Loading Link Libraries OverviewDescription of Polymorphic DLLs. -
          Purpose

          Dynamically load libraries during program -execution.

          These interfaces are used by programs that need to load -libraries at run-time, that have a common interface, but different concrete -behaviour. Because of this relationship between interface and behaviour, such -libraries are called polymorphic DLLs.

          -
          Architectural relationships

          Many parts of the system -use polymorphic DLLs. Communications components, such as Sockets and Messaging, -use architectures in which particular communications protocols are provided -as polymorphic DLLs, and are loaded as needed. UI application programs are -also polymorphic DLLs that are loaded when the user starts the program.

          -
          Description

          The API has three key concepts: polymorphic -DLL, polymorphic DLL handle, and polymorphic DLL function pointer.

          -
          Polymorphic DLL

          A program that uses a type of polymorphic -DLLs defines their interface in terms of a single abstract class whose functions -are declared as pure virtual. Each type of polymorphic DLL is given a unique -identifier (UID).

          A particular concrete DLL:

            -

          • implements the interface -by defining and implementing a concrete class derived from the abstract class.

            • -

          • exports a function that -creates an object of the derived class type. All other functions in the DLL -are virtual and called through the base class interface.

            • -
          -
          Polymorphic DLL handle

          The polymorphic DLL handle -allows a program to load and close a particular polymorphic DLL. It also allows -the caller to obtain pointers to functions exported by the DLL. The system -can check that a polymorphic DLL is of the correct type by checking the type -UID value.

          The polymorphic DLL handle interface is provided by RLibrary.

          A -wildcard file system search for polymorphic DLLs can be done through TFindLibrary.

          -
          Polymorphic DLL function pointer

          An exported function -is called through a pointer to function obtained through a polymorphic DLL -handle.

          The polymorphic DLL function pointer type is provided by the TLibraryFunction typedef. -The caller casts the pointer to the real type of the exported function before -using it.

          -           - -UID Manipulation -Overview - + + + + + +Dynamically Loading Link Libraries OverviewDescription of Polymorphic DLLs. +
          Purpose

          Dynamically load libraries during program execution.

          These +interfaces are used by programs that need to load libraries at run-time, +that have a common interface, but different concrete behavior. Because +of this relationship between interface and behaviour, such libraries +are called polymorphic DLLs.

          +
          Architectural +relationships

          Many parts of the system use polymorphic +DLLs. Communications components, such as Sockets and Messaging, use +architectures in which particular communications protocols are provided +as polymorphic DLLs, and are loaded as needed. UI application programs +are also polymorphic DLLs that are loaded when the user starts the +program.

          +
          Description

          The API has three key concepts: polymorphic DLL, polymorphic +DLL handle, and polymorphic DLL function pointer.

          +
          Polymorphic +DLL

          A program that uses a type of polymorphic DLLs defines +their interface in terms of a single abstract class whose functions +are declared as pure virtual. Each type of polymorphic DLL is given +a unique identifier (UID).

          A particular concrete DLL:

            +

          • implements the +interface by defining and implementing a concrete class derived from +the abstract class.

            • +

          • exports a function +that creates an object of the derived class type. All other functions +in the DLL are virtual and called through the base class interface.

            • +
          +
          Polymorphic +DLL handle

          The polymorphic DLL handle allows a program to +load and close a particular polymorphic DLL. It also allows the caller +to obtain pointers to functions exported by the DLL. The system can +check that a polymorphic DLL is of the correct type by checking the +type UID value.

          The polymorphic DLL handle interface is provided +by RLibrary.

          A wildcard file system search +for polymorphic DLLs can be done through TFindLibrary.

          +
          Polymorphic +DLL function pointer

          An exported function is called through +a pointer to function obtained through a polymorphic DLL handle.

          The polymorphic DLL function pointer type is provided by the TLibraryFunction typedef. The caller casts the pointer +to the real type of the exported function before using it.

          +           +UID +Manipulation Overview           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2610E11C-26FA-538E-A3E1-34AADA35F20B.dita --- a/Symbian3/SDK/Source/GUID-2610E11C-26FA-538E-A3E1-34AADA35F20B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2610E11C-26FA-538E-A3E1-34AADA35F20B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -36,5 +36,5 @@ } ... CleanupStack::PopAndDestroy(1); -}

          Now that you have performed a basic database query you can start thinking about more advanced querying options. The following will show you how:

          • Reading to a buffer

          • Reading to memory

          • Reading to a data stream

          SQL Overview Basic SQL Example +}

          Now that you have performed a basic database query you can start thinking about more advanced querying options. The following will show you how:

          • Reading to a buffer

          • Reading to memory

          • Reading to a data stream

          SQL Overview Basic SQL Example Application           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-261ADCEC-C8C8-46E3-A7DC-804AC868C233.dita --- a/Symbian3/SDK/Source/GUID-261ADCEC-C8C8-46E3-A7DC-804AC868C233.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-261ADCEC-C8C8-46E3-A7DC-804AC868C233.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,23 +10,23 @@ Descriptors -

          Descriptors are self-describing strings that can be used to store binary -data and text. Each descriptor object holds the length of the string as well -as its type which identifies the underlying memory layout of the data it holds. -For more information on different descriptor classes, see Using -Descriptors.

          -

          There are modifiable and non-modifiable descriptors, the latter type -is identified by a "C" suffix in the class name. The length of a non-modifiable -descriptor is defined when compiling an application, and the length of a modifiable -descriptor can vary within the limits set by iMaxLength. -Nonmodifiable descriptors are more secure, as their length is checked during -compilation. The following figure shows the differences between these types.

          -Differences between modifiable, nonmodifiable, and pointer descriptors -

          When designing applications, avoid using fixed-length buffers as parameters -and use base classes (preferably constant base type TDesC) -instead. Descriptor objects provide a flexible interface for manipulating -the contained string, including size and length checks. Take advantage of -these when possible.

          -

          For more information and examples, see the Descriptors -Overview topic.

          +

          Descriptors are self-describing strings that can be used to +store binary data and text. Each descriptor object holds the length +of the string as well as its type which identifies the underlying +memory layout of the data it holds. For more information on different +descriptor classes, see Using Descriptors.

          +

          There are modifiable and non-modifiable descriptors, the latter +type is identified by a "C" suffix in the class name. The length of +a non-modifiable descriptor is defined when compiling an application, +and the length of a modifiable descriptor can vary within the limits +set by iMaxLength. Nonmodifiable descriptors are +more secure, as their length is checked during compilation. The following +figure shows the differences between these types.

          +Differences between modifiable, nonmodifiable, and pointer +descriptors +

          When designing applications, avoid using fixed-length buffers +as parameters and use base classes (preferably constant base type TDesC) instead. Descriptor objects provide +a flexible interface for manipulating the contained string, including +size and length checks. Take advantage of these when possible.

          +

          For more information and examples, see the Descriptors Overview topic.

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26399981-1E45-5578-851E-D234295F3B05_d0e76115_href.png Binary file Symbian3/SDK/Source/GUID-26399981-1E45-5578-851E-D234295F3B05_d0e76115_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26399981-1E45-5578-851E-D234295F3B05_d0e76153_href.png Binary file Symbian3/SDK/Source/GUID-26399981-1E45-5578-851E-D234295F3B05_d0e76153_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2645AE91-8087-5423-95A7-8BC6EFD271E7.dita --- a/Symbian3/SDK/Source/GUID-2645AE91-8087-5423-95A7-8BC6EFD271E7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2645AE91-8087-5423-95A7-8BC6EFD271E7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Message Store on a Phone

          This section explains how the UI layer displays a Message Store to a phone user.

          A message centre application displays the structure of the Message Store to the user. Different UIs map the structure to different views.

          Note: The presentation of folders is done in the UI layer and not the Messaging API.

          Series 60

          The following figure shows the top level view of a message centre application on a Series 60 phone:

          Series 60 message centre -

          In the figure, you can see that the message centre has hidden the local service and shows the standard folders at the same level as the services. Also the SMTP, SMS and MMS services are marked as hidden entries in the Message Store, and so do not appear in the message application. The outbox does not retain copies of sent messages, but are saved in the Sent folder.

          \ No newline at end of file +

          In the figure, you can see that the message centre has hidden the local service and shows the standard folders at the same level as the services. Also the SMTP, SMS and MMS services are marked as hidden entries in the Message Store, and so do not appear in the message application. The outbox does not retain copies of sent messages, but are saved in the Sent folder.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2676BA6B-4BEB-5E2A-AD18-D2199465B121.dita --- a/Symbian3/SDK/Source/GUID-2676BA6B-4BEB-5E2A-AD18-D2199465B121.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2676BA6B-4BEB-5E2A-AD18-D2199465B121.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ (SIS files). The collection also includes a set of tools, which enable you to extract information from SIS files, SWIcertstore and registry entries for analysis.

          -
          Components
            +
            Components

            • MaKeKeys is a stand-alone tool that enables you to create a private key-public key pair and generate certificate requests.

              • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26778399-0105-413F-A39D-535A3BF5EBE2_d0e58092_href.png Binary file Symbian3/SDK/Source/GUID-26778399-0105-413F-A39D-535A3BF5EBE2_d0e58092_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26778399-0105-413F-A39D-535A3BF5EBE2_d0e58235_href.png Binary file Symbian3/SDK/Source/GUID-26778399-0105-413F-A39D-535A3BF5EBE2_d0e58235_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-269D6756-98B5-5928-9A83-261C3F729BCE_d0e335760_href.png Binary file Symbian3/SDK/Source/GUID-269D6756-98B5-5928-9A83-261C3F729BCE_d0e335760_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-269D6756-98B5-5928-9A83-261C3F729BCE_d0e342226_href.png Binary file Symbian3/SDK/Source/GUID-269D6756-98B5-5928-9A83-261C3F729BCE_d0e342226_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26E2294F-871F-45D1-B71C-9F470703A9C8_d0e36237_href.png Binary file Symbian3/SDK/Source/GUID-26E2294F-871F-45D1-B71C-9F470703A9C8_d0e36237_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-26E2294F-871F-45D1-B71C-9F470703A9C8_d0e36404_href.png Binary file Symbian3/SDK/Source/GUID-26E2294F-871F-45D1-B71C-9F470703A9C8_d0e36404_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-271E14D1-7B9B-5048-B1F0-1E25B4EA4E16.dita --- a/Symbian3/SDK/Source/GUID-271E14D1-7B9B-5048-B1F0-1E25B4EA4E16.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-271E14D1-7B9B-5048-B1F0-1E25B4EA4E16.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,127 +1,111 @@ - - - - - -SqlExample: -Creating and Querying an SQL DatabaseThis example application demonstrates the use of the SQL API for -creating and querying a database. -
              Description

              Creating -the database

              You can create two types of databases; secure and -non-secure.

                -

              • Non-secure database: A -database that can be accessed and updated by any program since no security -policy is provided.

                • -

              • Secure database: A -database with static policy defined and therefore can be accessed by authorized -clients with specific capabilities.

                • -

              Creating a non-secure database

              The application first -creates an RSqlDatabase object and creates a non-secure -SQL database using the RSqlDatabase::Create() function. -The database is then closed. Finally the database is deleted using the RSqlDatabase::Delete() function.

              The -format for naming the non-secure database would be the following:

              X:<path><database-name>.db

              where, X is -the writable drive on the device or the emulator.

              If path is not specified, -it returns the KErrArgument error, and if the specified path -is not writable by SQL server, the application returns KErrPermission error. -In this example, the application will create the database in its own data -area, pass a handle to the database to enable the data manipulation by the -SQL server.

              You cannot create two databases with the same name -in a location

              Related APIs

                -

              • RSqlDatabase - A handle to a SQL database.

                • -

              • RSqlDatabase::Create()

                • -

              • RSqlDatabase::Delete()

                • -

              Creating a secure database

              To create a secure database, -you need to provide the following:

                -

              • UID of the application

                • -

              • security policy

                • -

              UID

              You need to use the UID of the example application -to name the database.

              The format for naming the database would be -the following:

              X:<UID><name>.db

              where,

                -

              • X is -the drive in which the database is created

                • -

              • UID is -the UID of the application that creates the database

                • -

              • name is -any valid database name. You should not specify the complete path of the database.

                • -

              To successfully create and use a secure database, you must have appropriate -capabilities such as READUSERDATA, WRITEUSERDATA. -The example application uses NETWORKCONTROL capablity along -with above specified capabilities.

              If the given UID does not -match with that of client application (in this case, the SQL example application) -the attempts to create the database fails.

              Security policy

              To -create a secure database, you need to initially set up a container that has -a set of security policies (TSecurityPolicy), and pass -it to the RSqlDatabase::Create() function. The TSecurityPolicy object -defines what capabilities the calling application must have in order to perform -a specific database operation. To cross check if the database security policy -matches with the policy used when the database was created, the RSqlDatabase::GetSecurityPolicy() function -is called.

              Related APIs

                -

              • RSqlDatabase::Create()

                • -

              • RSqlDatabase::GetSecurityPolicy()

                • -

              • TSecurityPolicy - Class representing a generic security -policy

                • -

              Copying one database to another

              The example copies -one database to another using the RSqlDatabase::Copy() function. -If the database was created using a specific UID, then only the application -with same UID, can perform the copy operation.

              In this example, -copy function is essentially a file copy as the client does a copy -within its data cage. The copy operation should ideally fail if the destination -database already exists. An application with appropriate permissions can use -the file system to copy the database.

              Related APIs

                -

              • RSqlDatabase::Copy()

                • -

              Attaching the database

              The example application then -demonstrates attaching two databases. In this example, a non-secure database -is attached to a secure database. The attached database is later read from -and written to, and the secure database is also written to before the two -databases are deleted using the RSqlDatabase::Delete() function.

              Related -APIs

                -

              • RSqlDatabase::Delete()

                • -

              Querying the database

              The example then demonstrates -how to prepare and execute a query.

              Simple query

              A -simple query statement is prepared and executed using the CSqlExample::DataTypesQueryL() function.

              Query -with a large parameter and writing using streaming

              A query with -a large parameter is prepared, executed and the results are written to RSqlParamWriteStream stream. -A table containing fields of data types; integer, 64-bit integer, float, text -and binary is created. It inserts two records into the table and implements -the TSqlScalarFullSelectQuery function for 64 bit integer -(F2) and text (F4) fields and checks the returned value. The query for the -data type which the column does not hold is executed, only to show that this -is possible. For example, if a column holding the integer value 1000 is queried -as real, it would return 1000.00.

              Related APIs

                -

              • RSqlParamWriteStream - The write stream interface.

                • -

              • TSqlScalarFullSelectQuery - TSqlScalarFullSelectQuery -interface is used for executing SELECT sql queries, which -return a single row consisting of a single column value.

                • -

              Query returning data being read using streaming

              The -example lastly demonstrates how to prepare and execute a query which returns -the data, and read that data from the data stream (RSqlColumnReadStream). -The read stream interface class is used for reading a large amount of binary -or text data from the column.

              Related APIs

                -

              • RSqlColumnReadStream - The read stream interface.

                • -
              -
              Download

              Click -on the following link to download the example: SqlExample.zip

              Click: browse to view the example code.

              -
              Class summary
                -

              • RSqlDatabase

                • -

              • RSqlStatement

                • -

              • RSqlColumnReadStream

                • -

              • RSqlParamWriteStream

                • -

              • RSqlSecurityPolicy

                • -

              • TSqlScalarFullSelectQuery

                • -
              -
              Build

              The Symbian build -process describes how to build an application.

              The Sql example -builds an executable called sqlexample.exe in the standard -location (\epoc32\release\winscw\ <build_variant> for -CodeWarrior). After launching the executable depending on the emulator, you -may need to task away from the app launcher or shell screen to view the console.

              -               -SQL Tutorials - + + + + + +SqlExample: Creating and Querying an SQL DatabaseThis example application demonstrates the use of the SQL +API for creating and querying a database. +
              Description

              Creating the database

              You can create two types +of databases; secure and non-secure.

                +

              • Non-secure +database: A database that can be accessed and updated by any program +since no security policy is provided.

                • +

              • Secure database: A database with static policy defined and therefore can be accessed +by authorized clients with specific capabilities.

                • +

              Creating a non-secure database

              The application +first creates an RSqlDatabase object and creates +a non-secure SQL database using the RSqlDatabase::Create() function. The database is then closed. Finally the database is deleted +using the RSqlDatabase::Delete() function.

              The format for naming the non-secure database would be the following:

              X:<path><database-name>.db

              where, X is the writable drive on the device +or the emulator.

              If path is not specified, it returns the KErrArgument error, and if the specified path is not writable +by SQL server, the application returns KErrPermission error. In this example, the application will create the database +in its own data area, pass a handle to the database to enable the +data manipulation by the SQL server.

              You cannot create +two databases with the same name in a location

              Related +APIs

                +

              • RSqlDatabase - A handle to a SQL database.

                • +

              • RSqlDatabase::Create()

                • +

              • RSqlDatabase::Delete()

                • +

              Creating a secure database

              To create a secure +database, you need to provide the following:

                +

              • UID of the application

                • +

              • security policy

                • +

              UID

              You need to use the UID of the example +application to name the database.

              The format for naming the +database would be the following:

              X:<UID><name>.db

              where,

                +

              • X is the drive in which the database is created

                • +

              • UID is the UID of the application that creates the database

                • +

              • name is any valid database name. You should not specify the complete +path of the database.

                • +

              To successfully create and use a secure database, you must +have appropriate capabilities such as READUSERDATA, WRITEUSERDATA. The example application uses NETWORKCONTROL capablity along with above specified capabilities.

              If the given UID does not match with that of client application +(in this case, the SQL example application) the attempts to create +the database fails.

              Security policy

              To create a secure database, you need to initially set up a container +that has a set of security policies (TSecurityPolicy), and pass it to the RSqlDatabase::Create() function. +The TSecurityPolicy object defines what capabilities +the calling application must have in order to perform a specific database +operation. To cross check if the database security policy matches +with the policy used when the database was created, the RSqlDatabase::GetSecurityPolicy() function is called.

              Related APIs

                +

              • RSqlDatabase::Create()

                • +

              • RSqlDatabase::GetSecurityPolicy()

                • +

              • TSecurityPolicy - Class representing a generic +security policy

                • +

              Copying one database to another

              The example +copies one database to another using the RSqlDatabase::Copy() function. If the database was created using a specific UID, then +only the application with same UID, can perform the copy operation.

              In this example, copy function is essentially a file +copy as the client does a copy within its data cage. The copy +operation should ideally fail if the destination database already +exists. An application with appropriate permissions can use the file +system to copy the database.

              Related APIs

                +

              • RSqlDatabase::Copy()

                • +

              Attaching the database

              The example application +then demonstrates attaching two databases. In this example, a non-secure +database is attached to a secure database. The attached database is +later read from and written to, and the secure database is also written +to before the two databases are deleted using the RSqlDatabase::Delete() function.

              Related APIs

                +

              • RSqlDatabase::Delete()

                • +

              Querying the database

              The example then demonstrates +how to prepare and execute a query.

              Simple query

              A simple query statement is prepared and executed using the CSqlExample::DataTypesQueryL() function.

              Query +with a large parameter and writing using streaming

              A query +with a large parameter is prepared, executed and the results are written +to RSqlParamWriteStream stream. A table containing +fields of data types; integer, 64-bit integer, float, text and binary +is created. It inserts two records into the table and implements the TSqlScalarFullSelectQuery function for 64 bit integer (F2) +and text (F4) fields and checks the returned value. The query for +the data type which the column does not hold is executed, only to +show that this is possible. For example, if a column holding the integer +value 1000 is queried as real, it would return 1000.00.

              Related APIs

                +

              • RSqlParamWriteStream - The write stream +interface.

                • +

              • TSqlScalarFullSelectQuery - TSqlScalarFullSelectQuery +interface is used for executing SELECT sql queries, +which return a single row consisting of a single column value.

                • +

              Query returning data being read using streaming

              The example lastly demonstrates how to prepare and execute a +query which returns the data, and read that data from the data stream +(RSqlColumnReadStream). The read stream interface +class is used for reading a large amount of binary or text data from +the column.

              Related APIs

                +

              • RSqlColumnReadStream - The read stream interface.

                • +
              +
              Download

              Click on the following link to download the example: SqlExample.zip

              Click: browse to view the example code.

              +
              Class +summary
                +

              • RSqlDatabase

                • +

              • RSqlStatement

                • +

              • RSqlColumnReadStream

                • +

              • RSqlParamWriteStream

                • +

              • RSqlSecurityPolicy

                • +

              • TSqlScalarFullSelectQuery

                • +
              +
              Build

              The Symbian build process describes how to build an application.

              The Sql example builds an executable called sqlexample.exe in the standard location (\epoc32\release\winscw\ <build_variant> for CodeWarrior). After launching the +executable depending on the emulator, you may need to task away from +the app launcher or shell screen to view the console.

              +               +SQL +Tutorials               \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27340D18-A31D-512E-920A-B06C784A978A.dita --- a/Symbian3/SDK/Source/GUID-27340D18-A31D-512E-920A-B06C784A978A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-27340D18-A31D-512E-920A-B06C784A978A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ idea:

              String pool representation - +

              A string pool is a mechanism for storing strings in a particular way that makes the comparison of strings a very fast operation. It is particularly @@ -81,7 +81,7 @@ to a call to:

              void RStringTable::OpenL( const TStringTable& aTable );

              The following diagram illustrates a general picture. Note that the strings in any given string table are deemed to be either case sensitive or case insensitive, and this governs how comparisons are made.

              - +

              As the name implies, a static string table is declared as a const TStringTable data member of a class with a user-defined name. The class name is defined in a header file while the table itself is diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2735BDAF-295F-5F1E-8925-8F4212D95CD1_d0e264145_href.png Binary file Symbian3/SDK/Source/GUID-2735BDAF-295F-5F1E-8925-8F4212D95CD1_d0e264145_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2735BDAF-295F-5F1E-8925-8F4212D95CD1_d0e269008_href.png Binary file Symbian3/SDK/Source/GUID-2735BDAF-295F-5F1E-8925-8F4212D95CD1_d0e269008_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2751DBB8-D882-5803-9881-1C1F7B4FE413.dita --- a/Symbian3/SDK/Source/GUID-2751DBB8-D882-5803-9881-1C1F7B4FE413.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2751DBB8-D882-5803-9881-1C1F7B4FE413.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,42 +1,38 @@ - - - - - -IRPrinting: -Infrared Printing -

              Download

              Click on the following link to download -the example: ServerClientSide.zip

              Download some additional files -required by the example: CommonFiles

              Click: browse to view the example code.

              View the additional -files: browse.
              -
              Description

              IRPrinting illustrates the use of the Serial Communications Server for -infra-red communications, such as to an IrDA-capable printer. See the IrDA -Serial Overview for more information.

              The example:

                -

              • Creates a connection -to the Comms server

                • -

              • Loads the Comms server -module that supports infra-red (“IrCOMM”)

                • -

              • Opens a port

                • -

              • Writes a short message -to the port

                • -

              • Closes the port

                • -

              • Closes the Comms server

                • -

              The write operation times out with an error after four seconds if -it is not successful, as will occur if no receiver is present.

              -
              Class Summary

              RComm: serial port

              RCommServ: -Comms server

              -
              Build

              The source code includes the two project -files needed for building: bld.inf and the .mmp file.

              The Symbian platform build process describes -how to build this application, which results in an executable called \epoc32\release\<target>\<urel -or udeb>\IRPRINTING.EXE.

              -
              Usage

              Run the executable IRPRINTING.EXE.

              Executables -for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

              + + + + + +IRPrinting: Infrared Printing +
              Download

              Click on the following link to download the example: ServerClientSide.zip

              Download some additional +files required by the example: CommonFiles

              Click: browse to view the example code.

              View the +additional files: browse.
              +
              Description

              IRPrinting illustrates the use of the Serial Communications +Server for infra-red communications, such as to an IrDA-capable +printer. See the IrDA Serial Overview for more information.

              The example:

                +

              • Creates a connection +to the Comms server

                • +

              • Loads the Comms +server module that supports infra-red (“IrCOMM”)

                • +

              • Opens a port

                • +

              • Writes a short +message to the port

                • +

              • Closes the port

                • +

              • Closes the Comms +server

                • +

              The write operation times out with an error after four seconds +if it is not successful, as will occur if no receiver is present.

              +
              Class +Summary

              RComm: serial port

              RCommServ: Comms server

              +
              Build

              The source code includes the two project files needed for building: bld.inf and the .mmp file.

              The Symbian platform build process describes how to build this application, +which results in an executable called \epoc32\release\<target>\<urel +or udeb>\IRPRINTING.EXE.

              +
              Usage

              Run the executable IRPRINTING.EXE.

              Executables for the emulator targets wins and winscw can be run on your PC. Executables for ARM targets +must be copied to your target platform before being run.

              \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27529BB0-8034-56B0-82FA-3E4CFDEBC99A_d0e299272_href.png Binary file Symbian3/SDK/Source/GUID-27529BB0-8034-56B0-82FA-3E4CFDEBC99A_d0e299272_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27529BB0-8034-56B0-82FA-3E4CFDEBC99A_d0e305744_href.png Binary file Symbian3/SDK/Source/GUID-27529BB0-8034-56B0-82FA-3E4CFDEBC99A_d0e305744_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2762FDF6-F76D-5268-AE2D-4ABA807CFFEE.dita --- a/Symbian3/SDK/Source/GUID-2762FDF6-F76D-5268-AE2D-4ABA807CFFEE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2762FDF6-F76D-5268-AE2D-4ABA807CFFEE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -47,7 +47,7 @@ use the resizable buffer descriptor.

              - +

              Example of a Heap descriptor

                             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27CB7E85-8E6F-456B-8B90-55A605A0085E.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-27CB7E85-8E6F-456B-8B90-55A605A0085E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,146 @@ + + + + + +Setting +universal time and offset +

              Internally, the kernel uses UTC (Coordinated Universal Time) and stores +an offset for the difference between UTC and local time which is made up of +both the time zone and any daylight saving time added. This removes the responsibility +for handling time zones and daylight saving from the kernel to a user side +"timezone" server. A positive offset indicates a time ahead of UTC: a negative +offset indicates a time behind UTC.

              +

              The API below is used to set and get the UTC offset values.

              +
                +

              • User::SetUTCTime()

                • +

              • User::SetUTCOffset()

                • +

              • User::SetUTCTimeAndOffset()

                • +

              • User::UTCOffset()

                • +
              +

              Setting the UTC time and offset requires the WriteDeviceData security +capability.

               +
              Customizing +the default time zone setting

              The local time zone is calculated +using an offset from UTC. User::SetUTCOffset() is used +to set the offset to the required value. This function is called by three +different components at boot up:

                +

              • EStart - +sets the offset at the start of the boot process and then provides the correct +time for parts of the system that are initialized before the TimeZone and +Locale services are running.

                • +

              • InitialiseLocale - +sets and gets the locale information stored within the repository. This is +necessary if the TimeZoneServer is not included.

                • +

              • TimeZoneServer - +is an optional service that device manufactures can choose to include. It +is recommended that the offset is set both here and within InitialiseLocale. +

                • +
              +
              EStart

              The +call in EStart is required for backwards compatibility with systems that do +not use the TimeZoneServer. The call in EStart also allows many parts of the +system to see the correct time before the timezone/locale services are up +and running. If the timezone offset is not set during startup then many components +may, for that period, see the wrong time.

              The data format for the +persisted locale data makes no allowance for daylight savings that are not +equal to one hour, but in new code the daylight savings flag is never used +(specifically because of this issue) and the offset is adjusted by the correct +amount instead.

              To alter the default time zone operation within EStart, +provide your own implementation of the EStart virtual function TFSStartup::LoadLocale(). +See EStart: customizing +code.

              The offset set through EStart is retrieved through User::UTCOffset(). +

              +
              InitialiseLocale

              InitialiseLocale +initializes and persists changes to the system locale settings. The system +locale data is persisted using the central repository. The executable initialiseLocale.exe loads +the system locale data at device boot and ensures that changes to the system +locale data are persisted.

              Once initialiseLocale.exe has +been loaded (as part of the system boot sequence) the contents of the system +locale data are initialized and any subsequent changes to the system locale +settings are persisted without any intervention from the application or component +making the changes.

              Changing System Locale Settings

              Create +an empty TExtendedLocale object and use LoadSystemSettings() to +get the settings from the repository, make changes and save them with SaveSystemSettings(). +This function generates a notification for system locale changes so changes +to the locale information may not be immediate.

              For example, an application +that wishes to change the system time and date settings (without changing +any other locale settings) goes through the following steps:

                +

              1. Create an empty instance +of TExtendedLocale.

                TExtendedLocale myExtendedLocale; +
                2. +

              2. Initialize it to the +current system settings.

                myExtendedLocale.LoadSystemSettings(); +
                3. +

              3. Change the time and +date settings locally.

                myExtendedLocale.LoadLocaleAspect( ELocaleTimeDateSettings, KLocaleDllTimeDateSettings ); +
                4. +

              4. Write the new settings +to the system locale data.

                myExtendedLocale.SaveSystemSettings();
                5. +

              The security capability WriteDeviceData is +required to save settings.

              +
              TimeZoneServer

              The +time zone server simplifies the synchronisation between handsets in different +time zones. For example, if one handset is in the UK and another in the US +a meeting can be scheduled at the same time (UTC) and the local time is calculated +for each by the time zone server.

              The Time Zone Server converts UTC +to local time based on different time zones and DST rules, and publishes any +change to subscribing clients, for example the Calendar application. See Publish and Subscribe.

              The +time zone server is an optional service that licensees can choose to include +otherwise another method can be used to supply the UTC offset, for example, +Network time update, see RMobilePhone::GetNITZInfo(). Because +the time zone server may not be included in the product it is necessary to +persist the UTC offset as part of the locale data (TLocale). +The time zone server persists the current time zone and updates the UTC offset +based on whether daylight savings applies or not.

              The following code +example should help to illustrate the interactions that may occur if User:SetUTCOffset() or User::SetUTCTimeAndOffset() are called while the time zone server is running.

              Preconditions +for this code are:

                +

              • The time zone server is not already running.

                • +

              • It is assumed that the current UTC offset is not 36000 seconds (10 +hours). For describing this example, we will take the UTC to be 18000 seconds +(5 hours).

                • +
              void MainL() + { + RTz tz; + TTimeIntervalSeconds offsetWhenTzRunningInitial; + TTimeIntervalSeconds offsetWhenTzRunningAfterSetting; + TTimeIntervalSeconds offsetWhenTzNotRunningInitial; + TTimeIntervalSeconds offsetWhenTzNotRunningAfterSetting; + + TInt err = tz.Connect(); + User::LeaveIfError( err ); + offsetWhenTzRunningInitial = User::UTCOffset(); + User::SetUTCOffset( 36000 ); + User::After( 1*1000*1000 ); + offsetWhenTzRunningAfterSetting = User::UTCOffset(); + tz.Close(); + + offsetWhenTzNotRunningInitial = User::UTCOffset(); + User::SetUTCOffset( 36000 ); + offsetWhenTzNotRunningAfterSetting = User::UTCOffset(); + }

              Given the preconditions listed, the values for the offsets +retrieved are:

                +

              1. offsetWhenTzRunningInitial 18000 +(seconds).

                2. +

              2. offsetWhenTzRunningAfterSetting 18000 +(seconds).

                3. +

              3. offsetWhenTzNotRunningInitial 18000 +(seconds).

                4. +

              4. offsetWhenTzNotRunningAfterSetting 36000 +(seconds).

                5. +

              The value of offsetWhenTzRunningAfterSetting is not +36000 as one might expect from just looking at the code. This is because the +time zone server observes the kernel setting of the UTC offset and when this +value is changed, it checks the current time zone and ensures that the offset +matches this value. The delay is placed in this example code to ensure that +the time zone server is given a chance to run and to change the value.

              If +a call to User::UTCOffset() were made before the call to User::After(), +then the value can be either 36000 or 18000 depending on the CPU load, presence +of other processes and their relative priorities.

              +               \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27EC3C5B-175C-5D27-874C-43D46AA44C08_d0e287704_href.png Binary file Symbian3/SDK/Source/GUID-27EC3C5B-175C-5D27-874C-43D46AA44C08_d0e287704_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27EC3C5B-175C-5D27-874C-43D46AA44C08_d0e292532_href.png Binary file Symbian3/SDK/Source/GUID-27EC3C5B-175C-5D27-874C-43D46AA44C08_d0e292532_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-27F345DA-7969-5B3B-B2BD-285CD168CF72.dita --- a/Symbian3/SDK/Source/GUID-27F345DA-7969-5B3B-B2BD-285CD168CF72.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-27F345DA-7969-5B3B-B2BD-285CD168CF72.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,40 +1,40 @@ - - - - - -Timers -And Timing Services OverviewProvides timers that asynchronously notify an application after -an interval or at a specific time. -
              Architectural relationships

              The User class -in the System Static Functions API provides simple functions to suspend a -thread for a given interval or until a specific time.

              -
              Description

              The API has three key concepts: simple -timer, periodic timer, and heartbeat timer.

              -
              Simple timer

              The simple timer produces an event -at a given system time or after a given interval. It is provided by RTimer. -This service is wrapped in an active object by CTimer.

              -
              Periodic timer

              A periodic timer -produces a sequence of events at a specified interval. The application is -called through a callback (TCallBack) when they occur. -It is provided by CPeriodic.

              -
              Heartbeat timer

              A heartbeat timer is similar to -a periodic timer. However, if the application is busy handling another event -when the timer event occurs, a periodic timer simple delays delivering the -event, while a heartbeat timer will inform the application that it has missed -the event.

              It is provided by CHeartbeat. Applications -are alerted to timer events through implementing an interface MBeating.

              -               - -Asynchronous -Services Overview - -System Static -Functions Overview + + + + + +Timers And Timing Services OverviewProvides timers that asynchronously notify an application +after an interval or at a specific time. +
              Architectural +relationships

              The User class in the +System Static Functions API provides simple functions to suspend a +thread for a given interval or until a specific time.

              +
              Description

              The API has three key concepts: simple timer, periodic timer, +and heartbeat timer.

              +
              Simple +timer

              The simple timer produces an event at a given system +time or after a given interval. It is provided by RTimer. This service is wrapped in an active object by CTimer.

              +
              Periodic +timer

              A periodic timer produces a sequence +of events at a specified interval. The application is called through +a callback (TCallBack) when they occur. It is provided +by CPeriodic.

              +
              Heartbeat +timer

              A heartbeat timer is similar to a periodic timer. +However, if the application is busy handling another event when the +timer event occurs, a periodic timer simple delays delivering the +event, while a heartbeat timer will inform the application that it +has missed the event.

              It is provided by CHeartbeat. Applications are alerted to timer events through implementing an +interface MBeating.

              +               + +Asynchronous Services Overview +System +Static Functions Overview               \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-28227926-2D5A-500C-B2BC-0EE6CC077DBE.dita --- a/Symbian3/SDK/Source/GUID-28227926-2D5A-500C-B2BC-0EE6CC077DBE.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -About application resources
              Overview

              Much of the information that defines the appearance, behaviour and functionality of a Symbian platform application is stored externally to the main body of the program, in a resource file. This is unlike some other programming environments, in which a single executable contains all the code and information used by the application. Resource files can have the advantages that information is loaded only when needed, which can reduce RAM requirements, they can be compressed, and they can be localised without needing to recompile the main program.

              Resource files are developed as text files written in a Symbian platform-specific resource language. These source files are then compiled into a binary file format that can be loaded and read by programs. The source files can be compiled on their own using the command-line resource builder tool (epocrc), or as part of the standard project building process either from the command-line or from within an IDE.

              Purposes of resource files

              Resource files are used for the following purposes:

              • to define the application user interface. The C++ application programming framework requires that some aspects of an application’s layout and behaviour, such as the menu bars and dialogs, are defined in a resource file

              • to define application properties that are used by the application launcher or system shell.

                Until v9.0, (.aif) files are used to define the application's icon and caption, and various properties, for instance whether the application is exposed to users or hidden, whether the application can be embedded, and the priority at which the application should be associated with MIME data types. Aif files are built from a type of resource file.

                From v9.0, aif files are replaced by application registration information. The caption and icon are defined either in a special resource file called a localisable icon/caption definition file, or, if more convenient, in the application's UI resource file. The application's properties and some other information is defined in another type of resource file called a registration file.

              • Literal strings and other constant data: for example, dialog text and error messages. The resource tool chain provides support for localisation of these.

              File types reference

              The resource compilation process uses a number of file types:

rss

resource source file

rls

defines localisable strings, for inclusion in the resource source file

h

header file, for inclusion in C++ file

rh

resource header, for inclusion in the resource source file

hrh

common C++ or resource header, for inclusion in either type of source file

rsg

resource header file output from the resource compiler

rsc

compiled resource file from the resource compiler

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2861F3D9-875E-5AB3-9600-B328F042CC38.dita --- a/Symbian3/SDK/Source/GUID-2861F3D9-875E-5AB3-9600-B328F042CC38.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2861F3D9-875E-5AB3-9600-B328F042CC38.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,57 +1,55 @@ - - - - - -MakeKeys -Overview -

The MakeKeys tool -is a PC-side command-line tool that enables Symbian application developers -to create a private key-public key pair and generate certificate requests.

-
Purpose

The MakeKeys tool can be used to create -a private key-public key (in form of a self-signed certificate) pair. The -private key can then be used by the SignSIS tool -to digitally sign an installation file. The self-signed certificate can be -used by the MakeKeys tool to create a certificate request file, which can -then be submitted to a Certification Authority (CA) for signing.

The -MakeKeys tool cannot generate Certification Authority (CA) certificates.
-
Key concepts and terms
- -
Key
-

A key is a constant value applied using a cryptographic algorithm to -encrypt text or to decrypt encrypted text.

Keys are classified as -symmetric and asymmetric based on the type of algorithm applied. If the same -key is used for both encryption and decryption, it is symmetric. If different -keys are used for encryption and decryption, they are asymmetric. Asymmetric -keys exist in the form of a private key-public key pair, where the public -key is used for encryption and the private key is used for decryption. For -more information, see Public -Key Cryptography.

- -
- -
Certification Authority
-

Certification Authority (CAs) is a trusted third party that provides -root certificates to users (End Entities). For details, see Certificates.

- -
- -
Digital signature
-

A digital signature is used to verify that a message (or data) actually -came from the sender (the one who signed the message) and that it has not -been tampered with. For details, see Digital -Signatures.

- -
- -MakeKeys -Tutorials -MakeKeys -Reference + + + + + +MakeKeys Overview +

The MakeKeys tool is a PC-side command-line tool that enables Symbian application +developers to create a private key-public key pair and generate certificate +requests.

+
Purpose

The MakeKeys tool can be used to +create a private key-public key (in form of a self-signed certificate) +pair. The private key can then be used by the SignSIS tool +to digitally sign an installation file. The self-signed certificate +can be used by the MakeKeys tool to create a certificate request file, +which can then be submitted to a Certification Authority (CA) for +signing.

The MakeKeys tool cannot generate Certification +Authority (CA) certificates.
+
Key concepts and terms
+ +
Key
+

A key is a constant value applied using a cryptographic algorithm +to encrypt text or to decrypt encrypted text.

Keys are classified +as symmetric and asymmetric based on the type of algorithm applied. +If the same key is used for both encryption and decryption, it is +symmetric. If different keys are used for encryption and decryption, +they are asymmetric. Asymmetric keys exist in the form of a private +key-public key pair, where the public key is used for encryption and +the private key is used for decryption. For more information, see Public Key Cryptography.

+ +
+ +
Certification Authority
+

Certification Authority (CAs) is a trusted third party that +provides root certificates to users (End Entities). For details, see Certificates.

+ +
+ +
Digital signature
+

A digital signature is used to verify that a message (or data) +actually came from the sender (the one who signed the message) and +that it has not been tampered with. For details, see Digital Signatures.

+ +
+ +MakeKeys +Tutorials +MakeKeys +Reference \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-28B9B737-AA79-5595-8DDE-7DD52402C0B9.dita --- a/Symbian3/SDK/Source/GUID-28B9B737-AA79-5595-8DDE-7DD52402C0B9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,190 +0,0 @@ - - - - - -Tools -and file types used in the build process -

This page briefly lists the main Symbian-specific tools and file types -used in building components. In addition to these tools, the build process -will use compilers and linkers supplied by various third party companies.

-

Tools supplied by Symbian are in epoc32\tools\ directory.

-
Tools - - - -

Tool

-

Description

- - -

bldmake

-

This tool processes a component description file (bld.inf), -which describes various aspects of the component, and generates make files -and a batch file called abld.bat. This batch file is -then used to drive the rest of the component build.

- - -

abld

-

Calls the .make files generated by the bldmake tool -to build a component. The make files typically call the makmake tool -to create makefiles that specify the required build steps to build the component -for a particular target.

- - -

makmake

-

Takes a .mmp project file which lists the elements -of the project, and produces a makefile for the platform specified. The GCC make utility -is then called to execute the make file.

- - -

elf2e32

-

Converts the ELF representation of an executable into an E32Image -format file, the format required to run on Symbian platform. Used only for -ARMV5 (ABIv2) target.

- - -

elftran

-

Transforms the ELF representation of an executable into an E32Image -format file, the format required to run on Symbian platform. Used only for -ARMV5 (ABIv1) target.

- - -

elf2Inf

-

Gets a list of the symbol names of the exported definitions from -an ELF file. Its output .inf file is input to makedef. -Used only for ARMV5 (ABIv1) target.

- - - -

makedef

-

Maintains or creates DEF files, which record an executable's exported -symbols by ordinal.

- - -

def2dll

-

Creates binary objects used to implement the Symbian platform DLL -model. These are a representation (ELF) of the export table (.exp file), -and its import library (.lib). Used only for ARMV5 (ABIv1) -target.

- - -

epocrc

-

Combines the actions of passing a resource file through the C++ -preprocessor, and then compiling it with the rcomp tool.

- - -

rcomp

-

Resource compiler. Compiles source rss resource -files into compiled resource data files, and a rsg resource -header file.

- - -

bmconv

-

Bitmap converter. Takes one or more Microsoft Windows bitmaps .bmp and -generates a single multi-bitmap file .mbm, optimised -for efficient runtime loading by the GDI. Also a header file .h with -symbolic definitions for each bitmap in the file.

- - - -

More specialised tools are available for particular types of development, -e.g. for generating font and printer driver libraries.

-
File types

The following file types are involved -in the build processes:

- - - -

bld.inf

-

component description file, input to bldmake

- - -

.mmp

-

project file: specification of a project, input to abld/makmake

- - -

.<target>

-

a makefile, output from makmake, used to build -the project for the specified target. Examples are .winscw for -the WINSCW target, .armv5 for the ARMV5 target, etc.

- - -

.make

-

build batch makefile, for use by abld for the -purposes of building, output from bldmake bldfiles

- - -

.cpp

-

C++ source file

- - -

.h

-

header file, for inclusion in C++ file

- - -

.rss

-

resource source file, for input to rcomp

- - -

.rh

-

resource header, for inclusion in resource file

- - -

.hrh

-

common C++ or resource header, for inclusion in either type of source -file

- - -

.rsg

-

generated resource header file, output from rcomp

- - -

.rsc

-

generated resource file, output from rcomp

- - -

.bmp

-

bitmap file, in Microsoft Windows format, input to bmconv (can -also be output)

- - -

.mbm

-

multi-bitmap file, generated by Symbian platform bitmap compiler, -output from bmconv (can also be input)

- - -

.def

-

linker definition file, defining an executable's exports and their -ordinal positions.

- - -

.lib

-

static library file, often containing stub functions for DLL linking.

- - -

.map

-

map of entities in an executable, output by linker

- - -

.exe

-

executable that can be loaded and run as a process

- - -

.dll

-

dynamic link library or DLL: executable containing shared functionality -that can be loaded by other executables

- - -

.dso

-

ELF format file output by compiler/linkers for ARM targets. Also -used for linking against DLLs in the ARMV5 ABIv2 target.

- - - -
- \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2910AB26-CA7C-50B9-A187-0C8406C1ED1F.dita --- a/Symbian3/SDK/Source/GUID-2910AB26-CA7C-50B9-A187-0C8406C1ED1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,65 +0,0 @@ - - - - - -prj_extensions -

prj_extensions

-

start extension subsystem\ext-template

-

[target target_file_name]

-

[sources source_file_1 ... source_file_n]

-

[dependencies dependency_file_1 ... -dependency_file_n]

-

[tool toolname]

-

[option key_1 value_1]

-

...

-

[option key_n value_n]

-

end

-

Note: The value argument in the option statement is optional.

-

The prj_extensions section lists all the template extension -makefiles that are to be invoked while building the component. This approach -is introduced since Symbian OS v9.3 and it deprecates the use of makefile and gnumakefile directives -in bld.inf files. It is recommend to use prj_extensions approach -to call the extension makefile templates.

-

Note that a prj_extensions section can have one or more of start extension -... end blocks.

-

subsystem/ext-template specifies the extension makefile -template name along with its path relative to the epoc32 template -directory, which is \epoc32\tools\makefile_templates\. -The .mk suffix of the template need not be specified, as -it is handled automatically.

-

The optional target target_file_name specifies -the name and location of the target to be built.

-

The optional sources source_file_1 .... - source_file_n specifies the list of source file names along -with their path, which are required to build the target.

-

The optional dependencies dependency_file_1 -... dependency_file_n specifies the list of dependency file -names along with their path, which are required to build the target. -The file extension part of the name need not be specified, as this will be -automatically supplied.

-

The optional tool toolname specifies -the tool to be used to build the target.

-

The optional option key_1 value_1 specifies -the parameter values for the template extension makefile, as key-value pairs. -These parameters are variables used in the template, and the precise set of -variables specified here are entirely dependent on the requirement. There -is no limit to the number of parameters a template extension makefile may -require and can take.

-

This example sets PREFIX, HALPATH and SOURCE options -of the template extension makefile config.mk

PRJ_EXTENSIONS -start extension base\config - -option PREFIX _SH2_ -option HALPATH \..\..\.. -option SOURCE \..\hal - -end - - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2922758C-37A4-436E-B0F3-358944F84E2A.dita --- a/Symbian3/SDK/Source/GUID-2922758C-37A4-436E-B0F3-358944F84E2A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2922758C-37A4-436E-B0F3-358944F84E2A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -58,7 +58,7 @@

Soft notification

Soft notifications are reminders that inform the user of events that have typically occurred during the user's absence. Soft notifications -can only be seen in the home screen, and the user can acknowledge them. There +can only be seen in the Idle state, and the user can acknowledge them. There are two types of soft notifications; the layouts resemble those of Confirmation queries and List queries:

  • A single soft notification contains one notification.

    • @@ -70,32 +70,15 @@

    Call window

    Incoming calls and outgoing calls are presented in pop-up windows.

     - -

    Discreet pop-up

     -

    Discreet pop-up is a temporary pop-up that appears on the upper -left corner for certain time-out. When discreet pop-up appears, it does not -dim the background and it does not have the focus. User can navigate in the -underlying application normally.

    Pop-up can have simple touch functionality. -It can be used, for example, for the information and confirmation note.

     -     - -

    Universal indicator pop-up

     -

    Universal indicator pop-up is opened from the universal indicator -pane. It contains more information of the active status indicators.

     -     -

    For more information, see Pop-ups

    Using -pop-up windows in applications

    For implementation information on -the pop-up window components, see:

      +pop-up windows in C++ applications

      For implementation information +on the pop-up window components, see:

      • Options menu

      • Query

      • Note

      • Soft notification

        • -

      • Discreet pop-up

        • -

      • Universal indicator -pop-up

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2939EEA8-DBC9-4882-B016-9C53166569CD_d0e56908_href.png Binary file Symbian3/SDK/Source/GUID-2939EEA8-DBC9-4882-B016-9C53166569CD_d0e56908_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2939EEA8-DBC9-4882-B016-9C53166569CD_d0e57051_href.png Binary file Symbian3/SDK/Source/GUID-2939EEA8-DBC9-4882-B016-9C53166569CD_d0e57051_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29486886-CB54-4A83-AD6D-70F971A86DFC.dita --- a/Symbian3/SDK/Source/GUID-29486886-CB54-4A83-AD6D-70F971A86DFC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-29486886-CB54-4A83-AD6D-70F971A86DFC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,7 +31,7 @@

    Launching the application

     - +

    • Framework requirements @@ -45,7 +45,7 @@

      Handling left softkey events and launching the Options menu

      - +

      • Event handling

        • @@ -55,9 +55,9 @@

        Handling key and pointer events

        - +

        - +

        • Handling window @@ -71,7 +71,7 @@

          Rotation

          - +

          Handling layout change events

           @@ -79,9 +79,9 @@

          Internationalization

           - +

          - +

          Internationalization and localization

           @@ -89,7 +89,7 @@

          Exiting the application

           - +

          Handling EEikCmdExit

           diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-296F25B4-8942-5FCB-B0A2-367157B72B72_d0e336710_href.png Binary file Symbian3/SDK/Source/GUID-296F25B4-8942-5FCB-B0A2-367157B72B72_d0e336710_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-296F25B4-8942-5FCB-B0A2-367157B72B72_d0e343176_href.png Binary file Symbian3/SDK/Source/GUID-296F25B4-8942-5FCB-B0A2-367157B72B72_d0e343176_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2972C100-EE68-5182-927C-3C46E8F5C0DD_d0e363980_href.png Binary file Symbian3/SDK/Source/GUID-2972C100-EE68-5182-927C-3C46E8F5C0DD_d0e363980_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2972C100-EE68-5182-927C-3C46E8F5C0DD_d0e383129_href.png Binary file Symbian3/SDK/Source/GUID-2972C100-EE68-5182-927C-3C46E8F5C0DD_d0e383129_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29E54156-DF94-5B34-ACAB-1417265C950D_d0e220101_href.png Binary file Symbian3/SDK/Source/GUID-29E54156-DF94-5B34-ACAB-1417265C950D_d0e220101_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29E54156-DF94-5B34-ACAB-1417265C950D_d0e225095_href.png Binary file Symbian3/SDK/Source/GUID-29E54156-DF94-5B34-ACAB-1417265C950D_d0e225095_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29E7942D-A00D-5771-9782-59260965C687_d0e213911_href.png Binary file Symbian3/SDK/Source/GUID-29E7942D-A00D-5771-9782-59260965C687_d0e213911_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29E7942D-A00D-5771-9782-59260965C687_d0e218909_href.png Binary file Symbian3/SDK/Source/GUID-29E7942D-A00D-5771-9782-59260965C687_d0e218909_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29F55D74-A206-5862-9C83-2C5045B2DB7F_d0e299287_href.png Binary file Symbian3/SDK/Source/GUID-29F55D74-A206-5862-9C83-2C5045B2DB7F_d0e299287_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-29F55D74-A206-5862-9C83-2C5045B2DB7F_d0e305759_href.png Binary file Symbian3/SDK/Source/GUID-29F55D74-A206-5862-9C83-2C5045B2DB7F_d0e305759_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A109FEC-5173-55FD-ACA8-3CAE48A93540_d0e356303_href.png Binary file Symbian3/SDK/Source/GUID-2A109FEC-5173-55FD-ACA8-3CAE48A93540_d0e356303_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A109FEC-5173-55FD-ACA8-3CAE48A93540_d0e375491_href.png Binary file Symbian3/SDK/Source/GUID-2A109FEC-5173-55FD-ACA8-3CAE48A93540_d0e375491_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e51533_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e51533_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e51676_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e51676_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e66217_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e66217_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e66360_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e66360_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e68802_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e68802_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e68826_href.png Binary file Symbian3/SDK/Source/GUID-2A4DED23-D0AB-436A-BCED-F0645FF05726_d0e68826_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2AB5AA00-71B2-58F4-AE17-9A38D1E5AA99_d0e213823_href.png Binary file Symbian3/SDK/Source/GUID-2AB5AA00-71B2-58F4-AE17-9A38D1E5AA99_d0e213823_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2AB5AA00-71B2-58F4-AE17-9A38D1E5AA99_d0e218821_href.png Binary file Symbian3/SDK/Source/GUID-2AB5AA00-71B2-58F4-AE17-9A38D1E5AA99_d0e218821_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2ABCF233-7DCC-59E2-B075-81E148A1D2AB_d0e262336_href.png Binary file Symbian3/SDK/Source/GUID-2ABCF233-7DCC-59E2-B075-81E148A1D2AB_d0e262336_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2ABCF233-7DCC-59E2-B075-81E148A1D2AB_d0e267200_href.png Binary file Symbian3/SDK/Source/GUID-2ABCF233-7DCC-59E2-B075-81E148A1D2AB_d0e267200_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2AD64552-440B-5439-885B-BE71DE0E8F1F.dita --- a/Symbian3/SDK/Source/GUID-2AD64552-440B-5439-885B-BE71DE0E8F1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Compiler macros

          The following macros are defined by the build tools. These macros may be used to control conditional compilation.

          __SYMBIAN32__

          indicates Symbian platform code in general

          __WINS__

          indicates the WINS or WINSCW platforms

          __DLL__

          if applicable, indicates that a DLL is being built

          __EXE__

          if applicable, indicates that a .exe is being built

          __CW32__

          indicates CodeWarrior is the compiler

          __EPOC32__

          indicates any target hardware platform, regardless of processor type or hardware architecture

          Further macros can be defined in project files through the MACRO statement.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2AE024D5-B34B-5E7E-BC7E-8C45E80173C5.dita --- a/Symbian3/SDK/Source/GUID-2AE024D5-B34B-5E7E-BC7E-8C45E80173C5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -freeze

          abld [ test ] freeze [-k] [-v] [ platform ] [ program ]

          This command freezes new DLL exports in frozen .def files using the FREEZE target provided in makefiles generated by makmake.

          The frozen .def files should be considered part of source for your component.

          • To freeze your component for the first time, having built the component, call this command.

          • Next, regenerate the makefiles so that import libraries can be created from the frozen .def files.

          The import libraries can be created explicitly using the abld - library command, or they can be built implicitly through abld - build or abld target.

          • To add new exports to a project within your component, having built the component, call this command.

          • Next, rebuild the import libraries so that they incorporate the new exports.

          Limitation:

          When freezing functions from the target types, build system can auto generate .def files only for DLL, EXEDLL, EXEXP, and STDDLL target types even if, you do not have a .def file specified in the matching .mmp file.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B50C6B1-E1E8-44E6-840B-7FAA206E6C26_d0e42265_href.png Binary file Symbian3/SDK/Source/GUID-2B50C6B1-E1E8-44E6-840B-7FAA206E6C26_d0e42265_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B50C6B1-E1E8-44E6-840B-7FAA206E6C26_d0e42423_href.png Binary file Symbian3/SDK/Source/GUID-2B50C6B1-E1E8-44E6-840B-7FAA206E6C26_d0e42423_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B7F7484-3A44-4A96-9B5D-79DF8A09115A.dita --- a/Symbian3/SDK/Source/GUID-2B7F7484-3A44-4A96-9B5D-79DF8A09115A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2B7F7484-3A44-4A96-9B5D-79DF8A09115A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,63 +1,59 @@ - - - - - -How resource -files work -

          In the Symbian platform, resource files -are used to define UI components used in applications. See Managing -resource files for information on defining the data structure.

          -

          The following resource files are typically used as source files in Symbian -applications:

          -
            -

          • .rss – resource source files used for UI -components in the application. For more information, see Resource -file structure, Required -resource file statements, and Optional -resource file statements.

            -
            • -

          • _reg.rss – resource source file used for -registration. For more information, see Creating -registration resource files.

            -
            • -

          • .hrh – resource header file used to define -enumerated sets of values. For more information, see Creating -resource header files.

            -
            • -

          • .rls – localization files used as a source -for UI texts strings in applications, and for managing these texts. For more -information, see Internationalization -and localization.

            -
            • -
          -

          The structures and symbolic IDs of the files are used in various ways -in your code.

          -

          The resource files above are then compiled to yield the following files:

          -
            -

          • .rsc or rNN, where -NN is a two number Symbian locale ID - compiled, machine-readable resource -files used by the application.

            • -

          • .rsg - generated resource header file containing -the symbolic IDs of the resources for inclusion into your code.

            • -

          • _reg.rsc or _reg.rNN, -where NN is a two number Symbian locale ID - compiled, machine-readable resource -file used for registration .

            • -
          - -

          The rsc, rNN, -and _reg.rsc files need to be included in your .sis installation -file so that they are placed in the device when the application is installed.

          - -

          When the application framework launches an application, it loads the -application resource file. The application framework compares the system locale -language setting with the available resource files, and loads the resource -file whose extension matches the locale language code. If there is no match, -then the system loads the resource file with the .rsc.

          + + + + + +How resource files work +

          In the Symbian platform, resource files +are used to define UI components used in applications. See Managing resource +files for information on defining the data structure.

          +

          The following resource files are typically used as source files +in Symbian applications:

          +
            +

          • .rss – resource source files used +for UI components in the application. For more information, see Resource file structure, Required resource file statements, and Optional resource file statements.

            +
            • +

          • _reg.rss – resource source file +used for registration. For more information, see Creating registration resource files.

            +
            • +

          • .hrh – resource header file used +to define enumerated sets of values. For more information, see Creating resource header files.

            +
            • +

          • .rls – localization files used as +a source for UI texts strings in applications, and for managing these +texts. For more information, see Internationalization +and localization.

            +
            • +
          +

          The structures and symbolic IDs of the files are used in various +ways in your code.

          +

          The resource files above are then compiled to yield the following +files:

          +
            +

          • .rsc or rNN, where NN is a two number Symbian locale ID - compiled, machine-readable +resource files used by the application.

            • +

          • .rsg - generated resource header +file containing the symbolic IDs of the resources for inclusion into +your code.

            • +

          • _reg.rsc or _reg.rNN, where NN is a two number Symbian locale ID - compiled, machine-readable +resource file used for registration .

            • +
          + +

          The rsc, rNN, and _reg.rsc files +need to be included in your .sis installation +file so that they are placed in the device when the application is +installed.

          + +

          When the application framework launches an application, it loads +the application resource file. The application framework compares +the system locale language setting with the available resource files, +and loads the resource file whose extension matches the locale language +code. If there is no match, then the system loads the resource file +with the .rsc.

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B820ED0-D0E1-4CF0-9D63-C91806EDB8F6_d0e2905_href.png Binary file Symbian3/SDK/Source/GUID-2B820ED0-D0E1-4CF0-9D63-C91806EDB8F6_d0e2905_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B820ED0-D0E1-4CF0-9D63-C91806EDB8F6_d0e2909_href.png Binary file Symbian3/SDK/Source/GUID-2B820ED0-D0E1-4CF0-9D63-C91806EDB8F6_d0e2909_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2B8CA0F5-8956-4D7B-B719-DE5EFD62C232.dita --- a/Symbian3/SDK/Source/GUID-2B8CA0F5-8956-4D7B-B719-DE5EFD62C232.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2B8CA0F5-8956-4D7B-B719-DE5EFD62C232.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ a number. This can be used to indicate item numbers in lists where necessary.

          Numbered list item - +

          Numbered items should be used only in lists where numbers are meaningful and give added value. There is no specific functionality (such as shortcuts) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2BF99BD2-5DB5-5DF6-8F82-22DD2E818584_d0e48659_href.png Binary file Symbian3/SDK/Source/GUID-2BF99BD2-5DB5-5DF6-8F82-22DD2E818584_d0e48659_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2BF99BD2-5DB5-5DF6-8F82-22DD2E818584_d0e48817_href.png Binary file Symbian3/SDK/Source/GUID-2BF99BD2-5DB5-5DF6-8F82-22DD2E818584_d0e48817_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C1DB75C-FB12-520C-85B1-57F1EDB61E3B.dita --- a/Symbian3/SDK/Source/GUID-2C1DB75C-FB12-520C-85B1-57F1EDB61E3B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -Feature variants

          Symbian platform can be built for multiple product configurations (variants). Each variant can include, enable or disable various features

          A variant-specific .hrh file is used to configure each different product. For example, the following .hrh files define features for products phone1, phone2 and phone3 respectively:

          • /epoc32/include/variant/Phone1.hrh

          • /epoc32/include/variant/Phone2.hrh

          • /epoc32/include/variant/Phone3.hrh

          The .hrh files contain macros which are used throughout the Symbian platform source. A DLL containing variant macros may be built differently for certain variants. It may also be common for certain variants. In order to identify variant DLLs, and to establish before compilation whether a variant DLL will be unique, a checksum value is calculated based on the combination of variant macros and appended to the DLL filename. If the checksum matches an existing DLL, already built for a different variant, that DLL is shared.

          For example, a my.dll with checksum appended appears as follows:

          /epoc32/release/armv5/urel/my.685dfabca1f1d90889ef4ac115c01a14.dll

          Support for variant builds is included in the Symbian platform build tool-chain as follows:

          • The configuration information specific to each product is defined in a .var file. The .var file is placed in the /epoc32/tools/variant/ folder. For more information on .var file syntax, refer to variant configuration file syntax.

          • The .hrh file containing the feature macro definitions is placed in the /epoc32/include/variant/ folder, and is referred in the .var file.

          • A DLL for a variant is built by specifying the variant name on the command-line using abld. For example, the following abld command builds the DLL for the variant var1:

            abld build armv5.var1

          • The build tool-chain generates a checksum for each variant (including the default variant) and appends it to the DLL name.

          • BUILDROM is modified to build a ROM image for a variant using the option -DFEATUREVARIANT. For example, the following command builds ROM image for var1:

            buildrom [options] –DFEATUREVARIANT=var1 <obey1> [<obey2> ...]

          If no .var file is specified the default.var file is used. The checksum will still be calculated and appended. You may avoid the checksum calculation by using the -invariant (or -inv) option with abld. This will build a default DLL with no checksum in the filename. If a DLL has FEATUREVARIANT specified in its mmp file, however, the -invariant option will be ignored.

          Notes

          • The .var file name must be same as the variant name.

          • If the .var file does not include an .hrh file, the build system uses default.hrh in /epoc32/include/variant/.

          • A DLL can be explicitly marked as a feature variant using the MMP keyword FEATUREVARIANT.

          • The DLLs built for a variant are placed in the appropriate folder under /epoc32/release/. For example, for all urel builds of ARMV5 variants the DLLs are stored in /epoc32/release/armv5/urel/.

          • The -inv or -invariant abld option is effective only if the DLL is not marked as feature variant explicitly.

          How to build feature based - variants How to build ROMs with - variants           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita --- a/Symbian3/SDK/Source/GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ v9.4).

          The following diagram provides an overview of the Window Server architecture in ScreenPlay.

          The Window Server in ScreenPlay - +

          Below we list some of the key features of the Window Server, including differences between the two architectures. The term surface is used in ScreenPlay for a hardware-independent memory buffer for holding an image diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C60C1C3-82B5-5ED3-98DF-E787193E8797.dita --- a/Symbian3/SDK/Source/GUID-2C60C1C3-82B5-5ED3-98DF-E787193E8797.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2C60C1C3-82B5-5ED3-98DF-E787193E8797.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ and generates bytecode for carrying out the work of each statement. The generated bytecode is then handed over to a Virtual Machine for evaluation.

          Simplified SQLite Architecture - +

          The Virtual Machine considers the database to be a set of B-Trees, one B-Tree for each table and one B-Tree for each index. The logic for creating, reading, writing, updating, balancing and destroying B-Trees is contained diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C68AC8D-6767-5865-B684-CB627C20C6DC.dita --- a/Symbian3/SDK/Source/GUID-2C68AC8D-6767-5865-B684-CB627C20C6DC.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,18 +0,0 @@ - - - - - -prj_testmmpfiles

          prj_testmmpfiles

          mmp_file_1 - [tidy] [manual] - [support]

          mmp_file_1 [tidy] [manual] - [support]

          makefile makefile_1 [tidy] [manual] - [support]

          makefile makefile_n [tidy] [manual] - [support]

          In the prj_testmmpfiles section, list the .mmp files contained in your component which define test programs.

          This section for test .mmp files has the same syntax as the section for standard .mmp files, except that two extra .mmp file attributes are provided: the manual and support attributes.

          If any such tests are listed, bldmake - bldfiles can create batch files for running the test programs for your component.

          • For automatic tests, which can be run without any user-intervention, do not specify either attribute.

          • For manual tests, which require user-input in order for them to complete successfully, specify the manual attribute.

          • Specify the support attribute if the test should not to be included in a batch file.

          For each platform, two batch files are created in the bldmake output directory for your component:

          • For automatic tests, a batch file called platform-name .auto.bat is created.

          • For manual tests, a batch file called platform-name .manual.bat is created.

          Note that, in order for the releasable test to be invoked successfully, the basename of the .mmp file must be the same as the basename of the releasable specified with the target statement in the .mmp file.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C74E932-B1CA-434B-AF96-66D52D689620.dita --- a/Symbian3/SDK/Source/GUID-2C74E932-B1CA-434B-AF96-66D52D689620.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2C74E932-B1CA-434B-AF96-66D52D689620.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,47 +9,39 @@ --> -Optional -resource file statements -

          The resource file statements listed in the following are optional; Create -resource file statements only for the UI components used by the application -for which the default implementation is not used.

          -

          For more information on resource statements for these components, see:

          +Optional resource file statements +

          The resource file statements listed in the following are optional; +Create resource file statements only for the UI components used by +the application for which the default implementation is not used.

          +

          For more information on resource statements for these components, +see:

            -

          • CBA buttons

            -
            • -

          • Menu -bar resource statements

            • +

          • CBA buttons

            • +

          • Menu bar resource statements

          • View -resource statements in the view architecture

            -
            • +resource statements in the view architecture

          • UI components

            -

            Building an AVKON-based application UI is a primary choice for third-party -add-on applications that do not need advanced customization. Such an approach -guarantees compatibility across different Series 60 Developer Platform editions, -but, in turn, puts some limitations on the application UI layout imposed by -AVKON. AVKON provides a wide choice of well-designed and versatile components, -but not all of these are easily modifiable.

            +

            Building an AVKON-based application UI is a primary choice for +third-party add-on applications that do not need advanced customization. +Such an approach guarantees compatibility across different Series +60 Developer Platform editions, but, in turn, puts some limitations +on the application UI layout imposed by AVKON. AVKON provides a wide +choice of well-designed and versatile components, but not all of these +are easily modifiable.

            -

            AVKON or AVKON-derived components should be favoured over custom CCoeControl-derived controls. AVKON UI components scale automatically +

            AVKON or AVKON-derived components should be favoured over custom CCoeControl-derived controls. +AVKON UI components scale automatically according to screen resolution and orientation.
              -

            • Dialogs -API

              • -

            • Editors -API

              • -

            • Form -API

              • -

            • Grids -API

              • -

            • Lists -API

              • -

            • Notes -API

              • -

            • Setting -Pages API

              • +

            • Dialogs API

              • +

            • Editors API

              • +

            • Form API

              • +

            • Grids API

              • +

            • Lists API

              • +

            • Notes API

              • +

            • Setting Pages API
            • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C8F2C68-5D25-5DB8-973C-E9CA6882A3FB_d0e323436_href.jpg Binary file Symbian3/SDK/Source/GUID-2C8F2C68-5D25-5DB8-973C-E9CA6882A3FB_d0e323436_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2C8F2C68-5D25-5DB8-973C-E9CA6882A3FB_d0e329906_href.jpg Binary file Symbian3/SDK/Source/GUID-2C8F2C68-5D25-5DB8-973C-E9CA6882A3FB_d0e329906_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e63133_href.png Binary file Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e63133_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e63276_href.png Binary file Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e63276_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e69226_href.png Binary file Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e69226_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e69250_href.png Binary file Symbian3/SDK/Source/GUID-2CBD504A-5538-4823-9139-2941A0BA5E8B_d0e69250_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2CEF22AD-7F80-58CE-AF5F-C7BF636D524F.dita --- a/Symbian3/SDK/Source/GUID-2CEF22AD-7F80-58CE-AF5F-C7BF636D524F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2CEF22AD-7F80-58CE-AF5F-C7BF636D524F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Camera Plug-in OverviewThis document introduces you to the Camera Plug-in component overview.
            Purpose

            The Camera Plug-in component provides an actual implementation for the Camera Framework component.

            Required background

            The Camera Plug-in component is implemented with the support of EcamPluginSupport.dll. It is expected that device creators can replace their own Camera Plug-in implementation.

            Architecture

            The Camera Plug-in component interacts with the Camera Framework component.

            The architectural relationship between Camera Plug-in and Camera Framework is shown below:

            Camera Plug-in Component Architecture -
            APIs

            The Camera Plug-in component consists of the following library:

            API Description

            ecamstubplugin.lib

            The Camera Stub Plug-in library is used to support the EcamPluginSupport.dll which is in the Camera Framework component.

            Typical uses

            Camera Plug-in is used as a symbian support implementation for the Camera Framework Ecom plug-ins.

            Camera Stub Plug-in +
APIs

The Camera Plug-in component consists of the following library:

API Description

ecamstubplugin.lib

The Camera Stub Plug-in library is used to support the EcamPluginSupport.dll which is in the Camera Framework component.

Typical uses

Camera Plug-in is used as a symbian support implementation for the Camera Framework Ecom plug-ins.

Camera Stub Plug-in Overview Camera Plug-in Support Camera Framework Overview \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D3F7471-9B92-5E49-B8BC-E0FA7AA709D7.dita --- a/Symbian3/SDK/Source/GUID-2D3F7471-9B92-5E49-B8BC-E0FA7AA709D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2D3F7471-9B92-5E49-B8BC-E0FA7AA709D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> DevSound Overview This document provides an overview of DevSound.
Purpose

DevSound provides a common API for all audio functionality.

DevSound library details

The DLL that provides the functionality and the library to which your code must link is identified below.

DLL LIB Short Description

mmfdevsound.dll

mmfdevsound.lib

These files are used for implementing DevSound.

Architectural relationship

Shown below is a representation of how DevSound interacts with the MMF Controller Framework and other components:

DevSound and related components -

DevSound uses the following components:

  • Client - DevSound can be used by the following clients:

    • applications

    • device creator library.

  • MMF Controller Framework

    For audio playing, recording, and conversion, the MMF client APIs interact with the lower levels of the MMF, the controller framework. The controller framework helps to manage the interface to DevSound and provides controller plug-ins for playing, recording, and converting audio data. The controller framework has two main classes RMMFController and CMMFController.

  • Controller Plug-in

    Depending on the functionality required by the client, the MMF controller framework loads the appropriate controller plug-ins. The plug-ins perform the required operations by communicating with DevSound and/or DevVideo, codecs and hardware.

    Custom controller plug-ins can be written to extend the MMF framework. For more information, see How to write a controller plug-in.

  • Audio Policy

    The Audio Policy component manages requests to access the audio hardware. For example, if DevSound needs to acquire the hardware for playing audio, it makes a request to the Audio Policy component. Depending on the priority of the request, the Audio Policy component grants or denies access to the hardware. DevSound must obey the Audio Policy.

  • Codecs

    DevSound uses codecs to convert multimedia data between different encodings.

    Custom codec plug-ins can be written. For more information, see How to write a codec plug-in.

  • Hardware Device API

    For audio functionality, the CMMFHwDevice plug-in class acts as the DevSound interface to the audio processing hardware.

Description

DevSound provides the interface between the Symbian platform and the audio processing hardware for all audio functionality. DevSound is responsible for providing access to audio resources, configuring audio hardware, and audio playback and recording.

Key DevSound classes

The DevSound API comprises the following classes:

  • CMMFDevSound is the class which forms the DevSound API.

  • MDevSoundObserver provides callbacks to users of the DevSound API. It serves as the method of communication between a client and DevSound. For example, MDevSoundObserver handles completion and cancellation requests for audio playing, recording, and conversion.

Using DevSound

DevSound offers the following main functions which can be used by DevSound clients:

  • Audio Settings

    DevSound can be used to initialise and configure hardware devices, for example, set microphone gain and stereo balance.

  • Audio Play

    DevSound can be used to play buffered audio data.

  • Audio Record

    DevSound can be used to record audio data.

  • Audio Convert

    DevSound can be used to convert the type, sample rate and format of audio data.

  • Tone Play

    DevSound can play a single tone, tone sequence or Dual Tone Multi-Frequency (DTMF) string.

Playing audio Recording Audio Playing tones \ No newline at end of file +

DevSound uses the following components:

  • Client - DevSound can be used by the following clients:

    • applications

    • device creator library.

  • MMF Controller Framework

    For audio playing, recording, and conversion, the MMF client APIs interact with the lower levels of the MMF, the controller framework. The controller framework helps to manage the interface to DevSound and provides controller plug-ins for playing, recording, and converting audio data. The controller framework has two main classes RMMFController and CMMFController.

  • Controller Plug-in

    Depending on the functionality required by the client, the MMF controller framework loads the appropriate controller plug-ins. The plug-ins perform the required operations by communicating with DevSound and/or DevVideo, codecs and hardware.

    Custom controller plug-ins can be written to extend the MMF framework. For more information, see How to write a controller plug-in.

  • Audio Policy

    The Audio Policy component manages requests to access the audio hardware. For example, if DevSound needs to acquire the hardware for playing audio, it makes a request to the Audio Policy component. Depending on the priority of the request, the Audio Policy component grants or denies access to the hardware. DevSound must obey the Audio Policy.

  • Codecs

    DevSound uses codecs to convert multimedia data between different encodings.

    Custom codec plug-ins can be written. For more information, see How to write a codec plug-in.

  • Hardware Device API

    For audio functionality, the CMMFHwDevice plug-in class acts as the DevSound interface to the audio processing hardware.

Description

DevSound provides the interface between the Symbian platform and the audio processing hardware for all audio functionality. DevSound is responsible for providing access to audio resources, configuring audio hardware, and audio playback and recording.

Key DevSound classes

The DevSound API comprises the following classes:

  • CMMFDevSound is the class which forms the DevSound API.

  • MDevSoundObserver provides callbacks to users of the DevSound API. It serves as the method of communication between a client and DevSound. For example, MDevSoundObserver handles completion and cancellation requests for audio playing, recording, and conversion.

Using DevSound

DevSound offers the following main functions which can be used by DevSound clients:

  • Audio Settings

    DevSound can be used to initialise and configure hardware devices, for example, set microphone gain and stereo balance.

  • Audio Play

    DevSound can be used to play buffered audio data.

  • Audio Record

    DevSound can be used to record audio data.

  • Audio Convert

    DevSound can be used to convert the type, sample rate and format of audio data.

  • Tone Play

    DevSound can play a single tone, tone sequence or Dual Tone Multi-Frequency (DTMF) string.

Playing audio Recording Audio Playing tones \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D74594C-AFEB-550E-AD69-1C4A0455C5AC.dita --- a/Symbian3/SDK/Source/GUID-2D74594C-AFEB-550E-AD69-1C4A0455C5AC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2D74594C-AFEB-550E-AD69-1C4A0455C5AC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,8 +11,8 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Structure of a Message Store

This section provides information about the Message Store entries.

Message Framework provides a tree view of entries in a Message Store. The tree is divided into three levels: root entry, service entry, and folder and message entry, which are provided TMsvEntry. The child entries of the root entry must be service entries. A message client application can begin from the root entry, and by successively finding the children of an entry, can traverse the whole entry tree. The parent of each entry is recorded in the index entry's details.

The following figure illustrates how services are placed below a root entry.

Message Store -

  • 1: Root entry —This entry is just present to tie the tree structure together.

  • 2: Service entry —This level used for settings information, usually to set up communication protocols, for example, ISP settings. There is one local service under which local folders and messages are stored, and zero or more remote services. Remote services represent message accounts.

    There are two types of service entry:

    • Remote Services: These represent message accounts stored on remote stores such as email servers and the SIM store of SMS messages.

    • Local Services: There is a single local service under which local folders and messages are stored.

      The Message Server handles changes to local entries. Internally it may delegate changes to remote entries, such as copying and moving messages to and from a remote service, to the server MTM that owns that service.

    +

    • 1: Root entry —This entry is just present to tie the tree structure together.

    • 2: Service entry —This level used for settings information, usually to set up communication protocols, for example, ISP settings. There is one local service under which local folders and messages are stored, and zero or more remote services. Remote services represent message accounts.

      There are two types of service entry:

      • Remote Services: These represent message accounts stored on remote stores such as email servers and the SIM store of SMS messages.

      • Local Services: There is a single local service under which local folders and messages are stored.

        The Message Server handles changes to local entries. Internally it may delegate changes to remote entries, such as copying and moving messages to and from a remote service, to the server MTM that owns that service.

      Remote and local entries -

    • 3: Folder entries and message entries — Folders entries are used to group a number of message entries. For more information on folders, see Message folders. Messages store the content of a message. Message entries can have child entries which represent the structure of a message.

      Folders and messages under the local service represent messages stored on the device. Folders and messages under remote services represent a local copy of messages that are present on a remote server. For example, under a POP3 email service you can have copies of all the messages present on the POP3 email server, and under an SMS service you can have SMS messages that are stored on a SIM.

      Each message entry also has an associated service ID. The service ID is associated with a service entry whose settings is used in all Messaging operations on that message entry.

    Validity of the Message Store

    The structure of the Message store is considered to be valid only if an index entry conforms to the following rules:

    • A non-service entry cannot be owned by root and must have its service ID field set.

    • A service entry must be owned by root and have the service ID of itself.

    Important: The Message Server controls access to the entries in the store. It enforces the three levels; therefore, attempts to create message or folder entries directly under the root entry fails.

    Message Server and Store Messaging Framework Message Server and Store +

  • 3: Folder entries and message entries — Folders entries are used to group a number of message entries. For more information on folders, see Message folders. Messages store the content of a message. Message entries can have child entries which represent the structure of a message.

    Folders and messages under the local service represent messages stored on the device. Folders and messages under remote services represent a local copy of messages that are present on a remote server. For example, under a POP3 email service you can have copies of all the messages present on the POP3 email server, and under an SMS service you can have SMS messages that are stored on a SIM.

    Each message entry also has an associated service ID. The service ID is associated with a service entry whose settings is used in all Messaging operations on that message entry.

Validity of the Message Store

The structure of the Message store is considered to be valid only if an index entry conforms to the following rules:

  • A non-service entry cannot be owned by root and must have its service ID field set.

  • A service entry must be owned by root and have the service ID of itself.

Important: The Message Server controls access to the entries in the store. It enforces the three levels; therefore, attempts to create message or folder entries directly under the root entry fails.

Message Server and Store Messaging Framework Message Server and Store Concepts Message Server and Store Tutorials \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D7BD92E-E242-524B-8D83-874C32EC0503_d0e135601_href.png Binary file Symbian3/SDK/Source/GUID-2D7BD92E-E242-524B-8D83-874C32EC0503_d0e135601_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D7BD92E-E242-524B-8D83-874C32EC0503_d0e139206_href.png Binary file Symbian3/SDK/Source/GUID-2D7BD92E-E242-524B-8D83-874C32EC0503_d0e139206_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D93660B-8206-5D20-85F5-6FFCF4549127.dita --- a/Symbian3/SDK/Source/GUID-2D93660B-8206-5D20-85F5-6FFCF4549127.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2D93660B-8206-5D20-85F5-6FFCF4549127.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ stream:

Persistent store with a root stream - +
See also

File stores

diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2D9B17E7-2B7A-5E16-AB06-D9507457A85D.dita --- a/Symbian3/SDK/Source/GUID-2D9B17E7-2B7A-5E16-AB06-D9507457A85D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2D9B17E7-2B7A-5E16-AB06-D9507457A85D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,33 +9,31 @@ --> -SMS -exampleThis example code demonstrates how to send and receive SMS messages -using the Messaging Framework APIs. -
Description

This -updated C++ example demonstrates programmatical handling of SMS messages. -Messages can be sent from the application and they can be received directly -into the application (that is, catching incoming messages before the user -gets any notification). In addition, messages can be deleted, copied, or moved -to other folders of the message store (inbox, outbox, drafts).

-
Download

Click -on the following link to download the example: smsexample.zip

Click: browse to view the example code.

+SMS exampleThis example code demonstrates how to send and receive +SMS messages using the Messaging Framework APIs. +
Description

This updated C++ example demonstrates programmatical handling +of SMS messages. Messages can be sent from the application and they +can be received directly into the application (that is, catching incoming +messages before the user gets any notification). In addition, messages +can be deleted, copied, or moved to other folders of the message store +(inbox, outbox, drafts).

+
Download

Click on the following link to download the example: smsexample.zip

Click: browse to view the example code.

Classes

CMsvSession

CMsvEntry

CMmsClientMtm

CSmsClientMtm

CClientMtmRegistry

CSmsHeader

-
Building and -configuring
    -

  • You can build the example -from your IDE or the command line.

    If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

    If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

    bldmake -bldfiles

    abld build

    How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

    • -

  • For the emulator, the -example builds an executable called smsexample.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

    • +
    Building +and configuring
      +

    • You can build +the example from your IDE or the command line.

      If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

      If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld +build

      • +

    • For the emulator, +the example builds an executable called smsexample.exe in the epoc32\release\winscw\<udeb or + urel>\ folder.

    -SMS MTM Overview - +SMS +MTM Overview \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2DC89F9D-30E8-5260-8850-53E4152EE3CF.dita --- a/Symbian3/SDK/Source/GUID-2DC89F9D-30E8-5260-8850-53E4152EE3CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2DC89F9D-30E8-5260-8850-53E4152EE3CF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,50 +1,47 @@ - - - - - -Finding -your way aroundRead this page to learn about the contents and structure of the -library. -
    The platform -structure and APIs

    The Symbian -Guide provides introductory documents to the platform -as a whole, and guides that describe the major areas of the platform in depth.

    The -Symbian platform is a large system, and contains hundreds of C++ classes and -thousands of member functions. Like most complex systems, it is easiest to -divide it into large areas, and gradually to narrow your focus down to the -areas that are most important to your tasks.

    The Symbian System Model organises the components of the -Symbian platform into a layered software architecture. The guides in this -library are also structured around this architecture. The guides describe -the key technology and architectural concepts of the area, and show the key -ways to use its classes.

    Note: Before the System Model was introduced, -the Symbian platform used another architectural view based on large divisions -called subsystems. Some documentation has not yet been changed to use the -System Model rather than subsystems.

    -
    Newcomers to -the Symbian platform

    For those developing on the Symbian platform -for the first time, the Essential -Idioms section describes the distinctive programming idioms and conventions -of the Symbian platform.

    -
    Examples

    The Examples section gives -instructions for building and using the large set of C++ example projects -that accompany the library. Projects include examples that demonstrate the -use of fundamental Symbian platform classes, and many examples showing how -to use particular Symbian platform C++ APIs.

    Example code is provided -for illustrative and demonstration purposes, and should not be assumed to -be useable as product code.

    - -
    Tools

    The -library does not include documentation for most tools, which are usually delivered -separately from the Symbian platform code. See the Tools section of the Symbian Developer Community website.

    The Tools And Utilities section -documents the tools that are delivered with the platform. In particular, the Build Tools Guide and -the Build Tools Reference document -the abld/bldmake (SBSv1) command line -build tools, and explain the project file formats.

    + + + + + +Finding your way aroundRead this page to learn about the contents and structure +of the library. +
    The +platform structure and APIs

    The Symbian Guide provides introductory documents to the platform as a whole, and +guides that describe the major areas of the platform in depth.

    The Symbian platform is a large system, and contains hundreds +of C++ classes and thousands of member functions. Like most complex +systems, it is easiest to divide it into large areas, and gradually +to narrow your focus down to the areas that are most important to +your tasks.

    The Symbian System Model organises the components +of the Symbian platform into a layered software architecture. The +guides in this library are also structured around this architecture. +The guides describe the key technology and architectural concepts +of the area, and show the key ways to use its classes.

    Note: +Before the System Model was introduced, the Symbian platform used +another architectural view based on large divisions called subsystems. +Some documentation has not yet been changed to use the System Model +rather than subsystems.

    +
    Newcomers +to the Symbian platform

    For those developing on the Symbian +platform for the first time, the Essential Idioms section describes the distinctive programming idioms and conventions +of the Symbian platform.

    +
    Examples

    The Examples section gives instructions for building and using the large set +of C++ example projects that accompany the library. Projects include +examples that demonstrate the use of fundamental Symbian platform +classes, and many examples showing how to use particular Symbian platform +C++ APIs.

    Example code is provided for illustrative and demonstration +purposes, and should not be assumed to be useable as product code.

    + +
    Tools

    The library does not include documentation for most tools, which +are usually delivered separately from the Symbian platform code. See +the Tools section of the Symbian Developer +Community website.

    The Tools section documents +the tools that are delivered with the platform. In particular, the +Build Tools Guide and the Build Tools Reference document the abld/bldmake (SBSv1) command line build +tools, and explain the project file formats.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2DDAAD1C-D9EB-5741-B6AE-2383646E0EDB.dita --- a/Symbian3/SDK/Source/GUID-2DDAAD1C-D9EB-5741-B6AE-2383646E0EDB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2DDAAD1C-D9EB-5741-B6AE-2383646E0EDB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,7 +39,7 @@ class, TDesC, contains a data member which holds the length of the data. The following drawing shows the layout of a TPtrC object for a string of five characters representing the English word "Hello".

    - +

    Non-modifiable pointer descriptor
Modifiable pointer descriptor

The data represented @@ -64,7 +64,7 @@ layout of a TPtr object for a string of five characters representing the English word "Hello". The maximum length to be represented by the descriptor is 12.

- +

Modifiable pointer descriptor
\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E0F793F-3D80-4303-AF48-C7341F417DC9.dita --- a/Symbian3/SDK/Source/GUID-2E0F793F-3D80-4303-AF48-C7341F417DC9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2E0F793F-3D80-4303-AF48-C7341F417DC9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -90,7 +90,7 @@ Editing menu - + Default touch events in editor diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E22CB5B-E648-5760-AB74-8947C7EDE2CF.dita --- a/Symbian3/SDK/Source/GUID-2E22CB5B-E648-5760-AB74-8947C7EDE2CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2E22CB5B-E648-5760-AB74-8947C7EDE2CF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,32 +1,30 @@ - - - - - -Lexical -Analysis OverviewProvides string analysis and string-to-number conversions -
Description

The API has two key concepts: lexical -analyser, and extraction mark.

-
Lexical analyser

The lexical analyser provides facilities -to identify and extract characters and tokens (substrings delimited by white -space) from a descriptor or NULL-terminated string. It also provides string-to-number -conversions.

The lexical analyser interface is provided by TLex16 for -wide strings, and TLex8 for narrow strings. TLex is -a typedef for TLex16.

-
Extraction mark

The extraction mark allows positions -in a string that is being analysed to be remembered. Later lexical analysis -operations can then operate on this position in the string.

The extraction -mark interface is provided by TLexMark16 for wide strings, -and TLexMark8 for narrow strings. TLexMark is -a typedef for TLexMark16.

- - -Descriptors Overview - + + + + + +Lexical Analysis OverviewProvides string analysis and string-to-number conversions +
Description

The API has two key concepts: lexical analyser, and extraction +mark.

+
Lexical +analyser

The lexical analyser provides facilities to identify +and extract characters and tokens (substrings delimited by white space) +from a descriptor or NULL-terminated string. It also provides string-to-number +conversions.

The lexical analyser interface is provided by TLex16 for wide strings, and TLex8 for +narrow strings. TLex is a typedef for TLex16.

+
Extraction +mark

The extraction mark allows positions in a string that +is being analysed to be remembered. Later lexical analysis operations +can then operate on this position in the string.

The extraction +mark interface is provided by TLexMark16 for wide +strings, and TLexMark8 for narrow strings. TLexMark is a typedef for TLexMark16.

+ + +Descriptors Overview \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E253B30-2611-546D-AE5B-1752556FC8E8.dita --- a/Symbian3/SDK/Source/GUID-2E253B30-2611-546D-AE5B-1752556FC8E8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2E253B30-2611-546D-AE5B-1752556FC8E8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@ Concepts

This section section describes the Simple Mail Transfer Protocol (SMTP) and its implementation on Symbian platform.

-
SMTP protocol

SMTP +

SMTP protocol

SMTP is the most widely used protocol for sending emails. It is a text-based and push protocol that cannot pull messages from a remote server on demand.

One or more recipients of a message are specified in a message along with the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E3A91F9-5538-5E23-8D23-CE97B677A668_d0e172781_href.jpg Binary file Symbian3/SDK/Source/GUID-2E3A91F9-5538-5E23-8D23-CE97B677A668_d0e172781_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E3A91F9-5538-5E23-8D23-CE97B677A668_d0e177801_href.jpg Binary file Symbian3/SDK/Source/GUID-2E3A91F9-5538-5E23-8D23-CE97B677A668_d0e177801_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2E986A81-F094-4F1D-9ECB-6A325CFA5BB4.dita --- a/Symbian3/SDK/Source/GUID-2E986A81-F094-4F1D-9ECB-6A325CFA5BB4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2E986A81-F094-4F1D-9ECB-6A325CFA5BB4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,38 +10,34 @@ Plug-ins -

Plug-ins connect to the system using the EPOC Component Object Model -(ECom). ECom is based on client/server architecture and provides services -to instantiate, resolve, and destroy instances of plug-ins at run time. For -more information, see the ECom -Architecture.

-ECom framework -

A hostile or malfunctioning plug-in may cause crashes or security leaks, -even on otherwise well-tested applications. The platform -security architecture protects the processes by verifying that the -plug-in has equal or greater set of capabilities than the process in which -it is loaded. For more information, see the ECom -and the Platform Security Architecture.

-

For examples, see Plug-in -Framework (ECom) Examples.

+

Plug-ins connect to the system using the EPOC Component Object +Model (ECom). ECom is based on client/server architecture and provides +services to instantiate, resolve, and destroy instances of plug-ins +at run time. For more information, see the ECom Architecture.

+ECom framework +

A hostile or malfunctioning plug-in may cause crashes or security +leaks, even on otherwise well-tested applications. The platform security architecture protects the processes by verifying that the plug-in +has equal or greater set of capabilities than the process in which +it is loaded. For more information, see the ECom and the Platform +Security Architecture.

+

For examples, see Plug-in Framework +(ECom) Examples.

Communication plug-ins

It is possible to use plug-ins to implement additional functionality to serial, socket, and messaging frameworks. These plug-ins are especially important for security because they deal with communication.

    -

  • For serial communication there are serial protocol modules -(CSY modules ), which are loaded by the Serial Comms Server. For more information -on serial communication, see Serial -Communications Server.

    • -

  • For socket-based communication there are protocol modules -(PRT), which are loaded by the Socket Server. For more information on socket-based -communication, see Socket +

  • For serial communication there are serial protocol +modules (CSY modules ), which are loaded by the Serial Comms Server. +For more information on serial communication, see Serial Communications Server.

    • -

  • For messaging there are Message Type Modules (MTM), which -include both client and server components. MTMs are a set of dlls -rather than a single dll. For more information, see Message Type Module.

    -
    • +

  • For socket-based communication there are protocol +modules (PRT), which are loaded by the Socket Server. For more information +on socket-based communication, see Socket Server.

    • +

  • For messaging there are Message Type Modules (MTM), +which include both client and server components. MTMs are a set of dlls rather than a single dll. For more +information, see Message Type Module.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2ED8BB5F-27CA-5DD3-BA0F-5773AE14A8CC_d0e202413_href.png Binary file Symbian3/SDK/Source/GUID-2ED8BB5F-27CA-5DD3-BA0F-5773AE14A8CC_d0e202413_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2ED8BB5F-27CA-5DD3-BA0F-5773AE14A8CC_d0e207420_href.png Binary file Symbian3/SDK/Source/GUID-2ED8BB5F-27CA-5DD3-BA0F-5773AE14A8CC_d0e207420_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e393415_href.png Binary file Symbian3/SDK/Source/GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e393415_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e397210_href.png Binary file Symbian3/SDK/Source/GUID-2EF123C9-62A2-52FF-9792-66EF41F37452_d0e397210_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F0008EB-715C-50EC-87AD-C78619F44858_d0e221141_href.png Binary file Symbian3/SDK/Source/GUID-2F0008EB-715C-50EC-87AD-C78619F44858_d0e221141_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F0008EB-715C-50EC-87AD-C78619F44858_d0e226135_href.png Binary file Symbian3/SDK/Source/GUID-2F0008EB-715C-50EC-87AD-C78619F44858_d0e226135_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F6EF388-CA87-5AAD-A4C5-37FC3CE15331_d0e243046_href.png Binary file Symbian3/SDK/Source/GUID-2F6EF388-CA87-5AAD-A4C5-37FC3CE15331_d0e243046_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F6EF388-CA87-5AAD-A4C5-37FC3CE15331_d0e248005_href.png Binary file Symbian3/SDK/Source/GUID-2F6EF388-CA87-5AAD-A4C5-37FC3CE15331_d0e248005_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F7E988C-C90D-54BA-A4A2-8255EF82135D.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-2F7E988C-C90D-54BA-A4A2-8255EF82135D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,13 @@ + + + + + +ReferenceThis section provides a summary of documents related to the secure sockets that you can refer.
Item Header

CSecureSocket

SecureSocket.h

MSecureSocket

SecureSocketInterface.h

TClientCertMode

SecureSocketInterface.h

TDialogMode

SecureSocketInterface.h

For more information about TLS_PSK operation, see RFC4279.

Sockets + Server \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F8B9FAD-1669-5458-BA24-2E15BB0D2F53_d0e276117_href.png Binary file Symbian3/SDK/Source/GUID-2F8B9FAD-1669-5458-BA24-2E15BB0D2F53_d0e276117_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F8B9FAD-1669-5458-BA24-2E15BB0D2F53_d0e280956_href.png Binary file Symbian3/SDK/Source/GUID-2F8B9FAD-1669-5458-BA24-2E15BB0D2F53_d0e280956_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2F987147-1435-55F1-B61C-8413C4AD8424.dita --- a/Symbian3/SDK/Source/GUID-2F987147-1435-55F1-B61C-8413C4AD8424.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2F987147-1435-55F1-B61C-8413C4AD8424.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@

The general structure of a direct file store, from the point of view of the physical file containing the store, is illustrated below.

- +

The header is the content of the descriptor returned by the Des() member function of TCheckedUid; this contains the file store type diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita --- a/Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ cache functionality in the Message Server.

Caching architecture - +
Creating and maintaining free space in memory

Memory allocation to the cache @@ -34,12 +34,12 @@ created with an initial size of 410KB (40 percent of 1024KB). If 70 percent of the free space in the cache gets used the server allocates an additional 205KB (20 percent of 1024).

- +

Message Server can make two further 205KB allocations which it does as use reaches 70 percent of the memory already allocated.

- +

If more than 70 percent of the first two allocated memory chunks is used, an additional 20 percent of memory is added to the free space.

- +
\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-2FCB4609-1568-5B5F-AD9D-5A531B17A68F.dita --- a/Symbian3/SDK/Source/GUID-2FCB4609-1568-5B5F-AD9D-5A531B17A68F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,24 +0,0 @@ - - - - - -resource -

resource resource-file-list

-

From v9.0, applications need to specify the directory -for the built resource. Use the start resource syntax to do this..

-

Use the resource statement, to specify resource files -for application projects. The makefile will build the resource file into the -target directory.

-

Each resource file should be given with its extension, e.g. squash.rss.

-

If more than one language is specified with the lang, -then each resource will be compiled multiple times, once for each language -specified.

-

If you have a system project rather than an application, use the systemresource statement.

- \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-300B4AF5-7F6E-542D-886D-335674EDE8FD_d0e321282_href.png Binary file Symbian3/SDK/Source/GUID-300B4AF5-7F6E-542D-886D-335674EDE8FD_d0e321282_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-300B4AF5-7F6E-542D-886D-335674EDE8FD_d0e327752_href.png Binary file Symbian3/SDK/Source/GUID-300B4AF5-7F6E-542D-886D-335674EDE8FD_d0e327752_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-301037F1-1983-565A-88F9-633BBF0EBB91.dita --- a/Symbian3/SDK/Source/GUID-301037F1-1983-565A-88F9-633BBF0EBB91.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-301037F1-1983-565A-88F9-633BBF0EBB91.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,213 +1,165 @@ - - - - - -posixsignals: -POSIX Signal Example, Using P.I.P.S.This example demonstrates various signal use cases as supported -in P.I.P.S. -
Purpose

The -example demonstrates the following use cases:

    -

  1. Sending and handling -a signal using the default handler

    2. -

  2. Sending and handling -a signal using a customized signal handler

    3. -

  3. Ignoring an incoming -signal

    4. -

  4. Blocking and releasing -a signal

    5. -

  5. Waiting for a signal

    6. -

  6. Generating and handling -a SIGPIPE signal

    7. -

  7. Using a signal to gracefully -terminate a process

    8. -

  8. Using a signal to handle -an asynchronous event

    9. -

The example delivers 3 sub projects:

    -

  • basicSignals: This -project demonstrates basic signal use cases. It shows the first six use cases -mentioned in the list above. The use cases are demonstrated through basicsignals.exe.

    • -

  • sigtermSignal: This -project demonstrates the graceful termination of a process using the SIGTERM signal. -The use case is demonstrated through sigtermsignal.exe and raisesignal.exe.

    • -

  • asyncSignal: This -project demonstrates asynchronous signal handling using the SIGUSR1 signal -and the SIGUSR2 signal. The use case is demonstrated using sigusr1.exe and sigusr2.exe.

    • -
-
Description

The -use cases demonstrated in this example are described below.

Note: For -clarity in the documentation for this example, signal names have been given -in capitals whilst process names have been given in lower case.

1. -Sending and handling a signal using the default handler

The default -implementation of the signals supported in P.I.P.S. will either terminate -a process or ignore a process. Signals are generated using the Kill() method -and they are handled as per the implementation in the default handler.

To -demonstrate this use case we use SIGCHLD and SIGALRM signals. SIGCHLD by -default gets ignored whenever it is raised, whereas SIGALRM causes -a process termination when raised. As a result the example terminates whenever SIGALRM is -raised, whereas an info message is printed when SIGCHLD is -raised.

2. Sending and handling a signal using a customized signal -handler

To override the default implementation of a signal a -customized handler can be defined. This customized handler can be set either -by using sigaction() or signal(). The sigaction() method -takes struct sigaction as one of its parameters (the sa_handler member -of this structure is filled with the custom handler). Now whenever a signal -is generated the custom handler is executed.

For the demonstration -of this particular use case, SIGCHLD and SIGALRM signals -are used. These signals are assigned custom handler functions. The handlers -for these signals contains a simple user message. Thus, whenever the signals -are raised, the customized signal handlers get invoked instead of the default -handlers.

3. Ignoring an incoming signal

A signal -can be ignored by setting SIG_IGN in the sa_handler member -of struct sigaction. The demonstration of this use case also -uses SIGCHLD and SIGALRM signals, and as -a result of setting SIG_IGN in sa_handler the -signals are ignored when raised.

4. Blocking and releasing a signal

A -signal can be blocked by first adding it to the blocking set (a list of signals -we want to block, when a signal is executing) by using the sigaddset() method -and then calling the sigprocmask() function. Once a signal -is blocked it will always be ignored upon generation. The sigrelse() method -is used to unblock a signal.

Demonstration of this use case involves -the SIGUSR1 and SIGUSR2 signals. Both SIGUSR1 and SIGUSR2 are -user-defined signals. We first block the SIGUSR1 signal by -adding it to the blocking set and making a call to the sigprocmask() function. -Now whenever SIGUSR1 is raised it will get ignored as it -is blocked. SIGUSR1 will keep waiting in the pending queue -until it is released. The release of SIGUSR1 happens in the SIGUSR2 signal -handler. Once SIGUSR1 is released, it is removed from the -pending queue and its handler function is called to handle it.

5. -Waiting for a signal

Before a process can wait on a particular -signal, it has to add the signal to the mask set (which is a list of signals -we want to block) and then call the sigprocmask() method. -The process then sets the timeout value using struct timespec. -Once this is done the process waits on a signal for a specified time period -using thesigtimedwait() method. If the signal is not received -within the specified time period, an error message is generated.

For -the demonstration of this use case we are setting a timeout of 5 seconds. -The SIGALRM signal is raised by a call to alarm() as -and when the timer expires. There are two instances in the example where SIGALRM signal -is raised, one after a duration of 4 seconds and one after 6 seconds. When SIGALRM is -raised after 4 seconds, it is well within the timeout limit (of 5 seconds) -and hence the signal gets received but not handled. But when the alarm is -raised after 6 seconds, timeout happens and an error is generated. Now as -the SIGALRM signal was added to the mask set it never gets -handled even though it is received. To handle the signal we need to move it -from block state to unblock state, which we do using the sigprocmask() method. -Once the signal gets unblocked its custom handler gets called.

6. -Generating and handling a SIGPIPE signal

The - SIGPIPE signal is generated when writing to a broken pipe. -To achieve this broken pipe condition the read end of the pipe (obtained using -the pipe() function call) is closed and then write to the -pipe is done. The associated handler function is executed in response to the -raised SIGPIPE signal .

7. Using a signal to gracefully -terminate a process

Graceful termination of process can be achieved -by using the SIGTERM signal. In the handler function of the -signal all the opened file descriptors need to be closed before exiting.

This -use case is demonstrated using the sigtermSignal project. -The project consists of two processes: the sigtermsignal process -and the raisesignal process.

    -

  • The sigtermsignal process -first defines a custom handler for the SIGTERM signal that -carries out the closing of all the open file descriptors when the signal is -raised. This is done in order to achieve the graceful termination of the process. -The sigtermsignal process then opens a file and obtains -names from user to be written in to it. It then simultaneously spawns a raisesignal process -and starts reading from the file. When the raisesignal process -sends a SIGTERM signal to the sigtermsignal process, -the sigtermsignal process closes all the open file descriptors -and prepares to exit.

    • -

  • The raisesignal process -sends the SIGTERM signal to the sigtermsignal process. -The custom handler of the SIGTERM signal takes care of properly -closing all opened file descriptors and then terminating the process. If the -custom handler is not implemented, the default handler will get called, which -will result in process termination without closing any opened file descriptors.

    • -

8. Using a signal to handle an asynchronous event

The -SIGUSR1 and SIGUSR2 signals are used to demonstrate -the handling of an asynchronous event. These signals are sent from one process -to another. On reception of these signals, respective custom handlers are -called and any necessary action is taken. The action taken is purely implementation -dependent .

This use case demonstration is performed using the asyncSignal project. -The project consists of two processes: the sigusr1 process -and the sigusr2 process, where the sigusr1 process -handles the SIGUSR1 signal and sends the SIGUSR2 signal -to the sigusr2 process. Whereas the sigusr2 process -handles the SIGUSR2 signal and sends the SIGUSR1 signal -to the sigusr1 process.

    -

  • The sigusr1 process -assigns a custom handler for the SIGUSR1 signal. It then -opens a file in read and write mode and write some content into the open file. -Once write operation is done the sigusr1 process spawns sigusr2 process -and waits for SIGUSR1 signal from sigusr2 process. -On receiving SIGUSR1 signal sigusr1 process -starts reading from the file. Once reading from the file is done and its contents -are displayed on the console, sigusr1 process sends SIGUSR2 signal -to sigusr2 process. It then closes all its open file -descriptor and prepares to exit.

    • -

  • The sigusr2 process -is spawned from sigusr1 process and it assigns a custom -handler for SIGUSR2 signal. It sends SIGUSR1 signal -to sigusr1 process in order to start file read and then -waits for SIGUSR2 signal from sigusr1 process. -When sigusr2 process receives SIGUSR2 signal -it prepares to exit.

    • -

Hence, the communication between the two processes happens through -the SIGUSR1 and SIGUSR2 signals and asynchronous -signal handling happens.

-
Download

Click -on the following link to download the example: BasicSignals.zip

Click on the following link -to download the example: SigtermSignal.zip

Click on the following link -to download the example: AsyncSignal.zip

To view the BasicSignal -example source click: browseBasicSignals

To view the SigtermSignal example -source click: browseSigtermSignal

To view the AsyncSignal example -source click: browseAsyncSignal

-
Building and -configuring

You can build the example from your IDE or the command -line:

    -

  • If you use an -IDE, import the bld.inf file of the example into your -IDE, and use the build command of the IDE.

    • -

  • If you use the command line, open a command prompt, and set the current -directory to the source code directory of the example. You can then build -the example with the SBSv1 build tools using the following commands:

      -

    • bldmake bldfiles

      • -

    • abld build

      • -

    How to use -bldmake and How -to use abld describe how to use the SBSv1 build tools.

    • -

The example builds the following executables :

    -

  • basicsignals.exe : for basic signal use cases -demonstration.

    • -

  • sigtermsignal.exe : for demonstrating graceful -termination of process .

    • -

  • raisesignal.exe : for sending SIGTERM signal.

    • -

  • sigusr1.exe : for demonstrating asynchronous event -handling , sending SIGUSR2 signal and receiving SIGUSR1 signal.

    • -

  • sigusr2.exe : for sending SIGUSR1 signal -and receiving SIGUSR2 signal.

    • -

in the epoc32\release\winscw\<udeb or urel>\ folder.

-
Running the -example

NOTE :

basicsignals.exe should -be executed first for running the first six uses cases mentioned above.

sigtermsignal.exe should -be executed for running the seventh use case.

sigusr1.exe should -be executed for running the last use case.

The sigtermsignal process -internally spawns the raisesignal process for taking -an input from the user and sending the SIGTERM signal. You -should not run the raisesignal process explicitly. You -should only run sigtermsignal.exe as the sigtermsignal process -takes proper care of launching the raisesignal process.

The sigusr1 process -also internally spawns the sigusr2 process.

The sigusr1 process -sends the SIGUSR2 signal to the sigusr2 process -and receives the SIGUSR1 signal from it.

The sigusr2 process -sends the SIGUSR1 signal to the sigusr1 process -and receives the SIGUSR2 signal from it.

As the sigusr1 process -spawns the sigusr2 process, hence you should run sigusr1.exe only.

In -order to toggle between the processes use Alt+ctrl+shift+T and -observe the behavior.

+ + + + + +posixsignals: POSIX Signal Example, Using P.I.P.S.This example demonstrates various signal use cases as supported +in P.I.P.S. +
Purpose

The example demonstrates the following use cases:

    +

  1. Sending and +handling a signal using the default handler

    2. +

  2. Sending and +handling a signal using a customized signal handler

    3. +

  3. Ignoring an +incoming signal

    4. +

  4. Blocking and +releasing a signal

    5. +

  5. Waiting for +a signal

    6. +

  6. Generating and +handling a SIGPIPE signal

    7. +

  7. Using a signal +to gracefully terminate a process

    8. +

  8. Using a signal +to handle an asynchronous event

    9. +

The example delivers 3 sub projects:

    +

  • basicSignals: This project demonstrates basic signal use cases. It shows the first +six use cases mentioned in the list above. The use cases are demonstrated +through basicsignals.exe.

    • +

  • sigtermSignal: This project demonstrates the graceful termination of a process +using the SIGTERM signal. The use case is demonstrated +through sigtermsignal.exe and raisesignal.exe.

    • +

  • asyncSignal: This project demonstrates asynchronous signal handling using the SIGUSR1 signal and the SIGUSR2 signal. +The use case is demonstrated using sigusr1.exe and sigusr2.exe.

    • +
+
Description

The use cases demonstrated in this example are described below.

Note: For clarity in the documentation for this example, signal +names have been given in capitals whilst process names have been given +in lower case.

1. Sending and handling a signal using the +default handler

The default implementation of the signals +supported in P.I.P.S. will either terminate a process or ignore a +process. Signals are generated using the Kill() method +and they are handled as per the implementation in the default handler.

To demonstrate this use case we use SIGCHLD and SIGALRM signals. SIGCHLD by default gets +ignored whenever it is raised, whereas SIGALRM causes +a process termination when raised. As a result the example terminates +whenever SIGALRM is raised, whereas an info message +is printed when SIGCHLD is raised.

2. +Sending and handling a signal using a customized signal handler

To override the default implementation of a signal a customized +handler can be defined. This customized handler can be set either +by using sigaction() or signal(). The sigaction() method takes struct sigaction as one of its parameters (the sa_handler member +of this structure is filled with the custom handler). Now whenever +a signal is generated the custom handler is executed.

For +the demonstration of this particular use case, SIGCHLD and SIGALRM signals are used. These signals are +assigned custom handler functions. The handlers for these signals +contains a simple user message. Thus, whenever the signals are raised, +the customized signal handlers get invoked instead of the default +handlers.

3. Ignoring an incoming signal

A +signal can be ignored by setting SIG_IGN in the sa_handler member of struct sigaction. +The demonstration of this use case also uses SIGCHLD and SIGALRM signals, and as a result of setting SIG_IGN in sa_handler the signals are ignored +when raised.

4. Blocking and releasing a signal

A signal can be blocked by first adding it to the blocking set +(a list of signals we want to block, when a signal is executing) by +using the sigaddset() method and then calling the sigprocmask() function. Once a signal is blocked it will +always be ignored upon generation. The sigrelse() method is used to unblock a signal.

Demonstration of this +use case involves the SIGUSR1 and SIGUSR2 signals. Both SIGUSR1 and SIGUSR2 are user-defined signals. We first block the SIGUSR1 signal by adding it to the blocking set and making a call to the sigprocmask() function. Now whenever SIGUSR1 is raised it will get ignored as it is blocked. SIGUSR1 will keep waiting in the pending queue until it is released. The +release of SIGUSR1 happens in the SIGUSR2 signal handler. Once SIGUSR1 is released, it is +removed from the pending queue and its handler function is called +to handle it.

5. Waiting for a signal

Before +a process can wait on a particular signal, it has to add the signal +to the mask set (which is a list of signals we want to block) and +then call the sigprocmask() method. The process then +sets the timeout value using struct timespec. Once +this is done the process waits on a signal for a specified time period +using thesigtimedwait() method. If the signal is +not received within the specified time period, an error message is +generated.

For the demonstration of this use case we are setting +a timeout of 5 seconds. The SIGALRM signal is raised +by a call to alarm() as and when the timer expires. +There are two instances in the example where SIGALRM signal is raised, one after a duration of 4 seconds and one after +6 seconds. When SIGALRM is raised after 4 seconds, +it is well within the timeout limit (of 5 seconds) and hence the signal +gets received but not handled. But when the alarm is raised after +6 seconds, timeout happens and an error is generated. Now as the SIGALRM signal was added to the mask set it never gets handled +even though it is received. To handle the signal we need to move it +from block state to unblock state, which we do using the sigprocmask() method. Once the signal gets unblocked its custom handler gets called.

6. Generating and handling a SIGPIPE signal

The SIGPIPE signal is generated when writing +to a broken pipe. To achieve this broken pipe condition the read end +of the pipe (obtained using the pipe() function +call) is closed and then write to the pipe is done. The associated +handler function is executed in response to the raised SIGPIPE signal .

7. Using a signal to gracefully terminate a +process

Graceful termination of process can be achieved +by using the SIGTERM signal. In the handler function +of the signal all the opened file descriptors need to be closed before +exiting.

This use case is demonstrated using the sigtermSignal project. The project consists of two processes: +the sigtermsignal process and the raisesignal process.

    +

  • The sigtermsignal process first defines a custom handler for +the SIGTERM signal that carries out the closing of +all the open file descriptors when the signal is raised. This is done +in order to achieve the graceful termination of the process. The sigtermsignal process then opens a file and obtains names +from user to be written in to it. It then simultaneously spawns a raisesignal process and starts reading from the file. +When the raisesignal process sends a SIGTERM signal to the sigtermsignal process, the sigtermsignal process closes all +the open file descriptors and prepares to exit.

    • +

  • The raisesignal process sends the SIGTERM signal to the sigtermsignal process. The custom +handler of the SIGTERM signal takes care of properly +closing all opened file descriptors and then terminating the process. +If the custom handler is not implemented, the default handler will +get called, which will result in process termination without closing +any opened file descriptors.

    • +

8. Using a signal to handle an asynchronous event

The SIGUSR1 and SIGUSR2 signals are used to demonstrate the handling of an asynchronous +event. These signals are sent from one process to another. On reception +of these signals, respective custom handlers are called and any necessary +action is taken. The action taken is purely implementation dependent +.

This use case demonstration is performed using the asyncSignal project. The project consists of two processes: +the sigusr1 process and the sigusr2 process, where the sigusr1 process handles +the SIGUSR1 signal and sends the SIGUSR2 signal to the sigusr2 process. Whereas the sigusr2 process handles the SIGUSR2 signal +and sends the SIGUSR1 signal to the sigusr1 process.

    +

  • The sigusr1 process assigns a custom handler for the SIGUSR1 signal. It then opens a file in read and write mode +and write some content into the open file. Once write operation is +done the sigusr1 process spawns sigusr2 process and waits for SIGUSR1 signal from sigusr2 process. On receiving SIGUSR1 signal sigusr1 process starts reading from +the file. Once reading from the file is done and its contents are +displayed on the console, sigusr1 process sends SIGUSR2 signal to sigusr2 process. +It then closes all its open file descriptor and prepares to exit.

    • +

  • The sigusr2 process is spawned from sigusr1 process and it assigns a custom handler for SIGUSR2 signal. It sends SIGUSR1 signal to sigusr1 process in order to start file read and then waits for SIGUSR2 signal from sigusr1 process. When sigusr2 process receives SIGUSR2 signal +it prepares to exit.

    • +

Hence, the communication between the two processes happens +through the SIGUSR1 and SIGUSR2 signals +and asynchronous signal handling happens.

+
Download

Click on the following link to download the example: BasicSignals.zip

Click on the following +link to download the example: SigtermSignal.zip

Click on the following +link to download the example: AsyncSignal.zip

To view the BasicSignal +example source click: browseBasicSignals

To view the SigtermSignal +example source click: browseSigtermSignal

To view the AsyncSignal +example source click: browseAsyncSignal

+
Building +and configuring

You can build the example from your IDE +or the command line:

    +

  • If you +use an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

    • +

  • If you use the command line, open a command prompt, and set +the current directory to the source code directory of the example. +You can then build the example with the SBSv1 build tools using the +following commands:

      +

    • bldmake bldfiles

      • +

    • abld build

      • +
    • +

The example builds the following executables :

    +

  • basicsignals.exe : for basic signal use +cases demonstration.

    • +

  • sigtermsignal.exe : for demonstrating +graceful termination of process .

    • +

  • raisesignal.exe : for sending SIGTERM signal.

    • +

  • sigusr1.exe : for demonstrating asynchronous +event handling , sending SIGUSR2 signal and receiving SIGUSR1 signal.

    • +

  • sigusr2.exe : for sending SIGUSR1 signal and receiving SIGUSR2 signal.

    • +

in the epoc32\release\winscw\<udeb or urel>\ folder.

+
Running +the example

NOTE :

basicsignals.exe should be executed first for running the first six uses cases mentioned +above.

sigtermsignal.exe should be executed +for running the seventh use case.

sigusr1.exe should be executed for running the last use case.

The sigtermsignal process internally spawns the raisesignal process for taking an input from the user and sending the SIGTERM signal. You should not run the raisesignal process explicitly. You should only run sigtermsignal.exe as the sigtermsignal process takes proper care +of launching the raisesignal process.

The sigusr1 process also internally spawns the sigusr2 process.

The sigusr1 process sends the SIGUSR2 signal to the sigusr2 process and receives the SIGUSR1 signal from it.

The sigusr2 process +sends the SIGUSR1 signal to the sigusr1 process and receives the SIGUSR2 signal from it.

As the sigusr1 process spawns the sigusr2 process, hence you should run sigusr1.exe only.

In order to toggle between the processes use Alt+ctrl+shift+T and observe the behavior.

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-301488F8-B6D8-569A-B05E-19B740FE4C00.dita --- a/Symbian3/SDK/Source/GUID-301488F8-B6D8-569A-B05E-19B740FE4C00.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-301488F8-B6D8-569A-B05E-19B740FE4C00.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,28 +34,28 @@ About Remote Devices , discusses in detail how to go about this.

Where Next?

This tutorial set takes you through all the steps involved in setting up and communicating over a Bluetooth connection.

    -

  • Selecting a Remote +

  • Selecting a Remote Device - This document

    • -

  • Inquiring +

  • Inquiring About Remote Devices

    • -

  • Inquiring +

  • Inquiring About Services on a Remote Device

    • -

  • Connecting +

  • Connecting and Transferring Data to a Remote Device

    • -

  • Using +

  • Using security on outgoing sockets

Where Next?

This tutorial set takes you through all the steps involved in setting up and communicating over a Bluetooth connection.

    -

  • Selecting a Remote +

  • Selecting a Remote Device - This document

    • -

  • Inquiring +

  • Inquiring About Remote Devices

    • -

  • Inquiring +

  • Inquiring About Services on a Remote Device

    • -

  • Connecting +

  • Connecting and Transferring Data to a Remote Device

    • -

  • Using +

  • Using security on outgoing sockets

\ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-301E5FAA-A1C3-4FD7-9D84-DAA61C66981B.dita --- a/Symbian3/SDK/Source/GUID-301E5FAA-A1C3-4FD7-9D84-DAA61C66981B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-301E5FAA-A1C3-4FD7-9D84-DAA61C66981B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,267 +9,261 @@ --> -Symbian -C++ Quick StartThis Quick Start is relevant if you want to create Symbian C++ -applications that run on Symbian devices - i.e. "on top" of the Symbian platform. -Typically this will include: professional application and games developers, -professional service companies, hobbyist developers and students. -

The tutorial shows you how to get the development tools (e.g. IDE) and -set up your development environment. It then shows you how to create a skeleton -application using Carbide.c++ and UI designer, and how to get it up and running -on both the Symbian Emulator and on the device; the whole process -takes just a few minutes!

+Symbian C++ Quick StartThis Quick Start is relevant if you want to create Symbian +C++ applications that run on Symbian devices - i.e. "on top" of the +Symbian platform. Typically this will include: professional application +and games developers, professional service companies, hobbyist developers +and students. +

The tutorial shows you how to get the development tools (e.g. IDE) +and set up your development environment. It then shows you how to +create a skeleton application using Carbide.c++ and UI designer, and +how to get it up and running on both the Symbian Emulator and on the device; the whole +process takes just a few minutes!

Comes with Code: File: HelloSymbianWorld Example Code.zip

-
Set -up the development environment

Assuming your computer meets -the System Requirements then setting up your PC for Symbian -C++ development is as simple as downloading and installing (do so in this -order):

    -

  1. Perl. See the Kits Q&As for notes on the recommended version.

    2. +
    Set up the development environment

    Assuming your +computer meets the System Requirements then setting up your PC +for Symbian C++ development is as simple as downloading and installing +(do so in this order):

      +

    1. Perl. See the Kits Q&As for notes on the recommended +version.

    2. Application Developer Toolkit (ADT).

    3. Software Developer Kit (SDK) (full installation) .

      4. -

    For help installing the SDK please refer to the Symbian^1 SDK Installation Guide.

    You can now -create your first application using the Carbide.c++ project wizard, as the -following sections will describe.

    -
    Starting Carbide.c++

    The -Carbide.c++ IDE is installed as part of the free Application Developer Toolkit (ADT) (step 2 in the -section above). It is the only supported/official IDE for Symbian C++ development. -

    Carbide.c++ is launched from the Windows Start button: All -Programs | Symbian Foundation ADT v<ADTVersion> | Carbide.c++ -| Carbide.++ v<CarbideVersion>.

    On start, you will be -prompted to select a workspace directory. The workspace directory contains -any projects you’ve already created in the workspace and their common settings -- such as code-formatting options (you can define multiple workspaces in order -to separate completely different tasks). If this is the first time you've -run Carbide.c++ the workspace will be empty.

    Your Symbian projects -must be on the drive where you installed your SDK. You must also ensure that -the path name of the workspace does not contain non-alphanumeric characters -or spaces. This is because the Symbian toolchain uses command line tools that -cannot read special path names.

    If you installed the SDK to drive C:\, -an example of a correct workspace path is: C:\Symbian\development\.

    - -

    Once Carbide.c++ has started, close the Welcome tab (by clicking -the cross shown circled in red below) to see the default workspace.

    - +

For help installing the SDK please refer to the Symbian^1 SDK Installation Guide.

You +can now create your first application using the Carbide.c++ project +wizard, as the following sections will describe.

+
Starting +Carbide.c++

The Carbide.c++ IDE is installed as part of +the free Application Developer Toolkit (ADT) (step +2 in the section above). It is the only supported/official IDE for +Symbian C++ development.

Carbide.c++ is launched from the +Windows Start button: All Programs | Symbian Foundation +ADT v<ADTVersion> | Carbide.c++ | Carbide.++ v<CarbideVersion>.

On start, you will be prompted +to select a workspace directory. The workspace directory contains +any projects you’ve already created in the workspace and their common +settings - such as code-formatting options (you can define multiple +workspaces in order to separate completely different tasks). If this +is the first time you've run Carbide.c++ the workspace will be empty.

Your Symbian projects must be on the drive where you installed +your SDK. You must also ensure that the path name of the workspace +does not contain non-alphanumeric characters or spaces. This is because +the Symbian toolchain uses command line tools that cannot read special +path names.

If you installed the SDK to drive C:\, an example of a correct workspace path is: C:\Symbian\development\.

+ +

Once Carbide.c++ has started, close the Welcome tab (by clicking the cross shown circled in red below) to see the default +workspace.

+
Creating -a Project

To launch the Carbide.c++ Create New Project Wizard select: File -| New | Symbian OS C++ Project.

Choose the GUI Application with -UI Designer application template (see S60 section). This template creates -a runnable GUI application with the UI Designer tool enabled (the UI -Designer allows views to be created "visually" by drag & dropping -standard UI components).

- -

The Next page of the wizard is "New Symbian OS C++ Project". -Define the project name - in this case "HelloWorld". Once again, make sure -the project directory is on the same drive as the SDK and does not contain -spaces or other special characters.

- -

The Next page of the wizard is "Symbian OS SDKs". Choose -the SDK(s) you want to use for building the project from among those installed -to your PC (You can add more SDKs to your project later on). This should include -a Symbian platform SDK. At time of writing the only -C++ Application Development SDK is the Symbian^1 SDK (Note: this is -a copy of the S60 5th Edition SDK v1.0).

- -

By default all build configurations will be selected:

    +a Project

    To launch the Carbide.c++ Create New Project +Wizard select: File | New | Symbian OS C++ Project.

    Choose the GUI Application with UI Designer application +template (see S60 section). This template creates a runnable GUI application +with the UI Designer tool enabled (the UI Designer allows +views to be created "visually" by drag & dropping standard UI +components).

    + +

    The Next page of the wizard is "New Symbian OS +C++ Project". Define the project name - in this case "HelloWorld". +Once again, make sure the project directory is on the same drive as +the SDK and does not contain spaces or other special characters.

    + +

    The Next page of the wizard is "Symbian OS SDKs". Choose the SDK(s) you want to use for building the project from +among those installed to your PC (You can add more SDKs to your project +later on). This should include a Symbian platform SDK. At time of writing the +only C++ Application Development SDK is the Symbian^1 SDK (Note: this is a copy of the S60 5th Edition SDK v1.0).

    + +

    By default all build configurations will be selected: +

    • Emulator Debug (WINSCW) builds binaries for the Windows-hosted emulator.

      • -

    • Phone Debug | Release (GCCE) builds binaries for the phone using -the (free) GCCE compiler that was installed with the SDK.

      • -

    • Phone Debug | Release (ARMV5) builds binaries for the phone -using the ARM RealView Compiler (RVCT). RVCT produces code that -is a few percent smaller and faster than the current versions of GCCE supported -for Symbian C++ development, but must be separately licensed from ARM. RVCT -is primarily used by phone manufacturers to build binaries for device ROM.

      • -

    Most developers should simply de-select the ARMV5 options above as -shown (the Emulator is needed by all developers, and GCCE is sufficient for -most third-party development).

    The Next page of the wizard -sets the "Application properties".

    - -

    Keep the default values. The Baseline SDK defines the common -compatibility level of your application. For example, if set to the S60 -5th Edition SDK, the UI designer doesn’t let you add elements that are -only available in later S60 5th Edition, Feature Pack 1+ SDKs and devices. -

    The Next page of the wizard allows you to choose an S60 UI -design. Keep the Empty user interface variant.

    The Next page -of the wizard "Container Name and Type" has default values that are -usually acceptable.

    The Finish button is active -in this page. The next page is optional but for the purposes of this tutorial -you should click Next, rather than Finish.

    - -

    Even though our application will only use one view, it’s usually -better to check "Support View Switching", in order to make the application -easier to extend later on.

    The Next page of the wizard "Basic -Settings" can be used to customize the project with your name and a copyright -notice for every human-readable file. It also allows you to specify the application -unique identifier (UID).

    - -

    The UID (actually the SID, but for the moment we can ignore the distinction) -defines the private area in the file system in which the application can store -its data. Among other things the UID can also be used to programmatically -identify and/or start the application.

    Carbide.c++ generates -a random UID value for you starting with ‘0xE’, which is the range of UIDs -reserved for internal development and testing. If you want to release your -application to the public, you need to get your own unique UID allocated by Symbian Signed. -

    As we do not intend to release our Hello World application to the -public, we’ll simply continue to use the value Carbide.c++ assigned us from -the development range (you can change the UID later on, although you must -be careful to change every instance of it found within your project - see How to change your application's UID).

    Select Finish to -close the wizard and create your application (there is no need to go to the Next (last) -page of the wizard as the default values are always acceptable).

    That's -it, your workspace should look similar to the screenshot below.

    - +

  • Phone Debug | Release (GCCE) builds binaries for the +phone using the (free) GCCE compiler that was installed with the SDK.

    • +

  • Phone Debug | Release (ARMV5) builds binaries for the +phone using the ARM RealView Compiler (RVCT). RVCT produces +code that is a few percent smaller and faster than the current versions +of GCCE supported for Symbian C++ development, but must be separately +licensed from ARM. RVCT is primarily used by phone manufacturers to +build binaries for device ROM.

    • +

Most developers should simply de-select the ARMV5 options +above as shown (the Emulator is needed by all developers, and GCCE +is sufficient for most third-party development).

The Next page of the wizard sets the "Application properties".

+ +

Keep the default values. The Baseline SDK defines +the common compatibility level of your application. For example, if +set to the S60 5th Edition SDK, the UI designer doesn’t let +you add elements that are only available in later S60 5th Edition, +Feature Pack 1+ SDKs and devices.

The Next page of +the wizard allows you to choose an S60 UI design. Keep the Empty user interface variant.

The Next page of the wizard +"Container Name and Type" has default values that are usually +acceptable.

The Finish button is active +in this page. The next page is optional but for the purposes of this +tutorial you should click Next, rather than Finish. +

+ +

Even though our application will only use one view, it’s +usually better to check "Support View Switching", in order to make +the application easier to extend later on.

The Next page of the wizard "Basic Settings" can be used to customize +the project with your name and a copyright notice for every human-readable +file. It also allows you to specify the application unique identifier +(UID).

+ +

The UID (actually the SID, but for the moment we can ignore the +distinction) defines the private area in the file system in which +the application can store its data. Among other things the UID can +also be used to programmatically identify and/or start the application.

Carbide.c++ +generates a random UID value for you starting with ‘0xE’, which is +the range of UIDs reserved for internal development and testing. If +you want to release your application to the public, you need to get +your own unique UID allocated by Symbian Signed.

As we do not intend to release our Hello World application +to the public, we’ll simply continue to use the value Carbide.c++ +assigned us from the development range (you can change the UID later +on, although you must be careful to change every instance of it found +within your project - see How to change your application's UID).

Select Finish to close the wizard and create your application +(there is no need to go to the Next (last) page of the wizard +as the default values are always acceptable).

That's it, your +workspace should look similar to the screenshot below.

+
Targeting the Emulator

Normally you'll start by building for the emulator; -you can use the emulator for most of your development work (it is possible -to access the Internet through the emulator, and even simulate GPS).

Building -for the Emulator

    -

  • First set the active build configuration. You can do this by clicking -the Manage configurations for the current project icon - in the toolbar or by selecting menu: Project | Build Configurations -| Set Active and select Emulator Debug.

    • +you can use the emulator for most of your development work (it is +possible to access the Internet through the emulator, and even simulate +GPS).

    Building for the Emulator

      +

    • First set the active build configuration. You can do this by +clicking the Manage configurations for the current project icon in the toolbar +or by selecting menu: Project | Build Configurations | Set Active and select Emulator Debug.

    - +
      -

    • Then build the current configuration using the Build icon in the toolbar or -through the menu: Project | Build Project (You can also select a particular -configuration to build from the Build icon selector).

      • -

    Warning: If you get an error message similar to "WARNING: EPOCROOT -does not specify an existing directory", you did not place your workspace/project -on the same drive as the application development SDK (which is installed by -default to C:\). Delete the project and start again. The diagram shows how -this might appear in Carbide.c++:

    - -

    Running on the Emulator

    If your application built -successfully, click on the Run button - (Ctrl + F11). Upon the first launch of your project, Carbide.c++ -will ask you which executable you want to launch:

    - +

  • Then build the current configuration using the Build icon in the toolbar or through the menu: Project | Build Project (You can also select a particular configuration to build from the +Build icon selector).

    • +

Warning: If you get an error message similar to "WARNING: +EPOCROOT does not specify an existing directory", you did not place +your workspace/project on the same drive as the application development +SDK (which is installed by default to C:\). Delete the project and +start again. The diagram shows how this might appear in Carbide.c++:

+ +

Running on the Emulator

If your application +built successfully, click on the Run button (Ctrl + +F11). Upon the first launch of your project, Carbide.c++ will ask +you which executable you want to launch:

+

  • If you choose HelloWorld.exe, the emulator will be launched -and your application started automatically. The emulator will close once you -exit your application.

    • -

  • If you choose Emulator the emulator (epoc.exe) will be launched -and you will need to navigate to the application and start it by clicking -on the icon (just as you do when starting an application on a device). We’ll -explain how to find the application shortly.

    • -

It may sound more difficult to choose the second method, but it has -some advantages. You can leave the emulator running if you are only doing -small edits in your source code – simply close your application in the emulator, -recompile and restart your app through the emulator’s menu. You’ll also see -any error messages that may be shown when you exit the application, because -the emulator will not shut down instantly after you exit Hello World in the -emulator. Those error messages are also visible in Carbide.c++’s console window. -

When the emulator starts for the first time you might have to wait -for several minutes before it is completely ready for use. Successive starts -will be a lot faster, because Windows caches most of the emulator DLLs.

- -

If you decide to launch the emulator and navigate to your application: First, -open the menu through the S60 menu symbol on the bottom left of the -screen. Your own application will be located at the bottom of the Applications folder; -use your mouse to navigate in the emulator’s menus.

When you launch -your application, the main pane will be empty. As you can see, the example -application the wizard has created already supports a full user interface -and handles input from the left and right softkeys at the bottom of the screen.

- -

Debugging on the Emulator

The Emulator is the -default debug target - you simply click the Debug button -.

Debugging on the Emulator is not covered further in this -tutorial. See Carbide.c++ User Guide > Debugging projects for extensive +and your application started automatically. The emulator will close +once you exit your application.

+

  • If you choose Emulator the emulator (epoc.exe) will +be launched and you will need to navigate to the application and start +it by clicking on the icon (just as you do when starting an application +on a device). We’ll explain how to find the application shortly.

    • +

    It may sound more difficult to choose the second method, but +it has some advantages. You can leave the emulator running if you +are only doing small edits in your source code – simply close your +application in the emulator, recompile and restart your app through +the emulator’s menu. You’ll also see any error messages that may be +shown when you exit the application, because the emulator will not +shut down instantly after you exit Hello World in the emulator. Those +error messages are also visible in Carbide.c++’s console window.

    When the emulator starts for the first time you might have to +wait for several minutes before it is completely ready for use. Successive +starts will be a lot faster, because Windows caches most of the emulator +DLLs.

    + +

    If you decide to launch the emulator and navigate to your +application: First, open the menu through the S60 menu +symbol on the bottom left of the screen. Your own application will +be located at the bottom of the Applications folder; use your +mouse to navigate in the emulator’s menus.

    When you launch +your application, the main pane will be empty. As you can see, the +example application the wizard has created already supports a full +user interface and handles input from the left and right softkeys +at the bottom of the screen.

    + +

    Debugging on the Emulator

    The Emulator +is the default debug target - you simply click the Debug button .

    Debugging on the Emulator is not covered further in this tutorial. +See Carbide.c++ User Guide > Debugging projects for extensive information on debugging using Carbide.c++.

    -
    Targeting the -Device

    The emulator can be used for most of your development work. -However, some situations still require a real device – for example, when you -want to use the camera or the acceleration sensor.

    Tip: You -should test your applications on the phone from time to time, even if it is -fully supported by the emulator.

    When you've finished development, -you'll also want to build a release version; stripping out debug code and -symbol information to make your binaries smaller and more efficient.

    Building -for the Device

    To tell the IDE that you want to build for the device, -change the active build configuration to a phone-release configuration for -GCCE (unless you have the RVCT compiler). As before, use the Manage configurations -for current project toolbar icon ( -) to select the active-build configuration.

    - -

    Next, choose to build the current configuration using the toolbar Build icon (or in the menu: Project -| Build Project).

    This will automatically compile the project -using the GCCE compiler and create an installation package – a file called HelloWorld.sisx in -your project's \HelloWorld\sis\ directory. You now need to -transfer this file to your phone to install it.

    Tip: Use -Carbide.c++ to find the file on your PC. Navigate to the file in the project -view, then right-click on it and select Show in Explorer.

    Don’t -forget to switch back to the Emulator Debug build configuration when -you continue development!

    Installing on the Device

    -You can use the PC Suite that came with your phone to install the application -on your device

      +
      Targeting +the Device

      The emulator can be used for most of your development +work. However, some situations still require a real device – for example, +when you want to use the camera or the acceleration sensor.

      Tip: You should test your applications on the phone from +time to time, even if it is fully supported by the emulator.

      When you've finished development, you'll also want to build a +release version; stripping out debug code and symbol information to +make your binaries smaller and more efficient.

      Building +for the Device

      To tell the IDE that you want to build for +the device, change the active build configuration to a phone-release +configuration for GCCE (unless you have the RVCT compiler). As before, use the Manage +configurations for current project toolbar icon () to select +the active-build configuration.

      + +

      Next, choose to build the current configuration using the +toolbar Build icon (or in the +menu: Project | Build Project).

      This will automatically +compile the project using the GCCE compiler and create an installation +package – a file called HelloWorld.sisx in your project's \HelloWorld\sis\ directory. You now need to transfer this +file to your phone to install it.

      Tip: Use Carbide.c++ +to find the file on your PC. Navigate to the file in the project view, +then right-click on it and select Show in Explorer.

      Don’t forget to switch back to the Emulator Debug build +configuration when you continue development!

      Installing +on the Device

      You can use the PC Suite that came with +your phone to install the application on your device

      • Ensure that the PC Suite is installed and running

        • -

      • Connect your device to the PC via Bluetooth or USB and add the phone -to the known devices in the PC Suite (if necessary).

        • -

      • Double-click the .sisx file in Windows Explorer or -the Project Explorer window of Carbide.c++.

        • -

      If the PC Suite is not installed on your PC, you can send the file -to the phone via Bluetooth or IrDA (if available):

        +

      • Connect your device to the PC via Bluetooth or USB and add +the phone to the known devices in the PC Suite (if necessary).

        • +

      • Double-click the .sisx file in Windows Explorer +or the Project Explorer window of Carbide.c++.

        • +

      If the PC Suite is not installed on your PC, you can send +the file to the phone via Bluetooth or IrDA (if available):

      • Locate the .sisx file in Windows Explorer

      • Right-click on it and select Send to | Bluetooth device.

        • -

      You will be prompted to install the application when you open the -message.

      Warning: If you get a Certificate -Error message when you try to install the application, then your -phone has been configured to prevent installation of self-signed sis files. -To change this behavior, go to Settings - Application manager - Installation -settings - Software installation and change the setting from Signed -Only to All. For other errors received upon installation, consult -the installation -error troubleshooting guide.

      Debugging on the Device

      -Debugging on a production phone is covered in the topic: Getting Started with Debugging on the Device.

      -
      Building on -the Command Line

      It is also possible to build your applications -using the command-line based Symbian toolchain. If you've never done so before -you will first need to set up the environment using the tool provided:

        -

      • Select the windows start button and select: Start | All Programs -| Symbian Foundation ADT v1.0 | Carbide.c++ | Configure environment for WINSCW -command line

        • -

      Open a command prompt in your project's /group/ folder (where the -bld.inf project file is located) and do:

      bldmake bldfiles -abld build

      The command bldmake bldfiles creates -a batch file abld.bat based on the component-definition file -(bld.inf) and the project-definition file(s) (.mmp). -The abld build command uses the batch file to build all the -default targets (i.e. for gcce and Emulator).

      You can build just one -target using

      abld build <target>

      For -example, "abld build winscw udeb" builds just the emulator -debug variant.

      You can start the emulator by selecting its executable -in your file system (it will be located at SDK DIRECTORY\epoc32\release\winscw\udeb\epoc.exe). -

      An overview of the commands and the generated outputs is shown below. +

    You will be prompted to install the application when you open +the message.

    Warning: If you get a Certificate Error message when you try to install the +application, then your phone has been configured to prevent installation +of self-signed sis files. To change this behavior, go to Settings +- Application manager - Installation settings - Software installation and change the setting from Signed Only to All. For +other errors received upon installation, consult the installation error troubleshooting guide.

    Debugging on the Device

    Debugging on +a production phone is covered in the topic: Getting Started with Debugging on the Device.

    +
    Building +on the Command Line

    It is also possible to build your applications +using the command-line based Symbian toolchain. If you've never done +so before you will first need to set up the environment using the +tool provided:

      +

    • Select the windows start button and select: Start | All +Programs | Symbian Foundation ADT v1.0 | Carbide.c++ | Configure environment +for WINSCW command line

      • +

    Open a command prompt in your project's /group/ folder +(where the bld.inf project file is located) and do:

    bldmake bldfiles +abld build

    The command bldmake bldfiles creates a batch file abld.bat based on the component-definition +file (bld.inf) and the project-definition file(s) +(.mmp). The abld build command uses +the batch file to build all the default targets (i.e. for gcce +and Emulator).

    You can build just one target using

    abld build <target>

    For example, +"abld build winscw udeb" builds just the emulator +debug variant.

    You can start the emulator by selecting its +executable in your file system (it will be located at SDK +DIRECTORY\epoc32\release\winscw\udeb\epoc.exe).

    An +overview of the commands and the generated outputs is shown below. There is also extensive documentation on the build process in the Symbian Developer Library: Symbian OS build process.

    - +
    -
    Troubleshooting

    -For the vast majority of users the preceding instructions can be followed -through without issue. If however you have any build issues, then please follow -the following instructions to check that your environment is set up correctly and troubleshoot any problems that may arise.

    -
    Summary

    In -this tutorial you set up your development environment, learned how to create -a skeleton application using Carbide.c++ UI Designer, and how to get -it up and running on both the Symbian platform emulator and on the device. -

    In Going Beyond -Hello: A Tutorial for Symbian C++ Applications we will extend the basic -skeleton to create a small paint application, along the way learning more -about the application frameworks (e.g. defining menus, how to handle touch-screen -events, drawing to the screen etc.).

    -
    Related Info

    -Further reading:

      -

    • Going Beyond -Hello: A Tutorial for Symbian C++ Applications provides a step by step -guide to creating your first "real application", covering the key elements -of the application framework.

      • -

    • Fundamentals of Symbian C++ provides all the essential -information you need to understand Symbian C++.

      • +
      Troubleshooting

      For the vast majority of users the preceding instructions can +be followed through without issue. If however you have any build issues, +then please follow the following instructions to check that your environment is set up correctly and troubleshoot any problems that may arise.

      +
      Summary

      In this tutorial you set up your development environment, learned +how to create a skeleton application using Carbide.c++ UI Designer, and how to get it up and running on both the Symbian platform emulator +and on the device.

      In Going Beyond Hello: +A Tutorial for Symbian C++ Applications we will extend the +basic skeleton to create a small paint application, along the way +learning more about the application frameworks (e.g. defining menus, +how to handle touch-screen events, drawing to the screen etc.).

      +
      Related +Info

      Further reading:

        +

      • Going +Beyond Hello: A Tutorial for Symbian C++ Applications provides +a step by step guide to creating your first "real application", covering +the key elements of the application framework.

        • +

      • Fundamentals of Symbian C++ provides all the +essential information you need to understand Symbian C++.

      About the Kits:

        -

      • What -are the Kits? explains the ADT and SDK.

        • +

      • What are the Kits? explains the ADT and SDK.

      • Kits Q&As.

      • Getting Started with Debugging on the Device.

      • Symbian^1 SDK Release Notes.

        • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita --- a/Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,51 +9,53 @@ --> -ECom -Architecture -

        In C++, the existence of abstract base classes and virtual functions allows -the programs to call, or access interfaces without knowing the actual implementation. -This mechanism gives a flexibility of writing the implementation independent -of the interface. The implementations are known as Plug-ins.

        -

        When an application wishes to use a plug-in, an object is to be instantiated -to perform the required processing. The object specifics are not known until -run-time. The general characteristics of the processing are known, and these -are presented as an interface API.

        -

        In early versions of Symbian platform, implementations were provided by polymorphic interface DLLs. -All the frameworks within the Symbian platform that needed to use plug-ins -had to provide own mechanisms for the clients to discover and instantiate -the implementations. The above method resulted in duplication of functionality.

        -

        The Plug-in (ECom) Framework introduces a generic framework that provides -a single mechanism to:

        +ECom Architecture +

        In C++, the existence of abstract base classes and virtual functions +allows the programs to call, or access interfaces without knowing +the actual implementation. This mechanism gives a flexibility of writing +the implementation independent of the interface. The implementations +are known as Plug-ins.

        +

        When an application wishes to use a plug-in, an object is to be +instantiated to perform the required processing. The object specifics are not known until run-time. The general characteristics +of the processing are known, and these are presented as an interface +API.

        +

        In early versions of Symbian platform, implementations were provided +by polymorphic interface DLLs. All the frameworks within the Symbian +platform that needed to use plug-ins had to provide own mechanisms +for the clients to discover and instantiate the implementations. The +above method resulted in duplication of functionality.

        +

        The Plug-in (ECom) Framework introduces a generic framework that +provides a single mechanism to:

          -

        • Register and discover -interface implementations

          • +

        • Register and +discover interface implementations

        • Select an appropriate implementation

          • -

        • Provide version control -for plug-ins

          • +

        • Provide version +control for plug-ins

        -
        Essentials of a Plug-In System

        A client wishes -to access an object to perform some processing. The specifics of this object -are not known until run-time. The general characteristics of the processing -are known, and are defined in an interface, but several variants of required -processing could exist, which are provided by implementations that support -the interface.

        There are four clearly-defined roles in such a system.

          -

        • The Client that -wishes to access services.

          • -

        • The Interface API that -defines how to request services.

          • -

        • The Interface Implementation that -provides the required processing.

          • -

        • The Framework that -provides the clients with the required access to the implementations.

          • +
          Essentials +of a Plug-In System

          A client wishes to access an object +to perform some processing. The specifics of this object are not known +until run-time. The general characteristics of the processing are +known, and are defined in an interface, but several variants of required +processing could exist, which are provided by implementations that +support the interface.

          There are four clearly-defined roles +in such a system.

            +

          • The Client that wishes to access services.

            • +

          • The Interface +API that defines how to request services.

            • +

          • The Interface +Implementation that provides the required processing.

            • +

          • The Framework that provides the clients with the required access to the implementations.

          The relationships can be represented as follows:

          Plug-in relationships - -

          The instantiation mechanism forms the backbone of such a system, -and is responsible for providing the services that identify, and load the -correct interface implementation at run-time. ECom is such a framework.

          We'll -now look at the system from the perspectives in turn of each of the interface -client, interface implementation, and interface definition, before summarising -the functions of the ECom.

          + +

          The instantiation mechanism forms the backbone of such a +system, and is responsible for providing the services that identify, +and load the correct interface implementation at run-time. ECom is +such a framework.

          We'll now look at the system from the perspectives +in turn of each of the interface client, interface implementation, +and interface definition, before summarising the functions of the +ECom.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30382EFD-90D5-570C-A6CD-19D34360F329.dita --- a/Symbian3/SDK/Source/GUID-30382EFD-90D5-570C-A6CD-19D34360F329.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-30382EFD-90D5-570C-A6CD-19D34360F329.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,42 +9,31 @@ --> -GraphicsShell: -drawing and zoomingA TechView application that demonstrates drawing points, lines -and shapes, and zooming a bitmap and text. -
        Download

        Click on the following link to download -the example: GraphicsShell.zip

        Download some additional files -required by the example: CommonGraphicsExampleFiles

        Click: browse to view the example code.

        View the additional -files: browse.
        -
        Description

        GraphicsShell provides -an application shell, and two concrete controls.

        CGraphicExampleControl is -a control class, derived from CCoeControl, which links the -app shell to the particular controls.

        CDrawControl illustrates -the drawing of shapes in a window. The code draws points, lines and shapes; -this exercises a variety of drawing functions provided by the window graphics -context such as MoveTo(), DrawLineTo(), DrawArc() etc.

        CZoomControl illustrates -the use of zooming.

        -
        Class Summary

        TPoint

        TRectTSize

        CWindowGc

        TRgb

        CFont

        TFontSpec

        CWindowGc

        TZoomFactor

        MGraphicsDeviceMap

        CFbsBitmap

        -
        Build

        The source code for this example -application can be found in the directory:

        examples\Graphics\GraphicsShell

        This -source code may be in the directory in which you installed the Symbian platform, -or it may be in the src\common\developerlibrary\ directory. -The directory includes the two project files needed for building the example: bld.inf and -the .mmp file.

        The -Symbian build process describes how to build this application. For -the emulator, an application called GraphicsShell.exe is -created in epoc32\release\winscw\<udeb or urel>\.

        +GraphicsShell: drawing and zoomingA TechView application that demonstrates drawing points, +lines and shapes, and zooming a bitmap and text. +
        Download

        Click on the following link to download the example: GraphicsShell.zip

        Download some additional +files required by the example: CommonGraphicsExampleFiles

        Click: browse to view the example code.

        View the +additional files: browse.
        +
        Description

        GraphicsShell provides an application shell, +and two concrete controls.

        CGraphicExampleControl is a control class, derived from CCoeControl, which +links the app shell to the particular controls.

        CDrawControl illustrates the drawing of shapes in a window. The code draws points, +lines and shapes; this exercises a variety of drawing functions provided +by the window graphics context such as MoveTo(), DrawLineTo(), DrawArc() etc.

        CZoomControl illustrates the use of zooming.

        +
        Class +Summary

        TPoint

        TRectTSize

        CWindowGc

        TRgb

        CFont

        TFontSpec

        CWindowGc

        TZoomFactor

        MGraphicsDeviceMap

        CFbsBitmap

        +
        Build

        The source code for this example application can be found in +the directory:

        examples\Graphics\GraphicsShell

        This source code may be in the directory in which you installed +the Symbian platform, or it may be in the src\common\developerlibrary\ directory. The directory includes the two project files needed for +building the example: bld.inf and the .mmp file.

        The Symbian build process describes +how to build this application. For the emulator, an application called GraphicsShell.exe is created in epoc32\release\winscw\<udeb +or urel>\.

        Usage
          -

        1. Launch the emulator:

          \epoc32\release\winscw\<udeb -or urel>\EPOC.EXE.

          2. -

        2. Click on GRAPHICSSHELL to -run the application. If using the TechView emulator, this will be in -the Extras menu.

          3. -

        3. The controls are listed -on the menu List of Programs. -Press the appropriate menu item to select a specific control.

          4. -

        4. Step through each phase -of the example by pressing the space bar or by tapping on the window drawn -by that example.

          5. +

        5. Launch the emulator:

          \epoc32\release\winscw\<udeb or urel>\EPOC.EXE.

          6. +

        6. Click on GRAPHICSSHELL to run the application. If using the TechView emulator, this will be in the Extras menu.

          7. +

        7. The controls +are listed on the menu List of Programs. Press the appropriate menu item to select a specific control.

          8. +

        8. Step through +each phase of the example by pressing the space bar or by tapping +on the window drawn by that example.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30647807-A0D2-4D96-975A-BF1800749977.dita --- a/Symbian3/SDK/Source/GUID-30647807-A0D2-4D96-975A-BF1800749977.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-30647807-A0D2-4D96-975A-BF1800749977.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ through the Tools > Preferences menu or by editing the epoc.ini file. The following illustration shows the options you have in the Platform security tab of the Preferences window.

        -Preferences window in the emulator +Preferences window in the emulator

        To set the platform security settings:

        1. In the emulator, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30987768-8B0A-5A35-820C-DBB410D2053B_d0e107221_href.png Binary file Symbian3/SDK/Source/GUID-30987768-8B0A-5A35-820C-DBB410D2053B_d0e107221_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30987768-8B0A-5A35-820C-DBB410D2053B_d0e107453_href.png Binary file Symbian3/SDK/Source/GUID-30987768-8B0A-5A35-820C-DBB410D2053B_d0e107453_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-30EB4252-4CBA-5174-9133-E79AC9AEAEBF.dita --- a/Symbian3/SDK/Source/GUID-30EB4252-4CBA-5174-9133-E79AC9AEAEBF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,15 +0,0 @@ - - - - - -Header information source file

          The build tools automatically generates a stub file, project-name .uid.cpp, which is built by the project and which contains the information on the project's UIDs and other properties. This stub file should not be edited, and should be considered as an intermediate file rather than a source file. It has a syntax such as:

          #include <e32cmn.h> -#pragma data_seg(".SYMBIAN") -__EMULATOR_IMAGE_HEADER2(0x10000079,0x1000008d,0x08a715f2,EPriorityForeground,0x00000000u,0x00000000u,0x08a715f2,0,0x00010000,0) -#pragma data_seg() \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3100800B-B2F7-50EF-BD4C-3C345ECCB2A5.dita --- a/Symbian3/SDK/Source/GUID-3100800B-B2F7-50EF-BD4C-3C345ECCB2A5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,93 +0,0 @@ - - - - - -The -Symbian build process -

          Symbian platform programs are initially developed for a Symbian emulator -running on Windows, and are then rebuilt for the ARM processor (native) targets -used in real Symbian platform phones. Building can be performed from the Windows -command line, or from within an IDE if one is available. The descriptions -given in this documentation set concentrate on command line building, as documentation -for using an IDE is normally distributed with the IDE itself.

          -

          Note: This page includes a description of the use of Symbian's -SBSv1 build system, which provides the bldmake and abld command -line tools. Symbian also provides a newer command line build system, called -SBSv2, in its Platform Developer Toolkit (PDT) product. SBSv2 can help achieve -improved build speed over SBSv1.

          -
          Build targets

          This section describes the tools -and compilers supported on the kits supplied by Symbian. Note that licensees -or third-parties may supply additional tools, or extend support to additional -compilers which are not described here.

          Symbian build their emulator -code with the Metrowerks CodeWarrior compiler. This is known as the WINSCW build -target. Binaries built with this compiler are put in the epoc32\release\winscw and epoc32\winscw directory -trees.

          You can build your programs for the Symbian emulator using -Metrowerks CodeWarrior. The build tools also have support for using the Microsoft -Visual Studio .NET 2003, or Microsoft Visual Studio v6 IDEs. See The -Symbian emulator build targets for more details.

          To build code -for a phone, a compiler based on the Application Binary Interface (ABI) for -the ARM Architecture is needed. This is a standard for the interfaces of binary -code running in ARM environments, and is intended to allow inter-operation -of binaries produced by different compilers that conform to the standard. -The specification is published by ARM at http://infocenter.arm.com.

          The Symbian platform -build tools are configured to work with two compilers in particular:

            -

          • ARM's own RealView Compiler -Tools (RVCT). This is particularly intended for licensee's building ROMs for -phones. For details, see ARM's website at http://www.arm.com.

            The situation -is complicated by there existing two versions of the ARM ABI, referred to -as v1 and v2 respectively. The toolchain allows either to be chosen.

            • -

          • A version of the GNU -Compiler Collection (GCC) that supports the ABI for the ARM Architecture. -This compiler is delivered on Symbian platform kits, and is freely available. -This target is known as GCCE. It can only be used to compile -code to v2 of the ARM ABI, not to the earlier v1.

            • -

          See The native -build targets for more details.

          -
          Project files

          Because of the variety of targets -and toolchains available, Symbian platform allows projects to be specified -in a form not specific to any. These neutral project files are then used by -Symbian platform tools to create toolchain-specific project files when these -are required.

          The key project files are:

            -

          • a project definition -file (.mmp file) that describes a project to be built. -This is an environment neutral file that can be used by the tools to produce -make files for any of the supported target environments. It also defines resource -file and application information files to be built.

            • -

          • a component description -file (bld.inf), which lists all the projects in a component, -and gives additional build instructions.

            • -

          When you create a new project, you write these files (or typically -copy existing similar files and modify them) in a text editor. IDE's may allow -new projects to be created from existing template projects.

          See How to build GUI applications, How to build DLLs, -and How to build EXEs for -guidance on how to write project files for the three most common types of -program. See the Build -tools reference for details on the file formats and syntax.

          -
          Building from the command line

          You can build for -any target from the command line. The procedure is summarised below.

            -

          1. Create a project specification -(.mmp) file.

            2. -

          2. Create a component definition -file (bld.inf). In many cases this will specify a single -project mmp file.

            3. -

          3. Run bldmake from -the directory where the bld.inf file is located:

            bldmake -bldfiles

            This creates a abld.bat batch -file, which you use in the next step.

            4. -

          4. Use abld -build to build the project.

            This builds the project -for all valid targets and both release and debug variants. To build for a -particular target and variant, use abld build -target-name variant, for example

            abld build -winscw udeb

            to build for the debug variant of WINSCW.

            5. -

          For more details on using the tools, see How -to use bldmake and How -to use abld.

          -           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita --- a/Symbian3/SDK/Source/GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-310A8A9C-98E7-59EE-9376-8E572580190F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,174 +1,177 @@ - - - - - -File -services in Symbian platformThis topic describes the common concepts of file systems and files -used by Symbian platform. -

          Like other software systems, Symbian platform can store data so that it -is kept when a handset is powered down.

          -

          On PCs, a file is kept on magnetic disk or optical media such as CD or -DVD. On older generations of personal organisers, a file was often kept in -RAM, needing a permanent power supply, and a backup battery to guarantee this. -On the most recent telephone handsets, files are normally stored in flash -memory, either NOR flash or NAND flash, and also on removable devices such -as MultiMediaCard (MMC), Secure Digital card (SD card), Memory Stick or Compact -flash (CF).

          -

          There are more sophisticated services for persisting data such as streams, -stores, central repository etc. that applications can use, but they all rely, -either directly or indirectly, on the commonly understood idea of the file.

          -

          The ROM on a typical handset is located in non-volatile flash memory, allowing -it to be upgraded by the handset manufacturer after initial production. The -location for user data is almost always flash memory (NAND or NOR), on the -grounds of cost, although rotating media devices capable of holding large -amounts of data are likely in future handsets.

          -
            -

          • Basic concepts

            • -

          • Accessing file services

            • -

          • Security issues

            • -

          • File systems and mounting a drive

            • -
          -
          Basic concepts

          Symbian -platform uses a number of file concepts that are common to most operating -systems, for example, drives and directories.

          Drives

          Symbian -platform uses the concept of the drive. This idea is similar to that -in other operating systems, i.e. it corresponds to a logical device. A media -device such as a MultiMediaCard can be logically split into partitions, and -each partition is treated as a separate drive. Symbian platform adopts a DOS-like -convention where each drive is identified by a single letter. This means that -there can be up to 26 drives on a handset, identified by the letters A: through -to Z:. In practice, there are far fewer than this, and -the number depends on the individual manufacturer's handset

          Internally, -Symbian platform uses the idea of a drive number instead of a letter, and -some legacy API items take a drive number as input, or return a drive number -as output. However, there are functions that can translate drive numbers to -and from drive letters: RFs::DriveToChar() and RFs::CharToDrive().

          The -main ROM on a handset is always identified as the Z: drive. -Other drives may be in use: sixteen of the drives C: to R: are -usually reserved as local drives, i.e. for media devices located within the -handset. A common convention is to adopt C: as the main -user data drive. and to designate D: or E: as -drives for removable media. Be aware, however, that this is a convention -that some handset manufacturers may not follow, so you are always advised -to check the full SDK that applies to a specific handset for guidance. Indeed, -as a matter of principle, you should always use the system -drive for user data.

          Volume

          The concept of the volume applies to removable media. As users insert -and remove individual devices, so different volumes are said to be mounted -and demounted. For media types that can be split into partitions, each partition -corresponds to a separate volume.

          File -names and directory structures

          Files have names, and Symbian platform -uses a hierarchical directory structure in which to organize them; this is -similar to schemes adopted by other operating systems. For example:

          C:\AAA\BBB\CCC\DDD.EXT

          There -are four main parts to the structure:

            -

          • the drive; this -is always at the top of the hierarchy, and is represented by a drive letter -and a colon.

            • -

          • the path; this -is a list of names, each name representing a level in the hierarchy. Each -directory name is separated by a back slash character, and the last directory -name is always terminated by a back slash character.

            • -

          • the filename; -this is everything after the final backslash, and before the dot if there -is a file extension. Symbian platform supports long file filenames.

            • -

          • the extension, -everything after the final dot. There is no restriction on the length of the -extension; limits on length apply to the whole structure, not to any single -part of it.

            • -

          You will find that the whole structure is sometimes referred to as -the full file name or the full path name. The maximum length of a full file -name is limited to 256 characters. Symbian platform does not use the extension -to identify the software or application that can access the data. Instead, -files have UIDs embedded within them, and the mapping of files to applications -is done through these UIDs. See Application -registration information.

          The case of full path names is always -preserved, but operations on names are case insensitive. This means that two -files that have the same name but differ only in case are considered to refer -to the same file.

          Full file names are normally manipulated programmatically. -Extracting drive names, filenames, file extensions, and changing the names -of a directory structure are typical activities. Symbian platform provides -you with the TParse, TParsePtr, and TParsePtrC classes -to help you do this manipulation.

          See parsing -paths and filenames .

          -
          Accessing file -services

          On Symbian platform, file services are a common resource. -Like other common or shared resources on Symbian platform, file services are -handled by a server - the file server. Applications and other software that -require access to files, directories and drives are clients of the file server, -and send file-related requests using the file -server client-side API.

          The file server is multithreaded, which -allows each logical drive to be accessed concurrently. More than one request -can be issued for the same drive, but these requests are handled sequentially. -For example, a request to read or write data to a MultiMediaCard can be handled -at the same time as a request to read or write data to the main user drive.

          The -file server has a main thread that initially handles all requests. Short requests, -such as those that require access to the ROM drive, and those that do not -require access to any media, run in the file server.

          The services -provided by the file server can be divided into two types:

            -

          • those that give you -access to individual files, directories and drives using the RFile, RDir and RFormat classes.

            See also How to -use sessions, files, and directories.

            • -

          • those that allow you -to do higher level longer running operations such as moving, copying and deleting -files, using the CFileMan class, scanning directory trees -using the CDirScan class, and tracking the progress of -these operations using the MFileManObserver class.

            See -also File management -and searching

            • -

          Like most other servers, the client API allows you to make file requests -synchronously or asynchronously.

          See also client-server.

          -
          Security issues

          Security -considerations restrict the parts of a handset's directory structure that -an application is allowed to access. The concept is referred to as data -caging.

          There are a number of principles involved:

            -

          • The fundamental principle -is the separation of executable code from data. Executable code can only reside -in the /sys/bin/ directory. Executables cannot be loaded -from any location other than /sys/bin/. Unless an application -has the appropriate system capabilities, the /sys/ directory -is not visible to that application. System capabilities are a discrete set -of 'permissions' that give access to various sensitive system services, and -which can only be granted to applications, if justified, through the Symbian Signed scheme.

            • -

          • Applications have their -own private directory, under which they are free to create further directory -structures and files, and to write to those files. This is the directory structure /private/<app_SID>/. <app_SID> is known as a secure identifier and, in general, is used when verifying -an executable's rights of access to system resources. Here, it is used to -form the path name for the executable's private directory. The secure identifier -is a UID which is allocated to a developer through the Symbian Signed scheme, and is guaranteed to be unique -within the handset on which the application is installed. The UID is coded -into the mmp file(s) that define the application's source -files, link requirements, and general characteristics.

            Other applications -have no right of access to an application's private directory.

            • -

          • There is a directory /resource/ to -which all applications have read access, but no write access. The purpose -of this directory is to conatin common read-only files.

            • -

          • All other directories -are accessible for both reading and writing. This allows the use of standard -file system hierarchies that may be available on removable media.

            • -

          • The above principles -apply regardless of the drive.

            • -

          It is possible to pass an open file to another process, or between -a client and server, so that the target can access the file without knowing -the full path name. The only information that is passed to the target is the -filename and extension.

          -
          File systems -and mounting a drive

          The varying characteristics of media types -can mean that different media types require different formats. A common format -is VFAT, and typically, this is used for removable media to maintain compatibility -with other systems. This also means that long file names are supported.

          In -Symbian platform, format schemes are implemented by what are called file systems; -they are constructed as plugins to the file server. This means that the file -server itself is independent of the format scheme, and also means that a phone -manufacturer is free to add new file systems to a handset. The ROM is an exception -- it has its own file system built into the main file server code.

          A -file system must be associated with a drive before the drive can be used. -This is known as mounting the drive, and is typically done at system boot -time.

          In practice, an application does not need to concern itself -with the format scheme.

          + + + + + +File services in Symbian platformThis topic describes the common concepts of file systems +and files used by Symbian platform. +

          Like other software systems, Symbian platform can store data so +that it is kept when a handset is powered down.

          +

          On PCs, a file is kept on magnetic disk or optical media such as +CD or DVD. On older generations of personal organisers, a file was +often kept in RAM, needing a permanent power supply, and a backup +battery to guarantee this. On the most recent telephone handsets, +files are normally stored in flash memory, either NOR flash or NAND +flash, and also on removable devices such as MultiMediaCard (MMC), +Secure Digital card (SD card), Memory Stick or Compact flash (CF).

          +

          There are more sophisticated services for persisting data such +as streams, stores, central repository etc. that applications can +use, but they all rely, either directly or indirectly, on the commonly +understood idea of the file.

          +

          The ROM on a typical handset is located in non-volatile flash memory, +allowing it to be upgraded by the handset manufacturer after initial +production. The location for user data is almost always flash memory +(NAND or NOR), on the grounds of cost, although rotating media devices +capable of holding large amounts of data are likely in future handsets.

          +
            +

          • Basic concepts

            • +

          • Accessing file services

            • +

          • Security issues

            • +

          • File systems and mounting a drive

            • +
          +
          Basic +concepts

          Symbian platform uses a number of file concepts +that are common to most operating systems, for example, drives and +directories.

          Drives

          Symbian platform uses the concept of the drive. This idea is similar to that in other operating systems, +i.e. it corresponds to a logical device. A media device such as a +MultiMediaCard can be logically split into partitions, and each partition +is treated as a separate drive. Symbian platform adopts a DOS-like +convention where each drive is identified by a single letter. This +means that there can be up to 26 drives on a handset, identified by +the letters A: through to Z:. In practice, there are far fewer than this, and the number depends +on the individual manufacturer's handset

          Internally, Symbian +platform uses the idea of a drive number instead of a letter, and +some legacy API items take a drive number as input, or return a drive +number as output. However, there are functions that can translate +drive numbers to and from drive letters: RFs::DriveToChar() and RFs::CharToDrive().

          The main ROM +on a handset is always identified as the Z: drive. +Other drives may be in use: sixteen of the drives C: to R: are usually reserved as local drives, +i.e. for media devices located within the handset. A common convention +is to adopt C: as the main user data drive. and +to designate D: or E: as +drives for removable media. Be aware, however, that this is +a convention that some handset manufacturers may not follow, so you +are always advised to check the full SDK that applies to a specific +handset for guidance. Indeed, as a matter of principle, you should +always use the system drive for user data.

          Volume

          The concept of the volume applies to removable +media. As users insert and remove individual devices, so different +volumes are said to be mounted and demounted. For media types that +can be split into partitions, each partition corresponds to a separate +volume.

          File names and directory structures

          Files have names, +and Symbian platform uses a hierarchical directory structure in which +to organize them; this is similar to schemes adopted by other operating +systems. For example:

          C:\AAA\BBB\CCC\DDD.EXT

          There are four main parts to the structure:

            +

          • the drive; this is always at the top of the hierarchy, and is represented +by a drive letter and a colon.

            • +

          • the path; this is a list of names, each name representing a level in the +hierarchy. Each directory name is separated by a back slash character, +and the last directory name is always terminated by a back slash character.

            • +

          • the filename; this is everything after the final backslash, and before the dot +if there is a file extension. Symbian platform supports long file +filenames.

            • +

          • the extension, everything after the final dot. There is no restriction on the +length of the extension; limits on length apply to the whole structure, +not to any single part of it.

            • +

          You will find that the whole structure is sometimes referred +to as the full file name or the full path name. The maximum length +of a full file name is limited to 256 characters. Symbian platform +does not use the extension to identify the software or application +that can access the data. Instead, files have UIDs embedded within +them, and the mapping of files to applications is done through these +UIDs. For more information, see Symbian^3 Tools Guide > Building.

          The case of full path names is always preserved, but operations +on names are case insensitive. This means that two files that have +the same name but differ only in case are considered to refer to the +same file.

          Full file names are normally manipulated programmatically. +Extracting drive names, filenames, file extensions, and changing the +names of a directory structure are typical activities. Symbian platform +provides you with the TParse, TParsePtr, and TParsePtrC classes to help you do this manipulation.

          See parsing +paths and filenames .

          +
          Accessing +file services

          On Symbian platform, file services are a +common resource. Like other common or shared resources on Symbian +platform, file services are handled by a server - the file server. +Applications and other software that require access to files, directories +and drives are clients of the file server, and send file-related requests +using the file +server client-side API.

          The file server is multithreaded, +which allows each logical drive to be accessed concurrently. More +than one request can be issued for the same drive, but these requests +are handled sequentially. For example, a request to read or write +data to a MultiMediaCard can be handled at the same time as a request +to read or write data to the main user drive.

          The file server +has a main thread that initially handles all requests. Short requests, +such as those that require access to the ROM drive, and those that +do not require access to any media, run in the file server.

          The services provided by the file server can be divided into two +types:

            +

          • those that give +you access to individual files, directories and drives using the RFile, RDir and RFormat classes.

            See also How to use sessions, +files, and directories.

            • +

          • those that allow +you to do higher level longer running operations such as moving, copying +and deleting files, using the CFileMan class, scanning +directory trees using the CDirScan class, and tracking +the progress of these operations using the MFileManObserver class.

            See also File management and +searching.

            • +

          Like most other servers, the client API allows you to make +file requests synchronously or asynchronously.

          See also client-server.

          +
          Security +issues

          Security considerations restrict the parts of a +handset's directory structure that an application is allowed to access. +The concept is referred to as data caging.

          There are +a number of principles involved:

            +

          • The fundamental +principle is the separation of executable code from data. Executable +code can only reside in the /sys/bin/ directory. +Executables cannot be loaded from any location other than /sys/bin/. Unless an application has the appropriate system +capabilities, the /sys/ directory is not visible +to that application. System capabilities are a discrete set of 'permissions' +that give access to various sensitive system services, and which can +only be granted to applications, if justified, through the Symbian +Signed scheme.

            • +

          • Applications +have their own private directory, under which they are free to create +further directory structures and files, and to write to those files. +This is the directory structure /private/<app_SID>/. <app_SID> is known as a secure identifier and, in general, +is used when verifying an executable's rights of access to system +resources. Here, it is used to form the path name for the executable's +private directory. The secure identifier is a UID which is allocated +to a developer through the Symbian +Signed scheme, and is guaranteed to be unique within the handset +on which the application is installed. The UID is coded into the mmp file(s) that define the application's source files, +link requirements, and general characteristics.

            Other applications +have no right of access to an application's private directory.

            • +

          • There is a directory /resource/ to which all applications have read access, +but no write access. The purpose of this directory is to conatin common +read-only files.

            • +

          • All other directories +are accessible for both reading and writing. This allows the use of +standard file system hierarchies that may be available on removable +media.

            • +

          • The above principles +apply regardless of the drive.

            • +

          It is possible to pass an open file to another process, or +between a client and server, so that the target can access the file +without knowing the full path name. The only information that is passed +to the target is the filename and extension.

          +
          File +systems and mounting a drive

          The varying characteristics +of media types can mean that different media types require different +formats. A common format is VFAT, and typically, this is used for +removable media to maintain compatibility with other systems. This +also means that long file names are supported.

          In Symbian +platform, format schemes are implemented by what are called file systems; +they are constructed as plugins to the file server. This means that +the file server itself is independent of the format scheme, and also +means that a phone manufacturer is free to add new file systems to +a handset. The ROM is an exception - it has its own file system built +into the main file server code.

          A file system must be associated +with a drive before the drive can be used. This is known as mounting +the drive, and is typically done at system boot time.

          In practice, +an application does not need to concern itself with the format scheme.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-314B1556-5CB5-4BCC-93C0-B22DB849D2D5.dita --- a/Symbian3/SDK/Source/GUID-314B1556-5CB5-4BCC-93C0-B22DB849D2D5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-314B1556-5CB5-4BCC-93C0-B22DB849D2D5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ Universal indicator pane. Indicators are placed side by side at the top (above the clock in the image on the right). - +

          The universal indicator pane is not accessible to applications.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-316D7B85-F827-4479-B5EE-81F210614236_d0e11518_href.png Binary file Symbian3/SDK/Source/GUID-316D7B85-F827-4479-B5EE-81F210614236_d0e11518_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-316D7B85-F827-4479-B5EE-81F210614236_d0e11621_href.png Binary file Symbian3/SDK/Source/GUID-316D7B85-F827-4479-B5EE-81F210614236_d0e11621_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-31A6FA69-418D-5F8D-A0FB-6A99AA8CC4E1_d0e76759_href.png Binary file Symbian3/SDK/Source/GUID-31A6FA69-418D-5F8D-A0FB-6A99AA8CC4E1_d0e76759_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-31A6FA69-418D-5F8D-A0FB-6A99AA8CC4E1_d0e76797_href.png Binary file Symbian3/SDK/Source/GUID-31A6FA69-418D-5F8D-A0FB-6A99AA8CC4E1_d0e76797_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-322A932E-5DC8-5CBB-BD3C-02F5CEDB060E.dita --- a/Symbian3/SDK/Source/GUID-322A932E-5DC8-5CBB-BD3C-02F5CEDB060E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-322A932E-5DC8-5CBB-BD3C-02F5CEDB060E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -213,7 +213,7 @@
      Implementing SSP notifiers

      Introdution

      The -Bluetooth sub-system has no user interface. It uses the Symbian notifier +Bluetooth sub-system has no user interface. It uses the Symbian notifier framework for user interaction when pairing. The UI system must provide a notifier, in plug-in form, for each user interaction required by SSP. The notifier must receive data in a specified format from the Bluetooth sub-system, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3239641A-2D13-56D7-B18D-6E65B6B24886_d0e287369_href.png Binary file Symbian3/SDK/Source/GUID-3239641A-2D13-56D7-B18D-6E65B6B24886_d0e287369_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3239641A-2D13-56D7-B18D-6E65B6B24886_d0e292200_href.png Binary file Symbian3/SDK/Source/GUID-3239641A-2D13-56D7-B18D-6E65B6B24886_d0e292200_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-329833DA-CB6E-4715-A8E6-AD838DD5A909_d0e4467_href.png Binary file Symbian3/SDK/Source/GUID-329833DA-CB6E-4715-A8E6-AD838DD5A909_d0e4467_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-329833DA-CB6E-4715-A8E6-AD838DD5A909_d0e4594_href.png Binary file Symbian3/SDK/Source/GUID-329833DA-CB6E-4715-A8E6-AD838DD5A909_d0e4594_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-32C1FC8B-F7D2-5275-BDF2-0D662551294C.dita --- a/Symbian3/SDK/Source/GUID-32C1FC8B-F7D2-5275-BDF2-0D662551294C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-32C1FC8B-F7D2-5275-BDF2-0D662551294C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -114,7 +114,7 @@ searching and sorting messages:

      High level class diagram of new search-sort API - +

      • CMsvSearchSortOperation

        The CMsvSearchSortOperation class is used in the client application for enhanced search-sort operations on the message store.

        This class can be used for the following:

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-32D39AB1-D1B0-5F44-8226-0777B8010C7D_d0e107181_href.png Binary file Symbian3/SDK/Source/GUID-32D39AB1-D1B0-5F44-8226-0777B8010C7D_d0e107181_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-32D39AB1-D1B0-5F44-8226-0777B8010C7D_d0e107413_href.png Binary file Symbian3/SDK/Source/GUID-32D39AB1-D1B0-5F44-8226-0777B8010C7D_d0e107413_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-32E29020-1956-461A-B79A-1492E06049E7.dita --- a/Symbian3/SDK/Source/GUID-32E29020-1956-461A-B79A-1492E06049E7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-32E29020-1956-461A-B79A-1492E06049E7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,13 +1,32 @@ - - - - - -Symbian GuideThe Symbian Guide describes the architecture and functionality -of the platform, and provides guides on using its APIs. \ No newline at end of file + + + + + +Symbian GuideThe Symbian Guide describes the architecture and functionality +of the platform, and provides guides on using its APIs. +

          Application Framework +Guide

          Application Installation Guide

          Cellular Baseband +Services Guide

          Classic UI Guide

          Common +Email Guide

          Communications Framework +Guide

          Contacts Guide

          Device Services Guide

          Generic +Application Support Guide

          Generic OS Services +Guide

          Graphics Guide

          High Level Internet +Protocols Guide

          IP Connection Management

          Kernel +and Hardware Services Guide

          Location Based Services +(LBS) Guide

          Messaging Application +Guide

          Messaging Middleware Guide

          Multimedia Guide

          Multimedia +Protocols Guide

          Networking Services +Guide

          Organizer Guide

          OS Security Guide

          Persistent +Data Services Guide

          Security Services +Guide

          Short Link Services Guide

          Text and Localization +Guide

          Web Guide

          XML Services Guide

          + + +           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-32F00078-6084-5288-9D3F-9F8D70514799.dita --- a/Symbian3/SDK/Source/GUID-32F00078-6084-5288-9D3F-9F8D70514799.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,58 +0,0 @@ - - - - - -RESOURCE -statement -<resource-statement> -resource-statement ::= -RESOURCE <struct-name> [ <resource-name> ] { <resource-initialiser-list> } -

          The RESOURCE statement is used to generate a resource -in the resource file. The statement specifies three things:

          -
            -

          • a struct-name which -denotes the structure that will be used for the resource

            It must have -been defined in a previous STRUCT statement and must be in -upper case.

            • -

          • an optional resource-name which -identifies the resource

            The resource-name must be -in lower case.

            The resource-name causes a symbolic -constant to be generated in the resource compiler’s output header file, so -that a resource

            RESOURCE TEST my_test { /* etc */ }

            will -result in a definition of the form

            #define MY_TEST 1

            in -the generated header file.

            The default ID for the first resource defined -in the file is one with subsequent resources’ IDs generated in ascending sequence. -See Resource file definition for -more information on how resource IDs are generated.

            If no resource -name is specified then the resource is generated in the object file and assigned -a resource ID as usual, but will not be published in the header file. Anonymous -resources are used mainly for playback scripts where the resources are read -in sequentially by default, so that assigning names to them would be superfluous.

            The resource-name may -also be used by the resource compiler for LINK and LLINK members -— see Resource identifiers -for LINKs and LLINKs.

            • -

          • initialisation for members -of the resource struct, where their default values are not appropriate

            • -
          -

          As an example, given the struct definition

          STRUCT NCEDIT - { - WORD current; - WORD low; - WORD high=65535; - }

          you could define a resource:

          RESOURCE NCEDIT memory_size - { - low=640; - high=1024; - }

          Thus, in the resource file, current has -the value compiler default value of 0, low has the value -640 (specified in the resource definition) and high has the -value 1024 (specified in the resource definition, overriding the default for -the struct type).

           -           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3314123F-205D-5E05-9041-DB9836B7812B.dita --- a/Symbian3/SDK/Source/GUID-3314123F-205D-5E05-9041-DB9836B7812B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3314123F-205D-5E05-9041-DB9836B7812B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,8 +39,7 @@ security capabilities.

      Related APIs

      mkdir(const char *,mode_t)

      fopen(const char *, const char *)

      -
      Build

      The Symbian -build process describes how to build this example application.

      The example builds an executable called fileaccessexample.exe in the standard locations.

      To run the example, start fileaccessexample.exe from the file system or from your +

      Build

      The example builds an executable called fileaccessexample.exe in the standard locations.

      To run the example, start fileaccessexample.exe from the file system or from your IDE. After launching the executable, depending on the emulator you are using, you may need to navigate away from the application launcher or shell screen to view the console.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-33241691-7362-5FA1-A3B0-C3FA550E5E09.dita --- a/Symbian3/SDK/Source/GUID-33241691-7362-5FA1-A3B0-C3FA550E5E09.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-33241691-7362-5FA1-A3B0-C3FA550E5E09.dita Tue Jul 20 12:00:49 2010 +0100 @@ -68,7 +68,7 @@ and embedded applications to handle their data storage through stores.

      Stores are also the basis of the relational database provided by DBMS.

      Store inheritance diagram - +
      APIs diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-33716081-180C-5DDB-A5D2-0EC61357250D.dita --- a/Symbian3/SDK/Source/GUID-33716081-180C-5DDB-A5D2-0EC61357250D.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,42 +0,0 @@ - - - - - -How -to use the post-linker (elf2e32) -

      The post-linker is a Symbian-specific build tool. Its principal function -is to create executables (DLLs and EXEs) in the particular format required -by Symbian platform, known as the E32Image format. Commercial compiler -and linkers, such as ARM's RVCT and GNU GCC, cannot directly generate that -format. Such compilers do however support a standard output format called -the Executable and Linking Format (ELF) (defined at http://www.caldera.com/developers/gabi/). A tool is -therefore needed to convert from the ELF format into the E32Image format, -and this is the key role of the post-linker. The tool also contains the functionality -to maintain and create the DEF files used for freezing the exports of libraries.

      -

      In ordinary use, the post-linker is not used directly by users. It is called -from the makefiles generated by abld on the command line, -or from the build commands of an IDE.

      -

      The tool can also be used to output -a description of an existing E32Image file for analysis.

      -

      This section contains the following topics:

      -
        -
      • Post Linker Overview
        • -
      • How to create executables
        • -
      • How to create a -DSO library file from a DEF file
        • -
      • How to dump an -E32Image file
        • -
      -       -elf2e32 command -syntax -Troubleshooting -post-linker (elf2e32) errors -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-337FA49D-DE53-5568-9A5C-D6AE3F25E0A6_d0e76374_href.png Binary file Symbian3/SDK/Source/GUID-337FA49D-DE53-5568-9A5C-D6AE3F25E0A6_d0e76374_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-337FA49D-DE53-5568-9A5C-D6AE3F25E0A6_d0e76412_href.png Binary file Symbian3/SDK/Source/GUID-337FA49D-DE53-5568-9A5C-D6AE3F25E0A6_d0e76412_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e36608_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e36608_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e36776_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e36776_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e51756_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e51756_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e51899_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e51899_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e68090_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e68090_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e68154_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e68154_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e69011_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e69011_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e69035_href.png Binary file Symbian3/SDK/Source/GUID-3382507E-1B21-418C-A908-DD3F688C0672_d0e69035_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-33D50AB9-AFA8-521F-8A85-031C24EA7D25.dita --- a/Symbian3/SDK/Source/GUID-33D50AB9-AFA8-521F-8A85-031C24EA7D25.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-33D50AB9-AFA8-521F-8A85-031C24EA7D25.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ Framework and the XML DOM Engine.

      Package diagram for the libxml2 component - +

      The libxml2 sub-component provides direct access to the C API of the standard libxml2 library.

      The Utilities sub-component provides object-oriented access to the C functions: it also implements the resource diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-34614E31-45F1-5BD8-963D-9526AAD31734.dita --- a/Symbian3/SDK/Source/GUID-34614E31-45F1-5BD8-963D-9526AAD31734.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-34614E31-45F1-5BD8-963D-9526AAD31734.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,88 +1,85 @@ - - - - - -resourcemanager: -Power Resource Manager Framework exampleThis example demonstrates the Power Resource Manager user side -APIs. -

      Purpose

      The example shows how to use the Power Resource Manager user -side APIs provided by the RBusDevResManUs class.

      The -use cases demonstrated are:
        -

      • How to get information about power resources.

        • -

      • How to get information about other clients registered with the Power -Resource Manager.

        • -

      • How to change the state of a resource.

        • -

      • How to get notification when a resource changes state.

        • -
      -
      Class summary
        -

      1. RBusDevResManUs

        2. -

      2. TResourceInfo

        3. -

      3. TClientInfo

        4. -
      -
      Download

      Click on the following link to download -the example: resourcemanager.zip.

      Click: browse to view the example code.

      -
      Design and implementation

      This example builds a -console application called resourcemanager.exe. It requests -user input, and prints information to the console.

      The following menu -options are presented to the user:

        -

      • Get Power Resource information.

        • -

      • Change the state of -a resource.

        • -

      • Notify a change of resource -state.

        • -

      Get Power Resource information

      This option gets and -displays information about the clients of the Power Resource Manager framework -and about the available resources.

      The following sub-menu options -are presented:

        -

      • 1. Get the number of -available resources.

        • -

      • 2. Get information about -a particular resource.

        • -

      • 3. Get information about -all the available resources.

        • -

      • 4. Get the state of -a particular resource.

        • -

      • 5. Get the number of -clients using a particular resource.

        • -

      • 6. Get the number of -resources used by a particular client.

        • -

      • 7. Get information about -all the resources in use by a particular client.

        • -

      • 8. Get information on -all clients using a particular resource.

        • -

      • 9. Get the names of -all clients.

        • -

      Change the state of a resource

      This option allows -the user to change the state of a resource.

      Notify any change of -resource state

      This option changes the state of a resource and -notifies the user about the change.

      -
      Building and configuring

      To build the example:

        -

      • You can build the example -from your IDE or the command line.

        If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

        If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

        bldmake -bldfiles

        abld build

        How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

        • -

      • For the emulator, the -example builds an executable called resourcemanager.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

        • -
      -
      Running the example

      To run the example, launch -the executable resourcemanager.exe, then choose from -the menu options. Press Esc to quit.

      Note: -this example requires an LDD, a PDD and a PSL (platform specific layer). If -these are not provided on the platform you are using, the example will not -run.

      - -Power Resource -Manager Architecture Overview + + + + + +resourcemanager: Power Resource Manager Framework exampleThis example demonstrates the Power Resource Manager user +side APIs. +
      Purpose

      The example shows how to use the Power Resource Manager +user side APIs provided by the RBusDevResManUs class.

      The use cases demonstrated are:
        +

      • How to get information about power resources.

        • +

      • How to get information about other clients registered with +the Power Resource Manager.

        • +

      • How to change the state of a resource.

        • +

      • How to get notification when a resource changes state.

        • +
      +
      Class summary
        +

      1. RBusDevResManUs

        2. +

      2. TResourceInfo

        3. +

      3. TClientInfo

        4. +
      +
      Download

      Click on the following link to +download the example: resourcemanager.zip.

      Click: browse to view the example code.

      +
      Design and implementation

      This example +builds a console application called resourcemanager.exe. It requests user input, and prints information to the console.

      The following menu options are presented to the user:

        +

      • Get Power Resource +information.

        • +

      • Change the state +of a resource.

        • +

      • Notify a change +of resource state.

        • +

      Get Power Resource information

      This option +gets and displays information about the clients of the Power Resource +Manager framework and about the available resources.

      The following +sub-menu options are presented:

        +

      • 1. Get the number +of available resources.

        • +

      • 2. Get information +about a particular resource.

        • +

      • 3. Get information +about all the available resources.

        • +

      • 4. Get the state +of a particular resource.

        • +

      • 5. Get the number +of clients using a particular resource.

        • +

      • 6. Get the number +of resources used by a particular client.

        • +

      • 7. Get information +about all the resources in use by a particular client.

        • +

      • 8. Get information +on all clients using a particular resource.

        • +

      • 9. Get the names +of all clients.

        • +

      Change the state of a resource

      This option +allows the user to change the state of a resource.

      Notify +any change of resource state

      This option changes the state +of a resource and notifies the user about the change.

      +
      Building and configuring

      To build the example:

        +

      • You can build +the example from your IDE or the command line.

        If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

        If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld +build

        • +

      • For the emulator, +the example builds an executable called resourcemanager.exe in the epoc32\release\winscw\<udeb or + urel>\ folder.

        • +
      +
      Running the example

      To run the example, +launch the executable resourcemanager.exe, then +choose from the menu options. Press Esc to +quit.

      Note: this example requires an LDD, a PDD and a PSL +(platform specific layer). If these are not provided on the platform +you are using, the example will not run.

      +       +Power +Resource Manager Architecture Overview       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3472798D-CEC5-5BA9-A3A7-D4245661DEDB.dita --- a/Symbian3/SDK/Source/GUID-3472798D-CEC5-5BA9-A3A7-D4245661DEDB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3472798D-CEC5-5BA9-A3A7-D4245661DEDB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,78 +1,67 @@ - - - - - -pubsub: -Using the Publish and Subscribe IPC MechanismThis example demonstrates the Publish and Subscribe IPC mechanisms -using the RProperty class. -
      Download

      Click -on the following link to download the example: pubsub.zip.

      Click: browse to view the example code.

      -
      Description

      This -example demonstrates three types of usage pattern for Publish and Subscribe:

        -

      • Standard State Publishing

          -

        • Publisher: The -publisher defines a byte-array property and pre-allocates memory to it. It -interactively updates and re-publishes the value of the property.

          • -

        • Subscriber: The -subscriber gets the value of the property defined by the publisher by subscribing -to it. It displays an error and stops running if it fails to get the value -of the property.

          • -
        • -

      • Pure Event Distribution

          -

        • Publisher: The -publisher defines an integer property and publishes a random integer value -periodically. This value has no significance to the subscriber.

          • -

        • Subscriber: The -subscriber gets a notification when the publisher publishes a value. It exits -when the property is deleted by the publisher.

          • -
        • -

      • Speculative Publishing

          -

        • Publisher: The -publisher does not define the property. It ignores the KErrNotFound error -when it publishes the value of the property.

          • -

        • Subscriber: The -subscriber defines and subscribes to the property. It ignores the KErrAlreadyExists error.

          • -
        • -
      -
      Class summary
        -

      • RProperty - User side interface to Publish & -Subscribe.

        • -

      • CActive - The core class of the active object abstraction.

        • -
      -
      Build

      The Symbian build process describes -how to build this example.

      This example builds the following binaries -in the standard location (\epoc32\release\winscw\<build_variant>) -for Carbide.c++:

        -

      • publishstd.exe: -The publisher process for the Standard State pattern.

        • -

      • subscribestd.exe: -The subscriber process for the Standard State pattern.

        • -

      • publishpe.exe: -The publisher process for the Pure Event Distribution pattern.

        • -

      • subscribepe.exe: -The subscriber process for the Pure Event Distribution pattern.

        • -

      • publishspec.exe: -The publisher process for the Speculative Publishing pattern.

        • -

      • subscribespec.exe: -The subscriber process for the Speculative Publishing pattern.

        • -
      -
      Running the -example

      To run the example, perform the following steps on each -usage pattern:

        -

      1. Open two eshells.

        2. -

      2. Run the publisher executable -file in one eshell.

        3. -

      3. Run the subscriber executable -file in another eshell.

        4. -

      Note: Switch between eshells by pressing CTRL+ALT+SHIFT+T.

      -
      See also

      For -more information, see Publish -and Subscribe in Using User Library (E32).

      + + + + + +pubsub: Using the Publish and Subscribe IPC MechanismThis example demonstrates the Publish and Subscribe IPC +mechanisms using the RProperty class. +
      Download

      Click on the following link to download the example: pubsub.zip.

      Click: browse to view the example code.

      +
      Description

      This example demonstrates three types of usage pattern for Publish +and Subscribe:

        +

      • Standard State +Publishing

          +

        • Publisher: The publisher defines a byte-array property and pre-allocates memory +to it. It interactively updates and re-publishes the value of the +property.

          • +

        • Subscriber: The subscriber gets the value of the property defined by the publisher +by subscribing to it. It displays an error and stops running if it +fails to get the value of the property.

          • +
        • +

      • Pure Event Distribution

          +

        • Publisher: The publisher defines an integer property and publishes a random +integer value periodically. This value has no significance to the +subscriber.

          • +

        • Subscriber: The subscriber gets a notification when the publisher publishes +a value. It exits when the property is deleted by the publisher.

          • +
        • +

      • Speculative +Publishing

          +

        • Publisher: The publisher does not define the property. It ignores the KErrNotFound error when it publishes the value of the property.

          • +

        • Subscriber: The subscriber defines and subscribes to the property. It ignores +the KErrAlreadyExists error.

          • +
        • +
      +
      Class +summary
        +

      • RProperty - User side interface to Publish +& Subscribe.

        • +

      • CActive - The core class of the active object +abstraction.

        • +
      +
      Build

      The Symbian build process describes how to build this example.

      This example builds the following binaries in +the standard location (\epoc32\release\winscw\<build_variant>) for Carbide.c++:

        +

      • publishstd.exe: The publisher process for the Standard State pattern.

        • +

      • subscribestd.exe: The subscriber process for the Standard State pattern.

        • +

      • publishpe.exe: The publisher process for the Pure Event Distribution pattern.

        • +

      • subscribepe.exe: The subscriber process for the Pure Event Distribution pattern.

        • +

      • publishspec.exe: The publisher process for the Speculative Publishing pattern.

        • +

      • subscribespec.exe: The subscriber process for the Speculative Publishing pattern.

        • +
      +
      Running +the example

      To run the example, perform the following steps +on each usage pattern:

        +

      1. Open two eshells.

        2. +

      2. Run the publisher +executable file in one eshell.

        3. +

      3. Run the subscriber +executable file in another eshell.

        4. +

      Note: Switch between eshells by pressing CTRL+ALT+SHIFT+T.

      +
      See +also

      For more information, see Publish and Subscribe in Using User Library (E32).

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-347ACB44-5D07-5EA6-8751-E424A118859D_d0e131819_href.jpg Binary file Symbian3/SDK/Source/GUID-347ACB44-5D07-5EA6-8751-E424A118859D_d0e131819_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-347ACB44-5D07-5EA6-8751-E424A118859D_d0e135423_href.jpg Binary file Symbian3/SDK/Source/GUID-347ACB44-5D07-5EA6-8751-E424A118859D_d0e135423_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3483E654-38CC-538B-8B66-9D7A0C0B4025.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-3483E654-38CC-538B-8B66-9D7A0C0B4025.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,14 @@ + + + + + +Supported Audio CodecsThis document provides a list of codecs supported by Multimedia audio components. Each codec is listed with its unique four character (FourCC) code identifier and equivalent Hexadecimal ASCII value.
      Codec FourCC Code Hexadecimal ASCII Value

      8-bit PCM

      P8

      Note: The first two characters in this FourCC code are spaces.

      0x38502020

      8-bit unsigned PCM

      PU8

      Note: The first character in this FourCC code is a space.

      0x38555020

      16-bit PCM

      P16

      Note: The first character in this FourCC code is a space.

      0x36315020

      16-bit unsigned PCM

      PU16

      0x36315550

      Advanced Audio Codec (AAC) or Moving Picture Experts Group 4 (MPEG-4) Audio Layer 3

      AAC

      Note: The first character in this FourCC code is a space.

      0x43414120

      Advanced Audio Codec Audio Data Transport Stream (AAC ADTS)

      ADTS

      0x53544441

      A-Law

      ALAW

      0x57414c41

      AMR

      AMR

      Note: The first character in this FourCC code is a space.

      0x524d4120

      AMR Wideband

      AMRW

      0x57524d41

      ATRAC3

      ATR3

      0x33525441

      Dolby Digital (DD) or Audio Coding 3 (AC-3)

      AC3

      Note: The first character in this FourCC code is a space.

      0x33434120

      Dolby Digital Plus (DD+) or Enhanced Audio Coding 3 (E-AC-3)

      EAC3

      0x33434145

      GSM 6.10

      GSM6

      0x364d5347

      IMA ADPCM

      IMAD

      0x44414d49

      IMA stereo ADPCM

      IMAS

      0x53414d49

      Most-significant byte first (big-endian) 16-bit PCM

      P16B

      0x42363150

      Most-significant byte first (big-endian) 16-bit unsigned PCM

      PU6B

      0x42365550

      MPEG-1 Audio Layer 3

      MP3

      Note: The first character in this FourCC code is a space.

      0x33504d20

      Mu-law or µ-law

      ULAW

      0x57414c75

      Null

      NULL

      Note: Use this FourCC code if the actual FourCC is not known or not applicable.

      0x4c4c554e

      SBC

      SBC

      Note: The first character in this FourCC code is a space.

      0x43425320

      Wideband AMR

      AWB

      Note: The first character in this FourCC code is a space.

      0x42574120

      Windows Media Audio (WMA)

      WMA

      Note: The first character in this FourCC code is a space.

      0x414d5720

      Writing a Codec Plug-in Writing a Controller + Plug-in Audio Output + Stream Library DevSound Library \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3490A064-8421-4ABB-9E93-99A5565CF4D7.dita --- a/Symbian3/SDK/Source/GUID-3490A064-8421-4ABB-9E93-99A5565CF4D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3490A064-8421-4ABB-9E93-99A5565CF4D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ Preferences API are listed below. One or more of the preferences can be set based on connection establishment requirements. For more details on the restrictions regarding the preferences that can be used jointly, refer TExtendedConnPref .

      - + Define Bearer Filtering

      Extended Connection Preferences API allows the application to limit diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-34BEF44B-EFBE-41EB-941D-0410FCB6782E.dita --- a/Symbian3/SDK/Source/GUID-34BEF44B-EFBE-41EB-941D-0410FCB6782E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-34BEF44B-EFBE-41EB-941D-0410FCB6782E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -42,7 +42,7 @@

      Architectural Relationships Class Relationships for TExtendedConnPref - +
      Typical Uses

      The API provides the following key services:

        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-34DB27CB-9010-5B7F-A51E-0CA794147CAE.dita --- a/Symbian3/SDK/Source/GUID-34DB27CB-9010-5B7F-A51E-0CA794147CAE.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -macro

        macro macro-list

        Where, macro-list =macro_name_1 macro_name_2=value_2...macro_name_n

        Use the macro statement to specify #defines for the preprocessing of source code. You can specify multiple macros separated by a space. if required, you can also assign values to those macros.

        Note: It is not mandatory that all the macros listed must have a value.

        Each macro specified is passed to the complier using the option -d for preprocessing the C++ source code in your project.

        Example MACRO _MACRO1 _MACRO2=value2

        To check whether these macros are passed to the compiler or not, use the -verbose abld option.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3527AAEE-210F-524B-A655-A65F1CE86C80.dita --- a/Symbian3/SDK/Source/GUID-3527AAEE-210F-524B-A655-A65F1CE86C80.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,62 +0,0 @@ - - - - - -How -to build a resource file -

        Resource building is performed by the epocrc tool. -It is a three-stage process:

        -
          -

        • pre-processing

          • -

        • localised string merging

          • -

        • compilation to binary -format

          • -
        -

        The sections below describe each stage in turn.

        -
        Pre-processing

        Resource files can use the familiar -pre-processor directives. In particular, #include is used -to include header files; #define is used to define macros -such as numeric constants; and #if and related directives -can be used to perform conditional compilation. Pre-processor arguments for -include file paths and macro definitions can be passed to the pre-processor -through epocrc.

        The source file is pre-processed, -using the cpp pre-processor, and an output file produced -with an extension .rpp.

        -
        Merging localised strings

        Strings that should be -localised should not be defined in the resource file itself, but in separate -files with an .rls extension. The .rpp files -are processed by epocrc to merge in the localisable strings.

        A -flag can also be specified to epocrc that causes it to -copy the .rpp files into a epoc32\localisation\ directory, -from where they can form input into a localisation kit.

        -
        Compilation to binary format

        The final -stage is to convert the intermediary .rpp files into -the final compiled format. This is done by the rcomp tool. -The resource compiler also produces a header file that contains a symbolic -identifier for each resource.

        The names of the output files are specified -as parameters to epocrc. Note though that:

          -

        • resource files as built -by the project build tools (abld) have the default extension .rsc. -The additional naming conventions used when you need to supply multiple resource -files, each for a different locale, are discussed in How -to localise resources

          • -

        • by convention, the -header file has an extension .rsg

          • -

        The identifiers in the header file provide symbolic names for index -positions in the resource file, so that your source code can be independent -of the number and order of resources within the file. For a named resource -such as:

        RESOURCE TBUF r_eik_bafl_error_offset { buf="Wrong format resource file"; }

        the generated header file will have a #define such as:

        #define R_EIK_BAFL_ERROR_OFFSET 0xf3b045

        where -the number is a resource ID which encodes the resource index, and is suitable -for passing to the C++ function RResourceFile::AllocReadLC().

        In -the course of project development, changes to the resource file may not always -result in changes to the set of #define statements generated. -If there is no change, the rsg file is not rebuilt, thereby -avoiding unnecessary re-compilation and linking.

        -         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3542A39C-8D0F-53A0-A5A2-81F381D3BA7B_d0e315024_href.png Binary file Symbian3/SDK/Source/GUID-3542A39C-8D0F-53A0-A5A2-81F381D3BA7B_d0e315024_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3542A39C-8D0F-53A0-A5A2-81F381D3BA7B_d0e321494_href.png Binary file Symbian3/SDK/Source/GUID-3542A39C-8D0F-53A0-A5A2-81F381D3BA7B_d0e321494_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-35521A99-3F1F-5EE1-8078-FFD8A298C0BD_d0e192564_href.png Binary file Symbian3/SDK/Source/GUID-35521A99-3F1F-5EE1-8078-FFD8A298C0BD_d0e192564_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-35521A99-3F1F-5EE1-8078-FFD8A298C0BD_d0e197572_href.png Binary file Symbian3/SDK/Source/GUID-35521A99-3F1F-5EE1-8078-FFD8A298C0BD_d0e197572_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-35532303-1316-58CA-90C8-FAB56EE3C1F5.dita --- a/Symbian3/SDK/Source/GUID-35532303-1316-58CA-90C8-FAB56EE3C1F5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,44 +0,0 @@ - - - - - -version -

        version major.minor [explicit]

        -

        The version keyword allows a version number to be set -for a project. The optional keyword, explicit is used to -append the specified version number to the .exe or .dll output -file.

        -

        EKA1 will only allow one version of an executable to exist in a Symbian -platform phone. However, EKA2 supports version numbering. Version numbering -associates a version number with each executable enabling new and old versions -of the same executable to be on the device simultaneously.

        -

        The version keyword takes a major and a minor value separated -by a full stop. This value is defined as 32 bit, anything exceeding this will -produce a warning. Failing to enter a value will result in a warning and a -default value of 10.0 being supplied for binaries built with an EABI compliant -compiler. Omitting the version keyword altogether will also result in a default -of 10.0 being applied. The version number can be found at Hexadecimal offset -70 within the header of the executable file in ROM.

        -

        Usage of the version keyword is optional. One use is to aid eclipsing. -In order to eclipse a file on ROM successfully the version of the new file -can be set to a higher value than the version of the file to eclipse. This -tells the loader that the new file is preferred over the old one.

        -

        See the Important -Considerations section for more information.

        -

        The loader will show preference to versions that have a major number that -is equal to the one requested, and of these the minor numbers -that are higher are preferred. The loader can assume by the version number -that the API is compatible, while also being the most up to date version available.

        -

        If the above is not available the loader will look for DLLs with a higher -major version number than the one requested. Of these it will select the one -with the lowest major number and the highest minor number. If the executable -requests exports that no longer exist in this DLL, then the loader cannot -use it.

        -         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3560E862-CB68-584F-B9B6-FCD9F0D202DC_d0e254247_href.png Binary file Symbian3/SDK/Source/GUID-3560E862-CB68-584F-B9B6-FCD9F0D202DC_d0e254247_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3560E862-CB68-584F-B9B6-FCD9F0D202DC_d0e259157_href.png Binary file Symbian3/SDK/Source/GUID-3560E862-CB68-584F-B9B6-FCD9F0D202DC_d0e259157_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-356B54BB-E389-5562-A2D9-80A472EAC9A3_d0e8317_href.png Binary file Symbian3/SDK/Source/GUID-356B54BB-E389-5562-A2D9-80A472EAC9A3_d0e8317_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-356B54BB-E389-5562-A2D9-80A472EAC9A3_d0e8439_href.png Binary file Symbian3/SDK/Source/GUID-356B54BB-E389-5562-A2D9-80A472EAC9A3_d0e8439_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-358412B8-8B98-419F-99E6-28A01ED99B79_d0e4980_href.png Binary file Symbian3/SDK/Source/GUID-358412B8-8B98-419F-99E6-28A01ED99B79_d0e4980_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-358412B8-8B98-419F-99E6-28A01ED99B79_d0e5103_href.png Binary file Symbian3/SDK/Source/GUID-358412B8-8B98-419F-99E6-28A01ED99B79_d0e5103_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-358A2262-2C01-509D-AB33-665A9FFF8E04.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-358A2262-2C01-509D-AB33-665A9FFF8E04.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Dynamic Transaction Rollback Recovery
        Overview

        The server will automatically attempt to recover (repair) a damaged database during a transaction rollback. The database is closed and re-opened. As part of the re-opening the database is recovered.

        Implementation Considerations

        In the previous version of the Contacts Model the client could explicitly call the CContactDatabase::RecoverL() API for one of the two following reasons:

        • A call to the CContactDatabase::IsDamaged() API indicates the database is damaged

        • An observer receives the EContactDbObserverEventRollback event

        In both of these scenarios the dynamic transaction rollback recovery will remove the need to call the CContactDatabase::RecoverL() explicitly.

        Note that in out-of-memory conditions transaction rollback recovery cannot be guaranteed.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-35D49549-1F4D-583F-A45D-9B557A207DD2.dita --- a/Symbian3/SDK/Source/GUID-35D49549-1F4D-583F-A45D-9B557A207DD2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-35D49549-1F4D-583F-A45D-9B557A207DD2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,55 +1,44 @@ - - - - - -GlassTerm: -glass teletype terminal -
        Download

        Click on the following link to download -the example: GlassTerm.zip

        Download some additional files required -by the example: CommonFiles

        Click: browse to view the example code.

        View the additional -files: browse.
        -
        Description

        GlassTerm is a terminal application -with configurable handshaking that illustrates the use of the Serial Communications -API.

        -
        Class Summary

        RComm: serial port

        RCommServ: -Comms server

        TCommCaps: serial port capabilities -(in package buffer)

        TCommConfig: serial port configuration -(in package buffer)

        TRequestStatus: asynchronous -request status

        TSerialInfo: serial protocol information

        -
        Build

        The source code for this example application -can be found in the directory:

        examples\SerialComms\ServerClientSide\GlassTerm

        The -source code may be in the directory in which you installed the Symbian platform, -or it may be in src\common\developerlibrary\. The source -code includes the two project files needed for building the example: bld.inf and -the .mmp file.

        The -Symbian build process describes how to build this application, which -results in an executable called \epoc32\release\<target>\<urel -or udeb>\GLASSTERM.EXE.

        -
        Usage
          -

        1. Run the executable GLASSTERM.EXE.

          Executables -for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

          2. -

        2. Once running, the glass -teletype application performs two simple functions:

            -

          • Read any key presses -and send the characters to the serial port.

            • -

          • Receive any incoming -characters from the serial port and display them on screen.

            • -

          It sends and receives at 19200 baud, 8 data bits, no parity, 1 stop -bit.

          3. -

        In order to see the application working, you must make a suitable -serial port connection. A simple way is to connect a PC and a Symbian device, -and run the application on both machines simultaneously. (Before doing this, -make sure to close down any other applications using the serial port on the -PC, and set the device's Link To Desktop option -to Off). Characters typed on one machine are -then echoed to the application on the other.

        + + + + + +GlassTerm: glass teletype terminal +
        Download

        Click on the following link to download the example: GlassTerm.zip

        Download some additional +files required by the example: CommonFiles

        Click: browse to view the example code.

        View the +additional files: browse.
        +
        Description

        GlassTerm is a terminal application with configurable handshaking +that illustrates the use of the Serial Communications API.

        +
        Class +Summary

        RComm: serial port

        RCommServ: Comms server

        TCommCaps: serial port capabilities (in package buffer)

        TCommConfig: serial port configuration (in package buffer)

        TRequestStatus: asynchronous request status

        TSerialInfo: serial protocol information

        +
        Build

        The source code for this example application can be found in +the directory:

        examples\SerialComms\ServerClientSide\GlassTerm

        The source code may be in the directory in which you installed +the Symbian platform, or it may be in src\common\developerlibrary\. The source code includes the two project files needed for building +the example: bld.inf and the .mmp file.

        The Symbian build process describes how to build this +application, which results in an executable called \epoc32\release\<target>\<urel +or udeb>\GLASSTERM.EXE.

        +
        Usage
          +

        1. Run the executable GLASSTERM.EXE.

          Executables for the emulator targets wins and winscw can be run on your +PC. Executables for ARM targets must be copied to your target platform +before being run.

          2. +

        2. Once running, +the glass teletype application performs two simple functions:

            +

          • Read any key +presses and send the characters to the serial port.

            • +

          • Receive any +incoming characters from the serial port and display them on screen.

            • +

          It sends and receives at 19200 baud, 8 data bits, no parity, +1 stop bit.

          3. +

        In order to see the application working, you must make a +suitable serial port connection. A simple way is to connect a PC and +a Symbian device, and run the application on both machines simultaneously. +(Before doing this, make sure to close down any other applications +using the serial port on the PC, and set the device's Link To Desktop option to Off). Characters typed on one machine are then echoed to the application +on the other.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-35E9F104-95F7-511F-B0C5-AB64BCA972D0.dita --- a/Symbian3/SDK/Source/GUID-35E9F104-95F7-511F-B0C5-AB64BCA972D0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-35E9F104-95F7-511F-B0C5-AB64BCA972D0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ The diagram above shows the encryption and decryption process using: an asymmetric algorithm; a plaintext message, M; a private key, K1, and a public key, K2 (or vice versa); and the ciphertext, K1(M). - +

        Although it varies depending on the specific algorithm, the generation of asymmetric keys is much slower than symmetric key generation.

        There are four basic primitives in asymmetric cryptography: encryption and decryption, @@ -148,20 +148,20 @@ and also the CEncryptor, CDecryptor and CPadding abstract classes. Also shown are the following classes from the Cryptography API: TInteger, MCryptoSystem, CRSAPKCS1v15Decryptor, CRSAPKCS1v15Encryptor, CRSAPrivateKey, CRSAPublicKey, CRSAPrivateKeyStandard, CRSAPrivateKeyCRT, CRSAKeyPair, CPaddingPKCS7, CPaddingPKCS1Encryption, CPaddingNone, CPaddingPKCS1Signature, and CPaddingSSLv3. - + The inheritance diagram above shows the <codeph>CRSASigner</codeph> and <codeph>CRSAVerifier</codeph> classes. Also shown are the following classes from the Cryptography API: <codeph>MSignatureSystem</codeph>, <codeph>CSigner</codeph>, <codeph>CRSAPKCS1v15Signer</codeph>, <codeph>CRSAParameters</codeph>, <codeph>CRSAPrivateKey</codeph>, <codeph>CRSAPublicKey</codeph>, <codeph>CPadding</codeph>, <codeph>CPaddingPKCS1Signature</codeph>, <codeph>CVerifier</codeph>, and <codeph>CRSAPKCS1v15Verifier</codeph>. - +

        DSA and associated classes

        The inheritance diagram above shows the <codeph>CDSAParameters</codeph> class. Also shown are the following classes from the Cryptography API: <codeph>MSignatureSystem</codeph>, <codeph>TInteger</codeph>, <codeph>RInteger</codeph>, <codeph>CSigner</codeph>, <codeph>CDSASigner</codeph>, <codeph>CDSASignature</codeph>, <codeph>CDSAPrimeCertificate</codeph>, <codeph>CDSAKeyPair</codeph>, <codeph>CDSAPrivateKey</codeph>, <codeph>CDSAPublicKey</codeph>, <codeph>CVerifier</codeph>, and <codeph>CDSAVerifier</codeph>. - +

        DH and associated classes

        The inheritance diagram above shows the <codeph>CDHParameters</codeph> class. Also shown are the following classes from the Cryptography API: <codeph>TInteger</codeph>, <codeph>RInteger</codeph>, <codeph>CDHPrivateKey</codeph>, <codeph>CDHPublicKey</codeph>, <codeph>CDH</codeph>, and <codeph>CDHKeyPair</codeph>. - +
      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3603126B-661E-509B-8CCF-04A99F9ACE07.dita --- a/Symbian3/SDK/Source/GUID-3603126B-661E-509B-8CCF-04A99F9ACE07.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3603126B-661E-509B-8CCF-04A99F9ACE07.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,38 +1,33 @@ - - - - - -HelloWorld: -writes “Hello World!” to the console -
      Description

      HelloWorld is a very -simple piece of code showing how text is written to the console. All other -examples in Basics and System use -the same technique.

      The file CommonFramework.h contains -the entry point and all code necessary to support the example itself, including -the construction of the console and the cleanup stack. Putting code into a .h file -may not be conventional practice, but it is useful to do so here.

      -
      Download

      Click on the following link to download -the example: HelloWorld.zip

      Download some additional files -required by the example: CommonFramework.zip.

      Click browse to view the example code.

      Click browse to view the additional file.

      -
      Build

      The example includes the two project files -needed for building: bld.inf and the .mmp file.

      The Symbian platform build -process describes how to build this application, which results in an -executable called:

      \epoc32\release\<target>\<urel -or udeb>\HELLOWORLD.EXE.

      -
      Usage

      Run the executable HELLOWORLD.EXE.

      Executables -for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

      -
      Classes used

      The example shows the use of the _LIT macro -which is used throughout all of the examples. The macro generates a:

      const static TLitC<TInt>

      object -and is an efficient and convenient way of generating constant literal text.

      As -this is a wide (Unicode) build, TLItC<TInt> is a typedef -for TLitC16<TInt>.

      + + + + + +HelloWorld: writes “Hello World!” to the console +
      Description

      HelloWorld is a very simple piece of code showing how text is written to the +console. All other examples in Basics and System use the same technique.

      The file CommonFramework.h contains the entry point and all code +necessary to support the example itself, including the construction +of the console and the cleanup stack. Putting code into a .h file may not be conventional practice, but it is useful +to do so here.

      +
      Download

      Click on the following link to +download the example: HelloWorld.zip

      Download some additional +files required by the example: CommonFramework.zip.

      Click browse to view the example code.

      Click browse to view the additional file.

      +
      Build

      The example includes the two project +files needed for building: bld.inf and the .mmp file.

      The Symbian platform build process +describes how to build this application, which results in an executable +called:

      \epoc32\release\<target>\<urel +or udeb>\HELLOWORLD.EXE.

      +
      Usage

      Run the executable HELLOWORLD.EXE.

      Executables for the emulator targets wins and winscw can be run on your PC. Executables +for ARM targets must be copied to your target platform before being +run.

      +
      Classes used

      The example shows the use +of the _LIT macro which is used throughout all of +the examples. The macro generates a:

      const static TLitC<TInt>

      object and is an efficient and convenient way of generating constant +literal text.

      As this is a wide (Unicode) build, TLItC<TInt> is a typedef for TLitC16<TInt>.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36221068-4E6D-4E03-AF9A-AD9465F1C6B6_d0e63652_href.png Binary file Symbian3/SDK/Source/GUID-36221068-4E6D-4E03-AF9A-AD9465F1C6B6_d0e63652_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36221068-4E6D-4E03-AF9A-AD9465F1C6B6_d0e63795_href.png Binary file Symbian3/SDK/Source/GUID-36221068-4E6D-4E03-AF9A-AD9465F1C6B6_d0e63795_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36743EC8-5A64-5FF5-8632-56CBBD04EC12.dita --- a/Symbian3/SDK/Source/GUID-36743EC8-5A64-5FF5-8632-56CBBD04EC12.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,27 +0,0 @@ - - - - - -How -to initialise simple RESOURCE members -<simple-initialiser> -simple-initialiser ::= - <number> | <string> | <resource-identifier> -
        -

      • A BYTE, WORD, LONG or DOUBLE member must be initialised with a number. The number can be the result of -simple expressions such as 3+1 or NUM1+NUM2 where NUM1 and NUM2 have -been #defined earlier on in the file.

        • -

      • A TEXT, LTEXT or BUF member -must be initialised with a string. If a length-limit has -been declared for that member in the STRUCT definition then -an error will be generated if the string is longer than -the limit. You cannot override this maximum length.

        • -
      -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36AA53D2-A117-5D80-A5B4-67EF865DC40E.dita --- a/Symbian3/SDK/Source/GUID-36AA53D2-A117-5D80-A5B4-67EF865DC40E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -library

      library filename-list

      Use the library statement to specify import libraries.

      The library statement may specify any number of files, and there may be many library statements. Specify the entire filename, e.g. euser.lib or euser.dso for ARMv5 target builds.

      Note: When you are building for Symbian OS v9.4 and beyond, you may change the library file extension from .lib to .dso in the MMP file. The ABIv2 toolchain will still allow you to link for ARM builds. However, it fails to link when you build for WINSCW target. Therefore, to make it work on both, the ARM and WINSCW build targets, it is recommended that the library file names with .lib extension be used.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36BB14BD-34B3-4F5D-A670-707710E57585_d0e36549_href.png Binary file Symbian3/SDK/Source/GUID-36BB14BD-34B3-4F5D-A670-707710E57585_d0e36549_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36BB14BD-34B3-4F5D-A670-707710E57585_d0e36717_href.png Binary file Symbian3/SDK/Source/GUID-36BB14BD-34B3-4F5D-A670-707710E57585_d0e36717_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36F18DC4-7BD0-59C6-95E9-8FD945B86D7E_d0e233427_href.png Binary file Symbian3/SDK/Source/GUID-36F18DC4-7BD0-59C6-95E9-8FD945B86D7E_d0e233427_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36F18DC4-7BD0-59C6-95E9-8FD945B86D7E_d0e238407_href.png Binary file Symbian3/SDK/Source/GUID-36F18DC4-7BD0-59C6-95E9-8FD945B86D7E_d0e238407_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-36FD1F9A-FA1C-5822-A95F-720600E8F418.dita --- a/Symbian3/SDK/Source/GUID-36FD1F9A-FA1C-5822-A95F-720600E8F418.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-36FD1F9A-FA1C-5822-A95F-720600E8F418.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Contact Items Management

      A Contact Item is an element in a Contact Database. Contact Items can be added, read, edited and removed from the database. As the diagram below shows, a Contact Item can be:

      • a contact card - either generic cards (CContactCard) or the device owner's card (CContactOwnCard)

      • a template card (CContactTemplate) - a card that sets the initial fields for other Contact Items

      • a collection of Contact Items (CContactItemPlusGroup) - a group that holds a set of associated Contact Item IDs

      • a contact which maps to the device's ICC (CContactICCEntry) or SIM (CContactCard).

      Each Contact Item is uniquely identified in the database by a Contact Item ID (TContactItemId). More than one Contact Item ID is referred to using a Contact Item ID array (CContactIdArray).

      CONTACT ITEM HIERARCHY -

      Contact Items have an access count and attributes ('hidden', for example). The access count is a record of the number of objects referencing a Contact Item. A Contact Item cannot be fully deleted until its access count is zero.

      Note: Fields in a Contact Item also have attributes. Attribute values specified in the Contact Item override those in the contained fields.

      Contact Items are accessed through the CContactDatabase class. Opening a Contact Item (using CContactDatabase::OpenContactL()) locks it so that it cannot be edited by another client. Closing the Contact Item (using CContactDatabase::CloseContactL()) releases the lock on the item without saving any changes made to it. Committing the Contact Item (using CContactDatabase::CommitContactL()) releases the lock and saves any changes made to it.

      Contact Item Fields

      Each Contact Item contains a number of fields (CContactItemFieldSet). Each field (CContactItemField) in CContactItemFieldSet has a content type, (CContentType), and a storage type, (TStorageType) and the field data (CContactTextField, CContactStoreField, CContactAgentField or CContactDateField).

      A content type contains at least one UID, using TFieldType. A storage type identifies the type of data (text, binary, contact agent ID, date/time) stored in a Contact Item field. As numeric field data is not supported all numbers are stored as text.

      Each field can also have a label which identifies the field to a user, for example, first name, last name. Fields can have attributes assigned to them such as hidden, disabled, synchronised, read only, user added, template and speed dial.

      Contact Groups

      A Contact Group (CContactGroup class) is a Contact Item which holds a set of associated Contact Item IDs. The members of the group may be contact cards, own cards, or even other groups. The group has a label which identifies the group such as 'family', or 'colleagues' to users. The type of a Contact Group is KUidContactGroup, as returned by CContactGroup::Type().

      It is possible to construct a group using CContactGroup::CreateContactGroupL(). These functions create the group, optionally with a label, add it to the database, and return a pointer to it. To create an association between a card and a group, use CContactDatabase::AddContactToGroupL(). To remove the association, use CContactDatabase::RemoveContactFromGroupL(). To find out which groups a card belongs to, use CContactCard::GroupsJoinedLC() or CContactOwnCard::GroupsJoinedLC().

      \ No newline at end of file +

      Contact Items have an access count and attributes ('hidden', for example). The access count is a record of the number of objects referencing a Contact Item. A Contact Item cannot be fully deleted until its access count is zero.

      Note: Fields in a Contact Item also have attributes. Attribute values specified in the Contact Item override those in the contained fields.

      Contact Items are accessed through the CContactDatabase class. Opening a Contact Item (using CContactDatabase::OpenContactL()) locks it so that it cannot be edited by another client. Closing the Contact Item (using CContactDatabase::CloseContactL()) releases the lock on the item without saving any changes made to it. Committing the Contact Item (using CContactDatabase::CommitContactL()) releases the lock and saves any changes made to it.

      Contact Item Fields

      Each Contact Item contains a number of fields (CContactItemFieldSet). Each field (CContactItemField) in CContactItemFieldSet has a content type, (CContentType), and a storage type, (TStorageType) and the field data (CContactTextField, CContactStoreField, CContactAgentField or CContactDateField).

      A content type contains at least one UID, using TFieldType. A storage type identifies the type of data (text, binary, contact agent ID, date/time) stored in a Contact Item field. As numeric field data is not supported all numbers are stored as text.

      Each field can also have a label which identifies the field to a user, for example, first name, last name. Fields can have attributes assigned to them such as hidden, disabled, synchronised, read only, user added, template and speed dial.

      Contact Groups

      A Contact Group (CContactGroup class) is a Contact Item which holds a set of associated Contact Item IDs. The members of the group may be contact cards, own cards, or even other groups. The group has a label which identifies the group such as 'family', or 'colleagues' to users. The type of a Contact Group is KUidContactGroup, as returned by CContactGroup::Type().

      It is possible to construct a group using CContactGroup::CreateContactGroupL(). These functions create the group, optionally with a label, add it to the database, and return a pointer to it. To create an association between a card and a group, use CContactDatabase::AddContactToGroupL(). To remove the association, use CContactDatabase::RemoveContactFromGroupL(). To find out which groups a card belongs to, use CContactCard::GroupsJoinedLC() or CContactOwnCard::GroupsJoinedLC().

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37042E73-123B-437B-8EC4-8FC6C3AD6D47_d0e4458_href.png Binary file Symbian3/SDK/Source/GUID-37042E73-123B-437B-8EC4-8FC6C3AD6D47_d0e4458_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37042E73-123B-437B-8EC4-8FC6C3AD6D47_d0e4585_href.png Binary file Symbian3/SDK/Source/GUID-37042E73-123B-437B-8EC4-8FC6C3AD6D47_d0e4585_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37057FD5-7ED0-5B18-9C28-39F6816D7627.dita --- a/Symbian3/SDK/Source/GUID-37057FD5-7ED0-5B18-9C28-39F6816D7627.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,71 +0,0 @@ - - - - - -Arrays -within structs -

      A declaration of a struct member may either be a simple type-name member-name, -or it may be an array of values of identical type.

      -

      Arrays are always indicated by square brackets:

      -STRUCT HAS_ARRAY - { - STRUCT elements[]; - } -

      In the example above, the HAS_ARRAY struct has one array -member, elements. Each member of elements is -of STRUCT type.

      -

      Array size

      -

      If you specify the array size, inside the square brackets, then the generated -resource will contain no count of the number of elements. So this resource:

      -STRUCT FIXED_ARRAY - { - WORD elements[3]; - } - -RESOURCE FIXED_ARRAY example1 - { - elements={9,8,7}; - } -

      will generate the output

      -0x09 0x00 0x08 0x00 0x07 0x00 -

      For variable length arrays, a count of the number of elements precedes -the resource. The default for this is a word, but by prefixing the struct -definition with LEN BYTE it will be a byte count. So the -following resource:

      -STRUCT VAR_ARRAY - { - WORD elements []; - } - -RESOURCE VAR_ARRAY example2 - { - elements={9,8,7}; - } -

      will generate the output

      -0x03 0x00 0x09 0x00 0x08 0x00 0x07 0x00 -

      whereas this resource:

      -STRUCT VAR_ARRAY2 - { - LEN BYTE WORD elements[]; - } - -RESOURCE VAR_ARRAY2 example3 - { - elements={9,8,7}; - } -

      will generate this output

      -0x03 0x09 0x00 0x08 0x00 0x07 0x00 -

      The compiler allows you to prefix LEN BYTE or LEN -WORD even for fixed length arrays, but it has no effect. Fixed length -arrays do not generate an element count.

      -       -How to initialise -array RESOURCE members -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-377B04D8-4E8B-54C7-AE7F-8BD47CB81758_d0e10475_href.png Binary file Symbian3/SDK/Source/GUID-377B04D8-4E8B-54C7-AE7F-8BD47CB81758_d0e10475_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-377B04D8-4E8B-54C7-AE7F-8BD47CB81758_d0e10591_href.png Binary file Symbian3/SDK/Source/GUID-377B04D8-4E8B-54C7-AE7F-8BD47CB81758_d0e10591_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37888891-DFB2-5A93-9547-3B22410906BF_d0e299302_href.png Binary file Symbian3/SDK/Source/GUID-37888891-DFB2-5A93-9547-3B22410906BF_d0e299302_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37888891-DFB2-5A93-9547-3B22410906BF_d0e305774_href.png Binary file Symbian3/SDK/Source/GUID-37888891-DFB2-5A93-9547-3B22410906BF_d0e305774_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-379D9401-04A2-4A32-A3BF-C6F127E8F074_d0e4687_href.png Binary file Symbian3/SDK/Source/GUID-379D9401-04A2-4A32-A3BF-C6F127E8F074_d0e4687_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-379D9401-04A2-4A32-A3BF-C6F127E8F074_d0e4813_href.png Binary file Symbian3/SDK/Source/GUID-379D9401-04A2-4A32-A3BF-C6F127E8F074_d0e4813_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37C193CD-3D8A-56A5-B78C-0A6FE7163EC2_d0e324269_href.png Binary file Symbian3/SDK/Source/GUID-37C193CD-3D8A-56A5-B78C-0A6FE7163EC2_d0e324269_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37C193CD-3D8A-56A5-B78C-0A6FE7163EC2_d0e330739_href.png Binary file Symbian3/SDK/Source/GUID-37C193CD-3D8A-56A5-B78C-0A6FE7163EC2_d0e330739_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37D2EFAE-FB55-5015-90CE-1361144C411E_d0e220875_href.png Binary file Symbian3/SDK/Source/GUID-37D2EFAE-FB55-5015-90CE-1361144C411E_d0e220875_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37D2EFAE-FB55-5015-90CE-1361144C411E_d0e225869_href.png Binary file Symbian3/SDK/Source/GUID-37D2EFAE-FB55-5015-90CE-1361144C411E_d0e225869_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37DCD20D-E123-5B62-976D-F91AD99A765D_d0e323490_href.jpg Binary file Symbian3/SDK/Source/GUID-37DCD20D-E123-5B62-976D-F91AD99A765D_d0e323490_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37DCD20D-E123-5B62-976D-F91AD99A765D_d0e329960_href.jpg Binary file Symbian3/SDK/Source/GUID-37DCD20D-E123-5B62-976D-F91AD99A765D_d0e329960_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita --- a/Symbian3/SDK/Source/GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-37E8A48E-09B8-5958-9263-B33EDAE3F7C6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ own controls and indirectly through derived classes provided by UIKON and AVKON.

      Cone architectural relationships - +
    Description

    Controls

    A control is a rectangular area of a window that may respond to user input. @@ -34,7 +34,7 @@ when its container control is redrawn.

    The following diagram shows simple controls in orange and container controls in grey.

    Simple and compound controls - +

    Controls and Windows

    A window may be considered as a transparent layer. Windows are managed by the Window Server and described elsewhere. A control provides a means of access to a window - it can be drawn onto the window and diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-38089CC3-D969-5501-9FDA-BB0369D5D6A9_d0e280262_href.png Binary file Symbian3/SDK/Source/GUID-38089CC3-D969-5501-9FDA-BB0369D5D6A9_d0e280262_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-38089CC3-D969-5501-9FDA-BB0369D5D6A9_d0e285101_href.png Binary file Symbian3/SDK/Source/GUID-38089CC3-D969-5501-9FDA-BB0369D5D6A9_d0e285101_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-380A8C4F-3EB6-5E1C-BCFB-ED5B866136D9.dita --- a/Symbian3/SDK/Source/GUID-380A8C4F-3EB6-5E1C-BCFB-ED5B866136D9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,157 +0,0 @@ - - - - - -How -to use UIDs -

    A UID is a globally unique identifier consisting of a 32-bit number.

    -

    In Symbian platform, objects are identified by a compound identifier, known -as the UID type, which is constructed from three 32 bit -identifiers. The individual UIDs making up the UID type are referred to as UID1, UID2 and UID3.

    -

    Symbian platform makes widespread use of UIDs:

    -
      -

    • UIDs are used to identify -the types of objects at runtime and loadtime, for example identifying executables, -DLLs, filestores.

      • -

    • UIDs are used to verify -that objects present compatible and expected interfaces at runtime and loadtime, -for example verifying that DLLs or filestores are of the expected type.

      • -

    • UIDs are fundamental -to the association of applications with documents. For example, associating -a document with an application allows the system to launch the application -when the document is opened.

      • -
    -

    A file's three UIDs are stored in the first 12 bytes of the file.

    -

    To program successfully, Symbian developers need to understand why and -how to use UIDs in their programs.

    -
    What UIDs are for

    From a user's point of view, -conventional file names are preferable to UIDs for file identification. Symbian -platform therefore supports a flexible, long filename, file naming scheme.

    However -from a system point of view, guaranteed unique, 32-bit numbers provide for -much safer, systematic, and more lightweight identification.

    UID1, -UID2 and UID3 have the following general characteristics:

      -

    • UID1 indicates -the structure of the file, for example, whether it is an executable, a DLL -or a file store.

      • -

    • The meaning of UID2 depends -on the type of object it applies to. For polymorphic interface (plug-in framework) -DLLs, UID2 identifies the interface that the DLL implements. For static interface -(shared library) DLLs that others link to, the UID2 value is always the same. -For executables the UID value has to be set to KUidApp or NULL.

      • -

    • UID3 distinguishes -between objects with the same UID2 and can be thought of as a project identifier. -For example, for an application, the same UID3 is shared by the executable, -registration file (which defines the application's icon, caption, and some -capability information), and all documents.

      The SECUREID need -not be explicitly specified in the .mmp file, but if it is omitted, then the -value of the UID3, specified elsewhere in the .mmp file, is used. If the UID3 -is not specified, then the secureid will take the value KNullUID. -This has several consequences, including lack of privacy for data used by -that application.

      • -

    The UID type is a TUidType object and is constructed -from a combination of all or some of the three possible UIDs. The UID type -can be queried to return its component UID1, UID2 and UID3 values.

    If -no UIDs are attached to an object, then all three component UIDs are returned -as KUidNull.

    -
    UID1, UID2, UID3, and the no UIDs case

    An object -in Symbian platform and more particularly files in Symbian platform may have -all, some, or none of the three possible UIDs defined.

    Symbian platform -predefines all possible UID1 values and the UID2 values used for GUI applications -and static interface DLLs at system level. Symbian developers refer to them -by their constant names, although in project (.mmp) files, -hexadecimal numbers are used.

      -

    • UID1: examples include KExecutableImageUid, KDynamicLibraryUid and KDirectFileStoreLayoutUid

      • -

    • UID2: examples include KSharedLibraryUid (0x1000008d) -for a static interface DLL and KUidApp (0x100039CE) or NULL -for a GUI application. Note: Both KUidApp and NULL -are acceptable values for UID2 when the application is an EXE, although at -the present time these values are ignored. At a later stage UID2 may be used -for other purposes, so setting UID2 to values outside of these values is not -recommended.

      • -

    • Symbian developers are -responsible for ensuring that where UID3 values are required, they are properly -allocated. See the Symbian -Signed web site for information on how to allocate UIDs (free registration -is required to see the FAQ).

      • -

    Note that in project (.mmp) files, UID2 and -UID3 values can be specified, but UID1 values cannot; the UID1 value is implied -by the project's target type.

    -
    EXE targets and UIDs

    All executable targets have -a UID1 of KExecutableImageUid. This is defined by Symbian -platform and is automatically built into any executable target based on the exe target -type declared in the project file.

    A UID2 value should be specified -by GUI applications (.EXE) and the application architecture expects this to -be KUidApp (0x100039CE) or NULL. Console applications (also -.EXE), which are often used for testing and as example code, do not need to -specify a UID2, and if they do, it is ignored.

    -
    DLLs and UIDs

    All DLLs, whether they have static -or polymorphic interfaces, have a UID1 of KDynamicLibraryUid. -This is defined by Symbian platform and is automatically built into any DLL -target based on the dll target type declared in the project -file.

    For static interface DLLs, the UID2 is KSharedLibraryUid. The -UID3, which is used to identify the interface to the library, must be allocated -by Symbian Signed.

    For polymorphic DLLs (for instance ECom plugins, -device drivers and front end processors), UID2 identifies the interface that -the DLL implements. UID3 (which, if required, must be allocated by Symbian -Signed) may be used to identify a specific implementation of that interface.

    -
    Documents and UIDs

    In Symbian platform, documents -are really file-stores: stores which can be closed and re-opened. There are -two different kinds of file store, direct file stores which -are write-once-read-many, and permanent file stores which -are write-many-read-many.

    A document's UID1 will therefore be one -of KDirectFileStoreLayoutUid or KPermanentFileStoreLayoutUid. -The UID2 and/or UID3 will be application dependent.

    Every native document -must have an appropriate UID1 which should be set by the application which -creates the document. Typically documents may have a UID2 of KUidAppDllDoc and -a UID3 shared with the creating application. More precisely, a document’s -UID3 should match that of the application which will open it.

    Only -the UID1 is required, but in most cases Symbian developers will want to specify -second and third UIDs for the documents their applications create and use. -These UIDs are used by the application architecture framework to manage associations -between applications and their documents. This allows an application to be -found and launched when a file is opened, and it also allows an application -icon to be associated with documents in system shell displays. Conversely, -it allows an application, when opening files, to select only applicable files.

    Symbian -platform also allows default file associations with the implication that in -some cases users may want to select a different application to open a file. -Applications which support this must therefore be able to open documents whose -third UID differs from their own.

    Applications may also want to open -non-native documents which have no UIDs, and may wish to be specified as default -applications for these documents.

    -
    UIDs in package files

    Package (.PKG) files are -used in Symbian platform to provide the information required to create Symbian -installation (.SIS) files. Each SIS file contains a UID, which is defined -in the package file's package -header. This UID should be allocated in the same way -as other UIDs, through Symbian Signed.

    -
    Uniqueness -and allocation

    Because UIDs are fundamental to Symbian platform, -it is important that they are used correctly when developing programs. To -ensure uniqueness, it is essential that UIDs are properly allocated.

    Uniqueness -is guaranteed by managing allocation centrally from a single database. All -UIDs must therefore be assigned to users by a central allocating authority.

    UIDs -are also split into protected and unprotected ranges. Any UID values falling -below 0x7FFFFFFF are classed as "protected" and are only intended for use -with signed applications (or those pre-installed in ROM). The software installer -will refuse to install an unsigned application if it uses a package UID in -the protected range.

    Symbian developers can request UIDs through https://www.symbiansigned.com. -For more information, see the Symbian Signed FAQ (free registration required). -Note that from version 9 of Symbian platform, UIDs are no longer requested -from uid@symbiandevnet.com.

    -
    Reserved UID range for development only

    During development, -or for test code, temporary UIDs may be chosen from the unprotected test range -0xExxxxxxx. These UIDs can be used during development for unsigned applications -but must not be used in released software. Note that such applications may -not be installable via a SIS file. See the Symbian Signed website for more -information.

    Care must still be taken to avoid clashes within development -teams and between multiple projects, including old projects which may still -be installed on a Symbian emulator or native platforms. UID clashes may stop -a program from loading correctly, typically leading to Not Found errors.

    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3829BD20-3DCB-5489-8FC4-07F954E391BF.dita --- a/Symbian3/SDK/Source/GUID-3829BD20-3DCB-5489-8FC4-07F954E391BF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3829BD20-3DCB-5489-8FC4-07F954E391BF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ use a TFindHandleBase derived class to locate a global Kernel object. The following diagram shows the general idea.

    - +

    See also:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-382B8A9D-9D10-54CD-91A6-B9E7A2477662.dita --- a/Symbian3/SDK/Source/GUID-382B8A9D-9D10-54CD-91A6-B9E7A2477662.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-382B8A9D-9D10-54CD-91A6-B9E7A2477662.dita Tue Jul 20 12:00:49 2010 +0100 @@ -73,10 +73,10 @@

    • CMsvOperationWait

    • RSendAsMessage

    -
    Build

    The Symbian -build process describes how to build an application.

    The SendAs example builds an executable called SendAs2Example.exe in the standard location (\epoc32\release\winscw\ <build_variant> for CodeWarrior). After launching the -executable, depending on the emulator you are using, you may need -to task away from the app launcher/shell screen to view the console.

    +
    Build

    The Symbian build process describes how to build an application.

    The SendAs example builds an executable called SendAs2Example.exe in the standard location (\epoc32\release\winscw\ <build_variant> for +CodeWarrior). After launching the executable, depending on the emulator +you are using, you may need to task away from the app launcher/shell +screen to view the console.

    See also

    To create advanced applications using the SendAs API refer to the complete SendAs API diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-383A617C-474B-509D-BA37-3515BCC5F1D1.dita --- a/Symbian3/SDK/Source/GUID-383A617C-474B-509D-BA37-3515BCC5F1D1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,27 +0,0 @@ - - - - - -CHARACTER_SET -statement -<character_set-statement> -character_set-statement ::= -CHARACTER_SET <character_set-name> -

    Use a CHARACTER_SET statement to define the character -set to be used. The permitted values for character_set-name are -defined as:

    -<character_set-name> -character_set-name ::= -CP1252 | UTF8 - -

    If the CHARACTER_SET statement is omitted from a resource -file, character set CP1252 is taken as default.

    -CHARACTER_SET UTF8 - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-383A96FD-99C3-593C-B7A2-58153F4050DE_d0e364630_href.png Binary file Symbian3/SDK/Source/GUID-383A96FD-99C3-593C-B7A2-58153F4050DE_d0e364630_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-383A96FD-99C3-593C-B7A2-58153F4050DE_d0e383779_href.png Binary file Symbian3/SDK/Source/GUID-383A96FD-99C3-593C-B7A2-58153F4050DE_d0e383779_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3853600F-A096-53A6-8E68-4815ED85FD05_d0e176377_href.png Binary file Symbian3/SDK/Source/GUID-3853600F-A096-53A6-8E68-4815ED85FD05_d0e176377_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3853600F-A096-53A6-8E68-4815ED85FD05_d0e181402_href.png Binary file Symbian3/SDK/Source/GUID-3853600F-A096-53A6-8E68-4815ED85FD05_d0e181402_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-38FF81FD-0C23-586D-AFAE-9F0761A36BAD_d0e213777_href.png Binary file Symbian3/SDK/Source/GUID-38FF81FD-0C23-586D-AFAE-9F0761A36BAD_d0e213777_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-38FF81FD-0C23-586D-AFAE-9F0761A36BAD_d0e218775_href.png Binary file Symbian3/SDK/Source/GUID-38FF81FD-0C23-586D-AFAE-9F0761A36BAD_d0e218775_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39186342-960A-46A4-BC35-851F53665FA8.dita --- a/Symbian3/SDK/Source/GUID-39186342-960A-46A4-BC35-851F53665FA8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-39186342-960A-46A4-BC35-851F53665FA8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,8 +12,8 @@ Writing the Version 3 Registration Resource FileThe version 3 registration resource file is an evolution of the version 2 . This version is evolved to accommodate extended interfaces. - -Set Info_format + +Set Info_format to the type of info record that is, IMPLEMENTATION_INFO or BINARY_IMPLEMENTATION_INFO. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-395C240D-6487-5832-B5F6-FC92991001FE_d0e357275_href.png Binary file Symbian3/SDK/Source/GUID-395C240D-6487-5832-B5F6-FC92991001FE_d0e357275_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-395C240D-6487-5832-B5F6-FC92991001FE_d0e376424_href.png Binary file Symbian3/SDK/Source/GUID-395C240D-6487-5832-B5F6-FC92991001FE_d0e376424_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-399F7F7D-3E8E-58BB-9925-9F34C561C39A_d0e299332_href.png Binary file Symbian3/SDK/Source/GUID-399F7F7D-3E8E-58BB-9925-9F34C561C39A_d0e299332_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-399F7F7D-3E8E-58BB-9925-9F34C561C39A_d0e305804_href.png Binary file Symbian3/SDK/Source/GUID-399F7F7D-3E8E-58BB-9925-9F34C561C39A_d0e305804_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39A8FBC9-5FD6-4F92-B71E-5C5438ECFD46.dita --- a/Symbian3/SDK/Source/GUID-39A8FBC9-5FD6-4F92-B71E-5C5438ECFD46.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-39A8FBC9-5FD6-4F92-B71E-5C5438ECFD46.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,14 +12,14 @@ OOM Monitor OverviewThis section provides an overview of the functionality and the architecture of the OOM Monitor component. -
    Purpose

    The +

    Purpose

    The OOM Monitor Client API monitors the memory situations and handles out of memory situations. OOM monitor is responsible to maintain good memory level in the device. In case of low memory situation, OOM Monitor releases memory by closing applications based on the priority defined. For information on priority, refer to OOM Monitor Priority.

    -
    Key concepts
    +
    Key concepts
    LOW_RAM_THRESHOLD

    It is the minimum amount of free RAM that is specified for the device. @@ -39,19 +39,19 @@

    For information on OOM Monitor Priority and Optional RAM allocation, refer to OOM Monitor Concepts

    -
    Architecture

    The +

    Architecture

    The basic function of the OOM Monitor is to monitor the amount of free RAM in the mobile device. Whenever the amount of free RAM decreases below a defined LOW_RAM_THRESHOLD threshold value, the OOM Monitor is triggered. The OOM Monitor then releases RAM by closing applications running on background in order to raise the amount of free RAM above the defined GOOD_RAM_THRESHOLD value.

    - + - +
    -
    APIs

    The +

    APIs

    The OOM Monitor Client API consists of ROomMonitorSession class. -The main functions of this class are:

    +The main functions of this class are:

    @@ -74,7 +74,7 @@

    The OOM Monitor Client API also consists of COomMonitorPlugin class. -The main functions of this plug-in class are:

    +The main functions of this plug-in class are:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39A995DC-F047-4B41-A60D-27063CE329BE.dita --- a/Symbian3/SDK/Source/GUID-39A995DC-F047-4B41-A60D-27063CE329BE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-39A995DC-F047-4B41-A60D-27063CE329BE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -38,7 +38,7 @@ steps until the necessary level of protection is achieved.

    -Security development process +Security development process

    The security development process is guided by cost, efficiency, and usability. If security is too tight, this may be expensive and affect both performance and the user's experience of the system or software. On the other hand, if diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39AAB0D3-6D4D-5DE3-B894-F5E763D3E19B_d0e244607_href.png Binary file Symbian3/SDK/Source/GUID-39AAB0D3-6D4D-5DE3-B894-F5E763D3E19B_d0e244607_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39AAB0D3-6D4D-5DE3-B894-F5E763D3E19B_d0e249566_href.png Binary file Symbian3/SDK/Source/GUID-39AAB0D3-6D4D-5DE3-B894-F5E763D3E19B_d0e249566_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-39B5850D-EAAD-56BC-B75A-2104033814E6.dita --- a/Symbian3/SDK/Source/GUID-39B5850D-EAAD-56BC-B75A-2104033814E6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-39B5850D-EAAD-56BC-B75A-2104033814E6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ one or more audio streams can be grouped into a logical unit called a context. The following diagram shows a context which contains two audio streams:

    Audio streams in a context - +

    Using a context means that, for the purposes of pre-emption, all audio streams in the context can be controlled as a single unit. For example, if an audio stream needs to be stopped because it uses a resource that is diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A05CD69-0AB6-5549-B18A-842F49C06874.dita --- a/Symbian3/SDK/Source/GUID-3A05CD69-0AB6-5549-B18A-842F49C06874.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -prj_exports

    prj_exports

    source_file_1 [destination_file]

    source_file_n [destination_file]

    :zip zip_file [destination_path]

    In the prj_exports section, list any files to be copied from the source directories to the releasables’ directories during the building of a component. It is intended mainly for specifying C++ header files to be copied to the directory epoc32\include\.

    Specify each file on a separate line.

    Note that:

    • If a source file is listed with a relative path, the path will be considered relative to the directory containing the bld.inf file.

    • If a destination file is not specified, the source file will be copied to epoc32\include\.

    • If a destination file is specified with the relative path, the path will be considered relative to directory epoc32\include\.

    • If a destination begins with a drive letter, then the file is copied to epoc32\data\<drive_letter>\<path>. For example,

      mydata.dat e:\appdata\mydata.dat

      copies mydata.dat to epoc32\data\e\appdata\mydata.dat.

      You can use any driveletter between A and Z.

    • A line can start with the preface :zip. This instructs the build tools to unzip the specified zip file to the specified destination path. If a destination path is not specified, the source file will be unzipped in the root directory.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A506E2A-2999-458B-BBA2-DCC4D2EA5492_d0e41135_href.png Binary file Symbian3/SDK/Source/GUID-3A506E2A-2999-458B-BBA2-DCC4D2EA5492_d0e41135_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A506E2A-2999-458B-BBA2-DCC4D2EA5492_d0e41293_href.png Binary file Symbian3/SDK/Source/GUID-3A506E2A-2999-458B-BBA2-DCC4D2EA5492_d0e41293_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A6BEF56-ADBF-543E-B70A-52195DE3E92A.dita --- a/Symbian3/SDK/Source/GUID-3A6BEF56-ADBF-543E-B70A-52195DE3E92A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3A6BEF56-ADBF-543E-B70A-52195DE3E92A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@ on behalf of all clients.

    Calendar's implementation of import and export behaviour is done using the AgnVersit2 plug-in.

    Calendar dependencies - +
    Description

    This document describes the following key areas:

    The Calendar Server

    The diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A8755A9-139E-4845-9B52-13AEECF9EBBD_d0e52689_href.png Binary file Symbian3/SDK/Source/GUID-3A8755A9-139E-4845-9B52-13AEECF9EBBD_d0e52689_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3A8755A9-139E-4845-9B52-13AEECF9EBBD_d0e52832_href.png Binary file Symbian3/SDK/Source/GUID-3A8755A9-139E-4845-9B52-13AEECF9EBBD_d0e52832_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51732_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51732_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51813_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51813_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51875_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51875_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51956_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e51956_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e57765_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e57765_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e57908_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e57908_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e58473_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e58473_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e58616_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e58616_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e68976_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e68976_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69000_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69000_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69055_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69055_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69079_href.png Binary file Symbian3/SDK/Source/GUID-3AA34D0C-539D-4D4E-9337-EB5B83AEF4C1_d0e69079_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AF1F492-3D7D-5F8C-B1AE-16FBD8224775.dita --- a/Symbian3/SDK/Source/GUID-3AF1F492-3D7D-5F8C-B1AE-16FBD8224775.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3AF1F492-3D7D-5F8C-B1AE-16FBD8224775.dita Tue Jul 20 12:00:49 2010 +0100 @@ -66,7 +66,7 @@ used by text strings.

    Resource File Interface

    Resource files contain data in numbered resources. A resource file has the following format:

    - +

    A resource file is generated from text input using the resource compiler. The index can be used to efficiently find a resource given its numeric ID. There can be 1 to 4095 resources in a resource file. Each resource contains @@ -86,7 +86,7 @@ in resource file usage

    The file types involved in resource file usage are defined in the following diagram:

    File types - +

    These files work together as follows:

    • the C++ compiler and linker, together, take .cpp source files and produce .exe output diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3AFA877F-41DE-5343-8BC2-C0FB894A062C.dita --- a/Symbian3/SDK/Source/GUID-3AFA877F-41DE-5343-8BC2-C0FB894A062C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Application registration information \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3B0602F1-4294-43C4-9E7A-B1A33291C22F.dita --- a/Symbian3/SDK/Source/GUID-3B0602F1-4294-43C4-9E7A-B1A33291C22F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3B0602F1-4294-43C4-9E7A-B1A33291C22F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,8 +28,8 @@ Monitor Server API) and avoid polling and keep-alives. If the application protocol mandates the use of timers, they should be tuned so that the control data over the air is minimized.

      - -Defining + +Defining Connection Management Items Prompting diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3B2957D0-4D1A-5289-BE2A-AC8CD34A54E6_d0e266338_href.png Binary file Symbian3/SDK/Source/GUID-3B2957D0-4D1A-5289-BE2A-AC8CD34A54E6_d0e266338_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3B2957D0-4D1A-5289-BE2A-AC8CD34A54E6_d0e271193_href.png Binary file Symbian3/SDK/Source/GUID-3B2957D0-4D1A-5289-BE2A-AC8CD34A54E6_d0e271193_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita --- a/Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,81 +1,81 @@ - - - - - -Process -identification -

      Sometimes it is useful for security reasons to obtain more information -about server or application processes, and identify an application and even -its vendor uniquely.

      -
        -

      • To verify an application's identity, use RApaLsSession to retrieve the application's name and Unique Identifier UID, -and compare them against known information.

        For more information, -see UID.

        -
        • -

      • Use the TApaTaskList class -to get a list of currently running applications.

        In the platform -security architecture there are two different identifiers for applications: -Secure Identifier (SID) and Vendor Identifier (VID).

        • -
      -

      Secure Identifier -(SID)

      -

      Every executable has its own Secure Identifier (SID), which is -used to identify the running process launched from the executable. It can -also be used to determine which private directory a process can access. SID -is stored in the executable binary, so it has the same security as any executable -code. The SID value is not relevant for dll.

      -

      SID values are requested from the Symbian -Signed web site. The Software -Installer ensures that no two applications have the same SID value -on a particular target device.

      -

      To retrieve the SID of a process, use the RProcess::SecureId() method . During inter process communication, use the TSecurityPolicy class to specify a security policy consisting of both capability and -SID checks.

      -

      For information on how to define the SID in the mmp file, -see secureid. -If SID is not specified in the mmp file, the value of UID3 -is used as the SID.

      -

      Vendor Identifier -(VID)

      -

      In addition to SID, signed applications have a Vendor Identifier (VID) -which can be used to identify the source of the application. Applications -from one vendor usually share a common VID, but the vendor may have different -VIDs for different product families. VIDs can also be used to group servers -and clients into logical groups providing services to each other.

      -

      Note that the VID cannot be reused for any other entity. For example, -the Nokia VID (0x101FB657) is property of Nokia.

      -

      For information on how to define the VID in the mmp file, -see vendorid.

      -
      Secure inter -process communication -

      Authentication can be done in different ways. The server can decide -to request (or not to request) capabilities from the client. The client's -options are more limited, the server is usually authenticated by name. The ProtServ capability allows -the server to insert an "!" in front of its name, indicating that the server -can be trusted. Nameless servers are also possible, but no client can connect -to them without a handle to the server. The server can also authenticate the -client with SID and VID.

      -

      Every server should define the following security policies:

      -
        -

      • Which capabilities are required by the calling application

        -
        • -

      • Which SID and VID are required by the calling application

        -
        • -

      • What actions are possible or must be done with the information -provided:

        -
          -

        • Can input data be trusted?

          • -

        • Is user acceptance needed for this operation?

          • -

        • Can this server act as a proxy towards other components?

          -
          • -
        -
        • -
      -
      + + + + + +Process identification +

      Sometimes it is useful for security reasons to obtain more information +about server or application processes, and identify an application +and even its vendor uniquely.

      +
        +

      • To verify an application's identity, use RApaLsSession to retrieve the application's +name and Unique Identifier UID, and compare them against known +information.

        For more information, see UID.

        +
        • +

      • Use the TApaTaskList class to get a list of currently +running applications.

        In the platform security architecture +there are two different identifiers for applications: Secure Identifier +(SID) and Vendor Identifier (VID).

        • +
      +

      Secure Identifier +(SID)

      +

      Every executable has its own Secure Identifier (SID), +which is used to identify the running process launched from the executable. +It can also be used to determine which private directory a process +can access. SID is stored in the executable binary, so it has the +same security as any executable code. The SID value is not relevant +for dll.

      +

      SID values are requested from the Symbian Signed web site. +The Software +Installer ensures that no two applications have the same SID +value on a particular target device.

      +

      To retrieve the SID of a process, use the RProcess::SecureId() method . During inter +process communication, use the TSecurityPolicy class to specify a security +policy consisting of both capability and SID checks.

      +

      For information on how to define the SID in the mmp file, see secureid. If SID is not specified in +the mmp file, the value of UID3 is used as the SID.

      +

      Vendor Identifier +(VID)

      +

      In addition to SID, signed applications have a Vendor Identifier (VID) which can be used to identify the source of the application. +Applications from one vendor usually share a common VID, but the vendor +may have different VIDs for different product families. VIDs can also +be used to group servers and clients into logical groups providing +services to each other.

      +

      Note that the VID cannot be reused for any other entity. For +example, the Nokia VID (0x101FB657) is property of +Nokia.

      +

      For information on how to define the VID in the mmp file, see vendorid.

      +
      Secure +inter process communication +

      Authentication can be done in different ways. The server can +decide to request (or not to request) capabilities from the client. +The client's options are more limited, the server is usually authenticated +by name. The ProtServ capability allows the server to insert an "!" in front of its name, indicating +that the server can be trusted. Nameless servers are also possible, +but no client can connect to them without a handle to the server. +The server can also authenticate the client with SID and VID.

      +

      Every server should define the following security policies:

      +
        +

      • Which capabilities are required by the calling application

        +
        • +

      • Which SID and VID are required by the calling application

        +
        • +

      • What actions are possible or must be done with the +information provided:

        +
          +

        • Can input data be trusted?

          • +

        • Is user acceptance needed for this operation?

          +
          • +

        • Can this server act as a proxy towards other components?

          +
          • +
        +
        • +
      +
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BA7EB01-D967-44B2-B817-91722C59F2DE_d0e65995_href.png Binary file Symbian3/SDK/Source/GUID-3BA7EB01-D967-44B2-B817-91722C59F2DE_d0e65995_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BA7EB01-D967-44B2-B817-91722C59F2DE_d0e66138_href.png Binary file Symbian3/SDK/Source/GUID-3BA7EB01-D967-44B2-B817-91722C59F2DE_d0e66138_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BB539EF-E1DE-4EB4-A9F0-BB31430DD64A_d0e63738_href.png Binary file Symbian3/SDK/Source/GUID-3BB539EF-E1DE-4EB4-A9F0-BB31430DD64A_d0e63738_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BB539EF-E1DE-4EB4-A9F0-BB31430DD64A_d0e63881_href.png Binary file Symbian3/SDK/Source/GUID-3BB539EF-E1DE-4EB4-A9F0-BB31430DD64A_d0e63881_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BB6E558-017D-584A-BCB7-AB1DD80C5A90.dita --- a/Symbian3/SDK/Source/GUID-3BB6E558-017D-584A-BCB7-AB1DD80C5A90.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,17 +0,0 @@ - - - - - -deffile

      deffile filename

      Use the deffile statement to override the default linker definition file for the project.

      A .def file specifies associations between exported function names and their ordinal export number. It is used by the linker when constructing a DLL and (where applicable) when constructing its associated import library.

      The assignment of ordinals must be controlled by a .def file in two situations:

      • A polymorphic interface DLL must export a particular function as ordinal 1. In this case, the .def file is used to specify this association, while other exported functions may have a random order.

      • A re-released DLL must be used by clients built against the old version. In this case, the .def file is used to ensure that all functions exported by the old version of the DLL are exported with the same ordinal by the new version.

      For many polymorphic DLL s, a special target type is provided so that the build tools can ensure that the correct function is exported as ordinal 1. Where a special target type is provided, the .def file can be dispensed with.

      .def files are sometimes colloquially referred to as freeze files, because they freeze the association between name and ordinal, for exported functions.

      The RVCT and Microsoft tool chains use different schemes for mangling the names of exported functions. This means that .def files of the same name must be differentiated by storing them in separate directories.

      Conventionally,

      ..\eabi\ is used for ARM .def files,

      while

      ..\bwins\ is used for WINSCW .def files.

      By default, the frozen .def file takes its basename from the basename of the target for the project.

      Where the default frozen .def file is overridden by the deffile statement, a path to the file can be specified as part of the filename.

      If no path is specified, the .def files are expected to be in:

      • directory ..\bwins\ for platforms WINSCW, CW_IDE, VS6 and VS2003

      • directory ..\eabi\ for the ARM platform.

      If a path is specified, place the deffile statement within #if defined( identifier ) so that the same file will not be used during both ARM and non-ARM builds.

      For example:

      #if defined(WINS) -deffile-stmt -#else if defined(MARM) -deffile-stmt -#endif

      Note that the platform name macros used with #if - defined( identifier ) must be in upper-case.

      In most cases, the functions exported from a DLL depend on the build variant. This is common because descriptor class names depend on whether the build is wide or narrow. For such DLLs, different .def files—differentiated by the -u suffix—are used. Although narrow builds are no longer supported, the -u suffix is still in use to maintain backward compatibility with previous versions of the build tools. This suffix behaviour can be removed by using nostrictdef.

      Note too that under WINSCW, when using an exedll target type, the first export is the one which will be called when the DLL is loaded, so you should use a .def file for the WINSCW variant.

      Makefiles create the import library associated with an executable (where applicable) directly from the frozen .def file, so only frozen exported functions will appear in the import library and only these exported functions can be linked against by other components.

      For ARM platforms, import libraries for compatible ABIs are also created.

      For example:

      • if a project is built for ARMv5, then ARMv5_ABIv1 import libraries will be created.

      • if a project is built for ARMv5_ABIv2, then ARMv5_ABIv2 import libraries will be created.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3BCA55F8-3867-579B-8D81-C540A32A8462.dita --- a/Symbian3/SDK/Source/GUID-3BCA55F8-3867-579B-8D81-C540A32A8462.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - - build

      abld [ test ] build ( ( [-c] | [-w] ) | ( [-s] [-k] [-v] ) ) [ platform ] [ build [ program ] ]

      This command combines the effects of several abld commands in one, and will probably be all you’ll need to invoke to build your component.

      The abld commands that this command combines are export, makefile, library, resource, target and final, which are carried out in turn.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e58883_href.png Binary file Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e58883_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59026_href.png Binary file Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59026_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59473_href.png Binary file Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59473_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59616_href.png Binary file Symbian3/SDK/Source/GUID-3C16A9DC-E4E6-4892-B0E5-E3AF2F950F03_d0e59616_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e58928_href.png Binary file Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e58928_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59071_href.png Binary file Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59071_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59856_href.png Binary file Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59856_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59999_href.png Binary file Symbian3/SDK/Source/GUID-3C61E57D-BBBB-4E52-8C99-F359CB83D1BC_d0e59999_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C8FD050-1CD4-5AFB-ACB7-4264536BB300_d0e322219_href.png Binary file Symbian3/SDK/Source/GUID-3C8FD050-1CD4-5AFB-ACB7-4264536BB300_d0e322219_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3C8FD050-1CD4-5AFB-ACB7-4264536BB300_d0e328689_href.png Binary file Symbian3/SDK/Source/GUID-3C8FD050-1CD4-5AFB-ACB7-4264536BB300_d0e328689_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3CA473CB-E79C-5B32-8B5B-F222B3DDEF3B.dita --- a/Symbian3/SDK/Source/GUID-3CA473CB-E79C-5B32-8B5B-F222B3DDEF3B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3CA473CB-E79C-5B32-8B5B-F222B3DDEF3B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Speech Recognition Controller Overview

      This document provides an overview of the Speech Recognition Controller (SRC) component.

      Purpose

      The Speech Recognition Controller component provides speech recognition services for clients requiring speech recognition functionality. The SRC component comprises a client utility, a data handler and a custom commands library.

      Required background

      Automatic Speech Recognition (ASR) is a technology that enables users to use speech to interact with devices. ASR works by converting speech into a machine-readable form. Voice activated dialling is an example of an ASR application.

      Architectural relationships

      The ASR Client Utility is dependent on the Multimedia Framework. The MMF acts as the interface between the ASR Client Utility and the low level DevASR. A Speech Recognition Services (SRS) controller plugin is responsible for transporting speech recognition requests from the MMF to the DevASR. For playback, the DevASR implementation uses DevSound to play the recorded speech.

      The relationship between the SRC component and other multimedia components is shown below.

      SRC component architectural relationship -
      API summary

      The SRC component includes the following APIs:

    API Description

    Automatic Speech Recognition Client Utility

    Client side interface for ASR.

    For more information, see Automatic Speech Recognition Client Utility Overview.

    Automatic Speech Recognition Custom Commands

    Custom commands for ASR.

    For more information, see Automatic Speech Recognition Custom Commands Overview.

    Automatic Speech Recognition Data Handling

    Recognition data handling for ASR.

    For more information, see Automatic Speech Recognition Data Handling Overview.

    Typical uses

    The SRC component is used for the following:

    • Recognising spoken input.

    • Training a new model.

    • Manipulating grammars, lexicons and models.

    See also

    DevSound Overview

    \ No newline at end of file +
    API summary

    The SRC component includes the following APIs:

    API Description

    Automatic Speech Recognition Client Utility

    Client side interface for ASR.

    For more information, see Automatic Speech Recognition Client Utility Overview.

    Automatic Speech Recognition Custom Commands

    Custom commands for ASR.

    For more information, see Automatic Speech Recognition Custom Commands Overview.

    Automatic Speech Recognition Data Handling

    Recognition data handling for ASR.

    For more information, see Automatic Speech Recognition Data Handling Overview.

    Typical uses

    The SRC component is used for the following:

    • Recognising spoken input.

    • Training a new model.

    • Manipulating grammars, lexicons and models.

    See also

    DevSound Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D110AD3-C5C7-533C-8E57-C4E3D032A229_d0e196324_href.png Binary file Symbian3/SDK/Source/GUID-3D110AD3-C5C7-533C-8E57-C4E3D032A229_d0e196324_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D110AD3-C5C7-533C-8E57-C4E3D032A229_d0e201333_href.png Binary file Symbian3/SDK/Source/GUID-3D110AD3-C5C7-533C-8E57-C4E3D032A229_d0e201333_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D20F136-4526-502D-A708-1F26550FC61A.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-3D20F136-4526-502D-A708-1F26550FC61A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,16 @@ + + + + + +Secure SocketsThe Secure Sockets allow a user to transport data over the network +by enabling the users to authenticate and encrypt the data. +

    This section provides the summary of concepts and tutorials related to +the Secure Sockets.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D8FE2A7-E544-51B9-9572-492A3B61377C_d0e76293_href.png Binary file Symbian3/SDK/Source/GUID-3D8FE2A7-E544-51B9-9572-492A3B61377C_d0e76293_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D8FE2A7-E544-51B9-9572-492A3B61377C_d0e76331_href.png Binary file Symbian3/SDK/Source/GUID-3D8FE2A7-E544-51B9-9572-492A3B61377C_d0e76331_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3D9C4B45-EEA0-581C-A9E5-8B2535014930.dita --- a/Symbian3/SDK/Source/GUID-3D9C4B45-EEA0-581C-A9E5-8B2535014930.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3D9C4B45-EEA0-581C-A9E5-8B2535014930.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Image Conversion Library Overview

    This document introduces you to the Image Conversion functionality.

    Purpose

    Image Conversion functionality supports many features like encoding, decoding, scaling, rotating, producing mirror image, flipping and cropping images.

    Image Conversion Library Details

    To use Image Conversion, you must obtain necessary binaries in the form of DLL file to implement the image encoding and the image decoding functions.

    DLL LIB Short Description

    imageconversion.dll

    imageconversion.lib

    These files are used for implementing image conversion operation.

    Architectural Relationship

    Image Conversion is primarily used for Image Encoding and Image Decoding. The following diagram shows how the Image Encoding and the Image Decoding interacts with other components.

    Image Conversion system diagram -
    Description

    The Image conversion provides several features to enable the conversion and basic manipulation of images. Conversions can be made from images stored in files or descriptors to CFbsBitmap objects, or from CFbsBitmap and CFrameImageData objects to files or descriptors. Features of the image conversion function include:

    • Standard decoders that can decode single or multiframe images, images with bitmasks, images with in-image or in-frame comments.

    • Support for progressive decoding.

    • Functions to decode images stored in files or descriptors.

    • Standard encoder that can encode single frame images and images with in image comments.

    • Functions to manipulate image properties such as scale, rotation, dithering and progressive decoding.

    • Advanced thread control for encoder and decoders.

    Key Image Conversion Classes

    The key classes are

    Image Encoding

    Image encoding is the process of taking a bitmap stored in a CFbsBitmap, converting it to a specified format and writing the output to a file or descriptor. Typical sources of bitmap data are cameras and paint applications. The CImageEncoder object is created specifying the source image and encoder plugin as parameters. The CImageEncoder::Convert() function then encodes the image using the methods provided by the plugin. The results of the conversion are then saved to a file or descriptor.

    Image Decoding

    Image decoding is the process of taking an image stored in a file or descriptor, converting it from a specified format and writing the output to a CFbsBitmap. The CImageDecoder object is created specifying the source image and decoder plugin as parameters. The CImageDecoder::Convert() function then decodes the image using the methods provided by the plugin. The results of the conversion are then saved to a CFbsBitmap.

    Image Processor

    Image Processor is an interface to process the decoded image using the CImageProcessor class.

    Using Image Conversion

    The Image Conversion functionality is used for the following:

    • Rotate, crop, mirror and flip an image frame during decode operation.

    • Scaling with reduction factor of an image during decode operation.

    • Decode an image by requesting pixel data block by block.

    • Decode an image from a descriptor or a file.

    • Decode an image using a mask for the image with transparency.

    • Decode an image using separate thread.

    • Decode a JPEG image thumbnail.

    • Decode a GIF multi-frame image.

    • Decode an image that supports YUV format into an image frame.

    • Turning OFF and ON dithering during decode operation of the image.

    • Encode a bitmap or an image frame into a descriptor or a file.

    • Encode an image frame by passing pixel data block by block.

    • Rotate, mirror and flip an image during encode functionality.

    • Rotate a bitmap image.

    • Scaling a bitmap image with or without a mask.

    Imaging Frameworks Overview Image Conversion Overview Image Encoding Tutorial Image Decoding Tutorial Guide to Symbian supplied Codecs     \ No newline at end of file +
    Description

    The Image conversion provides several features to enable the conversion and basic manipulation of images. Conversions can be made from images stored in files or descriptors to CFbsBitmap objects, or from CFbsBitmap and CFrameImageData objects to files or descriptors. Features of the image conversion function include:

    • Standard decoders that can decode single or multiframe images, images with bitmasks, images with in-image or in-frame comments.

    • Support for progressive decoding.

    • Functions to decode images stored in files or descriptors.

    • Standard encoder that can encode single frame images and images with in image comments.

    • Functions to manipulate image properties such as scale, rotation, dithering and progressive decoding.

    • Advanced thread control for encoder and decoders.

    Key Image Conversion Classes

    The key classes are

    Image Encoding

    Image encoding is the process of taking a bitmap stored in a CFbsBitmap, converting it to a specified format and writing the output to a file or descriptor. Typical sources of bitmap data are cameras and paint applications. The CImageEncoder object is created specifying the source image and encoder plugin as parameters. The CImageEncoder::Convert() function then encodes the image using the methods provided by the plugin. The results of the conversion are then saved to a file or descriptor.

    Image Decoding

    Image decoding is the process of taking an image stored in a file or descriptor, converting it from a specified format and writing the output to a CFbsBitmap. The CImageDecoder object is created specifying the source image and decoder plugin as parameters. The CImageDecoder::Convert() function then decodes the image using the methods provided by the plugin. The results of the conversion are then saved to a CFbsBitmap.

    Image Processor

    Image Processor is an interface to process the decoded image using the CImageProcessor class.

    Using Image Conversion

    The Image Conversion functionality is used for the following:

    • Rotate, crop, mirror and flip an image frame during decode operation.

    • Scaling with reduction factor of an image during decode operation.

    • Decode an image by requesting pixel data block by block.

    • Decode an image from a descriptor or a file.

    • Decode an image using a mask for the image with transparency.

    • Decode an image using separate thread.

    • Decode a JPEG image thumbnail.

    • Decode a GIF multi-frame image.

    • Decode an image that supports YUV format into an image frame.

    • Turning OFF and ON dithering during decode operation of the image.

    • Encode a bitmap or an image frame into a descriptor or a file.

    • Encode an image frame by passing pixel data block by block.

    • Rotate, mirror and flip an image during encode functionality.

    • Rotate a bitmap image.

    • Scaling a bitmap image with or without a mask.

    Imaging Frameworks Overview Image Conversion Overview Image Encoding Tutorial Image Decoding Tutorial Guide to Symbian supplied Codecs \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e184580_href.png Binary file Symbian3/SDK/Source/GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e184580_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e189577_href.png Binary file Symbian3/SDK/Source/GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e189577_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3DE276E8-D2C7-5297-AF3B-40B0B8733572.dita --- a/Symbian3/SDK/Source/GUID-3DE276E8-D2C7-5297-AF3B-40B0B8733572.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3DE276E8-D2C7-5297-AF3B-40B0B8733572.dita Tue Jul 20 12:00:49 2010 +0100 @@ -32,7 +32,7 @@ the WriteL() function. The following diagram illustrates this:

    - +

    The source or target location in the other thread is identified by pointer. The pointer only has meaning within the context of that thread; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E0E2E54-CD8A-5BAF-A87B-BF51FD8890D6_d0e431356_href.png Binary file Symbian3/SDK/Source/GUID-3E0E2E54-CD8A-5BAF-A87B-BF51FD8890D6_d0e431356_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E0E2E54-CD8A-5BAF-A87B-BF51FD8890D6_d0e435156_href.png Binary file Symbian3/SDK/Source/GUID-3E0E2E54-CD8A-5BAF-A87B-BF51FD8890D6_d0e435156_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E1199E4-4F19-58BB-B1EC-8975A04B68FF_d0e213809_href.png Binary file Symbian3/SDK/Source/GUID-3E1199E4-4F19-58BB-B1EC-8975A04B68FF_d0e213809_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E1199E4-4F19-58BB-B1EC-8975A04B68FF_d0e218807_href.png Binary file Symbian3/SDK/Source/GUID-3E1199E4-4F19-58BB-B1EC-8975A04B68FF_d0e218807_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E23788D-4D67-5E9B-961F-B67D7471BB71_d0e133201_href.png Binary file Symbian3/SDK/Source/GUID-3E23788D-4D67-5E9B-961F-B67D7471BB71_d0e133201_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E23788D-4D67-5E9B-961F-B67D7471BB71_d0e136805_href.png Binary file Symbian3/SDK/Source/GUID-3E23788D-4D67-5E9B-961F-B67D7471BB71_d0e136805_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E7A9A92-F217-4BD1-82CE-227931CFB8ED.dita --- a/Symbian3/SDK/Source/GUID-3E7A9A92-F217-4BD1-82CE-227931CFB8ED.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3E7A9A92-F217-4BD1-82CE-227931CFB8ED.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,25 +1,21 @@ - - - - -Support for Multiple Pointers in the Emulator -This section introduces support for multiple pointers in -the emulator which uses multiple mice to simulate human fingers. The -multiple pointer environment in the emulator allows application developers -to test multiple pointer UI features when hardware devices are not -available. - - - - -

    Variant: ScreenPlay. Target audience: Application developers.

    - - -Advanced Pointers - - - + + + + + +Support for Multiple Pointers in the EmulatorThis section introduces support for multiple pointers in +the emulator which uses multiple mice to simulate human fingers. The +multiple pointer environment in the emulator allows application developers +to test multiple pointer UI features when hardware devices +are not available. +

    Variant: ScreenPlay. Target audience: Application developers.

    +     +Advanced +Pointers +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E80A006-F8D8-45C5-9773-7CC239AE86D9_d0e194049_href.png Binary file Symbian3/SDK/Source/GUID-3E80A006-F8D8-45C5-9773-7CC239AE86D9_d0e194049_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3E80A006-F8D8-45C5-9773-7CC239AE86D9_d0e199059_href.png Binary file Symbian3/SDK/Source/GUID-3E80A006-F8D8-45C5-9773-7CC239AE86D9_d0e199059_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3EF88A1D-CCB6-5DE5-9CA6-F6E785A6898A.dita --- a/Symbian3/SDK/Source/GUID-3EF88A1D-CCB6-5DE5-9CA6-F6E785A6898A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3EF88A1D-CCB6-5DE5-9CA6-F6E785A6898A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Communications Framework Quick StartThis topic describes the activities that users can do to make use of the Communications Framework. -
    Getting started +<section id="GUID-DBF1C87D-7360-54B7-8658-B6659BF77F06-GENID-1-10-1-9-1-1-5-1-3-1"><title>Getting started with Communications Framework

    • To manage communications connections and transfer data, use the client interfaces provided by the Sockets @@ -56,7 +56,7 @@ Communications Server.

    The following diagram outlines the Communication Framework collections and the components associated with each collection.

    - +
    Technologies

    The Comms Framework defines the structure and operations of the communications protocol stack in Symbian platform, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F0789DE-8455-5BA6-850C-45C60C581F18_d0e124947_href.png Binary file Symbian3/SDK/Source/GUID-3F0789DE-8455-5BA6-850C-45C60C581F18_d0e124947_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F0789DE-8455-5BA6-850C-45C60C581F18_d0e128567_href.png Binary file Symbian3/SDK/Source/GUID-3F0789DE-8455-5BA6-850C-45C60C581F18_d0e128567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F0FCBB5-98D2-4355-96E3-2DA938DE1C16.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-3F0FCBB5-98D2-4355-96E3-2DA938DE1C16.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,92 @@ + + + + + +DSA Migration GuideThis migration guide explains the guidelines that applications +that use direct screen access (DSA) must follow in order to run on +ScreenPlay (NGA) devices. +

    Introduced in an earlier version of the Symbian platform, DSA enables +applications that require high frame rates (such as video and games) +to bypass the Window Server and write to the screen directly. On +ScreenPlay, Symbian recommends the use of EGL window surfaces in preference +to DSA.

    +

    Support for DSA is maintained for backward compatibility reasons. + However, whereas on some earlier devices, applications might work +without fully conforming to the rules of DSA, these rules are now +necessarily enforced. Applications that follow the following guidelines +should run correctly on a ScreenPlay device.

    +
    Always +use a DSA session when using DSA

    The main classes +of the DSA framework are CDirectScreenAccess, RDirectScreenAccess and MDirectScreenAccess. Before drawing to the screen, the DSA application must create a +DSA session; for example, by instantiating CDirectScreenAccess and calling CDirectScreenAccess::StartL(). This +rule applies regardless of whether the application accesses the DSA +framebuffer using CFbsBitGc, CFbsScreenDevice or gains a pointer directly through HAL.

    Applications that +fail to create a DSA session will not work. Applications that draw +outside of an active period of DSA will not work. This is because +all DSA rendering is directed into a virtual framebuffer and the Operating +System uses the DSA session to determine when that framebuffer should +be made visible.

    The following example demonstrates requesting +direct screen access:

    voidCMyDSAEngine::StartDrawingL() + { + // Initialize DSA. + TRAPD(dsaError,iDSA->StartL()); + if (dsaError==KErrNone) + { + // Get the graphics context for drawing. + iGc=iDSA->Gc(); + + // Get the region to draw to. + iRegion=iDSA->DrawingRegion(); + + // Set the clipping region to this region. + iGc->SetClippingRegion(iRegion); + + // Start generating timer events (the drawing is done in a timer callback). + iPeriodicTimer=CPeriodic::NewL(CActive::EPriorityStandard); + iPeriodicTimer->Start(0,KInterval,TCallBack(DrawNextFrame, this)); + iDrawing=ETrue; + } + } +
    +
    Inform +the Operating System after updating the DSA buffer

    Applications +can access the screen by writing to the video hardware framebuffer +or by using CFbsScreenDevice. Regardless which +of these methods you use, the application must inform the OS that +the framebuffer has been updated in order for the DSA drawing to be +pushed to the display.

    Applications that fail to declare modifications +to the framebuffer will not see their content correctly appear on-screen. + This is because the OS uses event-driven updating to copy the contents +of the DSA framebuffer into the display.

    When writing to the +video hardware frame buffer, force a screen update by creating a redraw +event like this:

    TRawEventredraw; +redraw.Set(TRawEvent::ERedraw); +UserSvr::AddEvent(redraw);

    When using CFbsScreenDevice, force a screen update by calling one of the following:

    void CFbsScreenDevice::Update(); +void CFbsScreenDevice::Update(constTRegion &aRegion); +
    +
    Do +not mix DSA and non-DSA rendering

    The application must not +issue CWindowGc rendering to a window when DSA +is active on that window. If both types of rendering are required, +the application must ensure that they only happen in distinct periods +demarcated by the DSA session.

    Applications that interleave +periods of DSA rendering with periods of standard indirect (CWindowGc) rendering, expecting to see each painted on +top of the previous, will not work. This is because the OS now uses +two separate framebuffers; one for DSA rendering and one for indirect +rendering. Previous versions of the OS use a single +framebuffer for both types of rendering.

    Applications must be +written to render the entire contents of their window using either +DSA or indirect rendering at any one point of time.

    + +The +ScreenPlay Graphics Architecture +Graphics +and Drawing + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F172A97-8B96-5E1B-854C-F198D1334D2A_d0e260274_href.png Binary file Symbian3/SDK/Source/GUID-3F172A97-8B96-5E1B-854C-F198D1334D2A_d0e260274_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F172A97-8B96-5E1B-854C-F198D1334D2A_d0e265137_href.png Binary file Symbian3/SDK/Source/GUID-3F172A97-8B96-5E1B-854C-F198D1334D2A_d0e265137_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F1FF06E-4190-5AC7-86C6-6732B632BA1A.dita --- a/Symbian3/SDK/Source/GUID-3F1FF06E-4190-5AC7-86C6-6732B632BA1A.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -reallyclean

    abld [ test ] reallyclean ( ( [-c] | [-w] ) | ( [-k] [-v] ) ) [ platform ] [ build [ program ] ]

    This command does what abld clean does, and also removes files exported by abld - export and the makefiles generated by abld - makefile.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F7DA54D-28D5-4099-B4EF-728489DCEF2C.dita --- a/Symbian3/SDK/Source/GUID-3F7DA54D-28D5-4099-B4EF-728489DCEF2C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3F7DA54D-28D5-4099-B4EF-728489DCEF2C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,6 +18,6 @@ selection grid.

    Example of color selection grid - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F880EFC-E891-5C71-8360-1BBB54367AFA.dita --- a/Symbian3/SDK/Source/GUID-3F880EFC-E891-5C71-8360-1BBB54367AFA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Localisable icon/caption definition files

    These files define the following information required by the application launcher or system shell:

    • the application’s caption. This is often displayed beside the icon in the application launcher, and is usually the application’s name,

    • an optional short version of the caption. This is used by some UIs in situations where screen space is limited,

    • the name of the icon file,

    • for view-based applications, optional information about the views, including view-specific captions and icons. This feature may not be supported by all UIs.

    • an optional application group name. This may also be defined in the registration file. If it is defined in both files, the localisable version takes precedence.

    This information is defined using a LOCALISABLE_APP_INFO resource struct, see AppInfo.rh. This resource can either be defined in a icon/caption definition resource file, or in the application's UI resource file, if it has one.

    This choice of two methods is provided to give flexibility. For instance:

    • applications without any UI resources but which require icons/captions might need to use an icon/caption definition file,

    • applications with UI resources that do not need to be localised, but which require multiple captions, would use a single UI resource file, but several language-dependent icon/caption definition files,

    • for applications with localisable UI resources and different captions for different languages, it may be more convenient to define the caption/icon information in the UI resource files instead of using icon/caption definition files.

    Localisable information is optional. A set of default icons are provided by the GUI, and the default caption is the application name.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3F938A76-3F27-56ED-BB3D-0E7EC4ACFB9C.dita --- a/Symbian3/SDK/Source/GUID-3F938A76-3F27-56ED-BB3D-0E7EC4ACFB9C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3F938A76-3F27-56ED-BB3D-0E7EC4ACFB9C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -47,7 +47,7 @@ is zero (0) which indicates the non-iterative method. You must set it to 1 to get specify the iterative method. New search-sort request process - +
    Simple search

    1. Create a search-sort diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3FB773BA-C648-5C0A-9022-3F9882C6724A.dita --- a/Symbian3/SDK/Source/GUID-3FB773BA-C648-5C0A-9022-3F9882C6724A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3FB773BA-C648-5C0A-9022-3F9882C6724A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Feature Manager Client Overview

      Provides the APIs required to communicate with the feature management server.

      Purpose

      Provides the complete set of functionality required for feature management.

      Required background

      A familiarity with the client/server framework is necessary because feature management uses the standard client/server architecture; the feature manager server actually does the work, the feature manager library provides the APIs to implement a client to that server.

      Architecture

      The relationship between the parts of the feature management system is :

      Architecture of the feature management system -
      APIs

      This component provides one set of APIs that can be used to communicate with the feature management server.

      This dll file holds the APIs that are @publishedPartner.

      API Description

      RFeatMgrClient

      Base class of the client-side communication with the feature manager server.

      RFeatureControl

      Contains the full functionality of the feature manager.

      MFeatureObserver

      Provides a callback interface for handling feature change notifications.

      CFeatureNotifier

      This is the active object for obtaining the notification of changes in features.

      Typical uses

      • Connect to the feature management server.

      • Produce a list of the features that are present.

      • Check to see if a feature is supported.

      • Delete a feature.

      Feature Manager Overview Feature Discovery Overview Feature Manager Server Guide \ No newline at end of file +
    APIs

    This component provides one set of APIs that can be used to communicate with the feature management server.

    This dll file holds the APIs that are @publishedPartner.

    API Description

    RFeatMgrClient

    Base class of the client-side communication with the feature manager server.

    RFeatureControl

    Contains the full functionality of the feature manager.

    MFeatureObserver

    Provides a callback interface for handling feature change notifications.

    CFeatureNotifier

    This is the active object for obtaining the notification of changes in features.

    Typical uses

    • Connect to the feature management server.

    • Produce a list of the features that are present.

    • Check to see if a feature is supported.

    • Delete a feature.

    Feature Manager Overview Feature Discovery Overview Feature Manager Server Guide     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3FC6342D-D09C-5C7F-8E03-3DA7B29D2CC8.dita --- a/Symbian3/SDK/Source/GUID-3FC6342D-D09C-5C7F-8E03-3DA7B29D2CC8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3FC6342D-D09C-5C7F-8E03-3DA7B29D2CC8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Recording AudioThis tutorial describes how to start, pause and resume, stop and retrieve the audio samples for audio recording.

    Before you start, you must:

    • Understand the A3F DevSound Component to which the DevSound library belongs.

    • Understand the architectural relationship of the DevSound. For information see DevSound Overview.

    You can perform various functionality in DevSound audio recording that are listed in the below section.

    Starting Audio Record Pausing and Resuming Audio Record Stopping Audio Record Retrieving Audio Record Samples     Playing Audio     \ No newline at end of file +Recording AudioThis tutorial describes how to start, pause and resume, stop and retrieve the audio samples for audio recording.

    Before you start, you must:

    • Understand the A3F DevSound Component to which the DevSound library belongs.

    • Understand the architectural relationship of the DevSound. For information see DevSound Overview.

    You can perform various functionality in DevSound audio recording that are listed in the below section.

    Starting Audio Record Pausing and Resuming Audio Record Stopping Audio Record Retrieving Audio Record Samples     Playing Audio     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3FFF726B-D158-4EDF-B950-4B58467F210B_d0e4749_href.png Binary file Symbian3/SDK/Source/GUID-3FFF726B-D158-4EDF-B950-4B58467F210B_d0e4749_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3FFF726B-D158-4EDF-B950-4B58467F210B_d0e4874_href.png Binary file Symbian3/SDK/Source/GUID-3FFF726B-D158-4EDF-B950-4B58467F210B_d0e4874_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e357820_href.png Binary file Symbian3/SDK/Source/GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e357820_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e386813_href.png Binary file Symbian3/SDK/Source/GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e386813_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40437D9A-7503-5087-851A-D1269F0AF9A9_d0e196473_href.png Binary file Symbian3/SDK/Source/GUID-40437D9A-7503-5087-851A-D1269F0AF9A9_d0e196473_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40437D9A-7503-5087-851A-D1269F0AF9A9_d0e201482_href.png Binary file Symbian3/SDK/Source/GUID-40437D9A-7503-5087-851A-D1269F0AF9A9_d0e201482_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-405F7AB8-0F0E-4171-95E6-3524D76917DE.dita --- a/Symbian3/SDK/Source/GUID-405F7AB8-0F0E-4171-95E6-3524D76917DE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-405F7AB8-0F0E-4171-95E6-3524D76917DE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,36 +9,19 @@ --> -Handling stylus pop-up menu events and commands -

    At the construction phase, CAknStylusPopUpMenu is given a MEikMenuObserver object, which is usually -a pointer to the application’s UI (CAknAppUi) or -another class that implements the interface. The stylus pop up menu -will grab the stylus event when one of its items is tapped on and -it will then report the item’s command ID to the menu observer. It -is then up to the application to handle the command in the implementation -of MEikMenuObserver::HandleCommandL().

    -

    When an item is tapped, the menu calls its observer's (iMenuObserver) ProcessCommandL() using:void ProcessCommandL(TInt aCommandId); where, aCommandID parameter is the command number recorded in -the resource file. You can also add it using AddMenuItemL() function as shown in the following code snippet:void AddMenuItemL( const TDesC& aItem, const TInt aCommandId );

    -

    The following code snippet illustrates how to handle the command:switch( aCommandId ) - { - case StylusMenuCommand1: - break; - case StylusMenuCommand2: - break; - case StylusMenuCommand3: - break; - case StylusMenuCommand4: - break; - case KErrCancel: - break; - default: - break; - } -

    -

    Typically the observer is application's AppUi. It is then the observer's -responsibility to handle the command appropriately. The observer is -informed with KErrCancel if the menu is closed without -making a selection.

    -

    Use the CAknStylusPopUpMenu::HandleControlEventL() method to handle events that occur when user selects a menu item.

    - +Handling +stylus pop-up menu events and commands +

    At the construction phase, CAknStylusPopUpMenu is given +a MEikMenuObserver object, which is usually a pointer to +the application’s UI (CAknAppUi) +or another class that implements the interface. The stylus pop up menu will +grab the stylus event when one of its items is tapped on and it will then +report the item’s command ID to the menu observer. It is then up to the application +to handle the command in the implementation of MEikMenuObserver::HandleCommandL().

    +

    When an item is tapped, the menu calls its observer's (iMenuObserver) +ProcessCommandL. Typically the observer is application's AppUi. It is then +the observer's responsibility to handle the command appropriately. The observer +is informed with KErrCancel if the menu is closed without making a selection.

    +

    Add sample code on event and command +handling here.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40619192-8C2F-4267-BFCA-F53E10BF5A31_d0e12529_href.png Binary file Symbian3/SDK/Source/GUID-40619192-8C2F-4267-BFCA-F53E10BF5A31_d0e12529_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40619192-8C2F-4267-BFCA-F53E10BF5A31_d0e12633_href.png Binary file Symbian3/SDK/Source/GUID-40619192-8C2F-4267-BFCA-F53E10BF5A31_d0e12633_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40A3938E-366E-5318-A7FA-146F9E5E23B1_d0e189180_href.png Binary file Symbian3/SDK/Source/GUID-40A3938E-366E-5318-A7FA-146F9E5E23B1_d0e189180_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40A3938E-366E-5318-A7FA-146F9E5E23B1_d0e194151_href.png Binary file Symbian3/SDK/Source/GUID-40A3938E-366E-5318-A7FA-146F9E5E23B1_d0e194151_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40B9136A-B91B-5FF4-A44D-CA6925F19B14.dita --- a/Symbian3/SDK/Source/GUID-40B9136A-B91B-5FF4-A44D-CA6925F19B14.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-40B9136A-B91B-5FF4-A44D-CA6925F19B14.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,5 +11,5 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Feature Discovery OverviewProvides a set of APIs that are used to initate a feature discovery operation.
    Purpose

    Feature discovery provides a set of APIs to discover if a feature or feature set is supported and available.

    Required background

    The feature management system uses the standard client server architecture that is the feature manager server does the work associated with the feature management functionality. Communication between the application and the server is undertaken by two dlls which contain the required API.

    Architecture

    The relationship between the parts of the feature management system is :

    Architecture of the feature management system -
    APIs

    This component provides one set of APIs that can be used to communicate with the feature management server.

    API Description

    TFeatureSet

    Used to determine if multiple features are supported.

    CFeatureDiscovery

    Used to determine if a feature is supported.

    Typical uses

    The APIs provided by this dll are for use by third parties

    • A third party app wants to find out if the device can execute it : there is no point installing an application needing a camera, if one is not present on the device.

    • For the above, they would use the API provided by featmgr.dll.

    • Would be used to check if the required feature (and assumed framework) is present.

    Use cases:

    • Query a single feature.

    • Query multiple features.

    Feature Manager Overview Feature Manager Client +
    APIs

    This component provides one set of APIs that can be used to communicate with the feature management server.

    API Description

    TFeatureSet

    Used to determine if multiple features are supported.

    CFeatureDiscovery

    Used to determine if a feature is supported.

    Typical uses

    The APIs provided by this dll are for use by third parties

    • A third party app wants to find out if the device can execute it : there is no point installing an application needing a camera, if one is not present on the device.

    • For the above, they would use the API provided by featmgr.dll.

    • Would be used to check if the required feature (and assumed framework) is present.

    Use cases:

    • Query a single feature.

    • Query multiple features.

    Feature Manager Overview Feature Manager Client Overview Feature Manager Server Guide \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40BE9805-6CEC-557F-BAAC-4D328E181AC3_d0e196422_href.png Binary file Symbian3/SDK/Source/GUID-40BE9805-6CEC-557F-BAAC-4D328E181AC3_d0e196422_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40BE9805-6CEC-557F-BAAC-4D328E181AC3_d0e201431_href.png Binary file Symbian3/SDK/Source/GUID-40BE9805-6CEC-557F-BAAC-4D328E181AC3_d0e201431_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40C995CA-9906-59D8-A5E7-08F592031AEE_d0e247945_href.png Binary file Symbian3/SDK/Source/GUID-40C995CA-9906-59D8-A5E7-08F592031AEE_d0e247945_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40C995CA-9906-59D8-A5E7-08F592031AEE_d0e252896_href.png Binary file Symbian3/SDK/Source/GUID-40C995CA-9906-59D8-A5E7-08F592031AEE_d0e252896_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40E64445-CBA3-59E4-A777-937609B311C9.dita --- a/Symbian3/SDK/Source/GUID-40E64445-CBA3-59E4-A777-937609B311C9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-40E64445-CBA3-59E4-A777-937609B311C9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ is primarily used by messaging, telephony, synchronisation and vCard viewer clients on a device.

    CONTACTS MODEL CLIENTS - +
    Description

    The CContactDatabase class allows clients access to the contact data stored on the device and has the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40ED6F39-F8E2-5292-ADA5-C2507F256AE0_d0e244714_href.png Binary file Symbian3/SDK/Source/GUID-40ED6F39-F8E2-5292-ADA5-C2507F256AE0_d0e244714_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40ED6F39-F8E2-5292-ADA5-C2507F256AE0_d0e249673_href.png Binary file Symbian3/SDK/Source/GUID-40ED6F39-F8E2-5292-ADA5-C2507F256AE0_d0e249673_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-40F5B725-A5D7-487F-BF5D-A616F768F40D.dita --- a/Symbian3/SDK/Source/GUID-40F5B725-A5D7-487F-BF5D-A616F768F40D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-40F5B725-A5D7-487F-BF5D-A616F768F40D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,7 +37,7 @@ same as that of a note. The example in the figure below is an ungrouped soft notification.

    Soft notification indicating a new message - +

  • Grouped soft notification: Many different items of information can be combined into one soft notification where the items are displayed as @@ -46,7 +46,7 @@ a List query (see Queries).

    Grouped soft notification. The height of the window is dynamic and depends on the number of lines in the list. - +

    • @@ -91,7 +91,7 @@

    -Default touch +<table id="GUID-D5917E40-42B1-461B-8722-C7AD66482078-GENID-1-10-1-7-1-1-5-1-16-1-1-2-10"><title>Default touch events for grouped soft notification diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4119C4BD-ABBF-524B-B649-0F39EF58A7FB_d0e107079_href.png Binary file Symbian3/SDK/Source/GUID-4119C4BD-ABBF-524B-B649-0F39EF58A7FB_d0e107079_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4119C4BD-ABBF-524B-B649-0F39EF58A7FB_d0e107311_href.png Binary file Symbian3/SDK/Source/GUID-4119C4BD-ABBF-524B-B649-0F39EF58A7FB_d0e107311_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4120651F-E0B9-5927-96B9-2662C51F5A09.dita --- a/Symbian3/SDK/Source/GUID-4120651F-E0B9-5927-96B9-2662C51F5A09.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4120651F-E0B9-5927-96B9-2662C51F5A09.dita Tue Jul 20 12:00:49 2010 +0100 @@ -45,7 +45,7 @@ and RConnection constitute the SIPPARAMS.

    Interface of Connection and Sub Connection. - +

    The SIP high level API models the SIP with Connection and SubConnection providers and makes it stackable against the unified comms-infras architecture. This enables the future connection convergence.

    Initial setup

    A diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-416A3756-B5D5-5BCD-830E-2371C5F6B502.dita --- a/Symbian3/SDK/Source/GUID-416A3756-B5D5-5BCD-830E-2371C5F6B502.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-416A3756-B5D5-5BCD-830E-2371C5F6B502.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Font Store Component OverviewThe Font Store contains all of the fonts and typefaces on a phone. It is encapsulated by the Font and Bitmap server which provides a client-side class that applications use to find which fonts are available and to find fonts to match their requirements.

    The Font Store component is sometimes called the Open Font System or Open Font Framework.

    Required background

    • You require no background knowledge or experience use the Font Store using the Font and Bitmap Server interfaces.

    • You require no background knowledge or experience to add new font files to the Font Store. You must simply copy the files to the appropriate location.

    • To create a font file or a font rasterizer, you require an in-depth knowledge of fonts and Symbian programming.

    Key concepts and terms

    See Concepts and Terms in the Font and Text Services Collection Overview.

    Architectural relationships

    The Font Store can contain three types of font: bitmap fonts, which are stored as fixed-size pixel definitions; open fonts, which may be stored in any format; and linked fonts, which use characters from two or more other fonts. Open fonts must be converted into bitmaps (rasterized) before they can be used so the Font Store must also contain a font rasterizer for each format of open font.

    Fonts are stored on Symbian phones as files. The Font Store maintains a list of font files along with specifications for each font that the file contains. When an application requests a font the Font Store searches its list for the best match. If the font is a bitmap font the Font Store loads it into the Font and Bitmap Server's shared heap (unless the font is in eXecute In Place (XIP) ROM, in which case it is accessed directly from ROM). If the font is an open font the Font Store uses the associated open font rasterizer to rasterize glyphs into the heap as they are required. Font rasterizers are ECOM plugins.

    Font Store relationships -
    Font Store API summary

    The Font Store contains APIs for specifying and selecting fonts and for rasterizing open fonts.

    API Description

    CBitmapFont

    Bitmap-based font object

    CFontStore

    Central font storage class

    CLinkedTypefaceGroup

    Linked fonts typeface group

    CLinkedTypefaceSpecification

    Linked font creation

    CLinkedTypefaceElementSpec

    Linked font typeface element spec

    COpenFont

    Generic outline font object

    COpenFontFile

    Open font file

    COpenFontRasterizer

    Open font rasterizer

    COpenFontRasterizerContext

    Open font rasterizer context

    TAlgStyle

    Algorithmic style attributes

    TCharacterMetrics

    Character information

    TLinkedTypeface

    Linked fonts

    TOpenFontAttachment

    Diacritic attachment point information

    TOpenFontCharMetrics

    Open font character metrics

    TOpenFontFaceAttrib

    Open font typeface information

    TOpenFontFaceAttribBase

    Basic open font typeface information

    TOpenFontGlyphData

    Open font glyph information

    TOpenFontMetrics

    Open font information

    TOpenFontSpec

    Open font specification

    Font Store tasks

    The following functionality is provided by the fntstore subsystem component:

    • Font loading

      Font file loading using plug-in font rasterizers if required.

    • Font request matching

      Closest-fit matching of font requests.

    • Font linking

      The creation and use of Linked Fonts – virtual fonts that are made out of one or (usually) more physical fonts. These can be used to:

      • Combine multiple character ranges from individual fonts into a single font.

      • Allow an existing font containing a particular script to be customized to use regional variant characters.

      • Allow a comprehensive range of scripts to be built into a device ROM and multiple possible subsets to be defined and used by software configuration.

      Linked fonts are primarily used for system fonts. The fact that a font is a linked font is invisible to the user.

    Platform security information

    Font data files are installed in the read-only folder \resource\fonts.

    Font and Text Services Collection +
    Font Store API summary

    The Font Store contains APIs for specifying and selecting fonts and for rasterizing open fonts.

    API Description

    CBitmapFont

    Bitmap-based font object

    CFontStore

    Central font storage class

    CLinkedTypefaceGroup

    Linked fonts typeface group

    CLinkedTypefaceSpecification

    Linked font creation

    CLinkedTypefaceElementSpec

    Linked font typeface element spec

    COpenFont

    Generic outline font object

    COpenFontFile

    Open font file

    COpenFontRasterizer

    Open font rasterizer

    COpenFontRasterizerContext

    Open font rasterizer context

    TAlgStyle

    Algorithmic style attributes

    TCharacterMetrics

    Character information

    TLinkedTypeface

    Linked fonts

    TOpenFontAttachment

    Diacritic attachment point information

    TOpenFontCharMetrics

    Open font character metrics

    TOpenFontFaceAttrib

    Open font typeface information

    TOpenFontFaceAttribBase

    Basic open font typeface information

    TOpenFontGlyphData

    Open font glyph information

    TOpenFontMetrics

    Open font information

    TOpenFontSpec

    Open font specification

    Font Store tasks

    The following functionality is provided by the fntstore subsystem component:

    • Font loading

      Font file loading using plug-in font rasterizers if required.

    • Font request matching

      Closest-fit matching of font requests.

    • Font linking

      The creation and use of Linked Fonts – virtual fonts that are made out of one or (usually) more physical fonts. These can be used to:

      • Combine multiple character ranges from individual fonts into a single font.

      • Allow an existing font containing a particular script to be customized to use regional variant characters.

      • Allow a comprehensive range of scripts to be built into a device ROM and multiple possible subsets to be defined and used by software configuration.

      Linked fonts are primarily used for system fonts. The fact that a font is a linked font is invisible to the user.

    Platform security information

    Font data files are installed in the read-only folder \resource\fonts.

    Font and Text Services Collection Overview Font and Bitmap Server Component Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4195F4EE-5A61-515D-A6EF-2E16E00E4AFF.dita --- a/Symbian3/SDK/Source/GUID-4195F4EE-5A61-515D-A6EF-2E16E00E4AFF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4195F4EE-5A61-515D-A6EF-2E16E00E4AFF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Recording media files

    You can use the MVS to record audio or video signals to media files. To record an audio signal, first connect a microphone; to record a video signal, connect a camera.

    To record a media file, choosing the plugin controller:

    1. In the File menu, click Open for Record. The Choose a plugin dialog box is displayed.

      Choosing a format when recording audio -

      Note: If you don't want to choose a plugin controller manually, click Cancel in the Choose a plugin dialog box: the Save as dialog box is displayed. In the Save as dialog box, enter the target file name including its extension; the controller appropriate to the extension is loaded automatically. If there is no appropriate controller, a Not Supported message is displayed.

    2. Select the Media Type to record by clicking either the Audio or Video option button.

    3. Select the Supported Format from the drop-down list. The corresponding plugin Controller is selected automatically.

      Note: To check which controllers are supported by the system:

      • In the File menu, click System Info. The controllers are listed:

    4. Click Next. The Save as dialog box is displayed.

    5. In the dialog box, enter the names of the disk drive and folder to contain the file, or select them from the lists.

    6. In the dialog box, enter the name of the file, without an extension, to contain the recorded audio or video.

    7. Click OK to save the file.

    The next steps depend on whether you are Recording an audio file or Recording a video file.

    Recording an audio file

    If you are recording an audio file, the Configure Audio Format dialog box is displayed.

    1. In the dialog box, select:

      • the codec

      • the bit rate

      • the number of channels (1 = mono, 2 = stereo)

      • the sample rate in bits per second.

    2. If required, click the Restore Settings check box to restore the previous settings or - if there are none - the default settings.

    3. Click OK to save the settings.

    4. To start recording, click the tool bar Record button, or in the Controls menu, click Record.

    Recording a video file

    If you are recording a video file, the Standard Video Record format dialog box is displayed.

    1. In the dialog box, select:

      • the video mime type

      • the video frame rate

      • the video frame size in pixels (width, height).

    2. To record audio with the video signal, click the Enable Audio check box.

    3. If required, click the Restore Settings check box to restore the previous settings or - if there are none - the default settings.

    4. Click OK to save the settings.

    5. To start recording, click the tool bar Record button, or in the Controls menu, click Record.

      • To pause recording, click the tool bar Pause button, or in the Controls menu, click Pause. To un-pause the file and resume recording, click the tool bar Record button, or in the Controls menu, click Record.

      • To stop recording, click the tool bar Stop button, or in the Controls menu, click Stop.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Playing media files

    Editing media files

    Configuring and clearing files

    \ No newline at end of file +

    Note: If you don't want to choose a plugin controller manually, click Cancel in the Choose a plugin dialog box: the Save as dialog box is displayed. In the Save as dialog box, enter the target file name including its extension; the controller appropriate to the extension is loaded automatically. If there is no appropriate controller, a Not Supported message is displayed.

  • Select the Media Type to record by clicking either the Audio or Video option button.

  • Select the Supported Format from the drop-down list. The corresponding plugin Controller is selected automatically.

    Note: To check which controllers are supported by the system:

    • In the File menu, click System Info. The controllers are listed:

  • Click Next. The Save as dialog box is displayed.

  • In the dialog box, enter the names of the disk drive and folder to contain the file, or select them from the lists.

  • In the dialog box, enter the name of the file, without an extension, to contain the recorded audio or video.

  • Click OK to save the file.

    • The next steps depend on whether you are Recording an audio file or Recording a video file.

    Recording an audio file

    If you are recording an audio file, the Configure Audio Format dialog box is displayed.

    1. In the dialog box, select:

      • the codec

      • the bit rate

      • the number of channels (1 = mono, 2 = stereo)

      • the sample rate in bits per second.

    2. If required, click the Restore Settings check box to restore the previous settings or - if there are none - the default settings.

    3. Click OK to save the settings.

    4. To start recording, click the tool bar Record button, or in the Controls menu, click Record.

    Recording a video file

    If you are recording a video file, the Standard Video Record format dialog box is displayed.

    1. In the dialog box, select:

      • the video mime type

      • the video frame rate

      • the video frame size in pixels (width, height).

    2. To record audio with the video signal, click the Enable Audio check box.

    3. If required, click the Restore Settings check box to restore the previous settings or - if there are none - the default settings.

    4. Click OK to save the settings.

    5. To start recording, click the tool bar Record button, or in the Controls menu, click Record.

      • To pause recording, click the tool bar Pause button, or in the Controls menu, click Pause. To un-pause the file and resume recording, click the tool bar Record button, or in the Controls menu, click Record.

      • To stop recording, click the tool bar Stop button, or in the Controls menu, click Stop.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Playing media files

    Editing media files

    Configuring and clearing files

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-41A53C1F-E9BF-420F-A967-83906299FE8B_d0e2875_href.png Binary file Symbian3/SDK/Source/GUID-41A53C1F-E9BF-420F-A967-83906299FE8B_d0e2875_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-41A53C1F-E9BF-420F-A967-83906299FE8B_d0e2879_href.png Binary file Symbian3/SDK/Source/GUID-41A53C1F-E9BF-420F-A967-83906299FE8B_d0e2879_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-41A70DFD-BADF-5B8F-8085-488F34F81561_d0e300969_href.png Binary file Symbian3/SDK/Source/GUID-41A70DFD-BADF-5B8F-8085-488F34F81561_d0e300969_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-41A70DFD-BADF-5B8F-8085-488F34F81561_d0e307441_href.png Binary file Symbian3/SDK/Source/GUID-41A70DFD-BADF-5B8F-8085-488F34F81561_d0e307441_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-422F37DF-F93F-443F-86EA-6A696A53E1E6.dita --- a/Symbian3/SDK/Source/GUID-422F37DF-F93F-443F-86EA-6A696A53E1E6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-422F37DF-F93F-443F-86EA-6A696A53E1E6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ you must also call the base class implementation of the function.

    Scrollbar - +

    For an implementation example, see below.

    void CMyContainerControl::HandleScrollEventL( CEikScrollBar* aScrollBar, TEikScrollEvent aEventType ) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-42609A21-CEDC-58E8-864C-0CF8458F6798_d0e287092_href.png Binary file Symbian3/SDK/Source/GUID-42609A21-CEDC-58E8-864C-0CF8458F6798_d0e287092_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-42609A21-CEDC-58E8-864C-0CF8458F6798_d0e291923_href.png Binary file Symbian3/SDK/Source/GUID-42609A21-CEDC-58E8-864C-0CF8458F6798_d0e291923_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-42833109-F8C2-57FC-9995-0461698A19FF.dita --- a/Symbian3/SDK/Source/GUID-42833109-F8C2-57FC-9995-0461698A19FF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-42833109-F8C2-57FC-9995-0461698A19FF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@ Concepts

    This section describes the Internet Message Access Protocol (IMAP4) and its implementation on the Symbian platform.

    -
    IMAP4 protocol

    IMAP4 +

    IMAP4 protocol

    IMAP4 is one of the most common Internet standard protocols for retrieving emails. It is an application layer Internet protocol operating on port 143 that allows a local client to access email on a remote server.

    The current version, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4303DBDB-3F67-54E6-AB24-5E1871053ED9_d0e46282_href.png Binary file Symbian3/SDK/Source/GUID-4303DBDB-3F67-54E6-AB24-5E1871053ED9_d0e46282_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4303DBDB-3F67-54E6-AB24-5E1871053ED9_d0e46440_href.png Binary file Symbian3/SDK/Source/GUID-4303DBDB-3F67-54E6-AB24-5E1871053ED9_d0e46440_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-431119D1-1B55-4503-905E-6E290FA241CE_d0e63537_href.png Binary file Symbian3/SDK/Source/GUID-431119D1-1B55-4503-905E-6E290FA241CE_d0e63537_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-431119D1-1B55-4503-905E-6E290FA241CE_d0e63680_href.png Binary file Symbian3/SDK/Source/GUID-431119D1-1B55-4503-905E-6E290FA241CE_d0e63680_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-432FF981-010F-540B-834F-FF924238AA2A.dita --- a/Symbian3/SDK/Source/GUID-432FF981-010F-540B-834F-FF924238AA2A.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -epocheapsize

    epocheapsize minimum maximum

    Use the epocheapsize statement to specify the minimum and maximum sizes of the initial heap for a process. The default sizes are 4KB minimum and 1MB maximum.This directive is applicable from Symbian OS v9.1, EKA2 releases. EKA2 supports multiple process creation and allows the heap size to be calibrated between the minimum and maximum limits.

    The minimum size specifies the RAM that is initially mapped for the heap's use. The process can then obtain more heap memory on demand until the maximum value is reached. For more information, see Memory Management concepts.

    The sizes can be specified in decimal or hexadecimal format. Memory is allocated in pages, so the minimum and maximum values are rounded up to a multiple of the page size (4K).

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-433698C1-C97D-5317-83C0-71A029E362E6_d0e303218_href.png Binary file Symbian3/SDK/Source/GUID-433698C1-C97D-5317-83C0-71A029E362E6_d0e303218_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-433698C1-C97D-5317-83C0-71A029E362E6_d0e309690_href.png Binary file Symbian3/SDK/Source/GUID-433698C1-C97D-5317-83C0-71A029E362E6_d0e309690_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-434F2412-59A1-4BCB-885D-5E708EAA6AB6.dita --- a/Symbian3/SDK/Source/GUID-434F2412-59A1-4BCB-885D-5E708EAA6AB6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-434F2412-59A1-4BCB-885D-5E708EAA6AB6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ query.

    Grid query - +
    Using grid queries in applications

    For implementation information, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4381EA7F-BE75-5B43-BE97-C97D71D04377_d0e332416_href.png Binary file Symbian3/SDK/Source/GUID-4381EA7F-BE75-5B43-BE97-C97D71D04377_d0e332416_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4381EA7F-BE75-5B43-BE97-C97D71D04377_d0e338882_href.png Binary file Symbian3/SDK/Source/GUID-4381EA7F-BE75-5B43-BE97-C97D71D04377_d0e338882_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36160_href.png Binary file Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36160_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36212_href.png Binary file Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36212_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36327_href.png Binary file Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36327_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36379_href.png Binary file Symbian3/SDK/Source/GUID-43A701DC-24FF-44F7-850B-AA6A79235B56_d0e36379_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4406BDE0-8256-5F97-9FC5-BBFD11D9C4A3.dita --- a/Symbian3/SDK/Source/GUID-4406BDE0-8256-5F97-9FC5-BBFD11D9C4A3.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Resource file

    A resource file is available to an application at run-time, and usually has extension .rsc. It contains resources compiled from a source file, .rss.

    Each resource is a sequence of bytes. Resources within a file are identified by number at run-time, but may also be identified symbolically in the source file. The resource compiler rcomp compiles a .rss into a .rsc, and also emits a series of #define statements into a .rsg file, which the C++ program may #include, to allow resources lookup by symbolic name rather than by number.

    Resources are built automatically by abld or the compiler IDE if the project file specifies a resource file using the RESOURCE statement.

    Resource data is mapped by structs — in a similar way to C’s structs. Resource structs are defined using STRUCT statements which are understood only by the resource compiler. Symbian platform provides many struct types: occasionally, applications also add their own. STRUCT statements are included in headers, conventionally with a .rh extension. These are #include d into .rss files.

    Symbolic constants for various purposes must be available to both C++ programs and resource file definitions. These are defined using #define statements or enum statements, and included in .hrh files. These may be #include d into either C++ or resource scripts.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-442D216B-117E-538C-A51F-0775BF37673E_d0e244320_href.png Binary file Symbian3/SDK/Source/GUID-442D216B-117E-538C-A51F-0775BF37673E_d0e244320_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-442D216B-117E-538C-A51F-0775BF37673E_d0e249279_href.png Binary file Symbian3/SDK/Source/GUID-442D216B-117E-538C-A51F-0775BF37673E_d0e249279_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-44347376-702D-5648-8938-EB55AFA329EC_d0e406701_href.png Binary file Symbian3/SDK/Source/GUID-44347376-702D-5648-8938-EB55AFA329EC_d0e406701_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-44347376-702D-5648-8938-EB55AFA329EC_d0e410501_href.png Binary file Symbian3/SDK/Source/GUID-44347376-702D-5648-8938-EB55AFA329EC_d0e410501_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-44ADB485-69C2-5557-AB95-3B6D20870F73_d0e115520_href.png Binary file Symbian3/SDK/Source/GUID-44ADB485-69C2-5557-AB95-3B6D20870F73_d0e115520_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-44ADB485-69C2-5557-AB95-3B6D20870F73_d0e115760_href.png Binary file Symbian3/SDK/Source/GUID-44ADB485-69C2-5557-AB95-3B6D20870F73_d0e115760_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-44FDDA27-1A5D-42B5-8DE0-D9E88EB75C93.dita --- a/Symbian3/SDK/Source/GUID-44FDDA27-1A5D-42B5-8DE0-D9E88EB75C93.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-44FDDA27-1A5D-42B5-8DE0-D9E88EB75C93.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ a particular sensor type. Once you get the list of sensor channels that are active, you can perform any required operations such as configuring sensor channel properties, controlling sensor channels and so on. - + Create an instance of TSensrvChannelInfo and set the required channel type as the search criteria. For example, to query for all double tapping channels @@ -28,7 +28,7 @@ CSensrvChannelFinder* finder = CSensrvChannelFinder::NewL(); finder->FindChannelsL(channelList, searchParameters); -Create an instance +Create an instance of RSensrvChannelInfoList to store the list of sensor channels. RSensrvChannelInfoList channelInfoList; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-45DD08DB-FCB3-5546-91B4-25868C8ABAE4_d0e115528_href.png Binary file Symbian3/SDK/Source/GUID-45DD08DB-FCB3-5546-91B4-25868C8ABAE4_d0e115528_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-45DD08DB-FCB3-5546-91B4-25868C8ABAE4_d0e115768_href.png Binary file Symbian3/SDK/Source/GUID-45DD08DB-FCB3-5546-91B4-25868C8ABAE4_d0e115768_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46040A24-92C3-4B0B-88CC-BDD8DDA8F27C_d0e41397_href.png Binary file Symbian3/SDK/Source/GUID-46040A24-92C3-4B0B-88CC-BDD8DDA8F27C_d0e41397_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46040A24-92C3-4B0B-88CC-BDD8DDA8F27C_d0e41555_href.png Binary file Symbian3/SDK/Source/GUID-46040A24-92C3-4B0B-88CC-BDD8DDA8F27C_d0e41555_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46121F24-AB53-5B44-A082-EF13A72EB7FF.dita --- a/Symbian3/SDK/Source/GUID-46121F24-AB53-5B44-A082-EF13A72EB7FF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-46121F24-AB53-5B44-A082-EF13A72EB7FF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ shows the key elements of the converter architecture, including an example client and an example converter DLL that provides two converters, myConverter1 and myConverter2.

    File Converter architecture - +
    Procedure

    1. Write diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4616CCC9-7BD3-5D91-873A-6027167329ED_d0e184851_href.png Binary file Symbian3/SDK/Source/GUID-4616CCC9-7BD3-5D91-873A-6027167329ED_d0e184851_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4616CCC9-7BD3-5D91-873A-6027167329ED_d0e189848_href.png Binary file Symbian3/SDK/Source/GUID-4616CCC9-7BD3-5D91-873A-6027167329ED_d0e189848_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46673FC4-ADA9-59D1-A743-B4784425D240_d0e79327_href.png Binary file Symbian3/SDK/Source/GUID-46673FC4-ADA9-59D1-A743-B4784425D240_d0e79327_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46673FC4-ADA9-59D1-A743-B4784425D240_d0e79385_href.png Binary file Symbian3/SDK/Source/GUID-46673FC4-ADA9-59D1-A743-B4784425D240_d0e79385_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46A91D57-7864-53AD-903C-B978B0C61DAD_d0e336132_href.jpg Binary file Symbian3/SDK/Source/GUID-46A91D57-7864-53AD-903C-B978B0C61DAD_d0e336132_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46A91D57-7864-53AD-903C-B978B0C61DAD_d0e342598_href.jpg Binary file Symbian3/SDK/Source/GUID-46A91D57-7864-53AD-903C-B978B0C61DAD_d0e342598_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46B5E7B1-F0C2-5C1E-972A-C339E7515225.dita --- a/Symbian3/SDK/Source/GUID-46B5E7B1-F0C2-5C1E-972A-C339E7515225.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -compresstarget

      compresstarget

      Use the compresstarget statement to specify that the target executable should be compressed. In detail, the code and data sections of the executable are compressed with the Deflate, Huffman+LZ77 algorithm.

      Compression allows the stored executable to use less space on the file system. The executable loader decompresses the file when it is loaded.

      See also nocompresstarget.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46E27DAF-B72D-5A86-91BB-1B3C0788C6A5_d0e341486_href.png Binary file Symbian3/SDK/Source/GUID-46E27DAF-B72D-5A86-91BB-1B3C0788C6A5_d0e341486_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-46E27DAF-B72D-5A86-91BB-1B3C0788C6A5_d0e347952_href.png Binary file Symbian3/SDK/Source/GUID-46E27DAF-B72D-5A86-91BB-1B3C0788C6A5_d0e347952_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-470FAFE8-2246-5E91-9F01-6CC95F975E54_d0e304255_href.jpg Binary file Symbian3/SDK/Source/GUID-470FAFE8-2246-5E91-9F01-6CC95F975E54_d0e304255_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-470FAFE8-2246-5E91-9F01-6CC95F975E54_d0e310727_href.jpg Binary file Symbian3/SDK/Source/GUID-470FAFE8-2246-5E91-9F01-6CC95F975E54_d0e310727_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47511301-DFF9-52B0-9602-DD9D293D3044_d0e230623_href.png Binary file Symbian3/SDK/Source/GUID-47511301-DFF9-52B0-9602-DD9D293D3044_d0e230623_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47511301-DFF9-52B0-9602-DD9D293D3044_d0e235603_href.png Binary file Symbian3/SDK/Source/GUID-47511301-DFF9-52B0-9602-DD9D293D3044_d0e235603_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47587124-66D8-5128-BDBB-AF190E67CAF5_d0e201499_href.png Binary file Symbian3/SDK/Source/GUID-47587124-66D8-5128-BDBB-AF190E67CAF5_d0e201499_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47587124-66D8-5128-BDBB-AF190E67CAF5_d0e206506_href.png Binary file Symbian3/SDK/Source/GUID-47587124-66D8-5128-BDBB-AF190E67CAF5_d0e206506_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-479133EB-1154-554E-8CEA-C61EDA747B69_d0e76189_href.png Binary file Symbian3/SDK/Source/GUID-479133EB-1154-554E-8CEA-C61EDA747B69_d0e76189_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-479133EB-1154-554E-8CEA-C61EDA747B69_d0e76227_href.png Binary file Symbian3/SDK/Source/GUID-479133EB-1154-554E-8CEA-C61EDA747B69_d0e76227_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47AA7F26-FF3F-4FEE-BBB4-F4E8A8E0E335_d0e70851_href.png Binary file Symbian3/SDK/Source/GUID-47AA7F26-FF3F-4FEE-BBB4-F4E8A8E0E335_d0e70851_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47AA7F26-FF3F-4FEE-BBB4-F4E8A8E0E335_d0e70876_href.png Binary file Symbian3/SDK/Source/GUID-47AA7F26-FF3F-4FEE-BBB4-F4E8A8E0E335_d0e70876_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47EF98E9-7833-5E94-ADFF-198401463A8C_d0e76304_href.png Binary file Symbian3/SDK/Source/GUID-47EF98E9-7833-5E94-ADFF-198401463A8C_d0e76304_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-47EF98E9-7833-5E94-ADFF-198401463A8C_d0e76342_href.png Binary file Symbian3/SDK/Source/GUID-47EF98E9-7833-5E94-ADFF-198401463A8C_d0e76342_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48363190-6FFB-4230-84B4-2E521EA51365.dita --- a/Symbian3/SDK/Source/GUID-48363190-6FFB-4230-84B4-2E521EA51365.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-48363190-6FFB-4230-84B4-2E521EA51365.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Using menu sections in menu bar resource statements -Menu sections in an Options menu +Menu sections in an Options menu

      The use of menu sections provides a means of combining menu bar resource declarations in Options menus. One example of how this could be used would be an application with two views. Three MENU_BAR resources diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5.dita --- a/Symbian3/SDK/Source/GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4841AEDF-D22C-57D0-872D-7BD8B6A29CF5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> What are Tiers?This topic describes the concepts of a Tier and a Tier Manager in the Communications Framework.

      A Tier is a group of Access Points (APs) related to one or more technologies sharing the same Selection and Availability monitoring logic. The Tier Manager provides the means for an application to connect to a communication service to send and receive data, or to check the current status of a communication service.

      When an application needs to contruct a stack either to request availability on a particular service or to establish a connection with a remote device or service, it will explicitly select a specific Tier Manager at the top of the stack to define the service. If the application does not explicitly select a specific Tier Manager, the default TM will be used. The selection process and connection preferences will define how the rest of the stack is constructed. Each Tier Manager is responsible for selecting the most appropriate AP from a range of alternatives and may also pass up availability information in some cases, depending on the Tier Manager.

      When a higher Layer wants to bind to a lower layer, it uses the supplied selection criteria to select a Tier and request a specific AP. Once the Tier has returned an AP and the stack has been bound together, the upper layer queries the availability to see if it is possible to connect at that moment.

      On a device there will be multiple Tier Managers, each responsible for a separate technology or group of technologies. Each Tier Manager will have distinct selection and availability logic and other technology specific algorithms.

      A single Tier Manager will be responsible for multiple instances of a layer, i.e. multiple APs of the same type. So the Wi-Fi Tier Manager would allow connection to multiple Wi-Fi Access Points, a Telephony Tier Manager will be responsible for connections to different APNs.

      Tier Managers (CTierManagerBase) are Comms Framework nodes created by their respective factories. Tier Managers respond to Node Messages sent across the Transport, in a similar way to Stack Nodes.

      The Tier Manager keeps track of the current Access Points that have been created through a query API, see Availability below. The Tier Manager responds to messages sent when an Access Point changes state. For example, when a Bearer stops being available, a message will be sent to the Tier Manager.

      In the diagram below, two Tier Managers are shown. The diagram shows that one Tier Manager can be responsible for more than one layer in a Stack.

      Communications Architecture showing Tier Managers -

      When a client application wants to start a connection it will request an AP by calling RConnection::Open() with a Tier Identifier (the iTag field in the Tier table). This will cause a stack of APs that meet the selection and availability criteria to be returned. When the RConnection:Start() occurs, a specific AP will be selected at the top layer and the matching CPRs, SCPRs and Data Flows in each of the layers for the connection will be started (unless the connection is already active and this new RConnection can share the open connection).

      Configuration

      The configuration for a Tier Manager is held in a number of Comms Database tables: most importantly the Tier table, and the Access Point table.

      The Tier Table contains the ECom ID of the loaded module that processes Tier Manager requests, and the Default Access Point. The Default Access Point is the one used if the client makes no special requests, see Explicit and Implicit Selection below.

      The Access Point Table contains the identifiers of the MCPR, CPR and SCPR for this layer, the selection policy, the protocol, the Tier ID and a protocol identifier.

      It is recommended that all connections should specify a Tier in the RConnection::Start(), but for backward compatability, RConnection::Start() without a Tier identifier will use the Default Tier which is stored in the GlobalSettings table. Important note: for legacy code to function correctly, the Default Tier must be the "Network " Tier. See Explicit and Implicit Selection below for more information.

      Usage

      Selection

      A Tier Manager uses selection to decide which Access Points can be used for a connection. A top-level Tier Manager responds to selection requests that originate from RConnection or RConnectionServ.

      Selection selects a stack of APs that may be used to provide a service. The result is a stack or inverted tree showing potential APs at each layer. Remember that a higher layer AP provides a service, but there may be several options at each lower layer for supporting that service (Wi-Fi, 3G telephony etc.). For example, when a client asks for a service to provide a data socket, the list returned will include all the available APs at each layer. The Tier Manager for each layer decides which AP to use.

      Explicit and Implicit Selection

      If Freeway/Mobility is required it is required that communications clients explicitly open an RConnection on an AP. and associate the RSocket with it. But to for legacy applications or connections that don't require mobility, Implicit Selection is supported which uses the Default Connection.

      Explicit Selection occurs when an application specifies the top-level Access Point when calling RConnection::Start() with a parameter bundle that specifies an AP. Explicit selection selects the top-level AP and joins this connection to the stack.

      Implicit selection occurs when a user calls RSocket::Open() on a socket that is not associated with any connection. Implicit selection will associate the socket with the Default Connection. Implicit selection also occurs when an RConnection::Start() is called without specifying an AP in the connection preferences.

      For Implicit Selection, only the top layer of the stack is created by the RSocket::Open(), the remainder of the layers are created when a Data Plane event occurs such as RSocket::Connect() or RSocket::Send().

      When the Data Plane activation event occurs:

      • if there is no bearer (no AP for the next layer in the stack), the Control Plane will finish the selection and start the selected connection.

      • if there is a bearer, the Data Plane states it has found a flow in the Layer below by protocol-specific means, for example IP routing table.

      Availability

      When a client application wants to monitor a technology or existing connection, it can call RConnectionServ::AccessPointStatusQuery() for an immediate status, or RConnectionServ::AccessPointNotification() to be informed of each status change. As the format of the query bundle is configurable by the MCPR, each technology can specify what information will be returned in a query or notification. For example, the query bundle could contain Wi-Fi hotspot availability, maximum data rate supported, costs etc.

      Layers Planes Nodes       \ No newline at end of file +

      When a client application wants to start a connection it will request an AP by calling RConnection::Open() with a Tier Identifier (the iTag field in the Tier table). This will cause a stack of APs that meet the selection and availability criteria to be returned. When the RConnection:Start() occurs, a specific AP will be selected at the top layer and the matching CPRs, SCPRs and Data Flows in each of the layers for the connection will be started (unless the connection is already active and this new RConnection can share the open connection).

      Configuration

      The configuration for a Tier Manager is held in a number of Comms Database tables: most importantly the Tier table, and the Access Point table.

      The Tier Table contains the ECom ID of the loaded module that processes Tier Manager requests, and the Default Access Point. The Default Access Point is the one used if the client makes no special requests, see Explicit and Implicit Selection below.

      The Access Point Table contains the identifiers of the MCPR, CPR and SCPR for this layer, the selection policy, the protocol, the Tier ID and a protocol identifier.

      It is recommended that all connections should specify a Tier in the RConnection::Start(), but for backward compatability, RConnection::Start() without a Tier identifier will use the Default Tier which is stored in the GlobalSettings table. Important note: for legacy code to function correctly, the Default Tier must be the "Network " Tier. See Explicit and Implicit Selection below for more information.

      Usage

      Selection

      A Tier Manager uses selection to decide which Access Points can be used for a connection. A top-level Tier Manager responds to selection requests that originate from RConnection or RConnectionServ.

      Selection selects a stack of APs that may be used to provide a service. The result is a stack or inverted tree showing potential APs at each layer. Remember that a higher layer AP provides a service, but there may be several options at each lower layer for supporting that service (Wi-Fi, 3G telephony etc.). For example, when a client asks for a service to provide a data socket, the list returned will include all the available APs at each layer. The Tier Manager for each layer decides which AP to use.

      Explicit and Implicit Selection

      If Freeway/Mobility is required it is required that communications clients explicitly open an RConnection on an AP. and associate the RSocket with it. But to for legacy applications or connections that don't require mobility, Implicit Selection is supported which uses the Default Connection.

      Explicit Selection occurs when an application specifies the top-level Access Point when calling RConnection::Start() with a parameter bundle that specifies an AP. Explicit selection selects the top-level AP and joins this connection to the stack.

      Implicit selection occurs when a user calls RSocket::Open() on a socket that is not associated with any connection. Implicit selection will associate the socket with the Default Connection. Implicit selection also occurs when an RConnection::Start() is called without specifying an AP in the connection preferences.

      For Implicit Selection, only the top layer of the stack is created by the RSocket::Open(), the remainder of the layers are created when a Data Plane event occurs such as RSocket::Connect() or RSocket::Send().

      When the Data Plane activation event occurs:

      • if there is no bearer (no AP for the next layer in the stack), the Control Plane will finish the selection and start the selected connection.

      • if there is a bearer, the Data Plane states it has found a flow in the Layer below by protocol-specific means, for example IP routing table.

      Availability

      When a client application wants to monitor a technology or existing connection, it can call RConnectionServ::AccessPointStatusQuery() for an immediate status, or RConnectionServ::AccessPointNotification() to be informed of each status change. As the format of the query bundle is configurable by the MCPR, each technology can specify what information will be returned in a query or notification. For example, the query bundle could contain Wi-Fi hotspot availability, maximum data rate supported, costs etc.

      Layers Planes Nodes \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48482288-B60B-477A-8E28-132F7CBE2C94.dita --- a/Symbian3/SDK/Source/GUID-48482288-B60B-477A-8E28-132F7CBE2C94.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-48482288-B60B-477A-8E28-132F7CBE2C94.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@

      The Selection key always causes the same action as the left softkey.

      Confirmation query - +

      Guidelines for designing Confirmation queries:

        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-488F24B1-DC9B-5A5B-8B0D-47A428B9AA3C_d0e322748_href.jpg Binary file Symbian3/SDK/Source/GUID-488F24B1-DC9B-5A5B-8B0D-47A428B9AA3C_d0e322748_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-488F24B1-DC9B-5A5B-8B0D-47A428B9AA3C_d0e329218_href.jpg Binary file Symbian3/SDK/Source/GUID-488F24B1-DC9B-5A5B-8B0D-47A428B9AA3C_d0e329218_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48B61662-0A11-4356-9882-7523B04FFD96.dita --- a/Symbian3/SDK/Source/GUID-48B61662-0A11-4356-9882-7523B04FFD96.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-48B61662-0A11-4356-9882-7523B04FFD96.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,21 +12,21 @@ Changing PassphraseThis section explains how to change the passphrase.

        The following steps explain the process of changing the passphrase:

         - -Create a file system + +Create a file system session using an RFs object. - + Create an object of type CUnifiedKeyStore using CUnifiedKeyStore::NewL() or CUnifiedKeyStore::NewLC(). - + Initialize the member functions and keystore using the asynchronous function CUnifiedKeyStore::Initialize(). - + Obtain the authentication object of a key using the CCTKeyInfo::Protector() function. - + Invoke the ChangeReferenceData() function for the authentication object obtained. The keystore prompts the user to enter the old and new passphrases. @@ -34,8 +34,8 @@

        The passphrase is changed for the selected key, if the old passphrase is entered correctly.

         -Example

        The -following code snippet shows how to set use policy for a key.

        // Create a file system session object +Example

        The +following code snippet shows how to set use policy for a key.

        // Create a file system session object RFs iFs; CleanupClosePushL(&iFs); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48BD628F-F47F-535B-B148-7425A6704FC2.dita --- a/Symbian3/SDK/Source/GUID-48BD628F-F47F-535B-B148-7425A6704FC2.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -always_build_as_arm

        always_build_as_arm

        Use the always_build_as_arm statement to instruct an ARMV5 build to not build the project for the THUMB instruction set, but for the ARM instruction set.

        For details, see ARM/THUMB overrides.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48C764A2-378F-57CC-B7F2-EC866AE8F830.dita --- a/Symbian3/SDK/Source/GUID-48C764A2-378F-57CC-B7F2-EC866AE8F830.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-48C764A2-378F-57CC-B7F2-EC866AE8F830.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -The reference counting object

        A reference counting object is one which uses reference counting to track concurrent references to itself and which arranges for automatic destruction of itself when the final reference is removed. It is also an object which can be named.

        A reference counting object is any object which has CObject as its base class.

        Constructing a CObject derived type, or calling its CObject::Open() member function, adds a reference to that object by adding one to its reference count. Calling its CObject::Close() member function removes a reference by subtracting one from its reference count. When the last user of the object calls CObject::Close(), the reference count becomes zero and the object is automatically destroyed.

        The following drawing shows the idea.

        A CObject is always part of a class hierarchy. It is a base class; an explicit CObject type is never instantiated.

        The server side implementation of a client/server subsession uses a CObject.

        See also:

        • CObject

        • Subsessions within a session

        • Using client/server

        \ No newline at end of file +The reference counting object

        A reference counting object is one which uses reference counting to track concurrent references to itself and which arranges for automatic destruction of itself when the final reference is removed. It is also an object which can be named.

        A reference counting object is any object which has CObject as its base class.

        Constructing a CObject derived type, or calling its CObject::Open() member function, adds a reference to that object by adding one to its reference count. Calling its CObject::Close() member function removes a reference by subtracting one from its reference count. When the last user of the object calls CObject::Close(), the reference count becomes zero and the object is automatically destroyed.

        The following drawing shows the idea.

        A CObject is always part of a class hierarchy. It is a base class; an explicit CObject type is never instantiated.

        The server side implementation of a client/server subsession uses a CObject.

        See also:

        • CObject

        • Subsessions within a session

        • Using client/server

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48D06D0E-C4D6-54F1-B603-7A75DEF669AA_d0e356267_href.png Binary file Symbian3/SDK/Source/GUID-48D06D0E-C4D6-54F1-B603-7A75DEF669AA_d0e356267_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-48D06D0E-C4D6-54F1-B603-7A75DEF669AA_d0e375455_href.png Binary file Symbian3/SDK/Source/GUID-48D06D0E-C4D6-54F1-B603-7A75DEF669AA_d0e375455_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-49205F79-C17B-4126-BDB2-D759B91B5894.dita --- a/Symbian3/SDK/Source/GUID-49205F79-C17B-4126-BDB2-D759B91B5894.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-49205F79-C17B-4126-BDB2-D759B91B5894.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,8 +14,8 @@ to use the best available data connection while operational.

        To use application-level roaming:

        - -Initiate an Internet + +Initiate an Internet connection using the Connection Manager API and the Internet destination network. In this example it is assumed that the best available access point for Internet is GPRS. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4922D80F-009D-56CE-B255-FDAF9C247667_d0e215301_href.png Binary file Symbian3/SDK/Source/GUID-4922D80F-009D-56CE-B255-FDAF9C247667_d0e215301_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4922D80F-009D-56CE-B255-FDAF9C247667_d0e220299_href.png Binary file Symbian3/SDK/Source/GUID-4922D80F-009D-56CE-B255-FDAF9C247667_d0e220299_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4930A22F-EF80-5B08-A878-C0DB73929558_d0e266550_href.png Binary file Symbian3/SDK/Source/GUID-4930A22F-EF80-5B08-A878-C0DB73929558_d0e266550_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4930A22F-EF80-5B08-A878-C0DB73929558_d0e271405_href.png Binary file Symbian3/SDK/Source/GUID-4930A22F-EF80-5B08-A878-C0DB73929558_d0e271405_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita --- a/Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-49363088-CE0B-558D-8E86-48400E4F7C2F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -46,7 +46,7 @@ to be cleared or snoozed.

        Alarm state diagram for multiple alarm notification support - +

        In the diagram above, a queued alarm can change to the ‘waiting to notify’ state if an alarm has expired but the maximum number of notifying alarms has been reached. The state can also change if Alarm Server is waiting diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-49397CFD-955A-5DF6-9251-368C44224966.dita --- a/Symbian3/SDK/Source/GUID-49397CFD-955A-5DF6-9251-368C44224966.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Build tools reference \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4941C035-C359-4968-9BD5-31F44EE5F810.dita --- a/Symbian3/SDK/Source/GUID-4941C035-C359-4968-9BD5-31F44EE5F810.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4941C035-C359-4968-9BD5-31F44EE5F810.dita Tue Jul 20 12:00:49 2010 +0100 @@ -41,11 +41,10 @@ framework directly and results in the Options menu being presented to the device user.

      -

      For more information on resource files, see Managing -resource files.

      +

      For more information on resource files, see Managing resource files.

      For an example of a resource file, see Resource management example: HelloWorldBasic.

      -Options menu +Options menu

      Commands are passed to the object with which the menu is associated. The object that receives the command should handle the command if it is specific to the object. If the command is relevant to another object, then it should diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-494AF38D-CE0C-4B4C-BE44-2FC7482F4B7B.dita --- a/Symbian3/SDK/Source/GUID-494AF38D-CE0C-4B4C-BE44-2FC7482F4B7B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-494AF38D-CE0C-4B4C-BE44-2FC7482F4B7B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,15 +9,8 @@ --> -Hiding and showing stylus pop-up menu items -

      To hide and show stylus pop-up menu items, use the method CAknStylusPopUpMenu::SetItemDimmed() in the class.

      -// You can remove the menu item dynamically according to the command id. For example: -iPopupMenu->RemoveMenuItem( StylusMenuCommand1 ); - -// You can dim (hide) a menu item without removing it -iPopupMenu->SetItemDimmed( StylusMenuDynamicAdd, ETrue ); - -// You can un-dim(show) the menu item again: -iPopupMenu->SetItemDimmed( StylusMenuDynamicAdd, EFalse ); - +Hiding +and showing stylus pop-up menu items +

      To hide and show stylus pop-up menu items, use the method SetItemDimmed() in the class CAknStylusPopUpMenu.

      +

      Add sample code here.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4957E6BB-C41D-52F1-94CD-68CF6D61C271.dita --- a/Symbian3/SDK/Source/GUID-4957E6BB-C41D-52F1-94CD-68CF6D61C271.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4957E6BB-C41D-52F1-94CD-68CF6D61C271.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ not only the new attribute which it introduces, but also every attribute which it inherits from the preceding format layer.

      - +

      The Symbian platform avoids this inefficiency by using the system of based-on links. Here, each new layer adds attributes in a natural way without @@ -35,13 +35,13 @@ arrow represents a based-on link.

      Format layering - +

      The following diagram demonstrates the system of based-on links when attributes are applied to different parts of text rather than added on top of existing attribute layers.

      - +

      In this case, several format layers are required, all of which are based on the normal layer.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-495C619C-1223-59C1-9B31-0F4031BAE4A9.dita --- a/Symbian3/SDK/Source/GUID-495C619C-1223-59C1-9B31-0F4031BAE4A9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -systeminclude

      systeminclude directory-list

      Use the systeminclude statement to define directories to be scanned for files specified in #include statements in source and resource files.

      It may be specified any number of times, and each may have any number of directories.

      When a project is being built, the pre-processor will be invoked specifying all the systeminclude and userinclude directories indicated in these statements. No standard include directories will be searched unless the project links to Win32 libraries under WINS.

      Files included from source code with a line such as #include - <e32def.h> are searched based on the first matching file in the directory, in the following order:

      • Directory containing the source file

      • Directories specified by userinclude keyword, if any

      • Directories specified by systeminclude keyword, if any

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-495EA1C8-E95F-54AE-B4D1-0F463003C2D7.dita --- a/Symbian3/SDK/Source/GUID-495EA1C8-E95F-54AE-B4D1-0F463003C2D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-495EA1C8-E95F-54AE-B4D1-0F463003C2D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ some of the key concepts that are used in the documentation of surfaces.

      Composition of the UI surface and an external surface, showing the viewport and extent - +
      Graphics surface
      @@ -65,7 +65,7 @@ can be seen.

      A cross section through the surfaces, showing the display output - +
    Supported Uses

    You can:

      @@ -92,7 +92,7 @@ surface from top to bottom and rotate it by 180° to achieve a mirroring effect.

    The following diagrams shows some surface configuration use cases.

    Surface configuration use cases - +
    Configuration

    There are a number of ways in which dynamically updated content can be configured diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-49700B0C-AEDD-50EB-874E-45025CF474BE.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-49700B0C-AEDD-50EB-874E-45025CF474BE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,37 @@ + + + + + +Debug Logging

    Overview

    There are three types of debug logging which can be enabled for the server. Each of these types of debug logging is activated by enabling one of the following macros in the server’s MMP file (app-engines\cntmodel\cntsrv\cntsrv.mmp):

    • __VERBOSE_DEBUG__
    • __STATE_MACHINE_DEBUG__
    • __PROFILE_DEBUG__
    Verbose Debug Logging

    Enabling the __VERBOSE_DEBUG__ macro activates a variety of debug logging.

    IPC Calls

    One of the more useful forms of verbose debug logging is for IPC calls. The following type of debug is emitted for each IPC call received by a session on the server:

    IPC: ECntCompress, SessId: 4, ErrCode: 0

    The debug indicates the IPC call op-code and the ID of the session that is handling the IPC call. The error code will always be 0 in this case.

    If an IPC call leaves on the server then the following type of debug is emitted:

    IPC_ERROR: ECntCompress, SessId: 4, ErrCode: -4

    The debug indicates the IPC call op-code, the ID of the session that is handling the IPC call and the error code for the leave.

    Database Events

    Another useful form of verbose debug logging is for database events. The following type of debug is emitted for each database event that is queued by the server:

    ->Q: Message: EContactDbObserverEventContactAdded, ContactID: 2, ConnectionId: 2

    For each event that is transferred from the server to the client the following type of debug is emitted:

    Q->: Message: EContactDbObserverEventContactAdded, ContactID: 1, ConnectionId: 2
    State Machine Debug Logging

    Enabling the __STATE_MACHINE_DEBUG__ macro activates state machine transition debug logging.

    Each time the state machine changes state a line of debug will be emitted. This indicates between which states the state machine is making a transition. For example:

    STA: EStateClosed --> EStateOpening

    This indicates that the state machine is in transition between the Closed and Opening states.

    Profile Debug Logging

    Enabling the __PROFILE_DEBUG__ macro activates profile debug logging. This form of debug logging indicates which methods are being called in order to identify paths of execution for optimisation. For example:

    MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntStateMachine::ProcessRequestL +MTD: CCntStateMachine::HandleDatabaseEventL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntStateMachine::ProcessRequestL +MTD: CCntStateMachine::HandleDatabaseEventL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntStateMachine::ProcessRequestL +MTD: CCntStateMachine::HandleDatabaseEventL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntStateMachine::ProcessRequestL +MTD: CCntStateMachine::HandleDatabaseEventL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL +MTD: CCntStateMachine::ProcessRequestL +MTD: CCntStateMachine::HandleDatabaseEventL +MTD: CCntSession::ServiceL +MTD: CCntSession::CntItemManagerL

    This table shows the methods called on the server when adding a series of contact items.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-497AD33D-F6DC-52D4-85C8-B9E02978ACD4_d0e169416_href.jpg Binary file Symbian3/SDK/Source/GUID-497AD33D-F6DC-52D4-85C8-B9E02978ACD4_d0e169416_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-497AD33D-F6DC-52D4-85C8-B9E02978ACD4_d0e174430_href.jpg Binary file Symbian3/SDK/Source/GUID-497AD33D-F6DC-52D4-85C8-B9E02978ACD4_d0e174430_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4A5A50EB-261E-5739-904E-1D14D1A6BAD9_d0e177144_href.png Binary file Symbian3/SDK/Source/GUID-4A5A50EB-261E-5739-904E-1D14D1A6BAD9_d0e177144_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4A5A50EB-261E-5739-904E-1D14D1A6BAD9_d0e182169_href.png Binary file Symbian3/SDK/Source/GUID-4A5A50EB-261E-5739-904E-1D14D1A6BAD9_d0e182169_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4A66B46E-8A23-42E4-ADAD-B124A36B180A.dita --- a/Symbian3/SDK/Source/GUID-4A66B46E-8A23-42E4-ADAD-B124A36B180A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4A66B46E-8A23-42E4-ADAD-B124A36B180A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,30 +12,9 @@ Showing and hiding stylus pop-up menu

    Use the method ShowMenu() in the class CAknStylusPopUpMenu to show the stylus pop-up menu.

    -

    Usually, the pop-up menu must not be directly displayed in the HandlePointerEventL of -a CCoeControl. Use the CAknLongTapDetector -to handle the Llong Tap event and show the pop-up on the HandleLongTapEventL, -which is the implementation to the interface MAknLongTapDetectorCallBack.

    -

    The following code snippets illustrates how to show pop-up menu:

    -CAknLongTapDetector * iLongTapDetector; -// "this" implement the interface MAknLongTapDetectorCallBack -iLongTapDetector = CAknLongTapDetector::NewL( this ); - -// pass the process to the long tap detector -void XXXX::HandlePointerEventL( - const TPointerEvent& aPointerEvent) - { - iLongTapDetector->PointerEventL( aPointerEvent ); - // Call base class HandlePointerEventL() - CCoeControl::HandlePointerEventL(aPointerEvent); - } -// handle long tap detector event to show the stylus popup -void XXXX::HandleLongTapEventL( const TPoint& aPenEventLocation, const TPoint& aPenEventScreenLocation ) - { - iPopupMenu->SetPosition( - aPenEventScreenLocation , - CAknStylusPopUpMenu::EPositionTypeRightBottom ); - iPopupMenu->ShowMenu(); - } - +

    How is the menu dismissed/hidden? +Automatically after a command has been selected or when the user taps outside +the menu?

    +

    Add sample code on showing and hiding +the menu here.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4AAABD77-C08E-5EE2-A02A-3B412EA6D23F.dita --- a/Symbian3/SDK/Source/GUID-4AAABD77-C08E-5EE2-A02A-3B412EA6D23F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4AAABD77-C08E-5EE2-A02A-3B412EA6D23F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,7 +31,7 @@ interacts with a specially customised DevSound (configured as optional).

    Shown below is a representation of how A3F interacts with DevSound and other components:

    A3F and related components - +
    Library summary

    A3F includes the following libraries:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4ADD8234-4AFD-4E80-94A4-AC018FE83276.dita --- a/Symbian3/SDK/Source/GUID-4ADD8234-4AFD-4E80-94A4-AC018FE83276.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4ADD8234-4AFD-4E80-94A4-AC018FE83276.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@

  • Spawn APIs

  • Libgmodule APIs

    • -
    Memory +<section id="GUID-DFAD39D6-BA92-4293-B5EC-97077CE1FC1A-GENID-1-10-1-13-1-1-7-1-6-1-4-1-3-3"> <title>Memory allocation

    The Symbian GLib implementation does not follow the default OSS behavior. The default OSS behavior is such that in the event of a memory allocation failure the application, using g_malloc() and @@ -30,7 +30,7 @@ all the application code written using GLib does not perform memory allocation failure checks. Hence, for Symbian GLib it is the application programmer's responsibility to check for memory allocation failures.

    -
    Spawn +<section id="GUID-DFAD39D6-BA92-4293-B5EC-97077CE1FC1A-GENID-1-10-1-13-1-1-7-1-6-1-4-1-3-4"> <title>Spawn APIs

    GLib has a set of APIs for process spawning. Since Symbian platform does not support the fork() and exec() APIs, the g_spawn* APIs have limitations in their functionality. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4AEBF49C-E62A-5D0D-8181-600BF29DFFC7.dita --- a/Symbian3/SDK/Source/GUID-4AEBF49C-E62A-5D0D-8181-600BF29DFFC7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4AEBF49C-E62A-5D0D-8181-600BF29DFFC7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,69 +1,59 @@ - - - - - -IPC: -IPC Mechanisms -

    This example demonstrates how a parent process communicates with its child -process using various IPC mechanisms. Two executables, a parent and a child -(spawned by the parent) are created to demonstrate these mechanisms. The child -process is created by the parent using the posix_spawn() function. -The parent process communicates with the child process using the following -IPC mechanisms:

    -
      -

    • Named pipes (FIFO - -First in First Out)

      • -

    • Single pipe (popen() system -call)

      • -
    -
    Download

    Click on the following link to download -the example: IPC.zip

    Click: browse to view the example code.

    -
    Description

    Spawning the child process

    The posix_spawn() function -creates the child process. A pointer to the process ID (pid) -of the child process and the path of the child process are passed as arguments -to this function. The parent waits for the child to terminate by calling the waitpid() function.

    Creating -a named pipe

    This example creates a named pipe using the mkfifo() function. -The child writes data into the FIFO and then exits. The parent reads data -from FIFO and writes it to the console. The first argument of the mkfifo() function -indicates the path of the FIFO file.

    Opening a single pipe

    The -parent creates a child process and a pipe to the child process using the popen() function. -A file handle to the pipe is returned to the parent and the parent uses this -handle to read the data written to the pipe by the child. The path of the -child process is passed as the first argument to the popen() function.

    -
    Build

    The following statements are present in all -the .mmp files of the example:

    SYSTEMINCLUDE epoc32\include\stdapis -LIBRARY libc.lib -STATICLIBRARY libcrt0.lib

    Note: You require these statements -because of the following reasons:

      -

    • The epoc32\include\stdapis directory -contains header files such as, stdio.h, unistd.h and -so on that are required to build an Open Environment application.

      • -

    • The libc.lib file -contains the definitions of all functions that are defined in the header files -associated with this example.

      • -

    • The libcrt0.lib file -provides the E32Main() function, which is the entry point -for the main() function of the example.

      • -

    The Symbian -build process describes how to build this example. The IPC builds -the following binaries in the standard location (\epoc32\release\winscw\<build_variant> for -Carbide.c++).

      -

    • ipcparent.exe: Executable -of the parent process.

      • -

    • ipcchild.exe: Executable -of the child process created using the popen() function.

      • -

    • fifochild.exe: Executable -of the child process created using the posix_spawn() function.

      • -
    -
    Runtime setting

    Two eshells must be opened before -executing this example. The executable, ipcparent.exe is -run in one eshell and the other eshell is used to run the child process fifochild.exe. -You can switch between the two eshells by pressing CTRL +ALT +SHIFT +T.

    + + + + + +IPC: IPC Mechanisms +

    This example demonstrates how a parent process communicates with +its child process using various IPC mechanisms. Two executables, a +parent and a child (spawned by the parent) are created to demonstrate +these mechanisms. The child process is created by the parent using +the posix_spawn() function. The parent process +communicates with the child process using the following IPC mechanisms:

    +
      +

    • Named pipes +(FIFO - First in First Out)

      • +

    • Single pipe +(popen() system call)

      • +
    +
    Download

    Click on the following link to download the example: IPC.zip

    Click: browse to view the example code.

    +
    Description

    Spawning the child process

    The posix_spawn() function creates the child process. A pointer to the process ID +(pid) of the child process and the path of the child +process are passed as arguments to this function. The parent waits +for the child to terminate by calling the waitpid() function.

    Creating a named pipe

    This example +creates a named pipe using the mkfifo() function. +The child writes data into the FIFO and then exits. The parent reads +data from FIFO and writes it to the console. The first argument of +the mkfifo() function indicates the path of the +FIFO file.

    Opening a single pipe

    The parent +creates a child process and a pipe to the child process using the popen() function. A file handle to the pipe is returned +to the parent and the parent uses this handle to read the data written +to the pipe by the child. The path of the child process is passed +as the first argument to the popen() function.

    +
    Build

    The following statements are present in all the .mmp files of the example:

    SYSTEMINCLUDE epoc32\include\stdapis +LIBRARY libc.lib +STATICLIBRARY libcrt0.lib

    Note: You require +these statements because of the following reasons:

      +

    • The epoc32\include\stdapis directory contains header files +such as, stdio.h, unistd.h and so on that are required to build an Open Environment application.

      • +

    • The libc.lib file contains the definitions of all functions +that are defined in the header files associated with this example.

      • +

    • The libcrt0.lib file provides the E32Main() function, which is the entry point for the main() function of the example.

      • +

    The IPC builds the following binaries in +the standard location (\epoc32\release\winscw\<build_variant> for Carbide.c++).

      +

    • ipcparent.exe: Executable of the parent process.

      • +

    • ipcchild.exe: Executable of the child process created using the popen() function.

      • +

    • fifochild.exe: Executable of the child process created using the posix_spawn() function.

      • +
    +
    Runtime +setting

    Two eshells must be opened before executing this +example. The executable, ipcparent.exe is run +in one eshell and the other eshell is used to run the child process fifochild.exe. You can switch between the two eshells +by pressing CTRL +ALT +SHIFT +T.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4B4110D9-0CAA-5CA1-A994-9DAF501119E4_d0e240294_href.png Binary file Symbian3/SDK/Source/GUID-4B4110D9-0CAA-5CA1-A994-9DAF501119E4_d0e240294_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4B4110D9-0CAA-5CA1-A994-9DAF501119E4_d0e245253_href.png Binary file Symbian3/SDK/Source/GUID-4B4110D9-0CAA-5CA1-A994-9DAF501119E4_d0e245253_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4B709839-8EEF-4AD2-9868-9AF0176B1E5B.dita --- a/Symbian3/SDK/Source/GUID-4B709839-8EEF-4AD2-9868-9AF0176B1E5B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4B709839-8EEF-4AD2-9868-9AF0176B1E5B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,8 +12,8 @@ Using Sensor Channels APIsThe Sensor Channel establishes a data exchange connection between the sensor framework and hardware using the sensor channel APIs. - -Include the library SensrvClient.lib in + +Include the library SensrvClient.lib in your .mmp file. Include the following diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4B7FA629-BFC9-594B-B253-AC920EAD6E67_d0e79138_href.png Binary file Symbian3/SDK/Source/GUID-4B7FA629-BFC9-594B-B253-AC920EAD6E67_d0e79138_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4B7FA629-BFC9-594B-B253-AC920EAD6E67_d0e79196_href.png Binary file Symbian3/SDK/Source/GUID-4B7FA629-BFC9-594B-B253-AC920EAD6E67_d0e79196_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BAA1BE9-E590-564E-8D5C-C7191AB4D8A6.dita --- a/Symbian3/SDK/Source/GUID-4BAA1BE9-E590-564E-8D5C-C7191AB4D8A6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4BAA1BE9-E590-564E-8D5C-C7191AB4D8A6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,52 +1,40 @@ - - - - - -BitmapsShell: -dealing with bitmaps -

    Note: This example is designed to work with TechView and there -is no guarantee that it will work with other interfaces.

    -
    Download

    Click -on the following link to download the example: BitmapsShell.zip

    Download some additional files -required by the example: CommonGraphicsExampleFiles

    Click: browse to view the example code.

    View the additional -files: browse.
    -
    Description

    BitmapsShell provides -an application shell, and two concrete controls.

    CGraphicExampleControl is -a control class, derived from CCoeControl, which links the -app shell to the particular controls.

    The CBitmapControl and CFbsControl classes, -derived from CGraphicExampleControl, define behaviour for -their particular controls.

    CBitmapControl illustrates -the handling and rendering of bitmaps.

    CFbsControl illustrates -the use of the font and bitmap server.

    -
    Build

    The source code for this example application -can be found in the directory:

    examples\Graphics\Bitmaps

    This -source code may be in the directory in which you installed the Symbian platform, -or it may be in src\common\developerlibrary\ directory. -The directory includes the two project files needed for building the example: bld.inf and -the .mmp file.

    The -Symbian build process describes how to build this application. For -the emulator, an application called BitmapsShell.exe is -created in epoc32\release\winscw\<udeb or urel>\.

    -
    Usage
      -

    1. Launch the emulator:

      \epoc32\release\winscw\<urel -or udeb>\EPOC.EXE.

      2. -

    2. Click on BITMAPSSHELL to -run the application. If using the TechView emulator, this will be in -the Extras menu.

      3. -

    3. The controls are listed -on the menu List of Programs. -Press the appropriate menu item to select a specific control.

      4. -

    4. Step through each phase -of an example by pressing the space bar or by tapping on the window drawn -by that example.

      5. -
    -
    Class Summary

    By the bitmap control:

    TPoint

    TRect

    TSize

    CWindowGc

    TRgb

    CFont

    CFbsBitmap

    By -the font and bitmap server control:

    CWindowGc

    CFbsBitmap

    + + + + + +BitmapsShell: dealing with bitmaps +

    Note: This example is designed to work with TechView and +there is no guarantee that it will work with other interfaces.

    +
    Download

    Click on the following link to download the example: BitmapsShell.zip

    Download some additional +files required by the example: CommonGraphicsExampleFiles

    Click: browse to view the example code.

    View the +additional files: browse.
    +
    Description

    BitmapsShell provides an application shell, +and two concrete controls.

    CGraphicExampleControl is a control class, derived from CCoeControl, which +links the app shell to the particular controls.

    The CBitmapControl and CFbsControl classes, +derived from CGraphicExampleControl, define behaviour +for their particular controls.

    CBitmapControl illustrates the handling and rendering of bitmaps.

    CFbsControl illustrates the use of the font and bitmap server.

    +
    Build

    The source code for this example application can be found in +the directory:

    examples\Graphics\Bitmaps

    This source code may be in the directory in which you installed +the Symbian platform, or it may be in src\common\developerlibrary\ directory. The directory includes the two project files needed for +building the example: bld.inf and the .mmp file.

    The Symbian build process describes +how to build this application. For the emulator, an application called BitmapsShell.exe is created in epoc32\release\winscw\<udeb +or urel>\.

    +
    Usage
      +

    1. Launch the emulator:

      \epoc32\release\winscw\<urel or udeb>\EPOC.EXE.

      2. +

    2. Click on BITMAPSSHELL to run the application. If using the TechView emulator, this will be in the Extras menu.

      3. +

    3. The controls +are listed on the menu List of Programs. Press the appropriate menu item to select a specific control.

      4. +

    4. Step through +each phase of an example by pressing the space bar or by tapping on +the window drawn by that example.

      5. +
    +
    Class +Summary

    By the bitmap control:

    TPoint

    TRect

    TSize

    CWindowGc

    TRgb

    CFont

    CFbsBitmap

    By the font and bitmap server control:

    CWindowGc

    CFbsBitmap

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e190311_href.png Binary file Symbian3/SDK/Source/GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e190311_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e195282_href.png Binary file Symbian3/SDK/Source/GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e195282_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BCE7915-6BF9-5D83-9049-B7FA9725B406_d0e221356_href.png Binary file Symbian3/SDK/Source/GUID-4BCE7915-6BF9-5D83-9049-B7FA9725B406_d0e221356_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BCE7915-6BF9-5D83-9049-B7FA9725B406_d0e226350_href.png Binary file Symbian3/SDK/Source/GUID-4BCE7915-6BF9-5D83-9049-B7FA9725B406_d0e226350_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BEFF7BA-2A39-5601-919E-22AF08D06023.dita --- a/Symbian3/SDK/Source/GUID-4BEFF7BA-2A39-5601-919E-22AF08D06023.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4BEFF7BA-2A39-5601-919E-22AF08D06023.dita Tue Jul 20 12:00:49 2010 +0100 @@ -87,7 +87,7 @@ be used to compress archives to zip archives.

    EZLib Architecture - +
    APIs

    The classes exported from ezlib.dll are tabulated below:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BF48607-54F0-51C8-A3A8-F334454FAC9C_d0e195578_href.png Binary file Symbian3/SDK/Source/GUID-4BF48607-54F0-51C8-A3A8-F334454FAC9C_d0e195578_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4BF48607-54F0-51C8-A3A8-F334454FAC9C_d0e200587_href.png Binary file Symbian3/SDK/Source/GUID-4BF48607-54F0-51C8-A3A8-F334454FAC9C_d0e200587_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4C6B9697-B69C-49D5-AD23-D7C0053BED3A_d0e4773_href.png Binary file Symbian3/SDK/Source/GUID-4C6B9697-B69C-49D5-AD23-D7C0053BED3A_d0e4773_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4C6B9697-B69C-49D5-AD23-D7C0053BED3A_d0e4898_href.png Binary file Symbian3/SDK/Source/GUID-4C6B9697-B69C-49D5-AD23-D7C0053BED3A_d0e4898_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4C859177-7B45-4569-9E27-B207300A7A1C_d0e40663_href.png Binary file Symbian3/SDK/Source/GUID-4C859177-7B45-4569-9E27-B207300A7A1C_d0e40663_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4C859177-7B45-4569-9E27-B207300A7A1C_d0e40821_href.png Binary file Symbian3/SDK/Source/GUID-4C859177-7B45-4569-9E27-B207300A7A1C_d0e40821_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4CC4D912-810B-4542-AFCD-58CEE8E0128C.dita --- a/Symbian3/SDK/Source/GUID-4CC4D912-810B-4542-AFCD-58CEE8E0128C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4CC4D912-810B-4542-AFCD-58CEE8E0128C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,30 +9,27 @@ --> -Open -C libz Example -

    The example demonstrates how to use the libz library to compress a file -and decompress it. The library can compress and decompress any kind of file -(txt, doc, xls, xml, mpeg, ppt, mp3 etc).

    -
    Download

    Click -on the following link to download the example: openclibz.zip

    Click: browse to view the example code.

    -
    Design and -Implementation

    The following sections provide more information -about the steps that the example performs.

    Capabilities

    Program -capabilities are defined in openclibz.mmp: CAPABILITY -None

    Implementation details of EXE

    This example is a -console based application. This application can be launched from the icon -(openclibz) in installed folder and also from eshell. When we launch it through -icon it prompts the user to enter the mode to process. The strategy parameter -is used to select the compression algorithm. For compressing a file, it reads -the file and then compresses it using the API of the libz library and then -stores the compressed content in a (.gz) file. If you want to decompress, -type d. For decompressing a file, it opens the compressed (.gz) file using -libz API's and then reads the content and decompresses it . To check what -happens to the content of the string after compression then type s. Enter -the string you want and see the data in compressed format . This option -is to demonstrate compression of string using libz API's.

    To run this application -through eshell:

    Usage : openclibz [-d] [-f] [-h] [-r] [-1 to -9] [files...] +Open C libz Example +

    The example demonstrates how to use the libz library to compress +a file and decompress it. The library can compress and decompress +any kind of file (txt, doc, xls, xml, mpeg, ppt, mp3 etc).

    +
    Download

    Click on the following link to download the example: openclibz.zip

    Click: browse to view the example code.

    +
    Design +and Implementation

    The following sections provide more +information about the steps that the example performs.

    Capabilities

    Program capabilities are defined in openclibz.mmp: CAPABILITY None

    Implementation +details of EXE

    This example is a console based application. +This application can be launched from the icon (openclibz) in installed +folder and also from eshell. When we launch it through icon it prompts +the user to enter the mode to process. The strategy parameter is used +to select the compression algorithm. For compressing a file, it reads +the file and then compresses it using the API of the libz library +and then stores the compressed content in a (.gz) file. If you want +to decompress, type d. For decompressing a file, it opens the compressed +(.gz) file using libz API's and then reads the content and decompresses +it . To check what happens to the content of the string after compression +then type s. Enter the string you want and see the data in compressed +format . This option is to demonstrate compression of string using +libz API's.

    To run this application through eshell:

    Usage : openclibz [-d] [-f] [-h] [-r] [-1 to -9] [files...] -d : decompress -f : compress with Z_FILTERED -h : compress with Huffman encoding @@ -40,27 +37,27 @@ -1 to -9 : compression level files : absolute path of files

    Some usage tips

    Once you choose compression -process, enter the file name. You should provide absolute path of the file -you want to compress. (drive letter):\[(folder name)\]filename. - To get : on phone you have to press 1 few times. To get on phone you have -to press 1 few times. To get on emulator is bit tricky. If you are lucky -then pressing 1 will get it for you, otherwise change the mode. using "\ BUTTON" -(Just above the enter button in the keyboard) and then try pressing 1. To -press enter on phone we are supposed to press 0 four times.

    Cross -platform usage

    We can compress the file on any platform and uncompress -it on any other platform. For example Unix's gzip files can be compressed -using the example application and decompressed using Unix's gunzip. Compression -can be done in a single step, if the buffers are large enough; or compression -can be done by repeated calls of the compression function. In the second scenario, -application must provide more input and consume the output (providing more -output space) before each call.

    -
    APIs Used

    compress, uncompress, gzopen, gzclose, gzread, gzwrite, gzerror from -libz library

    fopen, fclose, fread, fwrite, mmap, munmap, fstat, unlink, printf, scanf from -libc library

    -
    Building and -Using

    The Symbian -build process describes how to build this example application.

    To -build the example application, go to the openclibz\group directory and build -the application. The definition for the whole application can be found in -the bld.inf file in the group subdirectory of the applications main directory.
    +process, enter the file name. You should provide absolute path of +the file you want to compress. (drive letter):\[(folder +name)\]filename. To get : on phone you have to press +1 few times. To get on phone you have to press 1 few times. To get +on emulator is bit tricky. If you are lucky then pressing 1 will get +it for you, otherwise change the mode. using "\ BUTTON" (Just above +the enter button in the keyboard) and then try pressing 1. To press +enter on phone we are supposed to press 0 four times.

    Cross +platform usage

    We can compress the file on any platform +and uncompress it on any other platform. For example Unix's gzip +files can be compressed using the example application and decompressed +using Unix's gunzip. Compression can be done in a single step, if +the buffers are large enough; or compression can be done by repeated +calls of the compression function. In the second scenario, application +must provide more input and consume the output (providing more output +space) before each call.

    +
    APIs Used

    compress, uncompress, gzopen, gzclose, gzread, gzwrite, gzerror from libz library

    fopen, fclose, fread, fwrite, mmap, munmap, fstat, unlink, printf, scanf from libc library

    +
    Building +and Using

    The Symbian build process describes how to build +this example application.

    To build the example +application, go to the openclibz\group directory and build the application. + The definition for the whole application can be found in the bld.inf +file in the group subdirectory of the applications main directory.
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4CEB52EC-8F08-53B7-A900-AF163316D442.dita --- a/Symbian3/SDK/Source/GUID-4CEB52EC-8F08-53B7-A900-AF163316D442.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4CEB52EC-8F08-53B7-A900-AF163316D442.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ as, TCP/IP, are performed by MTMs. The Messaging Framework provides APIs to enable storage of messages in the Message Store. It also provides APIs to manipulate messages in the Message Store.

    - +
    Documentation and examples

    The following sections list tutorials and example applications that can be referred while creating diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4CFFD28E-25B5-5B3F-859F-DF8ADC1DC029_d0e201428_href.png Binary file Symbian3/SDK/Source/GUID-4CFFD28E-25B5-5B3F-859F-DF8ADC1DC029_d0e201428_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4CFFD28E-25B5-5B3F-859F-DF8ADC1DC029_d0e206435_href.png Binary file Symbian3/SDK/Source/GUID-4CFFD28E-25B5-5B3F-859F-DF8ADC1DC029_d0e206435_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4D4CB4DC-9B9A-5256-B949-C5E9F369D9C6.dita --- a/Symbian3/SDK/Source/GUID-4D4CB4DC-9B9A-5256-B949-C5E9F369D9C6.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -help

    abld help ( ( [ options ] | [ commands ] ) | ( command ) )

    This command provides a brief guide to abld command-line syntax.

    abld help options lists the options available with abld.

    abld help commands lists the available commands.

    abld help command displays the syntax for a particular command, and also a brief description of what the command is used for.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4D82B904-71BF-4945-85ED-655AF8879FF9_d0e67280_href.png Binary file Symbian3/SDK/Source/GUID-4D82B904-71BF-4945-85ED-655AF8879FF9_d0e67280_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4D92E302-3145-4453-AFA1-F5C5BDF933F9.dita --- a/Symbian3/SDK/Source/GUID-4D92E302-3145-4453-AFA1-F5C5BDF933F9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4D92E302-3145-4453-AFA1-F5C5BDF933F9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -97,10 +97,19 @@ CWsScreenDevice::SetPalette(), CWsScreenDevice::PaletteAttributes(), and CWsScreenDevice::GetPalette(). -These APIs are not supported. All calls to these -APIs will return KErrNotSupported. If the existing applications using -these APIs check for KErrNotSupported error, will continue to work -without any change. All other applications must be modified and rebuilt. +These APIs are not supported. All calls to these APIs will +return KErrNotSupported. If the existing applications using these +APIs check for KErrNotSupported error, will continue to work without +any change. All other applications must be modified and rebuilt. + + +CDirectScreenAccess, RDirectScreenAccess, and MDirectScreenAccess. +The usage of these Direct Screen Access (DSA) +APIs has changed in Symbian^3 because of the ScreenPlay feature, which +recommends using external surfaces instead of DSA to write to screen. +Refer to DSA +Migration Guide for information on how to use these APIs in +Symbian^3. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4DB70D45-1E74-5357-9824-566962316E12_d0e108681_href.png Binary file Symbian3/SDK/Source/GUID-4DB70D45-1E74-5357-9824-566962316E12_d0e108681_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4DB70D45-1E74-5357-9824-566962316E12_d0e108913_href.png Binary file Symbian3/SDK/Source/GUID-4DB70D45-1E74-5357-9824-566962316E12_d0e108913_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4DBE998D-9699-5770-8182-929FDCAA7E26_d0e276358_href.png Binary file Symbian3/SDK/Source/GUID-4DBE998D-9699-5770-8182-929FDCAA7E26_d0e276358_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4DBE998D-9699-5770-8182-929FDCAA7E26_d0e281197_href.png Binary file Symbian3/SDK/Source/GUID-4DBE998D-9699-5770-8182-929FDCAA7E26_d0e281197_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4E1D4E5D-7CE6-5A93-9170-BEF2937FC953_d0e192678_href.png Binary file Symbian3/SDK/Source/GUID-4E1D4E5D-7CE6-5A93-9170-BEF2937FC953_d0e192678_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4E1D4E5D-7CE6-5A93-9170-BEF2937FC953_d0e197686_href.png Binary file Symbian3/SDK/Source/GUID-4E1D4E5D-7CE6-5A93-9170-BEF2937FC953_d0e197686_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4E1F04EB-09EA-5354-8EFF-BBC95F44C9AE.dita --- a/Symbian3/SDK/Source/GUID-4E1F04EB-09EA-5354-8EFF-BBC95F44C9AE.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to use the audio player utility \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4EE4E79E-F6D5-5F14-BA8D-4DD10D229B74.dita --- a/Symbian3/SDK/Source/GUID-4EE4E79E-F6D5-5F14-BA8D-4DD10D229B74.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4EE4E79E-F6D5-5F14-BA8D-4DD10D229B74.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,10 +9,80 @@ --> -Handling BLOBs

    This document introduces you to Binary Large Objects (BLOB) in Symbian SQL.

    Purpose

    A BLOB is an SQL database container object for binary large objects, usually images or audio files but may also include other binary files such as an application executable.

    Features of SQL BLOB

    BLOBS offer the following features:

    • read from and write to BLOB objects in a RAM-efficient manner -- enables an overall reduction of RAM usage,

    • reduced read latency (compared to previous versions) -- improving the responsiveness of client applications,

    • larger BLOB objects can be stored and retrieved (>16Mb). Before version 9.5 there was a limit on the size of a BLOB object supported by Symbian SQL. This limit was dictated by the amount of server-side RAM available. Applications that needed to store large BLOB objects in their database (for example, MP3 files) are no longer restricted by this limit.

    • The maximum possible length for a blob is 2147483647 bytes.

    Streaming

    The classes RSqlBlobReadStream and RSqlBlobWriteStream allow direct access to BLOB content. These classes do not require the whole BLOB to be loaded into RAM before streaming can begin. These classes match the standard Symbian RReadStream /RWriteStream idiom.

    The server intelligently chooses the size of an internal buffer to incrementally read/write the requested blob data in blocks. The size of the buffer is calculated based on a combination of the size of the request and the value of aBlockSizeHint (if specified).

    aBlockSizeHint is provided by the client to provide a hint to the server about the size of block that it is intending to use to read/write the blob data. This is advance information about the intended behaviour of the client that the server may use to its benefit to read/write the blob data.

    Whole-blob access

    The class TSqlBlob allows one-shot storage and retrieval of whole blobs. This class avoids the need for double buffering of the blob in both the client and the server.

    there are two versions of the BLOB get functions. One is non-leaving and the other is leaving.

    Use the non-leaving variant when the client knows that the blob will either:

    • all be of a fixed size,

    • not exceed an upper size limit.

    In these situations the client can pre-allocate a buffer and avoid the overhead of memory allocation.

    Use the leaving variant when the client does not have prior knowledge of the BLOB size (or if the size varies wildly). In this situation the server allocates a buffer and passes ownership to the client.

    RAM benefits

    Symbian SQL has been improved to eliminate the need for a 2 MB server-side buffer. Data is transferred to the client in blocks so for example, the server-side buffer may be reduced to 32 KB.

    Previous to version 9.5, both whole-blob and streaming use cases require up to 3MB of server-side RAM. The page cache size is capped at 1MB due to a built-in limiting mechanism. But, a 2MB buffer must be allocated to hold the entire blob. A critical side-effect of this is that, due to heap exhaustion, there is a maximum limit on the size of a blob object that can be written to or read from a database.

    In the following diagram the top two sections illustrate whole-blob retrieval in which the entire blob is retrieved in one go using RSqlStatement. The bottom section illustrates streaming retrieval in which the blob is retrieved in blocks specified by the client using RSqlColumnReadStream.

    - Reading a 2MB blob. -
    SQL Security - Policies Database file - format SQLite - Modules Free Space - Reclaimation SQL Overview     \ No newline at end of file +Handling BLOBs +

    This document introduces you to Binary Large Objects (BLOB) in +Symbian SQL.

    +
    Purpose

    A BLOB is an SQL database container +object for binary large objects, usually images or audio files but +may also include other binary files such as an application executable.

    +
    Features of SQL BLOB

    BLOBS offer the following +features:

      +

    • read from and +write to BLOB objects in a RAM-efficient manner -- enables an overall +reduction of RAM usage,

      • +

    • reduced read +latency (compared to previous versions) -- improving the responsiveness +of client applications,

      • +

    • larger BLOB +objects can be stored and retrieved (>16Mb). Before version 9.5 there +was a limit on the size of a BLOB object supported by Symbian SQL. +This limit was dictated by the amount of server-side RAM available. +Applications that needed to store large BLOB objects in their database +(for example, MP3 files) are no longer restricted by this limit.

      • +

    • The maximum +possible length for a blob is 2147483647 bytes.

      • +
    +
    Streaming

    The classes RSqlBlobReadStream and RSqlBlobWriteStream allow direct access to +BLOB content. These classes do not require the whole BLOB to be loaded +into RAM before streaming can begin. These classes match the standard +Symbian RReadStream /RWriteStream idiom.

    The server intelligently chooses the size of an internal +buffer to incrementally read/write the requested blob data in blocks. +The size of the buffer is calculated based on a combination of the +size of the request and the value of aBlockSizeHint (if specified).

    aBlockSizeHint is provided +by the client to provide a hint to the server about the size of block +that it is intending to use to read/write the blob data. This is advance +information about the intended behaviour of the client that the server +may use to its benefit to read/write the blob data.

    +
    Whole-blob access

    The class TSqlBlob allows one-shot storage and retrieval of whole blobs. This class +avoids the need for double buffering of the blob in both the client +and the server.

    there are two versions of the BLOB get functions. +One is non-leaving and the other is leaving.

    Use the non-leaving variant when the client knows that the blob will +either:

      +

    • all be of a +fixed size,

      • +

    • not exceed an +upper size limit.

      • +

    In these situations the client can pre-allocate a buffer +and avoid the overhead of memory allocation.

    Use the leaving +variant when the client does not have prior knowledge of the BLOB +size (or if the size varies wildly). In this situation the server +allocates a buffer and passes ownership to the client.

    +
    RAM benefits

    Symbian SQL has been improved +to eliminate the need for a 2 MB server-side buffer. Data is transferred +to the client in blocks so for example, the server-side buffer may +be reduced to 32 KB.

    Previous to version 9.5, both whole-blob +and streaming use cases require up to 3MB of server-side RAM. The +page cache size is capped at 1MB due to a built-in limiting mechanism. +But, a 2MB buffer must be allocated to hold the entire blob. A critical +side-effect of this is that, due to heap exhaustion, there is a maximum +limit on the size of a blob object that can be written to or read +from a database.

    In the following diagram the top two sections +illustrate whole-blob retrieval in which the entire blob is retrieved +in one go using RSqlStatement. The bottom section +illustrates streaming retrieval in which the blob is retrieved in +blocks specified by the client using RSqlColumnReadStream.

    + Reading a 2MB blob. + +
    +     +SQL +Security Policies +Database +file format +SQLite + Modules + Reclaiming +Free Space +SQL +Overview +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4F879832-8425-5C56-B3FE-4C4592EBB6A5_d0e306923_href.png Binary file Symbian3/SDK/Source/GUID-4F879832-8425-5C56-B3FE-4C4592EBB6A5_d0e306923_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4F879832-8425-5C56-B3FE-4C4592EBB6A5_d0e313397_href.png Binary file Symbian3/SDK/Source/GUID-4F879832-8425-5C56-B3FE-4C4592EBB6A5_d0e313397_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4F9B3746-1FB2-5F3D-BD2C-189250C2C59F.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-4F9B3746-1FB2-5F3D-BD2C-189250C2C59F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Secure Sockets InterfaceThis section describes the Secure sockets interface.
    Description of the interface

    Secure Sockets allow the user to transport data over a public network. It provides both parties the ability to authenticate and to encrypt the data being sent.

    Secure sockets implement the MSecureSocket interface and its methods to:

    • create and close a secure connection

    • specify and query the certificates used in a connection

    • send and receive data

    This interface supports implementations that act in both the client modes, that is, connecting to a remote secure server, and acting as a server for remote clients.

    Secure socket implementations are used to secure an open and a connected socket. An application creates an instance of the CSecureSocket with reference to a connected RSocket and a protocol name to use. The CSecureSocket finds, loads, and creates a secure socket of the implementation. The CSecureSocket owns an instance of the CSecureSocket implementation object and acts as a proxy, sending any method calls to the actual implementation object.

    Protocol implementations are not directly exposed to applications. From the applications, the CSecureSocket class hides the MSecureSocket class and the plug-in nature of the implementations. Secure sockets are created through the static CSecureSocket::NewL() method.

    A secure socket plug-in is provided for TLS1.0 or SSL3.0.

    Protocol implementations

    Protocol implementations use the methods of the CSecureSocket to:

    • set a secure socket

    • set or get the current server certificate

    • set or get a protocol or version, if the implementations supports more than one

    • set or get the supported cipher suites. Note: Cipher suites are methods of encrypting the text.

    Sockets Server     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4FC82562-9163-45F5-9E14-DA0AB6B5E54C.dita --- a/Symbian3/SDK/Source/GUID-4FC82562-9163-45F5-9E14-DA0AB6B5E54C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4FC82562-9163-45F5-9E14-DA0AB6B5E54C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ the interaction style or language settings are not affected.

    Simplified illustration of the UI theme concept - +

    UI themes give the UI theme designer a freedom to design a unique GUI, and by designing backgrounds and icons, the result can be very different from diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-4FE5CA06-8C3A-4AC1-80CE-4418AC55937A.dita --- a/Symbian3/SDK/Source/GUID-4FE5CA06-8C3A-4AC1-80CE-4418AC55937A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-4FE5CA06-8C3A-4AC1-80CE-4418AC55937A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,8 +19,8 @@ time from the name / value pairs.

    The following are the steps to encode the WSP header:

     - - + + Create a header encoder object. //creates a pointer to CWspHeaderEncoder object CWspHeaderEncoder* primEncoder = CWspHeaderEncoder::NewLC(); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5012D63B-4353-5616-BBFB-DB04DAF71679.dita --- a/Symbian3/SDK/Source/GUID-5012D63B-4353-5616-BBFB-DB04DAF71679.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5012D63B-4353-5616-BBFB-DB04DAF71679.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,57 +1,49 @@ - - - - - -XmlExample: -Using the XML framework to parse an XML file -
    Download

    Click -on the following link to download the example: XmlExample.zip

    Click:browse to view the example code.

    -
    Introduction

    This example application demonstrates -the usage of the XML framework API to parse XML and WBXML -files.

    The overview contains the following sections:

      -

    • Description

      • -

    • Class summary

      • -

    • Build

      • -
    -
    Description

    The -example application demonstrates, how to use the Xml framework -to parse XML and WBXML files. It takes a valid XML file with a DTD (Document -Type Declaration) definining its structure, and a WBXML (WAP Binary XML format) -file as input. You can generate a WBXML file from an XML file using any freeware -converters. The application's bld.inf file specifies -the target path to which all the three files (XML, DTD, WBXML) need to be -exported.

    The application implements all the pure virtual functions -of the Xml::MContentHandler class, which is a client interface -to the Xml framework. These functions inform the client -application about the XML element being parsed, its content, parser errors -if any and so on.

    The XML and WBXML files are parsed using an object -of the Xml::CParser class. The parser object is configured -to report namespace mappings to the client application, using the function Xml::CParser::EnableFeature().

    The -application first opens a file session using RFs to read -the XML and WBXML files. Then, the Xml::ParseL() function -is called to start parsing the files. The application parses the XML file -followed by the WBXML file. While these files are being parsed, status messages -are printed to the console by the callback functions as and when they are -invoked.

    For demonstration purposes, the XML file is parsed twice, -once by the Xml::CParser object created using the MIME -type and again by the CParser object created using match -data criteria. The match data criteria are specified using an object of the Xml::CMatchData class, -which is passed to the Xml::CParser::NewLC() function while -creating the parser object. This will return a CParser object -that matches the specified MIME type, variant and so on.

    -
    Class summary

    Xml::MContentHandler Xml::RDocumentParameters Xml::RAttributeArray Xml::CParserXml::CMatchData

    -
    Build

    The Symbian platform build process describes -how to build an application.

    The XmlExample builds -an executable called xmlexample.exe in the standard location -(\epoc32\release\winscw\<build_variant> for CodeWarrior). -After launching the executable, depending on the emulator you are using, you -may need to task away from the application launcher/shell screen to view the -console.

    + + + + + +XmlExample: Using the XML framework to parse an XML file +
    Download

    Click on the following link to download the example: XmlExample.zip

    Click:browse to view the example code.

    +
    Introduction

    This example application demonstrates +the usage of the XML framework API to parse XML +and WBXML files.

    The overview contains the following sections:

      +

    • Description

      • +

    • Class summary

      • +

    • Build

      • +
    +
    Description

    The example application demonstrates, how to use the Xml framework to parse XML and WBXML files. It takes a +valid XML file with a DTD (Document Type Declaration) definining its +structure, and a WBXML (WAP Binary XML format) file as input. You +can generate a WBXML file from an XML file using any freeware converters. +The application's bld.inf file specifies the +target path to which all the three files (XML, DTD, WBXML) need to +be exported.

    The application implements all the pure virtual +functions of the Xml::MContentHandler class, which +is a client interface to the Xml framework. These +functions inform the client application about the XML element being +parsed, its content, parser errors if any and so on.

    The XML +and WBXML files are parsed using an object of the Xml::CParser class. The parser object is configured to report namespace mappings +to the client application, using the function Xml::CParser::EnableFeature().

    The application first opens a file session using RFs to read the XML and WBXML files. Then, the Xml::ParseL() function is called to start parsing the files. +The application parses the XML file followed by the WBXML file. While +these files are being parsed, status messages are printed to the console +by the callback functions as and when they are invoked.

    For +demonstration purposes, the XML file is parsed twice, once by the Xml::CParser object created using the MIME type and again +by the CParser object created using match data criteria. +The match data criteria are specified using an object of the Xml::CMatchData class, which is passed to the Xml::CParser::NewLC() function while creating the parser +object. This will return a CParser object that matches +the specified MIME type, variant and so on.

    +
    Class +summary

    Xml::MContentHandler Xml::RDocumentParameters Xml::RAttributeArray Xml::CParserXml::CMatchData

    +
    Build

    The Symbian platform build process describes how to build an +application.

    The XmlExample builds an executable called xmlexample.exe in +the standard location (\epoc32\release\winscw\<build_variant> for CodeWarrior). After launching the executable, depending on the +emulator you are using, you may need to task away from the application +launcher/shell screen to view the console.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita --- a/Symbian3/SDK/Source/GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita Tue Jul 20 12:00:49 2010 +0100 @@ -43,7 +43,7 @@
    Architectural relationships

    The following diagram shows the relationships between the Khronos rendering APIs.

    Dependencies between the Khronos rendering components - +
    Graphics diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-504E4334-FDA9-5982-8BF7-509D019AFD4C_d0e323870_href.jpg Binary file Symbian3/SDK/Source/GUID-504E4334-FDA9-5982-8BF7-509D019AFD4C_d0e323870_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-504E4334-FDA9-5982-8BF7-509D019AFD4C_d0e330340_href.jpg Binary file Symbian3/SDK/Source/GUID-504E4334-FDA9-5982-8BF7-509D019AFD4C_d0e330340_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-504EB40B-AC98-5AB2-9263-185887C29A7E.dita --- a/Symbian3/SDK/Source/GUID-504EB40B-AC98-5AB2-9263-185887C29A7E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,161 +0,0 @@ - - - - - -Searching -for an IAP Record by Name and Loading the Associated Service and the Bearer -Table: TutorialThis tutorial shows you how to search for a Symbian platform defined -Internet Access Points Configuration (IAP) record by name. The tutorial, then -shows you how load the connected service and the bearer table. - - -

    Before you start, -you must understand:

      -

    • the general concept -of the Comms Database

      • -

    • the specific concept -of fields, records, links and tables

      • -

    • how to write and build -application code to run on Symbian platform

      • -
     -

    This tutorial shows -you:

      -

    • how to search the Internet -Access Points Configuration table for a record defined by name. This table -is also called the IAP table

      • -

    • how to load the connected -service.

      • -

    • how to load the connected -bearer table.

      • -

    The principles that apply here also apply to the other Symbian platform -defined tables.

    - -Make sure that you -have created a session. - -Create an empty -IAP record in the tool or application process. - -You create a CMDBRecordSet <T> object -and specify CCDIAPRecord as the template -parameter. - -Symbian platform defines the CCDIAPRecord class to -represent a IAP record. The class is a schema for the record. The class defines -the fields and links that make a IAP record. -Symbian platform defines unique -numeric Id s for Symbian platform defined tables. The symbol KCDTIdIAPRecord also defines the value of this -Id for records in the IAP table. The Id allows the CommsDat API to get the -record from the Comms Database. -To work with other Symbian platform defined tables, use the correct -class name and the correct unique numeric Id values. The Reference section -contains a list of all Symbian platform defined tables. -... - -// This code fragment assumes that a session with the Comms Database has been created. -// iDb is a pointer to a CMDBSession object -... - -// When we search by Name or Id, there can be only one record to be returned -// Create an empty IAP record. -// -// Note: -// 1. the template parameter CCDIAPRecord defines -// the "IAP" record type. -// 2. to create a record, you use a factory function and pass the unique -// numeric Id KCDTIdIAPRecord as a parameter to the constructor. -// - -CCDIAPRecord* ptrIAPRecord = - static_cast<CCDIAPRecord *>(CCDRecordBase::RecordFactoryL(KCDTIdIAPRecord)); -... - -Define the name -of the IAP record to be found and set the name in IAP record. Do the search -for the record in the Comms Database. - -In this tutorial, the name of the IAP record is NTRas with Null Modem. - -Use the assignment operator to add the data to a field. A field that -has type T accepts a type T item as the right-hand argument -of an assignment call. - -A descriptor field needs an additional call to set the size of the descriptor. -Call SetMaxLengthL() to set the size of the descriptor. This -function is a member of the field class CMDBField <TDesC>. -Internally, the function causes the allocation of a descriptor. You must set -the size of the descriptor before you assign the data. You can also use the SetL() function. -This function sets the length and assigns the data. The function is a member -of the field class CMDBField <TDesC>. -... -// Define the name of the IAP record. -_LIT(KMyIap, "NTRas with Null Modem"); - -// Either -ptrIAPRecord->iRecordName.SetMaxLengthL(KMyIap().Length()); -ptrIAPRecord->iRecordName = KMyIap; - -// Or -ptrIAPRecord->iRecordName.SetL(KMyIap); - - -// Search the Comms Database -if(ptrIAPRecord->FindL(*iDb)) - { - // Found a matching record - ... - } - -... - -Load the NTRas with -Null Modem service and the associated bearer table. -... -// Search the Comms Database -if(ptrIAPRecord->FindL(*iDb)) - { - // Found a matching record - - // Now load the the associated service and bearer tables, - // The variables iService,iBearer, etc - // are links that point to other records. These links have a "Value" and - // "iLinkedRecord". - // - // The "Value" represent the id of the target field,and gets initialized along with the - // parent record(ptrIAPRecord). When we explictly call load on these LinkedFields, - // the "iLinkedRecord" pointer points to the appropriate object. - // - // The "iLinkedRecord" pointer is owned by the parent record and gets - // deleted along with it.THis means that it must be set to NULL - // if the user wants to take ownership. - - ptrIAPRecord->iService.LoadL(*iDb); - ptrIAPRecord->iBearer.LoadL(*iDb); - - // Take ownership of the loaded service record cache - CCDServiceRecordBase* ptrService = - static_cast< CCDServiceRecordBase *> (ptrIAPRecord->iService.iLinkedRecord); - (ptrIAPRecord->iService).iLinkedRecord = NULL; - - // Deleting ptrIAPRecord also deletes all the loaded iLinkedRecord - // pointers it owns unless set to null. - - delete ptrIAPRecord; - - //delete the service view. - delete ptrService; - } -... - - -     -Comms Database - concepts -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5059C3F9-1CEA-5DF3-914A-B99376570242_d0e278106_href.jpg Binary file Symbian3/SDK/Source/GUID-5059C3F9-1CEA-5DF3-914A-B99376570242_d0e278106_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5059C3F9-1CEA-5DF3-914A-B99376570242_d0e282945_href.jpg Binary file Symbian3/SDK/Source/GUID-5059C3F9-1CEA-5DF3-914A-B99376570242_d0e282945_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50941508-B999-5FCC-B2B9-F29F5F2CA4C1.dita --- a/Symbian3/SDK/Source/GUID-50941508-B999-5FCC-B2B9-F29F5F2CA4C1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -userinclude

    userinclude directory-list

    Use the userinclude statement to define directories to be scanned for files specified in #include statements in source and resource files.

    It may be specified any number of times, and each may have any number of directories.

    When a project is being built, the pre-processor will be invoked specifying all the userinclude and systeminclude directories indicated in these statements. No standard include directories will be searched unless the project links to Win32 libraries under WINS.

    Files included from source code with a line such as

    #include "squash.h"

    will first be searched for in the directory containing the source file, then in the userinclude directories and finally in the systeminclude directories.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50AB1B77-1912-5C73-A1B5-41220E7A2EA5.dita --- a/Symbian3/SDK/Source/GUID-50AB1B77-1912-5C73-A1B5-41220E7A2EA5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50AB1B77-1912-5C73-A1B5-41220E7A2EA5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@

    The other characteristics of a store map follow from this.

    -<image href="GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e357820_href.png" placement="inline"/> +<image href="GUID-4028CDCF-D2E8-5668-A751-A7CFA86CED46_d0e386813_href.png" placement="inline"/> </fig> <p>Entries in the store map can be deleted. An entry can be identified either by Swizzle or by stream ID. <codeph>CStoreMap::Unbind()</codeph> deletes an diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66.dita --- a/Symbian3/SDK/Source/GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50BBCB9C-F234-5813-A42E-3FCFB0F14B66.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ server information, meta information, and body content. The following image illustrates a simple HTTP session between a client and a server. </p> <fig id="GUID-784DD05A-B86B-57F0-A2E0-A34E373ABA34"> <title> Simple HTTP Interaction - +

    See Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616 for more details.

    Architectural diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita --- a/Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,32 +9,36 @@ --> <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept id="GUID-50BE8F1A-513A-433C-B045-66658FC226D7" xml:lang="en"><title>Client/server -communication -

    Inter Process -Communication (IPC) is the basis for client/server architecture. Clients -and servers run in different threads, although not necessarily in different -processes, and communicate through message passing protocol. There are no -direct pointers between the parties, leaving the integrity of the server and -its resources untouched by clients. For more information, see Introduction -to the client/server architecture.

    -

    Communication between the client and the server is managed by Inter-thread data transfer. -Only the server and its clients can decode the parameters of the message. -This is also a security feature, because process boundaries are separators -of memory space, direct pointers to the client's data structures cannot be -delivered. All data not fitting in the provided integers must be represented -as a descriptor, -and an address to the descriptor (or actually a TPckg object) -is delivered within the message. The server then uses safe inter-thread read -and write functions to access the provided descriptor.

    +Client/server communication +

    Inter +Process Communication (IPC) is the basis for client/server +architecture. Clients and servers run in different threads, although +not necessarily in different processes, and communicate through message +passing protocol. There are no direct pointers between the parties, +leaving the integrity of the server and its resources untouched by +clients. For more information, see Introduction to the +client/server architecture.

    +

    Communication between the client and the server is managed by Inter-thread data +transfer. Only the server and its clients can decode the parameters +of the message. This is also a security feature, because process boundaries +are separators of memory space, direct pointers to the client's data +structures cannot be delivered. All data not fitting in the provided +integers must be represented as a descriptor, and an address to the descriptor (or actually a TPckg object) is delivered within the message. +The server then uses safe inter-thread read and write functions to +access the provided descriptor.

    The following figure shows the relationship of the TDesC and TPckg classes.

    -Relationship of a message package and a descriptor class -

    Consider the following issues when implementing the client-side API:

    +Relationship of a message package and a descriptor class +

    Consider the following issues when implementing the client-side +API:

      -

    • Determine if the server is already running with the TFindServer class. If not, then it should be launched.

      • -

    • Once the server is running, create the connection with RSessionBase::CreateSession and make sure there are free message slots available to avoid lost -messages.

      • -

    • When packaging message arguments, make sure they are in a -format that the server understands. For more information, see TIpcArgs.

      • +

    • Determine if the server is already running with the TFindServer class. If not, then it should be +launched.

      • +

    • Once the server is running, create the connection +with RSessionBase::CreateSession and make sure there +are free message slots available to avoid lost messages.

      +
      • +

    • When packaging message arguments, make sure they +are in a format that the server understands. For more information, +see TIpcArgs.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50CA5439-29A1-426C-83BA-EC048FE86CDE.dita --- a/Symbian3/SDK/Source/GUID-50CA5439-29A1-426C-83BA-EC048FE86CDE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50CA5439-29A1-426C-83BA-EC048FE86CDE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,15 +19,15 @@ it must request the OOM Monitor using the ROomMonitorSession::RequestFreeMemory() method.

    An application can request for free RAM either synchronously or asynchronously.

    - -Create an OOM Monitor + +Create an OOM Monitor session ROomMonitorSession ioomMonitorSession; CleanUpClosePushL(ioomMonitorSession); User::LeaveIfError(ioomMonitorSession.Connect()); -Request for free +Request for free memory can be done in two ways: diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50F216D0-242A-5796-BDCC-7AAB28535458.dita --- a/Symbian3/SDK/Source/GUID-50F216D0-242A-5796-BDCC-7AAB28535458.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,82 +0,0 @@ - - - - - -Features -command syntax -
    Purpose

    The features tool processes -the Feature Database Manager (xml file) and generates the header file, feature -choices obey file and/or features.dat file. The header -file contains feature UIDs. The feature choices obey file is used to create -different ROM images. The features.dat file which is -a binary file, is used as a default configuration file by the Symbian emulator. -The features tool accepts both feature manager and feature -registry database as input, and for the feature registry database, it generates -only features.dat.

    -
    Syntaxfeatures [options] <xml database file> [<xml database file1> <xml database file2>...]

    The following options can be used:

    - - - -Options -Description - - --r[=<destination path>] or --hdrfile[=<destination -path>] -Creates a header file in <destination path> or -in the default path \epoc32\include, if the destination -path is not specified. - - --i[=<destination path>] or --ibyfile[=<destination -path> -Creates an IBY file in <destination path> or in -the default path \epoc32\rom\include\, if the destination -path is not specified. - - --d[=<destination path>] or --datfile[=<destination -path>] -Creates features.dat file in <destination -path> or in the current directory, if the destination path is not -specified. - - --c[=<destination path>] or --convert[=<destination -path>] -Converts the given feature registry database into a feature manager -database (for example, featureregistryname_converted.xml) -in <destination path> or in the current directory, if -the destination path is not specified. The converted file is named as featureregistryname_converted.xml by -default. See Conversion of feature registry DB to feature manager DB. - - --s or --strict -Enables strict mode. - - --v or --verbose -Enables verbose mode. - - --h or --help -Displays help. - - ---version -Displays the version of the tool. - - - -

    The features tool also allows you to specify a combination of options -(for example, features -rcv).

    <xml database -file> can be either a Feature Registry database (featureUIDs.xml) -or a Feature Manager database (featuredatabase.xml)

    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50FD71BF-2DDA-5E80-9904-82DC90FCE6DD.dita --- a/Symbian3/SDK/Source/GUID-50FD71BF-2DDA-5E80-9904-82DC90FCE6DD.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Resource member initialisation \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5107ABD8-6408-5501-8073-ACAF3719247B.dita --- a/Symbian3/SDK/Source/GUID-5107ABD8-6408-5501-8073-ACAF3719247B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5107ABD8-6408-5501-8073-ACAF3719247B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -81,7 +81,7 @@ and these classes provide the data members the contain the maximum length and the current length of the data.

    - +

    While an RBuf descriptor has similarities to a heap descriptor, it behaves more like a standard 'R' type resource class, i.e. as a handle diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5127C80E-EACE-5524-9A75-A0EFB41C2226.dita --- a/Symbian3/SDK/Source/GUID-5127C80E-EACE-5524-9A75-A0EFB41C2226.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5127C80E-EACE-5524-9A75-A0EFB41C2226.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ removed. The tail always logically follows the head and the implementation ensures that the tail never overtakes the head.

    - +

    Physically, the buffer is a contiguous block of memory. The implementation provides the appearance of circularity.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-512D0DA7-0BC2-534F-9233-11F46D285CA6_d0e7148_href.png Binary file Symbian3/SDK/Source/GUID-512D0DA7-0BC2-534F-9233-11F46D285CA6_d0e7148_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-512D0DA7-0BC2-534F-9233-11F46D285CA6_d0e7270_href.png Binary file Symbian3/SDK/Source/GUID-512D0DA7-0BC2-534F-9233-11F46D285CA6_d0e7270_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-516D2E22-F5C0-56FE-ABDA-948F01CD50DB_d0e215568_href.png Binary file Symbian3/SDK/Source/GUID-516D2E22-F5C0-56FE-ABDA-948F01CD50DB_d0e215568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-516D2E22-F5C0-56FE-ABDA-948F01CD50DB_d0e220566_href.png Binary file Symbian3/SDK/Source/GUID-516D2E22-F5C0-56FE-ABDA-948F01CD50DB_d0e220566_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-517D9795-88BC-5959-9384-36F132AE634C_d0e135615_href.png Binary file Symbian3/SDK/Source/GUID-517D9795-88BC-5959-9384-36F132AE634C_d0e135615_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-517D9795-88BC-5959-9384-36F132AE634C_d0e139220_href.png Binary file Symbian3/SDK/Source/GUID-517D9795-88BC-5959-9384-36F132AE634C_d0e139220_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51B0D0A9-C9FA-59DA-82B1-5834980CB35D_d0e271836_href.jpg Binary file Symbian3/SDK/Source/GUID-51B0D0A9-C9FA-59DA-82B1-5834980CB35D_d0e271836_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51B0D0A9-C9FA-59DA-82B1-5834980CB35D_d0e276682_href.jpg Binary file Symbian3/SDK/Source/GUID-51B0D0A9-C9FA-59DA-82B1-5834980CB35D_d0e276682_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51D6F328-82C4-5224-A51B-3EB9D4FF7B4C_d0e336843_href.png Binary file Symbian3/SDK/Source/GUID-51D6F328-82C4-5224-A51B-3EB9D4FF7B4C_d0e336843_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51D6F328-82C4-5224-A51B-3EB9D4FF7B4C_d0e343309_href.png Binary file Symbian3/SDK/Source/GUID-51D6F328-82C4-5224-A51B-3EB9D4FF7B4C_d0e343309_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51DDCDA8-8B26-4016-8CBA-BDBF82447096_d0e52712_href.png Binary file Symbian3/SDK/Source/GUID-51DDCDA8-8B26-4016-8CBA-BDBF82447096_d0e52712_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51DDCDA8-8B26-4016-8CBA-BDBF82447096_d0e52855_href.png Binary file Symbian3/SDK/Source/GUID-51DDCDA8-8B26-4016-8CBA-BDBF82447096_d0e52855_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51E0F9C6-CFAF-5113-8516-30045B1269C7_d0e108527_href.png Binary file Symbian3/SDK/Source/GUID-51E0F9C6-CFAF-5113-8516-30045B1269C7_d0e108527_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51E0F9C6-CFAF-5113-8516-30045B1269C7_d0e108759_href.png Binary file Symbian3/SDK/Source/GUID-51E0F9C6-CFAF-5113-8516-30045B1269C7_d0e108759_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51F43258-B3D8-5EC9-85EF-67F09499C253.dita --- a/Symbian3/SDK/Source/GUID-51F43258-B3D8-5EC9-85EF-67F09499C253.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-51F43258-B3D8-5EC9-85EF-67F09499C253.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Alarm States

    This section explains the various states of an alarm.

    At a given point of time, alarms can be in only one state, which is represented by TAlarmState. The following diagram is self-explanatory and represents the state transition of alarms:

    State Transition of Alarms -

    See Also

    Types of Alarm

    \ No newline at end of file +

    See Also

    Types of Alarm

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51F63BFF-CD62-4FFC-929D-ED778642044E_d0e63705_href.png Binary file Symbian3/SDK/Source/GUID-51F63BFF-CD62-4FFC-929D-ED778642044E_d0e63705_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-51F63BFF-CD62-4FFC-929D-ED778642044E_d0e63848_href.png Binary file Symbian3/SDK/Source/GUID-51F63BFF-CD62-4FFC-929D-ED778642044E_d0e63848_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5223D1C1-CBBE-551A-AC57-CD94F9D1B9B6_d0e273833_href.png Binary file Symbian3/SDK/Source/GUID-5223D1C1-CBBE-551A-AC57-CD94F9D1B9B6_d0e273833_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5223D1C1-CBBE-551A-AC57-CD94F9D1B9B6_d0e278679_href.png Binary file Symbian3/SDK/Source/GUID-5223D1C1-CBBE-551A-AC57-CD94F9D1B9B6_d0e278679_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-52743192-B1E0-5B71-B85B-43487F18F412_d0e427403_href.png Binary file Symbian3/SDK/Source/GUID-52743192-B1E0-5B71-B85B-43487F18F412_d0e427403_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-52743192-B1E0-5B71-B85B-43487F18F412_d0e431203_href.png Binary file Symbian3/SDK/Source/GUID-52743192-B1E0-5B71-B85B-43487F18F412_d0e431203_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-52783B69-09FC-4123-849A-79FF61406129_d0e38122_href.png Binary file Symbian3/SDK/Source/GUID-52783B69-09FC-4123-849A-79FF61406129_d0e38122_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-52783B69-09FC-4123-849A-79FF61406129_d0e38290_href.png Binary file Symbian3/SDK/Source/GUID-52783B69-09FC-4123-849A-79FF61406129_d0e38290_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5280EC0E-1A1F-5777-ACB1-CF4791EE2147.dita --- a/Symbian3/SDK/Source/GUID-5280EC0E-1A1F-5777-ACB1-CF4791EE2147.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,75 +0,0 @@ - - - - - -start -resource -

    start resource source-file

    -

    [target target-file-name]

    -

    [targetpath targetpath]

    -

    [header | headeronly]

    -

    [lang languages]

    -

    [uid uid-value-1 [uid-value-2] -]

    -

    end

    -

    A start resource section specifies how a resource file -should be compiled.

    -

    source-file specifies the resource source (.rss) -file. The file should be in the current sourcepath directory, -or specified relatively to that directory.

    -

    The optional target target-file specifies -the name of the compiled resource file. The file extension part of the name -does not need to be specified, as this will be automatically supplied. By -default, the target has the same name as the source file.

    -

    The optional targetpath targetpath allows -you to specify the location of the compiled file on the z: drive -(or the emulated Z: drive). By default, the target file -is built into the same directory as the project's executable.

    - In Symbian OS v9.0 and later, platform security requires resources -to be placed into the correct path, either \resource for -resources that are public but read-only, or \private\12345678, -for resources that are private to the application with application Secure_Id 12345678. -This means that this keyword will almost always be used. -

    The optional header keyword causes a resource header (.rsg) -file to be created in epoc32\include\ along with the -resource (.rsc) file. The optional headeronly keyword -causes only the resource header (.rsg) file to be created -in epoc32\include\. The resource header defines identifiers -for the index positions of the structures in the resource file.

    -

    The optional lang keyword specifies language codes for -the resource. This overrides any language settings made for the mmp file using -the lang keyword. -A language code is two-digit code, and is used to complete the extension of -the built resource file: e.g. if the language code is 01, then the extension -is .r01. The default language code is sc. -The resource file is compiled multiple times, once for each language specified.

    -

    The optional uid keyword specifies the values for the -second, and optionally, the third UID of the resource file. See UID2 -and UID3 statements and RResourceFile::UidType() for -more information.

    -

    This example builds the resource foo.rss into z:\private\10001234\foo.rsc.

    start resource foo.rss -TARGETPATH private\10001234 -end -

    This example builds the resource foo.rss into z:\private\10001234\bar.r01, -and creates a header bar.rsg in epoc32\include.

    START RESOURCE foo.rss -TARGET bar -TARGETPATH private\10001234 -HEADER -LANG 01 -UID 0x10002345 0x10003456 -END

    This example builds only the resource header bar.rsg in epoc32\include.

    START RESOURCE foo.rss -HEADERONLY -END     -     -Application -resource tools guide -Application -resource tools reference -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-52B2DFDD-063A-5ED4-9A0B-FB3346301482.dita --- a/Symbian3/SDK/Source/GUID-52B2DFDD-063A-5ED4-9A0B-FB3346301482.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -unpageddata

    unpageddata

    Use the unpageddata statement to specify that the data in the executable is not paged. This controls the paging of both heap and stacks for an executable. For more fine-grained control, the paging of heap and stack data can be specified separately during the creation of new threads and processes.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-530AB0D9-BE70-5892-BFBA-213687CA62D1_d0e357398_href.png Binary file Symbian3/SDK/Source/GUID-530AB0D9-BE70-5892-BFBA-213687CA62D1_d0e357398_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-530AB0D9-BE70-5892-BFBA-213687CA62D1_d0e386391_href.png Binary file Symbian3/SDK/Source/GUID-530AB0D9-BE70-5892-BFBA-213687CA62D1_d0e386391_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53313E89-3E23-4004-BD10-771858657DAD_d0e67159_href.png Binary file Symbian3/SDK/Source/GUID-53313E89-3E23-4004-BD10-771858657DAD_d0e67159_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53313E89-3E23-4004-BD10-771858657DAD_d0e67302_href.png Binary file Symbian3/SDK/Source/GUID-53313E89-3E23-4004-BD10-771858657DAD_d0e67302_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-534C1D1A-9450-5A1B-933F-5157039BF069_d0e309152_href.png Binary file Symbian3/SDK/Source/GUID-534C1D1A-9450-5A1B-933F-5157039BF069_d0e309152_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-534C1D1A-9450-5A1B-933F-5157039BF069_d0e315622_href.png Binary file Symbian3/SDK/Source/GUID-534C1D1A-9450-5A1B-933F-5157039BF069_d0e315622_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-535793F2-08F1-5B4E-AD32-783985C53124.dita --- a/Symbian3/SDK/Source/GUID-535793F2-08F1-5B4E-AD32-783985C53124.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -vendorid

    vendorid vendorid

    This keyword specifies the vendor of the executable. For details on how it is possible to use this with platform security.

    In most cases, this VID will be zero, meaning that source of the executable is not required for any security checks.

    The setting is only functional on OS versions based on the EKA2 kernel. For those versions based on EKA1, the keyword is ignored.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5357F135-46B1-5C3F-BD2D-2E71D7BD0046_d0e76204_href.png Binary file Symbian3/SDK/Source/GUID-5357F135-46B1-5C3F-BD2D-2E71D7BD0046_d0e76204_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5357F135-46B1-5C3F-BD2D-2E71D7BD0046_d0e76242_href.png Binary file Symbian3/SDK/Source/GUID-5357F135-46B1-5C3F-BD2D-2E71D7BD0046_d0e76242_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-535954FD-2501-5C80-AD86-AC73A86B18B5.dita --- a/Symbian3/SDK/Source/GUID-535954FD-2501-5C80-AD86-AC73A86B18B5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-535954FD-2501-5C80-AD86-AC73A86B18B5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,4 +26,4 @@ ... aStream >> iB; // internalises Swizzle from stream ... - }

    Here, iId is the stream ID containing CClassABC data.

    \ No newline at end of file + }

    Here, iId is the stream ID containing CClassABC data.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-536B2F20-DB19-595C-A465-25CF2E421050_d0e106915_href.png Binary file Symbian3/SDK/Source/GUID-536B2F20-DB19-595C-A465-25CF2E421050_d0e106915_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-536B2F20-DB19-595C-A465-25CF2E421050_d0e107147_href.png Binary file Symbian3/SDK/Source/GUID-536B2F20-DB19-595C-A465-25CF2E421050_d0e107147_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-536DCEAF-3598-4D3E-A812-E266720F350D.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-536DCEAF-3598-4D3E-A812-E266720F350D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,50 @@ + + + + + +Supported codecs +

    In order to play audio and video, devices need compression/decompression +(codec) software or hardware that performs conversions between different +compressed data types. Software codecs are implemented in software +only, whereas hardware-accelerated codecs use hardware to perform +some of the functions for increased processing speed. For more information, +see Video encoding guidelines.

    +

    The multimedia framework (MMF) is a high level interface +for accessing audio and video functionality. Codecs can be accessed +through MMF or through a lower level audio device driver, DevSound.

    +
    To access codecs +

    Use the following Symbian classes:

    +
      +

    • CMMFDevSound enables audio functions +on the device hardware.

      • +

    • CMdaAudioOutputStream

      and CMdaAudioInputStream provide an +interface for playing raw or encoded audio data.

      • +

    • CMMFCodec decodes and encodes between +different coding types, and provides access to MMF software codecs.

      +
      • +

    • CmdaAudioPlayerUtility plays audio +data.

      • +

    • CmdaAudioRecorderUtility plays, +records, and edits audio data.

      • +

    • CVideoPlayerUtility plays sampled +video data.

      • +
    +

    For more information, see:

    +
      +

    • eLearning module on Multimedia Framework

      • +

    • Symbian OS Multimedia Framework and Other Multimedia APIs

      • +

    • Media Device Framework Overview

      • +

    • Supported Audio Codecs

      • +

    • Audio Client Overview

      • +

    • Video Client Overview

      • +

    • Video HAI Overview

      • +
    +
    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53707903-9A88-409B-80F8-FDF7EF47ACBF.dita --- a/Symbian3/SDK/Source/GUID-53707903-9A88-409B-80F8-FDF7EF47ACBF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-53707903-9A88-409B-80F8-FDF7EF47ACBF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,9 +12,9 @@ CoverFlow: using ScreenPlayThis example application demonstrates creating semi-transparent UI content over OpenVG content that is rendered to a composition surface. This is only possible when ScreenPlay is enabled. -
    Download

    Click on the following link to download the example: GraphicsShell.zip

    Click: browse to view the example code.

    The example +

    Download

    Click on the following link to download the example: GraphicsShell.zip

    Click: browse to view the example code.

    The example is located in the examples\Graphics\CoverFlow directory.

    -
    Description This code implements a 'coverflow' application. It uses OpenVG to +
    Description This code implements a 'coverflow' application. It uses OpenVG to display images while semi-transparent or transparent windows and controls are used to display overlaid content. The application does the following:
      @@ -32,15 +32,15 @@ takes multiple overlaid surfaces as input and creates a single screen buffer. For more information, see Graphics Composition and The ScreenPlay Graphics Architecture.
    -
    Screenshots +
    Screenshots Basic Screenshot - + Screenshot showing ticker and incoming call animation - + Screenshot showing the absence of the mirror surface - +
    Class Summary

    These are the principal classes used in this example:

      @@ -53,18 +53,18 @@
    • CLoader

    Design -and Implementation

    +and Implementation

    UML class diagram - +

    -
    Building -and running

    The Symbian build -process describes how to build an application.

    +
    Building +and running

    The Symbian build process describes how to +build an application.

    Configuration settings for running the example on an Emulator or H4 board
      -

    1. Change the WINDOWMODE parameter to Color16MAP in epoc32\release\winscw\<udeb/urel>\z\system\data\wsini.ini (epoc32\data\z\system\data\wsini.ini on the H4 board).

      2. -

    2. The application +

    3. Change the WINDOWMODE parameter to Color16MAP in epoc32\release\winscw\<udeb/urel>\z\system\data\wsini.ini (epoc32\data\z\system\data\wsini.ini on the H4 board).

      4. +

    4. The application cannot run if ScreenPlay is disabled. If it is not already enabled, you need to enable it. See Enabling the Graphics Architecture Variants for more information.

      5. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5398C2DC-9AFA-5517-BCBF-5964970B9656_d0e230704_href.png Binary file Symbian3/SDK/Source/GUID-5398C2DC-9AFA-5517-BCBF-5964970B9656_d0e230704_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5398C2DC-9AFA-5517-BCBF-5964970B9656_d0e235684_href.png Binary file Symbian3/SDK/Source/GUID-5398C2DC-9AFA-5517-BCBF-5964970B9656_d0e235684_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53A2CA11-2ABF-5ED7-A26C-7BE9FD9A1D22_d0e281197_href.png Binary file Symbian3/SDK/Source/GUID-53A2CA11-2ABF-5ED7-A26C-7BE9FD9A1D22_d0e281197_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53A2CA11-2ABF-5ED7-A26C-7BE9FD9A1D22_d0e286036_href.png Binary file Symbian3/SDK/Source/GUID-53A2CA11-2ABF-5ED7-A26C-7BE9FD9A1D22_d0e286036_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53A5AC8D-8A43-505F-A0B6-9E34F3CF23BE.dita --- a/Symbian3/SDK/Source/GUID-53A5AC8D-8A43-505F-A0B6-9E34F3CF23BE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-53A5AC8D-8A43-505F-A0B6-9E34F3CF23BE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Playing AudioThis tutorial describes you how to start playing, pausing and resuming, stopping, retrieving the number of samples in the audio data.

      Before you start, you must:

      • Understand the A3F DevSound Component to which the DevSound library belongs.

      • Understand the architectural relationship of the DevSound. For information see DevSound Overview.

      You can perform various functionality in DevSound audio playing that are listed in the below section.

      Starting Audio Play Pausing and Resuming Audio Play Stopping Audio Play Retrieving Audio Play Samples       Recording Audio Playing Tones       \ No newline at end of file +Playing AudioThis tutorial describes you how to start playing, pausing and resuming, stopping, retrieving the number of samples in the audio data.

      Before you start, you must:

      • Understand the A3F DevSound Component to which the DevSound library belongs.

      • Understand the architectural relationship of the DevSound. For information see DevSound Overview.

      You can perform various functionality in DevSound audio playing that are listed in the below section.

      Starting Audio Play Pausing and Resuming Audio Play Stopping Audio Play Retrieving Audio Play Samples       Recording Audio Playing Tones       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-53C71C87-BFD9-4C9A-8A90-6735494F300C.dita --- a/Symbian3/SDK/Source/GUID-53C71C87-BFD9-4C9A-8A90-6735494F300C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-53C71C87-BFD9-4C9A-8A90-6735494F300C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ View state.

      Form in the Edit state - +

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-541C8505-335F-5C93-8C0E-96BCEE39D1E6_d0e228979_href.png Binary file Symbian3/SDK/Source/GUID-541C8505-335F-5C93-8C0E-96BCEE39D1E6_d0e228979_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-541C8505-335F-5C93-8C0E-96BCEE39D1E6_d0e233964_href.png Binary file Symbian3/SDK/Source/GUID-541C8505-335F-5C93-8C0E-96BCEE39D1E6_d0e233964_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-54401E25-31F5-58E8-AE8A-276DE5E9C072_d0e164369_href.jpg Binary file Symbian3/SDK/Source/GUID-54401E25-31F5-58E8-AE8A-276DE5E9C072_d0e164369_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-54401E25-31F5-58E8-AE8A-276DE5E9C072_d0e169383_href.jpg Binary file Symbian3/SDK/Source/GUID-54401E25-31F5-58E8-AE8A-276DE5E9C072_d0e169383_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5486EFD3-4660-4C19-A007-286DE48F6EEF.dita --- a/Symbian3/SDK/Source/GUID-5486EFD3-4660-4C19-A007-286DE48F6EEF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5486EFD3-4660-4C19-A007-286DE48F6EEF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ vertically.

      Essential information or features, such as a label, instructions, or sub-controls should never be placed below an interface element that can be touched, as it may be hidden by the user's finger.

      - + Following are some useful tips that can be used while placing essential information or features on interface element:

      • With interfaces having input devices, it makes sense to place targets diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-54E62386-E4DB-55C3-BA9A-FFB7BFE6703E.dita --- a/Symbian3/SDK/Source/GUID-54E62386-E4DB-55C3-BA9A-FFB7BFE6703E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-54E62386-E4DB-55C3-BA9A-FFB7BFE6703E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,128 +1,131 @@ - - - - - -File -locationsThis topic gives the location for different file types. -

        Pre-Symbian platform v9.0

        Application program files -must be located in directories with the form \system\apps\<program>\. -Initialisation and configuration files should be in the same directory, or -where the application is in ROM, in the equivalent directory on a writable -drive.

        Document files can be located in any directory except \system\, -and may be given any name: the system will not alter the capitalisation of -that name, and will not attempt to add or remove any extension.

        The -application architecture does not dictate the requirements for all files, -or even all file stores. For instance, an e-mail application is not document -based. An e-mail subsystem would store its messages in a directory structure -using special e-mail policies to implement inbox, outbox and folders. Normally, -this folder would be in a \system\ directory.

        -
        Symbian platform -v9.0 and beyond

        The following table gives the location for different -file types.

        - - - -Location -Example file types -Description - - - - -
          -

        • On the emulator (default):

            -

          • epoc32\release\winscw\udeb\

            • -

          • epoc32\release\winscw\urel\

            • -

          On the emulator, e.g. for text notifiers:

            -

          • \sys\bin\tnotifiers

            • -
          • -

        • On the device:

          \sys\bin\

          • -
         -

        .exe, .app,

        .dll, .ani,

        .ctl, .fep,

        .mdl, .csy,

        .ldd, .pdd,

        .prt,

        .ECOMIIC, .PLUGIN

        -
          -

        • Location of all binaries

          • -

        • The OS will refuse to -load any binary not in \sys\bin\

          • -

        • Code without AllFiles (or TCB) -capability will never be able to read (or write) anything under \sys\

          • -

        • Note that for the emulator -when PlatSecEnforceSysBin is enabled (in the epoc.ini file) -executables found under \system will not be able to be -loaded

          • -
         -         - -

        \private\<process SID>\

        -

        .doc, .txt,

        .xml, .dat,

        .ini, .mbm,

        .rsc

        -
          -

        • Location of all private -data files (e.g. if the file is to be accessed only by the application itself)

          • -

        • The directory name under \private is -determined by the SecureId (SID) of the process. If a SID is not specified, -the UID3 provided in the mmp file is used

          • -

        • Under the \private directory, -programs without the AllFiles capability will only ever be -able to see their own directory

          • -
         -         - -
          -

        • Applications on the -emulator, or built into the ROM must provide registration files in:

            -

          • \private\10003a3f\apps\

            • -
          • -

        • Applications installed -via Software Install must provide registration files in:

            -

          • \private\10003a3f\import\apps\

            • -
          • -
         -

        <appname>_reg.rsc

        -
          -

        • The private system directory -for an application's registration file

          • -

        • The directory must always -be on the same drive as the application

          • -

        • These paths are true -for both the emulator and target device

          • -
         -         - -

        \resource\apps\

        -

        .rsc, .mbm

        -
          -

        • Read access is allowed -by all

          • -

        • Write access only by -processes with AllFiles capability

          • -
         -         - -

        \resource\plugins\

        -

        <dllname>.rsc

        -
          -

        • Specifically for ECom -registration resource files for ECom plugins

          • -

        • Read access is allowed -by all

          • -
         -         - -

        Central Repository API

        \private\<process sid>\

        -

        .txt

        -
          -

        • If the file is read/write-only, -and access to it needs controlling through capabilities, then use the Central -Repository API, not a file at all.

          • -
         -         - - -
        + + + + + +File locationsThis topic gives the location for different file types. +
        Pre-Symbian +OS v9.0

        Application program files must be located in directories +with the form \system\apps\<program>\. Initialisation +and configuration files should be in the same directory, or where +the application is in ROM, in the equivalent directory on a writable +drive.

        Document files can be located in any directory except \system\, and may be given any name: the system +will not alter the capitalisation of that name, and will not attempt +to add or remove any extension.

        The application architecture +does not dictate the requirements for all files, or even all +file stores. For instance, an e-mail application is not document based. +An e-mail subsystem would store its messages in a directory structure +using special e-mail policies to implement inbox, outbox and folders. +Normally, this folder would be in a \system\ directory.

        +
        Symbian +OS v9.0 and beyond

        The following table gives the location +for different file types.

        + + + + +Location +Example file types +Description + + + + +
          +

        • On the emulator +(default):

            +

          • epoc32\release\winscw\udeb\

            • +

          • epoc32\release\winscw\urel\

            • +

          On the emulator, e.g. for text notifiers:

            +

          • \sys\bin\tnotifiers

            • +
          • +

        • On the device:

          \sys\bin\

          • +
         +

        .exe, .app,

        .dll, .ani,

        .ctl, .fep,

        .mdl, .csy,

        .ldd, .pdd,

        .prt,

        .ECOMIIC, .PLUGIN

        +
          +

        • Location of +all binaries

          • +

        • The OS will +refuse to load any binary not in \sys\bin\

          • +

        • Code without AllFiles (or TCB) capability will never +be able to read (or write) anything under \sys\

          • +

        • Note that for +the emulator when PlatSecEnforceSysBin is enabled +(in the epoc.ini file) executables found under \system will not be able to be loaded

          • +
         +         + +

        \private\<process SID>\

        +

        .doc, .txt,

        .xml, .dat,

        .ini, .mbm,

        .rsc

        +
          +

        • Location of +all private data files (e.g. if the file is to be accessed only by +the application itself)

          • +

        • The directory +name under \private is determined by the SecureId +(SID) of the process. If a SID is not specified, the UID3 provided in the mmp file is used

          • +

        • Under the \private directory, programs without the AllFiles capability will only ever be able to see their own directory

          • +
         +         + +
          +

        • Applications +on the emulator, or built into the ROM must provide registration files +in:

            +

          • \private\10003a3f\apps\

            • +
          • +

        • Applications +installed via Software Install must provide registration files in:

            +

          • \private\10003a3f\import\apps\

            • +
          • +
         +

        <appname>_reg.rsc

        +
          +

        • The private +system directory for an application's registration file

          • +

        • The directory +must always be on the same drive as the application

          • +

        • These paths +are true for both the emulator and target device

          • +
         +         + +

        \resource\apps\

        +

        .rsc, .mbm

        +
          +

        • Read access +is allowed by all

          • +

        • Write access +only by processes with AllFiles capability

          • +
         +         + +

        \resource\plugins\

        +

        <dllname>.rsc

        +
          +

        • Specifically +for ECom registration resource files for ECom plugins

          • +

        • Read access +is allowed by all

          • +
         +         + +

        Central Repository API

        \private\<process +sid>\

        +

        .txt

        +
          +

        • If the file +is read/write-only, and access to it needs controlling through capabilities, +then use the Central Repository API, not a file at all.

          • +
         +         + + +
         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-54EB6658-D2C1-514B-B9F1-BAB541A2972D.dita --- a/Symbian3/SDK/Source/GUID-54EB6658-D2C1-514B-B9F1-BAB541A2972D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-54EB6658-D2C1-514B-B9F1-BAB541A2972D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Bitmap Devices and Contexts

        The BitGDI API provides extensions for bitmap devices of the abstract drawing device and context interfaces defined in the GDI API. The key interfaces defined by it, used for drawing on the screen, are in fact abstract. The Window Server provides concrete classes for on-screen drawing which derive from these interfaces. The concrete device and context classes that the API does provide are normally only used by applications to draw to in-memory bitmaps.

        Bitmap graphics context

        CBitmapContext specializes a GDI context (CGraphicsContext) for bitmap graphics. It provides extra functionality for:

        • clearing and copying rectangular areas

        • bitmap block transfer

        • setting pen color to a grey level

        • setting the shadow mode

        • resetting the GC settings to their default values

        The Window Server client-side API provides one implementation, CWindowGc, used for screen drawing. Another implementation, CFbsBitGc, is used for drawing to in-memory bitmaps.

        Bitmap graphics device

        CBitmapDevice specializes a graphics device (CGraphicsDevice) for bitmap graphics.

        The Window Server client-side API provides one implementation, CWsScreenDevice, for screen drawing. Another implementation, CFbsBitmapDevice, is used for drawing to in-memory bitmaps. A third, CFbsScreenDevice, is used (rarely) to access the screen directly, without the mediation of the window server.

        Screen driver information

        The screen width and height must be a multiple of four. In certain cases where the screen mode would result in a scanline (the scanline runs in the current horizontal direction of the screen) not being divisible by a whole word (32 bits) the screen width must also be a multiple of 16. This restriction will also apply to the height if there is a screen-size mode with a rotation of 90 or 270 (or both)

        For example, the screen mode EGray4 is 2 bits per pixel, therefore one word would be 16 pixels, so in order for the scanline to be a whole number of words the width must be a multiple of 16.

        The vertical height is unrestricted unless there is at least one screen-size mode with a rotation of 90 or 270 (or both).

        Bitmaps BitGDI Component         \ No newline at end of file +Bitmap Devices and Contexts

        The BitGDI API provides extensions for bitmap devices of the abstract drawing device and context interfaces defined in the GDI API. The key interfaces defined by it, used for drawing on the screen, are in fact abstract. The Window Server provides concrete classes for on-screen drawing which derive from these interfaces. The concrete device and context classes that the API does provide are normally only used by applications to draw to in-memory bitmaps.

        Bitmap graphics context

        CBitmapContext specializes a GDI context (CGraphicsContext) for bitmap graphics. It provides extra functionality for:

        • clearing and copying rectangular areas

        • bitmap block transfer

        • setting pen color to a grey level

        • setting the shadow mode

        • resetting the GC settings to their default values

        The Window Server client-side API provides one implementation, CWindowGc, used for screen drawing. Another implementation, CFbsBitGc, is used for drawing to in-memory bitmaps.

        Bitmap graphics device

        CBitmapDevice specializes a graphics device (CGraphicsDevice) for bitmap graphics.

        The Window Server client-side API provides one implementation, CWsScreenDevice, for screen drawing. Another implementation, CFbsBitmapDevice, is used for drawing to in-memory bitmaps. A third, CFbsScreenDevice, is used (rarely) to access the screen directly, without the mediation of the window server.

        Screen driver information

        The screen width and height must be a multiple of four. In certain cases where the screen mode would result in a scanline (the scanline runs in the current horizontal direction of the screen) not being divisible by a whole word (32 bits) the screen width must also be a multiple of 16. This restriction will also apply to the height if there is a screen-size mode with a rotation of 90 or 270 (or both)

        For example, the screen mode EGray4 is 2 bits per pixel, therefore one word would be 16 pixels, so in order for the scanline to be a whole number of words the width must be a multiple of 16.

        The vertical height is unrestricted unless there is at least one screen-size mode with a rotation of 90 or 270 (or both).

        Bitmaps BitGDI Component         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5503ACC5-1C78-5EF6-AAD2-4B6FFA8890B9_d0e191959_href.png Binary file Symbian3/SDK/Source/GUID-5503ACC5-1C78-5EF6-AAD2-4B6FFA8890B9_d0e191959_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5503ACC5-1C78-5EF6-AAD2-4B6FFA8890B9_d0e196933_href.png Binary file Symbian3/SDK/Source/GUID-5503ACC5-1C78-5EF6-AAD2-4B6FFA8890B9_d0e196933_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5512B80D-77E8-5DFB-BD97-EBC1C4360E90.dita --- a/Symbian3/SDK/Source/GUID-5512B80D-77E8-5DFB-BD97-EBC1C4360E90.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -pageddata

        pageddata

        Use the pageddata statement to specify that the data in the executable is paged. This controls the paging of both heap and stacks for an executable. For more fine-grained control, the paging of heap and stack data can be specified separately during the creation of new threads and processes.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-55754EF4-EC25-5CE3-9B38-79F278BCF19F_d0e336970_href.png Binary file Symbian3/SDK/Source/GUID-55754EF4-EC25-5CE3-9B38-79F278BCF19F_d0e336970_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-55754EF4-EC25-5CE3-9B38-79F278BCF19F_d0e343436_href.png Binary file Symbian3/SDK/Source/GUID-55754EF4-EC25-5CE3-9B38-79F278BCF19F_d0e343436_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5598B53F-2A6D-5813-913C-94B2AB36134E_d0e75841_href.png Binary file Symbian3/SDK/Source/GUID-5598B53F-2A6D-5813-913C-94B2AB36134E_d0e75841_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5598B53F-2A6D-5813-913C-94B2AB36134E_d0e75879_href.png Binary file Symbian3/SDK/Source/GUID-5598B53F-2A6D-5813-913C-94B2AB36134E_d0e75879_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-55E4D84B-1B90-5BA4-9CE0-6D26EA208F13.dita --- a/Symbian3/SDK/Source/GUID-55E4D84B-1B90-5BA4-9CE0-6D26EA208F13.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-55E4D84B-1B90-5BA4-9CE0-6D26EA208F13.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,8 +11,8 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> OverviewThis topic describes memory management in the Communications Framework.
        Introduction

        The Communications Framework preallocates memory area buffers to increase the performance of its Data Plane. When a Comms Data Plane component needs a buffer, it asks for one from its pond. The pond contains pools of buffers : each pool contains buffers of a different size, and all the buffers in a pool have the same size. If the pond doesn't have a big enough buffer, it will string together a chain of smaller buffers to meet the request.

        The Communications Framework uses shared buffers. The Data Plane has strong performance requirements, and using shared buffers helps to avoid the memory copy that occurs between the kernel memory context and the Communications stack.

        Definitions
        Comms buffer (MBuf)

        A Comms buffer, or MBuf, is a contiguous memory area used to store data on the Data Plane. It is represented by an RMBuf object, which combines a shared buffer with metadata. See Shared buffers and Comms Buffers (MBuf) and Comms Chains.

        Comms buffer -
        Comms buffer chain

        A Comms buffer chain links together one or more Comms buffers. This decreases memory consumption because there is no need to reserve space for temporary large buffers, which can be created from a chain of smaller buffers. The chain is represented by a RMBufChain object. For more information, see Comms Buffers (MBuf) and Comms Chains.

        Pool

        Pre-allocated collection of shared buffers. See Shared buffers.

        The buffers of a pool all have the same size. Depending on the amount of used buffers, the pool dynamically grows and shrinks by a set number of buffers, which reduces the frequency of expensive memory allocation and reduces memory usage when possible.

        Pond

        The pond is a collection of pools. It is an RCommsBufPond object which keeps track of the memory available in the pools and allocates all the Comms buffer chains by taking buffers from the appropriate pools.

        The memory provided by the pond is available to all the layers of the Comms Framework as well as to the drivers underneath the lower layer. Therefore, the Comms Framework components and the drivers can exchange data without additional memory copies.

        At the moment, there is only one pond in the Comms Framework.

        For more information, see Advanced Pond Guide.

        +
        Comms buffer chain

        A Comms buffer chain links together one or more Comms buffers. This decreases memory consumption because there is no need to reserve space for temporary large buffers, which can be created from a chain of smaller buffers. The chain is represented by a RMBufChain object. For more information, see Comms Buffers (MBuf) and Comms Chains.

        Pool

        Pre-allocated collection of shared buffers. See Shared buffers.

        The buffers of a pool all have the same size. Depending on the amount of used buffers, the pool dynamically grows and shrinks by a set number of buffers, which reduces the frequency of expensive memory allocation and reduces memory usage when possible.

        Pond

        The pond is a collection of pools. It is an RCommsBufPond object which keeps track of the memory available in the pools and allocates all the Comms buffer chains by taking buffers from the appropriate pools.

        The memory provided by the pond is available to all the layers of the Comms Framework as well as to the drivers underneath the lower layer. Therefore, the Comms Framework components and the drivers can exchange data without additional memory copies.

        At the moment, there is only one pond in the Comms Framework.

        For more information, see Advanced Pond Guide.

        Pond contents -
        Typical usage

        Depending on where your component is in the Data Plane, you handle Comms buffers in a different way:

        • Protocol plugins manipulate the data plane flow represented by buffer chains. They obtain a buffer chain from another layer (up or down), process the chain, and send the chain to the next layer in the stack. Link layer components belong to that category.

          See Data Access Example.

        • Data source components, either at the top or at the bottom of the Comms Framework, create buffer chains and send them through the Data Plane. Device drivers belong to that category.

          See Allocation Tutorial and TLS Look-up Reduction Tutorial.

        In order to increase performance and decrease memory consumption with Comms buffers, you need to configure the pond according to your memory usage. For more information, see Advanced Pond Guide and Pond Configuration Reference.

        To monitor the pond and its available memory, see Memory Metrics.

        Shared Buffers Comms Buffers (MBuf) +
    Typical usage

    Depending on where your component is in the Data Plane, you handle Comms buffers in a different way:

    • Protocol plugins manipulate the data plane flow represented by buffer chains. They obtain a buffer chain from another layer (up or down), process the chain, and send the chain to the next layer in the stack. Link layer components belong to that category.

      See Data Access Example.

    • Data source components, either at the top or at the bottom of the Comms Framework, create buffer chains and send them through the Data Plane. Device drivers belong to that category.

      See Allocation Tutorial and TLS Look-up Reduction Tutorial.

    In order to increase performance and decrease memory consumption with Comms buffers, you need to configure the pond according to your memory usage. For more information, see Advanced Pond Guide and Pond Configuration Reference.

    To monitor the pond and its available memory, see Memory Metrics.

    Shared Buffers Comms Buffers (MBuf) and Comms Chains Advanced Pond Guide \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-565074B2-53E2-54CD-A06B-7E044E66EBE8.dita --- a/Symbian3/SDK/Source/GUID-565074B2-53E2-54CD-A06B-7E044E66EBE8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -sourcepath

    sourcepath directory

    Use the sourcepath statement to define the location of the project and its workfiles.

    Either relative or full paths can be specified with the keyword. Relative paths are considered relative to the directory containing the .mmp file. Full paths are considered relative to the location defined by the EPOCROOT variable.

    Multiple sourcepath statements may be specified, but note that the build tools will expect subsequent source and resource file statements to relate to the last previous sourcepath statement.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5673347B-DA7B-563A-AB2B-615BF7C19F92_d0e324956_href.png Binary file Symbian3/SDK/Source/GUID-5673347B-DA7B-563A-AB2B-615BF7C19F92_d0e324956_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5673347B-DA7B-563A-AB2B-615BF7C19F92_d0e331426_href.png Binary file Symbian3/SDK/Source/GUID-5673347B-DA7B-563A-AB2B-615BF7C19F92_d0e331426_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-567718E7-0267-4641-A9E3-538D893362D2.dita --- a/Symbian3/SDK/Source/GUID-567718E7-0267-4641-A9E3-538D893362D2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-567718E7-0267-4641-A9E3-538D893362D2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,9 +23,9 @@ framework will handle the remaining tasks. An example of Item-specific options menu within stylus pop-up menu. - + -Default touch +<table id="GUID-5B8DA500-4092-4E1A-A035-308C4D352138-GENID-1-10-1-7-1-1-5-1-11-1-1-3-1-2-4"><title>Default touch events for Item-specific options menu. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-567D36A2-1097-5D44-B1B2-896F0F812A32.dita --- a/Symbian3/SDK/Source/GUID-567D36A2-1097-5D44-B1B2-896F0F812A32.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -linkas

    linkas priority

    Use the linkas statement to give the DLL that your project defines a different internal name.

    By default, the internal name of the DLL will be the same as the DLL’s filename. Under certain rare circumstances, it is useful to be able to give a DLL a different internal name.

    For example, a DLL might be built with a certain name and then renamed as part of a ROM, so the internal name must be the same as the DLL’s name in ROM.

    Use of this statement will have no effect under Win32 platforms.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5696BEC1-51F5-5062-A4E6-C6CF48C7C95A_d0e132911_href.png Binary file Symbian3/SDK/Source/GUID-5696BEC1-51F5-5062-A4E6-C6CF48C7C95A_d0e132911_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5696BEC1-51F5-5062-A4E6-C6CF48C7C95A_d0e136515_href.png Binary file Symbian3/SDK/Source/GUID-5696BEC1-51F5-5062-A4E6-C6CF48C7C95A_d0e136515_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-56DF9711-1EFA-5A07-A92B-3F3D6FBD17A8.dita --- a/Symbian3/SDK/Source/GUID-56DF9711-1EFA-5A07-A92B-3F3D6FBD17A8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-56DF9711-1EFA-5A07-A92B-3F3D6FBD17A8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,8 +11,8 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Sockets Server Client API

    This topic introduces the Sockets Server API and discusses the main classes.

    The Sockets Server Client interfaces make asynchronous calls to the Sockets Server. The Server co-ordinates client access to socket services, and manages communications with the protocol plug-ins that provide support for the particular networking protocols.

    Each protocol plug-in may contain a number of protocols. The term ‘protocol’ may also be used to describe a suite of protocols. For example, the TCP/IP protocol plug-in contains UDP, TCP, ICMP, IP, and DNS. Sockets can access UDP and TCP to transfer data over IP. Another example of a protocol plug-in is the IrDA plug-in. the IrDA plug-in is used for communicating over infrared.

    The Sockets Server loads protocols plug-ins at runtime either explicitly or on demand. When the server starts, the server scans \private\101f7989\esock for .esk files to see which protocols and services are defined, and which protocols to load.

    The Sockets Server Client API implements the idea of transport independence: different protocols are accessed through the same API. However, individual protocols exhibit different properties and semantics regarding socket behaviour. The semantics implemented by any given protocol can be found by interrogating the system using RSocketServ::GetProtocolInfo(), which describes the protocol semantics encapsulated in a TProtocolDesc.

    APIs

    Five main classes provide the Sockets Server Client API functionality:

    • RSocketServ

    • RSocket

    • RHostResolver

    • RConnection

    • RSubConnection

    The RSocketServ class establishes and reserves resources for the base communication session to the Sockets Server. The RSocketServ hosts other Sockets Server Client APIs as subsessions inside the RSocketServ session. The Sockets Server Client APIs which are hosted as subsessions inside RSocketServ are RSocket, RHostResolver, RConnection and RSubConnection. The RSocketServ class provides functions to load and query protocols.

    Figure 1 - Class diagram of RSocketServ inheritance - + Figure 2 - Class diagram of classes which make up the subsession APIs to RSocketServ -

    The RSocket class provides a client endpoint to a protocol. It provides the following services:

    • socket creation

    • reading from and writing to a protocol

    • binding to addresses

    • active connecting

    • passive connection through the listen/accept model

    The RConnection class provides access to the Connection Management functionality of a socket. See Connection Management.

    The RSubConnection API provides functions to specify Quality of Service parameters for a channel. See SubConnection Client API.

    ESK Files Reading from a Socket: +

    The RSocket class provides a client endpoint to a protocol. It provides the following services:

    • socket creation

    • reading from and writing to a protocol

    • binding to addresses

    • active connecting

    • passive connection through the listen/accept model

    The RConnection class provides access to the Connection Management functionality of a socket. See Connection Management.

    The RSubConnection API provides functions to specify Quality of Service parameters for a channel. See SubConnection Client API.

    ESK Files Reading from a Socket: Tutorial     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-56E67157-08EE-414A-9EC5-ADAF27E0D36A_d0e63781_href.png Binary file Symbian3/SDK/Source/GUID-56E67157-08EE-414A-9EC5-ADAF27E0D36A_d0e63781_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-56E67157-08EE-414A-9EC5-ADAF27E0D36A_d0e63924_href.png Binary file Symbian3/SDK/Source/GUID-56E67157-08EE-414A-9EC5-ADAF27E0D36A_d0e63924_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5746BC4A-E8D2-51DE-B101-4BA68F0E1769_d0e148577_href.png Binary file Symbian3/SDK/Source/GUID-5746BC4A-E8D2-51DE-B101-4BA68F0E1769_d0e148577_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5746BC4A-E8D2-51DE-B101-4BA68F0E1769_d0e153659_href.png Binary file Symbian3/SDK/Source/GUID-5746BC4A-E8D2-51DE-B101-4BA68F0E1769_d0e153659_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-575CDD9C-ED6E-510E-AE11-46CA7EB7B74C_d0e132621_href.png Binary file Symbian3/SDK/Source/GUID-575CDD9C-ED6E-510E-AE11-46CA7EB7B74C_d0e132621_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-575CDD9C-ED6E-510E-AE11-46CA7EB7B74C_d0e136225_href.png Binary file Symbian3/SDK/Source/GUID-575CDD9C-ED6E-510E-AE11-46CA7EB7B74C_d0e136225_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57B7DA8C-A62F-4C65-B754-47D9F5E76416.dita --- a/Symbian3/SDK/Source/GUID-57B7DA8C-A62F-4C65-B754-47D9F5E76416.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-57B7DA8C-A62F-4C65-B754-47D9F5E76416.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,11 +31,11 @@ something.

    Virtual ITU-T keypad - + Virtual QWERTY keyboard - +

    The virtual QWERTY keyboard displays a keyboard that has a collection of basic keyboard functions (Shift, Caps lock, punctuation marks, and so on) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57C10E91-F0CD-494E-96CE-92FB1E06CB53_d0e292667_href.png Binary file Symbian3/SDK/Source/GUID-57C10E91-F0CD-494E-96CE-92FB1E06CB53_d0e292667_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57C10E91-F0CD-494E-96CE-92FB1E06CB53_d0e299139_href.png Binary file Symbian3/SDK/Source/GUID-57C10E91-F0CD-494E-96CE-92FB1E06CB53_d0e299139_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57CC6419-2800-4E54-8DF6-36EC2617D2FD_d0e4506_href.png Binary file Symbian3/SDK/Source/GUID-57CC6419-2800-4E54-8DF6-36EC2617D2FD_d0e4506_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57CC6419-2800-4E54-8DF6-36EC2617D2FD_d0e4633_href.png Binary file Symbian3/SDK/Source/GUID-57CC6419-2800-4E54-8DF6-36EC2617D2FD_d0e4633_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-57F38146-1DA3-5657-ADF4-76DF740363C5.dita --- a/Symbian3/SDK/Source/GUID-57F38146-1DA3-5657-ADF4-76DF740363C5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-57F38146-1DA3-5657-ADF4-76DF740363C5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Static Startup Configuration

    The System Starter is invoked by the Base Starter as part of the boot process once the file system has been mounted. It works by processing a list of instructions in sequence. The list is referred to as a Static Startup Configuration, or SSC. In practical terms the SSC is defined in a resource file and is built into the ROM.

    A fundamental feature of the SSC is that it allows the start up procedure to be optimised. Though the commands are processed in sequence their effect is to perform tasks not only in sequence (wait for the application or process to initialise before continuing) but also in parallel (do not wait for initialisation) and at the optimum time (wait until conditions are right).

    In the diagram above each vertical bar represents a process or application started during the startup procedure. The list on the left shows the SSC command for each process. An application may ‘rendezvous’ with the starter when its initialisation (shown in dark blue) is complete and it is ready to be used by dependent applications. A rendezvous is simply a signal from the appliation to the starter that it has reached a designated point.

    \ No newline at end of file +Static Startup Configuration

    The System Starter is invoked by the Base Starter as part of the boot process once the file system has been mounted. It works by processing a list of instructions in sequence. The list is referred to as a Static Startup Configuration, or SSC. In practical terms the SSC is defined in a resource file and is built into the ROM.

    A fundamental feature of the SSC is that it allows the start up procedure to be optimised. Though the commands are processed in sequence their effect is to perform tasks not only in sequence (wait for the application or process to initialise before continuing) but also in parallel (do not wait for initialisation) and at the optimum time (wait until conditions are right).

    In the diagram above each vertical bar represents a process or application started during the startup procedure. The list on the left shows the SSC command for each process. An application may ‘rendezvous’ with the starter when its initialisation (shown in dark blue) is complete and it is ready to be used by dependent applications. A rendezvous is simply a signal from the appliation to the starter that it has reached a designated point.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-581A8E4B-12BE-41C0-A20E-3087A80FEECF.dita --- a/Symbian3/SDK/Source/GUID-581A8E4B-12BE-41C0-A20E-3087A80FEECF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-581A8E4B-12BE-41C0-A20E-3087A80FEECF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,286 +1,264 @@ - - - - -Tactile feedback - - - - -

    There are two cases where vibration or audio of the device is used -as an output method:

    -
      -

    • As a tacticon to inform users through physical feedback, -that an important event is occurring in the device. For example, when -a new message arrives or a warning note is displayed.

      • -

    • As tactile feedback to indicate to the user that an -interaction event has been made. For example, users receive tactile -feedback when they press a button on the touch screen.

      • -
    -

    As with sounds, tactile feedback must be used carefully so as not -to desensitize the user to the vibration; the attention grabbing quality -remains and functions so long as the feedback is not too frequent.

    -

    Tactile feedback is enabled for all the Symbian platform UI components. -Tactile feedback can be disabled for the common UI components in an -application. However, this is acceptable only if tactile feedback -causes interference with other device functions.

    -

    The user can choose the level of tactile feedback and turn tacticons -ON and OFF.

    -

    The following table lists the tactile feedback effects:

    -

    -Tactile feedback effects - - - -

    Effects

     -

    Description

     -     - - - -

    Sensitive button

     -

    Provides single pulse effect on repeated key presses with -buttons. It is also possible with other similar components.

     -     - -

    Basic button

     -

    Provides stronger single pulse effect to buttons. It is -also possible with other similar components.

     -     - -

    Sensitive list

     -

    Provides single pulse effect to lists and grids. Effect -is used with move (drag and flick) when new item appears on the screen.

     -     - -

    Basic list

     -

    Provides stronger single pulse effect to lists and grids. -Effect is used with touch down and release when tap makes an action.

    In hierarchical list, collapsing/expanding item provides basic -list effect with touch down and release.

     -     - -

    Bounce effect

     -

    Provides pulse effect when list returns to its normal state -after boundary effect.

     -     - -

    Sensitive slider

     -

    Provides pulse effect with scrollbar and slider thumbs. -Effect is provided with touch down and release in thumb area.

     -     - -

    Smooth slider

     -

    Provides continuous smooth feedback when dragging scrollbar -or slider thumb. This can also be increasing or decreasing depending -of the slider type.

     -     - -

    Hold slider

     -

    Provides sensitive pulse effect when touch down and hold -on the slider or scrollbar area. Slider thumb starts moving step by -step towards the touch point. Every step gives one sensitive pulse. -If slider thumb moves directly to the touch point, then basic slider -effect is provided.

     -     - -

    Pop-up

     -

    Provides sensitive pulse effect when pop-up is opened or -closed. If the theme animations are ON, then pop-up effect is used -with opening event after increasing long touch effect. In this scenario, -there is no pop-up effect . All pop-ups do not have theme animation.

     -     - -

    Pop-up close

     -

    Provides decreasing smooth feedback a pop-up and when theme -animations are ON.

     -     - -

    Increasing long touch

     -

    Provides increasing smooth feedback. This can be used with -either long tap animation or pop-up opening theme effects. If the -theme effects are ON and long tap opens a pop-up, then feedback is -provided only with long tap. This is followed by pop-up.

     -     - -

    Basic tab

     -

    Provides strong pulse effect with touch down event in tab -area.

     -     - -

    Smooth flick

     -

    Provides smooth feedback with drag when horizontal movement -is possible.

     -     - -

    Sensitive flick

     -

    Provides sensitive pulse effect with touch release when -horizontal movement is possible.

     -     - -

    Sensitive edit

     -

    Provides sensitive pulse effect in editors with touch down -and release.

     -     - -

    Text edit

     -

    Provides pulse effect when painting the text. Effect is -provided with every character while painting the text.

     -     - -

    Blank edit

     -

    Provides pulse effect when painting blank character. By -default, it is none.

     -     - -

    Line edit

     -

    Provides pulse effect when painting a line.

     -     - -

    Empty line

     -

    Provides pulse effect when painting an empty line. By default, -it is none.

     -     - -

    Check box

     -

    Provides pulse effect when marking/unmarking a check box.

     -     - -

    Multiple touch recognition

     -

    Provides double pulse (sensitive + sensitive) effect when -multiple touch is recognized (generally, when second finger is touched -down).

     -     - -

    Smooth pinch

     -

    Provides smooth continuous feedback while moving fingers -in multiple touch pinch situation.

     -     - -

    Smooth rotate

     -

    Provides smooth continuous feedback while moving fingers -in multiple touch rotate situation.

     -     - - -

    -
    Haptics -concept

    The different senses associated to the skin are -called cutaneous senses. These senses are temperature, pressure (touch -itself), pain, tickle, itch and vibration senses. We can characterize -touch as passive or active. Passive touch means the sense of touch -itself, whereas active touch means the touch action.

    To communicate -through the sense of touch, we have to stimulate some of the cutaneous -senses or the movement sense. The stimulation of the cutaneous senses -or one of them by a product is called tactile stimulation. Respectively, -the stimulation of the movement sense by a product is called haptic -stimulation or just haptics. Haptics is also used as general term -for all issues related to sense of touch, both human and machine.

    Haptic feedback, often referred to as "Haptics", is the use of -the sense of touch in a user interface design to provide information -to an end user. In mobile phones, this generally means the use of -vibrations from the device's vibration alarm to denote that a touch -screen button has been pressed. In this particular example, the phone -would vibrate slightly in response to the user's activation of an -on-screen control, making up for the lack of a normal tactile response -that the user would experience when pressing a physical button.

    -
    Characteristics -of haptics related APIs

    You can use the following APIs -to create haptic effects:

      -

    • Tactile Feedback Client API

        -

      • Available from S60 5th Edition onwards.

        • -

      • It can be used on all S60 5th Edition or later mobile devices. -However, the feedback is played only on touch enabled layouts.

        • -

      • Provides simple functions for triggering various predefined -tactile feedback (vibration or audio) effects.

        • -

      • Enables a consistent user experience in all applications of -the mobile device (an application gives a logical feedback type as -an input and the actual physical effect depends on the mobile device -configuration and end user settings).

        • -

      • When the area feedback is used, latency is low for the feedback -triggering (a tactile feedback can already be triggered at the window -server level prior to the corresponding pointer event being delivered -to the visible application).

        • -

      • Direct feedback can be easily integrated into CCoeControl::HandlePointerEventL().

        • -

      • An application can select the logical tactile feedback from -certain types. The produced effect may be different on various mobile -devices.

        • -
      • -

    • Haptics API

        -

      • Available from S60 5th Edition, FP2 onwards.

        • -

      • It can be used in touch and hybrid mobile devices.

        • -

      • Provides an interface for accessing Haptics player that can -control different actuator types.

        • -

      • Enables producing of complex vibrator effects, such as an explosion -or machine gun effect in a game, bass boost for a music player, advanced -ringing tone vibration, and so on.

        • -

      • Enables simultaneous playing of different kinds of basis effects -and modifying them when played.

        • -

      • Allows the design of complex effects (using a separate PC application) -that can be loaded on Haptics player for playing.

        • -

      • It may require a special license key for third-party applications -(to be set at runtime) to enable the Haptics player functionality.

        • -
      • -

    • Vibra API

        -

      • Available from S60 3.0 onwards.

        • -

      • It can be used for running device vibrator with given intensity -for a given period of time.

        • -

      • It can be used by a privileged client application to play pulse -effects, which have a very short duration (as the ones used for tactile -feedback).

        • -
      • -
    -
    When -to use Tactile Feedback Client API, Haptics API, and Vibra API

      -

    • Tactile Feedback Client API for providing tactile feedback -in custom controls (grids, lists, and so on), which will comply with -the style of Core UI components to ensure a uniform user experience -among applications.

      • -

    • Haptics API on touch and hybrid mobile devices for producing -complex vibration feedback, which cannot be achieved with Tactile -Framework (games, simulations, demos, and so on).

      • -

    • Vibra API for producing haptic effects such as ringing tone -vibration in those mobile devices where Haptics API is not available -or functional.

      • -

    -
    Using -tactile feedback in applications

    The API to use for tactile -feedback is the Tactile feedback -client API.

    The Symbian platform includes a tactile feedback -interface to add, modify and remove feedback areas in the registry. -There is also an option to trigger direct feedback and bypass the -registry. MTouchFeedback::Instance() is used for -acquiring a pointer to a touch feedback instance. When touch feedback -is activated, the mobile device users get a slight vibration when -the control with the feedback interface is touched.

    Tactile -feedback can be set and disabled in a client application or a mobile -device in some scenarios, for example, during phone calls.

    Client applications cannot determine the actual physical feedback -that is generated. It depends on device configuration and current -settings. In current devices, the user changeable settings include -vibration and audio feedback intensity level.

    For more information, -see Feedback.

    - - - + + + + + +Tactile feedback +

    There are two cases where vibration or audio of the device is used +as an output method:

    +
      +

    • As a tacticon to inform users through physical feedback, +that an important event is occurring in the device. For example, when +a new message arrives or a warning note is displayed.

      • +

    • As tactile feedback to indicate to the user that an +interaction event has been made. For example, users receive tactile +feedback when they press a button on the touch screen.

      • +
    +

    As with sounds, tactile feedback must be used carefully so as not +to desensitize the user to the vibration; the attention grabbing quality +remains and functions so long as the feedback is not too frequent.

    +

    Tactile feedback is enabled for all the Symbian platform UI components. +Tactile feedback can be disabled for the common UI components in an +application. However, this is acceptable only if tactile feedback +causes interference with other device functions.

    +

    The user can choose the level of tactile feedback and turn tacticons +ON and OFF.

    +

    The following table lists the tactile feedback effects:

    +

    Tactile +feedback effects + + + +

    Effects

     +

    Description

     +     + + + +

    Sensitive button

     +

    Provides single pulse effect on repeated key presses with +buttons. It is also possible with other similar components.

     +     + +

    Basic button

     +

    Provides stronger single pulse effect to buttons. It is +also possible with other similar components.

     +     + +

    Sensitive list

     +

    Provides single pulse effect to lists and grids. Effect +is used with move (drag and flick) when new item appears on the screen.

     +     + +

    Basic list

     +

    Provides stronger single pulse effect to lists and grids. +Effect is used with touch down and release when tap makes an action.

    In hierarchical list, collapsing/expanding item provides basic +list effect with touch down and release.

     +     + +

    Bounce effect

     +

    Provides pulse effect when list returns to its normal state +after boundary effect.

     +     + +

    Sensitive slider

     +

    Provides pulse effect with scrollbar and slider thumbs. +Effect is provided with touch down and release in thumb area.

     +     + +

    Smooth slider

     +

    Provides continuous smooth feedback when dragging scrollbar +or slider thumb. This can also be increasing or decreasing depending +of the slider type.

     +     + +

    Hold slider

     +

    Provides sensitive pulse effect when touch down and hold +on the slider or scrollbar area. Slider thumb starts moving step by +step towards the touch point. Every step gives one sensitive pulse. +If slider thumb moves directly to the touch point, then basic slider +effect is provided.

     +     + +

    Pop-up

     +

    Provides sensitive pulse effect when pop-up is opened or +closed. If the theme animations are ON, then pop-up effect is used +with opening event after increasing long touch effect. In this scenario, +there is no pop-up effect . All pop-ups do not have theme animation.

     +     + +

    Pop-up close

     +

    Provides decreasing smooth feedback a pop-up and when theme +animations are ON.

     +     + +

    Increasing long touch

     +

    Provides increasing smooth feedback. This can be used with +either long tap animation or pop-up opening theme effects. If the +theme effects are ON and long tap opens a pop-up, then feedback is +provided only with long tap. This is followed by pop-up.

     +     + +

    Basic tab

     +

    Provides strong pulse effect with touch down event in tab +area.

     +     + +

    Smooth flick

     +

    Provides smooth feedback with drag when horizontal movement +is possible.

     +     + +

    Sensitive flick

     +

    Provides sensitive pulse effect with touch release when +horizontal movement is possible.

     +     + +

    Sensitive edit

     +

    Provides sensitive pulse effect in editors with touch down +and release.

     +     + +

    Text edit

     +

    Provides pulse effect when painting the text. Effect is +provided with every character while painting the text.

     +     + +

    Blank edit

     +

    Provides pulse effect when painting blank character. By +default, it is none.

     +     + +

    Line edit

     +

    Provides pulse effect when painting a line.

     +     + +

    Empty line

     +

    Provides pulse effect when painting an empty line. By default, +it is none.

     +     + +

    Check box

     +

    Provides pulse effect when marking/unmarking a check box.

     +     + +

    Multiple Touch recognition

     +

    Provides double pulse (sensitive + sensitive) effect when +multiple touch is recognized (generally, when second finger is touched +down).

     +     + +

    Smooth pinch

     +

    Provides smooth continuous feedback while moving fingers +in multiple touch pinch situation.

     +     + +

    Smooth rotate

     +

    Provides smooth continuous feedback while moving fingers +in multiple touch rotate situation.

     +     + + +

    +
    Haptics +concept

    The different senses associated to the skin are +called cutaneous senses. These senses are temperature, pressure (touch +itself), pain, tickle, itch and vibration senses. We can characterize +touch as passive or active. Passive touch means the sense of touch +itself, whereas active touch means the touch action.

    To communicate +through the sense of touch, we have to stimulate some of the cutaneous +senses or the movement sense. The stimulation of the cutaneous senses +or one of them by a product is called tactile stimulation. Respectively, +the stimulation of the movement sense by a product is called haptic +stimulation or just haptics. Haptics is also used as general term +for all issues related to sense of touch, both human and machine.

    Haptic feedback, often referred to as "Haptics", is the use of +the sense of touch in a user interface design to provide information +to an end user. In mobile phones, this generally means the use of +vibrations from the device's vibration alarm to denote that a touch +screen button has been pressed. In this particular example, the phone +would vibrate slightly in response to the user's activation of an +on-screen control, making up for the lack of a normal tactile response +that the user would experience when pressing a physical button.

    +
    Characteristics +of haptics related APIs

    You can use the following APIs +to create haptic effects:

      +

    • Tactile +Feedback Client API

        +

      • Available from S60 5th Edition onwards.

        • +

      • It can be used on all S60 5th Edition or later mobile devices. +However, the feedback is played only on touch enabled layouts.

        • +

      • Provides simple functions for triggering various predefined +tactile feedback (vibration or audio) effects.

        • +

      • Enables a consistent user experience in all applications of +the mobile device (an application gives a logical feedback type as +an input and the actual physical effect depends on the mobile device +configuration and end user settings).

        • +

      • When the area feedback is used, latency is low for the feedback +triggering (a tactile feedback can already be triggered at the window +server level prior to the corresponding pointer event being delivered +to the visible application).

        • +

      • Direct feedback can be easily integrated into CCoeControl::HandlePointerEventL().

        • +

      • An application can select the logical tactile feedback from +certain types. The produced effect may be different on various mobile +devices.

        • +
      • +

    • Haptics API

        +

      • Available from S60 5th Edition, FP2 onwards.

        • +

      • It can be used in touch and hybrid mobile devices.

        • +

      • Provides an interface for accessing Haptics player that can +control different actuator types.

        • +

      • Enables producing of complex vibrator effects, such as an explosion +or machine gun effect in a game, bass boost for a music player, advanced +ringing tone vibration, and so on.

        • +

      • Enables simultaneous playing of different kinds of basis effects +and modifying them when played.

        • +

      • Allows the design of complex effects (using a separate PC application) +that can be loaded on Haptics player for playing.

        • +

      • It may require a special license key for third-party applications +(to be set at runtime) to enable the Haptics player functionality.

        • +
      • +

    • Vibra +API

        +

      • Available from S60 3.0 onwards.

        • +

      • It can be used for running device vibrator with given intensity +for a given period of time.

        • +

      • It can be used by a privileged client application to play pulse +effects, which have a very short duration (as the ones used for tactile +feedback).

        • +
      • +
    +
    When +to use Tactile Feedback Client API, Haptics API, and Vibra API

      +

    • Tactile Feedback Client API for providing tactile feedback +in custom controls (grids, lists, and so on), which will comply with +the style of Core UI components to ensure a uniform user experience +among applications.

      • +

    • Haptics API on touch and hybrid mobile devices for producing +complex vibration feedback, which cannot be achieved with Tactile +Framework (games, simulations, demos, and so on).

      • +

    • Vibra API for producing haptic effects such as ringing tone +vibration in those mobile devices where Haptics API is not available +or functional.

      • +

    +
    Using tactile feedback +in applications

    The API to use for tactile feedback is the Tactile feedback +client API.

    The Symbian platform includes a tactile feedback +interface to add, modify and remove feedback areas in the registry. +There is also an option to trigger direct feedback and bypass the +registry. MTouchFeedback::Instance() is used for +acquiring a pointer to a touch feedback instance. When touch feedback +is activated, the mobile device users get a slight vibration when +the control with the feedback interface is touched.

    Tactile +feedback can be set and disabled in a client application or a mobile +device in some scenarios, for example, during phone calls.

    Client applications cannot determine the actual physical feedback +that is generated. It depends on device configuration and current +settings. In current devices, the user changeable settings include +vibration and audio feedback intensity level.

    For more information, +see Feedback.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-581FB79B-2DB9-5AB8-AB32-997B05A62070_d0e107302_href.png Binary file Symbian3/SDK/Source/GUID-581FB79B-2DB9-5AB8-AB32-997B05A62070_d0e107302_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-581FB79B-2DB9-5AB8-AB32-997B05A62070_d0e107534_href.png Binary file Symbian3/SDK/Source/GUID-581FB79B-2DB9-5AB8-AB32-997B05A62070_d0e107534_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5822CE94-C8AF-5F81-AB3F-E95B44265065.dita --- a/Symbian3/SDK/Source/GUID-5822CE94-C8AF-5F81-AB3F-E95B44265065.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -debuggable

    debuggable

    Use the debuggable statement to mark the application to be debugged using the run-mode debug API.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5918ED8A-B26B-41A0-94A6-AB6D51BF80A1.dita --- a/Symbian3/SDK/Source/GUID-5918ED8A-B26B-41A0-94A6-AB6D51BF80A1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5918ED8A-B26B-41A0-94A6-AB6D51BF80A1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,7 +10,7 @@ Menu bars -Menu bar configuration +Menu bar configuration

    The Symbian platform uses MENU_BAR resources to create the Options menu, when a mobile device user selects the Options softkey. The options that appear above the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59217FA7-3078-53CA-88B3-78D6FB788271.dita --- a/Symbian3/SDK/Source/GUID-59217FA7-3078-53CA-88B3-78D6FB788271.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-59217FA7-3078-53CA-88B3-78D6FB788271.dita Tue Jul 20 12:00:49 2010 +0100 @@ -54,7 +54,7 @@ MTMs through a single server interface. The following figure shows the MTM architecture.

    MTM architecture - +
    Message Server and MTMs

    The following figure shows the relationship between the Message Server and MTMs. The grey classes are @@ -65,7 +65,7 @@ the Message Server client API.

    Relationship between Message Server and MTMs - +
    MTM class summary

    Messaging Middleware provides the following base classes, which defines the component interfaces for MTM diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59230503-7E2E-505D-9BC9-C2D2DB96B3E9.dita --- a/Symbian3/SDK/Source/GUID-59230503-7E2E-505D-9BC9-C2D2DB96B3E9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-59230503-7E2E-505D-9BC9-C2D2DB96B3E9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,55 +1,53 @@ - - - - - -RTPExample: -RTP Packet Streaming Example -

    Description

    This example code demonstrates RTP -packet streaming. It uses CRtpFileSender to send RTP packets -and CRtpFileStreamer to receive RTP packets. The example -opens an RTP session using the pre-connected socket and initialises new send -and receive sources on the RTP session. It registers the callback functions -when an RTP packet is successfully sent by a send source or received by a -receive source, to receive notifications whenever an RTP packet is sent or -received.

    The RTPExample example code provides -the following functionality:

    -
    Download

    Click -on the following link to download the example: RTPExample.zip

    Click browse to view the example code.

    -
    Initialising void CRtpFileStreamer::ConstructL();

    Opens an RTP session using the pre-connected socket and initialises new send -sources on the RTP session.

    -
    Sending an RTP packet void CRtpFileSender::RunL();

    Sends the RTP packet. This does the following:

      -

    • gets a new RTP packet -to send from the send source

      • -

    • sets the RTP timestamp -of the RTP packet

      • -

    • reads a block of data -from the source file

      • -

    • creates an RTP packet -using the block of data

      • -

    • sends the RTP packet

      • -

    • closes the source file.

      • -

    CRtpFileSender::PacketSent() is called to notify -that the RTP packet has been successfully sent.

    -
    Receiving an RTP packet void CRtpFileStreamer::NewSource();

    When an RTP packet with a new receive source arrives, this callback function -is called, which registers the packet. This can be used for different types -of RTP packets such as APP, BYE, SDES, SR and RR.

    void CRtpFileStreamer::PacketArrived();

    Whenever an RTP packet arrives, this callback function is called. The -function retrieves the payload from the packet received and writes it to the -target file.

    -
    Class summary

    RSocket RSocketServ RConnection RRtpSession RRtpSendSource RRtpReceiveSource RRtpSendPacket RRtpReceivePacket RFs RFile

    -
    Usage

    The Symbian -build process describes how to build an application.

    This -is a console application, so does not have a GUI. It builds an executable -called RTPExample.exe in the standard location (\epoc32\release\winscw\ <build_variant> for -CodeWarrior). After launching the executable, depending on the emulator you -are using, you may need to task away from the app launcher/shell screen to -view the console.

    -
    See also

    RTP -overview

    + + + + + +RTPExample: RTP Packet Streaming Example +
    Description

    This example code demonstrates RTP packet streaming. It uses CRtpFileSender to send RTP packets and CRtpFileStreamer to receive RTP packets. The example opens an RTP session using the +pre-connected socket and initialises new send and receive sources +on the RTP session. It registers the callback functions when an RTP +packet is successfully sent by a send source or received by a receive +source, to receive notifications whenever an RTP packet is sent or +received.

    The RTPExample example code +provides the following functionality:

    +
    Download

    Click on the following link to download the example: RTPExample.zip

    Click browse to view the example code.

    +
    Initialising void CRtpFileStreamer::ConstructL();

    Opens an RTP session using the pre-connected socket and initialises +new send sources on the RTP session.

    +
    Sending +an RTP packet void CRtpFileSender::RunL();

    Sends the RTP packet. This does the following:

      +

    • gets a new RTP +packet to send from the send source

      • +

    • sets the RTP +timestamp of the RTP packet

      • +

    • reads a block +of data from the source file

      • +

    • creates an RTP +packet using the block of data

      • +

    • sends the RTP +packet

      • +

    • closes the source +file.

      • +

    CRtpFileSender::PacketSent() is called +to notify that the RTP packet has been successfully sent.

    +
    Receiving +an RTP packet void CRtpFileStreamer::NewSource();

    When an RTP packet with a new receive source arrives, this callback +function is called, which registers the packet. This can be used for +different types of RTP packets such as APP, BYE, SDES, SR and RR.

    void CRtpFileStreamer::PacketArrived();

    Whenever an RTP packet arrives, this callback function is called. +The function retrieves the payload from the packet received and writes +it to the target file.

    +
    Class +summary

    RSocket RSocketServ RConnection RRtpSession RRtpSendSource RRtpReceiveSource RRtpSendPacket RRtpReceivePacket RFs RFile

    +
    Usage

    The Symbian build process describes how to build an application.

    This is a console application, so does not have +a GUI. It builds an executable called RTPExample.exe in the standard location (\epoc32\release\winscw\ <build_variant> for CodeWarrior). After launching the +executable, depending on the emulator you are using, you may need +to task away from the app launcher/shell screen to view the console.

    +
    See +also

    RTP overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5927A119-C520-572D-83AF-7265DEEF4553.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-5927A119-C520-572D-83AF-7265DEEF4553.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,129 @@ + + + + + +Using +Pre-Shared Keys with Transport Layer Security : TutorialThis topic describes how to use Pre-Shared Keys (PSKs) with Transport +Layer Security (TLS). This tutorial is useful for licensees and third-party +developers. +

    TLS_PSK is a standard for using PSKs with Transport Layer Security +(TLS). You can use TLS_PSK instead of certificate authentication. The benefits +of using TLS_PSK are as follows:

      +

    • Easy to manage - For +example, PSK can derive from a "secret key" that vendors deploy in the SIM +card of each phone.

      • +

    • It improves the connection +setup performance and battery life, as the key exchange algorithm takes less +time to run.

      • +

    Symbian maintains the following TLS_PSK ciphersuites:

      +

    • TLS_PSK_WITH_RC4_128_SHA

      • +

    • TLS_PSK_WITH_3DES_EDE_CBC_SHA

      • +

    • TLS_PSK_WITH_AES_128_CBC_SHA

      • +

    • TLS_PSK_WITH_AES_256_CBC_SHA

      • +

    The ciphersuite is made up of a key exchange (for example PSK), a +cipher (for example RC4_128) and a hash (for example SHA).

    Note: TLS_PSK +operation is specified by RFC4279.

    For a client to make a secure connection +with a TLS_PSK server, it must provide a pre-shared key and an identity. To +provide a pre-shared key and an identity, do the following steps: +

     + +Configure a PSK +key handler + + +Set available ciphersuites. There are two possibilities for offering +PSK ciphersuites: + +Specify an explicit +ordered list of ciphersuites for the server to select from. +To do this call SetAvailableCipherSuites(). You can +do this only after configuring the PSK key handler. + +Use the default +list, which is automatically generated. +If you do not specify an explicit list, the stack automatically includes +the PSK ciphersuites in addition to any other ciphersuites supported. + + +If you specify an explicit list by calling SetAvailableCipherSuites(), +and you later deconfigure the PSK key handler, you must remove the PSK ciphersuites +from the list by calling SetAvailableCipherSuites() again. + + +Start a connection. +The server chooses a ciphersuite from those offered by the client. If +the server chooses a PSK ciphersuite, the following sequence of events occurs: + + +The server can +optionally send a “PSK identity hint” to the client. + This PSK identity hint might influence the choice of key and identity +the client makes. If the server sends one, it is passed to the key handler. +If it does not send one, NULL is passed to the key handler. +Note: The PSK identity hint is optional and its meaning is not defined +(format must be UTF8). Applications using TLS-PSK may left out it or use it +for any action (for example SUPL uses it to indicate the SUPL protocol version +and to present a list of allowed PSK generators). + +The TLS stack +on the client calls ptrToKeyHandler->getPskL() +The TLS stack on the client calls getPskL() for the instance of the +key handler (in this case ptrToKeyHandler). See MSoPskKeyHandler:: +GetPskL() for the prototype. This call returns the PSK identity +and value to be used to secure the connection. + +The TLS stack +sends the PSK identity to the server. +The TLS stack sends the PSK identity (chosen in Step 2) to the server +so it can retrieve the matching PSK value to secure the connection. + + +After the client has chosen which PSK to use, it sends an identity to +the server and the server can use this to obtain a matching PSK. Again the +meaning of the identity field is not specified, but its format must be UTF8. +An application may choose to use it or leave it empty. +Note: In the example, the server must select a PSK ciphersuite, because +the client provides only PSK ciphersuites. The connection fails, if the server +selects a PSK ciphersuite and fails to get a key that matches with the client. +The TLS assumes that the first common ciphersuite cannot fail and does not +implement connection retry. + + +TLS_PSK example

    The following example code shows +how to configure TLS_PSK:

    + + +//Configure a PSK key handler + +TPckgBuf<MSoPskKeyHandler *> pskConfigPkg; +pskConfigPkg() = ptrToKeyHandler; +User::LeaveIfError(secureSocket->SetOpt(KSoPskConfig, KSolInetSSL, pskConfigPkg)); + +//set available ciphersuites + +TBuf8<8> buf; +for(TInt i=0; i<4; ++i) +{ + // The supported PSK ciphersuites are as follows:- + // TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A }; + // TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B }; + // TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C }; + // TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0x8D }; + buf[i*2]=0; + buf[i*2+1]=0x8a+i; +} +secureSocket->SetAvailableCipherSuites( buf ); + +//Start a connection + +secureSocket->StartClientHandshake( iStatus ); + +     +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-594488FF-02C9-5066-85DB-5F88A754AE18.dita --- a/Symbian3/SDK/Source/GUID-594488FF-02C9-5066-85DB-5F88A754AE18.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to build DLLs \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5971E713-9CA1-5D75-AE9F-2EF9CBDE39F4_d0e220630_href.png Binary file Symbian3/SDK/Source/GUID-5971E713-9CA1-5D75-AE9F-2EF9CBDE39F4_d0e220630_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5971E713-9CA1-5D75-AE9F-2EF9CBDE39F4_d0e225624_href.png Binary file Symbian3/SDK/Source/GUID-5971E713-9CA1-5D75-AE9F-2EF9CBDE39F4_d0e225624_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-598140D3-6C92-5D8E-B204-C7197C6E404D_d0e365531_href.png Binary file Symbian3/SDK/Source/GUID-598140D3-6C92-5D8E-B204-C7197C6E404D_d0e365531_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-598140D3-6C92-5D8E-B204-C7197C6E404D_d0e384680_href.png Binary file Symbian3/SDK/Source/GUID-598140D3-6C92-5D8E-B204-C7197C6E404D_d0e384680_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5986717C-C777-590D-8487-CB8ED488E975.dita --- a/Symbian3/SDK/Source/GUID-5986717C-C777-590D-8487-CB8ED488E975.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,85 +0,0 @@ - - - - - -makmake -command syntax -

    Symbian projects are defined by an .mmp file which -specifies the essential elements of the project. The makmake tool -then uses this environment neutral file to build makefiles for use in various -environments. These makefiles are then used for project development.

    -

    Invocation syntax

    -

    makmake [ options ] [ source-path ] project platform

    -

    Details of options, source-path, project, -and platform are given below.

    -

    Options

    - - - - -

    -d

    -

    Indicates that the makefile is to be created in directory epoc32\build\ path_to_mmp_file \ mmp_basename \ platform rather -than the directory in which makmake was invoked.

    Note -that relative paths within the created makefile will be relative to the directory -in which makmake was invoked so nmake should -be invoked from that directory too if the project is to build correctly.

    -     - -

    -v

    -

    Indicates verbose operation

    When this flag is specified, makmake prints -many progress messages. The default is to give error messages only.

    -     - -

    -mmp

    -

    Provides basic syntax guide to writing .mmp files -instead of making the makefile.

    -     - -

    -plat platform

    -

    Provides syntax guide to writing platform-specific sections of .mmp files, -and information about which macros are defined for preprocessing the .mmp files.

    -     - -

    -arm

    -

    Instructs an ARMV5 build to not build the project as THUMB, but -as the appropriate ARM ABI.

    For details, see ARMV5 -build target.

    -     - -

    -debug

    -

    Generates symbolic debug information for release or debug builds.

    -     - -

    -no_debug

    -

    Does not generate symbolic debug information for release or debug -builds.

    -     - - -
    -

    Note that you can either use -debug to generate or -no_debug to -not generate the symbolic debug information, irrespective of UREL or UDEB build.

    -

    source-path

    -

    This specifies the path of the source .mmp file, relative -to the current directory.

    -

    If omitted, the source .mmp file is project .mmp in -the current directory.

    -

    Whether or not the source-path is specified, the generated -makefile is always written into the current directory.

    -

    project

    -

    This specifies the project for which to create the makefile.

    -

    platform

    -

    This specifies the target platform, e.g. thumb or winscw.

    -

    Command output

    -

    The output makefile name in most cases has the form project-name.platform-name. -The exceptions are for cw_ide, which produces a .xml file, -which can be imported into CodeWarrior, and vc6 and vc6winc, -which produce .dsw and .dsp files.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59A9871D-B0F3-54E2-A5BA-38790C109797_d0e47131_href.png Binary file Symbian3/SDK/Source/GUID-59A9871D-B0F3-54E2-A5BA-38790C109797_d0e47131_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59A9871D-B0F3-54E2-A5BA-38790C109797_d0e47289_href.png Binary file Symbian3/SDK/Source/GUID-59A9871D-B0F3-54E2-A5BA-38790C109797_d0e47289_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59C143F6-3A0C-5C37-9351-A72FE45AFFC9_d0e240099_href.png Binary file Symbian3/SDK/Source/GUID-59C143F6-3A0C-5C37-9351-A72FE45AFFC9_d0e240099_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59C143F6-3A0C-5C37-9351-A72FE45AFFC9_d0e245058_href.png Binary file Symbian3/SDK/Source/GUID-59C143F6-3A0C-5C37-9351-A72FE45AFFC9_d0e245058_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59D86225-4727-5B3F-9117-7815B4900445_d0e185535_href.jpg Binary file Symbian3/SDK/Source/GUID-59D86225-4727-5B3F-9117-7815B4900445_d0e185535_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59D86225-4727-5B3F-9117-7815B4900445_d0e190531_href.jpg Binary file Symbian3/SDK/Source/GUID-59D86225-4727-5B3F-9117-7815B4900445_d0e190531_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59ED6D14-0976-58AE-8DDC-73F051866406.dita --- a/Symbian3/SDK/Source/GUID-59ED6D14-0976-58AE-8DDC-73F051866406.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-59ED6D14-0976-58AE-8DDC-73F051866406.dita Tue Jul 20 12:00:49 2010 +0100 @@ -41,6 +41,6 @@ from the start of CMyClass.

    Links in singly linked lists - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59F26729-3FFB-48AE-91FB-4B9AC2955A06_d0e69489_href.png Binary file Symbian3/SDK/Source/GUID-59F26729-3FFB-48AE-91FB-4B9AC2955A06_d0e69489_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-59F26729-3FFB-48AE-91FB-4B9AC2955A06_d0e69513_href.png Binary file Symbian3/SDK/Source/GUID-59F26729-3FFB-48AE-91FB-4B9AC2955A06_d0e69513_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5A3A3EA0-6C03-56F2-B277-B61A27ABFF9E.dita --- a/Symbian3/SDK/Source/GUID-5A3A3EA0-6C03-56F2-B277-B61A27ABFF9E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,274 +0,0 @@ - - - - - -abld -command syntax overview -

    The abld batch file is used to control all aspects -of building a project. The batch file is created using bldmake from -a component description file.

    -
    Invocation syntax

    abld [ -test ] command [ options ] -[ platform [ build [ program ] -] ]

    The usage for test, command, options, platform, build, -and program are detailed in the following sections.

    Note: For -certain abld commands, parameters such as platform, build, -and program, do not apply. For example, abld export does -not require these parameters, as exports do not depend on build, platform, -or program.

    command

    You can use the -following commands with abld:

    - - - -Command -Purpose - - - - -

    build

    -

    To build the binaries for the specified target. It is a combination -of the commands, export, makefile, library, resource, target, -and final.

    -     - -

    clean

    -

    To remove everything built for the abld target.

    -     - -

    cleanexport

    -

    To remove files created by the abld export command.

    -     - -

    export

    -

    To copy the exported files to their destination.

    -     - -

    final

    -

    To allow extension makefiles to run final commands.

    -     - -

    freeze

    -

    To freeze the exported functions in a .def file.

    -     - -

    help

    -

    To display commands, options, or help about a particular command.

    -     - -

    library

    -

    To create import libraries from the frozen .def files.

    -     - -

    listing

    -

    To create an assembler listing file for a particular source file.

    -     - -

    makefile

    -

    To create makefiles or IDE workspaces.

    -     - -

    reallyclean

    -

    To remove all the files. It is similar to the clean command, -and additionally removes exported files and makefiles.

    -     - -

    resource

    -

    To create resource files and bitmaps.

    -     - -

    target

    -

    To create the main executable file and also the resources.

    -     - -

    tidy

    -

    To remove executable files which need not be released.

    -     - - -

    options

    You can use the following options with abld:

    - - - -Option -Purpose - - - - -

    -check or -c

    -

    To check whether the filenames of the executable and resource files -are compatible for Linux builds.

    -     - -

    -debug

    -

    To generate symbolic debug information for release or debug builds.

    -     - -

    -keepgoing or -k

    -

    To build unrelated targets on error.

    -     - -

    -no_debug

    -

    To not generate symbolic debug information for release or debug -builds.

    -     - -

    -savespace or -s

    -

    To delete intermediate files on success.

    -     - -

    -verbose or -v

    -

    To display the progress of the abld command.

    -     - -

    -what or -w

    -

    To list all releaseables, which include executable/map files, resource -files and so on.

    -     - -

    -I <platform>

    -

    To specify the ARM target to build for, overriding other settings.

    -     - -

    -wrap[=<value>]

    -

    A static analysis tool can be invoked if [=<value>] is -not specified. For example, -wrap. Alternatively, a run-time -analysis tool can be invoked if <value> is specified as proxy. -For example, -wrap=proxy.

    -     - - -

    Notes:

      -

    • You can use -debug or -no_debug options -irrespective of the output build type, that is, UREL or UDEB.

      • -

    • All options are not -applicable to all the commands. Wherever applicable, they can be specified -in their long or short forms. For example,

      -keepgoing (long -form)

      or

      -k (short form)

      • -

    platform

    This specifies the target platform. Possible -platforms are:

    - - - -Target platform -Purpose - - - - -

    all

    -

    To build for all platforms.

    -     - -

    armv5

    -

    To build for ABI v1 of ARMV5 architecture using the RealView Compilation -Tools (RVCT).

    -     - -

    armv5_abiv2

    -

    To build for ABI v2 of ARMV5 architecture using RVCT.

    -     - -

    armv6

    -

    To build for ABI v2 of ARMV6 architecture using RVCT.

    -     - -

    armv6t2

    -

    To build for ABI v2 of ARMV6 architecture that supports Thumb-2 -instruction set, using RVCT.

    -     - -

    armv7

    -

    To build for ABI v2 of ARMV7 architecture that supports Thumb-2 -instruction set, using RVCT.

    -     - - cw_ide

    -

    To build the Metrowerks CodeWarrior project file (importable .xml file).

    -     - -

    gcce

    -

    To build for ABI v2 of ARMV5 architecture using the GNU GCC compiler.

    -     - -

    gccev6

    -

    To build for ABI v2 of ARMV6 architecture using the GNU GCC compiler.

    -     - -

    gccev6t2

    -

    To build for ABI v2 of ARMV6 architecture that supports Thumb-2 -instruction set, using the GNU GCC compiler.

    -     - -

    gccev7

    -

    To build for ABI v2 of ARMV7 architecture that supports Thumb-2 -instruction set, using the GNU GCC compiler.

    -     - -

    gccxml

    -

    To generate the XML description of the project and the program using -GCC XML.

    -     - -

    vs6

    -

    To create the project files suitable for opening the project in -Microsoft Visual Studio IDE, version Visual C++ v6.

    -     - -

    vs2003

    -

    To create the project files suitable for opening the project in -Microsoft Visual Studio IDE, version .NET2003.

    -     - -

    winscw

    -

    To build for the Symbian emulator on Microsoft Windows, using the -Metrowerks CodeWarrior compiler.

    -     - - -

    Note: The target platforms, armv5 and armv5_abiv2 are -compatible with Symbian OS v9.4 or earlier versions. From Symbian OS v9.4 -onwards, these build platforms are renamed as armv5 and armv5_abiv1 to -generate binaries and libraries conforming to ABI v2 and ABI v1 respectively.

    If platform is -not specified, or is specified as all, then abld will -build for all the platforms specified in the component description file.

    Basenames -of .mmp files or extension makefiles must not be platform -names.

    build

    This specifies the build type. Possible -types are:

    - - - -

    udeb

    -

    Debug build

    -     - -

    urel

    -

    Release build

    -     - -

    all

    -

    Debug and release builds

    -     - - -

    If build is not specified, or specified as all, -then abld will build for both udeb and urel.

    Basenames -of .mmp files or extension makefiles must not be build -type names.

    program

    This specifies the basename of a -particular .mmp file or extension makefile, in order -to limit the command to a single project within a component.

    If program is -not specified, then all the projects within the component are built.

    test

    If test is -specified before command, the command will -build all the projects defined by .mmp files listed in -the prj_testmmpfiles section of the component description -file, rather than those listed in the prj_mmpfiles section.

    Note: The test parameter -is not relevant for some commands, and in those cases, it cannot be specified.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5ACFA8E4-3C4B-5851-A43E-9FA72D0B8403.dita --- a/Symbian3/SDK/Source/GUID-5ACFA8E4-3C4B-5851-A43E-9FA72D0B8403.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5ACFA8E4-3C4B-5851-A43E-9FA72D0B8403.dita Tue Jul 20 12:00:49 2010 +0100 @@ -50,7 +50,7 @@ that are described in the following section.

    Package diagram for the XML DOM Engine component - +
    Description

    The XML DOM Engine is an object-oriented provider of the DOM services included in the standard libxml2 library: tree-based @@ -64,7 +64,7 @@ types are shown in the following diagram.

    Extract of the class diagram for the XML DOM Engine parser - +

    Serialisation

    Serialisation transforms the DOM tree (including binary data) into one of the following formats:

    • Default (standard XML)

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5AF0B573-4351-5735-92A1-4F29BCF9A164.dita --- a/Symbian3/SDK/Source/GUID-5AF0B573-4351-5735-92A1-4F29BCF9A164.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,16 +0,0 @@ - - - - - -prj_mmpfiles

      prj_mmpfiles

      mmp_file_1 [build_as_arm] [tidy]

      makefile makefile_1 [build_as_arm] [tidy]

      makefile makefile_n [build_as_arm] [tidy]

      nmakefile makefile_1 [build_as_arm] [tidy]

      nmakefile makefile_n [build_as_arm] [tidy]

      gnumakefile makefile_1 [build_as_arm] [tidy]

      gnumakefile makefile_n [build_as_arm] [tidy]

      In the prj_mmpfiles section, list the .mmp files contained in your component.

      Specify each .mmp file on a separate line.

      Relative paths

      If a relative path is specified with an .mmp file, the path will be considered relative to the directory containing the bld.inf file.

      For example, if in the prj_mmpfiles section, a certain Hello.mmp file is specified as a relative path:

      PRJ_MMPFILES -ProjSpec\Hello.mmp

      and if the bld.inf file is in \MyComp\, then the full path for the location of Hello.mmp will be \MyComp\ProjSpec\Hello.mmp.

      The tidy attribute

      Specify the tidy attribute if the releasable that an .mmp file defines is purely internal to your component, and therefore not required either by other components or for your component to execute.

      If the tidy attribute is specified in your component’s description file, then this will indicate to the abld tool when it is used to run the command abld tidy, to remove those releasables that are no longer required.

      The build_as_arm attribute

      Use the build_as_arm statement to instruct an ARMV5 build to not build the project for the THUMB instruction set, but for the ARM instruction set.

      For details, see ARM/THUMB overrides.

      Extension makefiles

      Use the keyword makefile, nmakefile, and/or gnumakefile to specify extension makefiles for your component. Extension makefiles can be used where build activities need to be carried out which are not catered for by generated makefiles.

      makefile and nmakefile invoke nmake on the specified file. gnumakefile invokes make.

      Build activities relating to particular .mmp files or extension makefiles are carried out in the order in which the .mmp files and extension makefiles are listed in the bld.inf file. Extension makefiles can be interspersed among the .mmp files.

      See Extension makefiles targets for more details.

      Note that the extension makefiles are deprecated, use PRJ_EXTENSIONS instead.

      Platform-specific use

      The prj_mmpfiles section is preprocessed for each platform listed in the prj_platforms section.

      If an .mmp file or extension makefile applies only to a particular platform, then place the item within

      #if defined <identifier> -#endif

      For example, if an .mmp file relates only to the WINS platform, specify the file as follows:

      #if defined(WINS) -<mmp_file> -#endif
      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B442231-6E71-5F35-A27E-B14AEC2FC105.dita --- a/Symbian3/SDK/Source/GUID-5B442231-6E71-5F35-A27E-B14AEC2FC105.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,66 +0,0 @@ - - - - - -ARMV5 -build customisation -

      The ARMV5 build supports the notion of customisation. This allows a programmer -to define a new build target that is derived from the ARMV5 build. A new build -target is defined via a .BSF file. The build system becomes -aware of a customised build by the presence of its .BSF file in epoc32\tools\. -Such customisations are referred to by the name of their .BSF file: -e.g. the file XScale.bsf defines the build target XScale. -This name can be used in exactly the same way as built-in names such as ARMV5.

      -
      BSF Syntax

      It is intended that the syntax of a -.BSF file is toolchain specific with the exception of the obligatory header:

      #<BSF># : token to identify this as a BSF file must appear at start of first line. -CUSTOMIZES build : identitifies which build is customized by this spec e.g. ARMV5.

      Currently, -only ARMV5 can be customised. The ARMV5 specific .BSF syntax is as follows:

      THUMB_OPTIONS opt1 opt2 ... : compiler options used by default for user side code (expected to be THUMB mode) -ARM_OPTIONS opt1 opt2 ... : compiler options used when BUILD_AS_ARM etc are specified (expected to be ARM mode) -KERNEL_OPTIONS opt1 opt2 ... : compiler options used to compile kernel side code -COMMON_OPTIONS opt1 opt2 ... : compiler options that are added to all the above

      The -above four keywords specify compiler options that can be overriden in an MMP -file throughOPTION. For example:

      OPTION ARMCC -Ospace

      A final keyword specifies the system-wide options that cannot be overridden -in an MMP file via OPTION. Typically, these specify options -within the EABI e.g. the SOFTVFP calling convention. They are called invariant -since code compiled with different settings will not be binary compatible.

      INVARIANT_OPTIONS opt opt2 ... : these options are appended to all compiler command lines
      -

      The following is an example bsf file:

      #<bsf># - -# Example build specialization file -# -# NB currently specialization only applies to ARMV5 build using RVCT. - -# This file customizes the default ARMV5. It specifies a build that -# always uses optimization level O1 rather than the default O2. -customizes ARMV5 - -# The following options that can be overridden by MMP files - -# Use these options when compiling user-side THUMB code -thumb_options -thumb -O1 - -# Use these options when compiling user-side ARM code -arm_options -arm -O1 - -# Use these options when compiling Kernel code -kernel_options -arm -O1 - -# This just factors out common (contingent) options from the above. -# These options can also be overridden by MMP files. -common_options --diag_suppress 1,161,654,1135,1152,1300 --diag_error 1267 - -# Fixed options for this build. These options should only be changed with great care since -# they have the potential to introduce incompatible ABI (or machine) level effects. -# -cpu 5T - this build just targets a generic 5T -# -Ono_known_library - we use our own library so tell the compiler not to make assumptions about its implementation -# -fpu softvfp - some system code explicitly assumes this variant of the EABI (softvfp+vfp could be used on say XScale) -# --dll_vtbl - this switches on class exporting and is needed to support Symbian platform DLL model -# -apcs /inter - redundant on 5T, but worth saying anyway -invariant_options -cpu 5T -fy -Ono_known_library -fpu softvfp --dll_vtbl -apcs /inter       -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B6634EA-EB78-504E-BC5D-ABA67EEA06DF_d0e123175_href.png Binary file Symbian3/SDK/Source/GUID-5B6634EA-EB78-504E-BC5D-ABA67EEA06DF_d0e123175_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B6634EA-EB78-504E-BC5D-ABA67EEA06DF_d0e371630_href.png Binary file Symbian3/SDK/Source/GUID-5B6634EA-EB78-504E-BC5D-ABA67EEA06DF_d0e371630_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B8061C3-3BED-51D7-9919-5BA16EA6C6FE_d0e317563_href.png Binary file Symbian3/SDK/Source/GUID-5B8061C3-3BED-51D7-9919-5BA16EA6C6FE_d0e317563_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B8061C3-3BED-51D7-9919-5BA16EA6C6FE_d0e324033_href.png Binary file Symbian3/SDK/Source/GUID-5B8061C3-3BED-51D7-9919-5BA16EA6C6FE_d0e324033_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B8FEDA0-624E-44D6-BF70-C5228234BD15_d0e128056_href.png Binary file Symbian3/SDK/Source/GUID-5B8FEDA0-624E-44D6-BF70-C5228234BD15_d0e128056_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B8FEDA0-624E-44D6-BF70-C5228234BD15_d0e131676_href.png Binary file Symbian3/SDK/Source/GUID-5B8FEDA0-624E-44D6-BF70-C5228234BD15_d0e131676_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5B9DE39D-61D0-51FF-948E-15691CD673B5.dita --- a/Symbian3/SDK/Source/GUID-5B9DE39D-61D0-51FF-948E-15691CD673B5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5B9DE39D-61D0-51FF-948E-15691CD673B5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,109 +1,99 @@ - - - - - -AdvancedClientServerExample: -Using Client/Server APIsThis example application demonstrates the use of client/server -APIs using a logical device driver (LDD) and a physical device driver (PDD). -
      Introduction

      This -example implements asynchronous as well as synchronous client requests to -the server. This example also demonstrates a client and server running in -separate processes and a client and server running in the same process.

      This -example demonstrates the following:

        -

      • a server running -its own process: This is referred to in this document as the process -server. The example also implements a DLL that provides an API to allow -clients to request services from the process server. This client DLL is referred -to as the process client.

        • -

      • a server and client -running in a single process: These are referred to as the thread server and thread -client.

        • -

      • a shut down server: This -terminates the process or thread server if it has no clients connected to -it for 50 seconds.

        • -
      -
      Download

      Process -Client and Server

      Click the following links to download the example:

      ProcessClient.zip

      ProcessServer.zip

      Click the following links -for additional files:

      ProcessServerInc.zip

      Common.zip

      Driver.zip

      Click the following links to view -the example:

      browse ProcessClient

      browse ProcessServer

      Click the following links -to view additional files:

      browse ProcessServerInc

      browse Common

      browse Driver

      Thread Client and Server

      Click -the following links to download the example:

      ThreadClient.zip

      ThreadServer.zip

      Click the following links -to download additional files:

      ThreadServerInc.zip

      Driver.zip

      CommonInc.zip

      Common.zip

      Click the following links to view -the example:

      browse ThreadClient

      browse ThreadServer

      Click the following links to -view additional files

      browse ThreadServerInc

      browse Driver

      browse CommonInc

      browse Common

      -
      Directories

      common

      This -directory contains code that is common to the process and thread servers. -It implements the shut down server which checks the number of connected clients -to the thread or process server. If this number is zero, then after a time -delay, the thread/process server is terminated. The server is not terminated -in the following cases:

        -

      • if the client tries -to connect within the duration of the timer, then the shut down operation -is cancelled and the server handles the client's request to connect.

        • -

      • if the client tries -to connect after the timer has expired but before the server shut down process -has begun, then the process or thread server is stopped and restarted to handle -the client's request to connect.

        • -

      driver

      Device drivers are DLLs that allow code to -communicate with hardware. For more information about device drivers, see -the Device Driver Guide.

      ProcessClient

      This -directory implements a client DLL that starts the process server and creates -a session with it. The client DLL provides an API to allow clients to request -the server to load and unload the device driver.

      ProcessServer

      This -directory implements the process server class CProcessServer, -which is derived from CServer2. It handles client requests -to interact with the device drivers. It can have multiple clients connected -at the same time. The device driver, server and client all have the MultimediaDD capability. -Note that this is for demonstration purposes rather than because the code -uses any Multimedia APIs. The session class CProcessServerSession implements -a simple message queue to hold asynchronous requests.

      ThreadClient

      This -directory implements a client DLL that starts the thread server and creates -a session within it. The client DLL provides an API to allow clients to request -the server to load and unload the device driver.

      ThreadServer

      This -directory implements the thread server class CThreadServer, -which is derived from CServer2. An instance of the thread -server runs in the same process as the client. The thread server handles client -requests to interact with the device drivers. It can have multiple clients -connected at the same time. The session class CThreadServerSession implements -a simple message queue to hold asynchronous requests.

      test

      This -example directory contains a comprehensive test suite to test the process -client and server and the thread client and server.

      -
      Class summary

      CServer2 CSession2 RSessionBase RMessage2 RMessagePtr2 RProcess RThread RBusLogicalChannel DLogicalDevice DLogicalChannel DPhysicalDevice

      -
      Build

      Build -the development and test code using the abld build command -from AdvancedClientServerExample\group as described in the Symbian platform -build process.

      The AdvancedClientServerExample builds -the following binaries in the standard location (\epoc32\release\winscw\<build_variant> for -CodeWarrior):

        -

      • driver1_ldd.ldd.

        • -

      • driver1_pdd.pdd.

        • -

      • processclient.dll,threadclient.dll and threadserver.dll. ,\

        • -

      • processserver.exe, Te_ProcessClientServerTestSuite.exe and Te_ThreadClientServerTestSuite.exe.

        • -

      After launching the Te_ProcessClientServerTestSuite.exe or Te_ThreadClientServerTestSuite.exe executable, depending on the emulator you are using, you may have to -navigate away from the application launcher/shell screen to view the -console.

      -
      Running tests

      To -run the tests, perform the following steps:

        -

      • From the command prompt, change directory to epoc32\release\winscw\udeb.

        • -

      • Run the following command:

        epoc

        • -

      • On the emulator, go to eshell.

        • -

      • Run the following commands:

        testexecute c:\testdata\scripts\te_processclientservertestsuite.script

        testexecute c:\testdata\scripts\te_threadclientservertestsuite.script

        Note: Test -results are stored in the epoc32\winscw\c\logs\testexecute directory:

        • -

      • Process server -tests: Refer to the te_processclientservertestsuite.htm file.

        • -

      • Thread server tests: Refer -to the te_threadclientservertestsuite.htm file.

        • -
      -       -Inter Process -Communication - Device Driver -Guide + + + + + +AdvancedClientServerExample: Using Client/Server APIsThis example application demonstrates the use of client/server +APIs using a logical device driver (LDD) and a physical device driver +(PDD). +
      Introduction

      This example implements asynchronous as well as synchronous +client requests to the server. This example also demonstrates a client +and server running in separate processes and a client and server running +in the same process.

      This example demonstrates the following:

        +

      • a server +running its own process: This is referred to in this document +as the process server. The example also implements a DLL that +provides an API to allow clients to request services from the process +server. This client DLL is referred to as the process client.

        • +

      • a server +and client running in a single process: These are referred to +as the thread server and thread client.

        • +

      • a shut down +server: This terminates the process or thread server if it has +no clients connected to it for 50 seconds.

        • +
      +
      Download

      Process Client and Server

      Click the following links +to download the example:

      ProcessClient.zip

      ProcessServer.zip

      Click the following +links for additional files:

      ProcessServerInc.zip

      Common.zip

      Driver.zip

      Click the following links +to view the example:

      browse ProcessClient

      browse ProcessServer

      Click the following +links to view additional files:

      browse ProcessServerInc

      browse Common

      browse Driver

      Thread Client and Server

      Click the following links to download the example:

      ThreadClient.zip

      ThreadServer.zip

      Click the following +links to download additional files:

      ThreadServerInc.zip

      Driver.zip

      CommonInc.zip

      Common.zip

      Click the following links +to view the example:

      browse ThreadClient

      browse ThreadServer

      Click the following +links to view additional files

      browse ThreadServerInc

      browse Driver

      browse CommonInc

      browse Common

      +
      Directories

      common

      This directory contains code that is common +to the process and thread servers. It implements the shut down server +which checks the number of connected clients to the thread or process +server. If this number is zero, then after a time delay, the thread/process +server is terminated. The server is not terminated in the following +cases:

        +

      • if the client +tries to connect within the duration of the timer, then the shut down +operation is cancelled and the server handles the client's request +to connect.

        • +

      • if the client +tries to connect after the timer has expired but before the server +shut down process has begun, then the process or thread server is +stopped and restarted to handle the client's request to connect.

        • +

      driver

      Device drivers are DLLs that allow +code to communicate with hardware. For more information about device +drivers, see the Device Driver Guide.

      ProcessClient

      This directory implements a client DLL that starts the process +server and creates a session with it. The client DLL provides an API +to allow clients to request the server to load and unload the device +driver.

      ProcessServer

      This directory implements the process server +class CProcessServer, which is derived from CServer2. It handles client requests to interact with the +device drivers. It can have multiple clients connected at the same +time. The device driver, server and client all have the MultimediaDD capability. Note that this is for demonstration purposes rather +than because the code uses any Multimedia APIs. The session class CProcessServerSession implements a simple message queue +to hold asynchronous requests.

      ThreadClient

      This directory implements a client DLL that starts the thread +server and creates a session within it. The client DLL provides an +API to allow clients to request the server to load and unload the +device driver.

      ThreadServer

      This directory implements the thread +server class CThreadServer, which is derived from CServer2. An instance of the thread server runs in the +same process as the client. The thread server handles client requests +to interact with the device drivers. It can have multiple clients +connected at the same time. The session class CThreadServerSession implements a simple message queue to hold asynchronous requests.

      test

      This example directory contains a comprehensive +test suite to test the process client and server and the thread client +and server.

      +
      Class +summary

      CServer2 CSession2 RSessionBase RMessage2 RMessagePtr2 RProcess RThread RBusLogicalChannel DLogicalDevice DLogicalChannel DPhysicalDevice

      +
      Build

      Build the development and test code using the abld build command from AdvancedClientServerExample\group.

      The AdvancedClientServerExample builds the following binaries in the standard location (\epoc32\release\winscw\<build_variant> for CodeWarrior):

        +

      • driver1_ldd.ldd.

        • +

      • driver1_pdd.pdd.

        • +

      • processclient.dll,threadclient.dll and threadserver.dll. ,\

        • +

      • processserver.exe, Te_ProcessClientServerTestSuite.exe and Te_ThreadClientServerTestSuite.exe.

        • +

      After launching the Te_ProcessClientServerTestSuite.exe or Te_ThreadClientServerTestSuite.exe executable, depending on the emulator you are using, you may +have to navigate away from the application launcher/shell screen +to view the console.

      +
      Running +tests

      To run the tests, perform the following steps:

        +

      • From the command prompt, change directory to epoc32\release\winscw\udeb.

        • +

      • Run the following command:

        epoc

        • +

      • On the emulator, go to eshell.

        • +

      • Run the following commands:

        testexecute c:\testdata\scripts\te_processclientservertestsuite.script

        testexecute c:\testdata\scripts\te_threadclientservertestsuite.script

        Note: Test results are stored in the epoc32\winscw\c\logs\testexecute directory:

        • +

      • Process +server tests: Refer to the te_processclientservertestsuite.htm file.

        • +

      • Thread server +tests: Refer to the te_threadclientservertestsuite.htm file.

        • +
      +       +Inter +Process Communication + Device +Driver Guide       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BABDDEC-1D81-5847-9ADB-65DF8E404BFA_d0e230759_href.png Binary file Symbian3/SDK/Source/GUID-5BABDDEC-1D81-5847-9ADB-65DF8E404BFA_d0e230759_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BABDDEC-1D81-5847-9ADB-65DF8E404BFA_d0e235739_href.png Binary file Symbian3/SDK/Source/GUID-5BABDDEC-1D81-5847-9ADB-65DF8E404BFA_d0e235739_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BB017AA-46AE-5461-9184-98CE7FA898B9_d0e370068_href.jpg Binary file Symbian3/SDK/Source/GUID-5BB017AA-46AE-5461-9184-98CE7FA898B9_d0e370068_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BB017AA-46AE-5461-9184-98CE7FA898B9_d0e389217_href.jpg Binary file Symbian3/SDK/Source/GUID-5BB017AA-46AE-5461-9184-98CE7FA898B9_d0e389217_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e74018_href.png Binary file Symbian3/SDK/Source/GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e74018_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e74056_href.png Binary file Symbian3/SDK/Source/GUID-5BD8EE4B-3149-4331-91E0-7813DF4994E1_d0e74056_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C1E776D-5AEF-5326-BEA6-F2108F42CB71.dita --- a/Symbian3/SDK/Source/GUID-5C1E776D-5AEF-5326-BEA6-F2108F42CB71.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5C1E776D-5AEF-5326-BEA6-F2108F42CB71.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,96 +9,84 @@ --> -condvar: -Using Condition VariablesExamples that explains how to use condition variables. +condvar: Using Condition VariablesExamples that explains how to use condition variables.

      • condvarglobal

      • condvarlocal

      -
      condvarglobal

      This -example shows the use of the global condition variable IPC mechanism. The -scope of a global condition variable is inter-process. It can be shared by -threads of any process in the system.

      Download

      Click -on the following link to download the example: condvarglobal .zip

      Click browse to view the example code

      Class summary

      RCondVar RMutex RChunk CPeriodic

      Description

      This -example uses an adder and subtractor pattern to show the use of a global condition -variable. Two processes, the adder and the subtractor, modify a shared variable -by adding and subtracting random amounts. The condition variable ensures that -the value remains within given limits, KMaxValue and KMinValue, -by blocking one of the processes if the value crosses a warning threshold.

      The -adder program creates a global shared memory chunk. It also creates a global -mutex to control access to the chunk and a global condition variable to signal -that the value in the chunk is 'ready for use'. It then initialises -the value in the chunk to zero and periodically tries to add a random value -between 1 and 10 . If, having added a value, it finds that the value of the -chunk is greater than KUpperThreshold, it waits for a signal -from the condition variable before adding another value.

      The subtractor -program periodically tries to subtract a random value between 1 and 10 from -the global shared memory chunk. If, having subtracted a value, it finds that -the value of the chunk is less than KLowerThreshold, it waits -for a signal from the condition variable before subtracting another value.

      Design -and implementation

      - -

      Build

      The -Symbian build process describes how to build this example. The ConditionVariable -example builds the following binary files in the standard location (\epoc32\release\winscw\ +

      condvarglobal

      This example shows the use of the global condition variable IPC +mechanism. The scope of a global condition variable is inter-process. +It can be shared by threads of any process in the system.

      Download

      Click on the following link to download the +example: condvarglobal .zip

      Click browse to view the example code

      Class +summary

      RCondVar RMutex RChunk CPeriodic

      Description

      This example uses an adder and subtractor +pattern to show the use of a global condition variable. Two processes, +the adder and the subtractor, modify a shared variable by adding and +subtracting random amounts. The condition variable ensures that the +value remains within given limits, KMaxValue and KMinValue, by blocking one of the processes if the value +crosses a warning threshold.

      The adder program creates a global +shared memory chunk. It also creates a global mutex to control access +to the chunk and a global condition variable to signal that the value +in the chunk is 'ready for use'. It then initialises +the value in the chunk to zero and periodically tries to add a random +value between 1 and 10 . If, having added a value, it finds that the +value of the chunk is greater than KUpperThreshold, it waits for a signal from the condition variable before adding +another value.

      The subtractor program periodically tries to +subtract a random value between 1 and 10 from the global shared memory +chunk. If, having subtracted a value, it finds that the value of the +chunk is less than KLowerThreshold, it waits for +a signal from the condition variable before subtracting another value.

      Design and implementation

      + +

      Build

      The ConditionVariable example builds +the following binary files in the standard location (\epoc32\release\winscw\ <build_variant>) for Carbide.c++.

        -

      • adder.exe: Demonstrates -the use of the global condition variable. It creates a global shared memory -chunk and periodically adds random values to the chunk.

        • -

      • subtractor.exe: Demonstrates -the use of the global condition variable. It periodically subtracts random -values from the chunk created by adder.exe.

        • -

      How to run the Example

      To run the example, perform -the following steps:

        +

      1. adder.exe: Demonstrates the use of the global condition variable. It creates +a global shared memory chunk and periodically adds random values to +the chunk.

        2. +

      2. subtractor.exe: Demonstrates the use of the global condition variable. It periodically +subtracts random values from the chunk created by adder.exe.

        3. +

    How to run the Example

    To run the example, +perform the following steps:

    1. Run adder.exe.

    2. Run eshell.

      3. -

    3. Run subtract.exe in -your new eshell.

      4. -

    4. Switch between eshells -by pressing CTRL+ALT+SHIFT+T.

      5. -

    5. To finish, stop each -application by pressing any key.

      6. +

    6. Run subtract.exe in your new eshell.

      7. +

    7. Switch between +eshells by pressing CTRL+ALT+SHIFT+T.

      8. +

    8. To finish, stop +each application by pressing any key.

    -
    condvarlocal

    This -example shows the use of the local condition variable IPC mechanism. The scope -of a local condition variable is intra-process. It can be shared by threads -of the process that creates the condition variable.

    Download

    Click -on the following link to download the example: condvarlocal .zip

    Click browse to view the example.

    Class summary

    RMutex RThread CPeriodic RCondVar

    Description

    This -example uses the producer and the consumer model to show the use of the local -condition variable.

    The example creates two local threads: a producer -and a consumer. The two threads share a buffer, which is an object of the CQueue class. -The CQueue object creates a local condition variable using the RCondVar::CreateLocal() function. -It also defines the methods to insert and remove a token from the queue. The CQueue::Insert() function -inserts a token into the queue and signals the condition variable. The CQueue::Remove() function -tries to remove a token from the queue. If the queue is empty, it must wait -for a signal from the condition variable.

    An object of the CProducer class -creates and calls the producer thread. The producer thread is called once -every two seconds using an object of the CPeriodic class. -This thread inserts a token into the queue when it is called. It calls the CQueue::Insert() function -on the shared CQueue object.

    An object of the CConsumer class -creates and calls the consumer thread. The consumer thread is called once -a second using an object of the CPeriodic class. This thread -removes a token from the queue when it is called. It calls the CQueue::Remove() function -on the shared CQueue object.

    For more information, -refer to Condition Variables.

    Symbian -is not responsible for the content of external websites.

    Design -and implementation

    - -

    Build

    The -Symbian build process describes how to build this example. The ConditionVariable -example builds the following binary files in the standard location (\epoc32\release\winscw\ - <build_variant>) for Carbide.c++.

    condvarlocal.exe: -Demonstrates the use of the local condition variable.

    How to run -the Example

    To run the example, perform the following steps:

      -

    1. Run condvarlocal.exe. -The program calls the producer and the consumer threads periodically as shown -in the description section. It also displays a menu.

      2. -

    2. Press ‘d’ to -display the contents of the queue.

      3. -

    3. Press ‘p’ to -insert a token into the queue.

      4. -

    4. Press any key to stop -the program.

      5. +
      condvarlocal

      This example shows the use of the local condition variable IPC +mechanism. The scope of a local condition variable is intra-process. +It can be shared by threads of the process that creates the condition +variable.

      Download

      Click on the following link +to download the example: condvarlocal .zip

      Click browse to view the example.

      Class +summary

      RMutex RThread CPeriodic RCondVar

      Description

      This example uses the producer and the +consumer model to show the use of the local condition variable.

      The example creates two local threads: a producer and a consumer. +The two threads share a buffer, which is an object of the CQueue class. The CQueue object creates a local condition +variable using the RCondVar::CreateLocal() function. +It also defines the methods to insert and remove a token from the +queue. The CQueue::Insert() function inserts a token +into the queue and signals the condition variable. The CQueue::Remove() function tries to remove a token from the queue. If the queue is +empty, it must wait for a signal from the condition variable.

      An object of the CProducer class creates and +calls the producer thread. The producer thread is called once every +two seconds using an object of the CPeriodic class. +This thread inserts a token into the queue when it is called. It calls +the CQueue::Insert() function on the shared CQueue object.

      An object of the CConsumer class creates and calls the consumer thread. The consumer thread +is called once a second using an object of the CPeriodic class. This thread removes a token from the queue when it is called. +It calls the CQueue::Remove() function on the shared CQueue object.

      For more information, refer to Condition Variables.

      Symbian +is not responsible for the content of external websites.

      Design and implementation

      + +

      Build

      The Symbian build process describes +how to build this example. The ConditionVariable example builds the +following binary files in the standard location (\epoc32\release\winscw\ + <build_variant>) for Carbide.c++.

      condvarlocal.exe: Demonstrates the use of the +local condition variable.

      How to run the Example

      To run the example, perform the following steps:

        +

      1. Run condvarlocal.exe. The program calls the producer and the +consumer threads periodically as shown in the description section. +It also displays a menu.

        2. +

      2. Press ‘d’ to display the contents of the queue.

        3. +

      3. Press ‘p’ to insert a token into the queue.

        4. +

      4. Press any key +to stop the program.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C1EC237-EBC3-474D-B58D-502B82911DCA_d0e75308_href.png Binary file Symbian3/SDK/Source/GUID-5C1EC237-EBC3-474D-B58D-502B82911DCA_d0e75308_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C1EC237-EBC3-474D-B58D-502B82911DCA_d0e75346_href.png Binary file Symbian3/SDK/Source/GUID-5C1EC237-EBC3-474D-B58D-502B82911DCA_d0e75346_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C215C64-5D3D-5B65-A11F-BE6F8C306CF4.dita --- a/Symbian3/SDK/Source/GUID-5C215C64-5D3D-5B65-A11F-BE6F8C306CF4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5C215C64-5D3D-5B65-A11F-BE6F8C306CF4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -79,4 +79,4 @@

      The resource (.rss) file contains the XML file and the following information:

      • dll_uid and implementation_uid: These UIDs are supplied on request to Symbian Signed.

        Note: These UIDs can be the same.

      • interface_uid: This must have the value 0x102010DD.

      • default_data: The application UID (without 0x).

      • opaque_data: The application capabilities in XML format. This field is empty if application capabilities are defined in the implementation.

      Resolving the target client using CSIPResolvedClient

      The following illustration shows how the SIP Client Resolver subsystem resolves the target client implementation and requests the resolved client to connect to the SIP implementation. In this plan, the default resolution logic is applied.

      Call flow of resolving a target client implementation using CSIPResolvedClient -

      The following list describes how the target client is resolved using CSIPResolvedClient.

      1. The user receives a SIP request and the target client is defined using CSIPResolvedClient.

      2. The user requests the SIP Client Resolver API implementation for a channel UI to connect to the user.

      3. The user requests the target client to connect to SIP with the resolved UID if there is no connection with the resolved channel UID.

      4. The SIP Client Resolver API implementation starts the target client.

      See also

      Example of a SIP client resolver plug-in

      \ No newline at end of file +

      The following list describes how the target client is resolved using CSIPResolvedClient.

      1. The user receives a SIP request and the target client is defined using CSIPResolvedClient.

      2. The user requests the SIP Client Resolver API implementation for a channel UI to connect to the user.

      3. The user requests the target client to connect to SIP with the resolved UID if there is no connection with the resolved channel UID.

      4. The SIP Client Resolver API implementation starts the target client.

    See also

    Example of a SIP client resolver plug-in

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C4922C8-3AE3-424A-A2E7-5C6DA323FFA6.dita --- a/Symbian3/SDK/Source/GUID-5C4922C8-3AE3-424A-A2E7-5C6DA323FFA6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5C4922C8-3AE3-424A-A2E7-5C6DA323FFA6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -91,7 +91,7 @@ client for the Alarm Alert server. The following diagram illustrates the Alarm Server architecture:

    Alarm Server Architecture - +

    Alarm Client and Alarm Shared

    They are the static interface DLLs. Alarm client is the client side of the Alarm Server, which allows other components to interact with the Alarm Server.

    The Alarm diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C52B6B9-546C-5152-A968-B91CB3D885A0_d0e336267_href.jpg Binary file Symbian3/SDK/Source/GUID-5C52B6B9-546C-5152-A968-B91CB3D885A0_d0e336267_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C52B6B9-546C-5152-A968-B91CB3D885A0_d0e342733_href.jpg Binary file Symbian3/SDK/Source/GUID-5C52B6B9-546C-5152-A968-B91CB3D885A0_d0e342733_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C5A695C-A0BB-53C3-A20B-7C7F4DD718DF_d0e266965_href.png Binary file Symbian3/SDK/Source/GUID-5C5A695C-A0BB-53C3-A20B-7C7F4DD718DF_d0e266965_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C5A695C-A0BB-53C3-A20B-7C7F4DD718DF_d0e271820_href.png Binary file Symbian3/SDK/Source/GUID-5C5A695C-A0BB-53C3-A20B-7C7F4DD718DF_d0e271820_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C7F92F7-F3BC-4B00-A093-682AA6A26FFE_d0e64131_href.png Binary file Symbian3/SDK/Source/GUID-5C7F92F7-F3BC-4B00-A093-682AA6A26FFE_d0e64131_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5C7F92F7-F3BC-4B00-A093-682AA6A26FFE_d0e64274_href.png Binary file Symbian3/SDK/Source/GUID-5C7F92F7-F3BC-4B00-A093-682AA6A26FFE_d0e64274_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5D4DA7CA-DAB8-51E6-B597-4E8B0AB56477.dita --- a/Symbian3/SDK/Source/GUID-5D4DA7CA-DAB8-51E6-B597-4E8B0AB56477.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -target

    target filename . ext

    Use the target statement to specify the file generated by the project.

    Specify only the filename with its extension. The path for the released target will be chosen depending on the platform, variant, and release path.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5D508751-C824-48E4-A6E3-0C5EA05DEC99.dita --- a/Symbian3/SDK/Source/GUID-5D508751-C824-48E4-A6E3-0C5EA05DEC99.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5D508751-C824-48E4-A6E3-0C5EA05DEC99.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,50 +1,48 @@ - - - - - -PKG -file format to support multilingual application installation

    Symbian platform applications can be localized by defining all -the localizable text and images in language-specific resource and icon files. -For more information on localising the resource files, see How -to localise resources. The PKG file must contain language-specific -resource and icon files along with the elements required for simple -installation.

    -
    Example

    The following PKG file is provided -in examples\ToolsAndUtilities\Localise\.

    ; Install file for multi-lingual application supporting two language variants - -; List of languages supported -&EN,GE - -; List of localised vendor names for each supported language -%{"Nokia Corporation", "Nokia Corporation"} - -; Single, non-localised (global) vendor name. -:"Nokia Corporation" - -; Package header -; Component names specified in English and German as these are supported languages -#{"Hello World", "Hallo Welt"}, (0xE8000096), 1,0,0 - -; Language-neutral files to be installed irrespective of the languages supported on the Symbian device. - -"HelloWorld.exe"-"!:\sys\bin\HelloWorld.exe" -"HelloWorld_reg.rsc" - "!:\private\10003a3f\import\apps\HelloWorld_reg.rsc" - -; List of language-specific files; installed based on the language supported by the Symbian device. -if supported_language=01 - "HelloWorld.r01" -"!:\resource\apps\HelloWorld.r01" ;English version of the resource file - "HelloWorld01.mbm" -"!:\resource\apps\HelloWorld01.mbm" ;language-specific icon file -endif - -if supported_language=03 - "HelloWorld.r03" -"!:\resource\apps\HelloWorld.r03" ;German version of the resource file - "HelloWorld03.mbm" -"!:\resource\apps\HelloWorld03.mbm" ;language-specific icon file -endif
    + + + + + +PKG file format to support multilingual application installation

    Symbian platform applications can be localized by defining +all the localizable text and images in language-specific resource +and icon files. The PKG file must contain language-specific +resource and icon files along with the elements required for +simple installation.

    +
    Example

    The following PKG file is +provided in examples\ToolsAndUtilities\Localise\.

    ; Install file for multi-lingual application supporting two language variants + +; List of languages supported +&EN,GE + +; List of localised vendor names for each supported language +%{"Nokia Corporation", "Nokia Corporation"} + +; Single, non-localised (global) vendor name. +:"Nokia Corporation" + +; Package header +; Component names specified in English and German as these are supported languages +#{"Hello World", "Hallo Welt"}, (0xE8000096), 1,0,0 + +; Language-neutral files to be installed irrespective of the languages supported on the Symbian device. + +"HelloWorld.exe"-"!:\sys\bin\HelloWorld.exe" +"HelloWorld_reg.rsc" - "!:\private\10003a3f\import\apps\HelloWorld_reg.rsc" + +; List of language-specific files; installed based on the language supported by the Symbian device. +if supported_language=01 + "HelloWorld.r01" -"!:\resource\apps\HelloWorld.r01" ;English version of the resource file + "HelloWorld01.mbm" -"!:\resource\apps\HelloWorld01.mbm" ;language-specific icon file +endif + +if supported_language=03 + "HelloWorld.r03" -"!:\resource\apps\HelloWorld.r03" ;German version of the resource file + "HelloWorld03.mbm" -"!:\resource\apps\HelloWorld03.mbm" ;language-specific icon file +endif
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5D712F4A-E956-543D-BCC0-91107C6E4717.dita --- a/Symbian3/SDK/Source/GUID-5D712F4A-E956-543D-BCC0-91107C6E4717.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5D712F4A-E956-543D-BCC0-91107C6E4717.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Notification of changes to the comms databaseThis topic describes the mechanism that allows the CommsDat API to notify tools and applications of changes to the Comms Database.

    All elements that you can read and write have the class MMetaDatabase as a base class. This base class contains the functions that allow the CommsDat API to notify tools and applicaions of changes to the database.

    Tables, records, links and fields are all elements. The classes that represent tables, records, links and fields have MMetaDatabase in their class hierearchy. You can use the CommsDat::MMetaDatabase::RequestNotification() function to register for notification of changes to the Comms Database. You can use the CommsDat::MMetaDatabase::CancelNotification() function to cancel a request for notification.

    \ No newline at end of file +Notification of changes to the comms databaseThis topic describes the mechanism that allows the CommsDat API to notify tools and applications of changes to the Comms Database.

    All elements that you can read and write have the class MMetaDatabase as a base class. This base class contains the functions that allow the CommsDat API to notify tools and applicaions of changes to the database.

    Tables, records, links and fields are all elements. The classes that represent tables, records, links and fields have MMetaDatabase in their class hierearchy. You can use the CommsDat::MMetaDatabase::RequestNotification() function to register for notification of changes to the Comms Database. You can use the CommsDat::MMetaDatabase::CancelNotification() function to cancel a request for notification.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5D831531-2430-4C61-B8C4-BEE9850387C2_d0e38281_href.png Binary file Symbian3/SDK/Source/GUID-5D831531-2430-4C61-B8C4-BEE9850387C2_d0e38281_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5D831531-2430-4C61-B8C4-BEE9850387C2_d0e38449_href.png Binary file Symbian3/SDK/Source/GUID-5D831531-2430-4C61-B8C4-BEE9850387C2_d0e38449_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5DB0F7C7-6132-552B-BA42-B47D267D1143_d0e49355_href.png Binary file Symbian3/SDK/Source/GUID-5DB0F7C7-6132-552B-BA42-B47D267D1143_d0e49355_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5DB0F7C7-6132-552B-BA42-B47D267D1143_d0e49513_href.png Binary file Symbian3/SDK/Source/GUID-5DB0F7C7-6132-552B-BA42-B47D267D1143_d0e49513_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5E380880-9DBB-51D7-8942-829C6FD788C2_d0e281245_href.png Binary file Symbian3/SDK/Source/GUID-5E380880-9DBB-51D7-8942-829C6FD788C2_d0e281245_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5E380880-9DBB-51D7-8942-829C6FD788C2_d0e286084_href.png Binary file Symbian3/SDK/Source/GUID-5E380880-9DBB-51D7-8942-829C6FD788C2_d0e286084_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5E7FB4BD-DF3B-4F97-8394-5E1A6FF8D11B_d0e4494_href.png Binary file Symbian3/SDK/Source/GUID-5E7FB4BD-DF3B-4F97-8394-5E1A6FF8D11B_d0e4494_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5E7FB4BD-DF3B-4F97-8394-5E1A6FF8D11B_d0e4621_href.png Binary file Symbian3/SDK/Source/GUID-5E7FB4BD-DF3B-4F97-8394-5E1A6FF8D11B_d0e4621_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5E8AA6B6-38EB-5347-BA30-F9FF4BF7C107.dita --- a/Symbian3/SDK/Source/GUID-5E8AA6B6-38EB-5347-BA30-F9FF4BF7C107.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5E8AA6B6-38EB-5347-BA30-F9FF4BF7C107.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,7 +27,7 @@ the SQL database.

    Message Server architecture with the SQL database - + Write operations like updating, creating and deleting entries require disk operation to retrieve TMsvEntry from database, because the entry cache is always in synchronisation with the corresponding diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5F4510C9-5B16-593A-A225-37606800915B.dita --- a/Symbian3/SDK/Source/GUID-5F4510C9-5B16-593A-A225-37606800915B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5F4510C9-5B16-593A-A225-37606800915B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Controlling Video Playback

    This tutorial describes how to control video playback.

    Purpose

    The purpose of this tutorial is to show you how to use the video player to control video playback.

    Required Background

    The Video Client Overview introduces the video client utilities.

    Introduction

    The video player utility is used to open, play, and obtain information from sampled video data. This functionality is implemented by the CVideoPlayerUtility class. The video data can be supplied either in a file, a descriptor or a URL.

    The sequence diagram below explains the different functionalities of the Video Player Utility:

    Video Player sequence diagram -
    Using Video Player

    The following tasks will be covered in this tutorial:

    • Play Video Clips

    • Get Current Frame

    Playing Video Clips

    The high level steps to play video clips are shown here:

    1. After configuring the properties, the CVideoPlayerUtility::Play() function is called for the video clip to be played.

    2. The play can be paused for a small duration using CVideoPlayerUtility::PauseL() and later resumed by calling CVideoPlayerUtility::Play() function once again.

    3. To halt the video play CVideoPlayerUtility::Stop() is called.

    4. In order to unload all related controllers and return, use CVideoPlayerUtility::Close().

    These high level steps are shown in the following example code:

    void CPlayVideo::Play() //Starts playback of the video clip +
    Using Video Player

    The following tasks will be covered in this tutorial:

    • Play Video Clips

    • Get Current Frame

    Playing Video Clips

    The high level steps to play video clips are shown here:

    1. After configuring the properties, the CVideoPlayerUtility::Play() function is called for the video clip to be played.

    2. The play can be paused for a small duration using CVideoPlayerUtility::PauseL() and later resumed by calling CVideoPlayerUtility::Play() function once again.

    3. To halt the video play CVideoPlayerUtility::Stop() is called.

    4. In order to unload all related controllers and return, use CVideoPlayerUtility::Close().

    These high level steps are shown in the following example code:

    void CPlayVideo::Play() //Starts playback of the video clip { iVideoUtility->Play(); } diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5F72210C-1636-584D-9D89-987D25136975_d0e363464_href.png Binary file Symbian3/SDK/Source/GUID-5F72210C-1636-584D-9D89-987D25136975_d0e363464_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5F72210C-1636-584D-9D89-987D25136975_d0e382613_href.png Binary file Symbian3/SDK/Source/GUID-5F72210C-1636-584D-9D89-987D25136975_d0e382613_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5F749184-C804-41FC-BA81-038783BDC967.dita --- a/Symbian3/SDK/Source/GUID-5F749184-C804-41FC-BA81-038783BDC967.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-5F749184-C804-41FC-BA81-038783BDC967.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,38 +1,37 @@ - - - - - -Resources -

    In Symbian mobile application development, resource files are used for -defining user interface components and visible text. The advantage of using -resource files include:

    -
      -

    • making source code shorter and simpler

      • -

    • saving memory, because text is loaded only when needed

      -
      • -

    • making it easier to implement localization to different language -groups

      • -
    -

    A key example of the use of resource files is found in the implementation -of AVKON components. -AVKON UI components consist of data structures that are defined in the resource files , and then are called from the classes controlling the UI implementation. -When UI component implementation is split into these two approaches, it means -that resources can be recompiled, for example for new languages, without having -to recompile the application code.

    -

    For more information on managing resource files, see:

    -
      -

    • Managing -resource files

      -
      • -

    • Internationalization -and localization

      -
      • -
    + + + + + +Resources +

    In Symbian mobile application development, resource files are +used for defining user interface components and visible text. The +advantage of using resource files include:

    +
      +

    • making source code shorter and simpler

      +
      • +

    • saving memory, because text is loaded only when needed

      +
      • +

    • making it easier to implement localization to different +language groups

      • +
    +

    A key example of the use of resource files is found in the implementation +of AVKON components. AVKON UI components consist of data structures that are defined +in the resource +files , and then are called from the classes controlling the UI implementation. +When UI component implementation is split into these two approaches, +it means that resources can be recompiled, for example for new languages, +without having to recompile the application code.

    +

    For more information on managing resource files, see:

    +
      +

    • Managing resource files

      • +

    • Internationalization +and localization

      • +
     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5FE10ECA-1FAB-4E4F-A1D9-67D379EE8CB3_d0e290304_href.png Binary file Symbian3/SDK/Source/GUID-5FE10ECA-1FAB-4E4F-A1D9-67D379EE8CB3_d0e290304_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5FE10ECA-1FAB-4E4F-A1D9-67D379EE8CB3_d0e296776_href.png Binary file Symbian3/SDK/Source/GUID-5FE10ECA-1FAB-4E4F-A1D9-67D379EE8CB3_d0e296776_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-5FFBC0B0-FC6E-5D60-868B-064DBEB632E0.dita --- a/Symbian3/SDK/Source/GUID-5FFBC0B0-FC6E-5D60-868B-064DBEB632E0.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,125 +0,0 @@ - - - - - -Resource -builder tool: epocrc -
    Purpose

    epocrc combines the -actions of passing a resource file through the C++ preprocessor, and then -compiling it with rcomp.

    -
    Command line -syntaxepocrc [-Dargs] -[-Iargs] [-u] [-ttmpdir] [-uid2 uid] -[-uid3 uid] source-file [-ooutput-file] -[-hheader-file]

    Arguments

    - - - -

    -D args

    -

    Pass arguments args to the preprocessor's -D -(macro definitions) option.

    -     - -

    -I args

    -

    Pass arguments args to the preprocessor's -I -(additional include files path) option.

    -     - -

    -u

    -

    Generate a Unicode resource binary.

    -     - -

    -t tmpdir

    -

    Create any temporary files in the directory tmpdir.

    If -this option is not specified, the current directory is used.

    -     - -

    -uid2 uid

    -

    Second UID for the resource file. Specifying either -uid2 or -uid3 -overrides all UIDs specified in the source file.

    -     - -

    -uid3 uid

    -

    Third UID for the resource file

    -     - -

    source-file

    -

    Name (and path if the file is not in the current directory) of the -resource file to compile

    -     - -

    -o output-file

    -

    Create data output file output-file. If a path -is not specified, the current directory is used.

    If this option is -not specified, no data output file is created.

    -     - -

    -h header-file

    -

    Create header output file header-file. If a path -is not specified, the current directory is used.

    If this option is -not specified, no header output file is created.

    -     - -

    -v

    -

    Verbose. Displays the command line syntax.

    -     - - -

    Output files

    - - - -

    output-file

    -

    Compiled resource data referred to by the application at run-time.

    -     - -

    header-file

    -

    The generated header file defining macro identifiers for referring -to resources by a resource index

    -     - - -

    epocrc configuration -file format

    Apart from the options listed above, you can use the epocrc.config file -located at epoc32\tools\ to configure the pre-processor -and the rcomp tool. The file is supplied to each Symbian -platform licensee as they need it, but it may not be present on some platforms.

    The epocrc.config file -contains the following options:

      -

    • check_rls_items: -This option can either be set to 0 or 1. If you want to check for the presence -of localisation comment tags before each RLS item declaration, set it to 1, -otherwise set it to 0. If there are no localisation comment tags within the -resource file, it is assumed that localisation is not required for this file.

      • -

    • strict_checking: -This option can either be set to 0 or 1. If you set it to 1, the rcomp tool -warns you if the rpp file contains RLS item declarations -without the localisation comment tags. If you want to enable this functionality, -you must set check_rls_items to 1.

      • -

    • include:: -This option is used to specify files and directories, which need to be passed -to the C++ pre-processor. File names and directory names must be relative -to EPOCROOT.

      • -
    You can comment a line in the epocrc.config file -by preceding it by '#'.

    Here is an example of the epocrc.config file, -which enables the strict_checking and check_rls_items options, -and lists the resource headers to be included using the include: option:

    # epocrc.config -# -# Copyright (c) 2005 Symbian Ltd. All rights reserved. -# -check_rls_items = 1; -strict_checking = 1; -include: epoc32\include\SymbianTags.rh -include: epoc32\include\SymbainContexts.rh -
    -
    Example

    The following example compiles the source -file ex.rss into the compiled resource file ex.rsc and -the header file ex.rsg.

    epocrc -I\symbian\epoc32\include\ --u ex.rss -oex.rsc -hex.rsg

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6006AAB0-B319-546F-8D79-E2D4887A1E72.dita --- a/Symbian3/SDK/Source/GUID-6006AAB0-B319-546F-8D79-E2D4887A1E72.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6006AAB0-B319-546F-8D79-E2D4887A1E72.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ items; for example, a stack.

    Singly linked list - +

    Singly linked lists involve the creation and use of the classes:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-600DCD27-ADC0-40D7-B061-1D44238363BA_d0e128297_href.png Binary file Symbian3/SDK/Source/GUID-600DCD27-ADC0-40D7-B061-1D44238363BA_d0e128297_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-600DCD27-ADC0-40D7-B061-1D44238363BA_d0e131917_href.png Binary file Symbian3/SDK/Source/GUID-600DCD27-ADC0-40D7-B061-1D44238363BA_d0e131917_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6025A68F-625B-570A-87D7-2C11E66044D4.dita --- a/Symbian3/SDK/Source/GUID-6025A68F-625B-570A-87D7-2C11E66044D4.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,86 +0,0 @@ - - - - - -Build -FAQ -

      This page gives some quick answers to problems and issues you may encounter -when building code.

      -

      Why do applications build to the Symbian Emulator's Z: drive?

      -

      The build tools were originally designed for building ROM-based applications, -and so assume that applications should be placed in the emulated ROM area -(i.e. epoc32\release\winscw\udeb\ or urel\). Third party -applications intended to loaded on disk are also built to this location, but -this doesn't mean they can only be installed in ROM or have any other impact -on them. (Note that your code should not assume that it will be installed -on any particular drive, as this is choice is best left to the user).

      -

      Why does abld makefile give a WARNING: Can't find following headers -in System Include Path message, even though I export the header(s) in my bld.inf?

      -

      You can specify that headers from your project should be copied into the -system headers directory, epoc32\include, by using a prj_exports statement -in the bld.inf file. The header is not actually copied -though until an abld export command, or a command -that calls this, such as abld build is executed. -The solution is to call abld export before abld -makefile.

      -

      What Symbian platform tools can I cause to be invoked through a project -file keywords?

      -

      The chief purpose of a project (.mmp) file is to specify -the source files and options to pass to the appropriate compiler toolchain -for the platform. In many cases though, you will want to create a number of -additional, Symbian platform-specific, support files as part of the project -build. You can invoke the tools to create such files by specifying a number -of project file keywords:

      -
        -

      • start -resource to compile resource files

        • -

      • start -bitmap to compile multi-bitmap files.

        • -
      -

      Of the other commonly used Symbian platform tools, the project file does -not specify keywords that invoke the:

      -
        -

      • Installation -File Generator (makesis)

        • -

      • Certification -Generator (makekeys)

        • -

      • Context -Sensitive Help Compiler (cshlpcmp)

        • -
      -

      Note though you can invoke these, and any other tools, through extension -makefiles.

      -

      What are edll.obj and eexe.obj?

      -

      The build process builds into each .exe file a small -object file, eexe.lib, which contains a small amount -of code to manage process startup. Similiarly, each DLL has an object file edll.lib built -into it.

      -

      Why does the build give a message diff: <file-path-and-name>: No -such file or directory?

      -

      This message appears when building a project's resource or multi-bitmap -file for the first time. It can be ignored.

      -

      Why do I get a LNK2001: unresolved external symbol __chkstk error?

      -

      The program exceeds the stack space available, e.g. by creating a large TBuf on -the stack. The solution is to reduce the use of stack space by using the heap -appropriately.

      -

      How can I change the libraries for a project open in an IDE?

      -

      To change a project's libraries, you should edit the .mmp file's library statement -as normal, and then regenerate the IDE workspace using abld -makefile.

      -

      Where are the .lib files for ARM debug builds?

      -

      The .lib files required for ARM debug builds are identical -to those for release builds, so the build tools use a single copy of the libs -in the urel directory.

      -

      Why do I get an error from petran when I build for ARM, when the WINS/WINSCW -build is fine?

      -

      petran is a tool that is invoked only at the final -stage of the build process for ARM targets. It will give an error if you build -a DLL that contains writeable static data. See Static -data for more information.

      -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60B4CDBE-B863-52EA-9125-632A1FF1A059_d0e396128_href.png Binary file Symbian3/SDK/Source/GUID-60B4CDBE-B863-52EA-9125-632A1FF1A059_d0e396128_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60B4CDBE-B863-52EA-9125-632A1FF1A059_d0e399923_href.png Binary file Symbian3/SDK/Source/GUID-60B4CDBE-B863-52EA-9125-632A1FF1A059_d0e399923_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60B9404B-5102-4FBB-A32F-55F2ACFD1481.dita --- a/Symbian3/SDK/Source/GUID-60B9404B-5102-4FBB-A32F-55F2ACFD1481.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-60B9404B-5102-4FBB-A32F-55F2ACFD1481.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,7 +27,7 @@ uses these plug-ins to perform various roles such as encoding, decoding and media processing.

      GStreamer plug-ins - +

    Description

    Some GStreamer concepts are as follows:

      @@ -69,7 +69,7 @@

    • Video editing

      • For example the diagram below shows how a Media Player uses GStreamer:

      Media playback using GStreamer - +

      Sound device is a framework to perform hardware accelerated audio functionality. Audio Policy manages the requests to access the audio hardware. Digital Signal Processing converts diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60B98AFE-6DE6-5086-B70C-F377562E60D9.dita --- a/Symbian3/SDK/Source/GUID-60B98AFE-6DE6-5086-B70C-F377562E60D9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,23 +0,0 @@ - - - - - -Extension makefile targets

      Extension makefiles can be used where certain build steps are required that are not catered for by the generated makefiles. Extension makefiles are makefiles to be run by make.exe (the GCC make utility) or nmake.exe (the Microsoft make utility). They must contain certain make targets. During build activities, abld will call the target corresponding to the build activity that is being carried out. This will then execute whatever commands your makefile specifies for that target.

      The following table lists the required make targets:

      Target

      Corresponding abld command

      makmake

      makefile

      freeze

      freeze

      lib

      library

      cleanlib

      tidy

      clean

      clean

      final

      final. This target is provided specifically to allow extension makefiles to execute final commands.

      resource

      resource

      bld

      target

      savespace

      target -savespace

      releasables

      target [-what | -check]

      All targets must be provided in an extension makefile. This should be done even if no commands are listed with a particular target, for the following two reasons:

      • The target will be called, during the build, whether commands are listed or not

      • nmake.exe /make.exe will generate an error if the target cannot be found.

      Simple example

      An example of a simple extension makefile is given below:

      MAKMAKE : - echo this is an example - -FINAL FREEZE LIB CLEANLIB RESOURCE RELEASABLES CLEAN BLD SAVESPACE :

      This prints this is an example to the console at the makefile construction stage of an abld, and does nothing for the other targets.

      Note that:

      • You can put multiple targets on the same line, as above.

      • You must have a space or a tab at the start of lines containing target commands.

      • Commands listed with each target can be calls to any tools or system commands that are available at build-time.

      Platform-specific commands example

      If different commands are required for the same target for different platforms, special nmake.exe /make.exe syntax can be used in conjunction with the $(PLATFORM) and $(CFG) macros that abld defines to carry out the different commands.

      $(CFG) is defined as UDEB or UREL. $(PLATFORM) is WINS, ARMI, etc.

      For example, the following nmake makefile prints ARMI MAKEMAKE COMMAND at the makefile stage for the ARMI target, or NOT ARMI BUILD for any other platform:

      !IF "$(PLATFORM)" == "ARMI" -MAKMAKE: - echo ARMI MAKEMAKE COMMAND -!ELSE -MAKMAKE: - echo NOT ARMI BUILD -!ENDIF - -FINAL FREEZE LIB CLEANLIB RESOURCE RELEASABLES CLEAN BLD SAVESPACE :
      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60DBA025-8FA0-5DF2-90D0-744A016998EE.dita --- a/Symbian3/SDK/Source/GUID-60DBA025-8FA0-5DF2-90D0-744A016998EE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-60DBA025-8FA0-5DF2-90D0-744A016998EE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Panoramic Stitching Guide

      This document introduces you to the panoramic stitching functionality.

      -
      Purpose

      Panoramic +

      Purpose

      Panoramic stitching involves combining a collection of images into a single image.

      Panoramic stitching overview

      The panorama image is created by stitching a collection of several separate image into one large @@ -183,7 +183,7 @@ to capture many images to be stitched into a single panorama image, repeat the steps 5, 6 and 7.

      - +

      Panorama stitching

      The CVFTracker helps to decide when to capture each of the full resolution images using the camera. The images @@ -198,7 +198,7 @@ been captured you can render the stitched image to file, image buffer, CFbsBitmap or image frame using CImagePanorama::RenderL().

      - +

      User Interface

      Provide a good user interface (UI) application for the CImagePanorama is crucial. An example of UI design is described below, which gives you a robust and easy application for generating @@ -212,18 +212,18 @@ direction from left-to-right. The rotation is made around the imagined axis through mobile (axis of rotation in the image). A panorama image covers approximately a 100 degree field of view.

      - +

    • Application Start

      When you launch the application the UI appears as shown in the below diagram.

      - +

      Here the screen area shows the viewfinder image. When you sweep the mobile, several images are captured and then the images are stitched to create a panorama image.

    • Capture a panorama image during tracking

      When you choose to capture a panorama image the UI changes, which is shown in the below diagram.

      - +

      In the above diagram you see three different boxes named 1, 2 and 3 which represent the position of the camera. The blue box representation changes according to the rotation of the mobile phone.

      The boxes shown @@ -307,12 +307,12 @@ They are as follows:

      • The total panorama coverage area is divided into four different image areas:

        - +

      • When you choose to capture a panorama image the following steps are performed. The first image is captured at position 0. The UI looks as follows:

        - +

      • When you rotate the mobile phone clockwise, the blue box moves to the right using the translation @@ -323,18 +323,18 @@ stops. You then known that the next image is captured. At this moment the camera must be steady.

        After second image is captured the blue box is moving again and vibrator is set-on. The UI looks as follows:

        - +

        Again, you rotate the mobile clockwise until the two boxes coincide and vibrator stops; third image then captured. After this, the UI looks as follows:

        - +

        You rotate the mobile phone until the boxes coincide and the fourth (last) image is captured.

        Note: If the mobile phone rotation deviates from chosen (clockwise) direction or translates up and down, the blue box indicates this, and you must correct the mobile phone for the wrong movement.

        At this point the stitched image can be saved or you can reset the camera, to create another panorama image:

        - +

      • Camera diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-60EE22AA-402D-4FC2-9AD1-B3AEF822E8DC.dita --- a/Symbian3/SDK/Source/GUID-60EE22AA-402D-4FC2-9AD1-B3AEF822E8DC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-60EE22AA-402D-4FC2-9AD1-B3AEF822E8DC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,8 +16,8 @@

      Before listening for channel data, you must open the sensor channel.

      - -Create channel condition + +Create channel condition items using CSensrvChannelCondition constructor. These conditions can be used to filter the sensor data feeds. //Comparison values needed for condition diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61056CE2-97BF-5D32-8AC5-E625FBC7D0EC.dita --- a/Symbian3/SDK/Source/GUID-61056CE2-97BF-5D32-8AC5-E625FBC7D0EC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-61056CE2-97BF-5D32-8AC5-E625FBC7D0EC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ of the TXmlEngElement class for a comprehensive list.

      Creating a DOM tree - + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61459132-3AC2-55D3-AC28-D6FA689409E6.dita --- a/Symbian3/SDK/Source/GUID-61459132-3AC2-55D3-AC28-D6FA689409E6.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to invoke a static analysis tool using abld
      Description

      A static analysis tool can be integrated with the Symbian platform build system by using a command line argument to abld. This feature is new in v9.5.

      To invoke a static analysis tool, the –wrap option must be passed to abld. For example:

      abld build armv5 urel –wrap

      The name of the static analysis tool executable is set using the environment variable ABLD_COMPWRAP.

      If ABLD_COMPWRAP has not been set, then using the –wrap option causes abld to report an error and terminate. The exception to this is if the –keepgoing option has additionally been used, for instance:

      abld build armv5 urel –wrap -keepgoing

      In this case abld reports a warning and ignores the –wrap option.

      Log file output folders

      When invoking abld for multiple platforms and/or build variants (debug and release), the analysis tool may generate multiple log files. In order to avoid log files overwriting each other, they need to be generated in different locations. To do this, pass a target folder as an argument to the static analysis tool that includes the environment variable OUTPUT_NAME. abld will replace OUTPUT_NAME with a platform and build-specific folder name. For example, (the following command line assumes that the target folder is passed to the analysis tool using an argument called emitpath):

      set ABLD_COMPWRAP=tool.exe –emitpath c:\analysis\report\$(OUTPUT_NAME)

      abld build armv5 –wrap

      In this example, the log files for the release build are generated in c:\analysis\report\armv5_urel\ and for the debug build in c:\analysis\report\armv5_udeb\.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6163197B-7983-5FB7-9B92-02E490A900FB.dita --- a/Symbian3/SDK/Source/GUID-6163197B-7983-5FB7-9B92-02E490A900FB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6163197B-7983-5FB7-9B92-02E490A900FB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,6 +40,6 @@ from the start of CMyClass.

      -<image href="GUID-29E7942D-A00D-5771-9782-59260965C687_d0e213911_href.png" placement="inline"/> +<image href="GUID-29E7942D-A00D-5771-9782-59260965C687_d0e218909_href.png" placement="inline"/> </fig> </conbody></concept> \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-617A7B7E-DF91-5757-B473-D2E0B665F5E4.dita --- a/Symbian3/SDK/Source/GUID-617A7B7E-DF91-5757-B473-D2E0B665F5E4.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> -<!-- This component and the accompanying materials are made available under the terms of the License -"Eclipse Public License v1.0" which accompanies this distribution, -and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> -<!-- Initial Contributors: - Nokia Corporation - initial contribution. -Contributors: ---> -<!DOCTYPE concept - PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept id="GUID-617A7B7E-DF91-5757-B473-D2E0B665F5E4" xml:lang="en"><title>Application resource tools guide \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-619A607D-CA89-5A98-887D-5B1D2A5F921C.dita --- a/Symbian3/SDK/Source/GUID-619A607D-CA89-5A98-887D-5B1D2A5F921C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -mmp file statements

      always_build_as_arm

      override the build target to build for ARM

      armfpu

      how the compiler is to deal with floating point instructions

      baseaddress

      address to which a DLL will be built and, if possible, loaded

      bytepaircompresstarget

      specifies that the target executable should be compressed using the bytepair algorithm

      capability

      platform security capability

      compresstarget

      specifies that the target executable should be compressed using the Deflate, Huffman+LZ77 algorithm

      debuglibrary

      libraries that are only required in debug builds

      deffile

      override the default linker definition file

      document

      document (non-code) files

      epocheapsize

      minimum and maximum heap sizes for your executable

      epocprocesspriority

      process priority for your .exe executable

      epocstacksize

      stack size for your executable

      exportlibrary

      specify name of .lib file

      exportunfrozen

      create library file without requiring frozen exports

      inflatecompresstarget

      specifies that the target executable should be compressed using the Deflate, Huffman+LZ77 algorithm

      lang

      languages code for the project

      library

      import libraries

      linkas

      give a DLL a different internal name than its filename

      macro

      #defines for the preprocessing of source code

      nocompresstarget

      states that the target executable should not be compressed

      noexportlibrary

      stops the generation of a component's .lib file.

      nostrictdef

      do not apply a u suffix to frozen .def files

      option

      specify additional compiler options

      resource

      resource file for application projects

      secureid

      secure identifier of the executable

      source

      source files

      sourcepath

      location of the project and its workfiles

      srcdbg

      disables the use of optimisation in debug builds

      start bitmap

      bitmaps to build into an .mbm file

      start <platform>...end

      platform-specific section

      start resource

      resource file to build

      start stringtable

      specifies the source file for the string table

      staticlibrary

      static libraries

      strictdepend

      project's dependencies may differ with the variant,

      systeminclude

      system header files directories

      systemresource

      resource file for system projects; from v9.0, use start resource

      target

      file generated by the project

      targetpath

      where the project should be released

      targettype

      kind of project

      uid

      UIDs for a project

      userinclude

      project's header files directories

      vendorid

      vendor identifier

      version

      set the version

      wcharentrypoint

      set the entry point for a standard EXE

      win32_library

      Win32 system libraries to link to in a WINS/WINSCW build

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61BB12AA-7467-5633-8E4C-54D82AFF0F5E_d0e185528_href.jpg Binary file Symbian3/SDK/Source/GUID-61BB12AA-7467-5633-8E4C-54D82AFF0F5E_d0e185528_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61BB12AA-7467-5633-8E4C-54D82AFF0F5E_d0e190524_href.jpg Binary file Symbian3/SDK/Source/GUID-61BB12AA-7467-5633-8E4C-54D82AFF0F5E_d0e190524_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61C340D0-9058-45C2-9A90-4AB8E0612872_d0e41032_href.png Binary file Symbian3/SDK/Source/GUID-61C340D0-9058-45C2-9A90-4AB8E0612872_d0e41032_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-61C340D0-9058-45C2-9A90-4AB8E0612872_d0e41190_href.png Binary file Symbian3/SDK/Source/GUID-61C340D0-9058-45C2-9A90-4AB8E0612872_d0e41190_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6262B90B-3F91-517C-B2FA-749C84CE01DE_d0e106851_href.png Binary file Symbian3/SDK/Source/GUID-6262B90B-3F91-517C-B2FA-749C84CE01DE_d0e106851_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6262B90B-3F91-517C-B2FA-749C84CE01DE_d0e107083_href.png Binary file Symbian3/SDK/Source/GUID-6262B90B-3F91-517C-B2FA-749C84CE01DE_d0e107083_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-628A90FC-35F9-51D0-853E-9BECB3C91B59_d0e276648_href.png Binary file Symbian3/SDK/Source/GUID-628A90FC-35F9-51D0-853E-9BECB3C91B59_d0e276648_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-628A90FC-35F9-51D0-853E-9BECB3C91B59_d0e281487_href.png Binary file Symbian3/SDK/Source/GUID-628A90FC-35F9-51D0-853E-9BECB3C91B59_d0e281487_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6290D35A-7A41-5B9E-882A-E14F6D165ED7_d0e332712_href.png Binary file Symbian3/SDK/Source/GUID-6290D35A-7A41-5B9E-882A-E14F6D165ED7_d0e332712_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6290D35A-7A41-5B9E-882A-E14F6D165ED7_d0e339178_href.png Binary file Symbian3/SDK/Source/GUID-6290D35A-7A41-5B9E-882A-E14F6D165ED7_d0e339178_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-62DF565C-8121-429F-99D0-B5FBDE634AA9.dita --- a/Symbian3/SDK/Source/GUID-62DF565C-8121-429F-99D0-B5FBDE634AA9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-62DF565C-8121-429F-99D0-B5FBDE634AA9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,78 +1,78 @@ - - - - - -Using -long-tap events -

      Long-tap events allow you to specify functions performed when the user -taps and holds the button for a specified period of time. An example of a -long-tap function is fast forwarding in a media player application by tapping -and holding down a button.

      -

      To receive long-tap events, use the class CAknLongTapDetector in the Touch -UI utilities API.

      -

      To enable the handling of long tap events in your CAknButton , -set the flag KAknButtonReportOnLongPress for the button. -When the long tap event starts,CAknButton::ELongPressEvent() is -reported to the button observer (MCoeControlObserver). When -the long tap event ends, CAknButton::ELongPressEndedEvent() is -reported.

      -

      To define the period for which the button needs to be held down for a long-tap -event, use the method SetLongPressInterval() in the class CAknButton.

      -void CMyAppContainer::ConstructL() -{ -… -iButton = CAknButton::NewL( NULL, NULL, NULL, NULL, - -KNullDesC, KNullDesC , KAknButtonReportOnLongPress, 0 ); - -iButton->SetContainerWindowL( *this ); -iButton->SetObserver( this ); -… -} - -void CMyAppContainer::HandleControlEventL( CCoeControl* aControl, - TCoeEvent aEventType ) - { - switch ( aEventType ) - { - -// Button is pressed for a long time - - case CAknButton::ELongPressEvent: - if ( aControl == iButton ) - -{ - - … - -} - - break; - -// Button long press ended - - case CAknButton::ELongPressEndedEvent: - if ( aControl == iButton ) - -{ - - … - -} - - break; - - default: - break; - } - } - - + + + + + +Using +long-tap events +

      Long-tap events allow you to specify functions performed when the user +taps and holds the button for a specified period of time. An example of a +long-tap function is fast forwarding in a media player application by tapping +and holding down a button.

      +

      To receive long-tap events, use the class CAknLongTapDetector in the Touch +UI utilities API.

      +

      To enable the handling of long tap events in your CAknButton , +set the flag KAknButtonReportOnLongPress for the button. +When the long tap event starts, CAknButton::ELongPressEvent is +reported to the button observer (MCoeControlObserver). When +the long tap event ends, CAknButton::ELongPressEndedEvent is +reported.

      +

      To define the period for which the button needs to be held down for a long-tap +event, use the method SetLongPressInterval() in the class CAknButton.

      +void CMyAppContainer::ConstructL() +{ +… +iButton = CAknButton::NewL( NULL, NULL, NULL, NULL, + +KNullDesC, KNullDesC , KAknButtonReportOnLongPress, 0 ); + +iButton->SetContainerWindowL( *this ); +iButton->SetObserver( this ); +… +} + +void CMyAppContainer::HandleControlEventL( CCoeControl* aControl, + TCoeEvent aEventType ) + { + switch ( aEventType ) + { + +// Button is pressed for a long time + + case CAknButton::ELongPressEvent: + if ( aControl == iButton ) + +{ + + … + +} + + break; + +// Button long press ended + + case CAknButton::ELongPressEndedEvent: + if ( aControl == iButton ) + +{ + + … + +} + + break; + + default: + break; + } + } + +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-62E1A29B-E95C-5E5B-969B-410A78114A3B.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-62E1A29B-E95C-5E5B-969B-410A78114A3B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Dynamic Compression
      Overview

      A contacts database will be compressed automatically by the server based on two compression thresholds.

      These thresholds are expressed in terms of the total number of Create, Update or Delete (CUD) operations performed on a contacts database since the last time the database was compressed.

      The first threshold is 16 CUD operations. Once this threshold is reached the server will request an “idle” compression. This type of compression will only result in a compression request (internal to the server) if there are no operations of higher priority carried out by the server within 1 second.

      The second threshold is 64 CUD operations. Once this threshold is reached the server will request an “immediate” compression. This type of compression will always result in a compression request.

      Implementation Considerations

      Clients should still request database compression since short sessions with a database may not allow either of the CUD operation thresholds to be reached.

      There is no requirement to request compression during “bulk” operations (more than 64 CUD operations) but it is recommended to request a compression after any series of CUD operations, to ensure minimum fragmentation of the database.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-631E27DB-97A7-47E2-8FC1-856198435FFF_d0e5956_href.png Binary file Symbian3/SDK/Source/GUID-631E27DB-97A7-47E2-8FC1-856198435FFF_d0e5956_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-631E27DB-97A7-47E2-8FC1-856198435FFF_d0e6077_href.png Binary file Symbian3/SDK/Source/GUID-631E27DB-97A7-47E2-8FC1-856198435FFF_d0e6077_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63AD2899-FDDC-4E3F-8876-C72EC7C194CE_d0e12287_href.png Binary file Symbian3/SDK/Source/GUID-63AD2899-FDDC-4E3F-8876-C72EC7C194CE_d0e12287_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63AD2899-FDDC-4E3F-8876-C72EC7C194CE_d0e12391_href.png Binary file Symbian3/SDK/Source/GUID-63AD2899-FDDC-4E3F-8876-C72EC7C194CE_d0e12391_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63BA04BD-2242-4365-95A1-717569207E92_d0e306657_href.png Binary file Symbian3/SDK/Source/GUID-63BA04BD-2242-4365-95A1-717569207E92_d0e306657_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63BA04BD-2242-4365-95A1-717569207E92_d0e313121_href.png Binary file Symbian3/SDK/Source/GUID-63BA04BD-2242-4365-95A1-717569207E92_d0e313121_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63BB9C30-9103-5900-9FD7-5B45FD78A5D7_d0e45518_href.png Binary file Symbian3/SDK/Source/GUID-63BB9C30-9103-5900-9FD7-5B45FD78A5D7_d0e45518_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63BB9C30-9103-5900-9FD7-5B45FD78A5D7_d0e45676_href.png Binary file Symbian3/SDK/Source/GUID-63BB9C30-9103-5900-9FD7-5B45FD78A5D7_d0e45676_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-63C60154-2A50-5A39-A188-515A607F498B.dita --- a/Symbian3/SDK/Source/GUID-63C60154-2A50-5A39-A188-515A607F498B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-63C60154-2A50-5A39-A188-515A607F498B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@

      The following diagram illustrates how elements are organised within the array buffer:

      - +

      This kind of array is suitable for a small number of elements or for a moderately large but fixed maximum number of elements. It is not suitable diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita --- a/Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -33,7 +33,7 @@ this handle-number. The following diagram helps visualise the situation.

      Thread-death notifier - +

      The following code fragments demonstrate this:

      { diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e184568_href.png Binary file Symbian3/SDK/Source/GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e184568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e189565_href.png Binary file Symbian3/SDK/Source/GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e189565_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-646C2A7A-B90C-5E82-B44F-EA24DDBB1EC5_d0e111407_href.png Binary file Symbian3/SDK/Source/GUID-646C2A7A-B90C-5E82-B44F-EA24DDBB1EC5_d0e111407_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-646C2A7A-B90C-5E82-B44F-EA24DDBB1EC5_d0e111639_href.png Binary file Symbian3/SDK/Source/GUID-646C2A7A-B90C-5E82-B44F-EA24DDBB1EC5_d0e111639_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6482956D-C3A3-5B68-A37F-4250C85B0D82.dita --- a/Symbian3/SDK/Source/GUID-6482956D-C3A3-5B68-A37F-4250C85B0D82.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,53 +0,0 @@ - - - - - -Polymorphic -interface DLLs -

      A polymorphic DLL contains an interface defined by a gate function and -an abstract class with at least one virtual function.

      -

      The polymorphic DLL exports the gate function at ordinal 1, which typically -constructs a concrete class derived from the abstract interface. The virtual -function is then called, and the functions of the class are available.

      -

      Examples of polymorphic DLLs in Symbian platform include ECom plug-ins, -device drivers, Front End Processors, and many more.

      -

      Each type of interface should specify its own UID, which is used as uid2 for -the polymorphic DLL.

      -

      The function responsible for loading a polymorphic DLL should check that -its uid2 corresponds with the expected interface type.

      -

      For polymorphic DLLs, the interpretation of uid3 depends -on the interface type. uid3 may not be required by all interfaces.

      -

      The build process for a polymorphic DLL produces an import library, but -it is not used.

      -
      mmp project specification

      The project -file for a polymorphic DLL must specify the correct target type and UIDs:

        -

      • Specify the TARGETTYPE line -as:

        TARGETTYPE dll

        This -implicitly specifies UID1 correctly. Note that some types -of polymorphic DLLs, have particular support by the build tools, and have -their own different target types. See Polymorphic -DLL targettype summary.

        • -

      • Specify the UID for -the DLL in a UID line:

        UID <UID2> <UID3>

        The UID2 value is defined by the interface which is being implemented. -Some types of polymorphic DLL also require a third UID, but, if so, its meaning -is defined by the DLL.

        • -
      -

      An example of a project file (PolymorphicDLL1.mmp) -for a polymorphic DLL is given below.

      TARGET PolymorphicDLL1.dll -TARGETTYPE dll -UID 0x10004262 0x10004264 -SOURCEPATH . -SOURCE PolymorphicDLL1.cpp -USERINCLUDE . -USERINCLUDE ..\UsingDLLs -SYSTEMINCLUDE \Epoc32\include -LIBRARY euser.lib -EXPORTUNFROZEN       -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-64AC6F53-A9A5-46FD-BCC6-4A9BD8D4DB5C.dita --- a/Symbian3/SDK/Source/GUID-64AC6F53-A9A5-46FD-BCC6-4A9BD8D4DB5C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-64AC6F53-A9A5-46FD-BCC6-4A9BD8D4DB5C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -46,8 +46,8 @@

    • Device Orientation, when the keyboard is opened, resulting in the display being set at an angle to the keyboard. For example, N97.

    - -Create an instance + +Create an instance of CSensorDataCompensator. iCompensator = CSensorDataCompensator::NewL(TSensrvAccelerometerAxisData::KDataTypeId,ESensorCompensateDeviceAndUIOrientation); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-64BDD1DA-6B93-5F45-8CBD-7DBAF92CC4C7_d0e262462_href.png Binary file Symbian3/SDK/Source/GUID-64BDD1DA-6B93-5F45-8CBD-7DBAF92CC4C7_d0e262462_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-64BDD1DA-6B93-5F45-8CBD-7DBAF92CC4C7_d0e267326_href.png Binary file Symbian3/SDK/Source/GUID-64BDD1DA-6B93-5F45-8CBD-7DBAF92CC4C7_d0e267326_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-64D2B0E2-BB5D-4009-ACE5-7A3503016341.dita --- a/Symbian3/SDK/Source/GUID-64D2B0E2-BB5D-4009-ACE5-7A3503016341.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-64D2B0E2-BB5D-4009-ACE5-7A3503016341.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Troubleshooting TipsThis section addresses the basic differences in the way things are done in Symbian Platform and in Linux. -
    Symbian +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-1"> <title>Symbian directory structure

    In Symbian platform, project source files are arranged based on the directory pattern shown below.

    @@ -36,7 +36,7 @@

    The developer can choose whether to follow these tips.

    -
    EXPORT_C, +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-2"> <title>EXPORT_C, DEF file and ordinal numbers

    This applies only for the DLL target type. If a DLL wants to export an API, the code definition should start with the macro EXPORT_C.

    // Declaration @@ -94,7 +94,7 @@ return something; }
    -
    <codeph>dlsym()</codeph> or <codeph>g_module_symbol()</codeph> +
    <codeph>dlsym()</codeph> or <codeph>g_module_symbol()</codeph>

    Since DLL entry points are not exported by name, DLL symbol lookup functions do not work on Symbian platform. For more information about alternatives suggested on Symbian platform, see Dynamic @@ -105,7 +105,7 @@ symbol parameter (refer the library's list of exports, the DEF file for the function's ordinal number):

    dlsym(&handle, "foo")

    needs to be changed to:

    dlsym (&handle, "3")
    -
    Problem with +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-4"><title>Problem with a variable list of arguments in macros

    This section suggests a way to overcome the problems faced when macros with a variable list of arguments are used.

    #define DEBUG(a,...)

    The above statement @@ -114,14 +114,14 @@ static inline void _DEBUG (const char *a, ...) { }

    -
    Keep +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-5"> <title>Keep changes to OSS to a minimum

    While porting the OSS code, keep the changes to the OSS code as few as possible. The OSS code is already tested and used by a bigger community, and is unlikely to have any compilation errors or major logical errors. In many cases code changes that are necessary brings potential logical flaws to the OSS port. Minimum changes to the OSS code while porting also helps in merging to the new OSS.

    -
    Exporting +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-6"> <title>Exporting variables from a DLL

    Exporting data from a DLL is not allowed in Symbian platform . The following pattern can be used:

    1. Do not export global @@ -140,13 +140,13 @@ IMPORT_C int* GlbData (); #define globalVal (*GlbData())

    -
    Application +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-7"> <title>Application is not loaded

    The absence of the dependent libraries could be one of the reasons for the application not to load in the mobile device. On the target device, Symbian platform looks for libraries in c:\sys\bin or in z:\sys\bin.

    Do make sure that all the libraries are present in either of the above-mentioned libraries.

    -
    Capabilities +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-8"> <title>Capabilities not known

    Capabilities are specified in the MMP file. The primary information source is the P.I.P.S. API reference documentation. If problems with capabilities remain, one known method to find the capability @@ -155,7 +155,7 @@ for release code it is good practice to give a valid capability in the MMP file in order to have the application successfully signed. The following is a sample of a capability error found in the [Debug Messages] window.

    *PlatSec* ERROR - Capability check failed - Process hellogst.exe[10015942]0001 was checked by Thread c32exe.exe[101f7989]0001::ESock_IP and was found to be missing the capabilities: NetworkServices.
    -
    Environment +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-9"> <title>Environment variables

    At the moment, environment variables are not completely supported in Symbian C++. Therefore be wary of using library functions like getenv() which work on environment variables. Make sure the library initialization routine @@ -166,7 +166,7 @@ { setenv ("JPEGMEM ", "XXXXX", 1); }

    -
    Assembly +<section id="GUID-77D7347D-8DEC-45D0-A677-8FDBDFB8FF81-GENID-1-10-1-13-1-1-5-1-3-1-9-1-3-10"> <title>Assembly code

    The syntax for inline assembly code is different in Symbian platform. The following is a code snippet of assembly code syntax in Symbian platform.

    EXPORT_C __NAKED__ TUint16 TTemplate::Register16(TUint anAddr) @@ -180,7 +180,7 @@ }

    In common practice the assembly code has the extension .CIA in Symbian platform, whereas in Linux the assembly code has the extension .S.

    -
    Glossary +
    Glossary

    The following table lists terms used in Linux and their approximate equivalents in Symbian platform:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-652DA0DD-AB1D-58A4-A6D2-27B5BAA506FF.dita --- a/Symbian3/SDK/Source/GUID-652DA0DD-AB1D-58A4-A6D2-27B5BAA506FF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-652DA0DD-AB1D-58A4-A6D2-27B5BAA506FF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ content, first flip the surface and then rotate it by 180°.

    Mirroring - +

    The following example code assumes that the surface already exists. Call TSurfaceConfiguration::SetFlip() to flip the surface, then call TSurfaceConfiguration::SetOrientation() to diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65365507-5773-4FE9-B63E-450CC2DD7570_d0e40462_href.png Binary file Symbian3/SDK/Source/GUID-65365507-5773-4FE9-B63E-450CC2DD7570_d0e40462_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65365507-5773-4FE9-B63E-450CC2DD7570_d0e40620_href.png Binary file Symbian3/SDK/Source/GUID-65365507-5773-4FE9-B63E-450CC2DD7570_d0e40620_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-656E2E4F-D7C5-5FDC-B1E6-DFA5970BB3F0_d0e286968_href.jpg Binary file Symbian3/SDK/Source/GUID-656E2E4F-D7C5-5FDC-B1E6-DFA5970BB3F0_d0e286968_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-656E2E4F-D7C5-5FDC-B1E6-DFA5970BB3F0_d0e291799_href.jpg Binary file Symbian3/SDK/Source/GUID-656E2E4F-D7C5-5FDC-B1E6-DFA5970BB3F0_d0e291799_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65885916-0242-5DDB-9D88-EB214096C4DF_d0e308626_href.png Binary file Symbian3/SDK/Source/GUID-65885916-0242-5DDB-9D88-EB214096C4DF_d0e308626_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65885916-0242-5DDB-9D88-EB214096C4DF_d0e315096_href.png Binary file Symbian3/SDK/Source/GUID-65885916-0242-5DDB-9D88-EB214096C4DF_d0e315096_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-659E2A30-C2E0-4E5A-AA9F-50EBEC7E9579.dita --- a/Symbian3/SDK/Source/GUID-659E2A30-C2E0-4E5A-AA9F-50EBEC7E9579.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-659E2A30-C2E0-4E5A-AA9F-50EBEC7E9579.dita Tue Jul 20 12:00:49 2010 +0100 @@ -67,7 +67,7 @@

    Panes - +
    Using windows and panes in applications

    Windows and panes diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e77512_href.png Binary file Symbian3/SDK/Source/GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e77512_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e77550_href.png Binary file Symbian3/SDK/Source/GUID-65A4BA91-579F-5B9B-ACC1-D3D9B1F233B7_d0e77550_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-65E9C040-AAB6-5C1E-9724-8828DADFC741.dita --- a/Symbian3/SDK/Source/GUID-65E9C040-AAB6-5C1E-9724-8828DADFC741.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-65E9C040-AAB6-5C1E-9724-8828DADFC741.dita Tue Jul 20 12:00:49 2010 +0100 @@ -75,7 +75,7 @@ Figure 1. RPositionServer and RPositioner with basic position data classes - +

    Platform security capabilities

    Applications must have the Location capability to use the Location Acquisition diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66470976-7B8B-582B-B32B-4010C95052FF.dita --- a/Symbian3/SDK/Source/GUID-66470976-7B8B-582B-B32B-4010C95052FF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Compressed Unicode resource format

    This page describes the compressed resource file format introduced from Symbian OS v7.0.

    This format compresses, for those cases where actual benefit is yielded by compressing, Unicode text-strings in the resource data by using the Standard Compression Scheme for Unicode, described in http://www.unicode.org/unicode/reports/tr6/tr6-3.2.html.

    Resource files in this format are generated by the resource compiler from Symbian OS v7.0.

    Number of bytes

    Description

    16

    These bytes store the resource file’s UIDs.

    The first twelve bytes consist of three four-byte integers (in little-endian byte order) followed by a four-byte CRC checksum generated from those three integers.

    The first UID is always 0x101f4a6b.

    The second and third UIDs can be specified on rcomp's command-line. By default, the second UID is zero and the third UID is the resource file’s “offset”, i.e. the twenty-bit integer generated from the resource file’s name. These twenty bits are stored in the least significant twenty bits of the third UID; the most significant twelve bits are all zero.

    1

    This byte stores flags. Currently, there is only one flag defined, which is the lowest bit of the byte (0x01). This flag indicates whether the third UID is actually the resource file’s “offset” (see the row above). The bit is set to non-zero if it is, and zero if it is not.

    2

    This two-byte integer (in little-endian byte order) stores the size in bytes of the largest resource in the file (that is, the size when uncompressed).

    number_of_resources/8 (rounded up to the nearest whole number)

    This is a bit-array (one bit for each resource) storing which resources contain compressed Unicode. The least significant bit of the first byte corresponds to the first resource, the next-to-least significant bit of the first byte corresponds to the second resource, etc. A bit being set to non-zero indicates that the corresponding resource contains compressed Unicode, a zero bit indicates that it does not contain compressed Unicode.

    [any]

    This contains the data for all the resources stored in order, one after another with no byte-padding between them. The format of the data for each resource is in one of two possible formats depending on whether the resource contains compressed Unicode. The bit-array described in the row above indicates which resources contain compressed Unicode. Note that resources in either of these two formats may contain uncompressed Unicode: this is because compressing Unicode using the Standard Compression Scheme for Unicode can, in certain conditions, yield larger output than input, hence such Unicode text-strings will not be compressed as it would not be beneficial. Extra padding bytes (arbitrarily 0xab) are inserted in front of any uncompressed Unicode text-string that would otherwise not be aligned on a two-byte boundary relative to the start of that resource’s data, once the resource has been uncompressed.

    Resources not containing compressed Unicode:

    The binary data of these resources is laid out exactly as specified in the resource definition (although note the comment about padding bytes above).

    Resources containing compressed Unicode:

    The binary data of these resources is split up into one or more sequences, or “runs”, alternating between compressed Unicode and other material.

    Each run is preceded by an integer containing the length in bytes of the run (not including the byte(s) it occupies itself). The run-length occupies a single byte if it is less than 128, otherwise it occupies two bytes (in little-endian byte order), with the most significant bit of the first byte set to non-zero to indicate that the run-length occupies two bytes. Only the length of the first run may be zero (which would be the case if the resource does not start with compressed Unicode).

    (number_of_resources+1)*2

    This is the resource index, which is a series of two-byte integers (in little-endian byte order), one for each resource in the resource file, each storing the file-position of that resource’s data (see row immediately above).

    This is followed by a two-byte integer (in little-endian byte order), which is the file-position one byte past the end of the last resource’s data. This is so that working out the length of a resource’s data is trivially done by subtracting the file-position stored in that resource’s index-entry from the file-position in the next index-entry.

    This last entry in the resource index, which stores the file-position one byte past the end of the last resource’s data, can also be thought of as storing the file-position of the start of the resource index.
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-669190F8-3BE9-58FC-B689-00F06FDAD74D_d0e363158_href.png Binary file Symbian3/SDK/Source/GUID-669190F8-3BE9-58FC-B689-00F06FDAD74D_d0e363158_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-669190F8-3BE9-58FC-B689-00F06FDAD74D_d0e382307_href.png Binary file Symbian3/SDK/Source/GUID-669190F8-3BE9-58FC-B689-00F06FDAD74D_d0e382307_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66BBA81D-2488-50B8-8822-43AAAA139DDE.dita --- a/Symbian3/SDK/Source/GUID-66BBA81D-2488-50B8-8822-43AAAA139DDE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-66BBA81D-2488-50B8-8822-43AAAA139DDE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -38,7 +38,7 @@ For information on each class see the Cryptography API Reference material.

    The inheritance hierarchy for the RRandomSession and CSystemRandom classes - +

    How to use TRandom

    TRandom is a cryptographically stong random number generator. Its declaration is:

    class TRandom { diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66C1F45B-FA94-5724-AD8F-371EAE92B7E9.dita --- a/Symbian3/SDK/Source/GUID-66C1F45B-FA94-5724-AD8F-371EAE92B7E9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -DEBUGGABLE_UDEBONLY

    DEBUGGABLE_UDEBONLY

    Use the DEBUGGABLE_UDEBONLY statement to mark only the debug version of application to be debugged using the run-mode debug API.

    If both DEBUGGABLE_UDEBONLY and debuggable are in an .mmp file, the behaviour will follow as DEBUGGABLE_UDEBONLY.

    The following examples show the different scenarios when using the keywords debuggable and DEBUGGABLE_UDEBONLY:

    • Perform the following steps using the keyword debuggable:

      1. Add keyword debuggable into helloworld.mmp file

      2. Build helloworld.mmp

      3. Execute READIMAGE to dump helloworld.exe (release and debug version).

        The expected result is 0x00000800, which means the executable file is debuggable.

    • Perform the following steps using the keyword DEBUGGABLE_UDEBONLY:

      1. Add keyword DEBUGGABLE_UDEBONLY into helloworld.mmp file

      2. Build helloworld.mmp

      3. Execute READIMAGE to dump helloworld.exe (release and debug version).

        The expected result is that the debug version of the executable file is debuggable but, the release executable file is not debuggable.

    • Perform the following steps using both DEBUGGABLE_UDEBONLY and debuggable keywords:

      1. Add both DEBUGGABLE_UDEBONLY and debuggable keywords into helloworld.mmp file.

      2. Build helloworld.mmp file

      3. Execute READIMAGE to dump helloworld.exe (release and debug version).

        The expected result is that the debug version of the executable file is debuggable but, the release executable file is not debuggable.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66E0B7F2-DEB4-5326-9DE0-5C0E253568AF_d0e351163_href.png Binary file Symbian3/SDK/Source/GUID-66E0B7F2-DEB4-5326-9DE0-5C0E253568AF_d0e351163_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66E0B7F2-DEB4-5326-9DE0-5C0E253568AF_d0e380156_href.png Binary file Symbian3/SDK/Source/GUID-66E0B7F2-DEB4-5326-9DE0-5C0E253568AF_d0e380156_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-66EFFCF5-581A-4EE7-B784-8087A1081B6D.dita --- a/Symbian3/SDK/Source/GUID-66EFFCF5-581A-4EE7-B784-8087A1081B6D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-66EFFCF5-581A-4EE7-B784-8087A1081B6D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,33 +12,29 @@ Title pane

    The Title pane displays a context-dependent application -title or state name. Title pane in Home screen view can work with touch down -and release but by default, there is no functionality.

    - +title or state name.

    + Title pane - +

    • Typically, the title text is the descriptive name of the current main pane view.

      • -

    • In an application title pane, the title text is typically -the application name.

      • -

    • In the home screen, the Title pane may contain -an operator logo (left-aligned in the area available) instead of the operator -name as text.

      • +

    • In an application idle state, the title text is typically the application +name.

      • +

    • In the idle state, the Title pane may contain +an operator logo (left-aligned in the area available) instead +of the operator name as text.

    -
    Using -the title pane in applications

    The API to use for the title pane -component is the Title pane API. For observing title pane touch events, use -the Title Pane Touch Observer API.

    To use a title pane in your application, -create an instance of the CAknTitlePane class.

    Use -the CAknTitlePane::SetTextL() method to set the title pane -text and display it. To set the text to scroll if it does not fit the title -pane text area, set the flag aScroll to ETrue. -To set the text to the default (name of the application), use the CAknTitlePane::SetTextToDefault() method.

    Use -the CAknTitlePane::SetPicture() method to display a picture -in the title pane. To set the icon from a file, use the CAknTitlePane::SetPictureFromFileL() method. -Alternatively, to set a small icon to be displayed together with text, use -the CAknTitlePane::SetSmallPicture() method.

    To set -the title pane contents from a resource file, use the CAknTitlePane::SetFromResourceL() method.

    +
    Using the title pane +in C++ applications

    The API to use for the title pane component +is the Title +pane API. For observing title pane touch events, use the Title +Pane Touch Observer API.

    To use a title pane in your application, +create an instance of the class CAknTitlePane.

    Use the method SetTextL() in the class CAknTitlePane to set the title pane text and display it. To set the text to scroll +if it does not fit the title pane text area, set the flag aScroll to ETrue. +To set the text to the default (name of the application), use the method SetTextToDefault().

    Use the method SetPicture() to display a picture in the title pane. +To set the icon from a file, use the method SetPictureFromFileL(). Alternatively, to set a small +icon to be displyed together with text, use the method SetSmallPicture().

    To set the title pane contents +from a resource file, use the method SetFromResourceL().

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6740A668-33A2-52B1-9416-E9F21591D16C_d0e168995_href.jpg Binary file Symbian3/SDK/Source/GUID-6740A668-33A2-52B1-9416-E9F21591D16C_d0e168995_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6740A668-33A2-52B1-9416-E9F21591D16C_d0e174009_href.jpg Binary file Symbian3/SDK/Source/GUID-6740A668-33A2-52B1-9416-E9F21591D16C_d0e174009_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-676D1493-0035-4AD3-A0E5-A207B25809E4.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-676D1493-0035-4AD3-A0E5-A207B25809E4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,145 @@ + + + + + +Time +Zone Services Overview +
    Purpose

    Interfaces +within Time Zone Services are used to enable client applications to make updates +to system TZ data, receive notification of time changes, and manage user-defined +TZ data. Conversion services enable a client to convert time between Universal +Time Coordinated and any other time.

    +
    Key concepts/termsThe following terms are used throughout +Time Zone Services documentation:

    + +
    P&S
    +

    Publish and Subscribe.

    +     + + + + +
    System TZ data
    +

    Refers to the time zone database found in the TZ Server component and +the TZ localization resources found in the TZ Localization component.

    +     + +
    TZID
    +

    Refers to the time zone database found in the TZ Server component and +the TZ localization resources found in the TZ Localization component.

    +     + +
    TZ rules data
    +

    Refers to the TZ rules found in the TZ database, the TZ rules that +define the current/system TZ and the user-defined TZ rules.

    +     + +
    User-defined TZ data
    +

    The TZ rules and TZ names (city name, region name and long/short standard +time name and long/short daylight time names). User-defined TZ data may be +added by the user of the device.

    +     + +
    UTC
    +

    Universal Time Coordinated.

    +     +

    +
    Architectural relationships

    Alarm Server and Calendar +Server components depend on the latest TZ rules information. When notified +of changes to TZ rules data these components update their TZ-dependent data. +TZ conversion rules are used to convert between UTC and a time in the past, +present or future, for any time zone.

    Time zone conversion allows you +to set the device time zone and to convert time between UTC and any time, +past, present or future, for any time zone, as long as a rule exists for the +conversion.

    +
    Time Zone Services interfaces

    The following classes +form the main interface to Time Zone Services:

    + + + +

    Interface

     +

    Description

     +     + + + +

    CTzUserData

     +

    Allows a client to manage user-defined time zones.

     +     + +

    CTzUserNames

     +

    Contains the names for a user-defined time zone.

     +     + +

    CTzRules

     +

    Encapsulates a collection of time zone rules

     +     + +

    CTzId

     +

    Contains a time zone identifier.

     +     + +

    RTz

     +

    Converts between UTC time and local time, and sets the current local +time zone.

     +     + +

    CTzConverter

     +

    Provides client-side caching for conversions in the local time zone.

     +     + + +

    The following interfaces are also used:

      +

    • SWI service - see System TZ Data Update

      • +

    • Resource files - see User-defined TZ Data

      • +

    • Publish and Subscribe - see TZ Data Change Notification

      • +

    System TZ data update

    The system TZ data can be updated +at run-time. The installation mechanism uses the standard SWI service to install +a SIS file containing the updated TZ data onto a device.

    Once the system +TZ data has been updated using the SIS file, the device will automatically +make use of the updated data. This includes updating any cached data managed +by Symbian platform components and notifying all registered clients of the +system TZ data change.

    User-defined TZ data

    CTzUserData provides +functions to create, read, update or delete user-defined TZ data. The API +also allows the TZIDs for all existing user-defined TZ data to be determined. +

    CTzUserNames is used to contain the names for user-defined +time zones. These include long/short standard time names, long/short daylight +time names, city name and region name.

    TZID is a time zone identifier +contained in the CTzId class. There are two components to +a TZID: a numeric identifier and a name identifier.

    TZ data change +notification

    The Time Zone Services APIs support several Publish +and Subscribe (P&S) properties, some of which are described below. Clients +can attach and subscribe to these properties to allow them to be notified +of TZ data changes.

    The Calendar uses the callback API MCalChangeCallBack2 for +asynchronous change notification.

      +

    • Publish and Subscribe - The NTzUpdate namespace +contains a property category and property keys. The property key ETzRulesChange is +used to inform clients of changes to:

        +

      • the system TZ database

        • +

      • current and system TZ rules

        • +

      • user-defined rules.

        • +

      The property key ETzNamesChange is responsible for +changes to the localized system TZ names and non-localized user-defined TZ +names.

      • +

    • Alarm Server client - The Alarm Server supports fixed UTC time +and floating local time to express the expiry time of an alarm. The TZ Server +then recalculates and sets the current UTC offset.

      See System +Time and Locale Changes.

      • +

    • Calendar client - The Calendar API allows a client to be notified +of changes to Calendar entries.

      For more information, see Callback +Interfaces.

      • +
    +
    See also
      +

    • Time zone services +tutorials

      • +

    • Time Zone Conversion +Overview

      • +
    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-22-1-1-4-1-1-3-1.dita --- a/Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-22-1-1-4-1-1-3-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -Feature Management OverviewThis section gives an overview of feature management, what it does, how it works, how to use it and links to relevant links.
    Purpose

    A feature is a piece of functionality that is shipped with the device, but which can be disabled or enabled.

    Feature management is used to manage the enabling and disabling of these features and associated activities for example to provide a means of allowing the system to know if a feature is enabled or not.

    Architecture

    The feature management system consists of a server and two dll files.

    The feature management system has a standard client server architecture. The server is the feature management server and the dll files provide a series of APIs with which the client can communicate with the server.

    Description

    As described above, the functionality of feature management can be broken into two groups: the server and the dll files.

    The feature manager server: this comes as an executable called featmgrserver.exe.

    • This does all the feature management work that is keeping track of the status of each feature.

    The communication to the feature management server is carried out via the two dll files i.e. featdiscovery.dll and featmgr.dll.

    • Provide a means of telling the client when a change to the status of a feature has occurred.

    • Allows the client to specify which feature is to be enabled or disabled.

    • Allows the client to add or delete features.

    Components

    The following components make up the feature management collection.

    • Feature Discovery

      featdiscovery.dll

      Provides the APIs that provide only a subset of what can be provided by feature management.

      It provides the functionality for TFeatureSet and CFeatureDiscovery.

    • Feature Manager

      featmgr.dll

      Provides the APIs that allow the client to carry out the full functionality available with feature management.

      It provides the functionality for RFeatMgrClient, RFeatureControl, MFeatureObserver and CFeatureNotifier.

    • Feature Manager Server

      featmgrserver.exe

      Performs all the actual operations and maintains details about features.

    Feature Manager - Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-22-1-1-4-1-1-4-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-22-1-1-4-1-1-4-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -Feature Management OverviewThis section gives an overview of feature management, what it does, how it works, how to use it and links to relevant links.
    Purpose

    A feature is a piece of functionality that is shipped with the device, but which can be disabled or enabled.

    Feature management is used to manage the enabling and disabling of these features and associated activities for example to provide a means of allowing the system to know if a feature is enabled or not.

    Architecture

    The feature management system consists of a server and two dll files.

    The feature management system has a standard client server architecture. The server is the feature management server and the dll files provide a series of APIs with which the client can communicate with the server.

    Description

    As described above, the functionality of feature management can be broken into two groups: the server and the dll files.

    The feature manager server: this comes as an executable called featmgrserver.exe.

    • This does all the feature management work that is keeping track of the status of each feature.

    The communication to the feature management server is carried out via the two dll files i.e. featdiscovery.dll and featmgr.dll.

    • Provide a means of telling the client when a change to the status of a feature has occurred.

    • Allows the client to specify which feature is to be enabled or disabled.

    • Allows the client to add or delete features.

    Components

    The following components make up the feature management collection.

    • Feature Discovery

      featdiscovery.dll

      Provides the APIs that provide only a subset of what can be provided by feature management.

      It provides the functionality for TFeatureSet and CFeatureDiscovery.

    • Feature Manager

      featmgr.dll

      Provides the APIs that allow the client to carry out the full functionality available with feature management.

      It provides the functionality for RFeatMgrClient, RFeatureControl, MFeatureObserver and CFeatureNotifier.

    • Feature Manager Server

      featmgrserver.exe

      Performs all the actual operations and maintains details about features.

    Feature Manager - Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-26-1-1-4-1-1-3-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-26-1-1-4-1-1-3-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,13 @@ + + + + + +Feature Management OverviewThis section gives an overview of feature management, what it does, how it works, how to use it and links to relevant links.
    Purpose

    A feature is a piece of functionality that is shipped with the device, but which can be disabled or enabled.

    Feature management is used to manage the enabling and disabling of these features and associated activities for example to provide a means of allowing the system to know if a feature is enabled or not.

    Architecture

    The feature management system consists of a server and two dll files.

    The feature management system has a standard client server architecture. The server is the feature management server and the dll files provide a series of APIs with which the client can communicate with the server.

    Description

    As described above, the functionality of feature management can be broken into two groups: the server and the dll files.

    The feature manager server: this comes as an executable called featmgrserver.exe.

    • This does all the feature management work that is keeping track of the status of each feature.

    The communication to the feature management server is carried out via the two dll files i.e. featdiscovery.dll and featmgr.dll.

    • Provide a means of telling the client when a change to the status of a feature has occurred.

    • Allows the client to specify which feature is to be enabled or disabled.

    • Allows the client to add or delete features.

    Components

    The following components make up the feature management collection.

    • Feature Discovery

      featdiscovery.dll

      Provides the APIs that provide only a subset of what can be provided by feature management.

      It provides the functionality for TFeatureSet and CFeatureDiscovery.

    • Feature Manager

      featmgr.dll

      Provides the APIs that allow the client to carry out the full functionality available with feature management.

      It provides the functionality for RFeatMgrClient, RFeatureControl, MFeatureObserver and CFeatureNotifier.

    • Feature Manager Server

      featmgrserver.exe

      Performs all the actual operations and maintains details about features.

    Feature Manager + Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-26-1-1-4-1-1-4-1-4-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-67D0F837-65EE-54FE-B8D6-E5226CB9D8C9-GENID-1-10-1-26-1-1-4-1-1-4-1-4-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,13 @@ + + + + + +Feature Management OverviewThis section gives an overview of feature management, what it does, how it works, how to use it and links to relevant links.
    Purpose

    A feature is a piece of functionality that is shipped with the device, but which can be disabled or enabled.

    Feature management is used to manage the enabling and disabling of these features and associated activities for example to provide a means of allowing the system to know if a feature is enabled or not.

    Architecture

    The feature management system consists of a server and two dll files.

    The feature management system has a standard client server architecture. The server is the feature management server and the dll files provide a series of APIs with which the client can communicate with the server.

    Description

    As described above, the functionality of feature management can be broken into two groups: the server and the dll files.

    The feature manager server: this comes as an executable called featmgrserver.exe.

    • This does all the feature management work that is keeping track of the status of each feature.

    The communication to the feature management server is carried out via the two dll files i.e. featdiscovery.dll and featmgr.dll.

    • Provide a means of telling the client when a change to the status of a feature has occurred.

    • Allows the client to specify which feature is to be enabled or disabled.

    • Allows the client to add or delete features.

    Components

    The following components make up the feature management collection.

    • Feature Discovery

      featdiscovery.dll

      Provides the APIs that provide only a subset of what can be provided by feature management.

      It provides the functionality for TFeatureSet and CFeatureDiscovery.

    • Feature Manager

      featmgr.dll

      Provides the APIs that allow the client to carry out the full functionality available with feature management.

      It provides the functionality for RFeatMgrClient, RFeatureControl, MFeatureObserver and CFeatureNotifier.

    • Feature Manager Server

      featmgrserver.exe

      Performs all the actual operations and maintains details about features.

    Feature Manager + Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6820BB9E-F0B9-4493-A4C3-686238527C9B_d0e60647_href.png Binary file Symbian3/SDK/Source/GUID-6820BB9E-F0B9-4493-A4C3-686238527C9B_d0e60647_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6820BB9E-F0B9-4493-A4C3-686238527C9B_d0e60790_href.png Binary file Symbian3/SDK/Source/GUID-6820BB9E-F0B9-4493-A4C3-686238527C9B_d0e60790_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-68417158-D625-56BF-BDD5-BE49A7651CED.dita --- a/Symbian3/SDK/Source/GUID-68417158-D625-56BF-BDD5-BE49A7651CED.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-68417158-D625-56BF-BDD5-BE49A7651CED.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Audio Output Streaming Overview

    This document provides an overview of Audio Output Streaming.

    Purpose

    Audio Output Streaming is the interface to streaming sampled audio data to the low level audio controller part of the Multimedia Framework (MMF).

    Audio Output Streaming Library Details

    The DLL that provides the functionality and the library to which your code must link is identified below.

    DLL LIB Short Description

    mediaclientaudiostream.dll

    mediaclientaudiostream.lib

    These files are used for implementing Audio Output Streaming.

    Architectural Relationship

    How the Audio Output Streaming classes interact with other components of MMF is shown below:

    Audio output streaming overview -
    Description

    Streamed audio data is sent and received incrementally. This means:

    • sound clips sent to the low level audio controller (audio play) can be sent as they arrive rather than waiting until the entire clip is received.

      The user of the API should maintain the data fragments in a queue before sending them to the server. If the user attempts to send data faster than the server can receive it, the excess data fragments are maintained in another client side queue (invisible to the user), whose elements are references to the buffers passed to it. The server notifies the client using a callback each time it has received a data fragment. This indicates to the client that the data fragment can be deleted.

    • sound clips that are being captured by the low level audio controller (audio record) can be read incrementally without having to wait until audio capture is complete.

      The low level audio controller maintains the received buffers where it can place the audio data that is being captured. The client uses a read function to read the received data into destination descriptors.

    The client is also notified (for audio play and record) when the stream is opened and available for use (opening takes place asynchronously), and when the stream is closed.

    This API can only be used to stream audio data, with the data being stored or sourced from a descriptor. Client applications must ensure that the data is in 16 bit PCM format as this is the only format supported. The API does not support mixing. A priority mechanism is used to control access to the sound device by more than one client.

    Key Audio Output Streaming Classes

    The functionality provided by Audio Output Streaming is contained within the CMdaAudioOutputStream class.

    Using Audio Output Streaming

    Clients can use Audio Output Streaming to:

    • Open, set audio properties, write to and close the audio stream.

    See Also

    Audio Output Streaming Tutorial

    \ No newline at end of file +
    Description

    Streamed audio data is sent and received incrementally. This means:

    • sound clips sent to the low level audio controller (audio play) can be sent as they arrive rather than waiting until the entire clip is received.

      The user of the API should maintain the data fragments in a queue before sending them to the server. If the user attempts to send data faster than the server can receive it, the excess data fragments are maintained in another client side queue (invisible to the user), whose elements are references to the buffers passed to it. The server notifies the client using a callback each time it has received a data fragment. This indicates to the client that the data fragment can be deleted.

    • sound clips that are being captured by the low level audio controller (audio record) can be read incrementally without having to wait until audio capture is complete.

      The low level audio controller maintains the received buffers where it can place the audio data that is being captured. The client uses a read function to read the received data into destination descriptors.

    The client is also notified (for audio play and record) when the stream is opened and available for use (opening takes place asynchronously), and when the stream is closed.

    This API can only be used to stream audio data, with the data being stored or sourced from a descriptor. Client applications must ensure that the data is in 16 bit PCM format as this is the only format supported. The API does not support mixing. A priority mechanism is used to control access to the sound device by more than one client.

    Key Audio Output Streaming Classes

    The functionality provided by Audio Output Streaming is contained within the CMdaAudioOutputStream class.

    Using Audio Output Streaming

    Clients can use Audio Output Streaming to:

    • Open, set audio properties, write to and close the audio stream.

    See Also

    Audio Output Streaming Tutorial

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-687AFC9D-ADB7-5190-A535-C54B835825DD.dita --- a/Symbian3/SDK/Source/GUID-687AFC9D-ADB7-5190-A535-C54B835825DD.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Application resource tools reference \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-68B999C2-0993-4804-9624-42C3D88BE5C7.dita --- a/Symbian3/SDK/Source/GUID-68B999C2-0993-4804-9624-42C3D88BE5C7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-68B999C2-0993-4804-9624-42C3D88BE5C7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@ architecture

    The following image illustrates the components of the view architecture approach.

    -View architecture classes +View architecture classes

    Symbian platform applications that follow the view architecture require:

    • a UI diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-68BBBA98-BDF7-4562-8168-5E90C73ADCF8.dita --- a/Symbian3/SDK/Source/GUID-68BBBA98-BDF7-4562-8168-5E90C73ADCF8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-68BBBA98-BDF7-4562-8168-5E90C73ADCF8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ their greatest threat, and allows intruders to try different attack methods against the device. The figure below illustrates the most common methods of attack against mobile devices.

      -Mobile device and common attack methods +Mobile device and common attack methods

      Due to the nature of mobile devices, including the potential vulnerabilities mentioned above, you should consider the following points when designing your application:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-68E3609C-3429-5B1C-B8D9-C0EBBACEF357_d0e188429_href.png Binary file Symbian3/SDK/Source/GUID-68E3609C-3429-5B1C-B8D9-C0EBBACEF357_d0e188429_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-68E3609C-3429-5B1C-B8D9-C0EBBACEF357_d0e193400_href.png Binary file Symbian3/SDK/Source/GUID-68E3609C-3429-5B1C-B8D9-C0EBBACEF357_d0e193400_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6913F58F-FDA1-4708-B03E-16AF6C545E5B_d0e1390_href.jpg Binary file Symbian3/SDK/Source/GUID-6913F58F-FDA1-4708-B03E-16AF6C545E5B_d0e1390_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6913F58F-FDA1-4708-B03E-16AF6C545E5B_d0e1394_href.jpg Binary file Symbian3/SDK/Source/GUID-6913F58F-FDA1-4708-B03E-16AF6C545E5B_d0e1394_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-694C7416-927E-58F7-B010-CA55D2FFA88F_d0e189143_href.png Binary file Symbian3/SDK/Source/GUID-694C7416-927E-58F7-B010-CA55D2FFA88F_d0e189143_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-694C7416-927E-58F7-B010-CA55D2FFA88F_d0e194114_href.png Binary file Symbian3/SDK/Source/GUID-694C7416-927E-58F7-B010-CA55D2FFA88F_d0e194114_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6971B0A2-F79B-4E05-8AF3-BB1FC1932A22.dita --- a/Symbian3/SDK/Source/GUID-6971B0A2-F79B-4E05-8AF3-BB1FC1932A22.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6971B0A2-F79B-4E05-8AF3-BB1FC1932A22.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,46 +10,42 @@ Capabilities -

      Capabilities allow the Symbian platform to control access by applications -to the functionalities provided by the platform APIs. Access to capabilities -is determined by the device configuration and how the application has been -signed. Capabilities can be divided into four categories:

      +

      Capabilities allow the Symbian platform to control access by +applications to the functionalities provided by the platform APIs. +Access to capabilities is determined by the device configuration and +how the application has been signed. Capabilities can be divided into +four categories:

        -

      • user capabilities: LocalServices, NetworkServices, ReadUserData, WriteUserData, UserEnvironment and, Location

        -
        • -

      • system capabilities: PowerMgmt, ProtServ, ReadDeviceData, SurroundingsDD, SwEvent, TrustedUI, WriteDeviceData

        -
        • -

      • restricted capabilities: CommDD, DiskAdmin, MultimediaDD and NetworkControl

        -
        • -

      • device manufacturer capabilities: AllFiles, DRM and TCB

        -
        • +

      • user capabilities: LocalServices, NetworkServices, ReadUserData, WriteUserData, UserEnvironment and, Location

        • +

      • system capabilities: PowerMgmt, ProtServ, ReadDeviceData, SurroundingsDD, SwEvent, TrustedUI, WriteDeviceData

        • +

      • restricted capabilities: CommDD, DiskAdmin, MultimediaDD and NetworkControl

        • +

      • device manufacturer capabilities: AllFiles, DRM and TCB

      -

      Capabilities required by the application are defined in the mmp project -definition file during the build process, and cannot be changed during run -time. For information on the parameters you can use, see capability. -Carbide.c++ has a Capability Scanner tool which can be accessed through the Project -> Run Capability Scanner on Project MMP menu. The tool scans and checks -the project for required capabilities.

      -

      During the installation the Software -Installer application in the device checks whether the application -has been certified or signed. It then checks the capabilities requested by -the application. If the application has been certified, it checks that the -root certificate is allowed to grant the required capabilities. If no problems -are encountered, the installation can continue. For information on certifications -required by the capabilities, see Application -signing.

      -

      The user can grant the user capabilities to a self-signed application. -For example, the following dialog is shown to the user to grant the LocalServices capability:

      -Granting LocalServices capability during the installation +

      Capabilities required by the application are defined in the mmp project definition file during the build process, and +cannot be changed during run time. For information on the parameters +you can use, see Symbian Tools Guide > Building > +Symbian Build System (SBSv1) > Build tools reference > MMP file syntax +> capability. Carbide.c++ has a Capability Scanner tool which +can be accessed through the Project > Run Capability Scanner on +Project MMP menu. The tool scans and checks the project for required +capabilities.

      +

      During the installation the Software Installer application in the device checks whether the application has been +certified or signed. It then checks the capabilities requested by +the application. If the application has been certified, it checks +that the root certificate is allowed to grant the required capabilities. +If no problems are encountered, the installation can continue. For +information on certifications required by the capabilities, see Application signing.

      +

      The user can grant the user capabilities to a self-signed +application. For example, the following dialog is shown to the user +to grant the LocalServices capability:

      +Granting LocalServices capability during the installation
      dll capabilities

      A dll must have equal or greater set of capabilities -than the loading process, otherwise the process is not allowed to load the dll. -Once loaded, a dll runs at the capability level of the loading -process. A dll that has a higher capability set than the -loading process cannot leak capabilities to the process, but a process can -leak capabilities to the dll.

      -

      For more information, see DLL -capability model in a secure platform (TSS000454) in the Forum Nokia -Knowledge Base.

      +than the loading process, otherwise the process is not allowed to +load the dll. Once loaded, a dll runs at the capability level of the loading process. A dll that has a higher capability set than the loading process cannot +leak capabilities to the process, but a process can leak capabilities +to the dll.

      +

      For more information, see DLL capability model in a secure platform (TSS000454) in +the Forum Nokia Knowledge Base.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-69831D75-D16D-54CF-A083-0EDB358F3390_d0e80082_href.png Binary file Symbian3/SDK/Source/GUID-69831D75-D16D-54CF-A083-0EDB358F3390_d0e80082_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-69831D75-D16D-54CF-A083-0EDB358F3390_d0e80140_href.png Binary file Symbian3/SDK/Source/GUID-69831D75-D16D-54CF-A083-0EDB358F3390_d0e80140_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e76050_href.png Binary file Symbian3/SDK/Source/GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e76050_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e76088_href.png Binary file Symbian3/SDK/Source/GUID-69847989-624F-5119-8AC0-3D95D72AF076_d0e76088_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A482ACB-D39E-578B-B58B-44E4142A5897_d0e351818_href.png Binary file Symbian3/SDK/Source/GUID-6A482ACB-D39E-578B-B58B-44E4142A5897_d0e351818_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A482ACB-D39E-578B-B58B-44E4142A5897_d0e380811_href.png Binary file Symbian3/SDK/Source/GUID-6A482ACB-D39E-578B-B58B-44E4142A5897_d0e380811_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A5D0445-5D53-5293-A501-136203C80BEE_d0e202292_href.png Binary file Symbian3/SDK/Source/GUID-6A5D0445-5D53-5293-A501-136203C80BEE_d0e202292_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A5D0445-5D53-5293-A501-136203C80BEE_d0e207299_href.png Binary file Symbian3/SDK/Source/GUID-6A5D0445-5D53-5293-A501-136203C80BEE_d0e207299_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A783365-3CC3-5D7E-9F1C-D3585C4AE66C.dita --- a/Symbian3/SDK/Source/GUID-6A783365-3CC3-5D7E-9F1C-D3585C4AE66C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -FEATUREVARIANT

      All DLLs are variant by default, but they are disabled using -invariant or -inv option in the abld command.

      A DLL marked as FEATUREVARIANT in its .mmp file remains variant, when -invariant or -inv option is specified in the abld command.

      FEATUREVARIANT has an effect only when used with -invariant or -inv option in the abld command.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A7F8298-F3E9-513C-8C1F-D057AC62E5E3.dita --- a/Symbian3/SDK/Source/GUID-6A7F8298-F3E9-513C-8C1F-D057AC62E5E3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6A7F8298-F3E9-513C-8C1F-D057AC62E5E3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -124,7 +124,7 @@ with UID KUidECamEventCameraSettingFocusRange2.

      Autofocus

      Autofocus support for camera applications is controlled through the CCameraAdvancedSettings class.

      Implementation of autofocus - +

      Pressing the camera shutter key on the device halfway down generates additional key events. The key events can be used to activate autofocus if the camera hardware supports the functionality. Shutter release (image capture) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A9991B8-CF03-5097-BE7D-FB486D26D41B_d0e289302_href.png Binary file Symbian3/SDK/Source/GUID-6A9991B8-CF03-5097-BE7D-FB486D26D41B_d0e289302_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6A9991B8-CF03-5097-BE7D-FB486D26D41B_d0e295774_href.png Binary file Symbian3/SDK/Source/GUID-6A9991B8-CF03-5097-BE7D-FB486D26D41B_d0e295774_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6ABEF478-F3DB-524E-A500-9431B42C6665.dita --- a/Symbian3/SDK/Source/GUID-6ABEF478-F3DB-524E-A500-9431B42C6665.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6ABEF478-F3DB-524E-A500-9431B42C6665.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ shows how to dial or answer one call at a time. It presumes there are no other calls being made.

      Single Call State Diagram - +

      The boxes are states. The enumeration value in each box is the status of the voice line. Voice line status describes the states and their meaning. You can also find diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6AD1DA34-EA3D-4EC9-A667-390507B4D6CB.dita --- a/Symbian3/SDK/Source/GUID-6AD1DA34-EA3D-4EC9-A667-390507B4D6CB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6AD1DA34-EA3D-4EC9-A667-390507B4D6CB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,255 +1,251 @@ - - - - - -helloworldbasic.rss -

      In the Symbian platform, resource files are used to define UI components -such as status panes, CBA -(Control Button Area) buttons, menu -bars, views, -dialogs, strings, and constants used in applications.

      -

      For more information about resource files, see Managing -resource files.

      -// RESOURCE IDENTIFIER -NAME HEWB // 4 letter ID - - -

      This NAME statement defines the mandatory identifier for this resource -file, which is unique within this application. For more information, see Resource -file structure.

      -// INCLUDES -#include <eikon.rh> -#include <avkon.rh> - -

      These are preprocessor statements for EIKON and AVKON files -provided in the ./Epoc32/include sub-folder. They are -required for data structures used in the resource file. For more information -on the available preprocessor statements in resource files, see Resource -file structure.

      -#include <avkon.rsg> - -

      These is a preprocessor statement for a generated resource file provided -in the ./Epoc32/include subfolder that provides a list -of symbolic IDs that point to compiled resources. For more on Symbian precompiled -options, see Precompiled -resource values available from the Symbian platform.

      -#include <appinfo.rh> - -

      This is a preprocessor statement for an AVKON file -provided in the ./Epoc32/include subfolder that is required -for the data structure used for the localizable information for the application -registration resource file.

      -#include "HelloWorldBasic.hrh" -

      This is a preprocessor statement for the HelloWorldBasic custom -command IDs. For more on custom command IDs, see Creating -resource header files.

      -#include "HelloWorldBasic.rls" - -

      This is a preprocessor statement for the file used to manage building -the localized strings for the HelloWorldBasic application. For more -on internationalization and localization, see Internationalization -and localization.

      -// RESOURCE DEFINITIONS -// ----------------------------------------------------------------------------- -// -// Define the resource file signature -// This resource should be empty. -// -// ----------------------------------------------------------------------------- -// -RESOURCE RSS_SIGNATURE - { - } - - -

      This is the required RESOURCE definition that indicates -the version of this resource file. For this application, no version is defined.

      -// ----------------------------------------------------------------------------- -// -// Default Document Name -// -// ----------------------------------------------------------------------------- -// -RESOURCE TBUF r_default_document_name - { - buf="HEWB"; - } - - -

      This is the required RESOURCE definition that defines -the name used if the helloworldbasicdocument class needs -to store a document.

      -// ----------------------------------------------------------------------------- -// -// Define default menu and CBA key. -// -// ----------------------------------------------------------------------------- -// -RESOURCE EIK_APP_INFO - { - menubar = r_helloworldbasic_menubar; - cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT; - } - -

      This is the required RESOURCE definition that defines -the resource used for constructing the menu bar and the Control Button Area -(CBA) buttons used in the application. The menu bar is constructed later in -this resource file. The CBA buttons declaration uses a precompiled symbolic -ID from the avkon.rsg file, which in turns points to -a compiled resource that provides an Options text above -the left softkey and an Exit text above the right softkey. -The application framework handles the event generated by selection of the Options softkey -and opens the MENU_PANE resource. Selection of the Exit softkey -generates a EAknSoftkeyExit event that needs to be handled -by your code. For more information on event handling, see Event -handling.

      -// ----------------------------------------------------------------------------- -// -// r_helloworldbasic_menubar -// Menubar for HelloWorldBasic example -// -// ----------------------------------------------------------------------------- -// -RESOURCE MENU_BAR r_helloworldbasic_menubar - { - titles = - { - MENU_TITLE { menu_pane = r_helloworldbasic_menu; } - }; - } - -

      This RESOURCE definition defines the r_helloworldbasic_menubar menu -bar declared in EIK_APP_INFO. The MENU_TITLE statement -maps to the Options softkey, which opens the defined MENU_PANE resources -when selected.

      -// ----------------------------------------------------------------------------- -// -// r_helloworldbasic_menu -// Menu for "Options" -// -// ----------------------------------------------------------------------------- -// -RESOURCE MENU_PANE r_helloworldbasic_menu - { - items = - { - // added the new Options menu command here - MENU_ITEM - { - command = EHelloWorldBasicCommand1; - txt = STRING_hewb_command1; - }, - MENU_ITEM - { - command = EHelloWorldBasicCommand2; - txt = STRING_hewb_command2; - }, - MENU_ITEM - { - command = EHelloWorldBasicCommand3; - txt = STRING_r_hewb_command3; - }, - MENU_ITEM - { - command = EAknSoftkeyExit; - txt = STRING_r_hewb_exit; - } - }; - } - -

      This RESOURCE definition defines the r_helloworldbasic_menu menu -opened when Option is selected. Four menu items are offered: Hello, Hello -from file, Hello from edit, and Exit. -The command definitions indicate which event is returned -by the application framework when the option is selected and the txt declarations -provide the strings used in the menu. The enumerated command command -IDs here are listed in the helloworldbasic.hrh file, -with the exception of EAknSoftkeyExit, which is a command -ID available from avkon.hrh.

      -// ----------------------------------------------------------------------------- -// -// Resources for messages. -// -// ----------------------------------------------------------------------------- -// -RESOURCE TBUF32 r_hewb_command1_text { buf=STRING_r_hewb_command1_text; } -RESOURCE TBUF32 r_hewb_file_text { buf=STRING_r_hewb_file_text; } -RESOURCE TBUF32 r_hewb_caption_string { buf=STRING_r_hewb_caption_string; } - -

      These RESOURCE definitions define TBUF32 resources -that can be read in the application implementation code later with the StringLoader class.

      -// ---------------------------------------------------------------------------- -// -// r_helloworldbasic_localisable_app_info -// -// ---------------------------------------------------------------------------- -// -RESOURCE LOCALISABLE_APP_INFO r_helloworldbasic_localisable_app_info - { - short_caption = STRING_hewb_caption_string; - caption_and_icon = - CAPTION_AND_ICON_INFO - { - caption = STRING_hewb_caption_string; - - number_of_icons = 1; - icon_file = "\\resource\\apps\\Helloworldbasic_aif.mif"; - }; - } - -

      This RESOURCE definition defines the localizable -information for the HelloWorldBasic registration file, where:

      -
        -

      • r_helloworldbasic_localisable_app_info is -the resource identifier

        • -

      • STRING_hewb_caption_string is the symbolic -ID for HelloWorld, which is used for both the short and -long caption

        • -

      • there is one icon for HelloWorldBasic and it is in -the \\resource\\apps\\Helloworldbasic_aif.mif file

        -
        • -
      -// ---------------------------------------------------------------------------- -// -// r_dialog_text_edit_query -// -// ---------------------------------------------------------------------------- -// -RESOURCE DIALOG r_dialog_text_edit_query - { - flags = EGeneralQueryFlags; - buttons = R_AVKON_SOFTKEYS_OK_CANCEL; - items = - { - DLG_LINE - { - type = EAknCtQuery; - id = EGeneralQuery; - control = AVKON_DATA_QUERY - { - layout = EDataLayout; - label = ""; - control = EDWIN - { - width = 32; - maxlength = 32; - lines = 1; - }; - }; - } - }; - } -// End of File - -

      This RESOURCE definition defines the resource required -for a dialog used in theHelloWorldBasic application. For more information -on defining DIALOG resources, see Using -Dialog API.

      + + + + + +helloworldbasic.rss +

      In the Symbian platform, resource files are used to define UI components +such as status panes, CBA +(Control Button Area) buttons, menu +bars, views, +dialogs, strings, and constants used in applications.

      +

      For more information about resource files, see Managing +resource files.

      +// RESOURCE IDENTIFIER +NAME HEWB // 4 letter ID + + +

      This NAME statement defines the mandatory identifier for this resource +file, which is unique within this application. For more information, see Resource file structure.

      +// INCLUDES +#include <eikon.rh> +#include <avkon.rh> + +

      These are preprocessor statements for EIKON and AVKON files +provided in the ./Epoc32/include sub-folder. They are +required for data structures used in the resource file. For more information +on the available preprocessor statements in resource files, see Resource file structure.

      +#include <avkon.rsg> + +

      These is a preprocessor statement for a generated resource file provided +in the ./Epoc32/include subfolder that provides a list +of symbolic IDs that point to compiled resources. For more on Symbian precompiled +options, see Precompiled resource values available from the Symbian platform.

      +#include <appinfo.rh> + +

      This is a preprocessor statement for an AVKON file +provided in the ./Epoc32/include subfolder that is required +for the data structure used for the localizable information for the application +registration resource file.

      +#include "HelloWorldBasic.hrh" +

      This is a preprocessor statement for the HelloWorldBasic custom +command IDs. For more on custom command IDs, see Creating resource header files.

      +#include "HelloWorldBasic.rls" + +

      This is a preprocessor statement for the file used to manage building +the localized strings for the HelloWorldBasic application. For more +on internationalization and localization, see Internationalization +and localization.

      +// RESOURCE DEFINITIONS +// ----------------------------------------------------------------------------- +// +// Define the resource file signature +// This resource should be empty. +// +// ----------------------------------------------------------------------------- +// +RESOURCE RSS_SIGNATURE + { + } + + +

      This is the required RESOURCE definition that indicates +the version of this resource file. For this application, no version is defined.

      +// ----------------------------------------------------------------------------- +// +// Default Document Name +// +// ----------------------------------------------------------------------------- +// +RESOURCE TBUF r_default_document_name + { + buf="HEWB"; + } + + +

      This is the required RESOURCE definition that defines +the name used if the helloworldbasicdocument class needs +to store a document.

      +// ----------------------------------------------------------------------------- +// +// Define default menu and CBA key. +// +// ----------------------------------------------------------------------------- +// +RESOURCE EIK_APP_INFO + { + menubar = r_helloworldbasic_menubar; + cba = R_AVKON_SOFTKEYS_OPTIONS_EXIT; + } + +

      This is the required RESOURCE definition that defines +the resource used for constructing the menu bar and the Control Button Area +(CBA) buttons used in the application. The menu bar is constructed later in +this resource file. The CBA buttons declaration uses a precompiled symbolic +ID from the avkon.rsg file, which in turns points to +a compiled resource that provides an Options text above +the left softkey and an Exit text above the right softkey. +The application framework handles the event generated by selection of the Options softkey +and opens the MENU_PANE resource. Selection of the Exit softkey +generates a EAknSoftkeyExit event that needs to be handled +by your code. For more information on event handling, see Event +handling.

      +// ----------------------------------------------------------------------------- +// +// r_helloworldbasic_menubar +// Menubar for HelloWorldBasic example +// +// ----------------------------------------------------------------------------- +// +RESOURCE MENU_BAR r_helloworldbasic_menubar + { + titles = + { + MENU_TITLE { menu_pane = r_helloworldbasic_menu; } + }; + } + +

      This RESOURCE definition defines the r_helloworldbasic_menubar menu +bar declared in EIK_APP_INFO. The MENU_TITLE statement +maps to the Options softkey, which opens the defined MENU_PANE resources +when selected.

      +// ----------------------------------------------------------------------------- +// +// r_helloworldbasic_menu +// Menu for "Options" +// +// ----------------------------------------------------------------------------- +// +RESOURCE MENU_PANE r_helloworldbasic_menu + { + items = + { + // added the new Options menu command here + MENU_ITEM + { + command = EHelloWorldBasicCommand1; + txt = STRING_hewb_command1; + }, + MENU_ITEM + { + command = EHelloWorldBasicCommand2; + txt = STRING_hewb_command2; + }, + MENU_ITEM + { + command = EHelloWorldBasicCommand3; + txt = STRING_r_hewb_command3; + }, + MENU_ITEM + { + command = EAknSoftkeyExit; + txt = STRING_r_hewb_exit; + } + }; + } + +

      This RESOURCE definition defines the r_helloworldbasic_menu menu +opened when Option is selected. Four menu items are offered: Hello, Hello +from file, Hello from edit, and Exit. +The command definitions indicate which event is returned +by the application framework when the option is selected and the txt declarations +provide the strings used in the menu. The enumerated command command +IDs here are listed in the helloworldbasic.hrh file, +with the exception of EAknSoftkeyExit, which is a command +ID available from avkon.hrh.

      +// ----------------------------------------------------------------------------- +// +// Resources for messages. +// +// ----------------------------------------------------------------------------- +// +RESOURCE TBUF32 r_hewb_command1_text { buf=STRING_r_hewb_command1_text; } +RESOURCE TBUF32 r_hewb_file_text { buf=STRING_r_hewb_file_text; } +RESOURCE TBUF32 r_hewb_caption_string { buf=STRING_r_hewb_caption_string; } + +

      These RESOURCE definitions define TBUF32 resources +that can be read in the application implementation code later with the StringLoader class.

      +// ---------------------------------------------------------------------------- +// +// r_helloworldbasic_localisable_app_info +// +// ---------------------------------------------------------------------------- +// +RESOURCE LOCALISABLE_APP_INFO r_helloworldbasic_localisable_app_info + { + short_caption = STRING_hewb_caption_string; + caption_and_icon = + CAPTION_AND_ICON_INFO + { + caption = STRING_hewb_caption_string; + + number_of_icons = 1; + icon_file = "\\resource\\apps\\Helloworldbasic_aif.mif"; + }; + } + +

      This RESOURCE definition defines the localizable +information for the HelloWorldBasic registration file, where:

      +
        +

      • r_helloworldbasic_localisable_app_info is +the resource identifier

        • +

      • STRING_hewb_caption_string is the symbolic +ID for HelloWorld, which is used for both the short and +long caption

        • +

      • there is one icon for HelloWorldBasic and it is in +the \\resource\\apps\\Helloworldbasic_aif.mif file

        +
        • +
      +// ---------------------------------------------------------------------------- +// +// r_dialog_text_edit_query +// +// ---------------------------------------------------------------------------- +// +RESOURCE DIALOG r_dialog_text_edit_query + { + flags = EGeneralQueryFlags; + buttons = R_AVKON_SOFTKEYS_OK_CANCEL; + items = + { + DLG_LINE + { + type = EAknCtQuery; + id = EGeneralQuery; + control = AVKON_DATA_QUERY + { + layout = EDataLayout; + label = ""; + control = EDWIN + { + width = 32; + maxlength = 32; + lines = 1; + }; + }; + } + }; + } +// End of File + +

      This RESOURCE definition defines the resource required +for a dialog used in theHelloWorldBasic application. For more information +on defining DIALOG resources, see Using +Dialog API.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6B8BA8A8-AD56-55BA-9659-15091E988FB7.dita --- a/Symbian3/SDK/Source/GUID-6B8BA8A8-AD56-55BA-9659-15091E988FB7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6B8BA8A8-AD56-55BA-9659-15091E988FB7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,30 +9,27 @@ --> -HTTP -Client ExampleThis example shows how to use HTTP APIs. -
      Description

      This -updated C++ application demonstrates simple HTTP GET and POST transactions -using the HTTP Client API. Basic HTTP authentication is also supported.

      -
      Download

      Click -on the following link to download the example: Httpclientexample.zip

      Click: browse to view the example code.

      -
      Building and -configuring

      To build the example:

        -

      • You can build the example -from your IDE or the command line.

        If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

        If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

        bldmake -bldfiles

        abld build

        How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

        • -

      • For the emulator, the -example builds an executable called httpexampleclient.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

        • +HTTP Client ExampleThis example shows how to use HTTP APIs. +
        Description

        This updated C++ application demonstrates simple HTTP GET and +POST transactions using the HTTP Client API. Basic HTTP authentication +is also supported.

        +
        Download

        Click on the following link to download the example: Httpclientexample.zip

        Click: browse to view the example code.

        +
        Building +and configuring

        To build the example:

          +

        • You can build +the example from your IDE or the command line.

          If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

          If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

          bldmake bldfiles

          abld +build

          • +

        • For the emulator, +the example builds an executable called httpexampleclient.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

        -Simple Client -Session guide -HTTP Overview - +Simple +Client Session guide +HTTP +Overview         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6B97D07F-DF2A-5CF1-84A9-84DBE7CB2115.dita --- a/Symbian3/SDK/Source/GUID-6B97D07F-DF2A-5CF1-84A9-84DBE7CB2115.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6B97D07F-DF2A-5CF1-84A9-84DBE7CB2115.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@

        See the latest version of the public System Model from the Symbian foundation.

        System model relationship - +
        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6B9E5B8D-E2F7-5972-ABFB-49F7F466EBBD_d0e332788_href.png Binary file Symbian3/SDK/Source/GUID-6B9E5B8D-E2F7-5972-ABFB-49F7F466EBBD_d0e332788_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6B9E5B8D-E2F7-5972-ABFB-49F7F466EBBD_d0e339254_href.png Binary file Symbian3/SDK/Source/GUID-6B9E5B8D-E2F7-5972-ABFB-49F7F466EBBD_d0e339254_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6BA9989F-6D45-5D77-BC79-DE4B5DD35A6C_d0e244875_href.png Binary file Symbian3/SDK/Source/GUID-6BA9989F-6D45-5D77-BC79-DE4B5DD35A6C_d0e244875_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6BA9989F-6D45-5D77-BC79-DE4B5DD35A6C_d0e249834_href.png Binary file Symbian3/SDK/Source/GUID-6BA9989F-6D45-5D77-BC79-DE4B5DD35A6C_d0e249834_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6BD861E5-7F33-513D-8B35-CFA47E3E82F3.dita --- a/Symbian3/SDK/Source/GUID-6BD861E5-7F33-513D-8B35-CFA47E3E82F3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6BD861E5-7F33-513D-8B35-CFA47E3E82F3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ access the functions with the CTelephony class.

        Telephony API for Applications - Block Diagram - +
      Description

      The CTelephony class provides a limited set of telephony functions to client applications. The CTelephony is built on top of the core, multimode diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6C069F43-207C-5C6A-B9F6-3865BE8E70E8.dita --- a/Symbian3/SDK/Source/GUID-6C069F43-207C-5C6A-B9F6-3865BE8E70E8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,134 +0,0 @@ - - - - - -Variant -configuration file syntax -

      Purpose

      A variant configuration file (.var) -defines settings that are specific to a variant. It is used to modify certain -aspects of an existing build platform.

      -
      Syntax

      KEYWORD [OPERATION] -[VALUE]

      A summary of keywords, operations and values -is given below:

      Keyword

      Possible keywords are as follows:

      - - - -

      VARIANT

      -

      Indicates that VALUE is the name of the variant -configuration.

      -       - -

      VIRTUAL

      -

      Indicates that the variant is meant only for grouping variants and -not to be used as a build configuration.

      -       - -

      EXTENDS

      -

      Indicates that the variant extends an existing variant configuration.

      -       - -

      VARIANT_HRH

      -

      Specifies the pre-included header (.hrh) file -that defines feature macros.

      -       - -

      BUILD_INCLUDE

      -

      Specifies the location of the files to be included when building -the binary.

      -       - -

      ROM_INCLUDE

      -

      Specifies the location of the files to be included when building -the ROM image containing the variant binary.

      -       - - -

      Note: If VARIANT_HRH keyword is not present, then /epoc32/include/variant/name.hrh is -used.

      operation

      The possible operations are set, append and prepend. -These operations provide the flexibility of extending the existing include -paths within the .var file. The operations are applicable -only to the BUILD_INCLUDE and ROM_INCLUDE keywords.

      Example

      # default.var -VARIANT default -BUILD_INCLUDE set /epoc32/include -BUILD_INCLUDE append /epoc32/include/variant -ROM_INCLUDE set /epoc32/rom/include # phone.var -VARIANT phone -EXTENDS default -BUILD_INCLUDE append /epoc32/include/variant/phone -ROM_INCLUDE prepend /epoc32/rom/phone

      For the variant phone the -include lists will be:

      BUILD (/epoc32/include, /epoc32/include/variant, /epoc32/include/variant/phone) -ROM (/epoc32/rom/phone, /epoc32/rom/include)

      value

      Value -can be a variant name, a file name or a directory name. for example, myphone -or /epoc32/tools/variant/name.var.

        -

      • Use '/' as the path separator between files and directories.

        • -

      • Begin all paths with '/' implying that they are relative to EPOCROOT.

        • -

      Example

      An example of a variant:

      VARIANT name -VIRTUAL -EXTENDS parent -VARIANT_HRH /epoc32/include/variant/something.hrh -BUILD_INCLUDE set directoryA -BUILD_INCLUDE append directoryB -BUILD_INCLUDE prepend directoryC -ROM_INCLUDE set directoryD -ROM_INCLUDE append directoryE -ROM_INCLUDE prepend directoryF - -

      Notes

        -

      • All .var files -must exist in /epoc32/tools / variant.

        • -

      • A default variant configuration -file (default.var) must exist in /epoc32/tools/variant/.

        • -

      • The name of the variant -configuration file (.var) must be same as the variant name. For example, if -the variant name is myvar, then the variant configuration file must -be named as myvar.var.

        • -

      • Each variant must have -a default <variant_name>.hrh file at /epoc32/include/variant/. -If you want to use any other .hrh file under EPOCROOT, -use the VARIANT_HRH keyword to specify its name along with -the relative path.

        • -

      • A default variant cannot -be VIRTUAL.

        • -
      -
      Example

      An example of a variant:

      VARIANT name -VIRTUAL -EXTENDS parent -VARIANT_HRH /epoc32/include/variant/something.hrh -BUILD_INCLUDE set directoryA -BUILD_INCLUDE append directoryB -BUILD_INCLUDE prepend directoryC -ROM_INCLUDE set directoryD -ROM_INCLUDE append directoryE -ROM_INCLUDE prepend directoryF - -
      -
      Notes
        -

      • All .var files -must exist in /epoc32/tools / variant.

        • -

      • A default variant configuration -file (default.var) must exist in /epoc32/tools/variant/.

        • -

      • The name of the variant -configuration file (.var) must be same as the variant name. For example, if -the variant name is myvar, then the variant configuration file must -be named as myvar.var.

        • -

      • Each variant must have -a default <variant_name>.hrh file at /epoc32/include/variant/. -If you want to use any other .hrh file under EPOCROOT, -use the VARIANT_HRH keyword to specify its name along with -the relative path.

        • -

      • A default variant cannot -be VIRTUAL.

        • -
      - -How to build -feature based variants -How to build -ROMs with variants - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6C1D941B-ADD1-5BD3-9045-53B66253316B.dita --- a/Symbian3/SDK/Source/GUID-6C1D941B-ADD1-5BD3-9045-53B66253316B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -epocallowdlldata

      epocallowdlldata

      epocallowdlldata statement allows you to use global writeable static data in DLLs.

      See Static data for issues with using the writeable static data.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CB40FC5-5CBF-592C-B27D-29922C3815DC.dita --- a/Symbian3/SDK/Source/GUID-6CB40FC5-5CBF-592C-B27D-29922C3815DC.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -library

      abld [ test ] library [-k] [-v] [ platform ] [ program ]

      This command creates the import libraries for the DLLs in your component by calling the library target provided in makefiles generated by makmake.

      Import libraries are generated directly from frozen .def files, so exported functions will not be incorporated into import libraries until these functions are frozen with abld - freeze.

      The import libraries are created implicitly as part of the build activity carried out by abld target (and thus abld build), so it isn’t generally necessary to call this command separately if projects are listed in the component description file in order of dependency—dependent projects appearing after those projects they depend upon.

      If there are mutual imports between projects within your component then abld library can be called explicitly, though mutual imports are often a sign of poor software design.

      An import library will not be regenerated if it has a later date stamp than the corresponding frozen .def file.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CDDDD1E-BDB9-5C61-8EFD-8B3369F5A12D.dita --- a/Symbian3/SDK/Source/GUID-6CDDDD1E-BDB9-5C61-8EFD-8B3369F5A12D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6CDDDD1E-BDB9-5C61-8EFD-8B3369F5A12D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,149 +9,134 @@ --> -P.I.P.S. -Overview -

      P.I.P.S. supplies a new framework of POSIX 'C' APIs to be used by Symbian -developers with RTOS, Linux or Microsoft Windows® knowledge. The new APIs -are packaged into industry standard libraries - libc, libm, libpthread and libdl - and will help reduce development costs.

      -
      Purpose

      The -Symbian platform already provides a library called 'ESTLIB', -which includes a subset of Standard C APIs. This was created to allow the -Java virtual machine to run on the Symbian platform rather than to allow applications -written in C to be ported to the Symbian platform. Furthermore, the functionality -provided by ESTLIB is not fully compliant with the Standard -C and POSIX standards. Symbian intends to deprecate ESTLIB once -P.I.P.S. is mature.

      The P.I.P.S. libraries are included in ROM on -certain smartphones based on Symbian OS v9.3 onwards. For smartphones based -on earlier versions of Symbian platform, a freely downloadable SIS file is -available from the Symbian Developer Network (specifically http://developer.symbian.org/wiki/index.php/Open_C_and_Open_C%2B%2B_Quick_Start) -and can be installed on any Symbian OS v9.x smartphones.

      -
      Required background

      The -differences between the Symbian platform and other operating systems

      The -Symbian platform is an operating system designed for mobile devices and comes -in the form of many libraries that contain hundreds of classes and thousands -of member functions.

      The Symbian platform has been specifically designed -to provide efficient memory and power management.

      P.I.P.S. has been -introduced to the Symbian platform to make it more attractive to third party -Symbian developers with C/C++ experience and to allow them to port their applications -to the Symbian platform with greater ease.

      The P.I.P.S. initiative -aims to reduce the development cost of porting software to run on the Symbian -platform. It achieves this by providing a POSIX-like API layer above the Symbian -platform. Given the structure of the Symbian platform, however, it is not -possible to provide a fully compliant API and some functionality, such as, fork() and exec() are -not supported. This guide details such non-compliance and recommended alternatives.

      Specific -differences between the Symbian platform and Unix-like systems are described -in the relevant sections of this guide.

      What P.I.P.S. is not

      The -P.I.P.S. environment is not a UNIX® application environment. You will -not be able to run a UNIX application on the Symbian platform 'as is'. At -a minimum, you will need to create a .mmp file and a bld.inf file -for the application and rebuild the application's source code for the Symbian -platform. For further information, see The -Symbian build process section.

      If the application does not -work at the first attempt, you may have to modify the application code to -replace missing APIs or port the required APIs to extend the P.I.P.S. environment. -To find out more about porting C libraries to the Symbian platform, see the P.I.P.S. Porting Tutorials sections.

      The -P.I.P.S. environment is not 100% POSIX compliant and it is not officially -certified as POSIX compatible. However, the implementation is as compliant -as the underlying Symbian platform allows it to be. For example, P.I.P.S. -does not provide the APIs fork() and exec(), -but it does provide popen(), mkfifo() and -so on, which can be used to implement well known alternative patterns. For -further information, see the Process -Creation section.

      -
      Architecture

      P.I.P.S. -provides an API layer above the native Symbian platform APIs that is more -closely aligned with industry standard APIs.

      The core P.I.P.S. libraries -are:

        -

      • libc: -Standard C and POSIX APIs - includes support for files, sockets, pipes, message -queues, shared memory APIs and environment variables

        • -

      • libm: -Standard C maths support APIs

        • -

      • libpthread: -Standard POSIX threading APIs

        • -

      • libdl: -Standard C dynamic loading and symbol lookup APIs (only ordinal lookup is -supported on pre-Symbian OS v9.3 releases).

        • -

      The first three libraries listed above are seeded from FreeBSD.

      The diagram below shows the high -level architecture of the P.I.P.S. environment.

      +P.I.P.S. Overview +

      P.I.P.S. supplies a new framework of POSIX 'C' APIs to be used +by Symbian developers with RTOS, Linux or Microsoft Windows® knowledge. +The new APIs are packaged into industry standard libraries - libc, libm, libpthread and libdl - and will help reduce development costs.

      +
      Purpose

      The Symbian platform already provides a library called 'ESTLIB', which includes a subset of Standard C APIs. This +was created to allow the Java virtual machine to run on the Symbian +platform rather than to allow applications written in C to be ported +to the Symbian platform. Furthermore, the functionality provided by ESTLIB is not fully compliant with the Standard C and POSIX +standards. Symbian intends to deprecate ESTLIB once +P.I.P.S. is mature.

      The P.I.P.S. libraries are included in +ROM on certain smartphones based on Symbian OS v9.3 onwards. For smartphones +based on earlier versions of Symbian platform, a freely downloadable +SIS file is available from the Symbian Developer Network (specifically http://developer.symbian.org/wiki/index.php/Open_C_and_Open_C%2B%2B_Quick_Start) and can be installed on any Symbian OS v9.x smartphones.

      +
      Required +background

      The differences between the Symbian platform +and other operating systems

      The Symbian platform is an +operating system designed for mobile devices and comes in the form +of many libraries that contain hundreds of classes and thousands of +member functions.

      The Symbian platform has been specifically +designed to provide efficient memory and power management.

      P.I.P.S. has been introduced to the Symbian platform to make it more +attractive to third party Symbian developers with C/C++ experience +and to allow them to port their applications to the Symbian platform +with greater ease.

      The P.I.P.S. initiative aims to reduce +the development cost of porting software to run on the Symbian platform. +It achieves this by providing a POSIX-like API layer above the Symbian +platform. Given the structure of the Symbian platform, however, it +is not possible to provide a fully compliant API and some functionality, +such as, fork() and exec() are +not supported. This guide details such non-compliance and recommended +alternatives.

      Specific differences between the Symbian platform +and Unix-like systems are described in the relevant sections of this +guide.

      What P.I.P.S. is not

      The P.I.P.S. environment +is not a UNIX® application environment. You will not be able +to run a UNIX application on the Symbian platform 'as is'. At a minimum, +you will need to create a .mmp file and a bld.inf file for the application and rebuild the application's +source code for the Symbian platform.

      If the application does +not work at the first attempt, you may have to modify the application +code to replace missing APIs or port the required APIs to extend the +P.I.P.S. environment. To find out more about porting C libraries to +the Symbian platform, see the P.I.P.S. Porting +Tutorials sections.

      The P.I.P.S. environment is not +100% POSIX compliant and it is not officially certified as POSIX compatible. +However, the implementation is as compliant as the underlying Symbian +platform allows it to be. For example, P.I.P.S. does not provide the +APIs fork() and exec(), but it does +provide popen(), mkfifo() and +so on, which can be used to implement well known alternative patterns. +For further information, see the Process Creation section.

      +
      Architecture

      P.I.P.S. provides an API layer above the native Symbian platform +APIs that is more closely aligned with industry standard APIs.

      The core P.I.P.S. libraries are:

        +

      • libc: Standard C and POSIX APIs - includes support for files, sockets, +pipes, message queues, shared memory APIs and environment variables

        • +

      • libm: Standard C maths support APIs

        • +

      • libpthread: Standard POSIX threading APIs

        • +

      • libdl: Standard C dynamic loading and symbol lookup APIs (only ordinal +lookup is supported on pre-Symbian OS v9.3 releases).

        • +

      The first three libraries listed above are seeded from FreeBSD.

      The diagram below shows the high level architecture of the P.I.P.S. +environment.

      P.I.P.S. environment architecture - -

      This diagram shows how P.I.P.S. fits in with the Symbian platform, -and also how C/C++ applications, additional C shared libraries and hybrid -applications developed by third party Symbian developers using P.I.P.S. fit -in.

      P.I.P.S. environment is based on industry-standard APIs. These -standards include

        -

      • Standard C (stdC) -and

        • + +

        This diagram shows how P.I.P.S. fits in with the Symbian +platform, and also how C/C++ applications, additional C shared libraries +and hybrid applications developed by third party Symbian developers +using P.I.P.S. fit in.

        P.I.P.S. environment is based on industry-standard +APIs. These standards include

          +

        • Standard C (stdC) and

        • POSIX.

          • -

        The P.I.P.S. environment is a mandatory part of Symbian OS v9.5 onward.

        For -devices already in the market, a SIS file is freely downloadable from the -Forum Nokia site (specifically http://www.forum.nokia.com/Technology_Topics/Development_Platforms/Open_C_and_C++/) -and can be installed on any v9.x phone.

        Components

        P.I.P.S. -is based on an industry-standard API and system behaviour.  The relevant -industry standards are Open Group standards and include Standard C (stdC), -POSIX, GNU C library (glibc) and Standard C++ (stdC++).

        The -diagram below shows how the Standard C libraries and exported applications -fit into the native platform.

        +

      The P.I.P.S. environment is a mandatory part of Symbian OS +v9.5 onward.

      For devices already in the market, a SIS file +is freely downloadable from the Forum Nokia site (specifically http://www.forum.nokia.com/Technology_Topics/Development_Platforms/Open_C_and_C++/) and can be installed on any v9.x phone.

      Components

      P.I.P.S. is based on an industry-standard API and system +behaviour.  The relevant industry standards are Open Group standards +and include Standard C (stdC), POSIX, GNU C library +(glibc) and Standard C++ (stdC++).

      The diagram below shows how the Standard C libraries and +exported applications fit into the native platform.

      The subsystem components - -

      The System Call Adaptation Layer (SCAL) is not directly accessed -by the developer wishing to export to the Symbian platform, but through calls -in the P.I.P.S. libraries.

      Traditionally, in Unix-like systems, system -calls are implemented in the kernel, separate from the C libraries. On the -Symbian platform, the 'System Call Adaptation Layer' runs in the context of -the user side but is considered 'kernel-like' code. APIs that belong to this -layer are tagged as @internalComponent and may only be extended -by Symbian.

      Note that P.I.P.S. is not a Linux application environment -- you cannot simply run an application that you've compiled for your Linux -desktop. At a minimum, you will have to rebuild your application from source.

      For -more information, see the Build -Process section.

      Glue -code (CRT0)

      Executables built for the Symbian platform enter via E32Main(), -whereas Standard C applications expect to be started from main(). -It is therefore necessary to have 'glue code' (formerly known as CRT0) between -these two functions. The glue code is also responsible for allocating any -system resources, obtaining system and environment data, and initialising -the SCAL infrastructure prior to calling the main() function -of the application. There are two versions of the glue code library - libcrt0.lib (for -use by applications that enter via char main()) and libwcrt0.lib (for -use by applications that enter via wide char main()).

      To -include the glue code library you should explicity link to libcrt0.lib and libwcrt0.lib statically, -however, if you are using the STDEXE or STDDLL target -types, glue code will be added automatically.

      P.I.P.S. -Core libraries

      Currently, the C libraries include the libc, libm, -and libpthread (seeded from FreeBSD) and libdl libraries. The -APIs provided by these libraries are defined to be compliant, via compatibility -features, with the POSIX standard. They are not officially certified as POSIX -compatible but they conform to it mostly.

      The P.I.P.S. libraries include -the following APIs:

        -

      • stdio, -including print(), scanf(), and so on

        • -

      • stdlib, -including environment variable support, and so on

        • + +

        The System Call Adaptation Layer (SCAL) is not directly +accessed by the developer wishing to export to the Symbian platform, +but through calls in the P.I.P.S. libraries.

        Traditionally, +in Unix-like systems, system calls are implemented in the kernel, +separate from the C libraries. On the Symbian platform, the 'System +Call Adaptation Layer' runs in the context of the user side but is +considered 'kernel-like' code. APIs that belong to this layer are +tagged as @internalComponent and may only be extended +by Symbian.

        Note that P.I.P.S. is not a Linux application +environment - you cannot simply run an application that you've compiled +for your Linux desktop. At a minimum, you will have to rebuild your +application from source.

        Glue code (CRT0)

        Executables built for the Symbian platform enter via E32Main(), whereas Standard C applications expect to be +started from main(). It is therefore necessary to +have 'glue code' (formerly known as CRT0) between these two functions. +The glue code is also responsible for allocating any system resources, +obtaining system and environment data, and initialising the SCAL infrastructure +prior to calling the main() function of the application. +There are two versions of the glue code library - libcrt0.lib (for use by applications that enter via char main()) and libwcrt0.lib (for use by applications +that enter via wide char main()).

        To include +the glue code library you should explicity link to libcrt0.lib and libwcrt0.lib statically, however, if you +are using the STDEXE or STDDLL target +types, glue code will be added automatically.

        P.I.P.S. Core libraries

        Currently, the C libraries include the libc, libm, and libpthread (seeded +from FreeBSD) and libdl libraries. The APIs provided by these +libraries are defined to be compliant, via compatibility features, +with the POSIX standard. They are not officially certified as POSIX +compatible but they conform to it mostly.

        The P.I.P.S. libraries +include the following APIs:

          +

        • stdio, including print(), scanf(), and so on

          • +

        • stdlib, including environment variable support, and so on

        • string manipulation and character APIs

          • -

        • locale and system services

          • -

        • searching, sort and -pattern matching

          • -

        • IPC mechanisms, including -shared memory, pipes, FIFOs and message queues

          • -

        • process creation, including popen(), posix_spawn() and system()

          • -

        • networking and socket -APIs

          • -

        • mathematical and arithmetic -APIs

          • -

        • dynamic loading and -symbol lookup

          • -

        • thread creation and -synchronisation mechanisms.

          • -

        Due to fundamental differences between Linux and the Symbian platform -kernel architecture, there is no support for fork() and exec(). -For more information, see the Process -Creation section.

        The original seed directory structure (FreeBSD) is preserved -as fully as possible to allow for future catch-ups to be performed more easily. -The table below shows the original seed directory structure in FreeBSD.

        +

      • locale and system +services

        • +

      • searching, sort +and pattern matching

        • +

      • IPC mechanisms, +including shared memory, pipes, FIFOs and message queues

        • +

      • process creation, +including popen(), posix_spawn() and system()

        • +

      • networking and +socket APIs

        • +

      • mathematical +and arithmetic APIs

        • +

      • dynamic loading +and symbol lookup

        • +

      • thread creation +and synchronisation mechanisms.

        • +

        Due to fundamental differences between Linux and the Symbian +platform kernel architecture, there is no support for fork() and exec(). For more information, see the Process Creation section.

        The original seed directory structure (FreeBSD) is +preserved as fully as possible to allow for future catch-ups to be +performed more easily. The table below shows the original seed directory +structure in FreeBSD.

        @@ -160,13 +145,13 @@

        core\libc

        -

        Contains Standard C and POSIX APIs as defined by the Standard C -and POSIX standards

        +

        Contains Standard C and POSIX APIs as defined by the Standard +C and POSIX standards

        core\libm

        -

        Contains the Standard C Math API as defined by -Standard C

        +

        Contains the Standard C Math API as defined +by Standard C

        core\libpthread

        @@ -178,29 +163,30 @@         -

        Although P.I.P.S. provides a wide range of APIs, some of the functionality -required in order to complete a porting task might be missing - this could -be some APIs from an existing library or an entire library.

        Several -options are available to the user:

          -

        • Port the missing APIs -using the P.I.P.S. libraries

          • -

        • Implement the missing -APIs on top of the Symbian platform native C++ APIs

          • -

        • Use a workaround - for -example, use popen() instead of fork().

          • -

        Note: The following are the limitations associated with porting -a UNIX® application:

          -

        • Limited stack-space: The -default stack size per thread on Unix-like operating systems ranges from 64 -kB to 1 MB. The Symbian platform, however, defines a default stack size of -8 kB per thread. P.I.P.S. Pthreads use this by default. You can use the pthread_attr_setstacksize() function -to modify this before calling pthread_create().

          • -

        • Limited threads -per process: Assuming that all threads use the default stack size (8 kB), -Symbian specifies a limit of 128 threads per process. The limit changes depending -on the stack size you use for individual threads. For example, if you create -your threads with a stack size of 16 kB, the OS only supports 64 threads per -process.

          • +

          Although P.I.P.S. provides a wide range of APIs, some +of the functionality required in order to complete a porting task +might be missing - this could be some APIs from an existing library +or an entire library.

          Several options are available to the +user:

            +

          • Port the missing +APIs using the P.I.P.S. libraries

            • +

          • Implement the +missing APIs on top of the Symbian platform native C++ APIs

            • +

          • Use a workaround +- for example, use popen() instead of fork().

            • +

          Note: The following are the limitations associated +with porting a UNIX® application:

            +

          • Limited +stack-space: The default stack size per thread on Unix-like operating +systems ranges from 64 kB to 1 MB. The Symbian platform, however, +defines a default stack size of 8 kB per thread. P.I.P.S. Pthreads +use this by default. You can use the pthread_attr_setstacksize() function to modify this before calling pthread_create().

            • +

          • Limited +threads per process: Assuming that all threads use the default +stack size (8 kB), Symbian specifies a limit of 128 threads per process. +The limit changes depending on the stack size you use for individual +threads. For example, if you create your threads with a stack size +of 16 kB, the OS only supports 64 threads per process.

      P.I.P.S. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CE1C2E0-8F57-57D3-9041-929FE30ECEB9_d0e78358_href.png Binary file Symbian3/SDK/Source/GUID-6CE1C2E0-8F57-57D3-9041-929FE30ECEB9_d0e78358_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CE1C2E0-8F57-57D3-9041-929FE30ECEB9_d0e78396_href.png Binary file Symbian3/SDK/Source/GUID-6CE1C2E0-8F57-57D3-9041-929FE30ECEB9_d0e78396_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CEE397C-78E3-40AE-8D39-3DC0980A932A_d0e4566_href.png Binary file Symbian3/SDK/Source/GUID-6CEE397C-78E3-40AE-8D39-3DC0980A932A_d0e4566_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6CEE397C-78E3-40AE-8D39-3DC0980A932A_d0e4693_href.png Binary file Symbian3/SDK/Source/GUID-6CEE397C-78E3-40AE-8D39-3DC0980A932A_d0e4693_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6D7F3D5C-BC1C-5657-993A-4D7E5712CAF5.dita --- a/Symbian3/SDK/Source/GUID-6D7F3D5C-BC1C-5657-993A-4D7E5712CAF5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,43 +0,0 @@ - - - - - -start -stringtable -

      start stringtable source-file

      -

      [exportpath location]

      -

      [headeronly]

      -

      end

      -

      A start stringtable section specifies the source file -for the string table. A string table is a collection of string identifiers -with corresponding values. The source file is a simple text file with the -file extension .st, and is used to generate the .cpp and .h files -which contains the string constants required for the program. The header file -location is added to the list of userinclude directories -so that the source files may include the generated header. The .cpp file -is added to the list of source files, which are built into a component.

      -

      For more information on string tables, refer to String -Pools.

      -

      Note: The .cpp file need not be added explicitly -into the list of sources, as this will be done implicitly while building the -component.

      -

      The optional exportpath location specifies -a directory location for the generated header file.

      -

      The optional headeronly keyword causes only the .h file -to be generated, and no .cpp files are generated or included -into the project. If the exportpath is specified, the .h file -is copied to the specified location.

      -

      This example will generate HttpStringConstants.cpp and HttpStringConstants.h using -the HttpStringConstants.st file, and export the HttpStringConstants.h to -the \epoc32\include directory.

      START STRINGTABLE HttpStringConstants.st -EXPORTPATH \epoc32\include -END -       -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6DA5C169-5143-5DDD-B4A0-004D4571D9B8_d0e356629_href.png Binary file Symbian3/SDK/Source/GUID-6DA5C169-5143-5DDD-B4A0-004D4571D9B8_d0e356629_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6DA5C169-5143-5DDD-B4A0-004D4571D9B8_d0e385622_href.png Binary file Symbian3/SDK/Source/GUID-6DA5C169-5143-5DDD-B4A0-004D4571D9B8_d0e385622_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6DAF85AD-E412-5823-81C2-FC1755A90A84.dita --- a/Symbian3/SDK/Source/GUID-6DAF85AD-E412-5823-81C2-FC1755A90A84.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6DAF85AD-E412-5823-81C2-FC1755A90A84.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ the behaviour that allows an element to operate with the Comms Database. [See accessing the database or words to that effect.]

      - +
      The Element Id

      The iElementId data member of CMDBElement is @@ -55,7 +55,7 @@ number and a 7 bit number. The 8 bit number is the Table Id and the 7 bit number is the Column Id. The Type Id and the Record Id are in defined locations in the 32 bit number iElementId.

      - +

      The header file comsdat.h contains the constants that define the location of these Ids in the 32 bit number:

      @@ -84,7 +84,7 @@ an element are defined by the bits in the element. The TCDAttributeFlags enum defines the access levels of an element. These bits are stored in the fourth byte of the iElementId member of CMDBElement.

      - +

      KCDMaskShowAttributes in the header file comsdat.h defines the location of these access control bits in the 32 bit number.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6DF52DDC-B03C-5971-94C8-0E9BAAB949FD.dita --- a/Symbian3/SDK/Source/GUID-6DF52DDC-B03C-5971-94C8-0E9BAAB949FD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6DF52DDC-B03C-5971-94C8-0E9BAAB949FD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Drawing Text

      This topic provides examples that demonstrate how to draw a line of text and text in a colored box.

      Text

      The basic way to draw text is to call CGraphicsContext::DrawText() with a point specifying the bottom left position, as shown below:

      Before calling, you must use the graphics context to:

      1. Set the font to use

      2. Set the pen color for the text

      // In this example, we use one of the standard font styles +Drawing Text

      This topic provides examples that demonstrate how to draw a line of text and text in a colored box.

      Text

      The basic way to draw text is to call CGraphicsContext::DrawText() with a point specifying the bottom left position, as shown below:

      Before calling, you must use the graphics context to:

      1. Set the font to use

      2. Set the pen color for the text

      // In this example, we use one of the standard font styles CFont* fontUsed = iEikonEnv->TitleFont(); gc.UseFont(fontUsed); @@ -17,7 +17,7 @@ TPoint pos(50,50); _LIT(KExampleText,"blacktext"); -gc.DrawText(KExampleText,pos);
      Text in a box

      To draw text in a box, you must specify:

      • a rectangle to draw the text in

      • an offset from the top of the rectangle to the text baseline: to center the text, add half the height of the rectangle to half the height of the font's ascent

      • the text alignment mode: in the example, left alignment is used

      • a margin: the left margin for left-aligned text, or the right margin for right-aligned text

      The following figure show how these fit together:

      In addition to the font and pen color, you can also set the brush for filling the box.

      ... +gc.DrawText(KExampleText,pos);
      Text in a box

      To draw text in a box, you must specify:

      • a rectangle to draw the text in

      • an offset from the top of the rectangle to the text baseline: to center the text, add half the height of the rectangle to half the height of the font's ascent

      • the text alignment mode: in the example, left alignment is used

      • a margin: the left margin for left-aligned text, or the right margin for right-aligned text

      The following figure show how these fit together:

      In addition to the font and pen color, you can also set the brush for filling the box.

      ... // Draw some text left justified in a box, // Offset so text is just inside top of box diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E161670-EBC6-599B-8EB8-2E48C8EA57CC_d0e272089_href.jpg Binary file Symbian3/SDK/Source/GUID-6E161670-EBC6-599B-8EB8-2E48C8EA57CC_d0e272089_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E161670-EBC6-599B-8EB8-2E48C8EA57CC_d0e276935_href.jpg Binary file Symbian3/SDK/Source/GUID-6E161670-EBC6-599B-8EB8-2E48C8EA57CC_d0e276935_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E221034-9A01-53AB-8374-315C38CCA21E.dita --- a/Symbian3/SDK/Source/GUID-6E221034-9A01-53AB-8374-315C38CCA21E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6E221034-9A01-53AB-8374-315C38CCA21E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,7 +37,7 @@ wait until EProfileCreated event is reported in the observer. When the event is received the profile is created.

      - +

      The following code snippet shows how to create and save a profile.

      /*Client must create an instance of the CSIP class. The API used for this is, here TUid must be an application UID.*/ CSIP* CSIP::NewL(const TUid& aUid, MSIPObserver& aObserver); @@ -111,7 +111,7 @@ wait until it gets a notification through the MSIPProfileRegistryObserver callback interface about the profile registration.

      - +

      The following code snippet shows how to enable a SIP profile.

      /*With the assumption that the profile was created and is saved to the persistent storage. */ //Create an Instance of SIP client @@ -333,7 +333,7 @@

    • The registration status of the profile is set to Registered.

      • The following sequence diagram shows how to enable a profile to refresh.

      - +

      The following code describes how to refresh enable a profile.

      //Checks if the profile is already enabled and requests the Profile Agent to refresh it. // If the profile is not enabled it leaves with KErrArgument. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E2F23B0-4765-5E4E-9B15-9F1D0EC5C28B_d0e271965_href.jpg Binary file Symbian3/SDK/Source/GUID-6E2F23B0-4765-5E4E-9B15-9F1D0EC5C28B_d0e271965_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E2F23B0-4765-5E4E-9B15-9F1D0EC5C28B_d0e276811_href.jpg Binary file Symbian3/SDK/Source/GUID-6E2F23B0-4765-5E4E-9B15-9F1D0EC5C28B_d0e276811_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E3AF264-6149-51FA-BBA0-68E2DB679048_d0e107369_href.png Binary file Symbian3/SDK/Source/GUID-6E3AF264-6149-51FA-BBA0-68E2DB679048_d0e107369_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E3AF264-6149-51FA-BBA0-68E2DB679048_d0e107601_href.png Binary file Symbian3/SDK/Source/GUID-6E3AF264-6149-51FA-BBA0-68E2DB679048_d0e107601_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E4CAA18-635E-5476-8CE4-DCA69C05CC07.dita --- a/Symbian3/SDK/Source/GUID-6E4CAA18-635E-5476-8CE4-DCA69C05CC07.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6E4CAA18-635E-5476-8CE4-DCA69C05CC07.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,13 +31,10 @@

    • The libc.lib file contains the definitions of all functions that are defined in the header files associated with this example.

    • The libcrt0.lib file provides the E32Main() function, which is the entry point for the main() function of the example.

      • -

      The -Symbian build process describes how to build this example.

      For the emulator, the example builds an executable +

      For the emulator, the example builds an executable file called hybridapp.exe in the epoc32\release\winscw\<udeb or urel>\ directory.

      Hybrid Applications -Build -Process       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6E52C463-5489-591F-859D-68EAD5BA80FD.dita --- a/Symbian3/SDK/Source/GUID-6E52C463-5489-591F-859D-68EAD5BA80FD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6E52C463-5489-591F-859D-68EAD5BA80FD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,6 +9,90 @@ --> -Multimedia Framework Guide

      This document introduces the Multimedia Framework (MMF) audio and video client interfaces.

      Purpose

      Multimedia Framework (MMF) provides several client interfaces that encapsulate a lightweight plugin framework. These interfaces enable you to manipulate the audio and video features of the Symbian platform.

      Architectural Relationships

      The following diagram shows how the MMF client interfaces interact with the Multimedia Controller Framework and the Media Device Framework (MDF).

      - Multimedia Framework - client utilities -

      MMF Controller Framework

      The MMF Controller Framework provides support for multimedia plugins within the Symbian platform. The main type of plugin for the MMF Controller Framework is the controller plugin. Each controller plugin provides support for one or more multimedia formats, for example, MP3 or AVI.

      Note: In addition to controller plugins, the Multimedia framework can also be extended through format encoder/decoder, codec, and sink/source plugins. For more information about plugins, see How to write Multimedia Framework plugins.

      The player and recorder interfaces of both audio and video and also the audio converter interface use the controller plugins provided by the MMF Controller Framework. These plugins provide the functionality to convert, interpret, and play audio and video data. The resultant data from the plugins can then be directed to one or more sinks such as a file, or directly to a screen or lower level device driver.

      The video recorder interface can also interact with the Onboard Camera, through a video controller plugin, to capture video. For more information about capturing video, see Video Capture Tutorial.

      Note: Tone player and audio streaming are also provided as part of the MMF but do not interact with controller plugins. Input and output is already in a known data format and so does not require a plugin for encoding or decoding. As a result, they bypass the MMF Controller Framework.

      Media Device Framework

      Media Device Framework is the layer below the controller plugins and above the hardware. It provides a layer of abstraction for the audio and video hardware. The MDF consists of DevSound, for audio input and output, and DevVideo for video.

      For more information about DevSound, see DevSound Overview. For more information about DevVideo, see DevVideo Overview.

      DRM Support

      The Symbian platform provides support for playback of Digital Rights Management (DRM) protected audio and video content by making use of the Content Access Framework (CAF). For more information about the CAF, see Content Access Framework.

      Note: In order to access any DRM protected content using Symbian multimedia, the client process must have the DRM capability.

      Description

      The features made available by the MMF client interfaces are:

      • Audio playing, recording, and conversion - An interface consisting of three classes; CMdaAudioPlayerUtility, CMdaAudioRecorderUtility, and CMdaAudioConvertUtility. These classes provide methods to create, play, and manipulate audio data stored in files, descriptors, and URLs.

      • Audio streaming - An interface consisting of two classes; CMdaAudioInputStream and CMdaAudioOutputStream. These classes provide methods for recording and playing audio streams such as audio from a web address.

        Note: There are no explicit interfaces for video streaming. However, the Onboard Camera can be used to achieve video input streaming, and direct screen access can be used to achieve video output streaming. For more information about the Onboard Camera, see Onboard Camera Overview.

      • Tone playing - An interface consisting of a single class CMdaAudioToneUtility. This class provides methods for playing and configuring single and sequenced tones as well as DTMF (Dual Tone Multi-Frequency) strings.

      • Video playing and recording - An interface consisting of two classes CVideoPlayerUtility and CVideoRecorderUtility. These classes provide methods to create, play, and manipulate video clips with or without audio tracks stored in files, descriptors, and URLs.

      Observer Classes

      For each multimedia client interface, there is a corresponding mixin class that must be implemented by the client. For example, to use the audio player utility you must implement the observer mixin class MMdaAudioPlayerCallback.

      When instantiating any of the MMF interfaces, it is necessary to provide a reference to a class that implements the appropriate mixin class. This allows the MMF to notify the client of events that occur and also to notify the client of errors that may occur.

      Multimedia Framework Tutorials

      The following tutorials are provided:

      • How to use the audio convert utility

      • How to use the audio record utility

      • How to use the audio player utility

      • Audio Input Stream Tutorial

      • Audio Output Stream Tutorial

      • Video Client Tutorials

      See Also

      Audio Client Overview

      Audio Input Stream Overview

      Audio Output Stream Overview

      Video Client Overview

      \ No newline at end of file +Multimedia Framework Guide +

      This document introduces the Multimedia Framework (MMF) audio and +video client interfaces.

      +
      Purpose

      Multimedia Framework (MMF) provides several client interfaces +that encapsulate a lightweight plugin framework. These interfaces +enable you to manipulate the audio and video features of the Symbian +platform.

      +
      Architectural +Relationships

      The following diagram shows how the MMF client +interfaces interact with the Multimedia Controller Framework and the +Media Device Framework (MDF).

      + Multimedia Framework - client utilities + + +

      MMF Controller Framework

      The MMF Controller Framework +provides support for multimedia plugins within the Symbian platform. +The main type of plugin for the MMF Controller Framework is the controller +plugin. Each controller plugin provides support for one or more multimedia +formats, for example, MP3 or AVI.

      Note: In addition +to controller plugins, the Multimedia framework can also be extended +through format encoder/decoder, codec, and sink/source plugins. For +more information about plugins, see How to write Multimedia +Framework plugins.

      The player and recorder interfaces +of both audio and video and also the audio converter interface use +the controller plugins provided by the MMF Controller Framework. These +plugins provide the functionality to convert, interpret, and play +audio and video data. The resultant data from the plugins can then +be directed to one or more sinks such as a file, or directly to a +screen or lower level device driver.

      The video recorder interface +can also interact with the Onboard Camera, through a video controller +plugin, to capture video. For more information about capturing video, +see Video Capture +Tutorial.

      Note: Tone player and audio streaming +are also provided as part of the MMF but do not interact with controller +plugins. Input and output is already in a known data format and so +does not require a plugin for encoding or decoding. As a result, they +bypass the MMF Controller Framework.

      Media Device Framework

      Media Device Framework is the +layer below the controller plugins and above the hardware. It provides +a layer of abstraction for the audio and video hardware. The MDF consists +of DevSound, for audio input and output, and DevVideo for video.

      For more information about DevSound, see DevSound Overview. For more information about DevVideo, see DevVideo Overview.

      DRM Support

      The Symbian platform provides support +for playback of Digital Rights Management (DRM) protected audio and +video content by making use of the Content Access Framework (CAF). +For more information about the CAF, see Content Access Framework.

      Note: In order to access any DRM protected content +using Symbian multimedia, the client process must have the DRM capability.

      +
      Description

      The features made available by the MMF client interfaces are:

        +

      • Audio playing, +recording, and conversion - An interface consisting of three classes; CMdaAudioPlayerUtility, CMdaAudioRecorderUtility, and CMdaAudioConvertUtility. These classes provide +methods to create, play, and manipulate audio data stored in files, +descriptors, and URLs.

        • +

      • Audio streaming +- An interface consisting of two classes; CMdaAudioInputStream and CMdaAudioOutputStream. These classes provide +methods for recording and playing audio streams such as audio from +a web address.

        Note: There are no explicit interfaces +for video streaming. However, the Onboard Camera can be used to achieve +video input streaming, and direct screen access can be used to achieve +video output streaming. For more information about the Onboard Camera, +see Onboard +Camera Overview.

        • +

      • Tone playing +- An interface consisting of a single class CMdaAudioToneUtility. This class provides methods for playing and configuring single +and sequenced tones as well as DTMF (Dual Tone Multi-Frequency) strings.

        • +

      • Video playing +and recording - An interface consisting of two classes CVideoPlayerUtility and CVideoRecorderUtility. These classes provide +methods to create, play, and manipulate video clips with or without +audio tracks stored in files, descriptors, and URLs.

        • +

      Observer Classes

      For each multimedia client interface, +there is a corresponding mixin class that must be implemented by the +client. For example, to use the audio player utility you must implement +the observer mixin class MMdaAudioPlayerCallback.

      When instantiating any of the MMF interfaces, it is necessary +to provide a reference to a class that implements the appropriate +mixin class. This allows the MMF to notify the client of events that +occur and also to notify the client of errors that may occur.

      +
      Multimedia +Framework Tutorials

      The following tutorials are provided:

        +

      • How to use the audio +convert utility

        • +

      • Audio Input +Stream Tutorial

        • +

      • Audio Output Stream +Tutorial

        • +

      • Video Client Tutorials

        • +
      +
      See +Also

      Audio Client Overview

      Audio Input Stream +Overview

      Audio Output Stream +Overview

      Video Client Overview

      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6F1ED7D0-5F41-4587-89AA-8DDE7AEC916F.dita --- a/Symbian3/SDK/Source/GUID-6F1ED7D0-5F41-4587-89AA-8DDE7AEC916F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-6F1ED7D0-5F41-4587-89AA-8DDE7AEC916F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,402 +1,372 @@ - - - - -What's new in Symbian^3 -Symbian^3 introduces a lot of new features that enhance -communication, connectivity, multimedia, graphics, security and the -overall usability of Symbian devices. These features benefit operators, -application developers and device creators by making it easier to -create feature-rich devices and applications. - - - - -

      If you are moving from a older version of Symbian platform to Symbian^3, -see Porting -applications to Symbian^3.

      -
      - - - -Technology Domain -New Features - - - - -Data Communications -
        -

      • FreeWay or Three Plane Comms Architecture: The Symbian -platform now supports a new IP networking architecture. The new architecture -significantly improves data flow performance and makes it easier for -third-party developers to integrate new technologies, for example -firewalls and hotspot authenticators. It also implements automatic -roaming between different access points, for example WLAN and GPRS. -For more information, see Goals of the -Comms Architecture.

        • -

      • One-Click Connectivity (OCC): The Symbian platform now -provides a new way of managing data connections on the Symbian platform. -OCC builds on the existing Application Level Roaming (ALR) solution. -This feature makes the user's interaction with "connecting" and "select -access point" dialogs significantly simple and easier. For more information, -see Extended -Connection Preferences.

        • -
       -       - -Device Connectivity -
        -

      • MTP Device Services Extension Specification: The Symbian -MTP implementation now supports the MTP device services extension -to the Media Transfer Protocol (MTP). For more information, see MTP Device Services Extension Specification.

        • -

      • AVRCP (Audio/Video Remote Control Profile) v1.4 Support: A Symbian device user can now see music track names and browse playlists -directly from the screen of a AVRCP v1.4 enabled Bluetooth headset -or remote control.

        • -

      • Centralized AT-command Handling: The Symbian platform -now enables all AT commands to be handled using the same mechanism -regardless of the connection type. For more information, refer to -the AT Extension Plug-in API.

        • -
       -       - -Device Management -
        -

      • Support for Open Mobile Alliance (OMA) Management Objects -(MO): The Symbian platform now supports OMA MO like Software Component -Management Object (SCOMO) v1.0, Device Capability Management Object -(DCMO) v1.0 and Connectivity Management Object (ConnMO). It also supports -Nokia Standard Streaming MO. Some enhancements have been made to Browser -MO and Email MO.

        • -

      • Other Device Management Enhancements: The Symbian platform -now provides an improved device Lock with security and an enhanced -firmware update installation experience.

        • -
       -       - -Location -
        -

      • Landmark-based URL Parser: The Symbian platform now -supports a parser that converts between landmark objects and URLs. -The parser supports a URL format that is compliant with Ovi Maps. -For more information, see CPosLandmarkParser.

        • -

      • New Management Object (MO) for A-GPS: The Symbian platform -now provides an enhancement to Secure User Plane Location (SUPL) now -allows the service provider to provide two access points for a SUPL -server in the MO. This improves the system stability because it acts -as a fallback mechanism in case one of the access points is unavailable.

        • -

      • Support for Application Processor Engine (APE) Centric Location -Architecture: Symbian devices can now use the new architecture -based on the APE that offers standardized session IDs on network privacy -and classes that use the SUPL. The architecture converges technology -from OS, middleware and application software layers.

        • -

      • Support for Location Based Services (LBS) SUPL Positioning -Module (PSY): The Symbian platform now enables the LBS SUPL PSY -to allow GPS-enabled devices to handle network-based SUPL location -requests. This includes Cell ID based positioning and assistance data -exchange as part of SUPL v2.0. .

        • -

      • Support for GPSCost5.0D and GPSCost4.0D GPS chipsets: The Symbian platform now uses the APE-centric architecture to support -GPSCost5.0D and GPSCost4.0D chipsets. A new A-GPS Nokia Positioning -Engine (NPE) integration module replaces the OS LBS subsystem reference -A-GPS version.

        • -

      • Support for LBS SUPL Radio Resource LCS Protocol (RRLP): The Symbian platform now uses the APE-centric architecture to support -NPE and RRLP on GPS-enabled device.

        • -

      • SUPL 2.0 Trigger Support: The Symbian platform now provides -SUPL 2.0 trigger support that allows the requester to receive location -updates periodically, which is both network and device initiated.

        • -

      • Location-based Triggering Enhancements: The Symbian -platform now includes key enhancements that enable integration with -an Context framework to develop plug-ins and increase support for -total and active triggers. An enhanced, dedicated common gateway interface -enables the client to provide multiple CGIs to create a trigger, which -is fired on successful matching with at least one CGI.

        • -

      • Enhanced Location Acquisition API to support LocationKnownPositionArea.

        • -

      • Here and Now: The Symbian platform now includes Here -and now that offers easy-to-use Web services related to the user's -current location. Here and now allows the user to check the local -weather and get other topical information while on the move.

        • -
       -       - -Multimedia -
        -

      • Mobile TV DVB-H Receiver HAI: Mobile TV Receiver is -a small internal system but does so much more than traditional TV. -It is broadcasted in a multi-grounded environment with high speed -by using low battery power and low memory usage. .

        • -

      • OpenMAX IL: OpenMAX IL is a low-level interface used -in mobile devices that allows the Multimedia Device Framework (MDF) -to load, control, connect and unload audio, video and imaging components. -.

        • -

      • Thin Adaptation of A3F DevSound: The A3F DevSound is -one of the key component in the Sound Device collection that provides -access to the hardware accelerator in audio technology. For more information, -see A3F -DevSound Component.

        • -

      • Image Processor library: The Image Processor is an independent -and high-level API and framework which is developed for mobile imaging. -The Image Processor has some pluggable advanced image editing libraries -to perform the Panoramic Stitching function and the Speed View function. -For more information, see Image Processor -Library.

        • -

      • Camera API Extensions: The Camera API is extended to -support the features such as background processing, continuous digital -zooming, time nudge image capturing and automatic aperture setting. -For more information, see Camera Library.

        • -

      • Camera Support for Video Encoding: The Camera supports -mobile device to capture video frames which are encoded in the H264 -format. For more information, see Using the Encoded -H264 Video Frames to Capture Video.

        • -

      • 3GP File Format Library: The 3GP Library component is -a Multimedia plug-in which supports for reading and writing 3GP, 3G2, -and MP4 files. The 3GP Library is also extended to support larger -3GP or MP4 files. .

        • -

      • Video Playback from Non-user Interface Thread: Media -Client Video Display is a standalone library used by the Video Client -library to support video playback. For more information, see Media Client -Video Display Library.

        • -

      • Video Subtitle CRP: Displays artwork on a video window -using the Video Subtitle CRP component. The Subtitle Graphic library -displays subtitles artwork on the screen through its interaction with -Client Process, Controller Process and WServ Process. For more information, -see Video -Subtitle CRP Component.

        • -

      • Dolby Digital Audio Support: The Symbian platform now -supports codecs that enable support for Dolby Digital Audio on Symbian -devices.

        • -

      • True Pause in Audio Playback: In the audio playback -request the true pause feature is implemented to stop the audio data -at the physical sound device without stopping the buffer traffic. -For more information, see Pausing and -Resuming Audio Play.

        • -

      • Global Surface Updates: The Video Render component is -extended to support the global surface updates. For more information, -see Global -Surface Updates.

        • -

      • Metadata Utility Library: The Metadata Utility library -belongs to the Metadata Utility Framework (MUF) component that provides -fast metadata access to audio, video and image media files. For more -information, see the Metadata Utility -Library section.

        • -

      • UI Patterns or Thumbnails Enhancement: This is a Multimedia -specific pattern enhancement, which includes many UI (User Interface) -features, listed below:

          -

        • Multiple customized Home Screens with 6 different widget enabled -screens.

          • -

        • Pinch zoom, kinetic scrolling and single-click features.

          • -

        • Good screen view with a new UI theme, and renewed icons.

          • -

        • Hardware acceleration with fast and responsive UI that creates -new transition effects.

          • -

        • Multitasking with Teleport visual task swapper.

          • -

        • Intelligent slide functionality for Hybrid touch and QWERTY -slider devices. Video Graphics Array (VGA) Touch supports for VGA -QWERTY mono blocks.

          • -

        • VGA Touch helps to control Music player.

          • -
        • -

      • Mobile TV: Mobile TV uses DVB-H receiver to consume -broadcast digital mobile television. The Symbian platform provides -fast and easy access to all videos and TV media content. One key press -opens videos and TV application suite, and user scrolls and selects -the desired video functionality. This media experience is built with -major components such as Videos and TV, video player and Mobile TV. -Videos and TV support high quality video up to 720 per resolution -at 12 Mbps and 30 frames per second.

        • -

      • Image Viewer Application: The Image Viewer application -is used when the client opens an image file for viewing. File Manager, -Messaging, Camcorder and Browser S60 components use the Image Viewer -application. It supports Extended ICL JPEG API, which enables a faster -and less memory-consuming way to rotate and zoom images.

        • -

      • FM Radio: The FM Radio application is used to listen -FM radio broadcast over the air. FM radio broadcast is a free service.

        • -

      • Video Sharing: Using the video sharing service, both -call users can start sharing their device live camera view or pre-recorded -video clip during a normal circuit switched (CS) voice call. The video -sharing feature allows the user to upgrade and downgrade their call -with one-way video at times of need. The video sharing application -uses the Multimedia Comms Engine API.

        • -
       -       - -Multimedia Applications -
        -

      • High-Definition Multimedia Interface (HDMI): The Symbian -platform now supports HDMI technology. HDMI is supported as an external -accessory for audio and video playback for a great television playback -experience. It provides improved data performance and is ideal for -streaming high definition audio and video. The 720p resolution is -supported in still image and video viewing. 5+1 channel audio is also -supported.

        • -

      • Home Music Widgets: The Symbian platform now provides -music information through Home Screen Music Widgets. The Home Music -Widgets controls from the Home Screen menu system enables to play -and pause the playing track. The Music Widget supports the Radio Player -and includes the Music Suite Matrix Menu. This menu is configured -through XML and by default supports to launch the functionality listed -below:

          -

        • The last played song

          • -

        • The music collection view

          • -

        • A music shop, or to open the FM radio

          • -
        • -

      • Fusion Player Application: The Symbian platform now -introduces the Fusion Player, which replaces the existing Media Player -and Video Center applications. It enables access to both online video -services and locally stored videos. If DVB-H device is available, -live TV viewing is also possible. The main features supported by the -Fusion player application are as follows:

          -

        • To browse stored videos and to see metadata features of the -video, such as title, thumbnail DRM info, size or play-time.

          • -

        • To check videos that are pre-installed with the device.

          • -

        • To play stored video file in the device.

          • -
        • -
       -       - -OS Base Services -
        -

      • Writable Data Paging (WDP): The Symbian platform now -supports WDP. This enables efficient use of memory and allows multiple -applications to run at the same time without physically adding more -RAM to the hardware. This leads to a more responsive system when switching -between a number of running applications. .

        • -

      • Symmetric multiprocessor (SMP): The Symbian platform -now supports SMP for multi-core processors, such as the ARM Cortex -A9. This allows device integrators to prototype and prove ARM-based -SMP platforms.

        • -

      • 64-bit file server: The Symbian platform now supports -files larger than 2 GB.

        • -
       -       - -Productivity -
        -

      • Nokia Messaging for Social Networks: Nokia Messaging -Social Networking service is a Nokia-hosted consumer service that -provides easy and affordable mobile access to popular social networking -communities.

        • -

      • Enhanced Calendar UI Architecture: Calendar UI architecture -has changed to improve flexibility of calendar for regional, religious, -custom-tailors and xSP calendar service needs. Multiple storages are -also supported. For more information, see Calendar Guide.

        • -

      • CalDAV Protocol: Calendar application now supports the -CalDAV Protocol, which is an open calendar synchronization standard -contributed by SUN Microsystems. This enables a user to access scheduling -information on remote servers.

        • -

      • Enhanced Contacts Application: The Contacts application -in this release includes the following changes:

          -

        • Integration with social media.

          • -

        • Support for Remote Contacts Lookup, for example, from post-installed -Mail for Exchange account.

          • -

        • Virtual Phonebook API (supports getting access to the user’s -own contact card).

          • -

        • Own contact card.

          • -
        • -
       -       - -Runtimes -
        -

      • The Symbian platform now supports the Open Source based Java -MIDP 2.1.

        • -

      • The Symbian platform now supports Browser Application v7.2 -(with Web Run Time 7.2) that includes the following features:

          -

        • Browser Control

          • -

        • Browser core features

          • -

        • Browser Customization

          • -

        • Browser plug-ins

          • -

        • Browser with touch screen

          • -

        • Content Download

          • -

        • URI Schemes

          • -

        • Display Resolution Optimizations

          • -

        • Optical Finger Navigation (OFN)

          • -

        • FlashLite 3.1

          • -

        • Search Client Integration

          • -

        • Expanding Language and Character Set Support

          • -

        • Improved Security Prompting

          • -

        • Updated Platform Service APIs

          • -

        • Visual Task Swapper Support

          • -

        • Performance Optimizations

          • -

        • Multiple touch/pinch zooming

          • -
        • -
       -       - -Security -The Symbian platform now provides an enhanced Security subsystem -that enables device creators to integrate hardware acceleration modules, -which improves the performance of cryptographic algorithms. This is -particularly valuable in intensive real-time use-cases, such as streaming -audio or video over a secure link, where bulk data needs to be encrypted -and decrypted. - - -User Interface -
        -

      • ScreenPlay, also known as the New Graphics Architecture -(NGA): This new graphics architecture enables device creators -to take advantage of improved software performance, hardware acceleration -and third party graphics engines. It makes it possible to combine -UI components, graphics and video to create highly innovative UIs. -For more information, see The ScreenPlay -Graphics Architecture.

        • -

      • Multiple Touch Support: The ScreenPlay version of the -Window Server has been extended to support multiple advanced pointers, -with support for proximity and pressure. The emulator now also supports -multiple advanced pointers. For more information, see Advanced Pointers.

        • -

      • Enhanced Touch UI: The touch UI includes the following -improvements:

          -

        • Multi-page Home Screen enables the user to navigate between -widgets with a simple flick gesture

          • -

        • Capacitive multiple touch events are supported.

          • -

        • Tactile Feedback utilizes advanced haptics effects.

          • -
        • -

      For more information about the new features in Graphics, see What's New in -Graphics in Symbian^3.

       -       - - -
      - - - -New C++ APIs in Symbian^3 -Porting applications to Symbian^3 -Introduction to Symbian^3 - - - - + + + + + +What's new in Symbian^3Symbian^3 introduces a lot of new features that enhance +communication, connectivity, multimedia, graphics, security and the +overall usability of Symbian devices. These features benefit operators, +application developers and device creators by making it easier to +create feature-rich devices and applications. +

      If you are moving from a older version of Symbian platform to Symbian^3, +see Porting +applications to Symbian^3.

      + + + + +Technology Domain +New Features + + + + +Data Communications +
        +

      • FreeWay or Three Plane Comms Architecture: The Symbian +platform now supports a new IP networking architecture. The new architecture +significantly improves data flow performance and makes it easier for +third-party developers to integrate new technologies, for example +firewalls and hotspot authenticators. It also implements automatic +roaming between different access points, for example WLAN and GPRS. +For more information, see Goals of the Comms +Architecture.

        • +

      • One-Click Connectivity (OCC): The Symbian platform now +provides a new way of managing data connections on the Symbian platform. +OCC builds on the existing Application Level Roaming (ALR) solution. +This feature makes the user's interaction with "connecting" and "select +access point" dialogs significantly simple and easier. For more information, +see Extended +Connection Preferences.

        • +
       +       + +Device Connectivity +
        + + + +

      • MTP Device Services Extension Specification: The Symbian +MTP implementation now supports the MTP device services extension +to the Media Transfer Protocol (MTP). For more information, see MTP Device Services Extension Specification.

        • +

      • AVRCP (Audio/Video Remote Control Profile) v1.4 Support: A Symbian device user can now see music track names and browse playlists +directly from the screen of a AVRCP v1.4 enabled Bluetooth headset +or remote control.

        • +

      • Centralized AT-command Handling: The Symbian platform +now enables all AT commands to be handled using the same mechanism +regardless of the connection type. For more information, refer to +the AT Extension Plug-in API.

        • +
       +       + +Device Management +
        +

      • Support for Open Mobile Alliance (OMA) Management Objects +(MO): The Symbian platform now supports OMA MO like Software Component +Management Object (SCOMO) v1.0, Device Capability Management Object +(DCMO) v1.0 and Connectivity Management Object (ConnMO). It also supports +Nokia Standard Streaming MO. Some enhancements have been made to Browser +MO and Email MO.

        • +

      • Other Device Management Enhancements: The Symbian platform +now provides an improved device Lock with security and an enhanced +firmware update installation experience.

        • +
       +       + +Location +
        +

      • Landmark-based URL Parser: The Symbian platform now +supports a parser that converts between landmark objects and URLs. +The parser supports a URL format that is compliant with Ovi Maps. +For more information, see CPosLandmarkParser.

        • +

      • New Management Object (MO) for A-GPS: The Symbian platform +now provides an enhancement to Secure User Plane Location (SUPL) now +allows the service provider to provide two access points for a SUPL +server in the MO. This improves the system stability because it acts +as a fallback mechanism in case one of the access points is unavailable.

        • +

      • Support for Application Processor Engine (APE) Centric Location +Architecture: Symbian devices can now use the new architecture +based on the APE that offers standardized session IDs on network privacy +and classes that use the SUPL. The architecture converges technology +from OS, middleware and application software layers.

        • +

      • Support for Location Based Services (LBS) SUPL Positioning +Module (PSY): The Symbian platform now enables the LBS SUPL PSY +to allow GPS-enabled devices to handle network-based SUPL location +requests. This includes Cell ID based positioning and assistance data +exchange as part of SUPL v2.0. .

        • +

      • Support for GPSCost5.0D and GPSCost4.0D GPS chipsets: The Symbian platform now uses the APE-centric architecture to support +GPSCost5.0D and GPSCost4.0D chipsets. A new A-GPS Nokia Positioning +Engine (NPE) integration module replaces the OS LBS subsystem reference +A-GPS version.

        • +

      • Support for LBS SUPL Radio Resource LCS Protocol (RRLP): The Symbian platform now uses the APE-centric architecture to support +NPE and RRLP on GPS-enabled device.

        • +

      • SUPL 2.0 Trigger Support: The Symbian platform now provides +SUPL 2.0 trigger support that allows the requester to receive location +updates periodically, which is both network and device initiated.

        • +

      • Location-based Triggering Enhancements: The Symbian +platform now includes key enhancements that enable integration with +an Context framework to develop plug-ins and increase support for +total and active triggers. An enhanced, dedicated common gateway interface +enables the client to provide multiple CGIs to create a trigger, which +is fired on successful matching with at least one CGI.

        • +

      • Enhanced Location Acquisition API to support LocationKnownPositionArea.

        • +

      • Here and Now: The Symbian platform now includes Here +and now that offers easy-to-use Web services related to the user's +current location. Here and now allows the user to check the local +weather and get other topical information while on the move.

        • +
       +       + +Multimedia +
        +

      • Mobile TV DVB-H Receiver HAI: Mobile TV Receiver is +a small internal system but does so much more than traditional TV. +It is broadcasted in a multi-grounded environment with high speed +by using low battery power and low memory usage. .

        • +

      • OpenMAX IL: OpenMAX IL is a low-level interface used +in mobile devices that allows the Multimedia Device Framework (MDF) +to load, control, connect and unload audio, video and imaging components. .

        • +

      • Thin Adaptation of A3F DevSound: The A3F DevSound is +one of the key component in the Sound Device collection that provides +access to the hardware accelerator in audio technology. For more information, +see A3F DevSound +Component.

        • +

      • Image Processor library: The Image Processor is an independent +and high-level API and framework which is developed for mobile imaging. +The Image Processor has some pluggable advanced image editing libraries +to perform the Panoramic Stitching function and the Speed View function. +For more information, see Image Processor Library.

        • +

      • Camera API Extensions: The Camera API is extended to +support the features such as background processing, continuous digital +zooming, time nudge image capturing and automatic aperture setting. +For more information, see Camera Library.

        • +

      • Camera Support for Video Encoding: The Camera supports +mobile device to capture video frames which are encoded in the H264 +format. For more information, see Using the Encoded +H264 Video Frames to Capture Video.

        • +

      • 3GP File Format Library: The 3GP Library component is +a Multimedia plug-in which supports for reading and writing 3GP, 3G2, +and MP4 files. The 3GP Library is also extended to support larger +3GP or MP4 files. .

        • +

      • Video Playback from Non-user Interface Thread: Media +Client Video Display is a standalone library used by the Video Client +library to support video playback. For more information, see Media Client Video +Display Library.

        • +

      • Video Subtitle CRP: Displays artwork on a video window +using the Video Subtitle CRP component. The Subtitle Graphic library +displays subtitles artwork on the screen through its interaction with +Client Process, Controller Process and WServ Process. For more information, +see Video Subtitle +CRP Component.

        • +

      • Dolby Digital Audio Support: The Symbian platform now +supports codecs that enable support for Dolby Digital Audio on Symbian +devices.

        • +

      • True Pause in Audio Playback: In the audio playback +request the true pause feature is implemented to stop the audio data +at the physical sound device without stopping the buffer traffic. +For more information, see Pausing and Resuming +Audio Play.

        • +

      • Global Surface Updates: The Video Render component is +extended to support the global surface updates. For more information, +see Global +Surface Updates.

        • +

      • Metadata Utility Library: The Metadata Utility library +belongs to the Metadata Utility Framework (MUF) component that provides +fast metadata access to audio, video and image media files. For more +information, see the Metadata Utility +Library section.

        • +

      • UI Patterns or Thumbnails Enhancement: This is a Multimedia +specific pattern enhancement, which includes many UI (User Interface) +features, listed below:

          +

        • Multiple customized Home Screens with 6 different widget enabled +screens.

          • +

        • Pinch zoom, kinetic scrolling and single-click features.

          • +

        • Good screen view with a new UI theme, and renewed icons.

          • +

        • Hardware acceleration with fast and responsive UI that creates +new transition effects.

          • +

        • Multitasking with Teleport visual task swapper.

          • +

        • Intelligent slide functionality for Hybrid touch and QWERTY +slider devices. Video Graphics Array (VGA) Touch supports for VGA +QWERTY mono blocks.

          • +

        • VGA Touch helps to control Music player.

          • +
        • +

      • Mobile TV: Mobile TV uses DVB-H receiver to consume +broadcast digital mobile television. The Symbian platform provides +fast and easy access to all videos and TV media content. One key press +opens videos and TV application suite, and user scrolls and selects +the desired video functionality. This media experience is built with +major components such as Videos and TV, video player and Mobile TV. +Videos and TV support high quality video up to 720 per resolution +at 12 Mbps and 30 frames per second.

        • +

      • Image Viewer Application: The Image Viewer application +is used when the client opens an image file for viewing. File Manager, +Messaging, Camcorder and Browser S60 components use the Image Viewer +application. It supports Extended ICL JPEG API, which enables a faster +and less memory-consuming way to rotate and zoom images.

        • +

      • FM Radio: The FM Radio application is used to listen +FM radio broadcast over the air. FM radio broadcast is a free service.

        • +

      • Video Sharing: Using the video sharing service, both +call users can start sharing their device live camera view or pre-recorded +video clip during a normal circuit switched (CS) voice call. The video +sharing feature allows the user to upgrade and downgrade their call +with one-way video at times of need. The video sharing application +uses the Multimedia Comms Engine API.

        • +
       +       + +Multimedia Applications +
        +

      • High-Definition Multimedia Interface (HDMI): The Symbian +platform now supports HDMI technology. HDMI is supported as an external +accessory for audio and video playback for a great television playback +experience. It provides improved data performance and is ideal for +streaming high definition audio and video. The 720p resolution is +supported in still image and video viewing. 5+1 channel audio is also +supported.

        • +

      • Home Music Widgets: The Symbian platform now provides +music information through Home Screen Music Widgets. The Home Music +Widgets controls from the Home Screen menu system enables to play +and pause the playing track. The Music Widget supports the Radio Player +and includes the Music Suite Matrix Menu. This menu is configured +through XML and by default supports to launch the functionality listed +below:

          +

        • The last played song

          • +

        • The music collection view

          • +

        • A music shop, or to open the FM radio

          • +
        • +

      • Fusion Player Application: The Symbian platform now +introduces the Fusion Player, which replaces the existing Media Player +and Video Center applications. It enables access to both online video +services and locally stored videos. If DVB-H device is available, +live TV viewing is also possible. The main features supported by the +Fusion player application are as follows:

          +

        • To browse stored videos and to see metadata features of the +video, such as title, thumbnail DRM info, size or play-time.

          • +

        • To check videos that are pre-installed with the device.

          • +

        • To play stored video file in the device.

          • +
        • +
       +       + +OS Base Services +
        +

      • Writable Data Paging (WDP): The Symbian platform now +supports WDP. This enables efficient use of memory and allows multiple +applications to run at the same time without physically adding more +RAM to the hardware. This leads to a more responsive system when switching +between a number of running applications. .

        • +

      • Symmetric multiprocessor (SMP): The Symbian platform +now supports SMP for multi-core processors, such as the ARM Cortex +A9. This allows device integrators to prototype and prove ARM-based +SMP platforms.

        • +

      • 64-bit file server: The Symbian platform now supports +files larger than 2 GB.

        • +
       +       + +Productivity +
        +

      • Nokia Messaging for Social Networks: Nokia Messaging +Social Networking service is a Nokia-hosted consumer service that +provides easy and affordable mobile access to popular social networking +communities.

        • +

      • Enhanced Calendar UI Architecture: Calendar UI architecture +has changed to improve flexibility of calendar for regional, religious, +custom-tailors and xSP calendar service needs. Multiple storages are +also supported. For more information, see Calendar Guide.

        • +

      • CalDAV Protocol: Calendar application now supports the +CalDAV Protocol, which is an open calendar synchronization standard +contributed by SUN Microsystems. This enables a user to access scheduling +information on remote servers.

        • +

      • Enhanced Contacts Application: The Contacts application +in this release includes the following changes:

          +

        • Integration with social media.

          • +

        • Support for Remote Contacts Lookup, for example, from post-installed +Mail for Exchange account.

          • +

        • Virtual Phonebook API (supports getting access to the user’s +own contact card).

          • +

        • Own contact card.

          • +
        • +
       +       + +Runtimes +
        +

      • The Symbian platform now supports the Open Source based Java +MIDP 2.1.

        • +

      • The Symbian platform now supports Browser Application v7.2 +(with Web Run Time 7.2) that includes the following features:

          +

        • Browser Control

          • +

        • Browser core features

          • +

        • Browser Customization

          • +

        • Browser plug-ins

          • +

        • Browser with touch screen

          • +

        • Content Download

          • +

        • URI Schemes

          • +

        • Display Resolution Optimizations

          • +

        • Optical Finger Navigation (OFN)

          • +

        • FlashLite 3.1

          • +

        • Search Client Integration

          • +

        • Expanding Language and Character Set Support

          • +

        • Improved Security Prompting

          • +

        • Updated Platform Service APIs

          • +

        • Visual Task Swapper Support

          • +

        • Performance Optimizations

          • +

        • Multiple touch/pinch zooming

          • +
        • +
       +       + +Security +The Symbian platform now provides an enhanced Security subsystem +that enables device creators to integrate hardware acceleration modules, +which improves the performance of cryptographic algorithms. This is +particularly valuable in intensive real-time use-cases, such as streaming +audio or video over a secure link, where bulk data needs to be encrypted +and decrypted. + + +User Interface +
        +

      • ScreenPlay, also known as the New Graphics Architecture +(NGA): This new graphics architecture enables device creators +to take advantage of improved software performance, hardware acceleration +and third party graphics engines. It makes it possible to combine +UI components, graphics and video to create highly innovative UIs. +For more information, see The ScreenPlay Graphics +Architecture.

        • + + +

      • Multiple Touch Support: The ScreenPlay version of the +Window Server has been extended to support multiple advanced pointers, +with support for proximity and pressure. The emulator now also supports +multiple advanced pointers. For more information, see Advanced Pointers.

        • + +

      • Enhanced Touch UI: The touch UI includes the following +improvements:

          +

        • Multi-page Home Screen enables the user to navigate between +widgets with a simple flick gesture

          • +

        • Capacitive multiple touch events are supported.

          • +

        • Tactile Feedback utilizes advanced haptics effects.

          • +
        • +

      For more information about the new features in Graphics, see What's New in Graphics +in Symbian^3.

       +       + + +
       + +New +C++ APIs in Symbian^3 +Porting +applications to Symbian^3 +Introduction +to Symbian^3 + +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e355771_href.png Binary file Symbian3/SDK/Source/GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e355771_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e384764_href.png Binary file Symbian3/SDK/Source/GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e384764_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e52493_href.png Binary file Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e52493_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e52636_href.png Binary file Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e52636_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e67337_href.png Binary file Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e67337_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e67478_href.png Binary file Symbian3/SDK/Source/GUID-6FE79448-5052-46F9-A74E-A128CB367697_d0e67478_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FFEC753-4006-559C-B8E9-14940CFCD012_d0e176588_href.png Binary file Symbian3/SDK/Source/GUID-6FFEC753-4006-559C-B8E9-14940CFCD012_d0e176588_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-6FFEC753-4006-559C-B8E9-14940CFCD012_d0e181613_href.png Binary file Symbian3/SDK/Source/GUID-6FFEC753-4006-559C-B8E9-14940CFCD012_d0e181613_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-700CD2E2-DBB7-40BD-BC6D-9BC79C5A0BBF_d0e5803_href.png Binary file Symbian3/SDK/Source/GUID-700CD2E2-DBB7-40BD-BC6D-9BC79C5A0BBF_d0e5803_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-700CD2E2-DBB7-40BD-BC6D-9BC79C5A0BBF_d0e5924_href.png Binary file Symbian3/SDK/Source/GUID-700CD2E2-DBB7-40BD-BC6D-9BC79C5A0BBF_d0e5924_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e238861_href.png Binary file Symbian3/SDK/Source/GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e238861_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e243820_href.png Binary file Symbian3/SDK/Source/GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e243820_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-706263D6-AAE2-40E2-B0B4-D12E253F70A8_d0e70764_href.png Binary file Symbian3/SDK/Source/GUID-706263D6-AAE2-40E2-B0B4-D12E253F70A8_d0e70764_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-706263D6-AAE2-40E2-B0B4-D12E253F70A8_d0e70789_href.png Binary file Symbian3/SDK/Source/GUID-706263D6-AAE2-40E2-B0B4-D12E253F70A8_d0e70789_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7068AB77-5C96-59A3-B975-7923FD843832.dita --- a/Symbian3/SDK/Source/GUID-7068AB77-5C96-59A3-B975-7923FD843832.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7068AB77-5C96-59A3-B975-7923FD843832.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,133 +1,126 @@ - - - - - -Hash -Table - Using Hash Table ClassesThis example application demonstrates some uses of the Hash Table -APIs of the User Library component -

      Hash table is used to construct the following:

      -
        -

      • Hash Set

        • -

      • Hash set of pointers

        • -

      • Hash map

        • -

      • Hash map of pointers

        • -
      -

      The example also demonstrates performing different operations on these -hash sets/maps, such as, inserting, finding, iterating, and removing items. -A set implements an unordered extensional set of objects and a map implements -an associative array with key and value type using probe sequence hash table.

      -

      The overview contains the following sections:

      -
        -

      • Download

        • -

      • Description

        • -

      • Class summary

        • -

      • Build

        • -
      -
      Download

      Click -on the following link to download the example: HashTableExample.zip

      Click: browse to view the example code.

      -
      Description

      Hash set

      The -application constructs a hash set by using the default hash and identity function -for integers and descriptors using the RHashSet template -class, and constructs another hash set by providing a defined custom hash -and identity functions.

      The application applies the following operations -to the hash set:

        -

      • Inserting items using -the RHashSet::Insert() function

        • -

      • Finding items using -the RHashSet::Find() function

        • -

      • Iterating items using -the RHashSet::TIter class

        • -

      • Removing items using -the RHashSet::Remove() function

        • -

      Related APIs

        -

      • RHashSet::Find()

        • -

      • RHashSet::Insert()

        • -

      • RHashSet::Remove()

        • -

      • RHashSet::TIter - A class which allows iteration -over the elements of a RHashSetclass.

        • -

      Hash set of pointers

      The -application constructs a hash set of pointers using the default hash and identity -function for integers and descriptors using the RPtrHashSet template -class, and constructs another hash set of pointers by providing a defined -custom hash and identity functions.

      The application applies the following -operations to the hash set of pointers:

        -

      • Inserting items using -the RPtrHashSet::Insert() function

        • -

      • Finding items using -the RPtrHashSet::Find() function

        • -

      • Iterating items using -the RPtrHashSet::TIter class

        • -

      • Removing items using -the RPtrHashSet::Remove() function

        • -

      Related APIs

        -

      • RPtrHashSet::Find()

        • -

      • RPtrHashSet::Insert()

        • -

      • RPtrHashSet::Remove()

        • -

      • RPtrHashSet::TIter - A class which allows iteration -over the elements of a RPtrHashSet class

        • -

      Hash map

      The -application constructs a hash map using the default hash and identity function -for integers and descriptors using the RHashMap template -class, and constructs another hash map by providing a defined custom hash -and identity functions.

      The application applies the following operations -to the hash map:

        -

      • Inserting items using -the RHashMap::Insert() function

        • -

      • Finding items using -the RHashMap::Find() function

        • -

      • Iterating items using -the RHashMap::TIter class

        • -

      • Removing items using -the RHashMap::Remove() function

        • -
        -

      • RHashMap::Find()

        • -

      • RHashMap::Insert()

        • -

      • RHashMap::Remove()

        • -

      • RHashMap::TIter - A class which allows iteration -over the elements of a RHashMap class.

        • -

      Hash map of pointers

      The -application constructs a hash map of pointers using the default hash and identity -function for integers and descriptors using the RPtrHashMap template -class, and constructs another hash map of pointers by providing a defined -custom hash and identity functions.

      The application applies the following -operations to the hash map of pointers:

        -

      • Inserting items using -the RPtrHashMap::Insert() function

        • -

      • Finding items using -the RPtrHashMap::Find() function

        • -

      • Iterating items using -the RPtrHashMap::TIter class

        • -

      • Removing items using -the RPtrHashMap::Remove() function

        • -

      Related APIs

        -

      • RPtrHashMap::Find()

        • -

      • RPtrHashMap::Insert()

        • -

      • RPtrHashMap::Remove()

        • -

      • RPtrHashMap::TIter - A class which allows iteration -over the elements of a RPtrHashMap class.

        • -
      -
      Class summary
        -

      • DefaultHash - A set of common hashing functions -for frequently occurring types.

        • -

      • DefaultIdentity - A set of common identity relations -for frequently occurring types.

        • -

      • THashFunctions32

        • -

      • TIdentityRelation

        • -

      • RHashSet

        • -

      • RPtrHashMap

        • -
      -
      Build

      The Symbian build process describes -how to build an application.

      The HashTableExample builds an executable -called hashtableexample.exe in the standard location -(\epoc32\release\winscw\<build_variant> for CodeWarrior). -After launching the executable, depending on the emulator you are using, you -may need to navigate away from the application launcher/shell screen to view -the console.

      + + + + + +Hash Table - Using Hash Table ClassesThis example application demonstrates some uses of the +Hash Table APIs of the User Library component +

      Hash table is used to construct the following:

      +
        +

      • Hash Set

        • +

      • Hash set of pointers

        • +

      • Hash map

        • +

      • Hash map of pointers

        • +
      +

      The example also demonstrates performing different operations on +these hash sets/maps, such as, inserting, finding, iterating, and +removing items. A set implements an unordered extensional set of objects +and a map implements an associative array with key and value type +using probe sequence hash table.

      +

      The overview contains the following sections:

      +
        +

      • Download

        • +

      • Description

        • +

      • Class summary

        • +

      • Build

        • +
      +
      Download

      Click on the following link to download the example: HashTableExample.zip

      Click: browse to view the example code.

      +
      Description

      Hash set

      The application constructs a hash set by using the default +hash and identity function for integers and descriptors using the RHashSet template class, and constructs another hash set +by providing a defined custom hash and identity functions.

      The application applies the following operations to the hash set:

        +

      • Inserting items +using the RHashSet::Insert() function

        • +

      • Finding items +using the RHashSet::Find() function

        • +

      • Iterating items +using the RHashSet::TIter class

        • +

      • Removing items +using the RHashSet::Remove() function

        • +

      Related APIs

        +

      • RHashSet::Find()

        • +

      • RHashSet::Insert()

        • +

      • RHashSet::Remove()

        • +

      • RHashSet::TIter - A class which allows iteration +over the elements of a RHashSetclass.

        • +

      Hash set +of pointers

      The application constructs a hash set of +pointers using the default hash and identity function for integers +and descriptors using the RPtrHashSet template class, +and constructs another hash set of pointers by providing a defined +custom hash and identity functions.

      The application applies +the following operations to the hash set of pointers:

        +

      • Inserting items +using the RPtrHashSet::Insert() function

        • +

      • Finding items +using the RPtrHashSet::Find() function

        • +

      • Iterating items +using the RPtrHashSet::TIter class

        • +

      • Removing items +using the RPtrHashSet::Remove() function

        • +

      Related APIs

        +

      • RPtrHashSet::Find()

        • +

      • RPtrHashSet::Insert()

        • +

      • RPtrHashSet::Remove()

        • +

      • RPtrHashSet::TIter - A class which allows +iteration over the elements of a RPtrHashSet class

        • +

      Hash map

      The application constructs a hash map using the default +hash and identity function for integers and descriptors using the RHashMap template class, and constructs another hash map +by providing a defined custom hash and identity functions.

      The application applies the following operations to the hash map:

        +

      • Inserting items +using the RHashMap::Insert() function

        • +

      • Finding items +using the RHashMap::Find() function

        • +

      • Iterating items +using the RHashMap::TIter class

        • +

      • Removing items +using the RHashMap::Remove() function

        • +
        +

      • RHashMap::Find()

        • +

      • RHashMap::Insert()

        • +

      • RHashMap::Remove()

        • +

      • RHashMap::TIter - A class which allows +iteration over the elements of a RHashMap class.

        • +

      Hash map +of pointers

      The application constructs a hash map of pointers +using the default hash and identity function for integers and descriptors +using the RPtrHashMap template class, and constructs +another hash map of pointers by providing a defined custom hash and +identity functions.

      The application applies the following +operations to the hash map of pointers:

        +

      • Inserting items +using the RPtrHashMap::Insert() function

        • +

      • Finding items +using the RPtrHashMap::Find() function

        • +

      • Iterating items +using the RPtrHashMap::TIter class

        • +

      • Removing items +using the RPtrHashMap::Remove() function

        • +

      Related APIs

        +

      • RPtrHashMap::Find()

        • +

      • RPtrHashMap::Insert()

        • +

      • RPtrHashMap::Remove()

        • +

      • RPtrHashMap::TIter - A class which allows +iteration over the elements of a RPtrHashMap class.

        • +
      +
      Class +summary
        +

      • DefaultHash - A set of common hashing functions +for frequently occurring types.

        • +

      • DefaultIdentity - A set of common identity +relations for frequently occurring types.

        • +

      • THashFunctions32

        • +

      • TIdentityRelation

        • +

      • RHashSet

        • +

      • RPtrHashMap

        • +
      +
      Build

      The Symbian build process describes how to build an application.

      The HashTableExample builds an executable called hashtableexample.exe in the standard location (\epoc32\release\winscw\<build_variant> for CodeWarrior). +After launching the executable, depending on the emulator you are +using, you may need to navigate away from the application launcher/shell +screen to view the console.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E1117B-17F0-5CF4-A5D0-35D3BEBB0FEA.dita --- a/Symbian3/SDK/Source/GUID-70E1117B-17F0-5CF4-A5D0-35D3BEBB0FEA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-70E1117B-17F0-5CF4-A5D0-35D3BEBB0FEA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,52 +9,49 @@ --> -Position -Area Data ClassesThis document describes the basic and extended position area data -classes that contain information about the accuracy of the position returned -to an application when it calls RPositioner::GetLastKnownPositionArea(). -

      LBS maintains a cache of previously calculated position fixes. If an application -calls RPositioner::GetLastKnownLocation(), LBS returns -the most recently calculated position. If an application calls RPositioner::GetLastKnownPositionArea(), -LBS returns the position fix that is the best match for the current location -of the mobile device. The current location of the mobile device is estimated -from data received from the network.

      -

      The Location Acquisition API defines a set of position area data classes -(figure 1). A client application passes an object of one of these classes -as a parameter when it calls RPositioner::GetLastKnownPositionArea(). -The position area data classes are defined in LbsAreaInfo.h.

      +Position Area Data ClassesThis document describes the basic and extended position +area data classes that contain information about the accuracy of the +position returned to an application when it calls RPositioner::GetLastKnownPositionArea(). +

      LBS maintains a cache of previously calculated position fixes. +If an application calls RPositioner::GetLastKnownLocation(), LBS returns the most recently calculated position. If an application +calls RPositioner::GetLastKnownPositionArea(), +LBS returns the position fix that is the best match for the current +location of the mobile device. The current location of the mobile +device is estimated from data received from the network.

      +

      The Location Acquisition API defines a set of position area data +classes (figure 1). A client application passes an object of one of +these classes as a parameter when it calls RPositioner::GetLastKnownPositionArea(). The position area data classes are defined in LbsAreaInfo.h.

      Figure 1. Position Area Data Classes. - + -

      A brief description of the classes follows. Follow the links to more detailed -reference documentation.

      +

      A brief description of the classes follows. Follow the links to +more detailed reference documentation.

        -

      • TPositionAreaInfoBase is -the base class of the position area data classes. Applications create an object -of one of the derived classes.

        • -

      • TPositionAreaInfo contains -basic information about the accuracy of a returned position. Its defines an -enumerated type TPositionAreaInfo::_TArea that defines -an estimate of how closely the current device position matches the returned -position. The position accuracy estimate can be from country level down to -street level, depending on how much information is available from the network.

        • -

      • TPositionAreaExtendedInfo extends TPositionAreaInfo to -provide details about how the accuracy estimate of the returned position was -calculated.

        An accuracy estimate can be obtained from the network -as some combination of the following:

          -

        • Mobile Country Code

          • -

        • Mobile Network Code

          • -

        • Location Area Code

          • +

        • TPositionAreaInfoBase is the base class of the position area data classes. Applications +create an object of one of the derived classes.

          • +

        • TPositionAreaInfo contains basic information about the accuracy of a returned position. +Its defines an enumerated type TPositionAreaInfo::_TArea that defines an estimate of how closely the current device position +matches the returned position. The position accuracy estimate can +be from country level down to street level, depending on how much +information is available from the network.

          • +

        • TPositionAreaExtendedInfo extends TPositionAreaInfo to provide details about +how the accuracy estimate of the returned position was calculated.

          An accuracy estimate can be obtained from the network as some +combination of the following:

            +

          • Mobile Country +Code

            • +

          • Mobile Network +Code

            • +

          • Location Area +Code

          • Cell ID

            • -

          LBS uses combinations of the above to derive the accuracy estimate -returned from TPositionAreaInfo::Area(). Your application -can find what types of data were used to calculate the accuracy estimate by -passing an object of class TPositionAreaExtendedInfo to RPositioner::GetLastKnownLocationArea() and -then using the methods shown in figure 1 to check for code and ID matches.

          • +

        LBS uses combinations of the above to derive the accuracy +estimate returned from TPositionAreaInfo::Area(). Your application can find what types of data were used to calculate +the accuracy estimate by passing an object of class TPositionAreaExtendedInfo to RPositioner::GetLastKnownLocationArea() and +then using the methods shown in figure 1 to check for code and ID +matches.

      - -How to Get -Location Information +How +to Get Location Information       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e60390_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e60390_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e60533_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e60533_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e62839_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e62839_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e62982_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e62982_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e68784_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e68784_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e68808_href.png Binary file Symbian3/SDK/Source/GUID-70E92884-004F-43B5-B740-B0C95E8E401C_d0e68808_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70FC2D13-493D-433F-9CFB-ACF9F512513F_d0e69973_href.png Binary file Symbian3/SDK/Source/GUID-70FC2D13-493D-433F-9CFB-ACF9F512513F_d0e69973_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-70FC2D13-493D-433F-9CFB-ACF9F512513F_d0e69996_href.png Binary file Symbian3/SDK/Source/GUID-70FC2D13-493D-433F-9CFB-ACF9F512513F_d0e69996_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-712DF59D-FAE1-592E-82A6-4E323676F5B8.dita --- a/Symbian3/SDK/Source/GUID-712DF59D-FAE1-592E-82A6-4E323676F5B8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-712DF59D-FAE1-592E-82A6-4E323676F5B8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,7 +27,7 @@ The diagram above shows the encryption and decryption process using: a symmetric algorithm; a plaintext message, M; a symmetric key, K; and the ciphertext, K(M). - +

      So it provides secrecy and also some kind of authentication. If Alice encrypts a secret using a key known only to her, then only she can access the secrets.

      It can also be used for communication: if Alice shares @@ -138,16 +138,16 @@ for block and stream ciphers respectively. Also shown are the following derived classes: CBufferedDecryptor, CBufferedEncryptor, CARC4, and CNullCipher. - +

      CBlockTransformation and derived classes

      The inheritance diagram above shows the <xref href="GUID-CFDA5321-EE13-3203-8DED-71E69D4469BD.dita"><apiname>CBlockTransformation</apiname></xref> abstract base class used for block ciphers. Also shown are the following derived classes: <xref href="GUID-436C3EBE-FC60-3760-A3BA-D8DF8FA5B8AF.dita"><apiname>CBlockChainingMode</apiname></xref>, <xref href="GUID-C65A1F55-A8D2-3393-8DC1-35656017E2B8.dita"><apiname>CModeCBCEncryptor</apiname></xref>, <xref href="GUID-7D5FBD2C-83A0-351A-96B3-C5C54FE525E6.dita"><apiname>CModeCBCDecryptor</apiname></xref>, <xref href="GUID-1C18ED2F-085F-3C3E-A93E-5FD37461E440.dita"><apiname>CDES</apiname></xref>, <xref href="GUID-E7401D77-AD0E-3B8F-A7CC-23ADA5151DB6.dita"><apiname>CDESEncryptor</apiname></xref>, <xref href="GUID-249270AC-907B-3E46-AFDB-131FDC6F612A.dita"><apiname>CDESDecryptor</apiname></xref>, <xref href="GUID-90A671B0-756E-3773-8429-6441D1594F4B.dita"><apiname>C3DES</apiname></xref>, <xref href="GUID-B931DBB9-4484-33FD-9E94-6F256ABD5C68.dita"><apiname>C3DESEncryptor</apiname></xref>, <xref href="GUID-C693C22D-04C5-3C9E-8605-0EA90F723AF3.dita"><apiname>C3DESDecryptor</apiname></xref>, <xref href="GUID-BEE18CDE-CFB6-3116-9FAE-046780D4D006.dita"><apiname>CRC2</apiname></xref>, <xref href="GUID-19F20C86-5722-3A35-B17D-3830D18CC7FC.dita"><apiname>CRC2Encryptor</apiname></xref>, <xref href="GUID-E6FD8DF9-258B-39BC-8C39-ABF7434A29B5.dita"><apiname>CRC2Decryptor</apiname></xref>, <xref href="GUID-B0AEE24A-91A6-335E-AD64-C9DDCC1F81A9.dita"><apiname>CRijndael</apiname></xref>, <xref href="GUID-AE1A9AC0-DB79-3C62-AA23-896812F25F14.dita"><apiname>CAESEncryptor</apiname></xref>, and <xref href="GUID-51666543-0256-3E0D-BF5F-8716753C5921.dita"><apiname>CAESDecryptor</apiname></xref>. - +

      CPadding and derived classes

      Above is an inheritance diagram showing the CPadding abstract base class used with block ciphers. Also shown are the following derived classes: <xref href="GUID-B7090C61-ECC7-3E8A-8D19-75C9170B0135.dita"><apiname>CPaddingPKCS7</apiname></xref>, <xref href="GUID-3150ECC9-CF8E-3890-91CD-87F5EBCE550E.dita"><apiname>CPaddingPKCS1Encryption</apiname></xref>, <xref href="GUID-F845CB30-7ABE-3EB6-B1B9-C72581897D0C.dita"><apiname>CRSAPKCS1v15Encryptor</apiname></xref>, <xref href="GUID-57C40DCA-8340-38B5-9777-2863C8F88B59.dita"><apiname>CPaddingNone</apiname></xref>, <xref href="GUID-723F64D1-01C5-3A03-B987-0FB862EE8EDE.dita"><apiname>CPaddingPKCS1Signature</apiname></xref>, and <xref href="GUID-CC2347BE-3272-3DDF-8BDD-B44F5C0026B3.dita"><apiname>CPaddingSSLv3</apiname></xref> - +
      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-715E0EA4-8B3D-5DDF-B773-922E367B114F.dita --- a/Symbian3/SDK/Source/GUID-715E0EA4-8B3D-5DDF-B773-922E367B114F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-715E0EA4-8B3D-5DDF-B773-922E367B114F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Audio Input Streaming Overview

      This document provides an overview of Audio Input Streaming.

      Purpose

      Audio Input Streaming is the interface to streaming sampled audio data from the low level audio controller part of the Multimedia Framework (MMF).

      Audio Input Streaming Library Details

      The DLL that provides the functionality and the library to which your code must link is identified below.

      DLL LIB Short Description

      mediaclientaudioinputstream.dll

      mediaclientaudioinputstream.lib

      These files are used for implementing Audio Input Streaming.

      Architectural Relationship

      How the Audio Input Streaming classes interact with other components of MMF is shown below:

      Audio input streaming overview -
      Description

      Streamed audio data is sent and received incrementally. This means:

      • sound clips sent to the low level audio controller (audio play) can be sent as they arrive rather than waiting until the entire clip is received.

        The user of the API should maintain the data fragments in a queue before sending them to the server. If the user attempts to send data faster than the server can receive it, the excess data fragments are maintained in another client side queue (invisible to the user), whose elements are references to the buffers passed to it. The server notifies the client using a callback each time it has received a data fragment. This indicates to the client that the data fragment can be deleted.

      • sound clips that are being captured by the low level audio controller (audio record) can be read incrementally without having to wait until audio capture is complete.

        The low level audio controller maintains the received buffers where it can place the audio data that is being captured. The client uses a read function to read the received data into destination descriptors.

      The client is also notified (for audio play and record) when the stream is opened and available for use (opening takes place asynchronously), and when the stream is closed.

      This API can only be used to stream audio data, with the data being stored or sourced from a descriptor. Client applications must ensure that the data is in 16 bit PCM format as this is the only format supported. The API does not support mixing. A priority mechanism is used to control access to the sound device by more than one client.

      Key Audio Input Streaming Classes

      The functionality provided by Audio Input Streaming is contained within the CMdaAudioInputStream class.

      Using Audio Input Streaming

      Clients can use Audio Input Streaming to:

      • Open, set audio and mobile equipment properties, read from and close the audio stream.

      See Also

      Audio Input Streaming Tutorial

      \ No newline at end of file +
      Description

      Streamed audio data is sent and received incrementally. This means:

      • sound clips sent to the low level audio controller (audio play) can be sent as they arrive rather than waiting until the entire clip is received.

        The user of the API should maintain the data fragments in a queue before sending them to the server. If the user attempts to send data faster than the server can receive it, the excess data fragments are maintained in another client side queue (invisible to the user), whose elements are references to the buffers passed to it. The server notifies the client using a callback each time it has received a data fragment. This indicates to the client that the data fragment can be deleted.

      • sound clips that are being captured by the low level audio controller (audio record) can be read incrementally without having to wait until audio capture is complete.

        The low level audio controller maintains the received buffers where it can place the audio data that is being captured. The client uses a read function to read the received data into destination descriptors.

      The client is also notified (for audio play and record) when the stream is opened and available for use (opening takes place asynchronously), and when the stream is closed.

      This API can only be used to stream audio data, with the data being stored or sourced from a descriptor. Client applications must ensure that the data is in 16 bit PCM format as this is the only format supported. The API does not support mixing. A priority mechanism is used to control access to the sound device by more than one client.

      Key Audio Input Streaming Classes

      The functionality provided by Audio Input Streaming is contained within the CMdaAudioInputStream class.

      Using Audio Input Streaming

      Clients can use Audio Input Streaming to:

      • Open, set audio and mobile equipment properties, read from and close the audio stream.

      See Also

      Audio Input Streaming Tutorial

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71B31715-3B6A-50F0-86C1-8F7F76985802_d0e169108_href.jpg Binary file Symbian3/SDK/Source/GUID-71B31715-3B6A-50F0-86C1-8F7F76985802_d0e169108_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71B31715-3B6A-50F0-86C1-8F7F76985802_d0e174122_href.jpg Binary file Symbian3/SDK/Source/GUID-71B31715-3B6A-50F0-86C1-8F7F76985802_d0e174122_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9.dita --- a/Symbian3/SDK/Source/GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,6 +9,6 @@ --> -The Font and Bitmap Server OverviewThe Font and Bitmap Server (FBServ) provides a memory efficient way of using bitmaps and fonts. It stores a single instance of each bitmap in either a shared heap or in eXecute In Place (XIP) ROM and provides clients with read and (when appropriate) write access.

      RAM-based fonts and bitmaps are reference counted and retained in RAM while they are being used. When they are no longer required they are automatically deleted.

      Key terms
      Bitmap

      A two-dimensional (2D) buffer (in memory) that contains the color values for individual pixels and is encapsulated by the CFbsBitmap class.

      Extended bitmap

      A bitmap that contains data compressed using proprietary formats.

      Raster image

      A data structure representing a rectangular grid of pixels. Scaling raster images usually leads to a loss of quality.

      Vector image

      The use of geometrical primitives such as points, lines, curves and polygons to represent an image. Vector images can be scaled without loss of quality.

      Rasterization

      The process of converting vector image drawing instructions into a raster image that can be displayed on the screen.

      Scan line

      A row of pixels in a raster image. This use of the term is derived from its original use in a raster scanning pattern, such as a video line on the cathode ray tube (CRT) display of a television.

      For font-related terms, see Font and Text Services Collection Overview.

      Architectural relationships

      The Font and Bitmap Server is tightly integrated with the BitGDI and Window Server components. It provides client-side classes for fonts, bitmaps and the typeface store.

      In use the Font and Bitmap Server is largely transparent. When a client of the Window Server opens a Window Server session, that session silently creates an RFbsSession and stores it in Thread Local Storage (TLS). Client-side font and bitmap classes such as CFbsFont and CFbsBitmap automatically find the session in TLS when they are constructed. (These are client-side objects that refer to objects in the server. Because they are heap-based classes, they have names beginning with C.)

      The Font and Bitmap Server contains the font store, which is a separate DLL provided by the Font Store (FntStore) component. Client-side access to the font store is through CFbsTypefaceStore.

      Description

      The Font and Bitmap Server is a singleton process that owns fonts and bitmaps. CFbsFont and CFbsBitmap objects are actually client-side handles to the font and bitmap objects, which are stored on a globally accessible heap while they are in use. Bitmap data is stored separately in a globally accessible disconnected chunk.

      When the reference count of clients using a font or bitmap that is resident in RAM falls to zero, the server can delete it and free the memory. XIP ROM based bitmaps are accessed in place, not copied into RAM.

      Open fonts, which are stored in font files as vector data, must be rasterized into the Font and Bitmap Server's shared heap. Rasterizers are plug-ins to the Font Store component. There is a performance overhead to rasterizing an open font and a memory overhead for storing it.

      API summary

      The Font and Bitmap Server presents a conventional client API through RFbsSession, which represents the handle to a server-side session. The classes CFbsFont and CFbsBitmap are client-side representations of font and bitmap classes.

      • The CFbsFont class represents fonts managed by the Font and Bitmap Server, both bitmap fonts and OpenType fonts.

      • The CFbsBitmap class represents bitmaps managed by the Font and Bitmap Server, both RAM and XIP ROM-based bitmaps. For RAM-based bitmaps, this class provides facilities for creating, loading, saving, and resizing bitmaps. RAM-based bitmaps are commonly loaded from a multi-bitmap file (.mbm) file or created as off-screen bitmaps, and then blitted to a window. For XIP ROM-based bitmaps, CFbsBitmap provides facilities for accessing the data.

      The Font and Bitmap Server is unusual in that the RFbsSession is stored in client-side thread local storage (TLS). The constructors for CFbsFont and CFbsBitmap find this session handle automatically: the client program does not have to pass it as a parameter. Therefore, to most client programs, the client/server nature of using fonts and bitmaps is hidden from the API.

      The RFbsSession is created for clients by the Window Server’s client-side API when a Window Server session, RWsSession, is constructed. A Window Server client is therefore also a client of the Font and Bitmap Server.

      When a client calls, for example, the CWindowGc::DrawBitmap() function, the handle number of the bitmap is passed to the Window Server through inter-process communication (IPC). Like all CWindowGc drawing commands, the handle number is stored in a client-side command buffer, which by default is flushed to the server side only when it is full. Once flushed to the server-side, the command buffer is processed by the Window Server rendering loop. Consider the scenario where an application calls CWindowGc::DrawBitmap() and then closes the bitmap before the client-side buffer is flushed. There needs to be some mechanism to prevent the bitmap’s reference count from reaching zero and hence being deleted before the Window Server can render it. For this reason, RFbsSession has a callback, which is invoked whenever a client closes a bitmap handle. The callback causes an immediate flush of the Window Server client-side command buffer. The Window Server then creates on the server side a duplicate CFbsBitmap for the bitmap. This increases the bitmap's reference count and therefore prevents it from being deleted before the Window Server attempts to render it. The same mechanism applies to font handles. This mechanism is transparent to clients of the Window Server.

      Font and Bitmap Server Collection Heap Locking in the Font and Bitmap +The Font and Bitmap Server OverviewThe Font and Bitmap Server (FBServ) provides a memory efficient way of using bitmaps and fonts. It stores a single instance of each bitmap in either a shared heap or in eXecute In Place (XIP) ROM and provides clients with read and (when appropriate) write access.

      RAM-based fonts and bitmaps are reference counted and retained in RAM while they are being used. When they are no longer required they are automatically deleted.

      Key terms
      Bitmap

      A two-dimensional (2D) buffer (in memory) that contains the color values for individual pixels and is encapsulated by the CFbsBitmap class.

      Extended bitmap

      A bitmap that contains data compressed using proprietary formats.

      Raster image

      A data structure representing a rectangular grid of pixels. Scaling raster images usually leads to a loss of quality.

      Vector image

      The use of geometrical primitives such as points, lines, curves and polygons to represent an image. Vector images can be scaled without loss of quality.

      Rasterization

      The process of converting vector image drawing instructions into a raster image that can be displayed on the screen.

      Scan line

      A row of pixels in a raster image. This use of the term is derived from its original use in a raster scanning pattern, such as a video line on the cathode ray tube (CRT) display of a television.

      For font-related terms, see Font and Text Services Collection Overview.

      Architectural relationships

      The Font and Bitmap Server is tightly integrated with the BitGDI and Window Server components. It provides client-side classes for fonts, bitmaps and the typeface store.

      In use the Font and Bitmap Server is largely transparent. When a client of the Window Server opens a Window Server session, that session silently creates an RFbsSession and stores it in Thread Local Storage (TLS). Client-side font and bitmap classes such as CFbsFont and CFbsBitmap automatically find the session in TLS when they are constructed. (These are client-side objects that refer to objects in the server. Because they are heap-based classes, they have names beginning with C.)

      The Font and Bitmap Server contains the font store, which is a separate DLL provided by the Font Store (FntStore) component. Client-side access to the font store is through CFbsTypefaceStore.

      Description

      The Font and Bitmap Server is a singleton process that owns fonts and bitmaps. CFbsFont and CFbsBitmap objects are actually client-side handles to the font and bitmap objects, which are stored on a globally accessible heap while they are in use. Bitmap data is stored separately in a globally accessible disconnected chunk.

      When the reference count of clients using a font or bitmap that is resident in RAM falls to zero, the server can delete it and free the memory. XIP ROM based bitmaps are accessed in place, not copied into RAM.

      Open fonts, which are stored in font files as vector data, must be rasterized into the Font and Bitmap Server's shared heap. Rasterizers are plug-ins to the Font Store component. There is a performance overhead to rasterizing an open font and a memory overhead for storing it.

      API summary

      The Font and Bitmap Server presents a conventional client API through RFbsSession, which represents the handle to a server-side session. The classes CFbsFont and CFbsBitmap are client-side representations of font and bitmap classes.

      • The CFbsFont class represents fonts managed by the Font and Bitmap Server, both bitmap fonts and OpenType fonts.

      • The CFbsBitmap class represents bitmaps managed by the Font and Bitmap Server, both RAM and XIP ROM-based bitmaps. For RAM-based bitmaps, this class provides facilities for creating, loading, saving, and resizing bitmaps. RAM-based bitmaps are commonly loaded from a multi-bitmap file (.mbm) file or created as off-screen bitmaps, and then blitted to a window. For XIP ROM-based bitmaps, CFbsBitmap provides facilities for accessing the data.

      The Font and Bitmap Server is unusual in that the RFbsSession is stored in client-side thread local storage (TLS). The constructors for CFbsFont and CFbsBitmap find this session handle automatically: the client program does not have to pass it as a parameter. Therefore, to most client programs, the client/server nature of using fonts and bitmaps is hidden from the API.

      The RFbsSession is created for clients by the Window Server’s client-side API when a Window Server session, RWsSession, is constructed. A Window Server client is therefore also a client of the Font and Bitmap Server.

      When a client calls, for example, the CWindowGc::DrawBitmap() function, the handle number of the bitmap is passed to the Window Server through inter-process communication (IPC). Like all CWindowGc drawing commands, the handle number is stored in a client-side command buffer, which by default is flushed to the server side only when it is full. Once flushed to the server-side, the command buffer is processed by the Window Server rendering loop. Consider the scenario where an application calls CWindowGc::DrawBitmap() and then closes the bitmap before the client-side buffer is flushed. There needs to be some mechanism to prevent the bitmap’s reference count from reaching zero and hence being deleted before the Window Server can render it. For this reason, RFbsSession has a callback, which is invoked whenever a client closes a bitmap handle. The callback causes an immediate flush of the Window Server client-side command buffer. The Window Server then creates on the server side a duplicate CFbsBitmap for the bitmap. This increases the bitmap's reference count and therefore prevents it from being deleted before the Window Server attempts to render it. The same mechanism applies to font handles. This mechanism is transparent to clients of the Window Server.

      Font and Bitmap Server Collection Heap Locking in the Font and Bitmap Server Font and Text Services Collection Overview Font Store Component Overview       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71DCEB48-8E8C-59A0-A99F-23245FF2DF13.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-71DCEB48-8E8C-59A0-A99F-23245FF2DF13.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,52 @@ + + + + + +timezoneconversion: Time Zone Conversion Example +
      Download

      Click on the following link to download the example: TZExample.zip

      Click: browse to view the example code.

      +
      Description

      This example code first connects to the time zone server (class RTz). Then it uses RTz::ConvertToLocalTime() to convert a UTC time to local time. The time to convert and the +time zone to convert it to are randomly chosen. This demonstrates +that the time zone server can convert any time, past, present or future, +for any time zone, as long as a rule exists for the conversion. Conversion +rules are stored in a native Symbian database that is a compressed +form of the Olson time zone database (http://www.twinsun.com/tz/tz-link.htm). The database can be configured by phone manufacturers to save +space.

      The example then converts the current local time for +the system time zone to the current local time for a different time +zone. This is a two stage process. First, the local time is converted +to UTC using RTz::ConvertToUniversalTime(). When +converting between local and UTC times for the current system time +zone, there is no need to specify the time zone ID. Then UTC is converted +to local time for the other time zone. Before the example terminates, +the connection to the server is closed.

      No special capabilities +are needed to do time zone conversion.

      Class CTzId identifies a time zone. It stores the identifier either as text, +(for instance Australia/Sydney), or as a number. Numeric time zone +IDs are assigned by the phone manufacturer, so can vary from phone +to phone.

      For efficiency, the time zone server caches a copy +of a range of conversion rules for the current time zone. These cached +rules are actualised, meaning they have been expanded from +the encoded compact format as stored in the database, so are quicker +to access.

      Class CTzConverter, which is +not used in this example, provides an alternative conversion API to RTz. It caches 5 years' worth of conversion rules for a +specific time zone (either the time zone specified in the conversion +function, or the system time zone), on the client side, so avoiding +the need for an an IPC call for each conversion. CTzConverter is more efficient than RTz when doing multiple +conversions for a single time zone.

      +
      Usage

      This is a console application, so does not have a GUI. It builds +an executable called TZExample.exe in the standard +location (\epoc32\release\winscw\<build_variant> for CodeWarrior). After launching the executable, depending on the +emulator you are using, you may need to task away from the app launcher/shell +screen to view the console.

      +
      Class +Summary
        +

      • RTz

        • +

      • CTzId

        • +

      • ESock::TTime

        • +
      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71E64F3E-40CB-560B-A482-CA92C7FD1AA2_d0e200807_href.png Binary file Symbian3/SDK/Source/GUID-71E64F3E-40CB-560B-A482-CA92C7FD1AA2_d0e200807_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-71E64F3E-40CB-560B-A482-CA92C7FD1AA2_d0e205814_href.png Binary file Symbian3/SDK/Source/GUID-71E64F3E-40CB-560B-A482-CA92C7FD1AA2_d0e205814_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7226154E-2387-5D14-A009-2A1A60617970.dita --- a/Symbian3/SDK/Source/GUID-7226154E-2387-5D14-A009-2A1A60617970.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -nostrictdef

      nostrictdef

      By default, for wide builds, the build tools expect the .def files for the project to have a u suffix: e.g. myprojectu.def. If the nostrictdef statement is specified, the u suffix will not be applied to the frozen .def file.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e40348_href.png Binary file Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e40348_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e40506_href.png Binary file Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e40506_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e66754_href.png Binary file Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e66754_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e66897_href.png Binary file Symbian3/SDK/Source/GUID-72262200-B940-4D0C-8FA0-6628E9894E8F_d0e66897_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-722FAAAD-AD14-4139-857E-83B639FDEB58_d0e65056_href.png Binary file Symbian3/SDK/Source/GUID-722FAAAD-AD14-4139-857E-83B639FDEB58_d0e65056_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-722FAAAD-AD14-4139-857E-83B639FDEB58_d0e65199_href.png Binary file Symbian3/SDK/Source/GUID-722FAAAD-AD14-4139-857E-83B639FDEB58_d0e65199_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7235E4E9-0046-4BE1-91CF-BD52CE4489DF.dita --- a/Symbian3/SDK/Source/GUID-7235E4E9-0046-4BE1-91CF-BD52CE4489DF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7235E4E9-0046-4BE1-91CF-BD52CE4489DF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ Note that there should be no more than three links in a single query.

      Message query - +
      Using message queries in applications

      For implementation information, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-726E3025-173C-4A91-8959-49F11DACA92B.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-726E3025-173C-4A91-8959-49F11DACA92B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,15 @@ + + + + + +Time +zone services examples +

      This section demonstrates Time Zone Services examples.

      + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-727E6071-591B-539E-997C-BC0CC5B62A11_d0e135705_href.png Binary file Symbian3/SDK/Source/GUID-727E6071-591B-539E-997C-BC0CC5B62A11_d0e135705_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-727E6071-591B-539E-997C-BC0CC5B62A11_d0e139310_href.png Binary file Symbian3/SDK/Source/GUID-727E6071-591B-539E-997C-BC0CC5B62A11_d0e139310_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7287F1D4-023E-5C90-91E1-6D8DF78D8241.dita --- a/Symbian3/SDK/Source/GUID-7287F1D4-023E-5C90-91E1-6D8DF78D8241.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7287F1D4-023E-5C90-91E1-6D8DF78D8241.dita Tue Jul 20 12:00:49 2010 +0100 @@ -58,10 +58,10 @@ section as the second diagram shows.

      User process 1's view. - + User process 2's view. - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7293765E-2B1E-5F0D-B6A8-0E48729DC365_d0e188567_href.png Binary file Symbian3/SDK/Source/GUID-7293765E-2B1E-5F0D-B6A8-0E48729DC365_d0e188567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7293765E-2B1E-5F0D-B6A8-0E48729DC365_d0e193538_href.png Binary file Symbian3/SDK/Source/GUID-7293765E-2B1E-5F0D-B6A8-0E48729DC365_d0e193538_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72B7B5CC-2E04-53CE-8414-C362DFD40D52_d0e229035_href.png Binary file Symbian3/SDK/Source/GUID-72B7B5CC-2E04-53CE-8414-C362DFD40D52_d0e229035_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72B7B5CC-2E04-53CE-8414-C362DFD40D52_d0e234020_href.png Binary file Symbian3/SDK/Source/GUID-72B7B5CC-2E04-53CE-8414-C362DFD40D52_d0e234020_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72F24867-8D67-5BD1-A8C4-93FC7A4290FC_d0e201561_href.png Binary file Symbian3/SDK/Source/GUID-72F24867-8D67-5BD1-A8C4-93FC7A4290FC_d0e201561_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-72F24867-8D67-5BD1-A8C4-93FC7A4290FC_d0e206568_href.png Binary file Symbian3/SDK/Source/GUID-72F24867-8D67-5BD1-A8C4-93FC7A4290FC_d0e206568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-73491C1D-6C74-5434-B2F3-4AF416AE37B7.dita --- a/Symbian3/SDK/Source/GUID-73491C1D-6C74-5434-B2F3-4AF416AE37B7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-73491C1D-6C74-5434-B2F3-4AF416AE37B7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -82,7 +82,7 @@ main classes used in the hash framework. For information on each class see the Cryptography API Reference material.

      Inheritance diagram for the Hash API - +

      The hash API is used internally by the Security components: AppInst, Certman (Certificate Management) and Cryptography. Networking/TLS uses a pseudo-random function (PRF) based on HMAC. Both MD5 and SHA-1 are used in TLS.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-736F9C4B-7C70-5927-A9C9-21A127C431AF_d0e31753_href.png Binary file Symbian3/SDK/Source/GUID-736F9C4B-7C70-5927-A9C9-21A127C431AF_d0e31753_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-736F9C4B-7C70-5927-A9C9-21A127C431AF_d0e31932_href.png Binary file Symbian3/SDK/Source/GUID-736F9C4B-7C70-5927-A9C9-21A127C431AF_d0e31932_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-738FADA9-E26F-53F1-A6D6-2E82019DDA1F.dita --- a/Symbian3/SDK/Source/GUID-738FADA9-E26F-53F1-A6D6-2E82019DDA1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-738FADA9-E26F-53F1-A6D6-2E82019DDA1F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ 1

      Alphabet of the Default GSM7 Turkish Single Converter - +

    • Turkish Locking GSM7 Extension Converter. The highlighted boxes in Figure 2 show that it supports @@ -35,7 +35,7 @@ 2

      Alphabet of the Turkish Locking GSM7 Extension Converter - +

    • Turkish Locking Single Converter. The highlighted boxes in Figure 3 show that it supports the Turkish @@ -46,7 +46,7 @@ 3

      Alphabet of the Turkish Locking Single Converter - +

    Note: For all of the converters, any undefined Unicode is converted to a question mark (?)–GSM code 0x37. Any code diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-739556F5-A2F3-5548-943C-7D50785DFB48_d0e360653_href.png Binary file Symbian3/SDK/Source/GUID-739556F5-A2F3-5548-943C-7D50785DFB48_d0e360653_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-739556F5-A2F3-5548-943C-7D50785DFB48_d0e389657_href.png Binary file Symbian3/SDK/Source/GUID-739556F5-A2F3-5548-943C-7D50785DFB48_d0e389657_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-73A431EF-44CA-5E62-AF3F-1601CFD2484F_d0e323663_href.jpg Binary file Symbian3/SDK/Source/GUID-73A431EF-44CA-5E62-AF3F-1601CFD2484F_d0e323663_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-73A431EF-44CA-5E62-AF3F-1601CFD2484F_d0e330133_href.jpg Binary file Symbian3/SDK/Source/GUID-73A431EF-44CA-5E62-AF3F-1601CFD2484F_d0e330133_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7461BD6A-F50B-5E14-8995-CF3F2D8F5F14_d0e363544_href.png Binary file Symbian3/SDK/Source/GUID-7461BD6A-F50B-5E14-8995-CF3F2D8F5F14_d0e363544_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7461BD6A-F50B-5E14-8995-CF3F2D8F5F14_d0e382693_href.png Binary file Symbian3/SDK/Source/GUID-7461BD6A-F50B-5E14-8995-CF3F2D8F5F14_d0e382693_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-74B329CD-4640-5636-9D8D-20F0D7E09EB4_d0e189164_href.png Binary file Symbian3/SDK/Source/GUID-74B329CD-4640-5636-9D8D-20F0D7E09EB4_d0e189164_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-74B329CD-4640-5636-9D8D-20F0D7E09EB4_d0e194135_href.png Binary file Symbian3/SDK/Source/GUID-74B329CD-4640-5636-9D8D-20F0D7E09EB4_d0e194135_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-74E94DC3-88C7-51BE-9354-C49B3A7A8B03.dita --- a/Symbian3/SDK/Source/GUID-74E94DC3-88C7-51BE-9354-C49B3A7A8B03.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -exportlibrary

    exportlibrary lib-name

    This allows the name of the .lib file generated to be explicitly specified, overriding the default name derived from the TARGET that would otherwise be used.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-74F1EBB6-293A-4B33-A08F-46F3C23B37CE.dita --- a/Symbian3/SDK/Source/GUID-74F1EBB6-293A-4B33-A08F-46F3C23B37CE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-74F1EBB6-293A-4B33-A08F-46F3C23B37CE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ items accordingly.

    Adaptive search - +
    Using adaptive search in applications

    The APIs to use for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7501D3AC-16FB-58E9-B55C-2598ECCD2FFA_d0e362101_href.png Binary file Symbian3/SDK/Source/GUID-7501D3AC-16FB-58E9-B55C-2598ECCD2FFA_d0e362101_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7501D3AC-16FB-58E9-B55C-2598ECCD2FFA_d0e381250_href.png Binary file Symbian3/SDK/Source/GUID-7501D3AC-16FB-58E9-B55C-2598ECCD2FFA_d0e381250_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-751F057B-BF6D-5B28-A47A-3E99B25731CF.dita --- a/Symbian3/SDK/Source/GUID-751F057B-BF6D-5B28-A47A-3E99B25731CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,21 +0,0 @@ - - - - - -unpaged -

    unpaged

    -

    Use the unpaged statement to specify that the executable -is not paged. This is the same as specifying both unpagedcode and unpageddata keywords -for an executable.

    -

    You can also mark an executable as unpaged using the OBY file keyword file[[HWVD]]. -For more information about the file[[HWVD]] keyword, refer to the ROM Tools -Guide in the Application Development Toolkit available for download at http://developer.symbian.org. -

    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-75553219-500C-487F-8D7E-0FAF48CF1872.dita --- a/Symbian3/SDK/Source/GUID-75553219-500C-487F-8D7E-0FAF48CF1872.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-75553219-500C-487F-8D7E-0FAF48CF1872.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ menu pop-up window) as a submenu.

    Submenu in the Options menu - +

    The submenu is opened by pressing either the left softkey (Select), the Selection key, or the Arrow right key. In touch enabled device, submenu diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-75AFF4B9-1F95-585E-9354-EAA6271251FA.dita --- a/Symbian3/SDK/Source/GUID-75AFF4B9-1F95-585E-9354-EAA6271251FA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to troubleshoot post-linker (elf2e32) errors

    The post-linker (elf2e32.exe) is a Symbian platform build tool that is run after the compiler and linker when a project is built. Its principal function is to create executables (DLLs and EXEs) in the particular format required by Symbian platform, known as the E32Image format.

    In ordinary use, the post-linker is called by the make files constructed by abld or an IDE. The options with which the tool is called depend on your settings of the project being built (i.e. as specified in the project MMP file). Error and warning messages reported by the tool can indicate a problem with these settings. This page contains some help on interpreting these messages correctly.

    Error

    Action

    DEF File <position> is not in proper format

    This indicates a syntax error in an input DEF file. You need to edit or regenerate the DEF file to correct this.

    ELF File <file> contains initialized writable data

    By default, Symbian platform DLL's may not contain writable static data. You should change the project's source code to remove such items. For suggestions on alternatives, see Static data.

    ELF File <file> contains uninitialized writable data

    By default, Symbian platform DLL's may not contain writable static data. You should change the project's source code to remove such items. For suggestions on alternatives, see Static data.

    Ordinal number is not in sequence

    The symbol is indicates that the input DEF file has been incorrectly edited, so that the symbols are not listed in consecutive ordinal order. You need to edit or regenerate the DEF file to correct this.

    Note that if you intended to remove an export from a frozen DEF file, this should be done by using the ABSENT keyword, for example:

    _ZNK14Foo14BarLER12CStreamStore @ 646 NONAME ABSENT

    Symbol <symbol> missing from ELF File

    The input DEF file, specified by a MMP deffile statement, specifies an export that is not found in the executable.

    If no binary compatibility break was intended, you should either correct your source to export the missing symbol. If a compatibility break was intended, you should fix the DEF file.

    If you are not concerned with maintaining compatibility, use exportunfrozen in the project. This will stop the tool reporting this error.

    Unrecognized capability

    Check that the platform security capabilities, specified by a MMP capability statement, are correctly spelled. Symbian OS v9.0 Security Architecture lists the available capabilities.

    Unsupported Target Type <type>

    Check that the target type, specified by a MMP targettype statement, is correctly specified. The targettype reference page lists the available target types.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-762A665F-43D0-53ED-B698-0CBD3AC46391.dita --- a/Symbian3/SDK/Source/GUID-762A665F-43D0-53ED-B698-0CBD3AC46391.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-762A665F-43D0-53ED-B698-0CBD3AC46391.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ can select fonts from the Font Store. Device creators can create and add fonts. The Font and Text Services collection - + Font and diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-763DCEF4-C960-58A2-99DC-7FFD3187BFD4.dita --- a/Symbian3/SDK/Source/GUID-763DCEF4-C960-58A2-99DC-7FFD3187BFD4.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -The native build targets \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7681734D-1291-59A3-B226-BC58403FA8A0.dita --- a/Symbian3/SDK/Source/GUID-7681734D-1291-59A3-B226-BC58403FA8A0.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -targetpath

    targetpath target-path

    Use the targetpath statement to specify where the project should be released.

    • for non-Win32 platforms, or for Win32 platforms when no release path is specified, the target will be released to

      epoc32\release\ platform \ variant \

    • for Win32 platforms, when a target path is specified, that path will be interpreted as a location on the z: drive, and the release path will therefore be

      epoc32\release\ platform \ variant \z\ target-path \

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita --- a/Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -45,7 +45,7 @@ a class derived from CSIPResolvedClient or CSIPResolvedClient2 to receive requests outside the SIP dialogs. If the target client is not running, it must be started to enable it to receive SIP requests.

    - +

    CSIPResolvedClient

    The target clients must implement the CSIPResolvedClient interface to receive SIP requests outside SIP dialogs and enable the client resolution mechanism.

    SIP diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-76901D63-BDA2-4DCA-A66C-7BAFD7E211EB_d0e68916_href.png Binary file Symbian3/SDK/Source/GUID-76901D63-BDA2-4DCA-A66C-7BAFD7E211EB_d0e68916_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-76901D63-BDA2-4DCA-A66C-7BAFD7E211EB_d0e68940_href.png Binary file Symbian3/SDK/Source/GUID-76901D63-BDA2-4DCA-A66C-7BAFD7E211EB_d0e68940_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-76B4C4D2-75A5-4139-9186-23443C68CD8F_d0e36126_href.png Binary file Symbian3/SDK/Source/GUID-76B4C4D2-75A5-4139-9186-23443C68CD8F_d0e36126_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-76B4C4D2-75A5-4139-9186-23443C68CD8F_d0e36293_href.png Binary file Symbian3/SDK/Source/GUID-76B4C4D2-75A5-4139-9186-23443C68CD8F_d0e36293_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-76FD2A71-E8A3-4C82-9704-3F7F6AD4DFD8.dita --- a/Symbian3/SDK/Source/GUID-76FD2A71-E8A3-4C82-9704-3F7F6AD4DFD8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-76FD2A71-E8A3-4C82-9704-3F7F6AD4DFD8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,13 +9,12 @@ --> -Navi -pane +Navi pane

    The principal uses of the Navi pane are to display information about the current state and view, and to help the user to navigate in the application.

    - + Navi pane - +

    Depending on the context, the Navi pane contains elements presented in the following table.

    @@ -32,8 +31,9 @@

    Tabs

    Tabs are used to view parallel data views alternatively. Arrow indicators -are used only for navigation texts.

    Each tab has either a graphic or -a text (or both) as a label. The following tab layouts can be used:

      +are shown at both ends of the pane when there are further tabs to scroll in +the corresponding direction. Each tab has either a graphic or a text (or both) +as a label. The following tab layouts can be used:

      • Two tabs

      • Three tabs

      • Four tabs

        • @@ -47,7 +47,7 @@

        Navigation text (icon+text)

        - +

        Navigation text is displayed in the Navi pane when similar items can be browsed by scrolling horizontally, such as dates in Calendar. @@ -55,7 +55,7 @@

        Indicators

        - +

        In editors, the Navi pane contains editing indicators. See Indicators for @@ -63,9 +63,9 @@

        Folder structure indication

        - +         -

        Opened sub-folders are indicated in the Navi pane.

         +

        Opened subfolders are indicated in the Navi pane.

        Application-specific content

         @@ -74,61 +74,21 @@

        Empty pane

        - +

        The Navi pane can be empty.

                 -

        -Default touch -events for ungrouped soft notification - - - -

        User action

         -

        State change

         -

        Feedback

         -         - - - -

        Touch down on navigation text or navigation arrow

         -

        Application specific

         -

        Tactile: In case of activity, basic button effect and audio feedback -is provided.

         -         - -

        Touch down and hold on navigation text

         -

        Inactive

         -

        Tactile: No effect

         -         - -

        Touch down and hold on arrows

         -

        This action performs a “key repeat”, similar to many touch downs -and releases on arrow

         -

        Tactile: Sensitive button effect and audio feedback is provided -with key repeat action.

         -         - -

        Touch release

         -

        No effect

         -

        Tactile: No effect

         -         - - -
        -

        Using -the navi pane in applications

        The API to use for the Navi pane is -the Navigation pane API. If you use tabs in the Navi pane, -the API for controlling the tabs is the Tabs API. Applications can implement an observer to handle -the touch events in the Navi pane area.

        For the indicators -in the Navi pane, use the Indicators API.

        For implementation information -on the Navi pane, see Using the Navigation pane API. For implementation information -on tabs, see Using the Tabs API.

        The MAknNaviDecoratorObserver class -provides touch support for the tab arrows in the Navi pane. To set the observer, -use the CAknNavigationDecorator::SetNaviDecoratorObserver() method.

        To -create a tab group in the Navi pane, use the CAknNavigationControlContainer::CreateTabGroupL(). -This is a factory method for a pre-implemented navigation pane tab group control.

        +
        Using the navi pane in +C++ applications

        The API to use for the Navi pane is the Navigation pane API. If you use tabs in the Navi pane, the API for +controlling the tabs is the Tabs +API.

        For the indicators in the Navi pane, use the Indicators API.

        For implementation information on the Navi pane, +see Using +the Navigation pane API. For implementation information on tabs, see Using +the Tabs API.

        The class MAknNaviDecoratorObserver provides touch support for the tab arrows in the Navi pane. To set +the observer, use the method CAknNavigationDecorator::SetNaviDecoratorObserver().

        To +create a tab group in the Navi pane, use the method CreateTabGroupL() in the class CAknNavigationControlContainer. This is a factory +method for a pre-implemented navigation pane tab group control.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7712BAB3-5F48-5A28-9EA9-104D8B4A0431_d0e333424_href.png Binary file Symbian3/SDK/Source/GUID-7712BAB3-5F48-5A28-9EA9-104D8B4A0431_d0e333424_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7712BAB3-5F48-5A28-9EA9-104D8B4A0431_d0e339890_href.png Binary file Symbian3/SDK/Source/GUID-7712BAB3-5F48-5A28-9EA9-104D8B4A0431_d0e339890_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-771AF721-E2D7-41C8-BF97-5BD30D1A28AD.dita --- a/Symbian3/SDK/Source/GUID-771AF721-E2D7-41C8-BF97-5BD30D1A28AD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-771AF721-E2D7-41C8-BF97-5BD30D1A28AD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -32,7 +32,7 @@
      Status pane areas - +

      Status pane items

      A single tap on:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-772DFFA1-4BBC-516F-909D-47CB773760F5.dita --- a/Symbian3/SDK/Source/GUID-772DFFA1-4BBC-516F-909D-47CB773760F5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-772DFFA1-4BBC-516F-909D-47CB773760F5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,31 +1,31 @@ - - - - - -Packages -as type-safe descriptorsDescribes the package function to transfer data in correct structure. -

      Descriptors are often used as the basis of data transfer within Symbian -platform. For example, inter-thread data transfer is specified in terms of -transferring data from a descriptor valid in the context of one thread, to -a descriptor valid in the context of another.

      -

      Data to be transferred almost always has a well defined structure and it -is important that the receiver of the data has some guarantee that the correct -structure has been passed. This is type safety.

      -

      A package is a descriptor and also acts as a wrapper around it. -It allows objects and data structures to be represented by descriptors in -a type safe way. Objects are either contained within a modifiable buffer descriptor -or are represented by pointer descriptors.

      -

      A package class is templated, the template parameter being the type of -the object represented. The use of a template provides the required type safety.

      -       - -Descriptor concepts - + + + + + +Packages as type-safe descriptorsDescribes the package function to transfer data in correct +structure. +

      Descriptors are often used as the basis of data transfer within +Symbian platform. For example, inter-thread data transfer is specified +in terms of transferring data from a descriptor valid in the context +of one thread, to a descriptor valid in the context of another.

      +

      Data to be transferred almost always has a well defined structure +and it is important that the receiver of the data has some guarantee +that the correct structure has been passed. This is type safety.

      +

      A package is a descriptor and also acts as a wrapper around +it. It allows objects and data structures to be represented by descriptors +in a type safe way. Objects are either contained within a modifiable +buffer descriptor or are represented by pointer descriptors.

      +

      A package class is templated, the template parameter being the +type of the object represented. The use of a template provides the +required type safety.

      +       + +Descriptor concepts       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-773A0EDC-F17C-553B-BEC3-DA990F5064B7_d0e214491_href.png Binary file Symbian3/SDK/Source/GUID-773A0EDC-F17C-553B-BEC3-DA990F5064B7_d0e214491_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-773A0EDC-F17C-553B-BEC3-DA990F5064B7_d0e219489_href.png Binary file Symbian3/SDK/Source/GUID-773A0EDC-F17C-553B-BEC3-DA990F5064B7_d0e219489_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7767599C-7B77-5DD1-8E3E-7AD01EC6F6A1.dita --- a/Symbian3/SDK/Source/GUID-7767599C-7B77-5DD1-8E3E-7AD01EC6F6A1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7767599C-7B77-5DD1-8E3E-7AD01EC6F6A1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@ aStream << iData; aStream << *iCompA; aStream << *iCompB; - }

      The stream can be visualised as:

    Storing components out-of-line

    Storing a compound object’s component objects out-of-line means writing all of its component objects to a different stream from that to which it, itself, is written. Each component may be written to its own stream or to its own network of streams. The main advantage of this is that it allows for deferred loading of streams.

    It is important to note that components are stored before the containing object.

    The following code fragment defines an example class, CCompound, having two components, CComponentA and CComponentB. The components are defined as instances of the templated class TSwizzle.

    CCompound class : public CBase + }

    The stream can be visualised as:

    Storing components out-of-line

    Storing a compound object’s component objects out-of-line means writing all of its component objects to a different stream from that to which it, itself, is written. Each component may be written to its own stream or to its own network of streams. The main advantage of this is that it allows for deferred loading of streams.

    It is important to note that components are stored before the containing object.

    The following code fragment defines an example class, CCompound, having two components, CComponentA and CComponentB. The components are defined as instances of the templated class TSwizzle.

    CCompound class : public CBase { ... TInt iDdata; @@ -47,7 +47,7 @@ map->Reset(); CleanupStack::PopAndDestroy(2); return id; - }

    The StoreL() function:

    • writes the CCompound components to their own streams.

    • writes CCompound itself and its components’ stream IDs to a single stream.

    • returns the ID of the top-level stream.

    This can be visualised as:

    CCompound ’s components are stored to their own streams by defining and implementing a StoreComponentsL() member function; this is prototyped as:

    void StoreComponentsL(CStreamStore& aStore,CStoreMap& aMap)

    and implemented as:

    void CCompound::StoreComponentsL(CStreamStore& aStore,CStoreMap& aMap) + }

    The StoreL() function:

    • writes the CCompound components to their own streams.

    • writes CCompound itself and its components’ stream IDs to a single stream.

    • returns the ID of the top-level stream.

    This can be visualised as:

    CCompound ’s components are stored to their own streams by defining and implementing a StoreComponentsL() member function; this is prototyped as:

    void StoreComponentsL(CStreamStore& aStore,CStoreMap& aMap)

    and implemented as:

    void CCompound::StoreComponentsL(CStreamStore& aStore,CStoreMap& aMap) { TStreamId id; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7767640D-5DD0-563B-8EE7-5C3EAEDBF859.dita --- a/Symbian3/SDK/Source/GUID-7767640D-5DD0-563B-8EE7-5C3EAEDBF859.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7767640D-5DD0-563B-8EE7-5C3EAEDBF859.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,12 +1,20 @@ - - - - - -UIDs

    A UID is a globally unique identifier consisting of a 32-bit number. UIDs are used throughout the Symbian platform to enable various kinds of file identification and association.

    Because UIDs are fundamental to the Symbian platform, it is important that they are used correctly when developing programs. To ensure uniqueness, it is essential that UIDs are properly allocated. Uniqueness is guaranteed by allocating UIDs centrally from a database managed by Symbian at https://www.symbiansigned.com.

    For more information on using UIDs, see How to use UIDs.

    \ No newline at end of file + + + + + +UIDs +

    A UID is a globally unique identifier consisting of a 32-bit number. +UIDs are used throughout the Symbian platform to enable various kinds +of file identification and association.

    +

    Because UIDs are fundamental to the Symbian platform, it is important +that they are used correctly when developing programs. To ensure uniqueness, +it is essential that UIDs are properly allocated. Uniqueness is guaranteed +by allocating UIDs centrally from a database managed by Symbian at https://www.symbiansigned.com.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-77EC9F20-32F4-5A1D-B183-75838EBA30B1_d0e176330_href.png Binary file Symbian3/SDK/Source/GUID-77EC9F20-32F4-5A1D-B183-75838EBA30B1_d0e176330_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-77EC9F20-32F4-5A1D-B183-75838EBA30B1_d0e181355_href.png Binary file Symbian3/SDK/Source/GUID-77EC9F20-32F4-5A1D-B183-75838EBA30B1_d0e181355_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-77F02412-00E1-59F9-A875-3147529F83F5_d0e110733_href.png Binary file Symbian3/SDK/Source/GUID-77F02412-00E1-59F9-A875-3147529F83F5_d0e110733_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-77F02412-00E1-59F9-A875-3147529F83F5_d0e110965_href.png Binary file Symbian3/SDK/Source/GUID-77F02412-00E1-59F9-A875-3147529F83F5_d0e110965_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78175610-72F4-5CAF-B1E9-9A761347C9DB.dita --- a/Symbian3/SDK/Source/GUID-78175610-72F4-5CAF-B1E9-9A761347C9DB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-78175610-72F4-5CAF-B1E9-9A761347C9DB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,31 +1,58 @@ - - - - - -Hello World: A minimal console applicationThis section describes the steps to build the Hello World project on the emulator. - -

    The code in this section has been taken from the Hello example.

    This example demonstrates the most basic use of STDLIB. It consists of the single source code file, slhello.c whose sole function, main() calls printf().

    The Hello example's project definition file (Hello.mmp) contains the following:

    TTARGET hello.exe -TARGETTYPE exe -UID 0 -SOURCEPATH . -SOURCE slhello.c -SYSTEMINCLUDE \epoc32\include\libc \epoc32\include - -LIBRARY estlib.lib euser.lib -STATICLIBRARY ecrt0.lib
    • The import library estlib.lib is the C standard library.
    • The project also links to ecrt0.lib. This file provides the E32Main() entrypoint for a .exe. It also provides other services including command-line parsing, and it calls main().
    • The SYSTEMINCLUDE path specifies \epoc32\include\libc\, which is the location for STDLIB's header files.
     -

    For more information on the project specification for a .exe see How to build for an EXE target.

     - To build Hello for the Emulator, run bldmake from the directory where the bld.inf file is located: - - bldmake bldfilesThis creates the <file>abld.bat</file> batch file. - Use abld to build the project, for instance:abld build wins udebTo run it, invoke hello.exeTo build Hello for the target machine, invoke bldmake and abld, specifying the appropriate target platform.To install software on the target device create a .sis file using the Symbian Installation system. See the Application Installation Guide - - - -     How to build for an EXE targetHow to use the Symbian build processApplication Installation Guide     \ No newline at end of file + + + + + +Hello +World: A minimal console applicationThis section describes the steps to build the Hello World +project on the emulator. +

    The code +in this section has been taken from the Hello example.

    This example demonstrates the most basic use of STDLIB. +It consists of the single source code file, slhello.c whose sole function, main() calls printf().

    The Hello example's project definition +file (Hello.mmp) contains the following:

    TTARGET hello.exe +TARGETTYPE exe +UID 0 +SOURCEPATH . +SOURCE slhello.c +SYSTEMINCLUDE \epoc32\include\libc \epoc32\include + +LIBRARY estlib.lib euser.lib +STATICLIBRARY ecrt0.lib
      +
    • The import library estlib.lib is the C standard library.
      • +
    • The project also links +to ecrt0.lib. This file provides the E32Main() entrypoint for a .exe. It +also provides other services including command-line parsing, and it +calls main().
      • +
    • The SYSTEMINCLUDE path specifies \epoc32\include\libc\, which +is the location for STDLIB's header files.
      • +
         + +To build Hello for the Emulator, run bldmake from the directory where the bld.inf file is +located: +bldmake bldfiles +This creates the <file>abld.bat</file> batch file. + +Use abld to build the project, for instance: +abld build wins udeb + +To run it, invoke hello.exe + +To build Hello for the target machine, invoke bldmake and abld, specifying the appropriate target platform. + +To install software +on the target device create a .sis file using +the Symbian Installation system. +See the Application Installation +Guide + + +     +Application +Installation Guide +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-781F53F0-0F84-4BF9-A565-C2E7333521CE.dita --- a/Symbian3/SDK/Source/GUID-781F53F0-0F84-4BF9-A565-C2E7333521CE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-781F53F0-0F84-4BF9-A565-C2E7333521CE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ query is launched for password.

    Data query with two input fields - +
    Using data queries with multiple fields in applications

    For implementation diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-783161AE-708E-4FB4-8219-EEC0F9939E9B_d0e55932_href.png Binary file Symbian3/SDK/Source/GUID-783161AE-708E-4FB4-8219-EEC0F9939E9B_d0e55932_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-783161AE-708E-4FB4-8219-EEC0F9939E9B_d0e56075_href.png Binary file Symbian3/SDK/Source/GUID-783161AE-708E-4FB4-8219-EEC0F9939E9B_d0e56075_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-783D0B50-0E8A-5199-A07E-749D4A71E671.dita --- a/Symbian3/SDK/Source/GUID-783D0B50-0E8A-5199-A07E-749D4A71E671.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-783D0B50-0E8A-5199-A07E-749D4A71E671.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,98 +1,136 @@ - - - - - -Processing an Extended Inquiry Response

    This tutorial shows you how to retrieve and process the data from a Bluetooth Extended Inquiry Response (EIR).

    Introduction

    This tutorial shows you how to retrieve the EIR data and how to access the various types of data within it.

    Basic Procedure

    The high level steps to access the EIR are shown here:

    1. Create the EIR object and during construction fill it with the data from the Extended Inquiry Response

    2. Use access functions to retrieve the different types of data.

    Environment

    This tutorial assumes that you have your device correctly configured, active and with Bluetooth enabled and the Bluetooth Stack initialised. iResult is in scope and contains a TNameEntry object as the result of a successful Inquiry request. See Inquiring About Remote Devices.

    Note: When the Inquiry Request is made, set the aDoEIR flag to specify that Extended Inquire Response data is required. The Bluetooth Stack will set the aDoEIR flag if an older version of the API (non-EIR) is used.

    Tutorial

    Create an object to hold the Extended Inquiry Response data

    • TBluetoothNameRecordWrapper eir(iResult());

    Use access functions to retrieve the various kinds of data

    1. Get the Bluetooth device local name

      Note: The device local name may be truncated if it is too long to fit in the EIR data packet. If the name is not truncated then the isNameComplete flag will be set to TRUE.

      -TBool isNameComplete; -TInt error = KErrNone; -TInt length = 0; - -// Get name -// This length could be used to create the TBuf to be passed into GetDeviceName() -length = eir.GetDeviceNameLength(); -TBuf<255> name; -if(length >= 0) - { - // name will contain a Unicode encoded 16-bit string - error = eir.GetDeviceName(name, isNameComplete); - } - else - { - error = length; - } -if(error == KErrNone) -// we have name here - { - if(isNameComplete == EFalse) - { - iHROutputConsole->Printf(_L("%d Bytes [Partial] Name: "), length); - } - else - { - iHROutputConsole->Printf(_L("%d Bytes [Complete] Name: "), length); - } - iHROutputConsole->Printf(_L("%S \n"),&name); - } -

    2. Get the Transmission Power level

      // Get TxPowerLevel -TInt8 txPowerLevel; -error = eir.GetTxPowerLevel(txPowerLevel); -if(error == KErrNone) - // TxPowerLevel present - { - iHROutputConsole->Printf(_L("TxPowerLevel: %ddBm\n"), txPowerLevel); - }

    3. Get the Service Class UUIDs.

      // Get UUIDs -RExtendedInquiryResponseUUIDContainer uuidContainer; -error = eir.GetServiceClassUuids(uuidContainer); -if(error >= KErrNone) - { - RArray<TUUID> uuids; - TInt uuidCount = uuidContainer.UUIDs().Count(); - if(uuidCount > 0) - { - iHROutputConsole->Printf(_L("*** UUID Count: %d\n"), uuidCount); - TInt i; - for(i=0;i<uuidCount;i++) - { - TInt j; - TPtrC8 uuid(uuidContainer.UUIDs()[i].ShortestForm()); - // Treat it as a big endian - for(j=0;j<uuid.Length();j++) - { - iHROutputConsole->Printf(_L("%02X"), uuid[j]); - } - - iHROutputConsole->Printf(_L(" \n")); - } - } - }

    4. Get Manufacturer Specific data.

      Note: This data is entirely defined by the individual Manufacturer.

      // Get Manufacturer Specific Data -length = eir.GetVendorSpecificDataLength(); -TBuf8<255> msd; -if(length > 0) - { - error = eir.GetVendorSpecificData(msd); - } -else - { - error = length; - } -if(error == KErrNone) -// we have Manufacturer Specific Data here - { - // This conversion is for display reason, in a real world this may not be necessary as - // Manufacturer specific data can be just raw 8-bit data, however GetDeviceName() is - // different as it always return Unicode encoded 16-bit string - error = CnvUtfConverter::ConvertToUnicodeFromUtf8(name, msd); - if(error >= KErrNone && length > 0) - { - iHROutputConsole->Printf(_L("%d Bytes Manufacturer Specific Data: %S\n"), length, &name); - } - } -}
    Bluetooth Extended Inquiry - Response \ No newline at end of file + + + + + +Processing an Extended Inquiry Response +

    This tutorial shows you how to retrieve and process the data from +a Bluetooth Extended Inquiry Response (EIR).

    +
    Introduction

    This tutorial shows you how +to retrieve the EIR data and how to access the various types of data +within it.

    Basic Procedure

    The high level steps to access the +EIR are shown here:

      +

    1. Create the EIR object and during construction fill it with the data +from the Extended Inquiry Response

      2. +

    2. Use access functions +to retrieve the different types of data.

      3. +
    +
    Environment

    This tutorial assumes that +you have your device correctly configured, active and with Bluetooth +enabled and the Bluetooth Stack initialised. iResult is in scope and contains a TNameEntry object +as the result of a successful Inquiry request. See Inquiring About Remote +Devices.

    Note: When the Inquiry Request is +made, set the aDoEIR flag to specify that Extended +Inquire Response data is required. The Bluetooth Stack will set the aDoEIR flag if an older version of the API (non-EIR) is +used.

    +
    Tutorial

    Create an object to hold the Extended Inquiry Response data

      +
    • TBluetoothNameRecordWrapper eir(iResult());
      • +

    Use access functions to retrieve the various kinds of data

      +

    1. Get the Bluetooth +device local name

      Note: The device local name may +be truncated if it is too long to fit in the EIR data packet. If the +name is not truncated then the isNameComplete flag +will be set to TRUE.

      +TBool isNameComplete; +TInt error = KErrNone; +TInt length = 0; + +// Get name +// This length could be used to create the TBuf to be passed into GetDeviceName() +length = eir.GetDeviceNameLength(); +TBuf<255> name; +if(length >= 0) + { + // name will contain a Unicode encoded 16-bit string + error = eir.GetDeviceName(name, isNameComplete); + } + else + { + error = length; + } +if(error == KErrNone) +// we have name here + { + if(isNameComplete == EFalse) + { + iHROutputConsole->Printf(_L("%d Bytes [Partial] Name: "), length); + } + else + { + iHROutputConsole->Printf(_L("%d Bytes [Complete] Name: "), length); + } + iHROutputConsole->Printf(_L("%S \n"),&name); + } +
      2. +

    2. Get the Transmission +Power level

      // Get TxPowerLevel +TInt8 txPowerLevel; +error = eir.GetTxPowerLevel(txPowerLevel); +if(error == KErrNone) + // TxPowerLevel present + { + iHROutputConsole->Printf(_L("TxPowerLevel: %ddBm\n"), txPowerLevel); + }
      3. +

    3. Get the Service +Class UUIDs.

      // Get UUIDs +RExtendedInquiryResponseUUIDContainer uuidContainer; +error = eir.GetServiceClassUuids(uuidContainer); +if(error >= KErrNone) + { + RArray<TUUID> uuids; + TInt uuidCount = uuidContainer.UUIDs().Count(); + if(uuidCount > 0) + { + iHROutputConsole->Printf(_L("*** UUID Count: %d\n"), uuidCount); + TInt i; + for(i=0;i<uuidCount;i++) + { + TInt j; + TPtrC8 uuid(uuidContainer.UUIDs()[i].ShortestForm()); + // Treat it as a big endian + for(j=0;j<uuid.Length();j++) + { + iHROutputConsole->Printf(_L("%02X"), uuid[j]); + } + + iHROutputConsole->Printf(_L(" \n")); + } + } + }
      4. +

    4. Get Manufacturer +Specific data.

      Note: This data is entirely defined +by the individual Manufacturer.

      // Get Manufacturer Specific Data +length = eir.GetVendorSpecificDataLength(); +TBuf8<255> msd; +if(length > 0) + { + error = eir.GetVendorSpecificData(msd); + } +else + { + error = length; + } +if(error == KErrNone) +// we have Manufacturer Specific Data here + { + // This conversion is for display reason, in a real world this may not be necessary as + // Manufacturer specific data can be just raw 8-bit data, however GetDeviceName() is + // different as it always return Unicode encoded 16-bit string + error = CnvUtfConverter::ConvertToUnicodeFromUtf8(name, msd); + if(error >= KErrNone && length > 0) + { + iHROutputConsole->Printf(_L("%d Bytes Manufacturer Specific Data: %S\n"), length, &name); + } + } +}
      5. +
    + +     +Bluetooth Extended Inquiry Response +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-785160B9-A6BC-47FA-957E-5BB87E79B4E7_d0e69648_href.png Binary file Symbian3/SDK/Source/GUID-785160B9-A6BC-47FA-957E-5BB87E79B4E7_d0e69648_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-785160B9-A6BC-47FA-957E-5BB87E79B4E7_d0e69671_href.png Binary file Symbian3/SDK/Source/GUID-785160B9-A6BC-47FA-957E-5BB87E79B4E7_d0e69671_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-786D76B7-B827-43B7-8202-BA7A7E5EE03E.dita --- a/Symbian3/SDK/Source/GUID-786D76B7-B827-43B7-8202-BA7A7E5EE03E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-786D76B7-B827-43B7-8202-BA7A7E5EE03E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,7 +37,7 @@
    Use cases Tactile feedback client API use cases - +

    To provide tactile feedback for touch events in your applications, implement the following use cases:

    • Using direct diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78989363-A405-4A1D-8F13-DC52FE6FAD80_d0e75242_href.png Binary file Symbian3/SDK/Source/GUID-78989363-A405-4A1D-8F13-DC52FE6FAD80_d0e75242_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78989363-A405-4A1D-8F13-DC52FE6FAD80_d0e75280_href.png Binary file Symbian3/SDK/Source/GUID-78989363-A405-4A1D-8F13-DC52FE6FAD80_d0e75280_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78AAEDF8-6C31-53E3-B411-3463DDAAC902_d0e79625_href.png Binary file Symbian3/SDK/Source/GUID-78AAEDF8-6C31-53E3-B411-3463DDAAC902_d0e79625_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78AAEDF8-6C31-53E3-B411-3463DDAAC902_d0e79683_href.png Binary file Symbian3/SDK/Source/GUID-78AAEDF8-6C31-53E3-B411-3463DDAAC902_d0e79683_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78B63C44-7765-5408-A611-DFE8709196F8_d0e195032_href.png Binary file Symbian3/SDK/Source/GUID-78B63C44-7765-5408-A611-DFE8709196F8_d0e195032_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-78B63C44-7765-5408-A611-DFE8709196F8_d0e200041_href.png Binary file Symbian3/SDK/Source/GUID-78B63C44-7765-5408-A611-DFE8709196F8_d0e200041_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79009102-0490-5C61-9722-C5EE49A1AF2B_d0e184827_href.png Binary file Symbian3/SDK/Source/GUID-79009102-0490-5C61-9722-C5EE49A1AF2B_d0e184827_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79009102-0490-5C61-9722-C5EE49A1AF2B_d0e189824_href.png Binary file Symbian3/SDK/Source/GUID-79009102-0490-5C61-9722-C5EE49A1AF2B_d0e189824_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79100974-CAE1-5451-9ED7-E06C9B27131B.dita --- a/Symbian3/SDK/Source/GUID-79100974-CAE1-5451-9ED7-E06C9B27131B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-79100974-CAE1-5451-9ED7-E06C9B27131B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,8 +9,7 @@ --> -Build -Process +Build Process

      • Introduction

      • P.I.P.S. target types

        • @@ -20,73 +19,62 @@

      • Using the System Call Adaptation Layer

    -
    Introduction

    Symbian -currently builds its emulator code with the Metrowerks CodeWarrior compiler. -This is known as the WINSCW build target. Binaries built -with this compiler are put in the epoc32\release\winscw and epoc32\winscw directory -trees.

    You can build your programs for the emulator using Metrowerks -CodeWarrior. The build tools also support the Microsoft® Visual Studio .NET -2003 and Microsoft Visual Studio v6 IDEs. For further information, see the Build tools guide section. -Note that licensees or third-parties may supply additional tools, or extend -support to additional compilers, which are not described here.

    The -following sections describe the Symbian platform target types -introduced with P.I.P.S.. For further information see the -native build targets section.

    When using tool chains for pre-Symbian -OS v9.3, the .mmp file has to be manually changed to -link in various libraries.

    For Symbian OS v9.3 onwards the tool chain -supports the new STDEXE and STDDLL target -types for P.I.P.S. EXEs and DLLs. See the Generation -of STDEXE, STDDLL and STDLIB section for further explanation of the -new target types introduced with P.I.P.S..

    -
    P.I.P.S. target -types

    P.I.P.S. EXEs require adaptation logic to set up the C program -environment and the P.I.P.S. run-time C library context - this is performed -by the CRT0 library (also known as glue code, see the Glue -code (CRT0) section for further details).

    P.I.P.S. executables -are implemented using native Symbian platform executables linked statically -to the glue code. The new target types for P.I.P.S. include the glue code -by default. The glue code provides the linking code between the E32Main() entry -point and the main() entry point used in 'C' P.I.P.S. EXEs.

    For -further information see the Target -Types section.

    -
    Symbol information

    When -building a P.I.P.S. DLL (that is, when the target type is STDDLL), -function and data symbols with extern linkage will be exported -or imported by default, without any requirement for IMPORT_C /EXPORT_C declarations -in the header or source files.

    Exporting of symbols with extern linkage -is the assumed default on other platforms and enables the source code to be -easily ported. Although this may normally be undesirable in the embedded world, -it is supported for STDDLL to avoid portable source code -having to include excessive decoration (that is, the IMPORT_C /EXPORT_C macros) -for the Symbian platform.

    STDEXE and STDDLL provide -symbol name information. For more information on the Symbian platform target -types see the Generation -of STDEXE, STDDLL and STDLIB section.

    -
    Mapping POSIX -handles to the Symbian platform resource objects

    Using -non-system calls

    Several P.I.P.S. APIs that directly manipulate -the Symbian platform (native) resources are implemented in the System Call -Adaptation Layer (SCAL). The exceptions to this are pthread s, -and memory maps. The pthread APIs use RThread s -and RMutex es directly from within libpthread. -Similarly, RChunk s that are used to provide support for -memory maps are directly manipulated from within libc. Note -that none of these APIs allow direct access to the underlying native resources. -References to these are wrapped in POSIX-defined data structures. These data -structures are intended to be treated as opaque and no attempt must be made -to dereference or use the underlying resource reference directly.

    All -IPC calls enter the SCAL, but are handled in a separate IPC library. This -is a component distinction. The IPC library is logically still part of the -SCAL.

    Using the -System Call Adaptation Layer

    One of the supports provided by the -System Call Adaptation Layer (SCAL) is the mapping of operations on UNIX® -file descriptors to the corresponding Symbian platform resource objects. The -section below discusses the file descriptors case.

    Creating -a new file descriptor

    The porting of the 'C' POSIX fopen() function, -below, is a good example of mapping POSIX handles to native Symbian platform -resource objects. The mapping is done through a file descriptor table. As -a reminder, every application/process has its own file descriptor table.

    This -example shows a call to the fopen() function:

    //myapp.cpp +
    Introduction

    Symbian currently builds its emulator code with the Metrowerks +CodeWarrior compiler. This is known as the WINSCW build target. Binaries built with this compiler are put in the epoc32\release\winscw and epoc32\winscw directory trees.

    You can build your programs for the emulator +using Metrowerks CodeWarrior. The build tools also support the Microsoft® +Visual Studio .NET 2003 and Microsoft Visual Studio v6 IDEs. Note that licensees or third-parties may supply additional +tools, or extend support to additional compilers, which are not described +here.

    The following sections describe the Symbian platform +target types introduced with P.I.P.S..

    When using tool chains +for pre-Symbian OS v9.3, the .mmp file has to +be manually changed to link in various libraries.

    For Symbian +OS v9.3 onwards the tool chain supports the new STDEXE and STDDLL target types for P.I.P.S. EXEs and DLLs. +See the Generation of STDEXE, STDDLL and STDLIB section for further +explanation of the new target types introduced with P.I.P.S..

    +
    P.I.P.S. +target types

    P.I.P.S. EXEs require adaptation logic to +set up the C program environment and the P.I.P.S. run-time C library +context - this is performed by the CRT0 library (also +known as glue code, see the Glue code (CRT0) section for further details).

    P.I.P.S. +executables are implemented using native Symbian platform executables +linked statically to the glue code. The new target types for P.I.P.S. +include the glue code by default. The glue code provides the linking +code between the E32Main() entry point and the main() entry point used in 'C' P.I.P.S. EXEs.

    For +further information see the Target Types section.

    +
    Symbol +information

    When building a P.I.P.S. DLL (that is, when +the target type is STDDLL), function and data symbols +with extern linkage will be exported or imported +by default, without any requirement for IMPORT_C /EXPORT_C declarations in the header or source +files.

    Exporting of symbols with extern linkage +is the assumed default on other platforms and enables the source code +to be easily ported. Although this may normally be undesirable in +the embedded world, it is supported for STDDLL to +avoid portable source code having to include excessive decoration +(that is, the IMPORT_C /EXPORT_C macros) for the Symbian platform.

    STDEXE and STDDLL provide symbol name information. For +more information on the Symbian platform target types see the Generation of STDEXE, STDDLL and STDLIB section.

    +
    Mapping +POSIX handles to the Symbian platform resource objects

    Using non-system +calls

    Several P.I.P.S. APIs that directly manipulate the +Symbian platform (native) resources are implemented in the System +Call Adaptation Layer (SCAL). The exceptions to this are pthread s, and memory maps. The pthread APIs use RThread s and RMutex es directly from +within libpthread. Similarly, RChunk s that are used to provide support for memory maps are directly +manipulated from within libc. Note that none of these +APIs allow direct access to the underlying native resources. References +to these are wrapped in POSIX-defined data structures. These data +structures are intended to be treated as opaque and no attempt must +be made to dereference or use the underlying resource reference directly.

    All IPC calls enter the SCAL, but are handled in a separate IPC +library. This is a component distinction. The IPC library is logically +still part of the SCAL.

    Using the System +Call Adaptation Layer

    One of the supports provided by +the System Call Adaptation Layer (SCAL) is the mapping of operations +on UNIX® file descriptors to the corresponding Symbian platform resource +objects. The section below discusses the file descriptors case.

    Creating a +new file descriptor

    The porting of the 'C' POSIX fopen() function, below, is a good example of mapping POSIX +handles to native Symbian platform resource objects. The mapping is +done through a file descriptor table. As a reminder, every application/process +has its own file descriptor table.

    This example shows a call +to the fopen() function:

    //myapp.cpp int foo() { //open the test.tx , fd=7 in this example @@ -95,31 +83,30 @@ //writes to file referenced by the file descriptor ret = write (fd, buf, size_t); -}

    When myapp tries to open the file with fopen(), -the application makes a call to the equivalent Symbian platform function, RFile::Open(), -and returns the next free entry in the file descriptor table.

    In each -table, the values 0, 1 and 2 are -reserved for stdin(), sdtout() and stderr(). -The figure below shows an example file descriptor table.

    - -

    According to the descriptor table the file descriptor equals 7, -as this was the next free entry in the table, and the write function will -be writing to the file referenced by 7.

    Note: A -POSIX descriptor is an index in the process open file table and represents, -for example, an open file, socket or pipe. A Symbian descriptor represents -data which can reside in any memory location, either in ROM or RAM. A descriptor -object maintains pointer and length information to describe the data. All -access to the data is made through the descriptor object.

    Descriptors -shared across multiple threads within the same process

    Originally +}

    When myapp tries to open the file with fopen(), the application makes a call to the equivalent +Symbian platform function, RFile::Open(), and returns +the next free entry in the file descriptor table.

    In each +table, the values 0, 1 and 2 are reserved for stdin(), sdtout() and stderr(). The figure below +shows an example file descriptor table.

    + +

    According to the descriptor table the file descriptor equals 7, as this was the next free entry in the table, and the +write function will be writing to the file referenced by 7.

    Note: A POSIX descriptor is an index in the process +open file table and represents, for example, an open file, socket +or pipe. A Symbian descriptor represents data which can reside in +any memory location, either in ROM or RAM. A descriptor object maintains +pointer and length information to describe the data. All access to +the data is made through the descriptor object.

    Descriptors shared +across multiple threads within the same process

    Originally on the Symbian platform, resources were thread specific and multi-tasking -was achieved using servers and active objects. In other operating systems, -such as Linux, resources are process-local and multi-tasking is achieved by -multi-threading. The purpose of the POSIX server in the original STDLIB was -to allow system-wide data, resources and descriptors to be shared across multiple -threads. This means there was context switching between the calling thread -and the server thread which added latency.

    With the introduction of -the EKA2 kernel, session handles can now be shared across multiple threads -and processes.

    P.I.P.S. takes advantage of EKA2 and re-factors the -SCAL to allow descriptors to be shared across multiple threads within the -same process, without the use of the POSIX server.

    +was achieved using servers and active objects. In other operating +systems, such as Linux, resources are process-local and multi-tasking +is achieved by multi-threading. The purpose of the POSIX server in +the original STDLIB was to allow system-wide data, +resources and descriptors to be shared across multiple threads. This +means there was context switching between the calling thread and the +server thread which added latency.

    With the introduction of +the EKA2 kernel, session handles can now be shared across multiple +threads and processes.

    P.I.P.S. takes advantage of EKA2 and +re-factors the SCAL to allow descriptors to be shared across multiple +threads within the same process, without the use of the POSIX server.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-793A5EF9-CC16-5EEB-9011-6431EA76EB15.dita --- a/Symbian3/SDK/Source/GUID-793A5EF9-CC16-5EEB-9011-6431EA76EB15.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,37 +0,0 @@ - - - - - -How -to use bldmake -

    The bldmake tool processes the component description -file (bld.inf) in the current directory and generates -the batch file abld.bat and several build batch makefiles -(.make). abld can then use the makefiles -to carry out the various stages of building the component.

    -

    The tool supports a number of command line options, however most Symbian -developers will simply use:

    -

    bldmake bldfiles

    -

    bldmake then carries out the following 3-stage process:

    -
      -

    1. Creates the directory: \epoc32\build\ absolute_path_to_bld.inf_file \

      2. -

    2. Generates makefiles -for the component into this directory

      3. -

    3. Produces a batch file -called abld.bat in the current directory.

      4. -
    -     -Bldmake syntax - -Bldmake component -definition file syntax -Using abld - -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-795B41AF-FBEA-56CE-AE20-EF17BE754723.dita --- a/Symbian3/SDK/Source/GUID-795B41AF-FBEA-56CE-AE20-EF17BE754723.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-795B41AF-FBEA-56CE-AE20-EF17BE754723.dita Tue Jul 20 12:00:49 2010 +0100 @@ -219,7 +219,7 @@

    The following diagram shows the InetProtUtils classes and their relationships.

    Class diagram for InetProtUtils - +
    Typical uses

    Applications that use HTTP transport framework use InetProtUtils API. The utilities may also diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7971886A-8ED0-5924-9BC0-A163BA499888.dita --- a/Symbian3/SDK/Source/GUID-7971886A-8ED0-5924-9BC0-A163BA499888.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --debug

    This option generates symbolic debug information for release or debug builds, independent of the compiler optimization level.

    By default, the build system generates symbolic debug information only for the debug builds. With this option, the generation of symbolic debug information is extended to release builds to support debugging of release binaries on ARM ABI compliant platforms.

    The option instructs the makmake tool to generate symbolic debug information for UREL or UDEB variants.

    Note that the option is applicable to the build and makefile commands only.

    Also note that this option cannot be used with the -no_debug option.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79B02562-B6E6-5DF9-BF98-F015C73A448C.dita --- a/Symbian3/SDK/Source/GUID-79B02562-B6E6-5DF9-BF98-F015C73A448C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-79B02562-B6E6-5DF9-BF98-F015C73A448C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,8 @@
    Purpose

    This example shows how to create and display a digital and analog clock. For more information about the API, see Clock Overview.

    Download

    Click on the following link to download the example: ClockExample.zip

    Click: browse to view the example code.

    -
    Class Summary
      +
      Class +Summary

      • CWsScreenDevice

      • CFbsFont

      • TRgb

        • @@ -32,8 +33,7 @@ use the command line, open a command prompt, and set the current directory to the source code directory of the example. You can then build the example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld -build

        How to use bldmake and How to -use abld describe how to use the SBSv1 build tools.

        +build

      • For the emulator, the example builds an executable called clockexample.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

        • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79C82F78-471B-521F-A0CA-968C8BF33B48_d0e189034_href.png Binary file Symbian3/SDK/Source/GUID-79C82F78-471B-521F-A0CA-968C8BF33B48_d0e189034_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-79C82F78-471B-521F-A0CA-968C8BF33B48_d0e194005_href.png Binary file Symbian3/SDK/Source/GUID-79C82F78-471B-521F-A0CA-968C8BF33B48_d0e194005_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A16B6E1-16F7-41EC-ABCC-4A2BEBD66FFF.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-7A16B6E1-16F7-41EC-ABCC-4A2BEBD66FFF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,21 @@ + + + + + +Converting +from local time for the system time zone to UTC + +To convert the local +time in the system time zone to UTC, use CTzConverter::ConvertToUniversalTime(), +without specifying the time zone to convert from: +

        TInt errCode = myConverter->ConvertToUniversalTime( myTime );

         +         +         +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A22FBD7-F306-578C-BD54-BCF74B7343CF.dita --- a/Symbian3/SDK/Source/GUID-7A22FBD7-F306-578C-BD54-BCF74B7343CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --keepgoing

        This option tells a particular abld command to “keep going” even if unrelated build steps report errors.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e51559_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e51559_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e51702_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e51702_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e55550_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e55550_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e55693_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e55693_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e68820_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e68820_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e68844_href.png Binary file Symbian3/SDK/Source/GUID-7A2A9222-7D10-4007-95AB-C9584EC54698_d0e68844_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A52BD40-E1C1-5C67-AAA0-1B79A34CF24C.dita --- a/Symbian3/SDK/Source/GUID-7A52BD40-E1C1-5C67-AAA0-1B79A34CF24C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,184 +0,0 @@ - - - - - -Template -extension makefiles -

        A template extension makefile is a makefile which is integrated into the -Symbian platform build system, such that it can be re-used by providing different -input values as parameters. This facility allows extension makefiles to separate -behaviour of the makefile from its input data. For example, you might want -to copy files from one location to another using a template extension makefile -which represents the required behaviour. The location from where these files -have to be copied is represented by the input data, which can be specified -in the bld.inf file using prj_extensions.

        -

        Note that it is recommended to follow GNU make syntax to define template -extension makefiles. For more details on GNU make syntax, refer http://www.gnu.org.

        -

        The template extension makefiles are invoked by the build system which -defines a set of standard makefile variables. These variables can have well -defined values and help the makefile writer to locate common directories, -configurations and so on. The proper usage of these variables may result in -achieving platform independence to a certain extent. It is highly recommended -to use these variables wherever it is necessary.

        -

        The following is a list of the variables defined:

        - - - - -Variable name -Description - - - - -

        $(EPOCROOT)

        -

        Location of the epoc32 tree.

        -         - -

        $(PLATFORM)

        -

        The current platform which can be TOOLS, ARMV5, WINSCW etc.

        -         - -

        $(CFG)

        -

        The current configuration either UREL or UDEB.

        -         - -

        $(TO_ROOT)

        -

        Relative path to EPOCROOT.

        -         - -

        $(TO_BLDINF)

        -

        The path to the top-level bld.inf.

        Note: -if a bld.inf file #includes another bld.inf, this variable will always contain -the directory of that top-level file. If you require the directory of the -bld.inf which actually references the makefile, use $(EXTENSION_ROOT) instead.

        -         - -

        $(EPOCBLD)

        -

        The project’s “working” build directory under \epoc32\build\….

        -         - -

        $(EXTENSION_ROOT)

        -

        The path to the directory containing the bld.inf in -which the extension makefile was called.

        -         - -

        $(HOST_SHELL)

        -

        The path of the host-platform specific (i.e. the shell) makefile -containing the above definitions.

        -         - -

        $/

        -

        Path element separator.

        -         - -

        $;

        -

        PATH environment variable separator.

        -         - -

        $(RMDIR)

        -

        Command for directory removal.

        -         - -

        $(RM)

        -

        Command for file deletion.

        -         - -

        $(ERASE)

        -

        Command for file deletion.

        -         - -

        $(MKDIR)

        -

        Command for directory creation.

        -         - -

        $(CP)

        -

        Command for file copying.

        -         - -

        $(PLATFORM_PATH)

        -

        The current platform in lower case to be used as part of path names.

        -         - -

        $(CFG_PATH)

        -

        The current configuration in lower case to be used as part of path -names.

        -         - - -
        -

        The extension makefiles integrated into the build system should support -a number of phony targets which correspond to different phases of the Symbian -platform build process. These phony targets are labels representing a set -of commands to be executed to perform a task. For more information on these -phony targets, refer to Extension -makefile targets.

        -

        The commands for a phony target can be platform specific operations such -as creating a directory, removing a directory, copying a file and so on. It -is recommended to use the above listed variables to perform these platform -specific operations, instead of invoking the command directly.

        -

        For example, the following will delete the files values.cpp and config.cpp for -the target CLEAN.

        -CLEAN : - -$(ERASE) $(MDIR)$/values.cpp - -$(ERASE) $(MDIR)$/config.cpp -

        Note that any path within a template extension makefile is recommended -to use the path separator variable $/ as listed in the above table.

        -

        A template extension makefile can be referenced in the bld.inf file -using the prj_extensions keyword. For more information on -how to reference a template extension makefile, see prj_extensions.

        -

        Each template extension makefile has an associated meta file which provides -additional information such as the template makefile type, the platform for -which the template can be applied and so on. It is mandatory to have a meta -file with each template extension makefile. For information on meta file syntax, -refer to Meta files.

        -

        Note that all the template extension makefiles along with their meta -files need to be located under the \epoc32\tools\makefile_templates\ folder.

        -

        This example will copy the source files to a target -path, build the component using the target copy of the source files, and finally -delete the target copy of the source files.

        # copy_default.mk -# - -SOURCE_COPY=$(EPOCROOT)epoc32$/release$/$(PLATFORM_PATH)$/$(CFG_PATH)$/$(SOURCES) - -TARGET_COPY=$(EPOCROOT)epoc32$/release$/$(PLATFORM_PATH)$/$(CFG_PATH)$/$(TARGET) - -$(TARGET_COPY) : $(SOURCE_COPY) - $(CP) "$?" "$@" - -DO_NOTHING : - @rem do nothing - -MAKMAKE : - -BLD : $(TARGET_COPY) - -SAVESPACE : BLD - -FREEZE : DO_NOTHING - -LIB : DO_NOTHING - -CLEANLIB : DO_NOTHING - -RESOURCE : DO_NOTHING - -CLEAN : - -$(ERASE) $(TARGET_COPY) - -RELEASABLES : - @echo $(TARGET_COPY) - -FINAL : -         -         -How to write -an extension makefile template -         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A552BC6-419F-4FD9-8D63-828E37982FD8.dita --- a/Symbian3/SDK/Source/GUID-7A552BC6-419F-4FD9-8D63-828E37982FD8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7A552BC6-419F-4FD9-8D63-828E37982FD8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ Editing indicators a) in the Navi pane and b) above the editor field in a pop-up window - +
        Using editing indicators in applications

        The API to use for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A6342C7-DED3-5BE0-AB1C-F2C7BC57D1D2_d0e409504_href.png Binary file Symbian3/SDK/Source/GUID-7A6342C7-DED3-5BE0-AB1C-F2C7BC57D1D2_d0e409504_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7A6342C7-DED3-5BE0-AB1C-F2C7BC57D1D2_d0e413304_href.png Binary file Symbian3/SDK/Source/GUID-7A6342C7-DED3-5BE0-AB1C-F2C7BC57D1D2_d0e413304_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7AC4C1C2-D796-508F-93CF-21F061F49A30_d0e47241_href.png Binary file Symbian3/SDK/Source/GUID-7AC4C1C2-D796-508F-93CF-21F061F49A30_d0e47241_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7AC4C1C2-D796-508F-93CF-21F061F49A30_d0e47399_href.png Binary file Symbian3/SDK/Source/GUID-7AC4C1C2-D796-508F-93CF-21F061F49A30_d0e47399_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7AE4D17F-728A-5B7E-A3F9-A903E64731B1_d0e189172_href.png Binary file Symbian3/SDK/Source/GUID-7AE4D17F-728A-5B7E-A3F9-A903E64731B1_d0e189172_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7AE4D17F-728A-5B7E-A3F9-A903E64731B1_d0e194143_href.png Binary file Symbian3/SDK/Source/GUID-7AE4D17F-728A-5B7E-A3F9-A903E64731B1_d0e194143_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7AE7EAE1-BA90-446E-AAAF-01794EF96576.dita --- a/Symbian3/SDK/Source/GUID-7AE7EAE1-BA90-446E-AAAF-01794EF96576.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7AE7EAE1-BA90-446E-AAAF-01794EF96576.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,6 +17,6 @@

        Grid item highlighting is a frame over the item in focus.

        List highlighting (a) and grid highlighting (b) - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita --- a/Symbian3/SDK/Source/GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7B173E02-9697-51F4-A7E8-795AEF547109.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,17 +9,14 @@ --> -Thread -Priority SchemeExplains the factors involved in allocating thread priority. -

        At any given time, the thread running on Symbian platform is the one with -the highest priority that is ready to run. The priority of a thread is simply -a number; the value determines the priority; the greater the number, the higher -the priority. We call this the true or absolute priority of -the thread.

        -

        The Kernel schedules a fixed amount of time called a quantum for -a thread to run on the CPU, and the scheduler chooses the highest priority -thread that is ready to run. Threads of equal priority are executed on a round -robin basis.

        +Thread Priority SchemeExplains the factors involved in allocating thread priority. +

        At any given time, the thread running on Symbian platform is the +one with the highest priority that is ready to run. The priority of +a thread is simply a number; the value determines the priority; the +greater the number, the higher the priority. We call this the true or absolute priority of the thread.

        +

        The Kernel schedules a fixed amount of time called a quantum for a thread to run on the CPU, and the scheduler chooses the highest +priority thread that is ready to run. Threads of equal priority are +executed on a round robin basis.

        The true priority values range from 0 (lowest) to 63 (highest).

        The priority range divides into four broad categories:

        @@ -27,17 +24,19 @@

        0

         -

        This is reserved for the null thread, which puts the processor -into idle mode to save power when no other threads are ready to run.

        +

        This is reserved for the null thread, which puts +the processor into idle mode to save power when no other threads are +ready to run.

        1 - 23

        -

        Used by kernel side threads and user-side applications and servers

        +

        Used by kernel side threads and user-side applications and +servers

        24 -31

        -

        Used by kernel side threads and protected system servers, i.e. servers -with the ProtServ capability.

        +

        Used by kernel side threads and protected system servers, +i.e. servers with the ProtServ capability.

        32 - 63

        @@ -47,7 +46,7 @@
        - +

        • Priority scheme for general user-side threads

          • @@ -55,53 +54,49 @@

        • Thread priority value mapping table

        • Platform security notes

        -
        Priority scheme -for general user-side threads

        User-side threads do not allocate true priority -values directly. Instead, they allocate priorities using symbolic values defined -by enums. Symbian platform maps these values to the true value.

        There +

        Priority +scheme for general user-side threads

        User-side threads +do not allocate true priority values directly. Instead, they +allocate priorities using symbolic values defined by enums. Symbian +platform maps these values to the true value.

        There are two priority allocation schemes:

        • Process-relative scheme

        • Process-independent scheme for general user threads

          • -

        Process-relative scheme

        This -scheme bases the true priority of a thread on the priority of its owning -process and the priority of the thread relative to the process. This means -that changing the process priority results in a change to the true priority -of the thread.

        A process can be assigned one of eight discrete priorities -represented by the individual enumerators of TProcessPriority, -and range from EPriorityLow, the lowest, to EPrioritySupervisor, -the highest.

        In practice, user processes can only be assigned -priorities that are one of the values:

          +

        Process-relative +scheme

        This scheme bases the true priority of a +thread on the priority of its owning process and the priority of the +thread relative to the process. This means that changing the process +priority results in a change to the true priority of the thread.

        A process can be assigned one of eight discrete priorities represented +by the individual enumerators of TProcessPriority, and range from EPriorityLow, the lowest, to EPrioritySupervisor, the highest.

        In practice, user processes can only be assigned priorities that are one of +the values:

        • EPriorityLow

        • EPriorityBackground

        • EPriorityForeGround

        • EPriorityHigh

          • -

        There are a further four process priorities that a user process is -not permitted to set: EPriorityWindowServer, EPriorityFileServer, EPriorityRealTimeServer and EPrioritySupervisor.

        A process priority can be assigned:

          -

        • when the associated .exe is -built; this is done by specifying the value in the .mmp file -that defines the project.

          • -

        • by calling RProcess::SetPriority() and -passing one of the TProcessPriority enum values.

          • -

        See also : Using -Makmake in the Build -Tools Guide.

        The priority of a thread relative to a -process is assigned by calling RThread::SetPriority() and -passing one of the five TThreadPriority enum values:

          +

        There are a further four process priorities that a user process +is not permitted to set: EPriorityWindowServer, EPriorityFileServer, EPriorityRealTimeServer and EPrioritySupervisor.

        A process priority +can be assigned:

          +

        • when the associated .exe is built; this is done by specifying the value in +the .mmp file that defines the project.

          • +

        • by calling RProcess::SetPriority() and passing one of the TProcessPriority enum values.

          • +

        The priority of a thread relative to +a process is assigned by calling RThread::SetPriority() and passing one of the five TThreadPriority enum +values:

        • EPriorityMuchLess

        • EPriorityLess

        • EPriorityNormal

        • EPriorityMore

        • EPriorityMuchMore

          • -

        The thread -priority value mapping table shows the true priority of a thread -based on the combination of process priority and process-relative thread priority

        Process-independent scheme -for general user threads

        In this scheme, the true priority -of a thread is independent of the priority of its owning process. Changing -the priority of the underlying process has no effect on the true priority -of the thread.

        The priority of a thread is assigned by calling RThread::SetPriority() and -passing one of the TThreadPriority enum values listed below. -Note that the set of enum values splits into two logical groupings based on -their equivalence to process-relative values. See the thread priority value mapping table.

        +

        The thread priority value mapping table shows the true priority +of a thread based on the combination of process priority and process-relative +thread priority

        Process-independent +scheme for general user threads

        In this scheme, the true priority of a thread is independent of the priority of its +owning process. Changing the priority of the underlying process has +no effect on the true priority of the thread.

        The priority +of a thread is assigned by calling RThread::SetPriority() and passing one of the TThreadPriority enum values +listed below. Note that the set of enum values splits into two logical +groupings based on their equivalence to process-relative values. See +the thread priority value mapping table.

        @@ -125,17 +120,14 @@ -

        The thread -priority value mapping table shows the resulting true priority -of the thread.

        -
        Priority scheme -for real-time user-side threads

        This scheme is the same as the process-independent -scheme for general user threads, but with one essential difference -- the range of TThreadPriority enum values to be passed -to RThread::SetPriority() is as shown below. These priorities -map to the true priority values in the range 24 -31, and can only be -set by executables having the ProtServ capability. This range -is referred to as the real time range.

          +

          The thread priority value mapping table shows the resulting true priority of the thread.

        +
        Priority +scheme for real-time user-side threads

        This scheme is the +same as the process-independent scheme for general user threads, but with +one essential difference - the range of TThreadPriority enum values to be passed to RThread::SetPriority() is as shown below. These priorities map to the true priority +values in the range 24 -31, and can only be set by executables having +the ProtServ capability. This range is referred to +as the real time range.

        • EPriorityAbsoluteRealTime1

        • EPriorityAbsoluteRealTime2

        • EPriorityAbsoluteRealTime3

          • @@ -144,34 +136,32 @@

        • EPriorityAbsoluteRealTime6

        • EPriorityAbsoluteRealTime7

        • EPriorityAbsoluteRealTime8

          • -

        The thread -priority value mapping table shows the resulting true priority -of the thread.

        -
        Thread priority -value mapping table

        This table shows the effect of setting priorities, -and the resulting true priority values. You need to be aware that this -may change in the future, and you should never synchronise threads on the -basis of thread priorities. If you need to synchronise threads, use mutexes -or semaphores.

        Notes

          -

        • True priority values -in the shaded region can only be accessed by threads running in processes -with the ProtServ capability.

          • +

        The thread priority value mapping table shows the resulting true priority of the thread.

        +
        Thread +priority value mapping table

        This table shows the effect +of setting priorities, and the resulting true priority values. +You need to be aware that this may change in the future, and you should +never synchronise threads on the basis of thread priorities. If you +need to synchronise threads, use mutexes or semaphores.

        Notes

          +

        • True priority +values in the shaded region can only be accessed by threads running +in processes with the ProtServ capability.

        • The process-priority -values : EPriorityWindowServer, EPriorityFileServer and EPrioritySupervisor all -map to the same range of priorities. Along with EPriorityRealTimeServer, -these have historically been used for system servers and other processes needing -access to high priorities suitable for real-time tasks, and their use requires ProtServ capability.

          • -

        • Note that ProtServ capability -will not be granted to general applications for the purpose of gaining access -to the very high thread priorities. This risks breaking important system functionality.

          • +values : EPriorityWindowServer, EPriorityFileServer and EPrioritySupervisor all map to the same range +of priorities. Along with EPriorityRealTimeServer, these have historically been used for system servers and other +processes needing access to high priorities suitable for real-time +tasks, and their use requires ProtServ capability.

          +

        • Note that ProtServ capability will not be granted to general applications +for the purpose of gaining access to the very high thread priorities. +This risks breaking important system functionality.

        - -

        Note that we have used E' as an abbreviation for EPriority in -this diagram.

        -
        Platform security -notes

        Platform security restrictions prevent thread and process -priorities from being modified by another user process. There is one exception: -by default, applications have “Priority Control” enabled for them which allows -the window server to switch them between foreground and background process -priorities depending on which has foreground focus.

        + +

        Note that we have used E' as an abbreviation for EPriority in this diagram.

        +
        Platform +security notes

        Platform security restrictions prevent thread +and process priorities from being modified by another user process. +There is one exception: by default, applications have “Priority Control” +enabled for them which allows the window server to switch them between +foreground and background process priorities depending on which has +foreground focus.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B2AA498-5E73-4CC4-91DF-5F07F452F0BF.dita --- a/Symbian3/SDK/Source/GUID-7B2AA498-5E73-4CC4-91DF-5F07F452F0BF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7B2AA498-5E73-4CC4-91DF-5F07F452F0BF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,6 +19,6 @@ setting types.

        Example image of a setting in a pop-up - +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B3578A0-7E2E-508A-A355-A39AEE0307AD_d0e304342_href.jpg Binary file Symbian3/SDK/Source/GUID-7B3578A0-7E2E-508A-A355-A39AEE0307AD_d0e304342_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B3578A0-7E2E-508A-A355-A39AEE0307AD_d0e310814_href.jpg Binary file Symbian3/SDK/Source/GUID-7B3578A0-7E2E-508A-A355-A39AEE0307AD_d0e310814_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B589949-2784-5B77-959E-99F8733A8853_d0e230612_href.png Binary file Symbian3/SDK/Source/GUID-7B589949-2784-5B77-959E-99F8733A8853_d0e230612_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B589949-2784-5B77-959E-99F8733A8853_d0e235592_href.png Binary file Symbian3/SDK/Source/GUID-7B589949-2784-5B77-959E-99F8733A8853_d0e235592_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7B5A854B-A9A0-557E-9970-9B13D7EE251E.dita --- a/Symbian3/SDK/Source/GUID-7B5A854B-A9A0-557E-9970-9B13D7EE251E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7B5A854B-A9A0-557E-9970-9B13D7EE251E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ When there is a client request to the AppArc for data type recognition, AppArc internally uses the MIME recognition framework for processing the request.

        -

        The client connects +

        The client connects to AppArc and creates a session using the class RApaLsSession. Apparc provides access to the MIME framework via RApaLsSession APIs. The class provides the APIs for data type recognition.

        All MIME (data) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C061090-83A8-5E0F-B42B-2D722BE054EE_d0e243007_href.png Binary file Symbian3/SDK/Source/GUID-7C061090-83A8-5E0F-B42B-2D722BE054EE_d0e243007_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C061090-83A8-5E0F-B42B-2D722BE054EE_d0e247966_href.png Binary file Symbian3/SDK/Source/GUID-7C061090-83A8-5E0F-B42B-2D722BE054EE_d0e247966_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C4A8920-359F-5328-8D28-2AFBA25A6A9E.dita --- a/Symbian3/SDK/Source/GUID-7C4A8920-359F-5328-8D28-2AFBA25A6A9E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -lang

        lang language-list

        Use the lang statement to indicate languages code for the project.

        If this statement is not specified, the default language code is sc.

        The language codes should be two-digit codes, and are used to complete the extension of generated resource files, as project.rsc.

        Each resource file specified with resource or systemresource or start resource is compiled multiple times, once for each language specified. The specification of several languages does not cause several versions of the bitmaps or application information files in your project to be created.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C51BC7A-CB97-5A7E-A5EF-BB3623DFFFED_d0e189683_href.png Binary file Symbian3/SDK/Source/GUID-7C51BC7A-CB97-5A7E-A5EF-BB3623DFFFED_d0e189683_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C51BC7A-CB97-5A7E-A5EF-BB3623DFFFED_d0e194654_href.png Binary file Symbian3/SDK/Source/GUID-7C51BC7A-CB97-5A7E-A5EF-BB3623DFFFED_d0e194654_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita --- a/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita Tue Jul 20 12:00:49 2010 +0100 @@ -75,7 +75,7 @@ diagram demonstrates that typically the RunL() starts with a GetRedraw() and ends with a call to RedrawReady().

        Window Server-initiated redraw - +

        A redrawer's RunL() function must not perform any non-redraw drawing (that is, any drawing operations that are not bracketed within the calls to BeginRedraw() and EndRedraw()). @@ -107,7 +107,7 @@ Application-initiated redrawing, "draw now" scenario - +

        The "draw deferred" scenario

        The "draw deferred" redraw scenario is when an application simply marks a window or a rectangle within a window as invalid. This eventually triggers a Window Server-initiated redraw. Typically @@ -115,7 +115,7 @@ However, it is also possible to do this by calling RWindow::Invalidate().

        Application-initiated redrawing, "draw deferred" scenario - +

        This approach is useful when the data to be displayed might be updated frequently but it is not necessary to update the display instantaneously.

        To illustrate how it works, consider a window that has a rectangle that is used @@ -126,14 +126,14 @@ the following diagram.

        Icons displayed using the "draw now" approach - +

        However, if you use the "draw deferred" approach when each event occurs, the Window Server may not update the display for each one. For example, the Window Server does not update the display when it is superceded by a later call.

        Icons displayed using the "draw deferred" approach - +

        If it is important that the display is updated immediately, you would generally use the "draw now" approach. However, if a short delay in the display being updated is unlikely to inconvenience the user, the "draw diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C87B04A-1CCC-47D2-9B53-4E341412EFD2_d0e66044_href.png Binary file Symbian3/SDK/Source/GUID-7C87B04A-1CCC-47D2-9B53-4E341412EFD2_d0e66044_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C87B04A-1CCC-47D2-9B53-4E341412EFD2_d0e66187_href.png Binary file Symbian3/SDK/Source/GUID-7C87B04A-1CCC-47D2-9B53-4E341412EFD2_d0e66187_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7D025BEF-61B9-4EF1-AFF7-604B500A8F2C_d0e64446_href.png Binary file Symbian3/SDK/Source/GUID-7D025BEF-61B9-4EF1-AFF7-604B500A8F2C_d0e64446_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7D025BEF-61B9-4EF1-AFF7-604B500A8F2C_d0e64589_href.png Binary file Symbian3/SDK/Source/GUID-7D025BEF-61B9-4EF1-AFF7-604B500A8F2C_d0e64589_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7D13B61C-0C9E-5098-87F0-BB9D741E9281_d0e267163_href.png Binary file Symbian3/SDK/Source/GUID-7D13B61C-0C9E-5098-87F0-BB9D741E9281_d0e267163_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7D13B61C-0C9E-5098-87F0-BB9D741E9281_d0e272018_href.png Binary file Symbian3/SDK/Source/GUID-7D13B61C-0C9E-5098-87F0-BB9D741E9281_d0e272018_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7D3B5008-CB40-504D-90A8-92DE482977CA.dita --- a/Symbian3/SDK/Source/GUID-7D3B5008-CB40-504D-90A8-92DE482977CA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -bld.inf file syntax \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7DDC1BC6-A100-5B50-ABFE-B4AA466716A6_d0e287350_href.png Binary file Symbian3/SDK/Source/GUID-7DDC1BC6-A100-5B50-ABFE-B4AA466716A6_d0e287350_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7DDC1BC6-A100-5B50-ABFE-B4AA466716A6_d0e292181_href.png Binary file Symbian3/SDK/Source/GUID-7DDC1BC6-A100-5B50-ABFE-B4AA466716A6_d0e292181_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7DDEE87B-7056-5AAA-91A1-33D3D0D50041.dita --- a/Symbian3/SDK/Source/GUID-7DDEE87B-7056-5AAA-91A1-33D3D0D50041.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7DDEE87B-7056-5AAA-91A1-33D3D0D50041.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@

        The following diagram illustrates how elements are organised within the array buffer:

        - +

        This kind of array is suitable for a small number of objects or for a moderately large but fixed maximum number of objects. It is not suitable for large arrays diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7DFA1B74-5BD1-494D-9BBA-B2D6F258C5F1.dita --- a/Symbian3/SDK/Source/GUID-7DFA1B74-5BD1-494D-9BBA-B2D6F258C5F1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7DFA1B74-5BD1-494D-9BBA-B2D6F258C5F1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@

        Left and right arrows

        Arrows in the Navi pane - +

        When horizontal navigation between different main pane views is used, the Navi pane displays the navigation information (tabs or text may @@ -36,7 +36,7 @@

        Editing indicators

        Editing indicators in the Navi pane - +

        When an editor is in use in the main pane, the indicators related to editing parameters are displayed in the Navi pane. They indicate things diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E6634DC-7F07-5687-AFEE-D5BD268B8E1D_d0e34576_href.png Binary file Symbian3/SDK/Source/GUID-7E6634DC-7F07-5687-AFEE-D5BD268B8E1D_d0e34576_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E6634DC-7F07-5687-AFEE-D5BD268B8E1D_d0e34755_href.png Binary file Symbian3/SDK/Source/GUID-7E6634DC-7F07-5687-AFEE-D5BD268B8E1D_d0e34755_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E7BCC57-E14F-56A4-B948-B9FB9E7AB598_d0e8390_href.png Binary file Symbian3/SDK/Source/GUID-7E7BCC57-E14F-56A4-B948-B9FB9E7AB598_d0e8390_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E7BCC57-E14F-56A4-B948-B9FB9E7AB598_d0e8512_href.png Binary file Symbian3/SDK/Source/GUID-7E7BCC57-E14F-56A4-B948-B9FB9E7AB598_d0e8512_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E801A44-4509-5AC0-88D5-7DEA1AF7969D_d0e7090_href.png Binary file Symbian3/SDK/Source/GUID-7E801A44-4509-5AC0-88D5-7DEA1AF7969D_d0e7090_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E801A44-4509-5AC0-88D5-7DEA1AF7969D_d0e7212_href.png Binary file Symbian3/SDK/Source/GUID-7E801A44-4509-5AC0-88D5-7DEA1AF7969D_d0e7212_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E8C363C-5908-445D-8595-D53F217186ED_d0e73568_href.png Binary file Symbian3/SDK/Source/GUID-7E8C363C-5908-445D-8595-D53F217186ED_d0e73568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7E8C363C-5908-445D-8595-D53F217186ED_d0e73606_href.png Binary file Symbian3/SDK/Source/GUID-7E8C363C-5908-445D-8595-D53F217186ED_d0e73606_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F0EC737-F5EE-5B58-B9EB-4D8A058E3A49_d0e195421_href.jpg Binary file Symbian3/SDK/Source/GUID-7F0EC737-F5EE-5B58-B9EB-4D8A058E3A49_d0e195421_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F0EC737-F5EE-5B58-B9EB-4D8A058E3A49_d0e200430_href.jpg Binary file Symbian3/SDK/Source/GUID-7F0EC737-F5EE-5B58-B9EB-4D8A058E3A49_d0e200430_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F3F89C0-999A-552E-90BB-17D720C53DE6_d0e184682_href.png Binary file Symbian3/SDK/Source/GUID-7F3F89C0-999A-552E-90BB-17D720C53DE6_d0e184682_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F3F89C0-999A-552E-90BB-17D720C53DE6_d0e189679_href.png Binary file Symbian3/SDK/Source/GUID-7F3F89C0-999A-552E-90BB-17D720C53DE6_d0e189679_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F6283C0-46E8-427C-B6A9-FB274A7D2C15.dita --- a/Symbian3/SDK/Source/GUID-7F6283C0-46E8-427C-B6A9-FB274A7D2C15.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7F6283C0-46E8-427C-B6A9-FB274A7D2C15.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,38 +12,38 @@ Opening a Connection to a SNAP by specifying SNAP TypeExtended Connection Preferences API can be used by applications to set the SNAP type prior to establishing a connection. -

        Specifying +

        Specifying SNAP type enables the applications to start a connection to a specific SNAP (For example, Internet SNAP or Intranet SNAP) without iterating through the SNAP list to identify the appropriate type.

         - -Connect to socket server . + +Connect to socket server . RSocketServ ss; ss.Connect(); - Open a RConnection object. + Open a RConnection object. RConnection conn; conn.Open( ss ); -Create a connection +Create a connection preference list and extended connection preferences object. TConnPrefList prefList; TExtendedConnPref preferences; -Set the SNAP type +Set the SNAP type using TExtendedConnPref::SetSnapPurpose(). preferences.SetSnapPurpose( CMManager::ESnapPurposeInternet ); -Append the extended +Append the extended connection preferences into connection preference list. prefList.AppendL( &preferences ); -Start a connection +Start a connection with connection preferences. conn.Start( prefList ); -

        The application +

        The application is connected to Internet SNAP.

                 Additional diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F8F6ABB-8F46-5486-A116-6965787BC539_d0e177349_href.png Binary file Symbian3/SDK/Source/GUID-7F8F6ABB-8F46-5486-A116-6965787BC539_d0e177349_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F8F6ABB-8F46-5486-A116-6965787BC539_d0e182374_href.png Binary file Symbian3/SDK/Source/GUID-7F8F6ABB-8F46-5486-A116-6965787BC539_d0e182374_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7F9F0EB3-8F0E-55BB-9864-C80FE6FC1528.dita --- a/Symbian3/SDK/Source/GUID-7F9F0EB3-8F0E-55BB-9864-C80FE6FC1528.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,17 +0,0 @@ - - - - - -How to set default STRUCT values

        Default values can be specified for struct members by using an initialiser, for example

        STRUCT NCEDIT - { - WORD current; - WORD low; - WORD high=65535; - }

        With this specification, any NCEDIT resource will, by default, have a high member whose value is 65,535. If the RESOURCE statement specifies a different value, it will be used instead.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7FA5898D-8898-53CE-875E-1DE97BE02C81.dita --- a/Symbian3/SDK/Source/GUID-7FA5898D-8898-53CE-875E-1DE97BE02C81.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -prj_testextensions

        prj_testextensions

        start extension team/sub-system/ext-template

        [target target_file_name]

        [sources source_file_1 .... - source_file_n]

        [dependencies dependency_file_1 ... - dependency_file_n]

        [tool toolname]

        [option key_1 value_1]

        ...

        [option key_n value_n]

        end

        Note: The value argument in the option statement is optional.

        In the prj_testextensions section, list the project extensions for the test programs. The options for start extension block are the same as those for prj_extensions, except that prj_testextensions is for test programs.

        For more information about start extension options, refer to prj_extensions.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7FCFB114-B186-5615-9134-08612BB675EE.dita --- a/Symbian3/SDK/Source/GUID-7FCFB114-B186-5615-9134-08612BB675EE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7FCFB114-B186-5615-9134-08612BB675EE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,45 +9,41 @@ --> -tcharexample: -TChar exampleThis example application demonstrates how to use TChar, TCharF, TCharLC and TCharUC classes. +tcharexample: TChar exampleThis example application demonstrates how to use TChar, TCharF, TCharLC and TCharUC classes.
        -
        Purpose

        TChar represents -a single character. It stores the character's value as a 32-bit unsigned integer -and it provides various functions to manipulate the character and retrieve -its properties.

        TChar and its derived classes can be used to represent -Unicode values outside plane 0 (that is, Unicode values within the -extended Unicode range from 0x10000 to 0xFFFFF). -This differentiates them from the related class TText, which -can only be used for 16-bit Unicode character values.

        -
        Class summary
          -

        • TChar - Holds a character value and provides a number -of utility functions to manipulate it and test its properties.

          • -

        • TCharF - Folds a specified character and provides -functions to fold additional characters after construction of the object.

          • -

        • TCharLC - Converts a specified character to lower -case and provides functions to convert additional characters after construction +

          Purpose

          TChar represents a single character. It stores +the character's value as a 32-bit unsigned integer and it provides +various functions to manipulate the character and retrieve its properties.

          TChar and its derived classes can be used to represent Unicode +values outside plane 0 (that is, Unicode values within the +extended Unicode range from 0x10000 to 0xFFFFF). This differentiates them from the related class TText, which can only be used for 16-bit Unicode character values.

          +
          Class +summary
            +

          • TChar - Holds a character value and provides +a number of utility functions to manipulate it and test its properties.

            • +

          • TCharF - Folds a specified character and +provides functions to fold additional characters after construction of the object.

            • -

          • TCharUC - Converts a specified character to upper -case and provides functions to convert additional characters after construction -of the object.

            • +

          • TCharLC - Converts a specified character +to lower case and provides functions to convert additional characters +after construction of the object.

            • +

          • TCharUC - Converts a specified character +to upper case and provides functions to convert additional characters +after construction of the object.

          -
          Download

          Click -on the following link to download the example: tcharexample.zip.

          click: browse to view the example code.

          -
          Design and -implementation

          Using TChar

          The example retrieves -information about a character using:

            -

          • various Is...() functions, -for instance its case (e.g. TChar::IsLower()), whether -it is alphabetic (TChar::IsAlpha()), a decimal digit (TChar::IsDigit()), -and whether it is printable (TChar::IsPrint()).

            • -

          • various Get...() functions, -for instance its upper, lower and title case versions, e.g. (TChar::GetUpperCase()), -and the character width for Chinese, Japanese and Korean characters (TChar::GetCjkWidth()).

            • -

          • the TChar::TCharInfo struct. -This struct holds most of the information about the character, including its -Unicode category, and is populated by calling TChar::GetInfo().

            • -

          Using TCharF, TCharLC and TCharUC

          Related APIs

            +
            Download

            Click on the following link to download the example: tcharexample.zip.

            click: browse to view the example code.

            +
            Design +and implementation

            Using TChar

            The example +retrieves information about a character using:

              +

            • various Is...() functions, for instance its case (e.g. TChar::IsLower()), whether it is alphabetic (TChar::IsAlpha()), a decimal digit (TChar::IsDigit()), and whether +it is printable (TChar::IsPrint()).

              • +

            • various Get...() functions, for instance its upper, lower and title +case versions, e.g. (TChar::GetUpperCase()), and +the character width for Chinese, Japanese and Korean characters (TChar::GetCjkWidth()).

              • +

            • the TChar::TCharInfo struct. This struct holds most of the +information about the character, including its Unicode category, and +is populated by calling TChar::GetInfo().

              • +

            Using TCharF, TCharLC and TCharUC

            Related +APIs

            • TChar::GetCjkWidth()

            • TChar::GetInfo()

            • TChar::GetUpperCase()

              • @@ -57,28 +53,28 @@

            • TChar::IsPrint()

            • TChar::TCharInfo - A structure to hold information about a Unicode character.

              • -

            TCharF represents a folded character. The example -demonstrates how folding a character removes case and accent distinctions.

            The -example also demonstrates converting characters between lower and upper case -using TCharLC and TCharUC.

            -
            Building and -configuring

            To build the example:

              -

            • You can build the example -from your IDE or the command line.

              If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

              If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

              bldmake -bldfiles

              abld build

              How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

              • -

            • For the emulator, the -example builds an executable called tcharexample.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

              • +

            TCharF represents a folded character. +The example demonstrates how folding a character removes case and +accent distinctions.

            The example also demonstrates converting +characters between lower and upper case using TCharLC and TCharUC.

            +
            Building +and configuring

            To build the example:

              +

            • You can build +the example from your IDE or the command line.

              If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

              If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

              bldmake bldfiles

              abld +build

              • +

            • For the emulator, +the example builds an executable called tcharexample.exe in the epoc32\release\winscw\<udeb or + urel>\ folder.

            -
            Running the -example

            The example application displays a list of options and -sub options to the user and takes input from the user.

            +
            Running +the example

            The example application displays a list of +options and sub options to the user and takes input from the user.

            Screenshot for TChar example - +
            \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7FD49142-23DC-44FC-BA7D-C11E0559C8CF.dita --- a/Symbian3/SDK/Source/GUID-7FD49142-23DC-44FC-BA7D-C11E0559C8CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-7FD49142-23DC-44FC-BA7D-C11E0559C8CF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,16 +15,16 @@

            Specifying SNAP ID enables the applications to start a connection to a specific SNAP.

             - -Connect to socket server . + +Connect to socket server . RSocketServ ss; ss.Connect(); - Open a RConnection object. + Open a RConnection object. RConnection conn; conn.Open( ss ); -Create a connection +Create a connection preference list and extended connection preferences object. TConnPrefList prefList; TExtendedConnPref preferences; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7FF363B0-B05F-5490-8D9C-59061B905381.dita --- a/Symbian3/SDK/Source/GUID-7FF363B0-B05F-5490-8D9C-59061B905381.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,22 +0,0 @@ - - - - - -How -to build ROMs with variants -

            A variant will define hundreds of features. Use BUILDROM, -to build a ROM for a variant. BUILDROM is the unified Symbian platform ROM -building tool.

            -
            ROM building -specifications

            A variant configuration will be defined in .var file. -Specify the VAR file name along with the FEATUREVARIANT keyword.

            For -example, if myvar.var is the VAR file name for variant myvar, -then use:

            buildrom [options] –DFEATUREVARIANT=myvar <obey1> [<obey2> ...]

            Note: For more information on BUILDROM, refer to BUILDROM reference.

            -             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-803D895B-E22F-5ADE-9BA6-F2EB20856541_d0e402303_href.png Binary file Symbian3/SDK/Source/GUID-803D895B-E22F-5ADE-9BA6-F2EB20856541_d0e402303_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-803D895B-E22F-5ADE-9BA6-F2EB20856541_d0e406103_href.png Binary file Symbian3/SDK/Source/GUID-803D895B-E22F-5ADE-9BA6-F2EB20856541_d0e406103_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8061E4C1-4E63-53F6-9863-D0D7BB8A2E5D.dita --- a/Symbian3/SDK/Source/GUID-8061E4C1-4E63-53F6-9863-D0D7BB8A2E5D.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Switching between ABI modes

            Symbian platform natively runs on ARM processors and to build a Symbian platform application, we need a compiler based on the Application Binary Interface (ABI) for ARM Architecture. There are two versions of the ARM ABI, referred to as v1 and v2 respectively. The Symbian platform build toolchain defines a set of native build targets (ARMV5 and ARMV6) that invoke ARM's RealView Compiler Tools (RVCT) to build binaries conforming to these two ABI versions. For more information on differences between ABI v1 and v2 toolchains, refer to ABIv1 to ABIv2 toolchain changes.

            From Symbian OS v9.4 onwards, the behaviour of these build targets (ARMV5, ARMV5_ABIv2, ARMV6 and ARMV6_ABIv2) can be changed. The following lists the behaviour of these build targets prior to, for and after Symbian OS v9.4:

            • For Symbian OS v9.3 and earlier versions, the build targets used to create binaries conforming to ABI v1 and ABI v2 are ARMV5 and ARMV5_ABIv2 respectively, and ARMV6 and ARMV6_ABIv2 respectively. By default, the abld build command will create binaries conforming to ARMV5 ABI v1.

            • For Symbian OS v9.4 and later, the build targets used to create binaries conforming to ABI v2 and ABI v1 are ARMV5 and ARMV5_ABIv1 respectively, and ARMV6 and ARMV6_ABIv1 respectively. By default, the abld build command will create binaries conforming to ARMV5 ABI v2.

            You can choose to switch between the above listed behaviours using the macro ENABLE_ABIV2_MODE. If you enable this macro, the behaviour of build targets ARMV5 and ARMV6 is changed to create binaries conforming to ABI v2 instead of ABI v1. If you want to create binaries conforming to ABI v1, use the build targets ARMV5_ABIv1 and ARMV6_ABIv1.

            How to switch to ABI v2 mode

            To switch to ABI v2 mode from ABI v1 mode, edit the variant.cfg file located at epoc32\tools\variant\ and add the macro ENABLE_ABIV2_MODE.

            After you add the macro to variant.cfg file, the following abld commands will create binaries conforming to ABI v2 under epoc32\release\ARMV5\ or epoc32\release\ARMV6\ folders:

            abld build

            abld build ARMV5

            abld build ARMV6

            If you want to create binaries conforming to ABI v1 under epoc32\release\ARMV5_ABIV1\ or epoc32\release\ARMV6_ABIV1\ folders, use the following abld commands:

            abld build ARMV5_ABIV1

            abld build ARMV6_ABIV1

            A summary of the available build targets, their instruction set, compiler version, ABI version and their target location, after you switch to ABI v2 mode is as follows:

            Target name

            Instruction set

            Compiler

            ABI

            Target location

            ARMV5

            v5

            RVCT 2.2 Build 616

            v2

            epoc32\release\ARMV5\

            ARMV5_ABIv1

            v5

            RVCT 2.2 Build 616

            v1

            epoc32\release\ARMV5_ABIV1\

            ARMV6

            v6

            RVCT 2.2 Build 616

            v2

            epoc32\release\ARMV6\

            ARMV6_ABIv1

            v6

            RVCT 2.2 Build 616

            v1

            epoc32\release\ARMV6_ABIV1\

            GCCE

            v5

            GCCE

            v2

            epoc32\release\gcce\

            How to switch to ABI v1 mode

            To switch back to ABI v1 mode from ABI v2 mode, disable the ENABLE_ABIV2_MODE macro. You can disable the macro either by commenting it or removing it from the variant.cfg file.

            After you disable the ENABLE_ABIV2_MODE macro, the following abld commands will create binaries conforming to ABI v1 under epoc32\release\ARMV5\ or epoc32\release\ARMV6\ folders:

            abld build

            abld build ARMV5

            abld build ARMV6

            If you want to build binaries conforming to ABI v2 under epoc32\release\ARMV5_ABIV2\ or epoc32\release\ARMV6_ABIV2\ folders, use the following abld commands:

            abld build ARMV5_ABIV2

            abld build ARMV6_ABIV2

            \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-809D428D-5BF6-57FF-952D-2FDF88E50833.dita --- a/Symbian3/SDK/Source/GUID-809D428D-5BF6-57FF-952D-2FDF88E50833.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -stdcpp

            stdcpp

            This keyword must be included in the project specification file (.mmp) to build a Symbian target (EXE, DLL, LIB, and so on) using the standard C++ semantics for global new operator. To know how the global new operator is handled in standard C++ and Symbian C++, refer to Standard C++ Library in the Generic Open Libraries (P.I.P.S.).

            By default all Symbian targets use the Symbian C++ semantics for global new operator.

            Note: If an .mmp file includes both stdcpp and nostdcpp keywords, the build system will ignore the keywords and use the Symbian C++ semantics to build the target.

            See also

            nostdcpp

            \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-80E8BA3A-FDF3-50A5-BF44-181C40C31F09.dita --- a/Symbian3/SDK/Source/GUID-80E8BA3A-FDF3-50A5-BF44-181C40C31F09.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-80E8BA3A-FDF3-50A5-BF44-181C40C31F09.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,5 +9,5 @@ --> -Video Subtitle CRP Overview

            This document introduces you to the Video Subtitle CRP component.

            Purpose

            The Video Subtitle CRP component is used for displaying subtitles artwork on a video window.

            Architectural relationship

            Video Subtitle CRP interacts with WServ Process; and Client Process interacts with Controller Process by a client thread and controller thread respectively.

            CRP is a plug-in framework provided by Window Server (WServ). WServ is the server side process which allows the artwork providers to render content to the application window within the WServ process.

            Client Process is the client side implementation of subtitle support using CVideoPlayerUtility2 class.

            Control Process contains Video Player Controller and Subtitle Decoder and Render to process the subtitle artwork on a video window.

            For information about Video Client API see Video Client Overview and for Multimedia Framework see Multimedia Framework Overview

            The architectural relationship between WServ Process, Client Process and Controller Process is shown below:

            Library summary

            The Video Subtitle CRP component consists of the following libraries:

            Library Description

            subtitlegraphic.dll

            The Subtitle Graphic library is used to add subtitle CRP for MMF. For more information, see Subtitle Graphic Overview.

            Typical uses

            The Video Subtitle CRP Component is used to add subtitle for a video.

            Subtitle Graphic Overview Video Subtitle CRP Support From +Video Subtitle CRP Overview

            This document introduces you to the Video Subtitle CRP component.

            Purpose

            The Video Subtitle CRP component is used for displaying subtitles artwork on a video window.

            Architectural relationship

            Video Subtitle CRP interacts with WServ Process; and Client Process interacts with Controller Process by a client thread and controller thread respectively.

            CRP is a plug-in framework provided by Window Server (WServ). WServ is the server side process which allows the artwork providers to render content to the application window within the WServ process.

            Client Process is the client side implementation of subtitle support using CVideoPlayerUtility2 class.

            Control Process contains Video Player Controller and Subtitle Decoder and Render to process the subtitle artwork on a video window.

            For information about Video Client API see Video Client Overview and for Multimedia Framework see Multimedia Framework Overview

            The architectural relationship between WServ Process, Client Process and Controller Process is shown below:

            Library summary

            The Video Subtitle CRP component consists of the following libraries:

            Library Description

            subtitlegraphic.dll

            The Subtitle Graphic library is used to add subtitle CRP for MMF. For more information, see Subtitle Graphic Overview.

            Typical uses

            The Video Subtitle CRP Component is used to add subtitle for a video.

            Subtitle Graphic Overview Video Subtitle CRP Support From MMF             \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-80EC80E2-E197-50F7-B1FD-720A00AC3B4D.dita --- a/Symbian3/SDK/Source/GUID-80EC80E2-E197-50F7-B1FD-720A00AC3B4D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-80EC80E2-E197-50F7-B1FD-720A00AC3B4D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -126,7 +126,7 @@

          • CCamera::CCameraVideoCaptureControl

            It controls the operations related to video capture.

          The class diagram of CCamera is shown below:

          - +
          Using Onboard Ecam API

          The clients can use CCamera function to control and acquire image data from the camera.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-80F2A7AC-6E86-54F2-96F0-4417A2AEA017.dita --- a/Symbian3/SDK/Source/GUID-80F2A7AC-6E86-54F2-96F0-4417A2AEA017.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-80F2A7AC-6E86-54F2-96F0-4417A2AEA017.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,7 +31,7 @@ The RMutex object exists on the user side; the corresponding mutex (a DMutex object) exists on the Kernel side.

          - +

          Here, code running on the user side constructs an RMutex and calls its Create() member function. This causes the Kernel diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-80F2DEC8-152F-4681-A9D0-8EB776131313.dita --- a/Symbian3/SDK/Source/GUID-80F2DEC8-152F-4681-A9D0-8EB776131313.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-80F2DEC8-152F-4681-A9D0-8EB776131313.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ functionality is called from a Symbian/S60 application, the need for conversions between Symbian descriptors and different string types provided by P.I.P.S. is needed. -

          Symbian +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-1"> <title>Symbian descriptors and C strings compared

          The main difference between Symbian descriptors and C strings is that the Symbian descriptors know how many characters are in a data array. A C string does not know its length, @@ -110,7 +110,7 @@

          -
          How +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-2"> <title>How to convert <codeph>TBuf16</codeph> to a <codeph>char</codeph> buffer

          A TBuf16 buffer can be converted to a char buffer using the wcstombs API. The example below illustrates how @@ -135,7 +135,7 @@ return (1); }

          -
          How +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-3"> <title>How to convert <codeph>TBuf8</codeph> to <codeph>wchar_t</codeph>

          A TBuf8 buffer can be converted to wchar_t using the mbstowcs API.

          #include <e32base.h> @@ -159,7 +159,7 @@ return (1); }
          -
          How +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-4"> <title>How to convert <codeph>TText16</codeph> to <codeph>char</codeph>

          The wcstombs API can be used to convert a TText16 buffer to a char buffer. This is one of the examples of converting @@ -184,7 +184,7 @@ return (1); }

          -
          How +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-5"> <title>How to convert a <codeph>char</codeph> array and a <codeph>wide char</codeph> array

          To use both char and wide char pointers or array in the program, the user must convert buffers from a char to @@ -231,7 +231,7 @@ return (1); }

          -
          How +<section id="GUID-A6479BB3-0176-4321-8D33-1465DCCAB049-GENID-1-10-1-13-1-1-5-1-3-1-7-1-10-1-3-6"> <title>How to declare a <codeph>wide-char</codeph> string

          To declare a wide-char string, prefix the string with 'L' [Capital L].

          #include <wchar.h> diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8105D1FC-DFFE-59F0-A664-3DA44F002F47.dita --- a/Symbian3/SDK/Source/GUID-8105D1FC-DFFE-59F0-A664-3DA44F002F47.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8105D1FC-DFFE-59F0-A664-3DA44F002F47.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,93 +1,90 @@ - - - - - -Enabling -File Server TracingThis document describes how to enable trace points in the file -server client API (EFSRV.DLL), the file system API (*.FSY) , and/or the proxy -drive API. -
          Introduction

          Enabling a trace point -results in trace data being output to the trace buffer.

          Tracing can -be enabled or disabled (i.e. compiled in or out) at build time. By default -file server tracing is enabled in debug builds of EFSRV.DLL and EFILE.EXE -and disabled in release builds. To enable tracing in release builds, there -are two options:

            -

          • replace the release -builds of EFSRV.DLL /EFILE.EXE with -their debug equivalents.

            • -

          • rebuild EFSRV.DLL /EFILE.EXE using efsrv_instrumented.mmp /efile_instrumented.mmp.

            • -

          Tracing can also be enabled or disabled at run time or at device -startup. For more details, see How -to enable tracing.

          The level of tracing required may be configured -by selecting one or more of the primary filters and one or more of the secondary -filters from the list below:

          //Primary filters -EPanic = 192 // to trace panics -EError = 193 // to trace errors -EBorder = 195, // to trace API calls //Secondary filters -EF32TraceUidEfsrv = 0x100039e4 // (268450276 in decimal) -EF32TraceUidFileSys = 0x10286575 // (271082869 in decimal) -EF32TraceUidProxyDrive = 0x10286576 // (271082870 in decimal)

          For -more details on capturing the trace data see how -to output traces.

          -
          APIs

          The following table lists the classes to -which the trace points have been added. It has been divided into three broad -categories as shown below.

            -

          • File system

              -

            • CFileSystem

              • -

            • CMountCB

              • -

            • CFileCB

              • -

            • CDirCB

              • -

            • CFormatCB

              • -
            • -

          • Proxy drive

              -

            • CLocalProxyDrive

              • -

            • CBaseExtProxyDrive

              • -
            • -

          • File server

              -

            • RFile

              • -

            • RFs

              • -

            • RDir

              • -

            • RFormat

              • -

            • RPlugin

              • -

            • CFileMan

              • -

            • CDirScan

              • -
            • -

          Trace points have been added to the public exported functions of -the classes listed above. As an example, the code fragment below illustrates -how the tracepoints have been added and what type of information is output -for the Open function of the RFile class:

          -EFSRV_EXPORT_C TInt RFile::Open(RFs& aFs,const TDesC& aName,TUint aMode) -{ -TRACEMULT3(UTF::EBorder, UTraceModuleEfsrv::EFileOpen, MODULEUID, aFs.Handle(), aMode, aName); - -aMode &= ~EFileBigFile; -TInt r = CreateSubSession(aFs,EFsFileOpen,TIpcArgs(&aName,aMode)); - -TRACERET2(UTF::EBorder, UTraceModuleEfsrv::EFileOpenReturn, MODULEUID, r, SubSessionHandle()); - -return r; -}

          A sample trace output is as shown:

          RFile::Open() sess 0x00008000 mode 0x00000100 FileName Z:\SYS\DATA\ESTARTFILESYSTEMS.TXT
          -
          Interpretation of the trace data

          Symbian does not -currently provide a tool for decoding file server trace data (though hopefully -this will change in the near future). The data can, however, be interpreted -by examining the following two publicly exported header files which provides -detail of what fields are output by each tracepoint.

            -

          • \epoc32\include\utraceefsrv.h

            • -

          • \epoc32\include\utraceefile.h

            • -

          For example:

          -/** @SYMTraceFormatString "RFile::Replace() sess %x mode %x FileName %*S" */ -EFileReplace

          In the above example the trace record will contain -the session RFs handle, the file open mode and the filename.

          -           -Unified Trace -solution -Kernel Trace -Tool Overview + + + + + +Enabling File Server TracingThis document describes how to enable trace points in the +file server client API (EFSRV.DLL), the file system API (*.FSY) , +and/or the proxy drive API. +
          Introduction

          Enabling a trace point results in trace data being output to +the trace buffer.

          Tracing can be enabled or disabled (i.e. +compiled in or out) at build time. By default file server tracing +is enabled in debug builds of EFSRV.DLL and EFILE.EXE and disabled +in release builds. To enable tracing in release builds, there are +two options:

            +

          • replace the +release builds of EFSRV.DLL /EFILE.EXE with their debug equivalents.

            • +

          • rebuild EFSRV.DLL /EFILE.EXE using efsrv_instrumented.mmp /efile_instrumented.mmp.

            • +

          Tracing can also be enabled or disabled at run time or at +device startup. For more information, see Symbian^3 Tools Guide +> Debugging.

          The level of tracing required may be configured +by selecting one or more of the primary filters and one or more of +the secondary filters from the list below:

          //Primary filters +EPanic = 192 // to trace panics +EError = 193 // to trace errors +EBorder = 195, // to trace API calls //Secondary filters +EF32TraceUidEfsrv = 0x100039e4 // (268450276 in decimal) +EF32TraceUidFileSys = 0x10286575 // (271082869 in decimal) +EF32TraceUidProxyDrive = 0x10286576 // (271082870 in decimal)

          For more information on capturing the trace data, see Symbian^3 +Tools Guide > Debugging.

          +
          APIs

          The following table lists the classes to which the trace points +have been added. It has been divided into three broad categories as +shown below.

            +

          • File system

              +

            • CFileSystem

              • +

            • CMountCB

              • +

            • CFileCB

              • +

            • CDirCB

              • +

            • CFormatCB

              • +
            • +

          • Proxy drive

              +

            • CLocalProxyDrive

              • +

            • CBaseExtProxyDrive

              • +
            • +

          • File server

              +

            • RFile

              • +

            • RFs

              • +

            • RDir

              • +

            • RFormat

              • +

            • RPlugin

              • +

            • CFileMan

              • +

            • CDirScan

              • +
            • +

          Trace points have been added to the public exported functions +of the classes listed above. As an example, the code fragment below +illustrates how the tracepoints have been added and what type of information +is output for the Open function of the RFile class:

          +EFSRV_EXPORT_C TInt RFile::Open(RFs& aFs,const TDesC& aName,TUint aMode) +{ +TRACEMULT3(UTF::EBorder, UTraceModuleEfsrv::EFileOpen, MODULEUID, aFs.Handle(), aMode, aName); + +aMode &= ~EFileBigFile; +TInt r = CreateSubSession(aFs,EFsFileOpen,TIpcArgs(&aName,aMode)); + +TRACERET2(UTF::EBorder, UTraceModuleEfsrv::EFileOpenReturn, MODULEUID, r, SubSessionHandle()); + +return r; +}

          A sample trace output is as shown:

          RFile::Open() sess 0x00008000 mode 0x00000100 FileName Z:\SYS\DATA\ESTARTFILESYSTEMS.TXT
          +
          Interpretation +of the trace data

          Symbian does not currently provide a +tool for decoding file server trace data (though hopefully this will +change in the near future). The data can, however, be interpreted +by examining the following two publicly exported header files which +provides detail of what fields are output by each tracepoint.

            +

          • \epoc32\include\utraceefsrv.h

            • +

          • \epoc32\include\utraceefile.h

            • +

          For example:

          +/** @SYMTraceFormatString "RFile::Replace() sess %x mode %x FileName %*S" */ +EFileReplace

          In the above example the trace record +will contain the session RFs handle, the file open +mode and the filename.

          +           +Kernel +Trace Tool Overview           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e51653_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e51653_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e51796_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e51796_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e64462_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e64462_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e64605_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e64605_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e68897_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e68897_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e68921_href.png Binary file Symbian3/SDK/Source/GUID-81767E3E-BE4D-40D9-A4F2-3801BCCC1EA7_d0e68921_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-817D677C-2422-52B1-8D44-D15A0351FDC6_d0e169014_href.jpg Binary file Symbian3/SDK/Source/GUID-817D677C-2422-52B1-8D44-D15A0351FDC6_d0e169014_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-817D677C-2422-52B1-8D44-D15A0351FDC6_d0e174028_href.jpg Binary file Symbian3/SDK/Source/GUID-817D677C-2422-52B1-8D44-D15A0351FDC6_d0e174028_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81835322-5EF7-5839-9DC1-9A3FD396BD36.dita --- a/Symbian3/SDK/Source/GUID-81835322-5EF7-5839-9DC1-9A3FD396BD36.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to build GUI applications \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81A5784D-A0C6-5108-9E7B-5D39C6743B1A_d0e216847_href.png Binary file Symbian3/SDK/Source/GUID-81A5784D-A0C6-5108-9E7B-5D39C6743B1A_d0e216847_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81A5784D-A0C6-5108-9E7B-5D39C6743B1A_d0e221845_href.png Binary file Symbian3/SDK/Source/GUID-81A5784D-A0C6-5108-9E7B-5D39C6743B1A_d0e221845_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81C19443-4925-4949-8473-44370C8ACE90.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-81C19443-4925-4949-8473-44370C8ACE90.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,14 @@ + + + + + +Multimedia +ConceptThis section provides concept material that relates to the Multimedia +module. \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-81E33E18-D390-4110-8D85-1FCDA9CC311E.dita --- a/Symbian3/SDK/Source/GUID-81E33E18-D390-4110-8D85-1FCDA9CC311E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-81E33E18-D390-4110-8D85-1FCDA9CC311E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ provided.

          Progress note - +
          Using progress notes in applications

          You can create either a basic diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-821FEEDD-81B8-5511-AC4E-B673A96F8CB4_d0e312224_href.png Binary file Symbian3/SDK/Source/GUID-821FEEDD-81B8-5511-AC4E-B673A96F8CB4_d0e312224_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-821FEEDD-81B8-5511-AC4E-B673A96F8CB4_d0e318694_href.png Binary file Symbian3/SDK/Source/GUID-821FEEDD-81B8-5511-AC4E-B673A96F8CB4_d0e318694_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8255A186-C1AC-44DA-844C-1FEA029C73BC.dita --- a/Symbian3/SDK/Source/GUID-8255A186-C1AC-44DA-844C-1FEA029C73BC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8255A186-C1AC-44DA-844C-1FEA029C73BC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,36 +1,36 @@ - - - - - -Publish -and Subscribe -

          Publish and Subscribe has replaced System Agent and the usage -of temporary Shared Data keys.

          -

          Publish and Subscribe allows the setting, retrieving and monitoring -of system-wide variables and provides a new inter process communication (IPC) -mechanism for peer to peer communication between threads. Threads may have -the role of the publisher or of the subscriber, while any thread can define -the property to be published. The process that defines a property can specify -access rights for both reading and writing. Rights can be defined in terms -of either requiring a particular capability, -by a process Secure -Identifier, or by a process VID.

          -

          Publish and Subscribe should be considered under any of the following -conditions:

          -
            -

          • An event should be sent simultaneously to multiple places -over the system.

            • -

          • Only the last value of the property is significant, not the -intermediate values.

            • -

          • The source of the value is not significant. The value may -have been set by any publisher with proper rights.

            • -
          -

          For more information about the use of Publish and Subscribe, see Using Publish and Subscribe.

          + + + + + +Publish and Subscribe +

          Publish and Subscribe has replaced System Agent and the +usage of temporary Shared Data keys.

          +

          Publish and Subscribe allows the setting, retrieving and monitoring +of system-wide variables and provides a new inter process communication +(IPC) mechanism for peer to peer communication between threads. Threads +may have the role of the publisher or of the subscriber, while any +thread can define the property to be published. The process that defines +a property can specify access rights for both reading and writing. +Rights can be defined in terms of either requiring a particular capability, by a process Secure Identifier, or by a process VID.

          +

          Publish and Subscribe should be considered under any of the +following conditions:

          +
            +

          • An event should be sent simultaneously to multiple +places over the system.

            • +

          • Only the last value of the property is significant, +not the intermediate values.

            • +

          • The source of the value is not significant. The value +may have been set by any publisher with proper rights.

            +
            • +
          +

          For more information about the use of Publish and Subscribe, +see Using Publish +and Subscribe.

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-82862A69-5E86-5924-BFF0-F7655FCBFAF0.dita --- a/Symbian3/SDK/Source/GUID-82862A69-5E86-5924-BFF0-F7655FCBFAF0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-82862A69-5E86-5924-BFF0-F7655FCBFAF0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,36 +1,33 @@ - - - - - -ContiguousnessDescription of contiguous data in flat and segmented buffers. -

          In flat buffers, all data is contiguous. The Ptr() function -always returns a pointer descriptor from the buffer position specified to -the end of the data, and the BackPtr() function always returns -a pointer descriptor from the beginning of the buffer to the buffer position -specified.

          -

          In segmented buffers, data is contained in segments and the maximum length -of contiguous data is the granularity of the buffer. The extent of contiguous -data contained in a segment may vary between a single byte, and the granularity, -if the insertion and deletion pattern is arbitrary.

          -

          However, the following guarantee is made: if the number of bytes inserted -or deleted in all insertion and deletion operations is a multiple of -some number n, and the granularity is also a multiple of this number n, -then all data extents will be a multiple of n in length. This implies -that the Ptr() function, given a buffer position which is -a multiple of n, will always return a pointer descriptor referring -to at least n bytes.

          -

          This property of segmented descriptors is exploited by the CArrayFixBase, CArrayVarBase and CArrayPakBase derived array classes. In these classes, all insertion or deletion operations -are always done in terms of the (fixed) length of data stored in the buffer. -Therefore, the data for an individual array element is always contiguous.

          -           - -Dynamic Arrays - + + + + + +ContiguousnessDescription of contiguous data in flat and segmented buffers. +

          In flat buffers, all data is contiguous. The Ptr() function always returns a pointer descriptor from the buffer position +specified to the end of the data, and the BackPtr() function always returns a pointer descriptor from the beginning +of the buffer to the buffer position specified.

          +

          In segmented buffers, data is contained in segments and the maximum +length of contiguous data is the granularity of the buffer. The extent +of contiguous data contained in a segment may vary between a single +byte, and the granularity, if the insertion and deletion pattern is +arbitrary.

          +

          However, the following guarantee is made: if the number of bytes +inserted or deleted in all insertion and deletion operations +is a multiple of some number n, and the granularity is also +a multiple of this number n, then all data extents will be +a multiple of n in length. This implies that the Ptr() function, given a buffer position which is a multiple of n, will always return a pointer descriptor referring to at least n bytes.

          +

          This property of segmented descriptors is exploited by the CArrayFixBase, CArrayVarBase and CArrayPakBase derived array classes. In these classes, all +insertion or deletion operations are always done in terms of the (fixed) +length of data stored in the buffer. Therefore, the data for an individual +array element is always contiguous.

          +           + +Dynamic Arrays           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-829C15B1-0769-4E90-935D-4DCA58895E81_d0e58353_href.png Binary file Symbian3/SDK/Source/GUID-829C15B1-0769-4E90-935D-4DCA58895E81_d0e58353_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-829C15B1-0769-4E90-935D-4DCA58895E81_d0e58496_href.png Binary file Symbian3/SDK/Source/GUID-829C15B1-0769-4E90-935D-4DCA58895E81_d0e58496_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-82B73D69-0176-5CBB-B3ED-5CA7F5CCD5D9.dita --- a/Symbian3/SDK/Source/GUID-82B73D69-0176-5CBB-B3ED-5CA7F5CCD5D9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-82B73D69-0176-5CBB-B3ED-5CA7F5CCD5D9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -32,7 +32,7 @@ classes and cannot be instantiated, However, these types can be passed as arguments to functions.

          - +

          Inheritance relationship between the concrete descriptor classes and their abstract base classes

           diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-82B8C95E-F7E7-59C2-A71A-4C882653D555.dita --- a/Symbian3/SDK/Source/GUID-82B8C95E-F7E7-59C2-A71A-4C882653D555.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-82B8C95E-F7E7-59C2-A71A-4C882653D555.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Continuous Digital ZoomingThis tutorial describes how to perform continuous digital zooming using the Ecam API.

          Before you start you should understand the following topics:

          • Overview of the advanced Camera settings functionality.

          • Tutorial of the advanced Camera settings functionality.

          For advanced camera settings, the continuous digital zooming API provides a greater control over continuous zoom by allowing you to specify the speed and acceleration of each continuous zoom operation. The minimum speed for zooming is zero and the minimum acceleration is a negative value (which means deceleration).

          For continuous zooming, you need to provide a concrete implementation of MCameraContinuousZoom.

          Call CCameraAdvancedSettings::NewL(CCamera&) to create a CCameraAdvancedSettings object. Call CCameraAdvancedSettings::GetSupportedContinuousZoomTypeL(TUint&) to retrieve supported continuous zoom options for CCameraAdvancedSettings. Call CCameraAdvancedSettings::CreateContinuousZoomL(MContinuousZoomObserver&, +Continuous Digital ZoomingThis tutorial describes how to perform continuous digital zooming using the Ecam API.

          Before you start you should understand the following topics:

          • Overview of the advanced Camera settings functionality.

          • Tutorial of the advanced Camera settings functionality.

          For advanced camera settings, the continuous digital zooming API provides a greater control over continuous zoom by allowing you to specify the speed and acceleration of each continuous zoom operation. The minimum speed for zooming is zero and the minimum acceleration is a negative value (which means deceleration).

          For continuous zooming, you need to provide a concrete implementation of MCameraContinuousZoom.

          Call CCameraAdvancedSettings::NewL(CCamera&) to create a CCameraAdvancedSettings object. Call CCameraAdvancedSettings::GetSupportedContinuousZoomTypeL(TUint&) to retrieve supported continuous zoom options for CCameraAdvancedSettings. Call CCameraAdvancedSettings::CreateContinuousZoomL(MContinuousZoomObserver&, TContinuousZoomType, CCameraContinuousZoom*&) to create a continuous zoom object. Call CCameraContinuousZoom::GetContinuousZoomSupportInfoL(CCameraAdvancedSettings::TContinuousZoomSupportInfo&) to retrieve information about the supported settings related to continuous zoom. Call CCameraAdvancedSettings::StartContinuousZoomL(CCameraAdvancedSettings::TContinuousZoomParameters) to start the continuous zoom operation. Call the CCameraContinuousZoom::ContinuousZoomProgress(CCameraContinuousZoom&, TInt, TInt) function when a new zoom factor has achieved during the current continuous zoom operation. Call the CCameraAdvancedSettings::GetContinuousZoomId (TInt aZoomId) function when you use more than one continuous zoom operation. This function is used to retrieve a unique ID which you can use to determine the callback function (like ContinuousZoomProgress() or ContinuousZoomCompleted()) is associated with which continuous zoom object. Call CCameraContinuousZoom::ContinuousZoomCompleted() to inform you that the continuous zoom function has either completed successfully or to report an error that has caused the operation to fail. Note: This callback function does not actually stop the continuous zoom. Call CCameraAdvancedSettings::StopContinuousZoom() to stop continuous zooming, if the continuous zoom function has not already completed. Example

          The following example shows you how to perform continuous digital zooming using the Ecam API:

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8300FD98-38D7-43EF-A71E-A7BEBFC3F8ED_d0e61693_href.png Binary file Symbian3/SDK/Source/GUID-8300FD98-38D7-43EF-A71E-A7BEBFC3F8ED_d0e61693_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8300FD98-38D7-43EF-A71E-A7BEBFC3F8ED_d0e61836_href.png Binary file Symbian3/SDK/Source/GUID-8300FD98-38D7-43EF-A71E-A7BEBFC3F8ED_d0e61836_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8305F179-8F26-4B38-8523-066D1B0B7A62_d0e212256_href.png Binary file Symbian3/SDK/Source/GUID-8305F179-8F26-4B38-8523-066D1B0B7A62_d0e212256_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8305F179-8F26-4B38-8523-066D1B0B7A62_d0e217254_href.png Binary file Symbian3/SDK/Source/GUID-8305F179-8F26-4B38-8523-066D1B0B7A62_d0e217254_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita --- a/Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-830E40D0-7DEE-5EFB-BCC6-EC0AA7FF7A02.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ server. The client/server interface is not to be used directly by applications, but through framework functions in the AppUi (CCoeAppUi).

          View Server architecture - +
          Description

          The API has several key concepts:

          Abstract view interface

          The abstract view interface is implemented by application diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83630B57-D842-4B60-8AF0-D2965251DE29.dita --- a/Symbian3/SDK/Source/GUID-83630B57-D842-4B60-8AF0-D2965251DE29.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-83630B57-D842-4B60-8AF0-D2965251DE29.dita Tue Jul 20 12:00:49 2010 +0100 @@ -65,8 +65,8 @@ and ESensrvArrayPropertyInfo as the index to retrieve the property item that contains this information.

        - -Create an instance + +Create an instance of TSensrvProperty. TSensrvProperty property;

        Each channel property is encapsulated by the TSensrvProperty class. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8367DC46-FB9C-554F-8DFF-5C0328F59EF6.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-8367DC46-FB9C-554F-8DFF-5C0328F59EF6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Secure Sockets ExamplesThis describes the example code for Secure Sockets. \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83798F82-15FB-4EA6-9AD8-540616CBF6C4.dita --- a/Symbian3/SDK/Source/GUID-83798F82-15FB-4EA6-9AD8-540616CBF6C4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-83798F82-15FB-4EA6-9AD8-540616CBF6C4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,10 +22,10 @@ pane section.

        Example images of pop-up components with two softkeys - + Examples images of pop-ups with one softkey - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8390D842-B8A3-5042-952D-73240DB30D6B.dita --- a/Symbian3/SDK/Source/GUID-8390D842-B8A3-5042-952D-73240DB30D6B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8390D842-B8A3-5042-952D-73240DB30D6B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,7 +31,7 @@ by third-parties.

        Logical structure of Messaging Middleware architecture - + No lower-level communication components are shown, as the architecture is designed to be independent of any particular communication protocol. Instead, communication libraries are accessed as needed by Server MTMs. For example, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83A4D862-368E-5DCC-998E-90144BE18A22.dita --- a/Symbian3/SDK/Source/GUID-83A4D862-368E-5DCC-998E-90144BE18A22.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-83A4D862-368E-5DCC-998E-90144BE18A22.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> How to Override Default Authentication Handling

        SIP provides a feature to the SIP client to handle authentication handling for services such as registration and session establishment. By default, this authentication challenge handling is handled by the SIP server using the digest mechanism. This mechanism is used by profile plug-ins that implement nondefault SIP behaviour which is also known as extensible Service Provider (xSP).

        These components are used when a SIP client handles authentication challenges independently. When an authentication problem is reported use CSIPAuthorizationHeader and CSIPProxyAuthorizationHeader objects to manipulate the registration or session initiation request headers. Then re-register a profile or reinitiate a session using the updated headers.

        To enable a client to override default authentication handling mechanisms, it must inform the SIP server by disabling the built-in security mechanism of the SIP using the CSIP::SetSecurityHandlingL() function. The client uses CSIP::IsSecurityHandlingEnabled() function to determine what is handling the authentication challenges. This function returns ETrue if the built-in security mechanism of the SIP is used.

        When a SIP client handles authentication challenges independently, it uses CSIPAuthorizationHeader and CSIPProxyAuthorizationHeader objects to manipulate the registration or session initiation request headers when an authentication problem is reported. Re-registration of a profile or reinitiating a session is done using the updated headers.

        In the following illustration the client handles authentication challenges related to the profile registration. All authentication errors are then forwarded to the xSP profile agent plug-in. When an error is reported to the plug-in, it runs a proprietary authentication procedure and tries to re-register the profile.

        The following illustration shows the call flow of handling authentication challenges while registering a SIP profile:

        Call flow for handling 401 challenges using xSP profile agent plug-in -

        In the following illustration the client handles authentication challenges related to the session initiation. All the authentication errors are then forwarded to the xSP provider. When an error is reported to the provider, it runs a proprietary authentication procedure and tries to reinitiate the session.

        The following illustration shows the call flow of handling authentication challenges while establishing a session:

        +

        In the following illustration the client handles authentication challenges related to the session initiation. All the authentication errors are then forwarded to the xSP provider. When an error is reported to the provider, it runs a proprietary authentication procedure and tries to reinitiate the session.

        The following illustration shows the call flow of handling authentication challenges while establishing a session:

        Call flow for handling 401 challenges using xSP provider -
        See also

        How to use the SIP Client API

        \ No newline at end of file +
        See also

        How to use the SIP Client API

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83BE15D8-511F-592D-A93B-C71BD6FB1B08.dita --- a/Symbian3/SDK/Source/GUID-83BE15D8-511F-592D-A93B-C71BD6FB1B08.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-83BE15D8-511F-592D-A93B-C71BD6FB1B08.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ a Symbian platform defined record.

        You create a table object on the heap. You use the new (Eleave) construction to create this object.

        - +

        The CommsDat API implements the table as an array of records and uses RPointerArray <T> as the array. The CommsDat API implements RPointerArray<T> in diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83DC4E21-72B3-459F-9AE8-41ED52BF219C_d0e65944_href.png Binary file Symbian3/SDK/Source/GUID-83DC4E21-72B3-459F-9AE8-41ED52BF219C_d0e65944_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-83DC4E21-72B3-459F-9AE8-41ED52BF219C_d0e66087_href.png Binary file Symbian3/SDK/Source/GUID-83DC4E21-72B3-459F-9AE8-41ED52BF219C_d0e66087_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-845F3021-E3ED-4676-916A-75740886DCBD.dita --- a/Symbian3/SDK/Source/GUID-845F3021-E3ED-4676-916A-75740886DCBD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-845F3021-E3ED-4676-916A-75740886DCBD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -52,7 +52,7 @@

      Use cases Choice list API use cases - +

      To use a choice list in your application, implementing the following use cases is mandatory:

      • Creating the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-84897583-A06F-42EE-917D-DF908B095AFF_d0e316089_href.png Binary file Symbian3/SDK/Source/GUID-84897583-A06F-42EE-917D-DF908B095AFF_d0e316089_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-84897583-A06F-42EE-917D-DF908B095AFF_d0e322559_href.png Binary file Symbian3/SDK/Source/GUID-84897583-A06F-42EE-917D-DF908B095AFF_d0e322559_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-85058500-87C5-457A-9567-ECAB29708759.dita --- a/Symbian3/SDK/Source/GUID-85058500-87C5-457A-9567-ECAB29708759.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-85058500-87C5-457A-9567-ECAB29708759.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,14 +13,14 @@ in pop-up windowsVertical lists are used extensively in most applications as part of the pop-up windows, to display the options available for a selected item. - +

        Design Guidelines : Lists do not have permanent highlight in touch. For information on the list navigation, see Dragging and flicking and Scrollbar.

        Tactile: For information about the feedback of list navigation, see Dragging and flicking and Scrollbar. For pop-up related tactile feedback, refer to Pop-ups.

        -Default touch +<table id="GUID-5B8DA500-4092-4E1A-A035-308C4D352138-GENID-1-10-1-7-1-1-5-1-8-1-1-9-1-7-1-3-4"><title>Default touch events for lists in pop-up windows diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8526BBD8-CA70-4B3F-B91D-D70AF06440B2_d0e55432_href.png Binary file Symbian3/SDK/Source/GUID-8526BBD8-CA70-4B3F-B91D-D70AF06440B2_d0e55432_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8526BBD8-CA70-4B3F-B91D-D70AF06440B2_d0e55575_href.png Binary file Symbian3/SDK/Source/GUID-8526BBD8-CA70-4B3F-B91D-D70AF06440B2_d0e55575_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-85291DF3-C134-4231-938A-C20DD122AB7D_d0e12428_href.png Binary file Symbian3/SDK/Source/GUID-85291DF3-C134-4231-938A-C20DD122AB7D_d0e12428_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-85291DF3-C134-4231-938A-C20DD122AB7D_d0e12531_href.png Binary file Symbian3/SDK/Source/GUID-85291DF3-C134-4231-938A-C20DD122AB7D_d0e12531_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-857A523E-E660-5AFA-98B1-3A5440A8372F_d0e250294_href.jpg Binary file Symbian3/SDK/Source/GUID-857A523E-E660-5AFA-98B1-3A5440A8372F_d0e250294_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-857A523E-E660-5AFA-98B1-3A5440A8372F_d0e255233_href.jpg Binary file Symbian3/SDK/Source/GUID-857A523E-E660-5AFA-98B1-3A5440A8372F_d0e255233_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita --- a/Symbian3/SDK/Source/GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@ The display is an orthogonal view of a series of layers. - +

        Composition requires:

          @@ -68,7 +68,7 @@ output which is rendered, composited and displayed.

          Graphics Composition - +

          In a device with graphics acceleration hardware (a Graphics Processing Unit or GPU) there might, in addition to the memory managed by the CPU, be @@ -79,7 +79,7 @@ in software and hardware.

          Hardware rendered graphics - the wrong way! - +

          The diagram, however, represents a system with several problem areas that would render it unsuitable for any practical implementation

          @@ -116,7 +116,7 @@ display. The diagram below illustrates how Window Server-rendered UI content and external surfaces are composited using the UI surface.

          Hardware composition and the Flattened UI - +

          Although this method of composition is flexible and powerful, it does have some limitations, particularly with respect to semi-transparent hardware-accelerated surfaces.

          It is not possible, for example, to @@ -128,18 +128,18 @@ green layer displays a hardware rendered surface so it is actually behind the layer on which it appears.

          The UI surface - +
          Composition Examples

          This illustrations below illustrate the use of hardware accelerated surfaces and the UI surface

          Video rendered to a hardware accelerated surface mapped to a layer behind the UI surface - + As above with a semi-transparent dialog on the UI surface - +
          The ScreenPlay diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-85CA1089-3F58-5E82-86A4-4674C893B25F.dita --- a/Symbian3/SDK/Source/GUID-85CA1089-3F58-5E82-86A4-4674C893B25F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-85CA1089-3F58-5E82-86A4-4674C893B25F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -31,11 +31,11 @@ of the SIP Codec API classes.

          Relationships of the SIP Codec classes - Part 1 - + Relationships of the SIP Codec classes - Part 2 - +

          The SIP Codec API defines the functions required to create the SIP headers of a SIP message. CSIPHeaderBase is the base class for all SIP headers. A client creates a new instance of the CSIPXHeader class, where “X” is the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-860DCACE-4C5A-508F-B94C-12336E96D1C7_d0e364024_href.png Binary file Symbian3/SDK/Source/GUID-860DCACE-4C5A-508F-B94C-12336E96D1C7_d0e364024_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-860DCACE-4C5A-508F-B94C-12336E96D1C7_d0e383173_href.png Binary file Symbian3/SDK/Source/GUID-860DCACE-4C5A-508F-B94C-12336E96D1C7_d0e383173_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8675AC01-E2D8-425C-899F-12BE99345AA9.dita --- a/Symbian3/SDK/Source/GUID-8675AC01-E2D8-425C-899F-12BE99345AA9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8675AC01-E2D8-425C-899F-12BE99345AA9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -83,7 +83,7 @@ // 3 wasted bytes TReal iReal; // offset 8, 8 bytes } // total length = 16 bytes - +

          Structures are regarded as T types: that is they may not own heap-allocated resources such as C type classes.

          An array contains many built-ins or other types

          TInt a[32]; // 32 TInts, = 128 bytes @@ -98,7 +98,7 @@ take the address of an object, then you can refer to it by pointer:

          S* ps; // pointer to an S ps=&s // take address of existing S

          A pointer is a 32-bit machine word, and could point to anything.

          - +

          The specifier is placed next to the type rather than the name.

          There is often a need to refer to memory as anything: for this, a void* pointer is used in C++. In Symbian, a TAny* may be referred to instead. @@ -108,7 +108,7 @@ does two things: firstly, it sets aside six bytes of memory containing the characters 'h', 'e', 'l', 'l', 'o', '\0'. Secondly, it sets the pointer hello to contain the address of the first of those bytes.

          - +

          Functions accessing the string rely on this address as its starting point, and the terminating \0 to indicate its end. Functions which manipulate the string must either deliberately not extend it, or must diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-86AADA3E-B77C-45CC-B523-785B75BAA5AA.dita --- a/Symbian3/SDK/Source/GUID-86AADA3E-B77C-45CC-B523-785B75BAA5AA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-86AADA3E-B77C-45CC-B523-785B75BAA5AA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ Menu with a 3 x 4 grid in portrait (left) and 4 x 3 grid in landscape (right) - +

          For more details on the landscape orientation, see Symbian UI with rotation.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-873186CE-9723-558F-9C7E-0CEE607F076C_d0e429248_href.png Binary file Symbian3/SDK/Source/GUID-873186CE-9723-558F-9C7E-0CEE607F076C_d0e429248_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-873186CE-9723-558F-9C7E-0CEE607F076C_d0e433048_href.png Binary file Symbian3/SDK/Source/GUID-873186CE-9723-558F-9C7E-0CEE607F076C_d0e433048_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-875D74D3-5663-42E3-A4B9-294F82FF5486.dita --- a/Symbian3/SDK/Source/GUID-875D74D3-5663-42E3-A4B9-294F82FF5486.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-875D74D3-5663-42E3-A4B9-294F82FF5486.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ every kind of successful action).

          Confirmation note - +
          Guidelines for using confirmation notes

          Use a confirmation note when:

            diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8761F82E-5DC4-5BD5-A422-2EC45A92925B_d0e364307_href.png Binary file Symbian3/SDK/Source/GUID-8761F82E-5DC4-5BD5-A422-2EC45A92925B_d0e364307_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8761F82E-5DC4-5BD5-A422-2EC45A92925B_d0e383456_href.png Binary file Symbian3/SDK/Source/GUID-8761F82E-5DC4-5BD5-A422-2EC45A92925B_d0e383456_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-876EE000-01B7-4457-AE9C-CE56E48CFF11_d0e67402_href.png Binary file Symbian3/SDK/Source/GUID-876EE000-01B7-4457-AE9C-CE56E48CFF11_d0e67402_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-881C353C-6482-4DFE-9D43-CFB80DEB77A5_d0e5894_href.png Binary file Symbian3/SDK/Source/GUID-881C353C-6482-4DFE-9D43-CFB80DEB77A5_d0e5894_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-881C353C-6482-4DFE-9D43-CFB80DEB77A5_d0e6015_href.png Binary file Symbian3/SDK/Source/GUID-881C353C-6482-4DFE-9D43-CFB80DEB77A5_d0e6015_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8862E271-ABA4-5A25-8990-C0B3931E370D_d0e406639_href.png Binary file Symbian3/SDK/Source/GUID-8862E271-ABA4-5A25-8990-C0B3931E370D_d0e406639_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8862E271-ABA4-5A25-8990-C0B3931E370D_d0e410439_href.png Binary file Symbian3/SDK/Source/GUID-8862E271-ABA4-5A25-8990-C0B3931E370D_d0e410439_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e190349_href.png Binary file Symbian3/SDK/Source/GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e190349_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e195320_href.png Binary file Symbian3/SDK/Source/GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e195320_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-894AB487-C127-532D-852B-37CB0DEA1440.dita --- a/Symbian3/SDK/Source/GUID-894AB487-C127-532D-852B-37CB0DEA1440.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-894AB487-C127-532D-852B-37CB0DEA1440.dita Tue Jul 20 12:00:49 2010 +0100 @@ -150,7 +150,7 @@ on which it is to be shown.

            Each window has a parent window group which is associated with a screen - +

            When you create a window surface in EGL using eglCreateWindowSurface, you pass in the RWindow as an argument. The window surface is then displayed on the screen associated with that window's parent window group. Currently a window can exist on only one screen.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8983A095-3F5A-5262-8920-8A13ADD045DC_d0e220940_href.png Binary file Symbian3/SDK/Source/GUID-8983A095-3F5A-5262-8920-8A13ADD045DC_d0e220940_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8983A095-3F5A-5262-8920-8A13ADD045DC_d0e225934_href.png Binary file Symbian3/SDK/Source/GUID-8983A095-3F5A-5262-8920-8A13ADD045DC_d0e225934_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-89ADFC64-AF9F-51B1-AC5F-493897226270.dita --- a/Symbian3/SDK/Source/GUID-89ADFC64-AF9F-51B1-AC5F-493897226270.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,168 +0,0 @@ - - - - - -STRUCT -member types -<struct-member> -struct-member ::= -<member-declaration> [ = <initialiser> ]; <member-declaration> -member-declaration ::= -<type-name> <member-name> | [ LEN [ BYTE ] ] <type-name> <member-name> [ ( <length-limit> ) ] [ [ [ <array-size> ] ] ] <type-name> -type-name ::= -BYTE | WORD | LONG | TEXT | DOUBLE | LTEXT | BUF | BUF8 | BUF<n> | LINK | SRLINK | STRUCT -

          Member declaration

          -

          Each member of a struct is identified by a member-declaration followed -by an optional initialiser, and then a semi-colon.

          -

          The simplest form of member-declaration is to specify -a type-name and a member-name only:

          -STRUCT TEST - { - WORD length; - } -

          Type name

          -

          The type-name must be in upper case (WORD in -this example).

          -

          These are the valid types:

          -
        - - - -

        BYTE

        -

        A single byte.

        Can be treated as a signed integer (–128 -to +127) or unsigned integer (0 to 255).

         -         - -

        WORD

        -

        Two bytes.

        Can be treated as a signed integer (–32,768 to -+32,767) or unsigned integer (0 to 65,535).

         -         - -

        LONG

        -

        Four bytes.

        Can be treated as a signed integer (–2,147,483,648 -to 2147483647) or an unsigned integer (0 to 4,294,967,295).

         -         - -

        DOUBLE

        -

        Eight byte real for double precision floating point numbers (approximately -±1.7E±308).

         -         - -

        TEXT

        -

        A string, terminated by a null.

        This is deprecated: use LTEXT instead.

         -         - -

        LTEXT

        -

        A Unicode string with a leading byte which holds the length of the -string, and no terminating null.

        -         - -

        BUF

        -

        A Unicode string with no terminating null and no leading byte.

         -         - -

        BUF8

        -

        A string of 8-bit characters, with no terminating null and no leading -byte. Used for putting 8-bit data into a resource.

         -         - -

        BUF<n>

        -

        A Unicode string with no terminating null and no leading byte but -which has a maximum length n.

        This type is an alternative -to using the length-limit with BUF types.

         -         - -

        LINK

        -

        The ID of another resource (16 bits), rather like a pointer to that -resource.

         -         - -

        LLINK

        -

        The ID of another resource (32 bits).

         -         - -

        SRLINK

        -

        A self-referencing link. This is a 32 bit link which contains the -resource ID of the resource it is defined in.

        An SRLINK member -may not have an initialiser since it is self-referencing -and, therefore, only takes the value of the resource ID the struct is declared -in. This is assigned automatically by the resource compiler.

         -         - -

        STRUCT

        -

        Any struct, rather like including that struct as a member in this -struct.

        STRUCT members are useful because it means -that once a struct has been defined it can be re-used for a variety of resources.

         -         - - -
        -

        Note that:

        -
          -

        • Numbers more than one -byte long are stored little-endian: that is, their least significant byte -is stored first.

          • -

        • LINK and STRUCT are -not type-safe: it is the responsibility of the user of a struct to ensure -that the correct resource type is linked or included. The definer of a struct -should give some idea, perhaps using a comment:

          STRUCT TEST - { - WORD length; - STRUCT text; // should be a STRING - }
          • -
        -

        Length limits

        -

        A length limit may be specified for members of string type (BUF, TEXT and LTEXT). -The length limit is enclosed in parentheses after the member name, for instance:

        -STRUCT TEST - { - TEXT string1(9); - LTEXT string2(MAX); - BUF string3; - } -
          -

        • string1 has -a maximum of 9 characters, string2 a maximum of MAX characters -(where MAX has been #defined elsewhere) -and string3 has no maximum length. Note that this maximum -applies only to the actual characters and does not take account of the terminating -zero (for TEXT members) or leading byte (for LTEXT members).

          • -

        • Note that from v5 onwards, TEXT is -deprecated.

          • -

        • An alternative method -to using length-limit with a BUF type -is to use the type BUF<n>. For example, see the definition -of TEST and the resource definitions for test1, test2 and test3 in -the examples below.

          • -
        -

        Member name

        -

        The member-name must be in lower case.

        -STRUCT TEST - { - BUF<4> string; - }RESOURCE TEST test1 - { - string="abcd"; - }RESOURCE TEST test2 - { - string="ab"; - }RESOURCE TEST test3 - { - string="abcdef"; - }
          -

        • test1 generates 0x61 -0x00 0x62 0x00 0x63 0x00 0x64 0x00

          • -

        • test2 generates 0x61 -0x00 0x62 0x00

          • -

        • but test3 generates -an error because the maximum length of string permitted by -the definition of the STRUCT is 4.

          • -
         - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-89C5B56D-0846-4D32-94E5-CEF8BFA47D4E.dita --- a/Symbian3/SDK/Source/GUID-89C5B56D-0846-4D32-94E5-CEF8BFA47D4E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-89C5B56D-0846-4D32-94E5-CEF8BFA47D4E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,8 +20,8 @@

        To migrate from C Standard Library (ESTLIB) to P.I.P.S., perform the following steps:

         - - + +

        Replace the LIBRARY entry in the .MMP file from estlib.lib to libc.lib libm.lib libpthread.lib.

                 @@ -29,7 +29,7 @@

        Replace the LIBRARY entry in the .MMP file from ecrt0.lib to libcrt0.lib.

                 - +

        Replace the SYSTEMINCLUDE path from \epoc32\include\libc to \epoc32\include\stdapis.

        Important: If any non-POSIX worked around code (written to satisfy POSIX-deviated ESTLIB return codes) is present in your existing diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-89D8ECA6-23C3-5573-8DC6-10F7FF7B491F.dita --- a/Symbian3/SDK/Source/GUID-89D8ECA6-23C3-5573-8DC6-10F7FF7B491F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-89D8ECA6-23C3-5573-8DC6-10F7FF7B491F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,15 +11,15 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Types of Email

        This section describes the types of email that Messaging Middleware supports and the structure of email messages.

        The following are the types of email that are supported. The diagrams represent the structure of the message entries in the Message Server.

        Plain text messages

        Non-MIME emails are the simplest type of mail message and contain only a plain text message body.

        Plain text messages -
        UUEncoded messages

        To allow for binary files to be ‘attached’ to non-MIME emails, it is possible to UUEncode the binary data and include it as text within the message. A typical message would consist of some text, followed by the UUEncoded data, followed by more text and UUEncoded data.

        +
        UUEncoded messages

        To allow for binary files to be ‘attached’ to non-MIME emails, it is possible to UUEncode the binary data and include it as text within the message. A typical message would consist of some text, followed by the UUEncoded data, followed by more text and UUEncoded data.

        UUEncoded messages -
        Multipart messages

        The multipart messages are the most popular form of modern emails. Multipart messages contain a sequence of body parts which can in turn contain additional nested body parts. The simplest example would be a text message with a single binary attachment. Binary data is typically encoded using BASE64 encoding.

        +
        Multipart messages

        The multipart messages are the most popular form of modern emails. Multipart messages contain a sequence of body parts which can in turn contain additional nested body parts. The simplest example would be a text message with a single binary attachment. Binary data is typically encoded using BASE64 encoding.

        Multipart messages -
        HTML text messages

        HTML text messages contain an HTML representation of the message body text (complete with all text formatting) and a corresponding plain text version. The email client can then decide which to display to the user based in its capabilities.

        +
        HTML text messages

        HTML text messages contain an HTML representation of the message body text (complete with all text formatting) and a corresponding plain text version. The email client can then decide which to display to the user based in its capabilities.

        HTML text messages -
        HTML messages with attachments

        As with HTML text messages, these contain plain and HTML versions of the body text, as well as additional body parts containing potentially encoded attachment data.

        +
        HTML messages with attachments

        As with HTML text messages, these contain plain and HTML versions of the body text, as well as additional body parts containing potentially encoded attachment data.

        HTML messages with attachments -
        HTML messages with embedded message

        Messages can contain embedded messages within their body parts. This example shows a message with parts consisting of plain text, an attachment, and an embedded message. The embedded message in turn contains an attachment as well a plain and html versions of the body text.

        +
        HTML messages with embedded message

        Messages can contain embedded messages within their body parts. This example shows a message with parts consisting of plain text, an attachment, and an embedded message. The embedded message in turn contains an attachment as well a plain and html versions of the body text.

        HTML messages with embedded message -
        Storage of email parts

        The majority of the message data is stored within a single file. This contain separate streams for header information, MIME headers, attachment information and the rich text store. If the message contained attachments, a corresponding folder exists that stores each attachment as a separate decoded file.

        Message Server and Store Message Type Module IMAP4 +
      Storage of email parts

      The majority of the message data is stored within a single file. This contain separate streams for header information, MIME headers, attachment information and the rich text store. If the message contained attachments, a corresponding folder exists that stores each attachment as a separate decoded file.

      Message Server and Store Message Type Module IMAP4 MTM POP3 MTM SMTP MTM \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8A5054C9-7556-5153-8CEE-FA8E5F4155AE.dita --- a/Symbian3/SDK/Source/GUID-8A5054C9-7556-5153-8CEE-FA8E5F4155AE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8A5054C9-7556-5153-8CEE-FA8E5F4155AE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -90,7 +90,7 @@ Explicit binding example

      Client A creates a socket with explicit binding using the specified interface connection.

      sock1 = RSocket.Open(srv,conn);

      ESock creates the socket within the default connection and subconnection.

      - +

      A socket can also be opened over a sub-connection using RSubConnection. When the socket is opened, a new Service Access Point (SAP) is created for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8A7B837D-4069-5364-A596-686EEBAE351D.dita --- a/Symbian3/SDK/Source/GUID-8A7B837D-4069-5364-A596-686EEBAE351D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8A7B837D-4069-5364-A596-686EEBAE351D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,8 +9,150 @@ --> -Plug-In Framework Overview

      The Plug-in (ECom) framework is a generic framework that provides a single mechanism to register and discover plug-ins and load an appropriate plug-in.

      Purpose

      In early versions of Symbian platform, plug-ins were provided by polymorphic interface DLLs. All the frameworks within the Symbian platform that needed to use plug-ins had to provide their own mechanisms for the clients to discover and instantiate the implementations. This resulted in duplication of functionality.

      The Plug-In framework is intended to provide a common and system-wide mechanism for instantiating a dynamically determined component.

      Three distinct users of the plug-in framework are:

      • Framework or Application designers

        These users need to understand interface definition design and platform security implications.

      • Plug-in writers

        These users need to understand interface implementation, DLL creation and platform security implementation issue.

      • Plug-in users

        These users need to understand that the plug-in framework helps in selecting the plug-in but sometimes may need to specify which implementation the framework should choose.

      Required background

      Run-time Binding: This is called dynamic binding or late binding. The linking of a routine or object is performed during runtime based on the requirements.

      DLL (Dynamic Link Library): Is a piece of code (a library) that is linked to a program at runtime rather than during the build process. The code inside a DLL can be shared by several clients at the same time without being duplicated in the mobile memory.

      In addition , the user should be aware of the Platform Security Considerations of the plug-in framework architecture.

      Key concepts and terms
      Plug-in

      In computing, a plug-in(extension) consists of a computer program that interacts with a host application(a web browser or an email client) to provide a very specific function on demand.

      Applications support plugins to:

      • Enable third-party developers to create capabilities to extend an application.

      • Reduce the size of an application.

      • Separate source code from an application.

      Plug-in System

      A client wishes to access a plug-in. The plug-in details are known only at run-time. The general characteristics of the plug-in are defined in an interface. Multiple variants of the plug-in can co-exist.

      The four clearly-defined roles of a plug-in system are:

      • The Client that wishes to access services.

      • The Interface Definition that defines how to request services.

      • The Interface Implementation/Plug-in that provides the required processing.

      • The Framework that provides the clients with the required access to the implementations.

      The relationships can be represented as follows:

      - Plug-in relationships -

      The instantiation mechanism is responsible for providing the services that identify, and load the correct implementation at run-time.

      Interface

      Is an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation. It allows internal modification and this modification does not affect the outside entities interaction with the interface. An interface can provide multiple abstractions.

      Interface API / Interface Definition

      Is a template for an interface implementation.

      Interface Client/Client

      Is an application that uses the interface definition.

      Interface Implementation Collection

      Is a collection of interface implementations/plug-ins.

      Registry

      Is a collection of plug-ins registered with the framework.

      Architecture

      The plug-in framework employs the client server architecture. The client session is a singleton per process thread.

      - Plug-in framework architecture -

      The functional components of the plug-in framework are:

      • The Client /Interface Client that invokes the available services via the interface definition.

      • The Server / Framework controls access to a registry of available implementations that is used for interface implementation resolution and loading.

        The server facilitates:

        • Addition and removal of interface implementations.

          The addition, removal or modifications to an implementation is notified to the server. The server updates the changes in the registry.

        • Search/Access mechanisms.

          The registry data is maintained as a hierarchical arrangement of implementations. The complete data is scanned and matching interface implementation list is produced as a result of search.

        • Resolution mechanisms.

          The best fit implementation from the resultant search is identified.

        • Load control.

          Controls access to a single instance of the available implementations. The implementation identification information is used to load the appropriate collection.

      APIs API Description

      REComSession

      Resolves, instantiates, and destroys interface class implementations requested by the plug-in framework clients.

      Typical uses

      The plug-in framework allows:

      • Framework developers to write interface definitions and extend interfaces.

      • Plug-in writer to implement the interfaces.

      • Plug-in user to use the interfaces.

      Framework Developer Tutorials Plug-in Writer's Tutorials Plug-in User's Tutorials \ No newline at end of file +Plug-In Framework Overview +

      The Plug-in (ECom) framework is a generic framework that provides +a single mechanism to register and discover plug-ins and load an appropriate +plug-in.

      +
      Purpose

      In early versions of Symbian platform, +plug-ins were provided by polymorphic interface DLLs. +All the frameworks within the Symbian platform that needed to use +plug-ins had to provide their own mechanisms for the clients to discover +and instantiate the implementations. This resulted in duplication +of functionality.

      The Plug-In framework is intended to provide +a common and system-wide mechanism for instantiating a dynamically +determined component.

      Three distinct users of the plug-in +framework are:

        +

      • Framework or +Application designers

        These users need to understand interface +definition design and platform security implications.

        • +

      • Plug-in writers

        These users need to understand interface implementation, DLL +creation and platform security implementation issue.

        • +

      • Plug-in users

        These users need to understand that the plug-in framework helps +in selecting the plug-in but sometimes may need to specify which implementation +the framework should choose.

        • +
      +
      Required background

      Run-time Binding: This is called dynamic binding or late binding. The linking of +a routine or object is performed during runtime based on the requirements.

      DLL (Dynamic Link Library): Is a piece of code (a library) +that is linked to a program at runtime rather than during the build +process. The code inside a DLL can be shared by several clients at +the same time without being duplicated in the mobile memory.

      In addition , the user should be aware of the Platform Security +Considerations of the plug-in framework architecture.

      +
      Key concepts and terms
      + +
      Plug-in
      +

      In computing, a plug-in(extension) consists of a computer program +that interacts with a host application(a web browser or an email client) +to provide a very specific function on demand.

      Applications +support plugins to:

        +

      • Enable third-party +developers to create capabilities to extend an application.

        • +

      • Reduce the size +of an application.

        • +

      • Separate source +code from an application.

        • +
      +       + +
      Plug-in System
      +

      A client wishes to access a plug-in. The plug-in details are +known only at run-time. The general characteristics of the plug-in +are defined in an interface. Multiple variants of the plug-in can +co-exist.

      The four clearly-defined roles of a plug-in system +are:

        +

      • The Client that wishes to access services.

        • +

      • The Interface +Definition that defines how to request services.

        • +

      • The Interface +Implementation/Plug-in that provides the required processing.

        • +

      • The Framework that provides the clients with the required access to the implementations.

        • +

      The relationships can be represented as follows:

      + Plug-in relationships + +

      The instantiation mechanism is responsible for providing +the services that identify, and load the correct implementation at +run-time.

      +       + +
      Interface
      +

      Is an abstraction that an entity provides of itself to the +outside. This separates the methods of external communication from +internal operation. It allows internal modification and this modification +does not affect the outside entities interaction with the interface. +An interface can provide multiple abstractions.

      +       + +
      Interface API / Interface Definition
      +

      Is a template for an interface implementation.

      +       + +
      Interface Client/Client
      +

      Is an application that uses the interface definition.

      +       + +
      Interface Implementation Collection
      +

      Is a collection of interface implementations/plug-ins.

      +       + +
      Registry
      +

      Is a collection of plug-ins registered with the framework.

      +       +
      +
      Architecture

      The plug-in framework employs +the client server architecture. The client session is a singleton +per process thread.

      + Plug-in framework architecture + +

      The functional components of the plug-in framework are:

        +

      • The Client +/Interface Client that invokes the available services via the +interface definition.

        • +

      • The Server +/ Framework controls access to a registry of available implementations +that is used for interface implementation resolution and loading.

        The server facilitates:

          +

        • Addition and +removal of interface implementations.

          The addition, removal +or modifications to an implementation is notified to the server. The +server updates the changes in the registry.

          • +

        • Search/Access +mechanisms.

          The registry data is maintained as a hierarchical +arrangement of implementations. The complete data is scanned and matching +interface implementation list is produced as a result of search.

          • +

        • Resolution mechanisms.

          The best fit implementation from the resultant search is identified.

          • +

        • Load control.

          Controls access to a single instance of the available implementations. +The implementation identification information is used to load the +appropriate collection.

          • +
        • +
      +
      APIs + + + +API +Description + + + + +

      REComSession

      +

      Resolves, instantiates, and destroys interface class implementations +requested by the plug-in framework clients.

      +       + + +
      +
      Typical uses

      The plug-in framework allows:

        +

      • Framework developers +to write interface definitions and extend interfaces.

        • +

      • Plug-in writer +to implement the interfaces.

        • +

      • Plug-in user +to use the interfaces.

        • +
      +       +Framework +Developer Tutorials +Plug-in +Writer's Tutorials +Plug-in +User's Tutorials +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e52168_href.png Binary file Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e52168_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e52311_href.png Binary file Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e52311_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e74470_href.png Binary file Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e74470_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e74508_href.png Binary file Symbian3/SDK/Source/GUID-8AEE1966-D348-41BB-8513-61C379945DB8_d0e74508_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AF21373-E51E-5B9D-ACC1-243752C9BB5B_d0e357317_href.png Binary file Symbian3/SDK/Source/GUID-8AF21373-E51E-5B9D-ACC1-243752C9BB5B_d0e357317_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8AF21373-E51E-5B9D-ACC1-243752C9BB5B_d0e386310_href.png Binary file Symbian3/SDK/Source/GUID-8AF21373-E51E-5B9D-ACC1-243752C9BB5B_d0e386310_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B137691-7C9E-4085-BFFE-4CFE4A64A091.dita --- a/Symbian3/SDK/Source/GUID-8B137691-7C9E-4085-BFFE-4CFE4A64A091.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8B137691-7C9E-4085-BFFE-4CFE4A64A091.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ labels associated with the softkeys.

      Control pane - + In landscape orientation, a part of the status pane (the clock and indicator pane) is inside the control pane. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B1C7778-0C6D-5DEE-90FD-3B016EC0E3CE_d0e355357_href.png Binary file Symbian3/SDK/Source/GUID-8B1C7778-0C6D-5DEE-90FD-3B016EC0E3CE_d0e355357_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B1C7778-0C6D-5DEE-90FD-3B016EC0E3CE_d0e384350_href.png Binary file Symbian3/SDK/Source/GUID-8B1C7778-0C6D-5DEE-90FD-3B016EC0E3CE_d0e384350_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B37A2C7-B4DB-5826-B6C2-3C21012EF9EA_d0e45567_href.png Binary file Symbian3/SDK/Source/GUID-8B37A2C7-B4DB-5826-B6C2-3C21012EF9EA_d0e45567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B37A2C7-B4DB-5826-B6C2-3C21012EF9EA_d0e45725_href.png Binary file Symbian3/SDK/Source/GUID-8B37A2C7-B4DB-5826-B6C2-3C21012EF9EA_d0e45725_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8B4CC1A0-1A39-4AF0-826B-8DDB9A837A27.dita --- a/Symbian3/SDK/Source/GUID-8B4CC1A0-1A39-4AF0-826B-8DDB9A837A27.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8B4CC1A0-1A39-4AF0-826B-8DDB9A837A27.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ server defines a plug-in interface for adding sensor plug-ins for any type of sensor hardware. The channel APIs enable client applications to interact with the sensor hardware. -
      Key Concepts +<section id="GUID-AB7AB8C8-DEB2-445C-A216-1FE142592C7D-GENID-1-10-1-11-1-1-6-1-4-1-3-1-3-1"><title>Key Concepts and Terms
      Sensor Channel
      @@ -56,7 +56,7 @@

    -
    Description

    The +

    Description

    The sensor server provides a plug-in interface (Sensor Definitions APIs) that enables platform developers to create sensor plug-ins for required sensors hardware. The sensor plug-ins enable the interaction between a client application @@ -71,7 +71,7 @@ of data from one sensor hardware to multiple clients simultaneously. It also resolves any contention between client applications for opening channels or configuring a sensor device.

    -
    APIs +
    APIs @@ -125,7 +125,7 @@
    - +

    A physical sensor can supply data to several sensor channels (CSensrvChannel) . A sensor channel provides data to an application in a channel-specific data format (for example, TSensrvXyzData) through a callback to the MSensrvDataListener::DataReceived() interface. A diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e36995_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e36995_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e37163_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e37163_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60154_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60154_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60297_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60297_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60783_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60783_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60926_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e60926_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e68958_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e68958_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e68982_href.png Binary file Symbian3/SDK/Source/GUID-8BA0D643-5ED1-4DC4-82EC-C8AA392DCBC4_d0e68982_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8C5A65E6-D753-472F-B885-FD0409589036.dita --- a/Symbian3/SDK/Source/GUID-8C5A65E6-D753-472F-B885-FD0409589036.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8C5A65E6-D753-472F-B885-FD0409589036.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ Class relationship between MHTTPDataOptimiser and RHTTPSession - +

    For more information about MHTTPTransactionCallback, see A simple HTTP Client diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8C8D6B06-E794-4269-B4DF-D2BE4DDB9E8B_d0e38310_href.png Binary file Symbian3/SDK/Source/GUID-8C8D6B06-E794-4269-B4DF-D2BE4DDB9E8B_d0e38310_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8C8D6B06-E794-4269-B4DF-D2BE4DDB9E8B_d0e38478_href.png Binary file Symbian3/SDK/Source/GUID-8C8D6B06-E794-4269-B4DF-D2BE4DDB9E8B_d0e38478_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e51707_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e51707_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e51850_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e51850_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e57411_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e57411_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e57554_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e57554_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e68938_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e68938_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e68962_href.png Binary file Symbian3/SDK/Source/GUID-8CCA308A-5302-4D95-8E60-DA75D8B6DC41_d0e68962_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CF0C00C-0FDF-517E-96FB-84F718237F61_d0e252803_href.jpg Binary file Symbian3/SDK/Source/GUID-8CF0C00C-0FDF-517E-96FB-84F718237F61_d0e252803_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8CF0C00C-0FDF-517E-96FB-84F718237F61_d0e257722_href.jpg Binary file Symbian3/SDK/Source/GUID-8CF0C00C-0FDF-517E-96FB-84F718237F61_d0e257722_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D046AD9-1D28-52AE-8B69-2CBF6441F733_d0e190606_href.png Binary file Symbian3/SDK/Source/GUID-8D046AD9-1D28-52AE-8B69-2CBF6441F733_d0e190606_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D046AD9-1D28-52AE-8B69-2CBF6441F733_d0e195577_href.png Binary file Symbian3/SDK/Source/GUID-8D046AD9-1D28-52AE-8B69-2CBF6441F733_d0e195577_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D4AD37E-6B96-5B82-8313-F88D97531DEC.dita --- a/Symbian3/SDK/Source/GUID-8D4AD37E-6B96-5B82-8313-F88D97531DEC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8D4AD37E-6B96-5B82-8313-F88D97531DEC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,8 +9,7 @@ --> -Types -of packageDescribes the three types of package descriptors. +Types of packageDescribes the three types of package descriptors.

    Three types of package are available:

    • a packaged modifiable @@ -20,36 +19,37 @@

    • a packaged modifiable pointer descriptor

    -
    Packaged modifiable buffer descriptor

    This is an -object of type TPckgBuf and is a modifiable buffer descriptor. -The class is templated; the template parameter defines the type of object -that this descriptor can contain.

    For example, a package descriptor -of type TPckgBuf<TExample> is a modifiable buffer descriptor -that only contains objects of type TExample.

    The package -class also allows functions to be called on the contained class.

    - +
    Packaged +modifiable buffer descriptor

    This is an object of type TPckgBuf and is a modifiable buffer descriptor. The class +is templated; the template parameter defines the type of object that +this descriptor can contain.

    For example, a package descriptor +of type TPckgBuf<TExample> is a modifiable buffer +descriptor that only contains objects of type TExample.

    The package class also allows functions to be called on +the contained class.

    +
    -
    Packaged non-modifiable pointer descriptor

    This -is an object of type TPckgC and is a non-modifiable pointer -descriptor. The class is templated; the template parameter defines the type -of object that this descriptor can represent.

    For example, a package -descriptor of type TPckgC<TExample> is a non- modifiable -pointer descriptor that only represents objects of type TExample.

    The -package class also allows functions to be called on the contained class.

    - +
    Packaged +non-modifiable pointer descriptor

    This is an object of +type TPckgC and is a non-modifiable pointer descriptor. +The class is templated; the template parameter defines the type of +object that this descriptor can represent.

    For example, a package +descriptor of type TPckgC<TExample> is a non- +modifiable pointer descriptor that only represents objects of type TExample.

    The package class also allows functions +to be called on the contained class.

    +
    -
    Packaged modifiable pointer descriptor

    This is -an object of type TPckg and is a modifiable pointer descriptor. -The class is templated; the template parameter defines the type of object -that this descriptor can represent.

    For example, a package descriptor -of type TPckg<TExample> is a modifiable pointer descriptor -that only represents objects of type TExample.

    The -package class also allows functions to be called on the contained class.

    - +
    Packaged +modifiable pointer descriptor

    This is an object of type TPckg and is a modifiable pointer descriptor. The class +is templated; the template parameter defines the type of object that +this descriptor can represent.

    For example, a package descriptor +of type TPckg<TExample> is a modifiable pointer +descriptor that only represents objects of type TExample.

    The package class also allows functions to be called on +the contained class.

    +
    -
    See also

    TBuf

    TPtrC

    TPtr

    +
    See +also

    TBuf

    TPtrC

    TPtr

    - -Descriptor concepts - + +Descriptor concepts \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D51B706-6941-5043-B435-1CAFBAE5A8F2_d0e396870_href.jpg Binary file Symbian3/SDK/Source/GUID-8D51B706-6941-5043-B435-1CAFBAE5A8F2_d0e396870_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D51B706-6941-5043-B435-1CAFBAE5A8F2_d0e400665_href.jpg Binary file Symbian3/SDK/Source/GUID-8D51B706-6941-5043-B435-1CAFBAE5A8F2_d0e400665_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D5FFAE9-7E8A-5144-B0CC-B56A34D42A3F_d0e220696_href.png Binary file Symbian3/SDK/Source/GUID-8D5FFAE9-7E8A-5144-B0CC-B56A34D42A3F_d0e220696_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D5FFAE9-7E8A-5144-B0CC-B56A34D42A3F_d0e225690_href.png Binary file Symbian3/SDK/Source/GUID-8D5FFAE9-7E8A-5144-B0CC-B56A34D42A3F_d0e225690_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D7AEB5A-9A88-5B6D-B6B0-7126A56AA495.dita --- a/Symbian3/SDK/Source/GUID-8D7AEB5A-9A88-5B6D-B6B0-7126A56AA495.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8D7AEB5A-9A88-5B6D-B6B0-7126A56AA495.dita Tue Jul 20 12:00:49 2010 +0100 @@ -128,7 +128,7 @@ with other App-Services components. The diagram below gives an abstract illustration of the internal dependencies of the Versit components themselves.

    Abstraction of Versit deliverables - +

    As the diagram above illustrates, it is possible to make use of the Versit.dll library on its own. If vCard or vCalendar support is required then the Versit library must be included as both vCard.dll and vCal.dll depend @@ -144,7 +144,7 @@

    API summary Relationship between different classes of the Versit component - + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D9FE811-3F8A-5C2A-B76A-5C0248179590_d0e336582_href.jpg Binary file Symbian3/SDK/Source/GUID-8D9FE811-3F8A-5C2A-B76A-5C0248179590_d0e336582_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8D9FE811-3F8A-5C2A-B76A-5C0248179590_d0e343048_href.jpg Binary file Symbian3/SDK/Source/GUID-8D9FE811-3F8A-5C2A-B76A-5C0248179590_d0e343048_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita --- a/Symbian3/SDK/Source/GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ calculates the bounding rectangles of the "Hello!" text and the red line (B). For each one, the application passes the rectangle to RWindow::BeginRedraw(const TRect &), then calls the draw commands and afterwards calls RWindow::EndRedraw().

    - +

    This has the advantage that the Window Server knows that the area of the window that has the "Hello!" text is not affected by the drawing of the red line. There are also advantages when some @@ -41,7 +41,7 @@ application must then perform a full window redraw, as shown in the next diagram.

    Non-redraw drawing sequence - +

    This is less efficient than the Window Server replaying the draw operations for the affected area.

    Symbian recommends that all drawing is now performed as redraw drawing. Typically this @@ -49,7 +49,7 @@ different aspects of the user interface—for example, as shown in the following diagram. If anything spoils the screen, the Window Server then only needs to redraw the corresponding portions of the user interface.

    - +

    In earlier versions of Symbian, before the introduction of the CCoeControl::DrawNow(const TRect &)const overload, developers sometimes used non-redraw drawing to update a small part of a control. This technique has often been used for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8DB5E558-9774-5CC3-AF8C-6C50D9FE0496.dita --- a/Symbian3/SDK/Source/GUID-8DB5E558-9774-5CC3-AF8C-6C50D9FE0496.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,64 +0,0 @@ - - - - - -How -to use makmake -

    Symbian projects are defined by an .mmp file which -specifies the essential elements of the project. The makmake tool -then uses this environment-neutral file to build makefiles for use in various -environments. These makefiles are then used for project development.

    -

    Some makefiles are built for use in building the project from the command-line, -while others are for use with an IDE. Command-line makefiles created by makmake contain -syntax which it is not possible to incorporate into makefiles intended for -an IDE: these are discussed below.

    -
    Building and running a project for WINSCW

    Starting -with hello.mmp, you can build the makefile file hello.winscw using:

    makmake -hello winscw

    You then build the project from the command -line by running:

    make -f hello.winscw

    -
    Building debug and release variants

    A command line -makefile produced by makmake allows the executable (an -EXE or any type of DLL) to be produced in one of two -variants:

      -

    • udeb: -debug mode

      • -

    • urel: -release mode

      • -

    which may be selected by specifying the variant as a target.

    For -example, to build the udeb variant of the executable, -you can do:

    make -f hello.armi udeb

    If make /nmake is -invoked with no target specified, then the following default targets will -be built: the default for ARM is release mode; the default for WINSCW, and -WINC is debug mode.

    You may use path specifications to locate the .mmp file -in any directory.

    For example:

    makmake ..\..epoc32ex\e32\hello -armv5

    or

    makmake ..\..epoc32ex\e32\hello -cw_ide

    will locate the specified .mmp file. -However, the generated makmake files are always written -into the current directory.

    -
    Command line makefile utilities

    Command-line makefiles -provide extra makefile targets which enable you to use make or nmake to -create work directories and erase non-source files for a particular build -variant of a project.

    For example,

      -

    • make --f hello.winscw clean attempts to delete the non-source files -created during a build of all variants of the project hello

      • -

    • make --f hello.winscw makework will create the work directories for -a build of all variants of the project hello, while nmake - -f hello.wins makeworkurel will create the work directories -for a wide release build of the project.

      • -

    The build-specific makework targets are listed as -dependencies of the main build-specific targets in command-line makefiles, -so work directories will automatically be created when a target is built with -a command-line makefile if these directories do not already exist.

    - -mmp file -syntax - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E158109-AE22-5216-90E8-63A4BD4CC90B.dita --- a/Symbian3/SDK/Source/GUID-8E158109-AE22-5216-90E8-63A4BD4CC90B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8E158109-AE22-5216-90E8-63A4BD4CC90B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -66,7 +66,7 @@ operations

  • Call Close to end the sub-session

    • -

    Example 1: Socket (RSocket)

    RSocketServ ss; +

    Example 1: Socket (RSocket)

    RSocketServ ss; RSocket sock; // Connect to the Sockets Server @@ -80,7 +80,7 @@ // Close the socket connection sock.Close(); -

    Example 2: Connection Management +

    Example 2: Connection Management (RConnection)

    RSocketServ ss; RConnection conn; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E2303E9-DB60-5F38-A4D4-8BF8F7A1EF9F_d0e304490_href.jpg Binary file Symbian3/SDK/Source/GUID-8E2303E9-DB60-5F38-A4D4-8BF8F7A1EF9F_d0e304490_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E2303E9-DB60-5F38-A4D4-8BF8F7A1EF9F_d0e310962_href.jpg Binary file Symbian3/SDK/Source/GUID-8E2303E9-DB60-5F38-A4D4-8BF8F7A1EF9F_d0e310962_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E322085-07E7-542C-B0FD-54431F7B4BB7_d0e272075_href.jpg Binary file Symbian3/SDK/Source/GUID-8E322085-07E7-542C-B0FD-54431F7B4BB7_d0e272075_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E322085-07E7-542C-B0FD-54431F7B4BB7_d0e276921_href.jpg Binary file Symbian3/SDK/Source/GUID-8E322085-07E7-542C-B0FD-54431F7B4BB7_d0e276921_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e393399_href.png Binary file Symbian3/SDK/Source/GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e393399_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e397194_href.png Binary file Symbian3/SDK/Source/GUID-8E3F3745-7875-51A2-BDA1-AA537C7B220E_d0e397194_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E6FD3FD-64C8-51E0-AFE7-76DC5AB6A254_d0e110556_href.png Binary file Symbian3/SDK/Source/GUID-8E6FD3FD-64C8-51E0-AFE7-76DC5AB6A254_d0e110556_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E6FD3FD-64C8-51E0-AFE7-76DC5AB6A254_d0e110788_href.png Binary file Symbian3/SDK/Source/GUID-8E6FD3FD-64C8-51E0-AFE7-76DC5AB6A254_d0e110788_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E759F53-8DA7-5AA3-B004-7D989CCF8755_d0e123728_href.jpg Binary file Symbian3/SDK/Source/GUID-8E759F53-8DA7-5AA3-B004-7D989CCF8755_d0e123728_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E759F53-8DA7-5AA3-B004-7D989CCF8755_d0e127348_href.jpg Binary file Symbian3/SDK/Source/GUID-8E759F53-8DA7-5AA3-B004-7D989CCF8755_d0e127348_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E794D5A-9C83-54EB-AD5A-6A74BB155223.dita --- a/Symbian3/SDK/Source/GUID-8E794D5A-9C83-54EB-AD5A-6A74BB155223.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8E794D5A-9C83-54EB-AD5A-6A74BB155223.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ JPEG Image Transform Extension Guide

    This document introduces you to the JPEG image transform extensions.

    -
    Purpose

    The +

    Purpose

    The Image Transform framework supports standard extensions for advanced JPEG functions.

    The functions are,

    • Orientation (Rotation and Mirror over horizontal and vertical Axis)

      • @@ -78,7 +78,7 @@ of the use of COverlayTransformExtension include adding timestamp or place-stamp, some text or inserting a company logo. The images below show an example of overlay functionality:

      - +

      The image overlay transformation can, depending on its implementation, be very fast eliminating the need to decode the whole image making it very useful, for example a camera application. The types of image that can be overlaid diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E7CCFD7-F820-596E-BACB-AE43878C6CD8.dita --- a/Symbian3/SDK/Source/GUID-8E7CCFD7-F820-596E-BACB-AE43878C6CD8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -final

      This command allows extension makefiles to be used to carry out any commands required to complete the build.

      abld [ test ] final [-k] [-v] [ platform ] [ build [ program ] ]

      The command has no effect for makefiles generated by makmake. It is provided only for extension makefiles.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E8F1999-4DE0-5CA0-9656-C54127FDB3D4_d0e337751_href.png Binary file Symbian3/SDK/Source/GUID-8E8F1999-4DE0-5CA0-9656-C54127FDB3D4_d0e337751_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E8F1999-4DE0-5CA0-9656-C54127FDB3D4_d0e344217_href.png Binary file Symbian3/SDK/Source/GUID-8E8F1999-4DE0-5CA0-9656-C54127FDB3D4_d0e344217_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E907968-E6F8-5792-9B04-664971762FFF_d0e230483_href.png Binary file Symbian3/SDK/Source/GUID-8E907968-E6F8-5792-9B04-664971762FFF_d0e230483_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E907968-E6F8-5792-9B04-664971762FFF_d0e235463_href.png Binary file Symbian3/SDK/Source/GUID-8E907968-E6F8-5792-9B04-664971762FFF_d0e235463_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E995178-F3F2-4391-B99D-7A3451880F53_d0e52050_href.png Binary file Symbian3/SDK/Source/GUID-8E995178-F3F2-4391-B99D-7A3451880F53_d0e52050_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8E995178-F3F2-4391-B99D-7A3451880F53_d0e52193_href.png Binary file Symbian3/SDK/Source/GUID-8E995178-F3F2-4391-B99D-7A3451880F53_d0e52193_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8ECEF376-CB27-52FC-A9DD-933ACC24FDDC_d0e307907_href.png Binary file Symbian3/SDK/Source/GUID-8ECEF376-CB27-52FC-A9DD-933ACC24FDDC_d0e307907_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8ECEF376-CB27-52FC-A9DD-933ACC24FDDC_d0e314379_href.png Binary file Symbian3/SDK/Source/GUID-8ECEF376-CB27-52FC-A9DD-933ACC24FDDC_d0e314379_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8EE8E38C-7CA1-5F1B-86D0-1A0B03AAC5F2_d0e149865_href.png Binary file Symbian3/SDK/Source/GUID-8EE8E38C-7CA1-5F1B-86D0-1A0B03AAC5F2_d0e149865_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8EE8E38C-7CA1-5F1B-86D0-1A0B03AAC5F2_d0e154936_href.png Binary file Symbian3/SDK/Source/GUID-8EE8E38C-7CA1-5F1B-86D0-1A0B03AAC5F2_d0e154936_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8EF8CDD3-9FFE-5C39-8303-67A661C67F6B_d0e337871_href.jpg Binary file Symbian3/SDK/Source/GUID-8EF8CDD3-9FFE-5C39-8303-67A661C67F6B_d0e337871_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8EF8CDD3-9FFE-5C39-8303-67A661C67F6B_d0e344337_href.jpg Binary file Symbian3/SDK/Source/GUID-8EF8CDD3-9FFE-5C39-8303-67A661C67F6B_d0e344337_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F04D882-B846-4A0D-B858-15FDA85758FA.dita --- a/Symbian3/SDK/Source/GUID-8F04D882-B846-4A0D-B858-15FDA85758FA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8F04D882-B846-4A0D-B858-15FDA85758FA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,7 +10,7 @@ Displaying -commands in a stylus pop-up menu +commands in a context menu

      To use a stylus pop-up menu in your application, implement the following use cases:

        @@ -36,8 +36,8 @@

      • Hiding and showing stylus pop-up menu items

      -
      Implementation -file

      The implementation file for the Stylus pop-up menu API is aknstyluspopupmenu.h.

      +
      Implementation file

      The implementation file for +the Stylus pop-up menu API is aknstyluspopupmenu.h.

       Stylus pop-up menu API description diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F1567B4-6957-5B93-9499-35489AD610F5.dita --- a/Symbian3/SDK/Source/GUID-8F1567B4-6957-5B93-9499-35489AD610F5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8F1567B4-6957-5B93-9499-35489AD610F5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -50,7 +50,7 @@ at the chunk's base address and a size that is a multiple of the MMU page size. The following diagram is an example of this kind of chunk:

      Normal chunks - +

      Double-ended chunks

      These chunks have a committed region consisting of a single contiguous range starting at arbitrary lower and upper endpoints within the reserved region. The only @@ -58,14 +58,14 @@ MMU page size. Both the bottom and top of the committed region can be altered dynamically. The following diagram shows an example of this kind of chunk:

      Double-ended chunks - +

      Disconnected chunks

      These chunks have a committed region consisting of an arbitrary set of MMU pages within the reserved region. Each page-sized address range within the reserved region starting on a page boundary can be committed independently. The following diagram shows an example of this kind of chunk:

      Disconnected chunks - +
    Shared chunks

    A shared chunk is a mechanism that allows kernel-side code to share memory buffers diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F19C257-9A41-5D38-BC8A-285D0EB16E1B_d0e402513_href.png Binary file Symbian3/SDK/Source/GUID-8F19C257-9A41-5D38-BC8A-285D0EB16E1B_d0e402513_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F19C257-9A41-5D38-BC8A-285D0EB16E1B_d0e406313_href.png Binary file Symbian3/SDK/Source/GUID-8F19C257-9A41-5D38-BC8A-285D0EB16E1B_d0e406313_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F29E5C9-0EEA-569C-ADB2-82FD61D87378_d0e323093_href.jpg Binary file Symbian3/SDK/Source/GUID-8F29E5C9-0EEA-569C-ADB2-82FD61D87378_d0e323093_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F29E5C9-0EEA-569C-ADB2-82FD61D87378_d0e329563_href.jpg Binary file Symbian3/SDK/Source/GUID-8F29E5C9-0EEA-569C-ADB2-82FD61D87378_d0e329563_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F4C626F-3490-50BC-A97F-FD1972FFF65B_d0e193631_href.png Binary file Symbian3/SDK/Source/GUID-8F4C626F-3490-50BC-A97F-FD1972FFF65B_d0e193631_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F4C626F-3490-50BC-A97F-FD1972FFF65B_d0e198639_href.png Binary file Symbian3/SDK/Source/GUID-8F4C626F-3490-50BC-A97F-FD1972FFF65B_d0e198639_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F6F6C2C-C00E-4412-A880-5EEBF7270265.dita --- a/Symbian3/SDK/Source/GUID-8F6F6C2C-C00E-4412-A880-5EEBF7270265.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8F6F6C2C-C00E-4412-A880-5EEBF7270265.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@

    The generic button can have properties such as ON/OFF button, Mode toggle button and Command button. For more details, see Toolbar:

    - +

    Buttons can have the following states:

    • Unavailable / dimmed when button function is not available

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8F8E3814-7ED6-4218-BEEF-741AE0E9366F.dita --- a/Symbian3/SDK/Source/GUID-8F8E3814-7ED6-4218-BEEF-741AE0E9366F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-8F8E3814-7ED6-4218-BEEF-741AE0E9366F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Changing the PriorityThis section describes how an application (internal or third-party) can change its priority by using OOM Monitor APIs. -

      An application +

      An application which is processing a task in the background can change its priority at runtime to protect itself from being closed by the OOM Monitor. For example:

      • Music Player playing music in the background

        • @@ -23,15 +23,15 @@ itself to be Busy using ROomMonitorSession::SetOomPriority(EOomPriorityBusy) method. When the application finishes its background job and becomes idle, it should change its priority to Normal.

        - -Create an OOM Monitor + +Create an OOM Monitor session ROomMonitorSession ioomMonitorSession; CleanUpClosePushL(ioomMonitorSession); User::LeaveIfError(ioomMonitorSession.Connect()); -Set the priority +Set the priority for the application to Busy before performing the background task iOomMonitorSession.SetOomPriority(ROomMonitorSession::EOomPriorityBusy); @@ -43,7 +43,7 @@ iOomMonitorSession.SetOomPriority(ROomMonitorSession::EOomPriorityNormal); -Close the session. +Close the session. iOomMonitorSession.Close(); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-8FF4D117-920A-5AFA-ABB3-C0101EE2B7AA.dita --- a/Symbian3/SDK/Source/GUID-8FF4D117-920A-5AFA-ABB3-C0101EE2B7AA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --no_debug

        This option does not generate symbolic debug information for release or debug builds.

        The option instructs the makmake tool to not generate the symbolic debug information for UREL or UDEB variants. It supports only ARM ABI compliant platforms.

        Note that the option is applicable to the build and makefile commands only.

        Also note that this option cannot be used with the -debug option.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90076A13-E062-5A7B-BB0F-168F7C8A96DD_d0e76235_href.png Binary file Symbian3/SDK/Source/GUID-90076A13-E062-5A7B-BB0F-168F7C8A96DD_d0e76235_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90076A13-E062-5A7B-BB0F-168F7C8A96DD_d0e76273_href.png Binary file Symbian3/SDK/Source/GUID-90076A13-E062-5A7B-BB0F-168F7C8A96DD_d0e76273_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9022E900-2BDD-5B64-9802-4EBA5BFEB4B2_d0e110872_href.png Binary file Symbian3/SDK/Source/GUID-9022E900-2BDD-5B64-9802-4EBA5BFEB4B2_d0e110872_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9022E900-2BDD-5B64-9802-4EBA5BFEB4B2_d0e111104_href.png Binary file Symbian3/SDK/Source/GUID-9022E900-2BDD-5B64-9802-4EBA5BFEB4B2_d0e111104_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9045FC43-162E-52B8-ABE2-5EC1EC88BD99_d0e196262_href.png Binary file Symbian3/SDK/Source/GUID-9045FC43-162E-52B8-ABE2-5EC1EC88BD99_d0e196262_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9045FC43-162E-52B8-ABE2-5EC1EC88BD99_d0e201271_href.png Binary file Symbian3/SDK/Source/GUID-9045FC43-162E-52B8-ABE2-5EC1EC88BD99_d0e201271_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90644B52-69D7-595C-95E3-D6F7A30C060D.dita --- a/Symbian3/SDK/Source/GUID-90644B52-69D7-595C-95E3-D6F7A30C060D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-90644B52-69D7-595C-95E3-D6F7A30C060D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -118,7 +118,7 @@ Figure 1: Handwriting simulation might use different glyphs for the letter p depending on its position in a word - +

        Contextual shaping is an essential feature of some scripts, including Arabic and many Indian and East Asian scripts, such as Devanagari, Kannada, Telugu, Tamil, Bengali, Malayalam and Gurmukhi. For this reason, support for @@ -144,7 +144,7 @@ Figure 2: The Graphics Device and Context Architecture.

        Note that the names of the BitGDI classes begin with CFbs.

        - +

        Applications access font services through the Font and Bitmap Server (FBSERV) which caches font bitmaps in a shared heap. The Font and Bitmap Server ensures that there is only ever a single instance diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90B593E2-F38B-5B38-9367-E2BF344A2834_d0e413239_href.png Binary file Symbian3/SDK/Source/GUID-90B593E2-F38B-5B38-9367-E2BF344A2834_d0e413239_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90B593E2-F38B-5B38-9367-E2BF344A2834_d0e417039_href.png Binary file Symbian3/SDK/Source/GUID-90B593E2-F38B-5B38-9367-E2BF344A2834_d0e417039_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-90DF40EF-7D3F-551D-9957-A3756317A254.dita --- a/Symbian3/SDK/Source/GUID-90DF40EF-7D3F-551D-9957-A3756317A254.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-90DF40EF-7D3F-551D-9957-A3756317A254.dita Tue Jul 20 12:00:49 2010 +0100 @@ -59,7 +59,7 @@ (in this case, the OCSP server), which replies with a single response. The following figure illustrates the interaction between the OCSP client and a single destination responder.

        - +

      • Multiple OCSP responders using an intermediate OCSP server

        Multiple OCSP responders use @@ -69,14 +69,14 @@ and one response is sent back to the client. The following figure shows the interaction between an OCSP client and multiple destination responders by using an intermediate responder.

        - +

      • Multiple OCSP responders without an intermediate server

        The client does the work of sending each request to the appropriate responder. The client collates the responses received. The following figure shows the interaction between the client and multiple destination responders.

        - +

      The choice of the correct method of interaction between the client and the responders depends on the nature of the Public Key Infrastructure diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-91224821-8094-59ED-A100-4174193A25EE_d0e264846_href.png Binary file Symbian3/SDK/Source/GUID-91224821-8094-59ED-A100-4174193A25EE_d0e264846_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-91224821-8094-59ED-A100-4174193A25EE_d0e269709_href.png Binary file Symbian3/SDK/Source/GUID-91224821-8094-59ED-A100-4174193A25EE_d0e269709_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9126A296-0301-4077-A183-3D703F77C548.dita --- a/Symbian3/SDK/Source/GUID-9126A296-0301-4077-A183-3D703F77C548.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9126A296-0301-4077-A183-3D703F77C548.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,113 +1,91 @@ - - - - -Support for Multiple Pointers in the Emulator Overview -This topic provides an overview of support for multiple -pointers in the emulator. Two mice are used to provide two independent -pointer positions. The emulator responds to the mice’s individual -button-clicks, moves, and mouse wheel scrolls as if two human fingers -are moving, touching or hovering over the screen. - - - - -

      The emulator can be extended to support more than two mice or other -pointer devices.

      -

      Variant: ScreenPlay. Target audience: Application developers.

      -

      The following figure shows two Windows pointers on the emulator -screen, each representing a mouse device. The ordinal integer (starting -from 0) beside each pointer is the unique device identifier. The position -of each mouse on the screen is represented by the X and Y coordinates. -The pressure (a positive value) and proximity (a negative value) information -captured by the mouse wheel is represented by the Z coordinate. Notice -that the status bar shows the identifier and the dynamic X, Y and -Z values of each pointer.

      - -Two pointers are displayed in the emulator - -

      The delivery of pointer events from the emulator driver to the -Window Server is the same when there are multiple pointers as in the -single pointer environment. This means the raw events for a mouse -move, button click and mouse wheel movement are delivered to the Window -Server as usual. Each mouse has a unique device identifier, which -makes it possible to ascertain which mouse the events relate to. The -raw events for each individual mouse include the following:

      -
        -

      • TRawEvent::EPointerMove indicates a mouse -move or a mouse wheel movement event.

        • -

      • TRawEvent::EButton1Down indicates that the -left mouse button is pressed down.

        • -

      • TRawEvent::EButton1Up indicates that the left -mouse button is released.

        • -

      • TRawEvent::EPointerOutOfRange indicates that -the proximity of a mouse is out of range. This means that the Z coordinate -value of the mouse has reached HALData::EPointer3DMaxProximity.

        • -
      -
      Pressure and proximity emulation

      The Z coordinate -value is used to represent the pressure and proximity to the screen. -In the emulator, the Z value is captured and tuned by the mouse wheel -movement.

        -

      • Z < 0 indicates the proximity of the device from the screen.

        • -

      • Z > 0 indicates pressure.

        • -

      See Advanced Pointer Overview for more information about pressure -and proximity.

      The mouse wheel combines the features of a wheel -and a mouse button. The wheel has discrete, evenly spaced notches. -Rotating the wheel backwards or forwards has the effect of changing -the pressure or proximity.

        -

      • When the mouse wheel is rotated, a device-specific message -is sent to the emulator window that has focus as each notch is encountered.

        • -

      • The Z coordinate is initiated as 0. Then when the wheel is -moved forward, the Z value enters the pressure range and increases -by one pressure step. When the wheel is moved backward, the Z value -enters the proximity range and decreases by one proximity step.

        The pressure or proximity step can be customized in the epoc.ini file. See Enabling Multiple -Pointers in the Emulator Tutorial for more information.

        • -

      • When the Z value is in the pressure range (Z > 0), moving the -wheel forward by one notch increases Z by one pressure step. Moving -the wheel backward by one notch decreases Z by one pressure step, -until Z returns to 0.

        • -

      • When the Z value is in the proximity range (Z < 0), moving -the wheel backward by one notch decreases Z by one proximity step. -Moving the wheel forward by one notch increases Z by one proximity -step, until Z returns to 0.

        • -

      • There are limits to the values of the Z coordinate. This means -that the Symbian emulator does not allow Z to exceed the upper boundary HALData::EPointer3DMaxPressure (a positive -value) and lower boundary HALData::EPointer3DMaxProximity (a negative -value). If Z is at the lower boundary, when the mouse wheel is moved -backward next time, Z does not change. A new Out of Range pointer event is generated and sent to the Window Server. Similarly -when Z is at the upper boundary, Z does not change when the mouse -wheel is moved forward.

        • -

      • When the mouse button down or up event (TRawEvent::EButton1Down or TRawEvent::EButton1Up) is generated, Z is reset -to 0.

        • -
      - - -Advanced Pointers -Enabling Multiple Pointers in the Emulator Tutorial - - - - + + + + + +Support for Multiple Pointers in the Emulator OverviewThis topic provides an overview of support for multiple +pointers in the emulator. Two mice are used to provide two independent +pointer positions. The emulator responds to the mice’s individual +button-clicks, moves, and mouse wheel scrolls as if two human fingers +are moving, touching or hovering over the screen. +

      The emulator can be extended to support more than two mice or other +pointer devices.

      +

      Variant: ScreenPlay. Target audience: Application developers.

      +

      The following figure shows two Windows pointers on the emulator +screen, each representing a mouse device. The ordinal integer (starting +from 0) beside each pointer is the unique device identifier. The position +of each mouse on the screen is represented by the X and Y coordinates. +The pressure (a positive value) and proximity (a negative value) information +captured by the mouse wheel is represented by the Z coordinate. Notice +that the status bar shows the identifier and the dynamic X, Y and +Z values of each pointer.

      + +Two pointers are displayed in the emulator + + +

      The delivery of pointer events from the emulator driver to the +Window Server is the same when there are multiple pointers as in the +single pointer environment. This means the raw events for a mouse +move, button click and mouse wheel movement are delivered to the Window +Server as usual. Each mouse has a unique device identifier, which +makes it possible to ascertain which mouse the events relate to. The +raw events for each individual mouse include the following:

      +
        +

      • TRawEvent::EPointerMove indicates a mouse +move or a mouse wheel movement event.

        • +

      • TRawEvent::EButton1Down indicates that the +left mouse button is pressed down.

        • +

      • TRawEvent::EButton1Up indicates that the left +mouse button is released.

        • +

      • TRawEvent::EPointerOutOfRange indicates that +the proximity of a mouse is out of range. This means that the Z coordinate +value of the mouse has reached HALData::EPointer3DMaxProximity.

        • +
      +
      Pressure and proximity emulation

      The Z coordinate value +is used to represent the pressure and proximity to the screen. In +the emulator, the Z value is captured and tuned by the mouse wheel +movement.

        +

      • Z < 0 indicates the proximity of the device from the screen.

        • +

      • Z > 0 indicates pressure.

        • +

      See Advanced Pointer Overview for more information about pressure +and proximity.

      The mouse wheel combines the features of a wheel +and a mouse button. The wheel has discrete, evenly spaced notches. +Rotating the wheel backwards or forwards has the effect of changing +the pressure or proximity.

        +

      • When the mouse wheel is rotated, a device-specific message +is sent to the emulator window that has focus as each notch is encountered.

        • +

      • The Z coordinate is initiated as 0. Then when the wheel is +moved forward, the Z value enters the pressure range and increases +by one pressure step. When the wheel is moved backward, the Z value +enters the proximity range and decreases by one proximity step.

        The pressure or proximity step can be customized in the epoc.ini file. See Enabling Multiple +Pointers in the Emulator Tutorial for more information.

        • +

      • When the Z value is in the pressure range (Z > 0), moving the +wheel forward by one notch increases Z by one pressure step. Moving +the wheel backward by one notch decreases Z by one pressure step, +until Z returns to 0.

        • +

      • When the Z value is in the proximity range (Z < 0), moving +the wheel backward by one notch decreases Z by one proximity step. +Moving the wheel forward by one notch increases Z by one proximity +step, until Z returns to 0.

        • +

      • There are limits to the values of the Z coordinate. This means +that the Symbian emulator does not allow Z to exceed the upper boundary HALData::EPointer3DMaxPressure (a positive value) and lower +boundary HALData::EPointer3DMaxProximity (a negative +value). If Z is at the lower boundary, when the mouse wheel is moved +backward next time, Z does not change. A new Out of Range pointer event is generated and sent to the Window Server. Similarly +when Z is at the upper boundary, Z does not change when the mouse +wheel is moved forward.

        • +

      • When the mouse button down or up event (TRawEvent::EButton1Down or TRawEvent::EButton1Up) is generated, Z is reset +to 0.

        • +
      +       +Advanced +Pointers +Enabling +Multiple Pointers in the Emulator Tutorial +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-914DD950-4332-5F23-B725-F4D330DB19EB.dita --- a/Symbian3/SDK/Source/GUID-914DD950-4332-5F23-B725-F4D330DB19EB.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,34 +0,0 @@ - - - - - -UID2 -and UID3 statements -<uid2-statement> -uid2-statement ::= -UID2 <uid-value> <uid3-statement> -uid3-statement ::= -UID3 <uid-value> -

      Defines the second (UID2) and third (UID3) -UIDs for the resource file. The uid-value is a UID number -(or macro representing such a number).

      -

      At the start of a resource file, a UID triplet is stored. The first UID -of a resource file is always 0x101f4a6b. By default, the -second UID is zero and the third UID is the resource file’s “offset”, i.e. -the twenty-bit integer generated from the resource file’s name. The defaults -can be overriden using these statements (or from a START RESOURCE statement -in an mmp file).

      -

      Some clients of resource files read the UID values (see RResourceFile::UidType()) -to test that a resource file is of a suitable type. In many other cases, the -reader of the resource file does not use the UID values, so there is no need -to use the UID2/UID3 statements.

      -UID2 KUidAppRegistrationResourceFile -UID3 0x10001234 -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-915A1B7D-10BB-5B4A-8C5E-99AD28375AD7.dita --- a/Symbian3/SDK/Source/GUID-915A1B7D-10BB-5B4A-8C5E-99AD28375AD7.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -ARMV7 build target

      The ARMV7 build target builds for the ARMV7 architecture that supports Thumb-2 instruction set. For details on ARMV7 architecture, refer to http://www.arm.com/products/CPUs/architecture.html. To build for ARMV7, ARM's RealView Compilation Tools (RVCT) v3.1 or later is required.

      Building binaries for ARMV7

      To build binaries for ARMV7 with abld, use:

      abld build ARMV7 [udeb | urel]

      Binaries are generated in the udeb and urel sub-directories of the epoc32\release\ARMV7\ directory for ABI v2.

      Note: Code is not built for ARMV7 target by default. It has to be explicitly specified on the command line or in the BLD.INF file using the prj_platforms statement.

      ARMV5 build - targets ARMV6 build targets GCCE build targets       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita --- a/Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9169062F-3B6D-544C-847C-BA859DAB33B9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -52,7 +52,7 @@ to the server.

      The following diagram illustrates this:

      - +

      Sending messages asynchronously to the server

      A server can support multiple connections from a client in a number of diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-917413FC-0AC0-5768-B5AD-36BD2EDCB1FF.dita --- a/Symbian3/SDK/Source/GUID-917413FC-0AC0-5768-B5AD-36BD2EDCB1FF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -How to build feature-based variants

      A feature-based variant defines features to which a DLL is sensitive. To build a DLL for a variant configuration of ARMV5, perform the steps outlined below:

      1. Add the FEATUREVARIANT keyword in the .mmp file to mark the DLL as a feature variant.

      2. Create a .var file containing the configuration for the variant. For variant file syntax, refer to variant configuration file syntax.

      3. Place the .var file in - /epoc32/tools/variant/ variant_name.var .

      4. Build the DLL for a variant using the abld command.

        For example:

        abld build armv5.myvar

      The DLL is built and placed in the /epoc32/release/armv5/urel folder.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-917790B7-A71D-511C-AFAB-BB46EFD046C6_d0e144644_href.jpg Binary file Symbian3/SDK/Source/GUID-917790B7-A71D-511C-AFAB-BB46EFD046C6_d0e144644_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-917790B7-A71D-511C-AFAB-BB46EFD046C6_d0e149734_href.jpg Binary file Symbian3/SDK/Source/GUID-917790B7-A71D-511C-AFAB-BB46EFD046C6_d0e149734_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-919E32B1-1316-4B09-B668-E744E78B0B6E.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-919E32B1-1316-4B09-B668-E744E78B0B6E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,411 @@ + + + + + +Supported +file types +

      This section describes the file types supported by the Media Fetch API +and the metadata system (MdS).

      +

      The Media Fetch API and the metadata +system support the following types of multimedia items:

      +
        +

      • Video files

        • +

      • Audio files

        • +

      • Image files

        • +

      • Streaming links

        • +

      • Playlist files

        • +
      +

      The following table describes the supported video files.

      +
    Supported video +files + + + +

    File extension

     +

    MIME type

     +

    Description

     +     +     + + +

    3g2

     +

    video/3gp

     +

    3GP is a multimedia container format that is defined by the Third +Generation Partnership Project (3GPP) for use on 3G mobile devices but that +can also be played on some 2G and 4G devices.

    The 3GPP2 standard is +defined for CDMA-based devices and has the file extension 3g2.

     +     + +

    3gp

     +

    video/3gp

     +

    The 3GPP standard is defined for GSM-based devices and has the file +extension 3gp.

     +     + +

    avi

     +

    video/avi

     +

    Audio video interleave (AVI) is a multimedia container format introduced +by Microsoft as part of its Video for Windows technology. AVI files can contain +both audio and video data in a file container that allows synchronous audio-with-video +playback.

     +     + +

    flv

     +

    video/x-flv

     +

    Flash video is a file format used to deliver video over the Internet +using Adobe Flash Player. Flash video content may also be embedded within +SWF files.

     +     + +

    m4v

     +

    video/mp4

     +

    M4V is a standard file format for videos for iPod and PlayStation +Portable devices developed by Apple. It is based on the MPEG-4 Part 2 compression.

     +     + +

    mp4

     +

    video/mp4

     +

    MPEG-4 is a multimedia container format standard that is most commonly +used to store digital audio and digital video streams, especially those defined +by MPEG. It can also be used to store other data such as subtitles and still +images.

    MPEG-4 files with audio and video generally use the standard +mp4 extension.

     +     + +

    mpeg4

     +

    video/mp4

     +

    Another file name extension for MPEG-4 files.

     +     + +

    mpg4

     +

    video/mp4

     +

    Another file name extension for MPEG-4 files.

     +     + +

    ram

     +

    video/3gpp

     +

    RealAudio metadata (RAM) is typically a small text file that contains +a link to the audio stream.

     +     + +

    rm

     +

    application/vnd.rn-realmedia

     +

    RealMedia is a multimedia container format created by RealNetworks +that is typically used in conjunction with RealVideo and RealAudio for streaming +content over the Internet.

     +     + +

    rmvb

     +

    application/vnd.rn-realmedia-vbr

     +

    RealMedia variable bitrate (RMVB) is a container streaming content +over the Internet with variable bit rate.

     +     + +

    rtp

     +

    application/x-nokia-teh-rtp

     +

    + + +

    rv

     +

    video/vnd.rn-realvideo

     +

    RealVideo is a proprietary video format developed by RealNetworks +that is usually paired with RealAudio and packaged in a RealMedia (rm) container.

    +     +     + +
    +

    The following table describes the supported audio files.

    +Supported audio +files + + + +

    File extension

     +

    MIME type

     +

    Description

     +     + + + +

    3gp

     +

    audio/3gpp

     +

    The 3GPP standard is defined for GSM-based devices and has the file +extension 3gp.

     +     + +

    3gpp

     +

    audio/3gpp

     +

    Another file name extension for 3GPP files.

     +     + +

    aac

     +

    audio/aac

     +

    Advanced audio coding (AAC) is a standardized, compression and encoding +scheme for digital audio. Designed to be the successor of the MP3 format, +AAC generally achieves better sound quality than MP3 at many bit rates.

     +     + +

    amr

     +

    audio/amr

     +

    A file format for storing spoken audio using the adaptive multi-rate +(AMR) codec. AMR is a patented audio data compression scheme optimized for +speech coding.

     +     + +

    au

     +

    audio/au

     +

    A simple audio file format.

    +     + +

    awb

     +

    audio/amr-wb

     +

    Adaptive multi-rate – wide band (AMR-WB) is a patented speech coding +standard developed after the AMR that provides excellent speech quality due +to wider speech bandwidth.

     +     + +

    m4a

     +

    audio/mp4

     +

    Audio-only MPEG-4 files generally have an m4a extension. This is +especially true of non-protected content.

    +     + +

    mid

     +

    audio/midi

     +

    Musical instrument digital interface (MIDI) is an industry-standard +protocol that enables electronic musical instruments, such as keyboard controllers, +computers, and other electronic equipment, to communicate, control, and synchronize +with each other.

    +     + +

    midi

     +

    audio/midi

     +

    Another file name extension for MIDI files.

     +     + +

    mp3

     +

    audio/mpeg

     +

    MPEG-1 audio layer 3, more commonly referred to as MP3, is a patented +digital audio encoding format using a form of data compression. It is a common +audio format for consumer audio storage and widely used for digital audio +compression for the transfer and playback of music on digital audio players.

     +     + +

    mp4

     +

    audio/mp4

     +

    MPEG-4 files with audio and video generally use the standard mp4 +extension.

     +     + +

    mxmf

     +

    audio/vnd.nokia.mobile-xmf

     +

    The extensible music format (XMF) is a tree-based digital container +format used to bundle music-oriented content, such as a MIDI file and optionally +the sounds it uses, liner notes or other content grouped by language-codes.

    +     + +

    nrt

     +

    -

     +

    Nokia Ringing Tone.

     +     + +

    ra

     +

    audio/vnd.rn-realaudio

     +

    RealAudio is a proprietary audio format developed by RealNetworks. +It uses a variety of audio codecs, ranging from low-bitrate formats that can +be used over dialup modems, to high-fidelity formats for music.

     +     + +

    rng

     +

    application/vnd.nokia.ringing-tone

     +

    Nokia Ringing Tone.

     +     + +

    spmid

     +

    audio/sp-midi

     +

    Scalable polyphony MIDI (SP-MIDI) is a MIDI variant for mobile applications +where different players may have different numbers of musical voices. SP-MIDI +is a component of 3GPP.

     +     + +

    wav

     +

    audio/wav

     +

    Waveform audio format is a Microsoft and IBM audio file format standard +for storing an audio bit stream on computers.

     +     + +

    wma

     +

    audio/x-ms-wma

     +

    Windows Media Audio (WMA) is an audio data compression technology +developed by Microsoft as a part of the Windows Media framework.

     +     + + +
    +

    The following table describes the supported image files.

    +Supported image +files + + + +

    File extension

     +

    MIME type

     +

    Description

     +     + + + +

    bmp

     +

    image/bmp

     +

    An image file format used to store digital images.

     +     + +

    gif

     +

    image/gif

     +

    Graphics interchange format (GIF) is a bitmap image format that +provides good-quality color images that take up a small amount of space.

     +     + +

    j2k

     +

    image/jp2

     +

    JPEG 2000 is a wavelet-based image compression standard.

    Files +that contain JPEG 2000 code stream data for testing purposes might use the +filename extension j2k.

     +     + +

    jp2

     +

    image/jp2

     +

    Files that conform to the JPEG 2000 specification, ISO/IEC 15444-1, +use the standardized filename extension jp2.

     +     + +

    jpeg

     +

    image/jpeg

     +

    JPEG is a method for compressing photographic images.

     +     + +

    jpf

     +

    image/jp2

     +

    Another file name extension for JPEG 2000 files.

     +     + +

    jpg

     +

    image/jpeg

     +

    Another file name extension for JPEG files.

     +     + +

    jpx

     +

    image/jpx

     +

    Files that conform to the extended part-2 JPEG 2000 specification, +ISO/IEC 15444-2, use the filename extension jpx.

     +     + +

    mbm

     +

    image/x-epoc-mbm

     +

    A multi-bitmap is a container for a set of bitmap images. MBM files +can be used by Symbian applications to store graphical content.

     +     + +

    ota

     +

    image/vnd.nokia.ota-bitmap

     +

    Over-the-air (OTA) images.

     +     + +

    png

     +

    image/png

     +

    Portable networking graphics (PNG) is a bit map image format that +was designed for transferring images on the Internet.

     +     + +

    tif

     +

    image/tiff

     +

    Tagged image file format (TIFF) is a file format for storing images, +including photographs and line art.

     +     + +

    tiff

     +

    image/tiff

     +

    Another file name extension for TIFF files.

     +     + +

    wbmb

     +

    image/vnd.wap.wbmp

     +

    Wireless bitmap (WBMP) is a monochrome image file format that is +optimized for mobile devices.

    +     + +

    wmf

     +

    image/x-wmf

     +

    Windows metafile (WMF) is a graphics file format on Microsoft Windows +systems that is intended to be portable between applications and may contain +both vector and bitmap components.

     +     + + +
    +

    The following table describes the supported streaming links.

    +Supported streaming +links + + + +

    File extension

     +

    MIME type

     +

    Description

     +     + + + +

    asx

     +

    video/x-ms-asf

     +

    Advanced systems format (ASF) is a Microsoft proprietary digital +audio and digital video container format, especially meant for streaming media. +The most common file types contained within an ASF file are Windows media +audio (WMA) and Windows media video (WMV).

     +     + +

    sdp

     +

    application/sdp

     +

    Streaming Download Project Multimedia is a source project to allow +the download of streaming media.

     +     + +

    ram

     +

    audio/vnd.rn-realaudio

     +

    RealAudio metadata (RAM) is typically a small text file that contains +a link to the audio stream.

     +     + + +
    +

    The following table describes the supported playlist files.

    +Supported playlist +files + + + +

    File extension

     +

    MIME type

     +

    Description

     +     + + + +

    m3u

     +

    audio/x-mpegurl

     +

    Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator, +MP3 URL is a computer file format that stores multimedia playlists.

     +     + + +
    +
    See also

    Supported Image Formats Guide

    Video Renderer Resource File

    Querying for Parser Supported +Formats

    + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-92018B6B-3CBB-434D-9E61-F271C67E98E3.dita --- a/Symbian3/SDK/Source/GUID-92018B6B-3CBB-434D-9E61-F271C67E98E3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-92018B6B-3CBB-434D-9E61-F271C67E98E3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ holds the stylus down on the screen at the same point for a long time.

    Long-tap event used for opening a stylus pop-up menu - +

    The Touch UI utilities API can be used in all GUI applications. It is a library API that provides an interface for constructing and using the long-tap diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-92067BE3-40F0-4652-A882-FFDE2816C9BD_d0e71873_href.png Binary file Symbian3/SDK/Source/GUID-92067BE3-40F0-4652-A882-FFDE2816C9BD_d0e71873_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-92067BE3-40F0-4652-A882-FFDE2816C9BD_d0e71900_href.png Binary file Symbian3/SDK/Source/GUID-92067BE3-40F0-4652-A882-FFDE2816C9BD_d0e71900_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-924576EE-A016-4689-8B63-E8176063E1E6-master.png Binary file Symbian3/SDK/Source/GUID-924576EE-A016-4689-8B63-E8176063E1E6-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-924576EE-A016-4689-8B63-E8176063E1E6_d0e67660_href.png Binary file Symbian3/SDK/Source/GUID-924576EE-A016-4689-8B63-E8176063E1E6_d0e67660_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-924E26D6-8B9D-5C76-AF61-7C5514BB3D78_d0e215705_href.png Binary file Symbian3/SDK/Source/GUID-924E26D6-8B9D-5C76-AF61-7C5514BB3D78_d0e215705_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-924E26D6-8B9D-5C76-AF61-7C5514BB3D78_d0e220703_href.png Binary file Symbian3/SDK/Source/GUID-924E26D6-8B9D-5C76-AF61-7C5514BB3D78_d0e220703_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-92966ADC-17CF-5411-A829-1201C182B59F.dita --- a/Symbian3/SDK/Source/GUID-92966ADC-17CF-5411-A829-1201C182B59F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-92966ADC-17CF-5411-A829-1201C182B59F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -133,9 +133,8 @@ been read successfully.

    Building -and running

    The Symbian build -process describes how to build an application.

    The ETel3rdPartyExample builds the following executables in -the standard location (\epoc32\release\winscw\<build_variant> for CodeWarrior):

      +and running

      The Symbian build process describes how to +build an application.

      The ETel3rdPartyExample builds the following executables in the standard location (\epoc32\release\winscw\<build_variant> for CodeWarrior):

      • phoneid.exe

      • phonemonitor.exe

      • networkinformation.exe

        • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-92AD13DF-216A-4B5A-9C6D-5FA50BB0D692.dita --- a/Symbian3/SDK/Source/GUID-92AD13DF-216A-4B5A-9C6D-5FA50BB0D692.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-92AD13DF-216A-4B5A-9C6D-5FA50BB0D692.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ you to adjust the coordinate system to match the changed system characteristics.

        Example to illustrate adjustment of the coordinate system due to device orientation change - +

        To convert the sensor data to the compensated values, the adjustment values (for example, interchanged x-axis with y-axis) for each device state that the compensation is applied to, must be configured and taken as an input @@ -36,7 +36,7 @@ Correcting the coordinate system of a Symbian device The figure depicts the correction of coordinate system in the Symbian device - +

        The following example explains how the sensor data compensation works, by illustrating the behavior of maps application of the Symbian device when the keyboard is in opened and closed state.

        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-930F1E88-2A03-4BD1-AA2A-3A0128A844BD.dita --- a/Symbian3/SDK/Source/GUID-930F1E88-2A03-4BD1-AA2A-3A0128A844BD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-930F1E88-2A03-4BD1-AA2A-3A0128A844BD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,76 +1,59 @@ - - - - -Enabling Multiple Pointers in the Emulator Tutorial -This topic describes how to configure the Symbian emulator -to enable a multiple pointer environment. - - - - -

        Variant: ScreenPlay. Target audience: Application developers.

        -

        This topic builds on Support for -Multiple Pointers in the Emulator Overview.

        -
        Configuring the emulator

        Make sure that two or more mice -are plugged in and detected on the Windows PC on which the emulator -will run. The number of detected mice can be from two up to the maximum -number defined in the HAL HALData::EPointerMaxPointers attribute.

          -

        1. Add the following -lines to the \epoc32\data\epoc.ini file. These -lines enable ScreenPlay and multiple pointers.

          SYMBIAN_BASE_USE_GCE ON -EnableMultiTouch ON
          2. -

        2. Specify the MultiTouchProximityStep and MultiTouchPressureStep values in the \epoc32\data\epoc.ini file to -define the proximity and pressure steps.

          MultiTouchProximityStep 10 -MultiTouchPressureStep 200 -

          If the above two options are not defined in the epoc.ini file, the default proximity and pressure steps -are taken from the following HAL attributes.

          HALData::EPointer3DProximityStep -HALData::EPointer3DPressureStep
          3. -

        Result: Launch the emulator to verify that the mice -are detected and displayed inside the application window area. When -you move a mouse or scroll the mouse wheel, its X, Y and Z values -are reflected in the status bar.

        -
        Enabling and disabling multiple pointers

        Multiple pointers are only required by UI applications. Therefore, -multiple pointers are enabled inside the orange rectangular area shown -on the following diagram. Inside the area two Windows pointers are -displayed. The one numbered zero is the system pointer and the other -is used only for emulating touch with two fingers. The first mouse -to report events to the emulator is automatically taken as the primary -mouse, which owns the Windows system pointer.

        -Multiple pointer area -

        System pointer. Once the -system pointer moves outside the multiple pointer area, multiple pointers -are temporarily disabled and standard emulator pointer behavior is -resumed. This means that only one Windows system pointer is displayed -and it is controlled by both mice.

        Non-system pointer. If the non-system pointer moves out of the multiple pointer area, -the pointer just disappears from the screen. Disabling multiple pointers -is then not necessary because the system pointer behaves normally -inside the multiple pointer area. Moving the non-system pointer back -into the area makes it reappear on the screen.

        -         - -Support for Multiple Pointers in the Emulator Overview - - -         - + + + + + +Enabling Multiple Pointers in the Emulator TutorialThis topic describes how to configure the Symbian emulator +to enable a multiple pointer environment. +

        Variant: ScreenPlay. Target audience: Application developers.

        +

        This topic builds on Support for Multiple +Pointers in the Emulator Overview.

        +
        Configuring the emulator

        Make sure that two or more mice +are plugged in and detected on the Windows PC on which the emulator +will run. The number of detected mice can be from two up to the maximum +number defined in the HAL HALData::EPointerMaxPointers attribute.

          +

        1. Add the following +lines to the \epoc32\data\epoc.ini file. These +lines enable ScreenPlay and multiple pointers.

          SYMBIAN_BASE_USE_GCE ON +EnableMultiTouch ON
          2. +

        2. Specify the MultiTouchProximityStep and MultiTouchPressureStep values in the \epoc32\data\epoc.ini file to +define the proximity and pressure steps.

          MultiTouchProximityStep 10 +MultiTouchPressureStep 200 +

          If the above two options are not defined in the epoc.ini file, the default proximity and pressure steps +are taken from the following HAL attributes.

          HALData::EPointer3DProximityStep +HALData::EPointer3DPressureStep
          3. +

        Result: Launch the emulator to verify that the mice +are detected and displayed inside the application window area. When +you move a mouse or scroll the mouse wheel, its X, Y and Z values +are reflected in the status bar.

        +
        Enabling and disabling multiple pointers

        Multiple pointers +are only required by UI applications. Therefore, multiple pointers +are enabled inside the orange rectangular area shown on the following +diagram. Inside the area two Windows pointers are displayed. The one +numbered zero is the system pointer and the other is used only for +emulating touch with two fingers. The first mouse to report events +to the emulator is automatically taken as the primary mouse, which +owns the Windows system pointer.

        +Multiple pointer area + +

        System pointer. Once the system pointer moves outside +multiple pointer area, multiple pointers are temporarily disabled +and standard emulator pointer behavior is resumed. This means that +only one Windows system pointer is displayed and it is controlled +by both mice.

        Non-system pointer. If the non-system +pointer moves out of the multiple pointer area, the pointer just disappears +from the screen. Disabling multiple pointers is then not necessary +because the system pointer behaves normally inside the multiple pointer +area. Moving the non-system pointer back into the area makes it reappear +on the screen.

        +         +Support +for Multiple Pointers in the Emulator Overview + +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-935057C9-8FA9-5B41-A36C-03A825C51B32_d0e214529_href.png Binary file Symbian3/SDK/Source/GUID-935057C9-8FA9-5B41-A36C-03A825C51B32_d0e214529_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-935057C9-8FA9-5B41-A36C-03A825C51B32_d0e219527_href.png Binary file Symbian3/SDK/Source/GUID-935057C9-8FA9-5B41-A36C-03A825C51B32_d0e219527_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93678518-1FBD-521D-807A-63DA2E33551F_d0e176542_href.png Binary file Symbian3/SDK/Source/GUID-93678518-1FBD-521D-807A-63DA2E33551F_d0e176542_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93678518-1FBD-521D-807A-63DA2E33551F_d0e181567_href.png Binary file Symbian3/SDK/Source/GUID-93678518-1FBD-521D-807A-63DA2E33551F_d0e181567_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-937C3D70-2DCC-5084-AC87-3B1E5865A827.dita --- a/Symbian3/SDK/Source/GUID-937C3D70-2DCC-5084-AC87-3B1E5865A827.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-937C3D70-2DCC-5084-AC87-3B1E5865A827.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Active Backup Client Overview

        The Active Backup Client enables Symbian Developers to write backup and restore software with complete control of which data is backed up and restored.

        The backup client application is often referred to as the data owner as it owns the data. The data owner is automatically invoked to prepare and supply the data to the Backup Engine at backup time. Similarly, the data is automatically supplied back to the data owner on restore.

        Required Background

        Before you start, you must understand the following architecture and concepts:

        • Symbian backup and restore architecture

        • Backup and restore modes (active, passive and proxy).

        Key concepts and terms

        Data owner

        A Symbian process that owns the data to be backed up or restored is a data owner. It can be an application or a server.

        Initiator/Responder

        There are two roles in MTP exchanges, an initiator and a responder. An initiator is the device which initiates requests and operations to the connected responder. A responder is the device which passively responds the requests and operations. Symbian MTP is implemented as a responder role only. A host PC or a portable device on a Symbian device is usually an initiator.

        Architecture

        The following flowchart shows how the Active Backup Client (data owner application) works with other components for data backup and restore. The components provided by Symbian are in green. The components that a device vendor must implement are in blue.

        Active Backup Client -

        • The Backup Server communicates directly with the backup and restore initiator, for example a host PC.

          The Backup Server receives a request from a host PC for a backup or restore operation. It then calls the Backup Engine using the Backup Engine Client API (conn::CSBEClient) for lists of data sets. It also transfers data during a backup or a restore.

          Note: The Symbian platform includes a backup server which a device vendor may replace.

        • The Backup Engine component contains the logic related to the data backup and restore. It signals the start or completion of a backup or restore to all data owners.

          Note: This component runs in a separate process which allows the Backup Server to operate synchronously and asynchronously.

        • An active Data Owner Application responds to signals from the Backup Engine. It releases resources in case of file lock or data confliction. It must define a conn::CActiveBackupClient instance to connect to the Backup Engine and must provide a pointer to an conn::MActiveBackupDataClient implementation. The conn::MActiveBackupDataClient implementation prepares and transfers data to the Backup Engine for a backup and restore.

        APIs

        The Active Backup Client includes the following APIs:

        API Description

        conn::CActiveBackupClient

        Establishes a connection to the Backup Engine for the data owing process.

        conn::MActiveBackupDataClient

        The data owner application must implement this interface to provide the data to the Backup Engine. It is passed to the conn::CActiveBackupClient constructor.

    Typical uses

    The Active Backup Client can be used to prepare and transfer data for the Backup Engine to do a backup and restore.

    Writing an Active Backup Client Tutorial \ No newline at end of file +

    • The Backup Server communicates directly with the backup and restore initiator, for example a host PC.

      The Backup Server receives a request from a host PC for a backup or restore operation. It then calls the Backup Engine using the Backup Engine Client API (conn::CSBEClient) for lists of data sets. It also transfers data during a backup or a restore.

      Note: The Symbian platform includes a backup server which a device vendor may replace.

    • The Backup Engine component contains the logic related to the data backup and restore. It signals the start or completion of a backup or restore to all data owners.

      Note: This component runs in a separate process which allows the Backup Server to operate synchronously and asynchronously.

    • An active Data Owner Application responds to signals from the Backup Engine. It releases resources in case of file lock or data confliction. It must define a conn::CActiveBackupClient instance to connect to the Backup Engine and must provide a pointer to an conn::MActiveBackupDataClient implementation. The conn::MActiveBackupDataClient implementation prepares and transfers data to the Backup Engine for a backup and restore.

    APIs

    The Active Backup Client includes the following APIs:

    API Description

    conn::CActiveBackupClient

    Establishes a connection to the Backup Engine for the data owing process.

    conn::MActiveBackupDataClient

    The data owner application must implement this interface to provide the data to the Backup Engine. It is passed to the conn::CActiveBackupClient constructor.

    Typical uses

    The Active Backup Client can be used to prepare and transfer data for the Backup Engine to do a backup and restore.

    Writing an Active Backup Client Tutorial \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-938C0EB5-D0B3-502E-87A9-7C626642AE4B_d0e270526_href.jpg Binary file Symbian3/SDK/Source/GUID-938C0EB5-D0B3-502E-87A9-7C626642AE4B_d0e270526_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-938C0EB5-D0B3-502E-87A9-7C626642AE4B_d0e275381_href.jpg Binary file Symbian3/SDK/Source/GUID-938C0EB5-D0B3-502E-87A9-7C626642AE4B_d0e275381_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93A4CD14-A3CD-57B2-BF32-57EF38F59ECF_d0e202480_href.png Binary file Symbian3/SDK/Source/GUID-93A4CD14-A3CD-57B2-BF32-57EF38F59ECF_d0e202480_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93A4CD14-A3CD-57B2-BF32-57EF38F59ECF_d0e207487_href.png Binary file Symbian3/SDK/Source/GUID-93A4CD14-A3CD-57B2-BF32-57EF38F59ECF_d0e207487_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93AB9273-08A5-52CD-AFF7-8B92D72067BF.dita --- a/Symbian3/SDK/Source/GUID-93AB9273-08A5-52CD-AFF7-8B92D72067BF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-93AB9273-08A5-52CD-AFF7-8B92D72067BF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,31 +1,29 @@ - - - - - -Using -TDesUse TDes for interfaces which take narrow or wide (Unicode) text, -depending on the build variant. -
    Usage in a -function interface

    An interface which needs to access and modify -either narrow text or wide (Unicode) text, depending on the build variant, -uses a TDes as the argument type. All build independent -concrete descriptors are derived from TDes which means that -the interface can accept any build independent descriptor.

    The following -code fragment shows the most common function prototype pattern.

    void ClassX::foo(TDes& anArg);

    The -use of TDes means that data can be accessed and modified -through the descriptor.

    If the interface is to handle explicit 8 bit -or explicit 16 bit data, regardless of the build variant, then use TDes8 or TDes16 instead.

    -     - -Using class TDes8 - -Using Class -TDes16 + + + + + +Using TDesUse TDes for interfaces which take narrow or wide (Unicode) +text, depending on the build variant. +
    Usage +in a function interface

    An interface which needs to access +and modify either narrow text or wide (Unicode) text, depending on +the build variant, uses a TDes as the argument +type. All build independent concrete descriptors are derived from TDes which means that the interface can accept any build +independent descriptor.

    The following code fragment shows the +most common function prototype pattern.

    void ClassX::foo(TDes& anArg);

    The use of TDes means that data can be accessed +and modified through the descriptor.

    If the interface is to +handle explicit 8 bit or explicit 16 bit data, regardless of the build +variant, then use TDes8 or TDes16 instead.

    +     + +Using Class TDes16 +Using +class TDes8     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93EFC9E4-8779-415D-ABEB-2AC9991996DD.dita --- a/Symbian3/SDK/Source/GUID-93EFC9E4-8779-415D-ABEB-2AC9991996DD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-93EFC9E4-8779-415D-ABEB-2AC9991996DD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ provided.

    Wait note - +
    Using wait notes in applications

    You can create diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93FFE6EF-9F6D-46BD-846C-CAC03F26E643_d0e53249_href.png Binary file Symbian3/SDK/Source/GUID-93FFE6EF-9F6D-46BD-846C-CAC03F26E643_d0e53249_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-93FFE6EF-9F6D-46BD-846C-CAC03F26E643_d0e53392_href.png Binary file Symbian3/SDK/Source/GUID-93FFE6EF-9F6D-46BD-846C-CAC03F26E643_d0e53392_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-94005A46-B4C6-4A30-A8E8-1B9C2D583D50.dita --- a/Symbian3/SDK/Source/GUID-94005A46-B4C6-4A30-A8E8-1B9C2D583D50.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-94005A46-B4C6-4A30-A8E8-1B9C2D583D50.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,10 +9,10 @@ --> -Classic -UI Guide -

    Classic UI provides the native UI support library, AVKON, including standard -controls, views, dialogs and some services for UI applications.

    +Classic UI Guide +

    Classic UI provides the native UI support library, AVKON, including +standard controls, views, dialogs and some services for UI applications. +

    @@ -23,29 +23,25 @@ -

    I want to understand the fundamental architecture of a GUI application.

     +

    I want to understand the fundamental architecture of a GUI +application.

     Application and UI frameworks     -

    I want to design my application for a phone with a touch screen.

     -Touch -UI +

    I want to design my application for a phone with a touch +screen.

     +Touch UI     -

    I want to use the standard controls and dialogs that Classic UI -provides.

     +

    I want to use the standard controls and dialogs that Classic +UI provides.

     UI components

    I want to create my own controls and animations.

     The UI Control Framework (CONE)     - -

    I want to understand the user experience in Symbian platform devices -without touch

     - -
    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-940AF1CE-3C33-54BF-B339-B8CF79C5FC9C_d0e129840_href.jpg Binary file Symbian3/SDK/Source/GUID-940AF1CE-3C33-54BF-B339-B8CF79C5FC9C_d0e129840_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-940AF1CE-3C33-54BF-B339-B8CF79C5FC9C_d0e133460_href.jpg Binary file Symbian3/SDK/Source/GUID-940AF1CE-3C33-54BF-B339-B8CF79C5FC9C_d0e133460_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita --- a/Symbian3/SDK/Source/GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -48,7 +48,7 @@
    Architecture

    The following diagram shows the interaction of APPARC with other components.

    - +

    The following list describes the interaction between APPARC and each of the components depicted in the APPARC architectural diagram:

    • APPARC provides the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9444E57C-1C2F-5EAC-B162-25FC27BB9516.dita --- a/Symbian3/SDK/Source/GUID-9444E57C-1C2F-5EAC-B162-25FC27BB9516.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Pre-v5.1 non-Unicode resource format

      This page describes the resource file format used with the pre-Unicode versions of Symbian platform (all versions before v5.1). This format is obsolete for later versions.

      Number of bytes

      Description

      2

      This two-byte integer (in little-endian byte order) stores the file-position of the start of the resource index (see the last row of this table for a description of the resource index).

      2

      This two-byte integer (in little-endian byte order) stores the size of the resource index in bytes.

      [any]

      This contains the data for all the resources stored in order, one after another with no byte-padding between them. The binary data of each resource is laid out exactly as specified in the resource definition.

      (number_of_resources+1)*2

      This is the resource index, which is a series of two-byte integers (in little-endian byte order), one for each resource in the resource file, each storing the file-position of that resource’s data (see row immediately above).

      The last 16-bit number gives the file offset of the end of the last resource (i.e. the beginning of the index table).

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-947317B7-7E12-509B-9A16-F0604D7F8BA2.dita --- a/Symbian3/SDK/Source/GUID-947317B7-7E12-509B-9A16-F0604D7F8BA2.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,55 +0,0 @@ - - - - - -armfpu -

      armfpu [ vfpv2 | softvfp ]

      -

      Use the armfpu statement to specify how the compiler is -to deal with floating point instructions.

      -

      There are two ways in which floating point instructions can be handled -on an ARM processor:

      -
        -

      • through the use of floating -point support functions.

        • -

      • directly on a hardware -floating point co-processor, the Vector Floating Point (VFP) unit.

        • -
      - - - - -

      softvfp

      -

      This keyword specifies that floating point instructions are handled -by floating point support functions.

      On a device without a VFP unit, -floating point support functions are implemented in software and operate slowly. -On a device with a VFP unit, the floating point support functions are handled -by the VFP unit, and operate faster than when implemented in software.

      Note -that applications do not need to make any changes to take advantage of VFP-enabled -floating point support functions, if they are provided in the device's ROM. -Such functions are used automatically at run time.

      If armfpu is -not specified in a .mmp file, then armfpu softvfp is -assumed by default.

      -       - -

      vfpv2

      -

      This keyword specifies that VFP specific code is to be generated -at compile time whenever floating point instructions are used.

      On -a device with a VFP unit, this option results in code that runs faster than -the floating point support functions generated by softvfp. -Note, however, that binaries produced with VFP specific code do not work on -devices without a VFP unit. Software Install attempts to prevent their -installation, but if any such binaries are installed onto a device in some -other way, for example by inclusion into the ROM at device creation time, -then a call to VFP specific code results in a KERN-EXEC 3 panic (see also Application Installation -Guide).

      -       - - -
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9482CC98-2600-539D-A243-639CF11A2599_d0e426550_href.jpg Binary file Symbian3/SDK/Source/GUID-9482CC98-2600-539D-A243-639CF11A2599_d0e426550_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9482CC98-2600-539D-A243-639CF11A2599_d0e430350_href.jpg Binary file Symbian3/SDK/Source/GUID-9482CC98-2600-539D-A243-639CF11A2599_d0e430350_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-94C64AC2-5680-4DED-8CCB-55CD5C25F1E5.dita --- a/Symbian3/SDK/Source/GUID-94C64AC2-5680-4DED-8CCB-55CD5C25F1E5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-94C64AC2-5680-4DED-8CCB-55CD5C25F1E5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,33 +1,31 @@ - - - - - -Resource -string handling -

      The Symbian platform provides support for loading and formatting resource -strings through the StringLoader class. -To use this class, you must define your strings in the resource file with -the RESOURCE TBUF statement.

      -

      The syntax for the resource string declaration is as follows:

      -RESOURCE TBUF r_name34 { buf = STRING_value_in_rls_file; } -

      where

      -
        -

      • RESOURCE is the keyword for the statement.

        -
        • -

      • TBUF is a utility structure to contain -the string.

        • -

      • r_name34 is the symbolic ID used in -your code.

        • -

      • STRING_value_in_rls_file maps to a value -in an rls file to support localization -and internationalization.

        • -
      -

      For more information, see TBUF.

      + + + + + +Resource string handling +

      The Symbian platform provides support for loading and formatting +resource strings through the StringLoader class. To use this class, you must define your strings +in the resource file with the RESOURCE TBUF statement.

      +

      The syntax for the resource string declaration is as follows:

      +RESOURCE TBUF r_name34 { buf = STRING_value_in_rls_file; } +

      where

      +
        +

      • RESOURCE is the keyword for +the statement.

        • +

      • TBUF is a utility structure +to contain the string.

        • +

      • r_name34 is the symbolic ID +used in your code.

        • +

      • STRING_value_in_rls_file maps +to a value in an rls file to support localization and +internationalization.

        • +
      +

      For more information, see TBUF.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-94EAB348-DB29-5814-BB93-968D9A2A8AD2.dita --- a/Symbian3/SDK/Source/GUID-94EAB348-DB29-5814-BB93-968D9A2A8AD2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-94EAB348-DB29-5814-BB93-968D9A2A8AD2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -85,25 +85,25 @@ to a file using PIPS

    • How to remove the secure directory using PIPS

      • -

    • How to use the P.I.P.S. +

    • How to use the P.I.P.S. standard C maths library, libm.dll

      • -

    • How to compress/ +

    • How to compress/ decompress a file using Open C library.

      • -

    • How to compress/ +

    • How to compress/ decompress a string using Open C library.

      • -

    • How to do filtered +

    • How to do filtered data compression and Huffman compression using Open C library.

      • -

    • How to send/receive +

    • How to send/receive messages using open C message queue library

      • -

    • Shows string utility +

    • Shows string utility using open C libraries

      • -

    • How to write solution +

    • How to write solution for Producer/ Consumer Problem using Open C

      • -

    • how to redirect stdio +

    • how to redirect stdio to a file using libc library

      • -

    • How to handle global +

    • How to handle global variables within the library code

      • -

    • How to solve WSD +

    • How to solve WSD (Writable Static Data) problem

    • How to write a simple console-based STDLIB (C Standard library) program

      • @@ -203,8 +203,8 @@

    • How to construct a control

    • How to rotate a bitmap

      • -

    • How to create a label

      • -

    • how to create OpenVG +

    • How to create a label

      • +

    • how to create OpenVG content on a semi-transparent or transparent UI using the new Graphics architecture using ScreenPlay

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-94F21522-D598-5F85-BE04-D606AE8D5A25.dita --- a/Symbian3/SDK/Source/GUID-94F21522-D598-5F85-BE04-D606AE8D5A25.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-94F21522-D598-5F85-BE04-D606AE8D5A25.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Overview

      Telnet refers to the client-side software implementation and TelnetD (Telnet Daemon) to the server-side implementation. A Telnet client (for example, host PC) is connected to a TelnetD (for example, device). Here the purpose is to run and control a shell on a device using a PC as a terminal with a keyboard.

      The main purpose of using Zsh connected through TelnetD is to launch utilities (such as, external programs), debug applications, generate logs and retrieve information (such as, contents of the file) from public directories. The Utilities are executables whose output can be made available to the remote Telnet user by viewing text, or archiving as files or as an another program.

      Zsh transfers characters to the Telnet client and vice versa using TelnetD. Zsh interface is provided to enable programs to be conveniently launched for testing purposes. The shell also supports a number of built-in commands.

      Using TelnetD and Zsh

      Zsh can be launched by selecting the Zsh icon on the device. It starts TelnetD automatically. A connection can then be established from the Telnet client (host PC) to TelnetD by giving the following command at a Windows® or a UNIX® command prompt:

      Telnet <ip-address of the device>

      For information on retrieving the IP address refer to Setup.

      Every login to Zsh is through a key handshake. The device prompts for a key when you try to connect from the host PC. The same key given to the device has to be given at the host PC for the login to be successful. If the login is successful then the device starts the Zsh application. The maximum number of characters a key can accept is eight. The characters can be a combination of alphabets, numerals, and special characters.

      For existing Telnet clients on the host PC such as Microsoft Windows or Linux to connect to the server running on the device, the device needs an IP address.

      TelnetD supports send and receive functionality: TelnetD sends any data to and from Zsh to the host PC. TelnetD runs only when it is connected through a TCP/IP network. When the Telnet client places a request, TelnetD starts Zsh on the device, executes the specified command on the device, and sends the resultant data back to the host PC.

      Connection between the client (host PC) and the server (device) -
      Reference Setup       \ No newline at end of file +
    Reference Setup     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95259B6D-19A0-569E-B04B-F75B8DADC80E.dita --- a/Symbian3/SDK/Source/GUID-95259B6D-19A0-569E-B04B-F75B8DADC80E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-95259B6D-19A0-569E-B04B-F75B8DADC80E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -The object container index

    All object containers must be held within a special type of container known as an object container index.

    An object container index is an instance of a CObjectConIx class.

    An object container index not only acts as a container for object containers, but also provides the mechanism through which object containers are created.

    CObjectConIx::CreateL() creates an object container and is responsible for assigning a unique ID to it. This unique ID forms part of the identity of all reference counting objects which that object container will, in due course, hold.

    For example, the sever creates a single object container index; from this it creates a number of object containers, each of which, in turn, holds reference counting objects. The following drawing shows the idea.

    An object container index is implemented as a simple array where each element of the array contains a pointer to an object container. CObjectConIx::CreateL() constructs an object container, assigns a unique ID to it and adds it into the CObjectConIx array.

    See also:

    • CObjectConIx

    • CObjectCon

    • CObject

    \ No newline at end of file +The object container index

    All object containers must be held within a special type of container known as an object container index.

    An object container index is an instance of a CObjectConIx class.

    An object container index not only acts as a container for object containers, but also provides the mechanism through which object containers are created.

    CObjectConIx::CreateL() creates an object container and is responsible for assigning a unique ID to it. This unique ID forms part of the identity of all reference counting objects which that object container will, in due course, hold.

    For example, the sever creates a single object container index; from this it creates a number of object containers, each of which, in turn, holds reference counting objects. The following drawing shows the idea.

    An object container index is implemented as a simple array where each element of the array contains a pointer to an object container. CObjectConIx::CreateL() constructs an object container, assigns a unique ID to it and adds it into the CObjectConIx array.

    See also:

    • CObjectConIx

    • CObjectCon

    • CObject

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9535CF67-7541-554E-BE5C-9FDDFDB58EA5.dita --- a/Symbian3/SDK/Source/GUID-9535CF67-7541-554E-BE5C-9FDDFDB58EA5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -targettype

    targettype target-type

    Use the targettype statement to specify the kind of project.

    The following target types are supported:

    Target type Description

    ani

    A window server animation DLL.

    app

    A GUI application. This is deprecated at v9.0. Applications must be converted to EXEs.

    ctl

    A system control. This is deprecated at v9.0. They must be converted to applications.

    dll

    A DLL: either a shared library, or a polymorphic interface.

    ecomiic

    An ECOM implementation collection. This is deprecated at v9.0. The plugin target type should be used instead.

    epocexe

    A Symbian platform executable that can be launched from the shell. This is an executable program which exports no functions under a multi-process platform and a DLL which is linked with the TIntWinsMain() function exported as ordinal 1 under a single-process platform.

    exe

    An executable program.

    exedll

    An executable program for a multi-process platform, a DLL for a single-process platform.

    exexp

    An executable program with exports.

    fsy

    A plug-in file system.

    implib

    Results solely in the generation of a .lib file. It is an error for a component of the IMPLIB type to contain SOURCE statements and the build tools enforce this.

    kdll

    A kernel DLL.

    kext

    A kernel extension.

    klib

    A kernel library.

    ldd

    A logical device driver.

    lib

    A static library.

    mda

    A media-server plug-in DLL (deprecated).

    mdl

    A MIME recognizer. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

    none

    A bitmap or resource file without any executable.

    notifier

    An extended notifier DLL. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

    opx

    An OPL extension.

    plugin

    An ECOM implementation collection.

    plugin3

    An ECOM implementation collection that supports extended interfaces.

    pdd

    A physical device driver. You can export functions from pdd if you have a .def file specified in the pdd's matching .mmp file.

    pdl

    A printer driver.

    rdl

    A recognizer. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

    stdexe

    A P.I.P.S. EXE, which is identified by the following UIDs on a Symbian platform:

    • UID1 - 0x1000007a

    • UID2 - 0x20004C45

    stddll

    A P.I.P.S. DLL, which is identified by the following UIDs on a Symbian platform:

    • UID1 - 0x10000079

    • UID2 - 0x20004C45

    stdlib

    A P.I.P.S. static library.

    var

    A variant file.

    Note:

    • For more information about the target types stdexe, stddll and stdlib, refer to Target Types.

    • The target types ecomiic, kdll, kext, klib, ldd, pdd and var are built in ARM mode, as these targets have access to kernel APIs. That is, all the kernel code is built in ARM mode using --arm compiler option, whereas all the user code is built in THUMB mode using --thumb compiler option.

    • The target types stdexe, stddll and stdlib are supported only on ARM ABI and Symbian emulator compliant platforms, such as, ARMv5, ARMv5_ABIv2, GCCE and WINSCW.

    • When exporting functions from the target types, build system can auto generate .def files only for DLL, EXEDLL, EXEXP, and STDDLL target types even if, you do not have a .def file specified in the matching .mmp file.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95493C3D-58C6-5EBF-85E1-167D58E68658.dita --- a/Symbian3/SDK/Source/GUID-95493C3D-58C6-5EBF-85E1-167D58E68658.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-95493C3D-58C6-5EBF-85E1-167D58E68658.dita Tue Jul 20 12:00:49 2010 +0100 @@ -115,7 +115,7 @@ Audio Video Distribution Transport Protocol (AVDTP) is used to deliver the output stream from the multimedia application to the controller device. The RemCon Server status is updated to the Controller through the AVRCP bearer.

    - +
    What's next?

    The following tutorial series has been provided to make writing remote control applications easier.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95580D64-315E-51E8-99C3-6C0B8FFF1522_d0e277871_href.png Binary file Symbian3/SDK/Source/GUID-95580D64-315E-51E8-99C3-6C0B8FFF1522_d0e277871_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95580D64-315E-51E8-99C3-6C0B8FFF1522_d0e282710_href.png Binary file Symbian3/SDK/Source/GUID-95580D64-315E-51E8-99C3-6C0B8FFF1522_d0e282710_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9574041E-183D-5C3F-8429-A62323B97739.dita --- a/Symbian3/SDK/Source/GUID-9574041E-183D-5C3F-8429-A62323B97739.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Dictionary-compressed resource format

      This page describes the dictionary-compressed resource file format introduced from Symbian OS v7.0. This format can produce higher-compression than the simple compression format.

      The format is supported by the resource reading APIs, but Development Kits do not currently contain a resource compiler that produces this format.

      Number of bytes

      Description

      16

      These bytes store the resource file’s UIDs.

      The first twelve bytes consist of three four-byte integers (in little-endian byte order) followed by a four-byte CRC checksum generated from those three integers.

      The first UID is always 0x101f5010.

      The second and third UIDs are the same as the second and third UIDs of the file from which the dictionary-compressed resource-file is generated.

      1

      The least significant three bits:

      These store the number of bits used for dictionary references, storing this value as an offset from 3. For example, if 2 is stored in these three bits, then the number of bits per dictionary reference would be 3+2=5. Thus, the number of bits per dictionary reference may range inclusively from 3 (=3+0) to 10 (=3+7). The maximum number of dictionary entries for each number of bits per dictionary reference is therefore 8 (=23), 16 (=24), 32 (=25), 64 (=26), 128 (=27), 256 (=28), 512 (=29), 1024 (=210).

      The most significant five bits:

      This stores flags. Currently there are three flags defined:

      The most significant bit (0x80) indicates whether the third UID is actually the resource file’s offset (see the first row of the preceding table for a description of what the offset is). The bit is set to non-zero if it is, and zero if it is not.

      The second-most significant bit (0x40) indicates whether the first resource in the resource file (from the client’s point of view) is an RSS_SIGNATURE with default values for which no data is actually stored later in the resource file. The bit is set to non-zero if it is, and zero if it is not. This flag must only be on if the third UID of the resource file is the resource file’s offset (see the 0x80 flag described immediately above).

      The third-most significant bit (0x20) flags if the bit-array that indicates which resources contain compressed Unicode has been stored as a resource before the client’s actual resources. (If it is stored as a resource, it benefits by being dictionary-compressed.) The bit is set to non-zero if the bit-array is stored as a resource, and zero if it is simply stored as a field on its own (see the fifth row of this table).

      Note that the bit-array will not contain a bit that refers to the “non-stored” (if the 0x40 flag is on) initial RSS_SIGNATURE resource. It will also not contain a bit that refers to itself if it is stored as a resource (i.e. if the 0x20 flag is on).

      2

      This two-byte integer (in little-endian byte order) stores the size in bytes of the largest resource in the file (that is, the size when uncompressed with regard to both dictionary-compression and compressed Unicode).

      2

      This two-byte integer (in little-endian byte order) stores the file-position of the start of the resource data (see the penultimate row of this table for a description of the resource data).

      Number_of_resources/8 (rounded up to the nearest whole number), or zero if the 0x20 flag (described in the second row of this table) is on

      This is a bit-array (one bit for each resource) storing which resources contain compressed Unicode. This field is not always present (see the left-hand column).

      [any]

      This contains the data for all the dictionary entries stored one after another with no bit-padding between them, encoded according to the scheme described in the next table. The last dictionary entry, if not finishing on a byte-boundary, is followed by zero pad-bits up to the next byte-boundary.

      Number_of_dictionary_entries*2

      This is the dictionary index which is a series of two-byte integers (in little-endian byte order), one for each dictionary entry, each storing the offset in bits from the start of the entire dictionary data to one-bit past the end of that dictionary entry’s data (see row immediately above).

      [any]

      This contains the data for all the resources stored in order, one after another with no bit-padding between them, encoded according to the scheme described in the next table. The data for the last resource, if not finishing on a byte-boundary, is followed by zero pad-bits up to the next byte-boundary.

      Number_of_resources*2, or (number_of_resources-1)*2 if the 0x40 flag (described in the second row of this table) is on

      This is the resource index which is a series of two-byte integers (in little-endian byte order), one for each stored resource, each storing the offset in bits from the start of the entire resource data to one-bit past the end of that resource’s data (see row immediately above).

      The data for each dictionary entry and the data for each resource consist of zero, one or more of the following bit-sequences shown in the table below. Note that the order of bits is taken as going from least-significant to most-significant. Thus, for example, the binary prefix 10 (assuming that these bits were not split across a byte-boundary) would actually be stored with the 1 in the less significant bit of the bit-pair and the 0 in the more significant bit.

      Prefix bits

      Description of what follows

      0

      This is followed by a dictionary reference (the second row of the previous table describes the field indicating how many bits a dictionary reference occupies). A dictionary reference is a zero-based index* into the dictionary entries, i.e. a dictionary reference of 0 indicates the first dictionary entry, and dictionary reference of 1 indicates the second dictionary entry, etc.

      10

      This is followed by one octet of data, the least significant bit of the octet being stored first.

      110

      This is followed by two octets of data, the least significant bit of the first octet being stored first.

      1110

      This is followed by a three-bit integer* storing the number of subsequent octets minus 3, followed by those octets themselves (the least significant bit of the first octet being stored first). Use this to store a run of between 3 and 10 octets (inclusive).

      1111

      This is followed by an eight-bit integer* storing the number of subsequent octets minus 11, followed by those octets themselves (the least significant bit of the first octet being stored first). Use this to store a run of between 11 and 266 octets (inclusive).

      * These integers, if split across one or more byte-boundaries are stored in little-endian “byte-order”, i.e. the segment of the integer stored in the “next” byte store more significant bits than the segment of the integer stored in the “current” byte.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95CE2206-7AE0-48C0-97A7-4E2082F9F662.dita --- a/Symbian3/SDK/Source/GUID-95CE2206-7AE0-48C0-97A7-4E2082F9F662.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-95CE2206-7AE0-48C0-97A7-4E2082F9F662.dita Tue Jul 20 12:00:49 2010 +0100 @@ -32,7 +32,7 @@ Fixed toolbar with implementation classes - +
      Implementing a toolbar

      To use a toolbar in your application, implement the following diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-95E557D0-9A84-514C-B51E-0556F26B3C98.dita --- a/Symbian3/SDK/Source/GUID-95E557D0-9A84-514C-B51E-0556F26B3C98.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-95E557D0-9A84-514C-B51E-0556F26B3C98.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,8 +37,10 @@

    • CEZGZipToFile

    • CEZFileToGZip

    -
    Build

    The Symbian -build process describes how to build an application.

    The EzlibExample builds an executable file called ezlibexample.exe in the standard location (\epoc32\release\winscw\ <build_variant > for CodeWarrior). After launching -the executable, depending on the emulator you are using, you may need -to navigate using the application launcher or the eshell screen to view the console.

    +
    Build

    The Symbian build process describes how to build an application.

    The EzlibExample builds an executable +file called ezlibexample.exe in the standard +location (\epoc32\release\winscw\ <build_variant > for CodeWarrior). After launching the executable, +depending on the emulator you are using, you may need to navigate +using the application launcher or the eshell screen +to view the console.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9620407B-0560-5D95-A862-5AE406C48983.dita --- a/Symbian3/SDK/Source/GUID-9620407B-0560-5D95-A862-5AE406C48983.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9620407B-0560-5D95-A862-5AE406C48983.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,11 +22,11 @@ and the components in its environment are shown below. It uses the RResourceFile class to access the actual resource files.

    String Resource Reader environment - +

    String Resource Reader consists of one class, CTulStringResourceReader. String Resource Reader uses BaflUtils and RResourceFile.

    Class diagram - +
    Description

    Usage

    String Resource Reader is designed to load strings from normal resource files. The diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9660B072-9BD6-5A84-B45A-636F0D06D467.dita --- a/Symbian3/SDK/Source/GUID-9660B072-9BD6-5A84-B45A-636F0D06D467.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9660B072-9BD6-5A84-B45A-636F0D06D467.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,12 +1,38 @@ - - - - - -setopt

    setopt [ {+|-}options | {+|-}o option_name ] [ name ... ]

    Set the options for the shell. All options specified either with flags or by name are set. If no arguments are supplied, the names of all options currently set are printed.

    Option Description

    -m

    The arguments are taken as patterns (which should be quoted to protect them from filename expansion), and all options with names matching these patterns are set.

    Note: For information about the options supported by the setopt command, refer to http://zsh.dotsrc.org. Note that not all the options listed on this web page are supported by Symbian.

    \ No newline at end of file + + + + + +setopt +

    setopt [ {+|-}options | {+|-}o option_name ] [ name +... ]

    +

    Set the options for the shell. All options specified either with +flags or by name are set. If no arguments are supplied, the names +of all options currently set are printed.

    + + + + +Option +Description + + + + +

    -m

    +

    The arguments are taken as patterns (which should be quoted +to protect them from filename expansion), and all options with names +matching these patterns are set.

    +     + + +
    +

    Note: For information about the options supported by the setopt command, refer to http://zsh.dotsrc.org. Note that not all the options listed +on this web page are supported by Symbian.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9665C072-EA52-54B8-87A3-A7F818940DCD.dita --- a/Symbian3/SDK/Source/GUID-9665C072-EA52-54B8-87A3-A7F818940DCD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9665C072-EA52-54B8-87A3-A7F818940DCD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -25,7 +25,7 @@ field at a given location in a record is in a column. A table can also be called a record set.

    - +

    Tables, records, columns and fields are all CommsDat elements. An element is an item that can be stored in the Comms Database.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-967F99EC-0C6E-468F-BB2D-C175C7F69B67_d0e4655_href.png Binary file Symbian3/SDK/Source/GUID-967F99EC-0C6E-468F-BB2D-C175C7F69B67_d0e4655_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-967F99EC-0C6E-468F-BB2D-C175C7F69B67_d0e4782_href.png Binary file Symbian3/SDK/Source/GUID-967F99EC-0C6E-468F-BB2D-C175C7F69B67_d0e4782_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-96C007D1-9AA0-57DC-A6DC-8B6E5A2DF644.dita --- a/Symbian3/SDK/Source/GUID-96C007D1-9AA0-57DC-A6DC-8B6E5A2DF644.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -capability

    capability capability-names

    Use the capability statement to specify the platform security capabilities of the executable.

    The setting is only functional on OS versions based on the EKA2 kernel. For those versions based on EKA1, the keyword is ignored.

    The keyword is followed by a space separated set of capabilities, for example:

    CAPABILITY LocalServices ReadDeviceData ReadUserData

    The special capability name ALL is used to represents all capabilities supported by the current version of Symbian platform. This can be used as an alternative to naming all capabilities individually.

    ALL can also be used together with capability names prefixed by a '-', to indicate which capabilities to exclude, e.g.

    CAPABILITY ALL -TCB -TrustedUI

    indicates a set of all capabilities excluding TCB and TrustedUI.

    If no capabilities are required, then NONE can be used.

    If the CAPABILITY keyword is not present in the MMP file, then the default of CAPABILITY NONE is used.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-96E46D0E-1CE3-58B4-AE99-6B2E622ADAF9.dita --- a/Symbian3/SDK/Source/GUID-96E46D0E-1CE3-58B4-AE99-6B2E622ADAF9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-96E46D0E-1CE3-58B4-AE99-6B2E622ADAF9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -36,11 +36,14 @@

  • RWindow::SetTransparentRegion(const TRegion&): this function restricts the transparency to a specified region of the window.

    • -

    Handling window server events

    The user-defined class CEventHandler handles -pointer events when transparent areas of the window are clicked by -the pointer device. An appropriate message is displayed when a click event is detected.

    -
    Build

    The Symbian -build process describes how to build this example.

    The Transparent example builds an executable called transparent.exe in the standard location (\epoc32\release\winscw\<build_variant> for Carbide.c++).

    +

    Handling window server events

    The user-defined +class CEventHandler handles pointer events when transparent +areas of the window are clicked by the pointer device. An appropriate +message is displayed when a click event is detected.

    +
    Build

    The Transparent example builds an executable +called transparent.exe in the standard location +(\epoc32\release\winscw\<build_variant> for +Carbide.c++).

    Running the example

    The example creates three windows:

    • One background diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-971C9B81-1D6F-59E7-9416-385A0787D642.dita --- a/Symbian3/SDK/Source/GUID-971C9B81-1D6F-59E7-9416-385A0787D642.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-971C9B81-1D6F-59E7-9416-385A0787D642.dita Tue Jul 20 12:00:49 2010 +0100 @@ -47,7 +47,7 @@ Example showing the order and priority of controls on the control stack - +

      On the stack shown in the diagram key-press events will be offered first to control D, followed by A, B and C in that order. A control on the stack diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97545AEB-0518-5937-AEB6-C97443B449D3_d0e270252_href.jpg Binary file Symbian3/SDK/Source/GUID-97545AEB-0518-5937-AEB6-C97443B449D3_d0e270252_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97545AEB-0518-5937-AEB6-C97443B449D3_d0e275107_href.jpg Binary file Symbian3/SDK/Source/GUID-97545AEB-0518-5937-AEB6-C97443B449D3_d0e275107_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-975CBC70-81E6-5FA2-80CE-88DD2ABE9595.dita --- a/Symbian3/SDK/Source/GUID-975CBC70-81E6-5FA2-80CE-88DD2ABE9595.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-975CBC70-81E6-5FA2-80CE-88DD2ABE9595.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ The collections and components in the Graphics package - +

      The following list gives links to high-level Graphics topics and the collections diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-979D7C71-A61A-5A49-AF67-8BB9CF67AFF0.dita --- a/Symbian3/SDK/Source/GUID-979D7C71-A61A-5A49-AF67-8BB9CF67AFF0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-979D7C71-A61A-5A49-AF67-8BB9CF67AFF0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Bluetooth Manager OverviewThe Bluetooth Manager component provides non-volatile storage of details of Bluetooth devices in the Bluetooth Registry.

      Purpose

      The Bluetooth Manager enables you to store details of devices in the Bluetooth Registry. It also enables you to retrieve, modify and delete the information about devices.

      Key concepts and terms

      Documentation on the Bluetooth Manager component uses the following key concepts and terms:

      Cookie

      Stored data that can be used by the UI whenever it is needed.

      EIR (Extended Inquiry Response)

      Information that is supplied by the host and transmitted in the inquiry responses sub-state.

      'Bonded' settings

      Details of peer devices with which a device has formed secure relationships in the past.

      'Last used' settings

      Details of when devices were last connected.

      Architecture

      Diagram showing Bluetooth Manager relationships -
      Bluetooth Manager summary

      The Bluetooth Manager component provides the following:

      • BT Device

        btdevice.dll

        Provides a mechanism for discovering, setting and retreiving information about the various properties of a Bluetooth device.

      • BT Manager Client

        btmanclient.dll

        Provides access to the Bluetooth Manager server.

      • BT Manager Server

        btmanserver.exe

        Provides access to the Bluetooth Registry.

      • EIR Client

        eirclient.dll

        Provides ways of publishing information over the Bluetooth EIR mechanism.

      \ No newline at end of file +
    Bluetooth Manager summary

    The Bluetooth Manager component provides the following:

    • BT Device

      btdevice.dll

      Provides a mechanism for discovering, setting and retreiving information about the various properties of a Bluetooth device.

    • BT Manager Client

      btmanclient.dll

      Provides access to the Bluetooth Manager server.

    • BT Manager Server

      btmanserver.exe

      Provides access to the Bluetooth Registry.

    • EIR Client

      eirclient.dll

      Provides ways of publishing information over the Bluetooth EIR mechanism.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97ACFC53-4B55-5880-988D-7C376D8AFB16.dita --- a/Symbian3/SDK/Source/GUID-97ACFC53-4B55-5880-988D-7C376D8AFB16.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-97ACFC53-4B55-5880-988D-7C376D8AFB16.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Overview

    The Session Description Protocol (SDP) provides the users with a standard representation for media details, transport addresses, and session description metadata. This representation is independent of the method the information is transported. The SDP Codec subsystem enables its clients the SDP Codec API do the following:

    • encode SDP descriptions into an internal form

    • decode the descriptions from an internal form

    • set and get the SDP field values

    Architectural Relationships

    The calls to the SDP Codec API are synchronous. The SDP Codec API does not require capabilities and it cannot be extended.

    SDP Codec API class structure

    The client uses some or all the SDP Codec API classes during the handling of a SDP description. The interface classes are derived from CBase. The client has a 'use' relationship with the SDP Codec API library.

    The following illustration shows the SDP Codec API class structure.

    Memory used

    The amount of memory used by every header object of the SDP Codec API is equivalent to the memory used by the header as text.

    See also

    • Multiparty Multimedia Session Control (mmusic)

    • Real Time Streaming Protocol (RTSP)

    • Integration of Resource Management and Session Initiation Protocol (SIP)

    • Grouping of Media Lines in the Session Description Protocol (SDP)

    • An Offer/Answer Model with the Session Description Protocol (SDP)

    \ No newline at end of file +Overview

    The Session Description Protocol (SDP) provides the users with a standard representation for media details, transport addresses, and session description metadata. This representation is independent of the method the information is transported. The SDP Codec subsystem enables its clients the SDP Codec API do the following:

    • encode SDP descriptions into an internal form

    • decode the descriptions from an internal form

    • set and get the SDP field values

    Architectural Relationships

    The calls to the SDP Codec API are synchronous. The SDP Codec API does not require capabilities and it cannot be extended.

    SDP Codec API class structure

    The client uses some or all the SDP Codec API classes during the handling of a SDP description. The interface classes are derived from CBase. The client has a 'use' relationship with the SDP Codec API library.

    The following illustration shows the SDP Codec API class structure.

    Memory used

    The amount of memory used by every header object of the SDP Codec API is equivalent to the memory used by the header as text.

    See also

    • Multiparty Multimedia Session Control (mmusic)

    • Real Time Streaming Protocol (RTSP)

    • Integration of Resource Management and Session Initiation Protocol (SIP)

    • Grouping of Media Lines in the Session Description Protocol (SDP)

    • An Offer/Answer Model with the Session Description Protocol (SDP)

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97C0A5B1-99AE-5F71-9092-A6976E54AEA7.dita --- a/Symbian3/SDK/Source/GUID-97C0A5B1-99AE-5F71-9092-A6976E54AEA7.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,57 +0,0 @@ - - - - - -How -to initialise STRUCT RESOURCE members -

    <struct-initialiser> -

    -

    struct-initialiser ::= -

    -

    <struct-name> { <struct-initialiser-item-list> } <struct-initialiser-item> -

    -

    struct-initialiser-item ::= -

    -

    <member-name> = <initialiser> ;

    -

    To initialise a member of STRUCT type, give the struct-name with -which you wish to initialise it, and then specify each member of that struct -which you wish to initialise.

    -

    The member-names listed must be members of the struct-name struct. -Each initialise must be of a type compatible with the member -it is initialising.

    -

    Example

    -

    Given the previously defined struct types,

    -STRUCT STRINGCOUNT - { - BUF message; - WORD num; - } -STRUCT SAMPLE - { - WORD anynumber; - STRUCT text; // should be a STRINGCOUNT - } -

    the following example shows how to define the struct within a resource:

    -RESOURCE SAMPLE show_how - { - anynumber=10; - text=STRINGCOUNT - { - message="Hello" - num=5; - }; - } -

    Type safety

    -

    The compiler does not enforce type safety. Any struct can be used to initialise -a member declared to be of struct type. Usually, however, the designer of -the struct will have intended only one or a limited number of structs ever -be used to initialise a member. You should ensure that you initialise struct -members with the intended struct type.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97C9A782-A7DE-480B-9DE0-97B213AAEDD0.dita --- a/Symbian3/SDK/Source/GUID-97C9A782-A7DE-480B-9DE0-97B213AAEDD0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-97C9A782-A7DE-480B-9DE0-97B213AAEDD0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,12 +23,12 @@ and “Enter PIN code”, and is always aligned close to input field.

    Example of alpha-numeric input mode in portrait and landscape. - +

    If only number entry is enabled, the Query input displays number buttons.

    Example of numeric input mode in portrait and landscape. - +

    In other data queries, the touch input is opened with touch down and release to the editor. In query input, the input is instantly available for immediate diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-97F216EE-B7EA-4A8A-A038-83E1548AE254.dita --- a/Symbian3/SDK/Source/GUID-97F216EE-B7EA-4A8A-A038-83E1548AE254.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-97F216EE-B7EA-4A8A-A038-83E1548AE254.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,6 +19,6 @@ stretching OFF) and 1 (list stretching ON).

    Example image of list stretch - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-983C5DB9-85EF-541E-B494-19E3E617914A.dita --- a/Symbian3/SDK/Source/GUID-983C5DB9-85EF-541E-B494-19E3E617914A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-983C5DB9-85EF-541E-B494-19E3E617914A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@

    The following diagram shows the idea:

    Embedded store within stream - +

    An embedded store can contain an arbitrarily complex network of streams. As well as being easy to delete, this stream network can also be copied by diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9901F6E2-0D36-59D6-A32A-D666C4F2DAAF_d0e76813_href.png Binary file Symbian3/SDK/Source/GUID-9901F6E2-0D36-59D6-A32A-D666C4F2DAAF_d0e76813_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9901F6E2-0D36-59D6-A32A-D666C4F2DAAF_d0e76851_href.png Binary file Symbian3/SDK/Source/GUID-9901F6E2-0D36-59D6-A32A-D666C4F2DAAF_d0e76851_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-993629CB-17B4-5E87-8DE1-06A4AC473FDD.dita --- a/Symbian3/SDK/Source/GUID-993629CB-17B4-5E87-8DE1-06A4AC473FDD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-993629CB-17B4-5E87-8DE1-06A4AC473FDD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> RTP overview

    Purpose

    The Multimedia Protocols RTP (Real-Time Transport Protocol) component provides RTP communication services. This overview shows the usage of the RTP/RTCP protocol as defined in RFC 3550.

    Required background

    The clients that make use of this API need to be familiar with RFC 3550 standard.

    Key concepts

    The component has the following key concepts:

    RTP

    RTP provides end-to-end network transport services for data with real-time characteristics, such as interactive audio and video. It is built on top of the User Datagram Protocol (UDP).

    RTP contains two closely linked parts:

    • RTP: Real-Time Transport Protocol to carry data that has real-time properties.

    • RTCP: RTP Control Protocol to provide feedback on the quality of service being provided by RTP.

    RTCP

    RTP Control Protocol used to provide feedback on the quality of service being provided by RTP. RTP and RTCP support transmission of the data and the control packets.

    Architectural Relationship

    The RTP component of MM-protocols uses the following:

    • Comms-infras ESOCK 

    • Networking INSOCK

    API summary

    The following are some of the main classes used for RTP communication.

    Class Name Description

    RRtpSession

    A handle to an RTP session that abstracts all RTP information going to and from an RTP socket, and its corresponding RTCP data.

    RRtpPacket

    A handle to an RTP packet used to access the packet through the interface provided by this handle.

    RRtpSendPacket

    Derived from RRtpPacket and used as a handle to an RTP send packet.

    RRtpReceivePacket

    Derived from RRtpPacket and used as a handle to an RTP receive packet.

    RRtpReceiveSource

    A handle to a receive stream. An object of this type represents the stream of data on a single SSRC and delivers the RTP packets and RTCP information in the order they arrive.

    RRtpSendSource

    A handle to a send stream, used to manage the creation and sending of packets.

    The following diagram shows the RTP classes and their relationships.

    Class diagram for RTP classes -
    Typical uses

    Any application requiring RTP as its transport protocol should use this API. RTP provides the following key services:

    • Payload-type identification

    • Sequence numbering

    • Time stamping

    • Delivery monitoring

    The RTP API allows you to perform the following tasks:

    1. Creating and Managing an RTP session

    2. Registering for and handling events

    3. Accessing an RTP packet

    4. Creating a send stream

    5. Sending an RTP packet

    6. Creating receive stream

    7. Sending and receiving non RTP-data

    8. Managing RTCP packets and reports

    9. Managing send and receive reports

    10. Securing RTP with SRTP

    Note: Before using any of these services, a connection to the socket server must have been made and the socket must be open.

    See also

    RTPExample: RTP packet streaming

    \ No newline at end of file +
    Typical uses

    Any application requiring RTP as its transport protocol should use this API. RTP provides the following key services:

    • Payload-type identification

    • Sequence numbering

    • Time stamping

    • Delivery monitoring

    The RTP API allows you to perform the following tasks:

    1. Creating and Managing an RTP session

    2. Registering for and handling events

    3. Accessing an RTP packet

    4. Creating a send stream

    5. Sending an RTP packet

    6. Creating receive stream

    7. Sending and receiving non RTP-data

    8. Managing RTCP packets and reports

    9. Managing send and receive reports

    10. Securing RTP with SRTP

    Note: Before using any of these services, a connection to the socket server must have been made and the socket must be open.

    See also

    RTPExample: RTP packet streaming

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-993A732B-13F8-48B6-B0C5-7246FA6828DF.dita --- a/Symbian3/SDK/Source/GUID-993A732B-13F8-48B6-B0C5-7246FA6828DF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-993A732B-13F8-48B6-B0C5-7246FA6828DF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ in the figure below.

    Toolbar API class structure - +

    CAknToolbar is the API main class that provides the most of the API functionality. The UI framework classes CEikAppUiFactory, CAknView, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9955D228-75CE-45B3-9714-AF635D04E553_d0e56643_href.png Binary file Symbian3/SDK/Source/GUID-9955D228-75CE-45B3-9714-AF635D04E553_d0e56643_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9955D228-75CE-45B3-9714-AF635D04E553_d0e56786_href.png Binary file Symbian3/SDK/Source/GUID-9955D228-75CE-45B3-9714-AF635D04E553_d0e56786_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9971A0B9-B2D7-59D3-8834-FDDEEC57AC67.dita --- a/Symbian3/SDK/Source/GUID-9971A0B9-B2D7-59D3-8834-FDDEEC57AC67.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9971A0B9-B2D7-59D3-8834-FDDEEC57AC67.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -How to use the SIP Profile API

    Protocols

    This section provides the information about the protocol and error handling related to the SIP Profile API:

    • When you create a CSIPProfileRegistry object, the client connects to the shared SIP Profile server. Note: If the server is not running, it is started by the API implementation.

      When the CSIPProfileRegistry object is deleted, the corresponding connection to the server is closed. The server stops if it has no other users.

    • The profile data is transferred from the server to the client when a user retrieves a CSIPProfile object through CSIPProfileRegistry.

      When the client holds an instance of CSIPProfile in its memory, all events related to the corresponding profile use MSIPProfileRegistryObserver callback functions to notify the client. The callback functions are implemented by the client.

      Note: A CSIPProfile object is created each time a profile is retrieved.

    • When the client deletes the CSIPProfile object, the client is not notified about events.

    • The profile must be active before a CSIPProfile object is used by the SIP Client API. Use the MSIPRegistrationContext::IsContextActive() function to check. A profile becomes active when it is enabled by the client and the state of the profile is ERegistered. ERegistered is an enum value of the TSIPProfileState enum defined in the class CSIPProfileAgent.

    • All profiles are automatically registered when they are enabled. If a profile is not registered before being enabled, the registration status change is acknowledged through MSIPProfileRegistryObserver. If the enabled profile is already registered, no additional registration or status change events are sent.

    • When a profile is enabled and registered, the client can use it and the SIP Client API to create SIP sessions. An enabled profile cannot be removed from the system while it is used by the client.

    • When a profile is not needed by the client, it is disabled. When you delete an instance of the profile the profile is disabled.

    The following illustration shows use of the SIP Profile API.

    Error handling

    The errors are indicated by return codes, by functions leaving, or by calling callback functions. If an error occurs during a synchronous operation initiated by the client, the called function leaves with a correct error code.

    If an error occurs during an asynchronous operation, the error is passed to the client through the callback function MSIPProfileRegistryObserver::ProfileRegistryErrorOccurred(). In this case, both the profile identifier and an error code are passed to the client. Any error passed to the client means that the indicated profile is not registered or enabled by the client.

    \ No newline at end of file +How to use the SIP Profile API
    Protocols

    This section provides the information about the protocol and error handling related to the SIP Profile API:

    • When you create a CSIPProfileRegistry object, the client connects to the shared SIP Profile server. Note: If the server is not running, it is started by the API implementation.

      When the CSIPProfileRegistry object is deleted, the corresponding connection to the server is closed. The server stops if it has no other users.

    • The profile data is transferred from the server to the client when a user retrieves a CSIPProfile object through CSIPProfileRegistry.

      When the client holds an instance of CSIPProfile in its memory, all events related to the corresponding profile use MSIPProfileRegistryObserver callback functions to notify the client. The callback functions are implemented by the client.

      Note: A CSIPProfile object is created each time a profile is retrieved.

    • When the client deletes the CSIPProfile object, the client is not notified about events.

    • The profile must be active before a CSIPProfile object is used by the SIP Client API. Use the MSIPRegistrationContext::IsContextActive() function to check. A profile becomes active when it is enabled by the client and the state of the profile is ERegistered. ERegistered is an enum value of the TSIPProfileState enum defined in the class CSIPProfileAgent.

    • All profiles are automatically registered when they are enabled. If a profile is not registered before being enabled, the registration status change is acknowledged through MSIPProfileRegistryObserver. If the enabled profile is already registered, no additional registration or status change events are sent.

    • When a profile is enabled and registered, the client can use it and the SIP Client API to create SIP sessions. An enabled profile cannot be removed from the system while it is used by the client.

    • When a profile is not needed by the client, it is disabled. When you delete an instance of the profile the profile is disabled.

    The following illustration shows use of the SIP Profile API.

    Error handling

    The errors are indicated by return codes, by functions leaving, or by calling callback functions. If an error occurs during a synchronous operation initiated by the client, the called function leaves with a correct error code.

    If an error occurs during an asynchronous operation, the error is passed to the client through the callback function MSIPProfileRegistryObserver::ProfileRegistryErrorOccurred(). In this case, both the profile identifier and an error code are passed to the client. Any error passed to the client means that the indicated profile is not registered or enabled by the client.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-99AC84AE-C4C0-53AA-8984-51AE84EE7651.dita --- a/Symbian3/SDK/Source/GUID-99AC84AE-C4C0-53AA-8984-51AE84EE7651.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-99AC84AE-C4C0-53AA-8984-51AE84EE7651.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ of available converters. If there is a converter that can do the conversion, then the framework assigns the request to that converter.

    The following diagram shows the File converter framework architecture.

    - +
    API summary diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-99C2E42F-1029-5E32-8446-CAAF29D733BA_d0e240083_href.png Binary file Symbian3/SDK/Source/GUID-99C2E42F-1029-5E32-8446-CAAF29D733BA_d0e240083_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-99C2E42F-1029-5E32-8446-CAAF29D733BA_d0e245042_href.png Binary file Symbian3/SDK/Source/GUID-99C2E42F-1029-5E32-8446-CAAF29D733BA_d0e245042_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9A38894D-98B8-5AFA-A36A-AC8B494EC2CC.dita --- a/Symbian3/SDK/Source/GUID-9A38894D-98B8-5AFA-A36A-AC8B494EC2CC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9A38894D-98B8-5AFA-A36A-AC8B494EC2CC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ gamma function on the input value

  • prints the output.

    • -
    Download

    Click on the following link to download the example: libmexample.zip

    Click: browse to view the example code.

    +
    Download

    Click on the following link to download the example: libmexample.zip

    Click: browse to view the example code.

    Class summary

    The example shows the use of the following API:

    • gamma(double) from the Standard C Maths support library (libm.dll).

      • @@ -33,8 +33,7 @@ use the command line, open a command prompt, and set the current directory to the source code directory of the example. You can then build the example with the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld -build

      How to use bldmake and How to -use abld describe how to use the SBSv1 build tools.

      +build

    • For the emulator, the example builds an executable called libmexample.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9A4543B3-2A79-5604-AE11-5087507C6755_d0e262222_href.png Binary file Symbian3/SDK/Source/GUID-9A4543B3-2A79-5604-AE11-5087507C6755_d0e262222_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9A4543B3-2A79-5604-AE11-5087507C6755_d0e267086_href.png Binary file Symbian3/SDK/Source/GUID-9A4543B3-2A79-5604-AE11-5087507C6755_d0e267086_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9A9654C4-4D7F-485E-8253-B2DB25D3DB78.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-9A9654C4-4D7F-485E-8253-B2DB25D3DB78.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,72 @@ + + + + + +Creating a User-Defined Time Zone +

    This tutorial describes how a device creator creates a user-defined +time zone using CTzUserData.

    The high-level steps +to create a user-defined time zone are described in Procedure section:     + +Create the +TZ rules object using CTzRules::NewL(). + +Use the CTzUserNames::NewL() function to create a TZ names object. + +Connect +to the TZ server using RTz::Connect(). + +Create a +user-defined time zone using CTzUserData::CreateL(). + + +

    An illustration of the procedure is given below. Note +that cleanup stack management and CTzRules object +creation details are omitted for clarity.

    #include <tz.h> // For CTzUserData etc. +#include <…> + +... + +// These strings would typically be supplied by the UI +layer. +_LIT( KTzUserStdName, ”Mountain Standard Time” ); +_LIT( KTzUserShortStdName, ”MST” ); +_LIT( KTzUserDstName, ”Mountain Daylight Time” ); +_LIT( KTzUserShortDstName, ”MDT” ); +_LIT( KTzUserCityName, ”Window Rock” ); +_LIT( KTzUserRegionName, ”America” ); + +// Create TZ rules object. +CTzRules* tzRules = ...; + +// Create TZ names object. +CTzUserNames* tzNames = CTzUserNames::NewL( KTzUserStdName, + KTzUserShortStdName, + KTzUserDstName, + KTzUserShortDstName, + KTzUserCityName, + KTzUserRegionName ); + +// Connect to TZ Server. +RTz tzServer; +User::LeaveIfError( tzServer.Connect() ); + +// Create user-defined TZ. +CTzUserData* tzUserData = CTzUserData::NewL( tzServer ); +CTzId* userTzId = tzUserData->CreateL( *tzRules, *tzNames ); + +...     +     + +Create +a user-defined time zone from an existing time zone +Time +Zone Services Overview + +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9AB5481B-C321-56C9-937D-2397AA80DE8E_d0e304377_href.jpg Binary file Symbian3/SDK/Source/GUID-9AB5481B-C321-56C9-937D-2397AA80DE8E_d0e304377_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9AB5481B-C321-56C9-937D-2397AA80DE8E_d0e310849_href.jpg Binary file Symbian3/SDK/Source/GUID-9AB5481B-C321-56C9-937D-2397AA80DE8E_d0e310849_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9AC6774A-41E9-5298-8696-0A317A09E1E9.dita --- a/Symbian3/SDK/Source/GUID-9AC6774A-41E9-5298-8696-0A317A09E1E9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9AC6774A-41E9-5298-8696-0A317A09E1E9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ and also with the Symbian platform:

    The Librt library interacting with P.I.P.S. and the Symbian platform - +
    APIs

    The following table is a comprehensive list of Librt APIs as per the LSB 3.1 specification:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9AD75103-CD56-5279-B639-5CA2BBF979B5.dita --- a/Symbian3/SDK/Source/GUID-9AD75103-CD56-5279-B639-5CA2BBF979B5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9AD75103-CD56-5279-B639-5CA2BBF979B5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ the other buttons.

    Driver communicates pointer state changes to the Window Server - +

    For a complete list of pointer states, the events that can be sent by the driver, and the associated events that the Window Server sends to the client, see the Pointer @@ -70,7 +70,7 @@ the closeness of the pointer to the screen. Down is extended with substates describing pressing.

    Extension of Up and Down states with substates - +

    The Window Server generates the following events for changes of closeness and pressing:

    • EExitCloseProximity

      • @@ -281,7 +281,7 @@ transitions that are described in the table above.

      Events sent from Window Server to client while the pointer traverses the full cycle of states. - + Advanced diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9BB849A2-8F69-580D-8A52-C7002D919521.dita --- a/Symbian3/SDK/Source/GUID-9BB849A2-8F69-580D-8A52-C7002D919521.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9BB849A2-8F69-580D-8A52-C7002D919521.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Email Overview

      The Email collection provides support for sending and receiving emails using the individual email protocols, such as IMAP4, POP3 and SMTP, and also has support for parsing and generating plain and rich text, MIME and M-HTML format emails.

      Architecture

      The Email collection consists of a set of utilities and MTMs for the POP3, IMAP4 and SMTP messaging protocols.

      Email architecture -
      Autosend

      Autosend is an executable file that is executed by the POP3 and IMAP4 client MTMs if the send on next connection setting is set. This executable makes a request to the SMTP server MTM to send messages associated with the SMTP service related to the POP3 or IMAP4 service, wait for the operation to finish and then exit.

      Server MTM

      A Server MTM provides specific message type storage and transport. It interacts with the Message Server to store and manage entries and provide a transport mechanism.

      Email client MTMs

      Email client MTMs provide client-side APIs (IMCM DLL) for IMAP4, POP3 and SMTP.

      The email client MTMs are used directly by clients to access parts of email messages for display. The CImEmailMessage class provides the functionality used by clients to display email messages, including listing attachments, getting body text and resolving URIs in M-HTML messages.

      Email client utilities

      The email client MTM uses the email client utilities when they are requested to create, reply to and forward messages. The CImEmailOperation class provides the functionality to perform these operations. Each email is represented by a parent message entry with child entries that represent MIME folders and MIME parts. Adding or deleting MIME parts involves navigating the tree of entries and inserting or removing entries as appropriate.

      Email server utilities

      Email server utilities are responsible for generating and parsing of RFC2822 format email messages and providing an API to wrap up a TCP/IP connection to a remote email server.

      Description

      Email messages are represented in a common format whether they are being sent by SMTP and downloaded by POP3 or IMAP4. Messaging clients can use the email client MTMs to create and compose email messages with attachments and a vCard signature. They can reply to or forward email messages. When connecting to a POP3 mailbox, just the header can be downloaded, or the entire message including attachments. However, when connecting to an IMAP4 mailbox, any or all of the following can be downloaded:

      • the header

      • the header and body text

      • the entire message including attachments

      • partial body text where the body text size limit is specified

      • download attachments if the attachment size is less then or equal to attachment size limit

      Messaging clients can access any part of the message for display to the user. Messages can be moved or copied within folders on the local device and, for IMAP4 only, within the mailbox as well.

      Email client MTMs provide APIs that allow configuration information, such as secure or non-secure TCP/IP connection, username, password and message limits to be stored on the local device. Email client MTMs can be commanded to stay online during a client session, or connect and disconnect only when necessary. Operations such as moving, deleting, or sending a message while not connected can be queued for execution when the next connection to the subscriber's mailbox is established.

      Note: Email client MTMs are not responsible for any graphical or user interface associated functionality, such as rendering HTML or images, although they do provide access to images and HTML downloaded to the local device.

      For each email account a pair of services entries is created in the Message Store. For a POP3 account there will be an SMTP service and a POP3 service. For an IMAP4 account there will be an SMTP service and an IMAP4 service. These entries are used to store the settings for the email transport. Each of the service entry has its related ID that is set to the other member of the pair. The SMTP service is invisible, so that the user only sees the POP3 or IMAP4 service entry. Copying a message to the SMTP service causes the SMTP server MTM to attempt to send the message. The POP3 and IMAP4 MTMs provide functionality to synchronise with a remote email server by using the client MTM interface through the InvokeAsync API.

      +
      Autosend

      Autosend is an executable file that is executed by the POP3 and IMAP4 client MTMs if the send on next connection setting is set. This executable makes a request to the SMTP server MTM to send messages associated with the SMTP service related to the POP3 or IMAP4 service, wait for the operation to finish and then exit.

      Server MTM

      A Server MTM provides specific message type storage and transport. It interacts with the Message Server to store and manage entries and provide a transport mechanism.

      Email client MTMs

      Email client MTMs provide client-side APIs (IMCM DLL) for IMAP4, POP3 and SMTP.

      The email client MTMs are used directly by clients to access parts of email messages for display. The CImEmailMessage class provides the functionality used by clients to display email messages, including listing attachments, getting body text and resolving URIs in M-HTML messages.

      Email client utilities

      The email client MTM uses the email client utilities when they are requested to create, reply to and forward messages. The CImEmailOperation class provides the functionality to perform these operations. Each email is represented by a parent message entry with child entries that represent MIME folders and MIME parts. Adding or deleting MIME parts involves navigating the tree of entries and inserting or removing entries as appropriate.

      Email server utilities

      Email server utilities are responsible for generating and parsing of RFC2822 format email messages and providing an API to wrap up a TCP/IP connection to a remote email server.

      Description

      Email messages are represented in a common format whether they are being sent by SMTP and downloaded by POP3 or IMAP4. Messaging clients can use the email client MTMs to create and compose email messages with attachments and a vCard signature. They can reply to or forward email messages. When connecting to a POP3 mailbox, just the header can be downloaded, or the entire message including attachments. However, when connecting to an IMAP4 mailbox, any or all of the following can be downloaded:

      • the header

      • the header and body text

      • the entire message including attachments

      • partial body text where the body text size limit is specified

      • download attachments if the attachment size is less then or equal to attachment size limit

      Messaging clients can access any part of the message for display to the user. Messages can be moved or copied within folders on the local device and, for IMAP4 only, within the mailbox as well.

      Email client MTMs provide APIs that allow configuration information, such as secure or non-secure TCP/IP connection, username, password and message limits to be stored on the local device. Email client MTMs can be commanded to stay online during a client session, or connect and disconnect only when necessary. Operations such as moving, deleting, or sending a message while not connected can be queued for execution when the next connection to the subscriber's mailbox is established.

      Note: Email client MTMs are not responsible for any graphical or user interface associated functionality, such as rendering HTML or images, although they do provide access to images and HTML downloaded to the local device.

      For each email account a pair of services entries is created in the Message Store. For a POP3 account there will be an SMTP service and a POP3 service. For an IMAP4 account there will be an SMTP service and an IMAP4 service. These entries are used to store the settings for the email transport. Each of the service entry has its related ID that is set to the other member of the pair. The SMTP service is invisible, so that the user only sees the POP3 or IMAP4 service entry. Copying a message to the SMTP service causes the SMTP server MTM to attempt to send the message. The POP3 and IMAP4 MTMs provide functionality to synchronise with a remote email server by using the client MTM interface through the InvokeAsync API.

      Email operation sequence diagram -
      Components

      The Email collection constitutes the following components:

      • IMAP4 MTM

      • POP3 MTM

      • SMTP MTM

      Using Email

      Email client applications can use the following functionality provided by the Email collection to:

      • Store emails including MIME headers, RFC2822 headers, attachments, body text and encoding information in the Message Store.

      • Manipulate email messages, for example, adding attachments and replying.

      • Encapsulate the character converters, which are used to convert between standard character sets and Unicode.

      • Store email settings in the central repository.

      • Get progress information for email operations.

      Message Type Module Email Tutorials       \ No newline at end of file +
      Components

      The Email collection constitutes the following components:

      • IMAP4 MTM

      • POP3 MTM

      • SMTP MTM

      Using Email

      Email client applications can use the following functionality provided by the Email collection to:

      • Store emails including MIME headers, RFC2822 headers, attachments, body text and encoding information in the Message Store.

      • Manipulate email messages, for example, adding attachments and replying.

      • Encapsulate the character converters, which are used to convert between standard character sets and Unicode.

      • Store email settings in the central repository.

      • Get progress information for email operations.

      Message Type Module Email Tutorials \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9BF177DF-9E59-5C30-95BA-70A8250579E0_d0e429704_href.png Binary file Symbian3/SDK/Source/GUID-9BF177DF-9E59-5C30-95BA-70A8250579E0_d0e429704_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9BF177DF-9E59-5C30-95BA-70A8250579E0_d0e433504_href.png Binary file Symbian3/SDK/Source/GUID-9BF177DF-9E59-5C30-95BA-70A8250579E0_d0e433504_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9BFF0271-F5C3-45B6-AD4D-9179107F300A.dita --- a/Symbian3/SDK/Source/GUID-9BFF0271-F5C3-45B6-AD4D-9179107F300A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9BFF0271-F5C3-45B6-AD4D-9179107F300A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,9 +14,9 @@

      OpenCProducerConsumerEx is a hybrid application that depicts solution for producer consumer problem using Open C. This application uses main() as an entry point for the application. It uses libc and libpthread

      -
      Download

      Click +

      Download

      Click on the following link to download the example: opencproducerconsumerex.zip

      Click: browse to view the example code.

      -
      Design and +<section id="GUID-7E7C4564-B10E-41F9-8A9D-D8A6C5E9C51C-GENID-1-10-1-13-1-1-5-1-3-1-11-1-13-1-2-3"><title>Design and Implementation

      The following sections provide information about the implementation of the example.

      Capabilities

      The program capability is defined in: ProducerConsumer.mmp (EXE - @@ -44,7 +44,7 @@ (from pthread)

      console I/O APIs

      File APIs of Symbian platform

      Threading APIs of Symbian platform

      -
      Building and +<section id="GUID-67A72761-1D92-46D1-B1C9-7455978BDE4E-GENID-1-10-1-13-1-1-5-1-3-1-11-1-13-1-2-4"><title>Building and Using To build the OpenCProducerConsumerEx application, go to the OpenCProducerConsumerEx\group directory and build the application. The definition for the whole application can be found in the bld.infin diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9C269F45-F160-5A4B-ABF8-896D2A538E3B.dita --- a/Symbian3/SDK/Source/GUID-9C269F45-F160-5A4B-ABF8-896D2A538E3B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9C269F45-F160-5A4B-ABF8-896D2A538E3B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,241 +1,197 @@ - - - - -Advanced Pointer Overview -This is an overview of the Window Server extensions that -support the use of advanced pointers. These extensions enable mobile -devices to respond to events from multiple pointers, including their -proximity and pressure. These extensions are available only in ScreenPlay. - - - - -

      Variant: ScreenPlay. Target audience: Application developers.

      -
      Architecture

      In response to multiple pointer movements, an input driver generates -a pointer event for each touch. The Window Server changes and delivers -the pointer events to the client application, as shown in the following -diagram.

      - Pointer events -

      Pointer-related events move from -the driver to the application. The TRawEvent, TWsEvent and TPointerEvent classes encapsulate the event information.

      -
      Key concepts/terms

      The following terms -are introduced here and are used throughout the advanced pointer documentation:

      - -
      Pointer
      -

      A device that points at the screen, for example, a mouse, pen, -finger, or touchpad.

      - -
      Multiple pointer support
      -

      Handling more than one pointer at the same time.

      -       - -
      Proximity
      -

      Proximity in this context means the distance of the pointer -from the mobile device. Sensors detect the value of the proximity -of the pointer from the mobile device.

      - -
      Pressure
      -

      Pressure in this context is a value that indicates the force -applied to the mobile device by the pointer. Sensors detect the value -of the pressure of the pointer on the mobile device.

      -       -
      -
      Logical model of pointing devices

      A logical -model is used to handle all of the different pointing devices correctly. -In this logical model, the pointer is performing an action when -any of the following scenarios occur:

        -

      • An EButton1Down event is sent to the client.

        • -

      • EDrag events are sent to the client (optional).

        • -

      • An EButton1Up event is sent to the client.

        • -

      Pointing devices can be in one of the following states:

    - - - -State -Description - - - - -

    Out of range

    -

    Not detected by the device's sensors.

    -     - -

    Up

    -

    Detected by sensors, coordinates available, not performing -an action.

    -     - -

    Down

    -

    Detected by sensors, coordinates available, performing an -action (as defined above).

    -     - - -

    The mapping between these states and physical actions -performed by the user vary for different pointing device types (mouse, -finger) and different phone models. Here are two example interpretations -of physical pointing device states:

      -

    • Mouse. An example interpretation by a driver of the physical state of -a mouse is as follows: It is always in the up state except -when the left button is pressed, when it is in the down state. -It is never out of range.

      • -

    • Fingers -with proximity support. The following is an example interpretation -of finger physical states when the device has proximity support (that -is, it can measure the finger's proximity from the screen):

        -

      • Out of range when proximity > 10cm

        • -

      • Up when -1cm < proximity <= 10cm

        • -

      • Down when proximity <= 1cm

        • -

      In this way the finger can perform actions (for example, -press buttons, drag items) without touching the screen.

      • -
    -
    Multiple pointers

    The system handles multiple -pointers at the same time by identifying each one with a number and -sending pointer events separately for each of them. A field (iPointerNumber) in the pointer event classes (TRawEvent and the TAdvancedPointerEvent class which extends TPointerEvent) identifies the pointer for which the event occurred. The -order and frequency of pointer events depends on the driver of the -pointing device.

    On each phone there is a pool of available -pointer numbers, ranging from 0 to HALData::EPointerNumberOfPointers - 1. Every time the driver detects a new pointer coming into the -range of the device, the driver assigns a number from the pool. After -the pointer goes out of the range of the device, the number no longer -identifies that particular pointer and the driver sends TRawEvent::EPointer3DOutOfRange with this -pointer number. The number is then released back to the pool and may -be reused to identify another pointer coming into the device's range.

    -
    Pressure and proximity

    The pressure of -the pointer on the screen is represented as a positive integer. The -proximity of the pointer to the screen is represented as a negative -integer. It is up to the UI Platform to define units of pressure and -proximity, which may be non-linear. In the TRawEvent class, pressure and proximity are expressed in terms of the -Z coordinate of the pointer. The definition of the Z coordinate is -based on the assumption that the pointer is either hovering over the -screen (proximity < 0, pressure = 0) or touching the screen (proximity -= 0, pressure >= 0):

      -

    • If proximity -< 0 and pressure = 0 then the Z coordinate = proximity.

      • -

    • If proximity -= 0 and pressure >= 0 then the Z coordinate = pressure.

      • -
    - Relationships between the pointer proximity, -pressure and z coordinate -
    -
    API summary - - - -API -Description - - - - -

    HALData

    -

    Includes z coordinate, pressure precision and number of -pointers. Also contains threshold values for proximity and pressure.

    -     - -

    TRawEvent

    -

    Includes the pointer number and a structure for proximity -and pressure data.

    -     - -

    RWindowBase

    -

    Enables advanced pointer events for the window.

    -     - -

    TWsEvent

    -

    Supports TAdvancedPointerEvent (derived -from TPointerEvent).

    -     - -

    TPointerEvent

    -

    Includes event types for pressing and closeness.

    -     - -

    TAdvancedPointerEvent

    -

    Inherits from TPointerEvent.

    Provides -capabilities for pressure, proximity and multiple pointers.

    -     - -

    RWsSession

    -

    Provides get and set methods to manipulate threshold values -for proximity and pressure.

    -     - - -
    -
    Typical uses
      -

    • Enabling -many pointers for a window

      Enables multiple pointers -to act on one window.

      • -

    • Enabling -concurrent control of many objects

      Controls many objects -on one or more windows with many pointers.

      • -

    • Getting -z coordinates from TPointerEvent

      Reads the pressure and -proximity values for a pointer.

      • -

    • Pinch zooming

      Enables the user to zoom in and out of data by using two -fingers to pinch an area of the screen. Pinch zooming is normally -used in web-page, map, picture, chart and control applications.

      • -

    • Responding -to high pressure events

      As the pointer state changes, -the pressure value can be checked. When it passes over a threshold -value, the Window Server responds appropriately to the client.

      • -
    - - -Pointer States and Event Communication - -Advanced Pointer Tutorial - - - + + + + + +Advanced Pointer Overview This is an overview of the Window Server extensions that +support the use of advanced pointers. These extensions enable mobile +devices to respond to events from multiple pointers, including their +proximity and pressure. These extensions are available only in ScreenPlay. +

    Variant: ScreenPlay. Target audience: Application developers.

    +
    Architecture

    In response to multiple pointer movements, an input driver generates +a pointer event for each touch. The Window Server changes and delivers +the pointer events to the client application, as shown in the following +diagram.

    + Pointer events + +

    Pointer-related events move from the driver to the application. +The TRawEvent, TWsEvent and TPointerEvent classes encapsulate the event information.

    +
    Key concepts/terms

    The following terms +are introduced here and are used throughout the advanced pointer documentation:

    + +
    Pointer
    +

    A device that points at the screen, for example, a mouse, pen, +finger, or touchpad.

    +     + +
    Multiple pointer support
    +

    Handling more than one pointer at the same time.

    +     + +
    Proximity
    +

    Proximity in this context means the distance of the pointer +from the mobile device. Sensors detect the value of the proximity +of the pointer from the mobile device.

    +     + +
    Pressure
    +

    Pressure in this context is a value that indicates the force +applied to the mobile device by the pointer. Sensors detect the value +of the pressure of the pointer on the mobile device.

    +     +
    +
    Logical model of pointing devices

    A logical +model is used to handle all of the different pointing devices correctly. +In this logical model, the pointer is performing an action when +any of the following scenarios occur:

      +

    • An EButton1Down event is sent to the client.

      • +

    • EDrag events are sent to the client (optional).

      • +

    • An EButton1Up event is sent to the client.

      • +

    Pointing devices can be in one of the following states:

    + + + +State +Description + + + + +

    Out of range

    +

    Not detected by the device's sensors.

    +     + +

    Up

    +

    Detected by sensors, coordinates available, not performing +an action.

    +     + +

    Down

    +

    Detected by sensors, coordinates available, performing an +action (as defined above).

    +     + + +

    The mapping between these states and physical actions +performed by the user vary for different pointing device types (mouse, +finger) and different phone models. Here are two example interpretations +of physical pointing device states:

      +

    • Mouse. An example interpretation by a driver of the physical state of +a mouse is as follows: It is always in the up state except +when the left button is pressed, when it is in the down state. +It is never out of range.

      • +

    • Fingers +with proximity support. The following is an example interpretation +of finger physical states when the device has proximity support (that +is, it can measure the finger's proximity from the screen):

        +

      • Out of range when proximity > 10cm

        • +

      • Up when +1cm < proximity <= 10cm

        • +

      • Down when proximity <= 1cm

        • +

      In this way the finger can perform actions (for example, +press buttons, drag items) without touching the screen.

      • +
    +
    Multiple pointers

    The system handles multiple +pointers at the same time by identifying each one with a number and +sending pointer events separately for each of them. A field (iPointerNumber) in the pointer event classes (TRawEvent and the TAdvancedPointerEvent class which extends TPointerEvent) identifies the pointer for which the event +occurred. The order and frequency of pointer events depends on the +driver of the pointing device.

    On each phone there is a pool +of available pointer numbers, ranging from 0 to HALData::EPointerNumberOfPointers - 1. Every time the driver detects a new pointer coming into the +range of the device, the driver assigns a number from the pool. After +the pointer goes out of the range of the device, the number no longer +identifies that particular pointer and the driver sends TRawEvent::EPointer3DOutOfRange with this pointer number. The number is then released back to the +pool and may be reused to identify another pointer coming into the +device's range.

    +
    Pressure and proximity

    The pressure of +the pointer on the screen is represented as a positive integer. The +proximity of the pointer to the screen is represented as a negative +integer. It is up to the UI Platform to define units of pressure and +proximity, which may be non-linear. In the TRawEvent class, pressure and proximity are expressed in terms of the Z coordinate +of the pointer. The definition of the Z coordinate is based on the +assumption that the pointer is either hovering over the screen (proximity +< 0, pressure = 0) or touching the screen (proximity = 0, pressure +>= 0):

      +

    • If proximity +< 0 and pressure = 0 then the Z coordinate = proximity.

      • +

    • If proximity += 0 and pressure >= 0 then the Z coordinate = pressure.

      • +
    + Relationships between the pointer proximity, +pressure and z coordinate + +
    +
    API summary + + + +API +Description + + + + +

    HALData

    +

    Includes z coordinate, pressure precision and number of +pointers. Also contains threshold values for proximity and pressure.

    +     + +

    TRawEvent

    +

    Includes the pointer number and a structure for proximity +and pressure data.

    +     + +

    RWindowBase

    +

    Enables advanced pointer events for the window.

    +     + +

    TWsEvent

    +

    Supports TAdvancedPointerEvent (derived +from TPointerEvent).

    +     + +

    TPointerEvent

    +

    Includes event types for pressing and closeness.

    +     + +

    TAdvancedPointerEvent

    +

    Inherits from TPointerEvent.

    Provides +capabilities for pressure, proximity and multiple pointers.

    +     + +

    RWsSession

    +

    Provides get and set methods to manipulate threshold values +for proximity and pressure.

    +     + + +
    +
    Typical uses
      +

    • Enabling +many pointers for a window

      Enables multiple pointers +to act on one window.

      • +

    • Enabling +concurrent control of many objects

      Controls many objects +on one or more windows with many pointers.

      • +

    • Getting +z coordinates from TPointerEvent

      Reads the pressure and +proximity values for a pointer.

      • +

    • Pinch zooming

      Enables the user to zoom in and out of data by using two +fingers to pinch an area of the screen. Pinch zooming is normally +used in web-page, map, picture, chart and control applications.

      • +

    • Responding +to high pressure events

      As the pointer state changes, +the pressure value can be checked. When it passes over a threshold +value, the Window Server responds appropriately to the client.

      • +
    +     +Pointer +States and Event Communication +Advanced +Pointer Tutorial +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9C51D27D-BEDB-59D1-8F0E-8426B8FF2230.dita --- a/Symbian3/SDK/Source/GUID-9C51D27D-BEDB-59D1-8F0E-8426B8FF2230.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9C51D27D-BEDB-59D1-8F0E-8426B8FF2230.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Descriptors

    Descriptors are the classes that Symbian platform C++ uses to manage strings. They are fundamental to the Symbian platform, and an excellent example of the difference of approach between non-OO and OO designs.

    Overview

    In C, a string such as

    char* hello="hello";

    causes some memory to be set aside containing the six characters 'h', 'e', 'l', 'l', 'o', '\0'. A function such as strlen() works by scanning the bytes starting from the beginning, and counting until it reaches the trailing null character. If you wish to extend the string, you need to know how much memory is allocated to it.

    In Symbian platform C++ however, strings are managed using a family of classes called descriptors. The abstract descriptor classes define common interfaces for all descriptor classes. Buffer, pointer, and heap descriptor classes provide implementations of the abstract descriptor interfaces, and provide different methods of storing the data.

    Abstract descriptors

    We can represent the basic requirements for strings by two abstract classes: TDesC and TDes.

    TDesC is a constant, or non-modifiable, descriptor. It has an address and a length. Using a class like this, you can do any manipulations to a string, provided they do not alter the data. As a consequence, the TDesC class has many non-modifying functions.

    TDes is a modifiable descriptor: it has, in addition, a maximum length. This allows the data to be manipulated, extended or contracted, provided it does not exceed the maximum length. As a consequence, TDes has many modifying functions which allow string manipulation.

    It is a fundamental aspect of descriptors that they do not allow modification to exceed the allocated length. Other classes are provided to allow this, for instance CBufBase and derived classes. If a TDes function causes overflow, a panic will occur.

    Because TDesC and TDes define all the functions needed to access and manipulate string and memory data, many functions take a const TDesC& parameter if they need to access data, or a TDes& parameter if they need to modify it.

    Pointer descriptor

    The abstract descriptor classes have several implementations. The simplest are pointer descriptors.

    TPtrC just has length and address: its representation needs just two machine words. A TPtrC may be set up to describe any existing data. A TPtr adds a maximum length, and so may be used to describe a buffer which is perhaps only partially allocated.

    TPtrC and TPtr are somewhat like C char* pointers. But because the length is contained in the descriptor itself, there is no need to scan for trailing null characters, or to allocate room for them.

    Buffer descriptors

    Buffer descriptors, TBufC and TBuf, contain their data as part of themselves, like char[] arrays in C.

    These descriptor classes exploit C++'s template mechanism, using an integer parameter to specify the length.

    Heap descriptors

    Heap descriptors contain their data in heap cell. These are used when you do not know the length required for a buffer at build time, but decide it at run-time. This is like (char*) malloc(length+1) in C.

    The non-modifiable heap descriptor type, HBufC, is allocated on the heap. They are always referred to through an HBufC*, rather than an HBufC directly:

    The modifiable heap descriptor type, RBuf, can be created on the stack, but contains a pointer to data on the heap. This is similar to a TPtr pointer descriptor, but an RBuf owns the data that it points to, and is responsible for freeing the memory when it is closed. An RBuf object can allocate its own buffer, take ownership of a pre-existing section of allocated memory, or take ownership of a pre-existing heap descriptor.

    RBuf is easier to use than HBufC, so should generally be preferred. RBuf was only introduced in version 8.0, however, so older code and APIs use HBufC.

    Descriptor classes

    The complete descriptor class hierarchy is

    It represents an elegant use of OO. The TBufCBase class is used as an implementation convenience, which is also a frequent OO idiom (though it should be used with caution).

    Versions of the descriptors classes are available that store 16-bit or 8-bit wide items. When using descriptors for strings, you should always use classes such as TDes etc. These classes are typedef ed to use the 16-bit implementations, such as TDes16 etc.

    Because descriptors may contain any data, including nulls, they may also be used to refer to byte data and general buffers. In these contexts, you should use the 8-bit implementations, such as TDes8, directly.

    \ No newline at end of file +Descriptors

    Descriptors are the classes that Symbian platform C++ uses to manage strings. They are fundamental to the Symbian platform, and an excellent example of the difference of approach between non-OO and OO designs.

    Overview

    In C, a string such as

    char* hello="hello";

    causes some memory to be set aside containing the six characters 'h', 'e', 'l', 'l', 'o', '\0'. A function such as strlen() works by scanning the bytes starting from the beginning, and counting until it reaches the trailing null character. If you wish to extend the string, you need to know how much memory is allocated to it.

    In Symbian platform C++ however, strings are managed using a family of classes called descriptors. The abstract descriptor classes define common interfaces for all descriptor classes. Buffer, pointer, and heap descriptor classes provide implementations of the abstract descriptor interfaces, and provide different methods of storing the data.

    Abstract descriptors

    We can represent the basic requirements for strings by two abstract classes: TDesC and TDes.

    TDesC is a constant, or non-modifiable, descriptor. It has an address and a length. Using a class like this, you can do any manipulations to a string, provided they do not alter the data. As a consequence, the TDesC class has many non-modifying functions.

    TDes is a modifiable descriptor: it has, in addition, a maximum length. This allows the data to be manipulated, extended or contracted, provided it does not exceed the maximum length. As a consequence, TDes has many modifying functions which allow string manipulation.

    It is a fundamental aspect of descriptors that they do not allow modification to exceed the allocated length. Other classes are provided to allow this, for instance CBufBase and derived classes. If a TDes function causes overflow, a panic will occur.

    Because TDesC and TDes define all the functions needed to access and manipulate string and memory data, many functions take a const TDesC& parameter if they need to access data, or a TDes& parameter if they need to modify it.

    Pointer descriptor

    The abstract descriptor classes have several implementations. The simplest are pointer descriptors.

    TPtrC just has length and address: its representation needs just two machine words. A TPtrC may be set up to describe any existing data. A TPtr adds a maximum length, and so may be used to describe a buffer which is perhaps only partially allocated.

    TPtrC and TPtr are somewhat like C char* pointers. But because the length is contained in the descriptor itself, there is no need to scan for trailing null characters, or to allocate room for them.

    Buffer descriptors

    Buffer descriptors, TBufC and TBuf, contain their data as part of themselves, like char[] arrays in C.

    These descriptor classes exploit C++'s template mechanism, using an integer parameter to specify the length.

    Heap descriptors

    Heap descriptors contain their data in heap cell. These are used when you do not know the length required for a buffer at build time, but decide it at run-time. This is like (char*) malloc(length+1) in C.

    The non-modifiable heap descriptor type, HBufC, is allocated on the heap. They are always referred to through an HBufC*, rather than an HBufC directly:

    The modifiable heap descriptor type, RBuf, can be created on the stack, but contains a pointer to data on the heap. This is similar to a TPtr pointer descriptor, but an RBuf owns the data that it points to, and is responsible for freeing the memory when it is closed. An RBuf object can allocate its own buffer, take ownership of a pre-existing section of allocated memory, or take ownership of a pre-existing heap descriptor.

    RBuf is easier to use than HBufC, so should generally be preferred. RBuf was only introduced in version 8.0, however, so older code and APIs use HBufC.

    Descriptor classes

    The complete descriptor class hierarchy is

    It represents an elegant use of OO. The TBufCBase class is used as an implementation convenience, which is also a frequent OO idiom (though it should be used with caution).

    Versions of the descriptors classes are available that store 16-bit or 8-bit wide items. When using descriptors for strings, you should always use classes such as TDes etc. These classes are typedef ed to use the 16-bit implementations, such as TDes16 etc.

    Because descriptors may contain any data, including nulls, they may also be used to refer to byte data and general buffers. In these contexts, you should use the 8-bit implementations, such as TDes8, directly.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9C57F0C6-E2E3-58A2-907D-924A7E22EA97-GENID-1-13-1-1-5-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-9C57F0C6-E2E3-58A2-907D-924A7E22EA97-GENID-1-13-1-1-5-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,94 +0,0 @@ - - - - - -Resource -compiler tool: rcomp -
    Purpose

    The -resource compiler, rcomp, compiles source rss resource -files into a rsc resource data file which can be used -by applications, and a rsg resource header file. The -operation of the resource compiler is usually wrapped in an abld batch -file. That provides the most commonly used rcomp functionality, -but does not provide some of the debugging options available directly through rcomp.

    Note: -From Symbian^4 onwards, rcomp supports long strings and -supplementary characters (not included in code point range of BMP) of the -range 0x10000 to 0x10ffff in rss files.

    -
    Command line syntaxrcomp [—v] [—p] [—l] -[—force] [—u] [—o DataOutputFile] [-{uid2,uid3 }] -[—h HeaderOutputFile] [—s SourceFileName] -[—i BaseInputFileName]

    Arguments

    - - - -

    -v

    -

    verbose output.

    -     - -

    -p

    -

    parser debugging

    -     - -

    -l

    -

    Check localisation comments

    -     - -

    -force

    -

    Emit warnings if the localisation comment tags are not present

    -     - -

    -u

    -

    generate Unicode resource binary

    -     - -

    -o DataOutputFile

    -

    Specify full path and name for data output file DataOutputFile. -If this is not specified, no data output file is created.

    -     - -

    [-{uid2,uid3 }]

    -

    Second and third UIDs for the resource file

    -     - -

    -h HeaderOutputFile

    -

    Specify header output file HeaderOutputFile; -this is the name only, and does not include the path. If this is not specified, -no header output file is created.

    -     - -

    -s SourceFileName

    -

    Specify resource compiler source file SourceFileName (output -of pre-processor BaseInputFileName.rpp). If not specified, -or specified as -s-, source is read from the standard input.

    -     - -

    -i BaseInputFileName

    -

    The file given to the pre-processor

    -     - - -

    Output files

    - - - -

    DataOutputFile

    -

    The resource data referred to by the application at run-time. Note -that the generated file can have any name. However, before the resource file -can be used it must be renamed to have an extension .rsc.

    -     - -

    HeaderOutputFile

    -

    The generated header file, which contains #define statements -for each resource defined in the source file.

    -     - - -
    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9C837724-B00E-58F4-8B71-53ECDBFF5CCE_d0e357261_href.png Binary file Symbian3/SDK/Source/GUID-9C837724-B00E-58F4-8B71-53ECDBFF5CCE_d0e357261_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9C837724-B00E-58F4-8B71-53ECDBFF5CCE_d0e376410_href.png Binary file Symbian3/SDK/Source/GUID-9C837724-B00E-58F4-8B71-53ECDBFF5CCE_d0e376410_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9CC5E096-74FB-59AB-BAB9-A5486B961B7D_d0e262298_href.png Binary file Symbian3/SDK/Source/GUID-9CC5E096-74FB-59AB-BAB9-A5486B961B7D_d0e262298_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9CC5E096-74FB-59AB-BAB9-A5486B961B7D_d0e267162_href.png Binary file Symbian3/SDK/Source/GUID-9CC5E096-74FB-59AB-BAB9-A5486B961B7D_d0e267162_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D2752D1-4153-5978-A7B8-4C3F860B6B87_d0e264555_href.png Binary file Symbian3/SDK/Source/GUID-9D2752D1-4153-5978-A7B8-4C3F860B6B87_d0e264555_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D2752D1-4153-5978-A7B8-4C3F860B6B87_d0e269418_href.png Binary file Symbian3/SDK/Source/GUID-9D2752D1-4153-5978-A7B8-4C3F860B6B87_d0e269418_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D3637D4-43BD-51ED-B4BC-1F234F09E24B.dita --- a/Symbian3/SDK/Source/GUID-9D3637D4-43BD-51ED-B4BC-1F234F09E24B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9D3637D4-43BD-51ED-B4BC-1F234F09E24B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -182,7 +182,7 @@ stack->AddToStack(*item); }

    as the following shows:

    Example singly linked list - +
    Removing elements from list

    The following code removes each CItem element diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D5641BC-226B-538F-B805-48511781B7C1_d0e334781_href.jpg Binary file Symbian3/SDK/Source/GUID-9D5641BC-226B-538F-B805-48511781B7C1_d0e334781_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D5641BC-226B-538F-B805-48511781B7C1_d0e341247_href.jpg Binary file Symbian3/SDK/Source/GUID-9D5641BC-226B-538F-B805-48511781B7C1_d0e341247_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D6C086F-7621-5522-AE0B-81CBD5E99125.dita --- a/Symbian3/SDK/Source/GUID-9D6C086F-7621-5522-AE0B-81CBD5E99125.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9D6C086F-7621-5522-AE0B-81CBD5E99125.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,6 +13,6 @@ void Scale(TRequestStatus* aRequestStatus, CFbsBitmap& aBitmap, const TSize& aDestinationSize, TBool aMaintainAspectRatio = ETrue);

    If two CFbsBitmap objects are specified in the scale operation, the dimensions of the destination object are used as the rescaling factors, subject to the aspect ratio setting (described below).

    If only the one CFbsBitmap object is specified in the scale operation, the scaling factor is taken from TSize subject to the aspect ratio setting.

    The aspect ratio is maintained if aMaintainAspectRatio is ETrue. If the ratio is used, then the image is rescaled to the smaller of the horizontal and vertical scaling factors. This is best explained by use of an example.

    In this example, the source image is 50 pixels wide by 150 pixels high (an aspect ratio of 1:3), aMaintainAspectRatio is set to ETrue, and the proposed rescaling is to 75 pixels wide by 300 high. Applying this ratio to the smaller of the horizontal and vertical factors means using a new value for the larger rescaling factor so that the aspect ratio matches that of the source image. The smaller value is 75 pixels, the aspect ratio required is 1:3 so the larger value will be 75*3 which is 225. The image will be rescaled to 75 wide by 225 high.

    Bitmap Transformation Example - Bitmap rotation

    There are two variants of the CBitmapScaler::Rotate() function. The first performs a rotational action on an image contained in one CFbsBitmap object and places the result in another object. The second variant performs a rotational action on an image contained in a CFbsBitmap object and places the result back in the same object. Valid rotational increments are specified in CBitmapRotator::TRotationAngle.

    Note: CBitmapScaler::Rotate() does not support user specified rotational angles. The only values allowed are those specified in CBitmapRotator::TRotationAngle.

    void Rotate(TRequestStatus* aRequestStatus, CFbsBitmap& aSrcBitmap, CFbsBitmap& aTgtBitmap, TRotationAngle aAngle); void Rotate(TRequestStatus* aRequestStatus, CFbsBitmap& aBitmap, TRotationAngle aAngle); -

    ERotation90DegreesClockwise

    ERotation180DegreesClockwise

    ERotation270DegreesClockwise

    EMirrorHorizontalAxis

    EMirrorVerticalAxis

    Imaging Frameworks overview Bitmap Transform Library +

    ERotation90DegreesClockwise

    ERotation180DegreesClockwise

    ERotation270DegreesClockwise

    EMirrorHorizontalAxis

    EMirrorVerticalAxis

    Imaging Frameworks overview Bitmap Transform Library Overview Bitmap Transform Library Guide Enhanced Features for Encoder and Decoder Tutorial \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D6D07D3-A93C-5290-AC08-15750AD34802_d0e402571_href.png Binary file Symbian3/SDK/Source/GUID-9D6D07D3-A93C-5290-AC08-15750AD34802_d0e402571_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9D6D07D3-A93C-5290-AC08-15750AD34802_d0e406371_href.png Binary file Symbian3/SDK/Source/GUID-9D6D07D3-A93C-5290-AC08-15750AD34802_d0e406371_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9DCAB1DC-D085-576C-A0B9-713E3BF2CAD5_d0e210051_href.png Binary file Symbian3/SDK/Source/GUID-9DCAB1DC-D085-576C-A0B9-713E3BF2CAD5_d0e210051_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9DCAB1DC-D085-576C-A0B9-713E3BF2CAD5_d0e215058_href.png Binary file Symbian3/SDK/Source/GUID-9DCAB1DC-D085-576C-A0B9-713E3BF2CAD5_d0e215058_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9DD43E77-FB3D-5931-899B-F17198F726D0_d0e272117_href.jpg Binary file Symbian3/SDK/Source/GUID-9DD43E77-FB3D-5931-899B-F17198F726D0_d0e272117_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9DD43E77-FB3D-5931-899B-F17198F726D0_d0e276963_href.jpg Binary file Symbian3/SDK/Source/GUID-9DD43E77-FB3D-5931-899B-F17198F726D0_d0e276963_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E0C8892-E67F-4DC9-8253-2F65611AD4C6_d0e66389_href.png Binary file Symbian3/SDK/Source/GUID-9E0C8892-E67F-4DC9-8253-2F65611AD4C6_d0e66389_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E0C8892-E67F-4DC9-8253-2F65611AD4C6_d0e66532_href.png Binary file Symbian3/SDK/Source/GUID-9E0C8892-E67F-4DC9-8253-2F65611AD4C6_d0e66532_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E12593C-38EF-5052-A2E8-0AB25EEFF4D0_d0e304473_href.jpg Binary file Symbian3/SDK/Source/GUID-9E12593C-38EF-5052-A2E8-0AB25EEFF4D0_d0e304473_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E12593C-38EF-5052-A2E8-0AB25EEFF4D0_d0e310945_href.jpg Binary file Symbian3/SDK/Source/GUID-9E12593C-38EF-5052-A2E8-0AB25EEFF4D0_d0e310945_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E3D71A2-34FA-5A66-B0B9-550816021D79_d0e356932_href.png Binary file Symbian3/SDK/Source/GUID-9E3D71A2-34FA-5A66-B0B9-550816021D79_d0e356932_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E3D71A2-34FA-5A66-B0B9-550816021D79_d0e385925_href.png Binary file Symbian3/SDK/Source/GUID-9E3D71A2-34FA-5A66-B0B9-550816021D79_d0e385925_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E705383-5D3F-45D9-82F7-EB76112F2800_d0e52568_href.png Binary file Symbian3/SDK/Source/GUID-9E705383-5D3F-45D9-82F7-EB76112F2800_d0e52568_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E705383-5D3F-45D9-82F7-EB76112F2800_d0e52711_href.png Binary file Symbian3/SDK/Source/GUID-9E705383-5D3F-45D9-82F7-EB76112F2800_d0e52711_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E83A253-3C7F-58E9-94FE-EC127BE9C026.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-9E83A253-3C7F-58E9-94FE-EC127BE9C026.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Transaction Notifications
    Overview

    Database events are not sent to observers during a transaction. Instead, they are queued by the server and only sent once the transaction is committed. If the transaction is cancelled (if a rollback occurs) then none of the queued events will be sent to observers apart from the EContactDbObserverEventRollback event.

    Transaction Related APIs

    The behaviour described above comes into effect when using the following APIs:

    • void CContactDatabase::DatabaseBeginL(…)

    • void CContactDatabase::DatabaseBeginLC(…)

    • void CContactDatabase::DatabaseCommitL(…)

    • void CContactDatabase::DatabaseCommitLP(…)

    • void CContactDatabase::DeleteContactsL(…)

    • void CContactDatabase::DatabaseRollback()

    Implementation Considerations

    A maximum of 1000 database events will be queued during a transaction. If there are more events than this then the queued events will be discarded. When the transaction is committed the EContactDbObserverEventUnknownChanges event will be sent to observers instead.

    It is important to note that in the previous version of the Contacts Model database events were sent to observers as they occurred during a transaction. The new model behaviour is more appropriate since, when a rollback occurs, there is no point in receiving events for operations which never actually happened (that is, were not committed).

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E9C00E1-00A2-5248-946B-D3AE182F44EC_d0e278090_href.jpg Binary file Symbian3/SDK/Source/GUID-9E9C00E1-00A2-5248-946B-D3AE182F44EC_d0e278090_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9E9C00E1-00A2-5248-946B-D3AE182F44EC_d0e282929_href.jpg Binary file Symbian3/SDK/Source/GUID-9E9C00E1-00A2-5248-946B-D3AE182F44EC_d0e282929_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9EE78D5A-32BC-5E0F-9139-AF00CDB95CC1.dita --- a/Symbian3/SDK/Source/GUID-9EE78D5A-32BC-5E0F-9139-AF00CDB95CC1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9EE78D5A-32BC-5E0F-9139-AF00CDB95CC1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,121 @@ --> -How to use the audio tone player utility

    The Audio Tone Player, provided by the class CMdaAudioToneUtility, has an interface for generating the following tones on all audio capable devices. Using this class you can play the following tones:

    • Single tone of a specified duration and frequency

    • Dual Tone Multi Frequency (DTMF) strings

    • Sequences of tones held in files or descriptors

    • Predefined (fixed) sequences of tones held in any mobile equipment

    Client applications such as ringtone applications, use CMdaAudioToneUtility to generate the tones they produce. The tone player in turn uses MMF for playing sounds and is also credited for interfacing with the audio hardware. An active scheduler is needed for all the clients applications for the use of active objects and callbacks.

    Using the tone player

    The tone player provides a simple interface to generate single and multiple tones. Once the tone player object has been constructed, multiple tones and tone sequences can be played without having to create new instances of the object.

    Using the tone player typically involves the following steps:

    - Tone Player Utility -

    1. Constructing a tone player

    2. Preparing a tone player

    3. Playing a tone

    4. Cancelling a tone

    5. Retrieving a custom interface

    Constructing a tone player

    The CMdaAudioToneUtility object can be constructed using the NewL() member function. There are two versions of this constructor function:

    • create a tone player with default priority settings:

      static CMdaAudioToneUtility* NewL(MMdaAudioToneObserver& aObserver, CMdaServer* aServer=NULL);

    • create a tone player with your own settings:

      static CMdaAudioToneUtility* NewL(MMdaAudioToneObserver& aObserver, CMdaServer* aServer, TInt aPriority, -TMdaPriorityPreference aPref=EMdaPriorityPreferenceTimeAndQuality);

    Both functions pass a reference of the MMdaAudioToneObserver object to the tone player. The MMdaAudioToneObserver is an observer interface to notifications from the member functions Prepare, Play, and, CancelPlay callback functions.

    Preparing a tone player

    Once the tone player object is created, it has to be prepared to play a tone or a DTMF string. use one of the following prepare member functions to get it ready for playing the corresponding tone.

    • PrepareToPlayTone() - to play a single tone of a fixed frequency (Hz) and duration (microseconds). For example:

      virtual void PrepareToPlayTone(TInt aFrequency, const TTimeIntervalMicroSeconds& aDuration);

    • PrepareToPlayDTMFString() - to play a DTMF string held in a descriptor. For example:

      virtual void PrepareToPlayDTMFString(const TDesC& aDTMF);

    • PrepareToPlayFileSequence() - to play a sequence of non-DTMF tones held in a file. For example:

      virtual void PrepareToPlayFileSequence(const TDesC& aFilename);

    • PrepareToPlayDesSequence() - to play a sequence of non-DTMF tones held in a descriptor. For example:

      virtual void PrepareToPlayDesSequence(const TDesC8& aSequence);

    • PrepareToPlayFixedSequence() - to play a sequence of non-DTMF tones stored on the mobile equipment. For example:

      virtual void PrepareToPlayFixedSequence(TInt aSequenceNumber);

    • PrepareToPlayDualTone() - to play a dual tone. For example:

      void PrepareToPlayDualTone(TInt aFrequencyOne, TInt aFrequencyTwo, const TTimeIntervalMicroSeconds& aDuration);

      The two tones, aFrequencyOne and aFrequencyTwo, are measured in Hz, and the duration of the tone, aDuration, is measured in microseconds.

    All the prepare member functions are asynchronous. In response to each, CMdaAudioToneUtility creates a CMMFToneConfig derived object that stores the data for the type of tone to play.

    On completion of a prepare, the observer function MMdaAudioToneObserver::MatoPrepareComplete() is called, indicating the success or failure of the prepare operation. If successful you can play the tone.

    You can cancel any prepare function using CancelPrepare() (the observer callback function is not called on completion of the cancel).

    Playing a tone

    Once the player is prepared successfully, certain configurations can be done before playing the tone as listed below:

    • Volume() and SetVolume() - This retrieves the current volume settings and sets to a new value specified by the user respectively.

    • GetBalanceL() and SetBalanceL() - This retrieves the current balance of the audio device and sets the audio balance specified by the user respectively..

    • SetPriority() - This sets the priority of the audio device. The priority is defined to arbitrate between multiple objects trying to access the controller at the same time.

    • SetVolumeRamp() - This defines the period over which the volume level is to rise (in microseconds) smoothly from zero to the specified volume level. A value of 0 causes the tone to be played at the SetVolume() level for the full duration of the playback. A value that is longer than the duration of the tone sequence means that the tone never reaches the specified volume.

      virtual void SetVolumeRamp(const TTimeIntervalMicroSeconds &aRampDuration);

    • SetDTMFLengths() - This alters the duration of DTMF tone, the gaps between two DTMF tones, and the pauses in microseconds.

    • FixedSequenceCount() - This returns the number of available pre-defined tone sequences, the number always being greater than zero.

    • FixedSequenceName() - This returns the name of the specified fixed tone sequence.

    Upon successful configuration, the Play() can be called as shown below.

    Play() - plays the tone, DTMF or tone sequence specified by the prepare statement. For example:

    virtual void Play();

    Here, the tone player uses the Play() from the audio player utility to play the tone.

    This function is asynchronous. It retrieves the details of the type of tone to play from the previous Prepare statement. When the tone has been played to completion, the observer callback function MMdaAudioToneObserver::MatoPlayComplete() is called, indicating the success or failure of the play operation. The play operation can be cancelled by calling the CancelPlay() member function.

    Playing the tone or DTMF string can be customised using the following member functions as mentioned below:

    • SetRepeats() - sets the number of times the tone sequence (plus an optional trailing silent period, measured in microseconds) is repeated during the play operation. For example:

      virtual void SetRepeats(TInt aRepeatNumberOfTimes, const TTimeIntervalMicroSeconds &aTrailingSilence);

      You can repeat the tone sequence indefinitely by setting aRepeatNumberOfTimes to KMdaRepeatForever.

    • State() - returns the current state of the tone player (an enum):

      • EMdaAudioToneUtilityNotReady - not prepared to play a tone

      • EMdaAudioToneUtilityPrepared - prepared and ready to play a tone

      • EMdaAudioToneUtilityPlaying - currently playing a tone

      For example:

      virtual TMdaAudioToneUtilityState State();

    To play another tone or sequence, either wait for MMdaAudioToneObserver::MatoPlayComplete() callback to be issued when the current tone or DTMF string completes playing, or use CancelPlay() and then issue the relevant prepare statement. The Play() function following the prepare statement plays the tone or DTMF string based on the previously issued prepare statement.

    Cancelling a tone

    CancelPlay() - cancels the tone, DTMF, or tone sequence currently playing. For example:

    virtual void CancelPlay();

    The observer callback function is not called on completion of the cancel.

    Retrieving a custom interface

    To retrieve a custom interface to the underlying device, use the CustomInterface() member function. For example:

    IMPORT_C TAny *CustomInterface(TUid aInterfaceId);

    aInterfaceId is the UID of the interface function required.

    The function returns a pointer to the interface implementation, or NULL if the device does not implement the interface requested. You must cast the return value to the correct type.

    See Also

    How to use the audio player utility

    How to use the audio convert utility

    How to use audio recorder utility

    \ No newline at end of file +How to use the audio tone player utility +

    The Audio Tone Player, provided by the class CMdaAudioToneUtility, has an interface for generating the following tones on all audio +capable devices. Using this class you can play the following tones:

    +
      +

    • Single tone +of a specified duration and frequency

      • +

    • Dual Tone Multi +Frequency (DTMF) strings

      • +

    • Sequences of +tones held in files or descriptors

      • +

    • Predefined (fixed) +sequences of tones held in any mobile equipment

      • +
    +

    Client applications such as ringtone applications, use CMdaAudioToneUtility to generate the tones they produce. +The tone player in turn uses MMF for playing sounds and is also credited +for interfacing with the audio hardware. An active scheduler is needed +for all the clients applications for the use of active objects and +callbacks.

    +
    Using +the tone player

    The tone player provides a simple interface +to generate single and multiple tones. Once the tone player object +has been constructed, multiple tones and tone sequences can be played +without having to create new instances of the object.

    Using +the tone player typically involves the following steps:

    + Tone Player Utility + +
      +

    1. Constructing a tone player

      2. +

    2. Preparing a tone player

      3. +

    3. Playing a tone

      4. +

    4. Cancelling a tone

      5. +

    5. Retrieving a custom interface

      6. +

    Constructing a tone +player

    The CMdaAudioToneUtility object +can be constructed using the NewL() member function. +There are two versions of this constructor function:

      +

    • create a tone +player with default priority settings:

      static CMdaAudioToneUtility* NewL(MMdaAudioToneObserver& aObserver, CMdaServer* aServer=NULL);
      • +

    • create a tone +player with your own settings:

      static CMdaAudioToneUtility* NewL(MMdaAudioToneObserver& aObserver, CMdaServer* aServer, TInt aPriority, +TMdaPriorityPreference aPref=EMdaPriorityPreferenceTimeAndQuality);
      • +

    Both functions pass a reference of the MMdaAudioToneObserver object to the tone player. The MMdaAudioToneObserver is an observer interface to notifications from the member functions Prepare, Play, and, CancelPlay callback functions.

    Preparing a tone +player

    Once the tone player object is created, it has +to be prepared to play a tone or a DTMF string. use one of the following +prepare member functions to get it ready for playing the corresponding +tone.

      +

    • PrepareToPlayTone() - to play a single tone of a fixed frequency (Hz) and duration (microseconds). +For example:

      virtual void PrepareToPlayTone(TInt aFrequency, const TTimeIntervalMicroSeconds& aDuration);
      • +

    • PrepareToPlayDTMFString() - to play a DTMF string held in a descriptor. For example:

      virtual void PrepareToPlayDTMFString(const TDesC& aDTMF);
      • +

    • PrepareToPlayFileSequence() - to play a sequence of non-DTMF tones held in a file. For example:

      virtual void PrepareToPlayFileSequence(const TDesC& aFilename);
      • +

    • PrepareToPlayDesSequence() - to play a sequence of non-DTMF tones held in a descriptor. For +example:

      virtual void PrepareToPlayDesSequence(const TDesC8& aSequence);
      • +

    • PrepareToPlayFixedSequence() - to play a sequence of non-DTMF tones stored on the mobile equipment. +For example:

      virtual void PrepareToPlayFixedSequence(TInt aSequenceNumber);
      • +

    • PrepareToPlayDualTone() - to play a dual tone. For example:

      void PrepareToPlayDualTone(TInt aFrequencyOne, TInt aFrequencyTwo, const TTimeIntervalMicroSeconds& aDuration);

      The two tones, aFrequencyOne and aFrequencyTwo, are measured +in Hz, and the duration of the tone, aDuration, is measured in microseconds.

      • +

    All the prepare member functions are asynchronous. In response +to each, CMdaAudioToneUtility creates a CMMFToneConfig derived object that stores the data for the +type of tone to play.

    On completion of a prepare, the observer +function MMdaAudioToneObserver::MatoPrepareComplete() is called, indicating the success or failure of the prepare operation. +If successful you can play the tone.

    You can cancel any prepare +function using CancelPrepare() (the observer callback +function is not called on completion of the cancel).

    Playing a tone

    Once the player is prepared successfully, certain configurations +can be done before playing the tone as listed below:

      +

    • Volume() and SetVolume() - This retrieves the current +volume settings and sets to a new value specified by the user respectively.

      • +

    • GetBalanceL() and SetBalanceL() - This retrieves the current +balance of the audio device and sets the audio balance specified by +the user respectively..

      • +

    • SetPriority() - This sets the priority of the audio device. The priority is defined +to arbitrate between multiple objects trying to access the controller +at the same time.

      • +

    • SetVolumeRamp() - This defines the period over which the volume level is to rise +(in microseconds) smoothly from zero to the specified volume level. +A value of 0 causes the tone to be played at the SetVolume() level for the full duration of the playback. +A value that is longer than the duration of the tone sequence means +that the tone never reaches the specified volume.

      virtual void SetVolumeRamp(const TTimeIntervalMicroSeconds &aRampDuration);
      • +

    • SetDTMFLengths() - This alters the duration of DTMF tone, the gaps between two DTMF +tones, and the pauses in microseconds.

      • +

    • FixedSequenceCount() - This returns the number of available pre-defined tone sequences, +the number always being greater than zero.

      • +

    • FixedSequenceName() - This returns the name of the specified fixed tone sequence.

      • +

    Upon successful configuration, the Play() can be called as +shown below.

    Play() - plays the tone, DTMF +or tone sequence specified by the prepare statement. For example:

    virtual void Play();

    Here, the tone player uses the Play() from +the audio player utility to play the tone.

    This function is +asynchronous. It retrieves the details of the type of tone to play +from the previous Prepare statement. When the tone +has been played to completion, the observer callback function MMdaAudioToneObserver::MatoPlayComplete() is called, indicating +the success or failure of the play operation. The play operation can +be cancelled by calling the CancelPlay() member function.

    Playing the tone or +DTMF string can be customised using the following member functions +as mentioned below:

      +

    • SetRepeats() - sets the number of times the tone sequence (plus an optional trailing +silent period, measured in microseconds) is repeated during the play +operation. For example:

      virtual void SetRepeats(TInt aRepeatNumberOfTimes, const TTimeIntervalMicroSeconds &aTrailingSilence);

      You can repeat the tone sequence indefinitely by setting aRepeatNumberOfTimes to KMdaRepeatForever.

      • +

    • State() - returns the current state of the tone player (an enum):

        +

      • EMdaAudioToneUtilityNotReady - not prepared to play a tone

        • +

      • EMdaAudioToneUtilityPrepared - prepared and ready to play a tone

        • +

      • EMdaAudioToneUtilityPlaying - currently playing a tone

        • +

      For example:

      virtual TMdaAudioToneUtilityState State();
      • +

    To play another tone or sequence, either wait for MMdaAudioToneObserver::MatoPlayComplete() callback to be +issued when the current tone or DTMF string completes playing, or +use CancelPlay() and then issue the relevant prepare statement. +The Play() function following the prepare statement +plays the tone or DTMF string based on the previously issued prepare +statement.

    Cancelling a tone

    CancelPlay() - cancels the tone, DTMF, +or tone sequence currently playing. For example:

    virtual void CancelPlay();

    The observer callback function is not called on completion +of the cancel.

    Retrieving a custom +interface

    To retrieve a custom interface to the underlying +device, use the CustomInterface() member function. +For example:

    IMPORT_C TAny *CustomInterface(TUid aInterfaceId);

    aInterfaceId is the UID of the interface function +required.

    The function returns a pointer to the interface +implementation, or NULL if the device does not implement the interface +requested. You must cast the return value to the correct type.

    +
    See +Also

    How to use the audio convert utility

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F14FB98-D7CD-55C9-8D27-715642B8FFC3_d0e404850_href.png Binary file Symbian3/SDK/Source/GUID-9F14FB98-D7CD-55C9-8D27-715642B8FFC3_d0e404850_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F14FB98-D7CD-55C9-8D27-715642B8FFC3_d0e408650_href.png Binary file Symbian3/SDK/Source/GUID-9F14FB98-D7CD-55C9-8D27-715642B8FFC3_d0e408650_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F22E663-8BC4-5502-879F-E6B790465E74.dita --- a/Symbian3/SDK/Source/GUID-9F22E663-8BC4-5502-879F-E6B790465E74.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -exportunfrozen

    exportunfrozen

    Use the exportunfrozen statement if unfrozen exports are to appear in the project’s import library.

    When it is used, the import library is created as a side-effect of linking so that all exported functions, even unfrozen ones, appear in the import library. This also means that import libraries for compatible ABIs are not created.

    If this is not used, you must supply a .def file with the frozen exports.

    Use of exportunfrozen is only recommended for the early stages of project development, when the Application Programming Interface is likely to be subject to change.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4675_href.png Binary file Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4675_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4802_href.png Binary file Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4802_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4806_href.png Binary file Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4806_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4930_href.png Binary file Symbian3/SDK/Source/GUID-9F4C948B-7A6B-4E90-BBB7-A6CC6F4A6769_d0e4930_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9F90A2F0-9C76-4871-A766-D1AE0FC42C08.dita --- a/Symbian3/SDK/Source/GUID-9F90A2F0-9C76-4871-A766-D1AE0FC42C08.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-9F90A2F0-9C76-4871-A766-D1AE0FC42C08.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,77 +1,72 @@ - - - - - -Defining -localizable registration information -

    You need to register your applications -to make them visible to the application menu and to provide other information -to the underlying system. To register, you need to provide a registration -resource file that contains the non-localized information for your -application. You also need to provide the localizable registration information. -The registration resource file is compiled during the build process and included -in the .pkg file used to make the file used to make -the sis installation file.

    - - -

    Localizable registration information is defined in a LOCALISABLE_APP_INFO resource -statement, which may be in a separate file or in the resource file for the -GUI resources. For a discussion of the available options for where you can -place this resource statement, see Localisable -icon/caption definition files.

    -

    To define the localizable registration information:

    -
      -

    1. Determine -the requirements of your application, including deciding on whether the resource -statement should be in its own file or part of the GUI resource file.

      -
      2. -

    2. Create a LOCALISABLE_APP_INFO resource. -The data structure is declared in the appinfo.rh file -in the ./epoc32/include folder, as is the CAPTION_AND_ICON_INFO structure -used in the resource. The syntax is as follows:

      - -RESOURCE LOCALISABLE_APP_INFO r_name36 - { - short_caption = ""; - CAPTION_AND_ICON_INFO - { - caption = ""; - number_of_icons =0; - icon_file = ""; - }; - view_list[]; // VIEW_DATA - group_name(KAppMaxGroupName) = ""; - } -

      where

      -
        -

      • r_name36 is the resource name that uniquely -identifies the RESOURCE statement in the application, and is used in the registration resource file.

        -
        • -

      • short_caption indicates a shortened -version of the caption used by some UIs when screen space is limited.

        -
        • -

      • caption indicates the caption used for -the application on the grid and list menu.

        • -

      • number_of_icons indicates the number -of icons used for the application in the menu.

        • -

      • icon_file indicates the name of the -file that contains the icon, including the path but not the drive name.

        -
        • -
      -

      For information on the other possible values, see Localisable -icon/caption definition files.

      -       -
      3. -

    3. Add the resource -name of this resource to the localisable_resource_id in -the registration resource file.

      4. -
    -

    For a commented example, see helloworldbasic.rss.

    + + + + + +Defining localizable registration information +

    You need to register your +applications to make them visible to the application menu and to provide +other information to the underlying system. To register, you need +to provide a registration resource file that contains the non-localized +information for your application. You also need to provide the localizable +registration information. The registration resource file is compiled +during the build process and included in the .pkg file used to make the file used to make the sis installation file.

    + + +

    Localizable registration information is defined in a LOCALISABLE_APP_INFO resource statement, which may be +in a separate file or in the resource file for the GUI resources. +For information on available options for where you can place this +resource statement, see Symbian^3 Tools Guide > Building.

    +

    To define the localizable registration information:

    +
      +

    1. Determine +the requirements of your application, including deciding on whether +the resource statement should be in its own file or part of the GUI +resource file.

      2. +

    2. Create +a LOCALISABLE_APP_INFO resource. The data structure +is declared in the appinfo.rh file in the ./epoc32/include folder, as is the CAPTION_AND_ICON_INFO structure used in the resource. The syntax is as follows:

      + +RESOURCE LOCALISABLE_APP_INFO r_name36 + { + short_caption = ""; + CAPTION_AND_ICON_INFO + { + caption = ""; + number_of_icons =0; + icon_file = ""; + }; + view_list[]; // VIEW_DATA + group_name(KAppMaxGroupName) = ""; + } +

      where

      +
        +

      • r_name36 is the resource name +that uniquely identifies the RESOURCE statement in the application, +and is used in the registration resource file.

        • +

      • short_caption indicates a shortened +version of the caption used by some UIs when screen space is limited.

        +
        • +

      • caption indicates the caption +used for the application on the grid and list menu.

        • +

      • number_of_icons indicates the +number of icons used for the application in the menu.

        • +

      • icon_file indicates the name +of the file that contains the icon, including the path but not the +drive name.

        • +
      +

      For information on Localisable icon, see Symbian^3 Tools +Guide > Building.

      +       +
      3. +

    3. Add +the resource name of this resource to the localisable_resource_id in the registration resource file.

      4. +
    +

    For a commented example, see helloworldbasic.rss.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9FB3502C-B3DF-5FBC-972D-0D476D661954_d0e107166_href.png Binary file Symbian3/SDK/Source/GUID-9FB3502C-B3DF-5FBC-972D-0D476D661954_d0e107166_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9FB3502C-B3DF-5FBC-972D-0D476D661954_d0e107398_href.png Binary file Symbian3/SDK/Source/GUID-9FB3502C-B3DF-5FBC-972D-0D476D661954_d0e107398_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e77290_href.png Binary file Symbian3/SDK/Source/GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e77290_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e77328_href.png Binary file Symbian3/SDK/Source/GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e77328_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A007DDF7-AC6D-5378-B7A6-84CB421E970F_d0e336695_href.png Binary file Symbian3/SDK/Source/GUID-A007DDF7-AC6D-5378-B7A6-84CB421E970F_d0e336695_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A007DDF7-AC6D-5378-B7A6-84CB421E970F_d0e343161_href.png Binary file Symbian3/SDK/Source/GUID-A007DDF7-AC6D-5378-B7A6-84CB421E970F_d0e343161_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e51905_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e51905_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e52048_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e52048_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e67708_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e67708_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e67772_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e67772_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e69130_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e69130_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e69154_href.png Binary file Symbian3/SDK/Source/GUID-A0208BE3-127F-4D04-8045-09C54EF202DD_d0e69154_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A049B0C2-5C30-5B07-AC4F-32A75046B60B.dita --- a/Symbian3/SDK/Source/GUID-A049B0C2-5C30-5B07-AC4F-32A75046B60B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A049B0C2-5C30-5B07-AC4F-32A75046B60B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,7 +40,7 @@ of the data. The following drawing shows the layout of a TBufC<5> object initialised with the string of five characters representing the English word "Hello".

    - +
    Modifiable buffer descriptor

    The data contained in a modifiable buffer descriptor can be both accessed and changed through @@ -64,6 +64,6 @@ that holds the maximum length of the data. The following drawing shows the layout of a TBuf<12> object initialised with the string of five characters representing the English word "Hello".

    - +
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-15-1-1-4-1-4-1-22-1-6-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-15-1-1-4-1-4-1-22-1-6-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,20 +0,0 @@ - - - - - -How -to stop a periodic timerDescribes how to stop a periodic timer. -

    To stop a periodic timer, call Cancel(). After the cancel, -the CPeriodic may be started again, and so on until it is -destroyed.

    - -iPeriodic->Cancel(); - -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-15-1-1-4-1-4-1-22-1-7-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-15-1-1-4-1-4-1-22-1-7-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,20 +0,0 @@ - - - - - -How -to stop a periodic timerDescribes how to stop a periodic timer. -

    To stop a periodic timer, call Cancel(). After the cancel, -the CPeriodic may be started again, and so on until it is -destroyed.

    - -iPeriodic->Cancel(); - -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-17-1-1-4-1-4-1-22-1-6-1-4-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-17-1-1-4-1-4-1-22-1-6-1-4-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,20 @@ + + + + + +How +to stop a periodic timerDescribes how to stop a periodic timer. +

    To stop a periodic timer, call Cancel(). After the cancel, +the CPeriodic may be started again, and so on until it is +destroyed.

    + +iPeriodic->Cancel(); + +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-17-1-1-4-1-4-1-22-1-7-1-4-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-A0531C8B-22F2-5FAE-9F37-92BACBBD9EEB-GENID-1-10-1-17-1-1-4-1-4-1-22-1-7-1-4-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,20 @@ + + + + + +How +to stop a periodic timerDescribes how to stop a periodic timer. +

    To stop a periodic timer, call Cancel(). After the cancel, +the CPeriodic may be started again, and so on until it is +destroyed.

    + +iPeriodic->Cancel(); + +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A05F0124-AE28-5088-8AFE-22956D1549AD.dita --- a/Symbian3/SDK/Source/GUID-A05F0124-AE28-5088-8AFE-22956D1549AD.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -noexportlibrary

    noexportlibrary

    This stops the generation of a component's .lib file.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0C0BEBA-1976-5D68-B4EF-C3727DF163A9.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-A0C0BEBA-1976-5D68-B4EF-C3727DF163A9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,22 @@ + + + + + +Contacts +Model API Example +
    Description This +C++ example is a simple application demonstrating the use of the Contacts +Model API. It allows viewing contact items from the default contacts database. +Each contact is shown using a custom text definition. New contacts can be +imported from files that contain vCard items. A contact item can also be selected +and exported to a file in the vCards format.
    +
    Download

    Click +on the following link to download the example: ContactsModel.zip

    Click: browse to view the example code.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A0E21681-F1EF-4E79-965A-040AC7D72A01.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-A0E21681-F1EF-4E79-965A-040AC7D72A01.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,69 @@ + + + + + +Time zone conversion overview +

    This document describes the Symbian platform time zone conversion +component.

    +

    +

    About +time zones and daylight saving time

    Time zones

    Time zones are regions that have adopted the same standard time. +All time zones are defined relative to UTC (Coordinated Universal +Time) which is the international time standard. See http://www.ghcc.msfc.nasa.gov/utc.html for +more details.

    The time for a location is given relative to UTC. +For example:
      +

    • Mumbai, India: UTC + 5:30 (For example, if it is 12:00 UTC, +then it is 17:30 in Mumbai)

      • +

    • Tokyo, Japan: UTC + 9 (For example, if it is 12:00 UTC, then +it is 21:00 in Tokyo)

      • +
    The local time may need to be adjusted due to the use of +a daylight saving time offset.

    The list of time zones used +within a country are found in Time zone list. Select a country to +view all the time zones used within that country. The time zones follow +a "Location/Area" format, with "Location" being a continent or geographic +region of the world and "Area" being a time zone region within that +location, for example, "Europe/Vienna".

    Local time

    The local time is the time according to the local time zone (the +place where the phone user is physically located). The local time +is sometimes referred to as "wall clock" time.

    If local time +is 10:00 hours in the US Eastern time zone, then the local time in +the US Pacific time zone is 07:00 hours. This is because US Eastern +Time is 4 hours behind UTC (UTC -4) and US Pacific Time is 7 hours +behind UTC (UTC –7 ).

    If a phone user’s normal location is +in the US Eastern time zone, and travels to a location in the US Pacific +time zone, the phone time zone should be changed to US Pacific Time. +

    The system time zone is the time zone to which the device +is set.

    +
    Time +zone conversion

    The time zone component allows you to set +the system time zone and to convert time between UTC and any time, +past, present or future, for any time zone, as long as a rule exists +for the conversion. The change rules include when to change to and +from daylight saving time for each time zone.

    The time zone +rules are provided in a Symbian-native database which is created from +Olson’s TZ database. It can be configured by device manufacturers +to save space. The time zone rules for the current time zone are cached +by the time zone server so that they are quicker to access for future +conversions.

    Using the time zone component you can do the +following:

      +

    • configure the current local time zone.

      • +

    • convert a UTC time to the local time for the system time zone.

      • +

    • convert a UTC time to the local time for a time zone provided +by the user.

      • +

    • convert the local time for the system time zone to UTC.

      • +

    • convert the local time for any time zone provided by the user +to UTC.

      • +

    The key classes involved are CTzId, RTz and CTzConverter.

    +Class diagram for Time zone Conversion + +

    See also

      +

    • Converting +between UTC and local time

      • +
    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A10EAF58-6B9F-55A5-B3E4-3D4B91A93C41_d0e237205_href.png Binary file Symbian3/SDK/Source/GUID-A10EAF58-6B9F-55A5-B3E4-3D4B91A93C41_d0e237205_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A10EAF58-6B9F-55A5-B3E4-3D4B91A93C41_d0e242185_href.png Binary file Symbian3/SDK/Source/GUID-A10EAF58-6B9F-55A5-B3E4-3D4B91A93C41_d0e242185_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A1148010-887F-549D-9DA0-D36FF4661FFE.dita --- a/Symbian3/SDK/Source/GUID-A1148010-887F-549D-9DA0-D36FF4661FFE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A1148010-887F-549D-9DA0-D36FF4661FFE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> What are Access PointsThis topic describes the concept of an Access Point in the Communications Framework.

    A Layer can make a service available to the Layer immediately above it. The service is called an Access Point.

    Each Layer except the highest Layer can have an Access Point. The highest Layer is called the Application Layer. The Communications Framework can limit the use of an Access Point to selected clients.

    The following diagram shows five Access Points. Each Access Point offers a service to the Layer above it.

    Access Points in the Communications Framework -

    In this diagram the Link Layer has three bearers. Each bearer has an Access Point. An application or a Layer above the Link Layer does not need to know which bearer in the Link Layer is in use during the connection. The Communication Framework can replace the bearer with another bearer. The Communication Framework does not need to tell the application when the bearer changes. An application can continue to send and receive data when the change occurs.

    For example, consider an email application on a device. The device connects over a GPRS network. A short time later the device detects that a Wi-Fi connection is available. This event can occur if the device has moved from an office location to a coffee shop. The device can have a selection policy. The policy can state that the device switch to WiFi without the creation of a new connection.

    The selection policy contains a list of Access Points in order of priority. Device manufacturers, Network Operators and users can configure the order of priority. The priority can be based on items like available bandwidth and cost. An alternative to selection policy is the concept of connection preference. For example, a device connects with a specific bearer (for example, GPRS) unless the application changes the bearer explicitly.

    It is useful to note that an Internet Access Point (IAP) is a specialisation of the Access Point concept for a Link Layer. IAPs identify a service to be accessed through a concrete link-layer bearer. Each IAP has an associated Access Point with the same physical value.

    IAP Layers     \ No newline at end of file +

    In this diagram the Link Layer has three bearers. Each bearer has an Access Point. An application or a Layer above the Link Layer does not need to know which bearer in the Link Layer is in use during the connection. The Communication Framework can replace the bearer with another bearer. The Communication Framework does not need to tell the application when the bearer changes. An application can continue to send and receive data when the change occurs.

    For example, consider an email application on a device. The device connects over a GPRS network. A short time later the device detects that a Wi-Fi connection is available. This event can occur if the device has moved from an office location to a coffee shop. The device can have a selection policy. The policy can state that the device switch to WiFi without the creation of a new connection.

    The selection policy contains a list of Access Points in order of priority. Device manufacturers, Network Operators and users can configure the order of priority. The priority can be based on items like available bandwidth and cost. An alternative to selection policy is the concept of connection preference. For example, a device connects with a specific bearer (for example, GPRS) unless the application changes the bearer explicitly.

    It is useful to note that an Internet Access Point (IAP) is a specialisation of the Access Point concept for a Link Layer. IAPs identify a service to be accessed through a concrete link-layer bearer. Each IAP has an associated Access Point with the same physical value.

    IAP Layers \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita --- a/Symbian3/SDK/Source/GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,14 +1,22 @@ - - - - - -Advanced Pointers In ScreenPlay, the Window Server provides advanced pointer features, such as support for multiple pointers and proximity and pressure coordinates.

    Variant: ScreenPlay. Target audience: Application developers.

    Window Server - Client-Side Events Overview Pointer - Handling     \ No newline at end of file + + + + + +Advanced +Pointers In ScreenPlay, the Window Server provides advanced pointer +features, such as support for multiple pointers and proximity and +pressure coordinates. +

    Variant: ScreenPlay. Target audience: Application developers.

    +     +Window +Server Client-Side Events Overview +Pointer + Handling +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A12A6C54-7E9E-5ECD-A0BF-8F980160A0D2.dita --- a/Symbian3/SDK/Source/GUID-A12A6C54-7E9E-5ECD-A0BF-8F980160A0D2.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -prj_platforms

    prj_platforms list_of_platforms

    In the prj_platforms section, list the platforms that the component supports.

    If the platforms section is not found, bldmake assumes the default build targets.

    Note, building for the MARM platform is no longer supported. If MARM is specified as a platform, it will be expanded to mean ARM4, ARMI and THUMB, but really these platforms should be listed explicitly, or the default relied upon.

    Specifying the pseudo-platform DEFAULT at the start of the list will cause any subsequent platforms to be added to the default list, unless these platforms are prefixed with a hyphen (-), in which case these platforms will be removed from the list.

    Platforms can be listed on several separate lines if required.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A15EDC87-A6EF-40D8-AA78-B52449465FEA.dita --- a/Symbian3/SDK/Source/GUID-A15EDC87-A6EF-40D8-AA78-B52449465FEA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A15EDC87-A6EF-40D8-AA78-B52449465FEA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@

    Use cases for the long-tap detector are shown in the figure below.

    Touch UI utilities API use cases - +

    To use the Touch UI utilities long-tap detector in your application, implement the following use cases.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A188606F-4A8E-5A85-A241-E15219960EFA.dita --- a/Symbian3/SDK/Source/GUID-A188606F-4A8E-5A85-A241-E15219960EFA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A188606F-4A8E-5A85-A241-E15219960EFA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,119 +9,117 @@ --> -Loader -OverviewThis topic describes the overview, purpose, key concepts and architecture -of loader. +Loader OverviewThis topic describes the overview, purpose, key concepts +and architecture of loader.

    • Purpose

    • Key concepts

    • Architectural relationships

    -
    Purpose

    The -loader makes EXEs and DLLs ready to run.

    The build tools compile the -source code into an executable file. An executable file is called a binary. -The build tools arrange the compiled code into EXEs and DLLs. The source code, -header files and other information that defines an executable file is defined -in an mmp file. The loader applies relocation information to the code and -data sections of EXEs and DLLs. The loader also loads DLLs that are referred -to by other EXEs and DLLs. EXEs and DLLs can then run in the process into -which they are loaded.

    -
    Key concepts

    The loader server

    The Symbian platform loader is a server. -The loader server has no public client interface. The client interface is -internal to Symbian platform. Requests to load an EXE or a DLL are passed -to the loader when you do the following:

      -

    • start a new process -- a call to RProcess::Create()

      • -

    • load a DLL - a call -to RLibrary::Load()

      • -

    • load a logical device -driver - a call to User::LoadLogicalDevice(). A logical -device driver is a type of DLL.

      • -

    • load a physical device -driver - a call to User::LoadPhysicalDevice(). A physical -device driver is a type of DLL.

      • -

    • load a file system - -a call to RFs::AddFileSystem(). A file system is a type -of DLL. A call to RFs::AddFileSystem() requires DiskAdmin +

      Purpose

      The loader makes EXEs and DLLs ready to run.

      The build +tools compile the source code into an executable file. An executable +file is called a binary. The build tools arrange the compiled code +into EXEs and DLLs. The source code, header files and other information +that defines an executable file is defined in an mmp file. The loader +applies relocation information to the code and data sections of EXEs +and DLLs. The loader also loads DLLs that are referred to by other +EXEs and DLLs. EXEs and DLLs can then run in the process into which +they are loaded.

      +
      Key +concepts

      The loader server

      The Symbian platform loader is a +server. The loader server has no public client interface. The client +interface is internal to Symbian platform. Requests to load an EXE +or a DLL are passed to the loader when you do the following:

        +

      • start a new +process - a call to RProcess::Create()

        • +

      • load a DLL - +a call to RLibrary::Load()

        • +

      • load a logical +device driver - a call to User::LoadLogicalDevice(). A logical device driver is a type of DLL.

        • +

      • load a physical +device driver - a call to User::LoadPhysicalDevice(). A physical device driver is a type of DLL.

        • +

      • load a file +system - a call to RFs::AddFileSystem(). A file +system is a type of DLL. A call to RFs::AddFileSystem() requires DiskAdmin capability. See ECapabilityDiskAdmin.

        • +

      • load a file +server extension - call to RFs::AddExtension(). +A file server extension is a type of DLL. This function requires DiskAdmin capability. See ECapabilityDiskAdmin.

        • -

      • load a file server extension -- call to RFs::AddExtension(). A file server extension -is a type of DLL. This function requires DiskAdmin capability. See ECapabilityDiskAdmin.

        • -

      • load a locale - a call -to TExtendedLocale::LoadLocale().

        • -

      Version -numbers

      The -reason for version numbers

      More than one version of an EXE can -exist on a device at the same time. More than one version of a DLL can exist -on a device at the same time. A device can store versions of an EXE or DLL -that are not compatible with an older version of that EXE or DLL.

      A -version number is a set of two numbers. The loader uses these numbers to identify -copies of the executable file. The two numbers are called the major version -number and the minor version number. The build tools encode the two numbers -into the header of the executable file. When a DLL is built, the version numbers -are encoded into the import library.

      The -structure of version information

      DLLs are the most common users -of versions. You assign new values to the version numbers of a DLL when you -change the published API of the DLL. Symbian recommends the following procedure:

        -

      • change the minor version -number if you make a change to a DLL that is backward compatible. An example -is a new function in the DLL.

        • -

      • change the major version -number if you make a change to a DLL that breaks an interface. An example -is the removal of a function or a change to the signature of a function. An -interface break is disruptive and must be prevented.

        • -

      The major and minor version numbers are defined in the .mmp file -that defines the source code, header files and other options that apply to -the executable file.

      If you do not specify version numbers, the build -tools apply the following default values:

        -

      • Major version number -: 10

        • -

      • Minor version number -: 0

        • -

      The major version number and the minor version number are stored -in the header of an EXE and DLL. The two numbers are stored in a single 32 -bit value. The high 16 bits hold the major version number. The low 16 bits -hold the minor version number.

      When you build a DLL, the build tools -encode the version numbers into the filename of the import library (the .lib file). -The build tools also create an import library that does not have the version -numbers encoded as part of the filename.The following example shows how the -version numbers are encoded in the filename. The major version number is (decimal) -11 and the minor version number is (decimal) 2. The version numbers in the -filename are in hexadecimal.

      abcdsrv{000B0002}.lib

      Notes:

        -

      • The left bracket and -the right bracket are part of the name.

        • -

      • The first four digits -after the open bracket are the hexadecimal representation of the major version -number.

        • -

      • The second four digits -are the hexadecimal representation of the minor version number.

        • -

      The build tools do not encode the version numbers in the filename -of the executable file.

      Loader -search rules

      EXEs and DLLs can exist on more than one drive. There -can be more than one version of an EXE and more than one version of a DLL. -The loader uses search rules to select the EXE and DLL to load.

      See Loader search rules

      Emulator

      Version numbers are stored in import files for DLLs -that run on devices and the emulator. Version numbers change how the loader -functions on devices, but not in the emulator. You cannot encode the version -numbers in the import library file name on the emulator.

      Tools support

      Use the build tools to apply version numbers -to EXEs and DLLs. You specify version numbers in the .mmp file -that describes the EXE or DLL.

      See also mmp -file syntax and Build -tools guide.

      +

    • load a locale +- a call to TExtendedLocale::LoadLocale().

      • +

    Version numbers

    The reason for version numbers

    More than one version +of an EXE can exist on a device at the same time. More than one version +of a DLL can exist on a device at the same time. A device can store +versions of an EXE or DLL that are not compatible with an older version +of that EXE or DLL.

    A version number is a set of two numbers. +The loader uses these numbers to identify copies of the executable +file. The two numbers are called the major version number and the +minor version number. The build tools encode the two numbers into +the header of the executable file. When a DLL is built, the version +numbers are encoded into the import library.

    The structure of version information

    DLLs are the +most common users of versions. You assign new values to the version +numbers of a DLL when you change the published API of the DLL. Symbian +recommends the following procedure:

      +

    • change the minor +version number if you make a change to a DLL that is backward compatible. +An example is a new function in the DLL.

      • +

    • change the major +version number if you make a change to a DLL that breaks an interface. +An example is the removal of a function or a change to the signature +of a function. An interface break is disruptive and must be prevented.

      • +

    The major and minor version numbers are defined in the .mmp file that defines the source code, header files and +other options that apply to the executable file.

    If you do +not specify version numbers, the build tools apply the following default +values:

      +

    • Major version +number : 10

      • +

    • Minor version +number : 0

      • +

    The major version number and the minor version number are +stored in the header of an EXE and DLL. The two numbers are stored +in a single 32 bit value. The high 16 bits hold the major version +number. The low 16 bits hold the minor version number.

    When +you build a DLL, the build tools encode the version numbers into the +filename of the import library (the .lib file). +The build tools also create an import library that does not have the +version numbers encoded as part of the filename.The following example +shows how the version numbers are encoded in the filename. The major +version number is (decimal) 11 and the minor version number is (decimal) +2. The version numbers in the filename are in hexadecimal.

    abcdsrv{000B0002}.lib

    Notes:

      +

    • The left bracket +and the right bracket are part of the name.

      • +

    • The first four +digits after the open bracket are the hexadecimal representation of +the major version number.

      • +

    • The second four +digits are the hexadecimal representation of the minor version number.

      • +

    The build tools do not encode the version numbers in the +filename of the executable file.

    Loader search rules

    EXEs and DLLs can exist on more +than one drive. There can be more than one version of an EXE and more +than one version of a DLL. The loader uses search rules to select +the EXE and DLL to load.

    See Loader search rules

    Emulator

    Version numbers are stored in import files +for DLLs that run on devices and the emulator. Version numbers change +how the loader functions on devices, but not in the emulator. You +cannot encode the version numbers in the import library file name +on the emulator.

    Tools support

    Use the build tools to apply version +numbers to EXEs and DLLs. You specify version numbers in the .mmp file that describes the EXE or DLL.

    See also MMP file syntax in Symbian Tools Guide > Building + > Symbian Build System (SBSv1) > Build tools reference.

    Architectural -relationships

    The loader is a server that runs in a separate thread -in the file server process. The loader is built as part of the file server.

    The -loader server starts when the file server starts. The file server starts after -the kernel is loaded at system start.

    The loader runs on the user -side, but calls the kernel for services that are not available to general -applications. Examples of services are process creation and code segment creation. -A code segment is an object that represents a piece of code loaded into RAM. -A code segment also represents a piece of code that runs directly from ROM. -The kernel services that the loader uses are protected. The file server process -only is allowed to access these services.

    The following picture is -an example of program flow. In this example, a client calls RLibrary::Load(), -which exists in euser.dll. Internal functions make client-server -calls to the loader server. The loader server code exists in efile.exe. -The loader server uses kernel services.

    - +relationships

    The loader is a server that runs in a separate +thread in the file server process. The loader is built as part of +the file server.

    The loader server starts when the file server +starts. The file server starts after the kernel is loaded at system +start.

    The loader runs on the user side, but calls the kernel +for services that are not available to general applications. Examples +of services are process creation and code segment creation. A code +segment is an object that represents a piece of code loaded into RAM. +A code segment also represents a piece of code that runs directly +from ROM. The kernel services that the loader uses are protected. +The file server process only is allowed to access these services.

    The following picture is an example of program flow. In this +example, a client calls RLibrary::Load(), which +exists in euser.dll. Internal functions make +client-server calls to the loader server. The loader server code exists +in efile.exe. The loader server uses kernel services.

    +
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A1D2C673-3B91-403A-800B-5E1504FB19EE.dita --- a/Symbian3/SDK/Source/GUID-A1D2C673-3B91-403A-800B-5E1504FB19EE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A1D2C673-3B91-403A-800B-5E1504FB19EE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ your application around the Symbian Ecam camera utility. To make use of the device camera to capture an image, the application needs to repeat the steps described in the illustration below.

    -The steps required to capture a still image +The steps required to capture a still image

    Important implementation considerations include:

    • The settings you can use in your application depend on what diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A1DBE03F-728E-4F31-BE74-5BDA3906C8DD.dita --- a/Symbian3/SDK/Source/GUID-A1DBE03F-728E-4F31-BE74-5BDA3906C8DD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A1DBE03F-728E-4F31-BE74-5BDA3906C8DD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ the visual appearance of the UI. Themes, also known as skins, only affect the visual appearance of the UI, the underlying architecture, interaction style, language settings, and general functionality are not affected.

      -Personalization through themes +Personalization through themes

      The Symbian platform provides an API to allow you to support themes in your applications. Although a mobile device based on the Symbian platform can contain several themes, mobile device users can only activate one theme diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A1F037FE-0D88-5108-B96E-4ADE6B3A4A3E.dita --- a/Symbian3/SDK/Source/GUID-A1F037FE-0D88-5108-B96E-4ADE6B3A4A3E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -inflatecompresstarget

      inflatecompresstarget

      Use the inflatecompresstarget statement to specify that the target executable should be compressed. In detail, the code and data sections of the executable are compressed with the Deflate, Huffman+LZ77 algorithm.

      Compression allows the stored executable to use less space on the file system. The executable loader decompresses the file when it is loaded.

      See also compresstarget.

      See also bytepaircompresstarget.

      See also nocompresstarget.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A2031A61-3319-4FBA-BC71-AC1327182053.dita --- a/Symbian3/SDK/Source/GUID-A2031A61-3319-4FBA-BC71-AC1327182053.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A2031A61-3319-4FBA-BC71-AC1327182053.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ and Standard Template Library Documentation

      C++ IOStream library documentation can be found at http://www.slac.stanford.edu/comp/unix/gnu-info/iostream_toc.html.

      Similarly, Standard Template Library (STL) documentation can be found at http://www.informatik.uni-freiburg.de/~danlee/fun/STL-doc/STL.html.

    -
    Changes to +<section id="GUID-BF521201-7BE5-4AC5-8D35-1E15AC4887C7-GENID-1-10-1-13-1-1-9-1-5-1-3-2"><title>Changes to the MMP file

    Add needed libraries used by the MMP file structure:

    If developers want to use any of Standard C++ library, they must link to the corresponding library in the MMP file using the LIBRARY keyword.

    If @@ -53,7 +53,7 @@ more stack space. The recommended stack size is 10K. To set the stack size to 10K add: EPOCSTACKSIZE 0x10000

    in the MMP file.

    -
    Example using <codeph>main()</codeph> +
    Example using <codeph>main()</codeph>

    A simple example using main() as an entry point is described below. The example writes a text to a console.

    • Modify the MMP file as mentioned before.

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A24491E4-867F-4006-9798-07281553EA51.dita --- a/Symbian3/SDK/Source/GUID-A24491E4-867F-4006-9798-07281553EA51.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A24491E4-867F-4006-9798-07281553EA51.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,103 +1,168 @@ - - - - - -Release NotesThis library is intended for application developers for -the Symbian^3 platform. -
      Major changes between the week 12 2010 release and -week 22 2010 release

      Since the week 12 2010 documentation -submission to the Symbian Foundation, the following major additions -have been made:

        -

      • CryptoSPI - documentation.

        • -

      • API -changes and compatibility breaks.

        • -

      • IP Connection -Management.

        • -

      Bug fixes:

      This release contains fixes for the -following bugs and known issues:

        -

      • Symbian^3 documentation.

        • -

      • Buildrom content is missing.

        • -

      • Some links to Multimedia example code occur more than once -in the table of contents and in landing pages.

        • -

      • Links to the Open C examples in the full example code list -are broken.

        • -

      • Broken and incorrect links in Platform security architecture -and Optional resource file statements topics.

        • -

      • The breadcrumb trails for Application framework guide, Multimedia -example code and System GUI Framework example code are wrong and contains -duplicates.

        • -
      -
      Major -changes between the week 03 2010 release and week 12 2010 release

      Since the week 03 2010 documentation submission to the Symbian -Foundation, the following major additions have been made:

        -

      • Inclusion of API reference extracted from the Symbian^3 source -code.

        • -

      • Inclusion of API specifications.

        • -

      • A new About Symbian^3 topic, including What's new and Porting applications -from S60 5th Edition to Symbian^3.

        • -

      • A new Getting Started, consisting of the Symbian Foundation's C++ -Quick Start and Going Beyond Hello tutorials.

        • -

      • Integration of the Panic Codes Reference.

        • -

      • Addition of new topics: Common Email Guide and System -Resource Monitoring.

        • -

      • The Graphics Guide has been updated for Symbian^3. For details, -see What's -New in Graphics in Symbian^3.

        • -

      • The Classic UI Guide has been updated for Symbian^3.

        • -

      • All guides have been updated to refer to the Symbian platform -rather than to Symbian OS and to S60, apart from where it is necessary -to refer to past releases.

        • -

      Bug fixes:

      This release contains fixes for the -following bugs:

        -

      • Change section headings in Symbian^3 product/app -reference

        • -

      • Fix up the links in the Platform security architecture -page

        • -

      • Link to sample chapter of quick recipes book in SDK -docs

        • -

      • Remove "Using the Indexes"

        • -

      • ambiguous documentation of text-options

        • -

      • Remove references to SDN and SDN++ from Symbian Developer -Library

        • -

      • Guide landing page is empty

        • -
      -
      Major -changes between the week 43 2009 release and week 03 2010 release

      New content:

        -

      • Classic -UI Guide

        • -

      • High -Level Internet Protocols Guide

        • -

      • Short -Link Services Guide

        • -

      • Web -Guide

        • -

      The following S60 5th Edition C++ Developer's Library 'Technology -area guides' have been integrated into the Symbian guide:

        -

      • Application -and UI frameworks is now in Classic UI Guide.

        • -

      • S60 -UI components is now in Classic UI Guide.

        • -

      • Multimedia is now in Multimedia Guide.

        • -

      • Browsing -and downloading is now in Web Guide.

        • -

      • Location is now in Location Based Services (LBS).

        • -

      • Security is now found at the top level.

        • -

      The S60 Open C and Open C++ documentation has been merged -into the Symbian P.I.P.S. documentation and is now in Generic OS Services -Guide.

      Other changes:

      The Symbian Developer -Library for Application Developers is released under the Eclipse Public License (EPL).

      -
      Known issues in the week 22 2010 release

      See Known issues with Symbian3 product developers -library.

      -
      Upcoming -releases and improvements in the Symbian Developer Library for Application -Developers

      See the Documentation Content Package Backlog.

      -
      Feedback

      To give feedback, please go to the Symbian Foundation Bugtracker (login required).

      -       \ No newline at end of file + + + + +Release Notes +This library is intended for application developers for +the Symbian^3 platform. + + + + + + +
      Major changes between the week 22 2010 release and +week 28 2010 release
        +

      • The PIM Application Engines and Services section has been split +into Contacts +Guide and Organizer Guide to match the Symbian Foundation package structure.

        • +

      • The Tools and Utilities section has been removed. The content +previously included in this section will be delivered with other Tools +documentation in the Symbian^3 and Symbian^4 Tools Guides (coming +soon).

        • +

      Bug fixes:

      This release contains fixes for the +following bugs:

        +
      • Guide landing page is empty
        • +
      • Fix up the links in the Platform security architecture +page
        • +
      +
      Major +changes between the week 12 2010 release and week 22 2010 release

      Since the week 12 2010 documentation submission to the Symbian +Foundation, the following major additions have been made:

        +

      • CryptoSPI documentation.

        • +

      • API changes and compatibility breaks.

        • +

      • IP Connection Management.

        • +

      Bug fixes:

      This release contains fixes for the +following bugs and known issues:

        +

      • Symbian^3 documentation.

        • +

      • Buildrom content is missing.

        • +

      • Some links to Multimedia example code occur more than once +in the table of contents and in landing pages.

        • +

      • Links to the Open C examples in the full example code list +are broken.

        • +

      • Broken and incorrect links in Platform security architecture +and Optional resource file statements topics.

        • +

      • The breadcrumb trails for Application framework guide, Multimedia +example code and System GUI Framework example code are wrong and contains +duplicates.

        • +
      +
      Major +changes between the week 03 2010 release and week 12 2010 release

      Since the week 03 2010 documentation submission to the Symbian +Foundation, the following major additions have been made:

        +

      • Inclusion of API reference extracted from the Symbian^3 source +code.

        • +

      • Inclusion of API specifications.

        • +

      • A new About Symbian^3 topic, including What's new and Porting applications +from S60 5th Edition to Symbian^3.

        • +

      • A new Getting Started, consisting of the Symbian Foundation's C++ +Quick Start and Going Beyond Hello tutorials.

        • +

      • Integration of the Panic Codes +Reference.

        • +

      • Addition of new topics: Common Email +Guide and System Resource +Monitoring.

        • +

      • The Graphics Guide has been updated for Symbian^3. For details, +see What's +New in Graphics in Symbian^3.

        • +

      • The Classic UI Guide has been updated for Symbian^3.

        • +

      • All guides have been updated to refer to the Symbian platform +rather than to Symbian OS and to S60, apart from where it is necessary +to refer to past releases.

        • +

      Bug fixes:

      This release contains fixes for the +following bugs:

        +

      • Change section headings in Symbian^3 product/app +reference

        • +

      • Fix up the links in the Platform security architecture +page

        • +

      • Link to sample chapter of quick recipes book in SDK +docs

        • +

      • Remove "Using the Indexes"

        • +

      • ambiguous documentation of text-options

        • +

      • Remove references to SDN and SDN++ from Symbian Developer +Library

        • +

      • Guide landing page is empty

        • +
      +
      Major +changes between the week 43 2009 release and week 03 2010 release

      New content:

        +

      • Classic UI Guide

        • +

      • High Level Internet Protocols Guide

        • +

      • Short Link Services Guide

        • +

      • Web Guide

        • +

      The following S60 5th Edition C++ Developer's Library 'Technology +area guides' have been integrated into the Symbian guide:

        +

      • Application and UI frameworks is now in Classic UI Guide.

        • +

      • S60 UI components is now in Classic UI Guide.

        • +

      • Multimedia is now in Multimedia Guide.

        • +

      • Browsing and downloading is now in Web Guide.

        • +

      • Location is now in Location Based Services (LBS).

        • +

      • Security is now found at the top level.

        • +

      The S60 Open C and Open C++ documentation has been merged +into the Symbian P.I.P.S. documentation and is now in Generic OS Services +Guide.

      Other changes:

      The Symbian Developer +Library for Application Developers is released under the Eclipse Public License (EPL).

      +
      Known +issues in the week 22 2010 release

      See Known issues with Symbian3 product developers library.

      +
      Upcoming +releases and improvements in the Symbian Developer Library for Application +Developers

      See the Documentation Content Package Backlog.

      +
      Feedback

      To give feedback, please go to the Symbian Foundation Bugtracker (login required).

      +       +       + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A27A05A2-B161-54D2-92E0-8620B01BFD44.dita --- a/Symbian3/SDK/Source/GUID-A27A05A2-B161-54D2-92E0-8620B01BFD44.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Polymorphic DLL targettype summary

      The following table summarises the polymorphic DLL types to which the build tools give special support through the targettype keyword. Projects using one of these target types do not require a DEF file to specify the frozen exports: the build tools will assume the correct frozen exports for the type.

      Description

      Target type

      UID2

      animation

      ani

      0x10003b22

      file system

      fsy

      0x100039df

      ECom plug-in

      PLUGIN

      0x10009D8D

      front-end processor

      fep

      0x10005e32

      notifier for text window server

      TEXTNOTIFIER2

      0x101fe38b

      printer device

      PDL

      0x10003b1c
      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A29FD82C-B3CC-5862-8DAB-1398A61D8B1F.dita --- a/Symbian3/SDK/Source/GUID-A29FD82C-B3CC-5862-8DAB-1398A61D8B1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A29FD82C-B3CC-5862-8DAB-1398A61D8B1F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -62,7 +62,7 @@

    • Managing HTTP digest security settings

    CSIP, MSIPObserver, CSIPConnection and MSIPConnectionObserver

    - +

    An application creates a single instance of the CSIP class, and implements the callback functions defined by MSIPObserver. The CSIP uses the MSIPObserver functions. @@ -76,14 +76,14 @@ application can have many CSIPConnection objects, but each of them must have a different IAP.

    Registration services

    - +

    An existing CSIPConnection is required to create an instance of CSIPRegistrationBinding. The CSIPRegistrationBinding class provides services for registration, updating the registration, and deregistration. This class also provides instructions to the SIP stack to automatically refresh the registration, and to query and set the outbound proxy used by the registration.

    SIP dialog associations

    - +

    CSIPDialogAssocBase is the base class for SIP dialog associations, such as CSIPInviteDialogAssoc, CSIPSubscribeDialogAssoc, CSIPReferDialogAssoc and CSIPNotifyDialogAssoc. The CSIPDialogAssocBase class is used to obtain the associated SIP dialog, for the associated CSIPDialog instance, @@ -104,7 +104,7 @@ an application to define and send NOTIFY requests.

    Sent and received network requests

    - +

    When a SIP request is sent to the network, the SIP Client API implementation creates a CSIPClientTransaction object and returns it to the application. A CSIPClientTransaction object represents @@ -122,7 +122,7 @@ the transaction type. Some operations are only allowed when the transaction is in a certain state. Note: The SIP Client API creates instances of CSIPClientTransaction and CSIPServerTransaction and they cannot be created by the application.

    SIP message related classes

    - +

    When a SIP request is sent to the network, the SIP Client API implementation creates a CSIPClientTransaction object and returns it to the application. A CSIPClientTransaction object represents @@ -140,7 +140,7 @@ transaction type. Some operations are only allowed when the transaction is in a certain state. Note: The SIP Client API creates instances of CSIPClientTransaction and CSIPServerTransaction and they cannot be created by the application.

    Automatically refreshing a SIP request

    - +

    The SIP stack automatically refreshes a SIP request using the CSIPRefresh object. REGISTER, SUBSCRIBE and a request outside the dialog are refreshed. After sending a refresh request, the application queries the state of the refresh from CSIPRefresh.

    CSIPRefresh provides @@ -148,7 +148,7 @@ dialog. The CSIPRegistrationBinding and CSIPSubscribeDialogAssoc classes are used to update and terminate a refreshed REGISTER or SUBSCRIBE.

    Managing HTTP digest security settings

    - +

    An application must create an instance of the CSIP class to use CSIPHttpDigest. The CSIPHttpDigest class manages HTTP digest security settings and contains only static functions.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A2EFD9AD-F230-545C-8C5D-193F717B9FE2_d0e34881_href.png Binary file Symbian3/SDK/Source/GUID-A2EFD9AD-F230-545C-8C5D-193F717B9FE2_d0e34881_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A2EFD9AD-F230-545C-8C5D-193F717B9FE2_d0e35060_href.png Binary file Symbian3/SDK/Source/GUID-A2EFD9AD-F230-545C-8C5D-193F717B9FE2_d0e35060_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A2F691C8-9525-4028-BF82-70E9D50630C6.dita --- a/Symbian3/SDK/Source/GUID-A2F691C8-9525-4028-BF82-70E9D50630C6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A2F691C8-9525-4028-BF82-70E9D50630C6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,8 +15,8 @@ prompt the user to select the connection.

    To prompt the user select the destination network:

     - -Start the connection + +Start the connection with RConnection::Start(ECommDbDialogPrefPrompt). RConnection handle is returned to the application. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A308643D-6EEA-5C41-BD9C-5DA76EE83BA6_d0e158775_href.jpg Binary file Symbian3/SDK/Source/GUID-A308643D-6EEA-5C41-BD9C-5DA76EE83BA6_d0e158775_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A308643D-6EEA-5C41-BD9C-5DA76EE83BA6_d0e163797_href.jpg Binary file Symbian3/SDK/Source/GUID-A308643D-6EEA-5C41-BD9C-5DA76EE83BA6_d0e163797_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A3155AA1-8D42-5855-AD49-089DC510BCB0_d0e364110_href.png Binary file Symbian3/SDK/Source/GUID-A3155AA1-8D42-5855-AD49-089DC510BCB0_d0e364110_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A3155AA1-8D42-5855-AD49-089DC510BCB0_d0e383259_href.png Binary file Symbian3/SDK/Source/GUID-A3155AA1-8D42-5855-AD49-089DC510BCB0_d0e383259_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A3301ED7-8FD5-580B-B365-4BE12FF2F3AA.dita --- a/Symbian3/SDK/Source/GUID-A3301ED7-8FD5-580B-B365-4BE12FF2F3AA.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -source

    source source-file-list

    Use the source statement to specify source files.

    Each source statement may specify an arbitrary number of source files. Each source file should be specified including its extension, e.g. hello.cpp.

    There may be an arbitrary number of source statements in the project description file relative to each sourcepath.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A331AA9C-ECEC-4497-B45A-7C08845DE0A4_d0e4606_href.png Binary file Symbian3/SDK/Source/GUID-A331AA9C-ECEC-4497-B45A-7C08845DE0A4_d0e4606_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A331AA9C-ECEC-4497-B45A-7C08845DE0A4_d0e4733_href.png Binary file Symbian3/SDK/Source/GUID-A331AA9C-ECEC-4497-B45A-7C08845DE0A4_d0e4733_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A3B58436-07E4-565B-800B-86435D205461.dita --- a/Symbian3/SDK/Source/GUID-A3B58436-07E4-565B-800B-86435D205461.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A3B58436-07E4-565B-800B-86435D205461.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ bottoms out when an entity which is already trusted is reached; that entity is usually self signed. This process is illustrated in the figure below:

    Certificate chain - +

    The set of certificates from an EE up to a trusted root CA certificate is called a certificate chain. Once a certificate chain has been constructed ,the EE's key pair at the start can be validated.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A3EBB297-1494-579C-83D5-8FDBBD01B674.dita --- a/Symbian3/SDK/Source/GUID-A3EBB297-1494-579C-83D5-8FDBBD01B674.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A3EBB297-1494-579C-83D5-8FDBBD01B674.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ // blit only the piece of the bitmap indicated by bmpPieceRect TPoint pos(100,100); -gc.BitBlt(pos, bitmap, bmpPieceRect);
    Masked bitmap block transfer

    Masks can be used to select which parts of a bitmap are drawn by CBitmapContext::BitBltMasked().

    Masks can be used to not display pixels of the source bitmap if their corresponding mask pixel is black, or, alternatively, where the mask is white (called an inverted mask).

    The following figure shows successively a source bitmap, a mask, and the outcome when they are blitted with BitBltMasked().

    // Load the mask bitmap, just like any other +gc.BitBlt(pos, bitmap, bmpPieceRect);
    Masked bitmap block transfer

    Masks can be used to select which parts of a bitmap are drawn by CBitmapContext::BitBltMasked().

    Masks can be used to not display pixels of the source bitmap if their corresponding mask pixel is black, or, alternatively, where the mask is white (called an inverted mask).

    The following figure shows successively a source bitmap, a mask, and the outcome when they are blitted with BitBltMasked().

    // Load the mask bitmap, just like any other CFbsBitmap* maskBitmap = new (ELeave) CFbsBitmap(); CleanupStack::PushL(maskBitmap); User::LeaveIfError(maskBitmap-> diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A467E933-C4B4-5518-96D6-471E44B216B3.dita --- a/Symbian3/SDK/Source/GUID-A467E933-C4B4-5518-96D6-471E44B216B3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A467E933-C4B4-5518-96D6-471E44B216B3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Advanced Pond GuideThis topic describes Comms ponds in more detail.
    APIs

    The following diagram is a partial representation of the class relationships for RCommsBufPond.

    Comms pond -

    An RCommsBufPond instance manages a number of memory pools. Each pool contains buffers of identical size.

    The Comms Data Plane uses chains of buffers to transfer data up and down the stack. For more information about buffers and chains, see Comms Buffers (MBuf) and Comms Chains.

    Lifecycle

    1. c32start.exe reads the pond configuration stored in the c32start.ini file (see Pond Configuration Reference).

    2. c32start.exe provides the configuration information to the Root Server when initializing it. For more information about the C32 process, see Root Server.

    3. The Root Server creates the pond with the specified pools.

    4. The Root Server puts the pond handle in the TLS of each thread in c32exe.exe (see TLS Look-up Reduction Tutorial).

    Overview Comms Buffers (MBuf) +

    An RCommsBufPond instance manages a number of memory pools. Each pool contains buffers of identical size.

    The Comms Data Plane uses chains of buffers to transfer data up and down the stack. For more information about buffers and chains, see Comms Buffers (MBuf) and Comms Chains.

    Lifecycle

    1. c32start.exe reads the pond configuration stored in the c32start.ini file (see Pond Configuration Reference).

    2. c32start.exe provides the configuration information to the Root Server when initializing it. For more information about the C32 process, see Root Server.

    3. The Root Server creates the pond with the specified pools.

    4. The Root Server puts the pond handle in the TLS of each thread in c32exe.exe (see TLS Look-up Reduction Tutorial).

    Overview Comms Buffers (MBuf) and Comms Chains Pond Configuration Reference     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A4799558-AF8C-5E97-9B03-7D1C04FEC243.dita --- a/Symbian3/SDK/Source/GUID-A4799558-AF8C-5E97-9B03-7D1C04FEC243.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A4799558-AF8C-5E97-9B03-7D1C04FEC243.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,7 +37,7 @@ ...

    The dotted line in the following diagram shows the effect of this:

    - +

    Note that for process-relative handles, there is no need to use Duplicate(); the handle passed from thread A to thread B can be used directly.

    Making specific handles from generic handles

    There diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A4B391F0-058F-5B51-8D28-6A7B5C4A1BB9.dita --- a/Symbian3/SDK/Source/GUID-A4B391F0-058F-5B51-8D28-6A7B5C4A1BB9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -v5.1-v6.1 legacy Unicode resource format

    This page describes the resource file format introduced with the first Unicode version of Symbian OS, v5.1. This was based on the resource-file format used from the initial version of Symbian platform. The format uses no compression at all.

    Resource files in this format are generated by the resource compiler from v5.1 up to, but not including, Symbian OS v7.0.

    Number of bytes

    Description

    2

    This two-byte integer (in little-endian byte order) stores the file-position of the start of the resource index (see the last row of this table for a description of the resource index).

    2

    This two-byte integer (in little-endian byte order) stores 1 + the size of the resource index in bytes. The addition of 1 was to distinguish this resource file format from an older, now obsolete, resource-file format.

    [any]

    This contains the data for all the resources stored in order, one after another with no byte-padding between them. The binary data of each resource is laid out exactly as specified in the resource definition, with the exception that extra padding bytes (arbitrarily 0xab) are inserted in front of any Unicode text-string that would otherwise not be aligned on a two-byte boundary relative to the start of that resource’s data.

    (number_of_resources+1)*2

    This is the resource index which is a series of two-byte integers (in little-endian byte order), one for each resource in the resource file, each storing the file-position of that resource’s data (see row immediately above).

    This is followed by a two-byte integer (in little-endian byte order), which is the file-position one byte past the end of the last resource’s data. This is so that working out the length of a resource’s data is trivially done by subtracting the file-position stored in that resource’s index-entry from the file-position in the next index-entry.

    This last entry in the resource index, which stores the file-position one byte past the end of the last resource’s data, can also be thought of as storing the file-position of the start of the resource index. This means that resource files in this format have the same two-byte integer at the very start and at the very end of the file.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A4F3738C-CBFD-4151-9132-26FE05966715.dita --- a/Symbian3/SDK/Source/GUID-A4F3738C-CBFD-4151-9132-26FE05966715.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A4F3738C-CBFD-4151-9132-26FE05966715.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> CBA buttons Application with Options and Exit softkeys in portrait -and landscape views +and landscape views

    The Symbian platform uses Control Button Area (CBA) resources to set the options in the control pane above the softkeys. CBA resources map the text that appears above the softkeys in the control pane with commands that diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A50BBBE2-2E23-5AEE-BF53-9EF54FD7F00E_d0e334165_href.jpg Binary file Symbian3/SDK/Source/GUID-A50BBBE2-2E23-5AEE-BF53-9EF54FD7F00E_d0e334165_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A50BBBE2-2E23-5AEE-BF53-9EF54FD7F00E_d0e340631_href.jpg Binary file Symbian3/SDK/Source/GUID-A50BBBE2-2E23-5AEE-BF53-9EF54FD7F00E_d0e340631_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A51AB0B8-A13D-52D0-BEF8-435F76B30941_d0e184934_href.png Binary file Symbian3/SDK/Source/GUID-A51AB0B8-A13D-52D0-BEF8-435F76B30941_d0e184934_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A51AB0B8-A13D-52D0-BEF8-435F76B30941_d0e189931_href.png Binary file Symbian3/SDK/Source/GUID-A51AB0B8-A13D-52D0-BEF8-435F76B30941_d0e189931_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A51E334E-F410-55A9-AB07-82F8A1D113B4.dita --- a/Symbian3/SDK/Source/GUID-A51E334E-F410-55A9-AB07-82F8A1D113B4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A51E334E-F410-55A9-AB07-82F8A1D113B4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ the components.

    The Graphics package in the Symbian Foundation System Model - +

    This documentation only covers collections and components that are relevant to application developers.

    Technologies
      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A5693758-495B-598E-A514-24C48D459BB6.dita --- a/Symbian3/SDK/Source/GUID-A5693758-495B-598E-A514-24C48D459BB6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A5693758-495B-598E-A514-24C48D459BB6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ gc.DrawEllipse(ellipseRect); ...
    How to draw an arc

    An arc is drawn as a portion of an ellipse. As well as the ellipse rectangle, the call must specify the two points: the first defines one end of a line from the geometric center of the ellipse; the point of intersection between this line and the ellipse defines the start point of the arc. The second specified point acts in the same way for the end of the arc.

    Arc construction -

    The example code here shows how an arc is drawn in an anti-clockwise direction using constructionPoint1 and constructionPoint2 as the start to the end points.

    ... +

    The example code here shows how an arc is drawn in an anti-clockwise direction using constructionPoint1 and constructionPoint2 as the start to the end points.

    ... // draw an arc centered in the rectangle gc.DrawArc(ellipseRect,constructionPoint1,constructionPoint2); ...

    You can reverse the pair of construction point arguments to draw the other half of the ellipse. The construction points and screen center are also drawn, with dotted construction lines:

    ... @@ -42,7 +42,7 @@ gc.Plot(screenCenterPoint); ...
    Drawing pie slices

    The example code here shows how two pie slices are drawn. A pie slice is the area bounded by:

    an arc as used above

    the straight line from the start point from the geometric center of the ellipse

    the straight line from the end point from the geometric center of the ellipse

    Pie slice construction -

    Solid and patterned brush styles are used to fill the portions of the elliptical disc.

    1. Use SetBrushStyle() to set the brush style to solid.

    2. Use SetBrushColour() to set the brush color to black.

    3. Use DrawPie() to draw a pie slice.

    4. Use SetBrushStyle() to set the patterned brush style.

    5. Use DrawPie() and reverse the pair of construction point arguments so that the two pie slices together form a whole ellipse.

    ... +

    Solid and patterned brush styles are used to fill the portions of the elliptical disc.

    1. Use SetBrushStyle() to set the brush style to solid.

    2. Use SetBrushColour() to set the brush color to black.

    3. Use DrawPie() to draw a pie slice.

    4. Use SetBrushStyle() to set the patterned brush style.

    5. Use DrawPie() and reverse the pair of construction point arguments so that the two pie slices together form a whole ellipse.

    ... // draw a pie slice centered in the rectangle gc.SetBrushStyle(CGraphicsContext::ESolidBrush); gc.SetBrushColor(black); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A5756C5F-9C93-4949-8B60-03DCA1BAF683.dita --- a/Symbian3/SDK/Source/GUID-A5756C5F-9C93-4949-8B60-03DCA1BAF683.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A5756C5F-9C93-4949-8B60-03DCA1BAF683.dita Tue Jul 20 12:00:49 2010 +0100 @@ -74,7 +74,7 @@ Pop-up field - +

    Any combination of these types is possible within one form.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A5E152B2-F15C-4809-A52A-BCDDBCD93255_d0e36431_href.png Binary file Symbian3/SDK/Source/GUID-A5E152B2-F15C-4809-A52A-BCDDBCD93255_d0e36431_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A5E152B2-F15C-4809-A52A-BCDDBCD93255_d0e36599_href.png Binary file Symbian3/SDK/Source/GUID-A5E152B2-F15C-4809-A52A-BCDDBCD93255_d0e36599_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A5F65344-BE05-5295-85BB-E8114505FB82.dita --- a/Symbian3/SDK/Source/GUID-A5F65344-BE05-5295-85BB-E8114505FB82.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A5F65344-BE05-5295-85BB-E8114505FB82.dita Tue Jul 20 12:00:49 2010 +0100 @@ -74,7 +74,7 @@ and Durations

    The following diagram illustrates the alarm sound play intervals:

    ALARM SOUND PLAY INTERVALS - +

    Alarm play intervals define the toggling of alarm sound playing/stopping and alarm dialog show/hide when an alarm expires. It consists of a duration and an offset. The offset is the time, in minutes, from the beginning alarm diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6116E8B-9C4A-5B9E-AA8A-BE031408AA2F.dita --- a/Symbian3/SDK/Source/GUID-A6116E8B-9C4A-5B9E-AA8A-BE031408AA2F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,160 +0,0 @@ - - - - - -Defining -application icons, captions and properties -

    Introduction

    This document describes the properties -of an application that are defined in application registration files and in -other related files. Various resource structs declared in AppInfo.rh are -used to hold the definitions.

    -
    Application -icons

    Icons are used to represent applications and their associated -document files in the system shell or application launcher. If the phone's -UI supports embedding, icons may also be used to represent embedded documents.

    The -source icon files may be .bmp bitmaps, or a vector graphics -format. If bitmaps are used, they are built into a single .mbm file -(Symbian platform multiple bitmap file) as part of the build process, see start bitmap for details. -Different sizes of source bitmap should be supplied. The OS selects the most -appropriate icon size for the UI's current zoom state. This avoids the need -for the icon to be dynamically scaled when it is drawn at a different size. -Scaling small bitmaps generally results in a loss of quality. The required -icon sizes are specific to the UI.

    For each icon size, an image bitmap -and a mask bitmap are needed. The mask should be black for the parts of the -image that should be visible, and white for the transparent areas, where the -background should appear instead.

    In addition to .mbm icon -files, registration files also support vector graphics formats for instance .svg. -If the icon file is a vector graphics format, the number_of_icons value -in the CAPTION_AND_ICON_INFO struct is irrelevant.

    In -either case, the name of the icon file is specified in the LOCALISABLE_APP_INFO resource.

    Localising -icons

    Some applications may need to localise their icons and -captions.

    Icon filenames can be localised by defining them in .rls files. -There should be one .rls file per language supported. -In the LOCALISABLE_APP_INFO definition, the icon filenames -should be referred to by their symbolic identifiers, rather than as the strings -themselves. Conditional compilation statements are used in the resource file -to include the appropriate .rls file. See an -example registration file and icon/caption file. Captions are localised -using the same technique.

    -
    Application -captions

    An application's caption is the text displayed beside -its icon. Typically it is the application's name.

    Captions are defined -in the localisable icon/caption definition, which provides for short and long -captions. The short caption may be used in situations where screen space is -limited. Captions are localised in the same way as icon filenames, see above.

    -
    Filename

    Registration files must provide the filename, -excluding path and extension of the application's executable. This is needed -in order for the application architecture to be able to find and launch the -application. The application architecture expects it to be located in \sys\bin\ on -the same drive as the registration file.

    -
    Attributes

    Registration files have an attributes field -which is used to identify non-standard types of application. For instance, KAppIsControlPanelItem identifies -control panel-type applications. Refer to the documentation for -the targetted UI platform for other supported values.

    -
    Application -properties

    The following properties can be defined in registration -files. In C++ they can be retrieved using the RApaLsSession class. -Note that not all of these are supported by every UI.

    embeddability

    An -application can have one of the following attributes: KAppEmbeddable, KAppNotEmbeddable, -or KAppEmbeddableOnly. The other listed values (KAppEmbeddableUiOrStandAlone and KAppEmbeddableUiNotStandAlone) are not used. The default value is KAppNotEmbeddable. -Embeddable applications appear in lists of embeddable applications, see for -example RApaLsSession::GetEmbeddableApps(). A file with -the property KAppEmbeddableOnly appears in the embeddable -list, but not in the shell or application launcher.

      -

    • document embedding may -not be not supported by all UIs,

      • -

    • the embeddable and embeddable-only -properties should only be set for file-based applications, in other words, -applications that create embeddable documents.

      • -

    hidden

    Hidden applications run in the background. -They are not shown to the user and do not appear in the application launcher -or in the embeddable applications list.

    The default value is KAppNotHidden.

    newfile

    This -property indicates whether the application is document-based and supports -the creation of new files.

    The default value is KAppDoesNotSupportNewFile.

    launch

    Indicates -whether the application will be launched in the foreground so that it takes -focus, or in the background.

    -
    Default screen number

    This number identifies the -screen on which the application is displayed. It can be omitted if the phone -has a single screen. In v8.1b, the application can only ever appear on this -screen; this may change in later releases. For the Symbian emulator, screen -numbers are initialised in the window server initialisation file, wsini.ini.

    -
    UIDs

    Two -UIDs must be specified in the source registration file: UID2 and UID3. UID2 always -has the value KUidAppRegistrationResourceFile; UID3 is -the third UID of the application.

    -
    MIME support

    Multipurpose -Internet Mail Extensions, MIMEs, define a file format for transferring non-ASCII -data, such as graphics, audio and fax, over the Internet. The datatype_list section -lists the MIME types that the application supports, and the priority of support -that each type is given. When a file is opened, Symbian platform launches -the application which has the highest priority of support for the type of -data in the file.

    There are four priority levels, of which only EDataTypePriorityNormal or EDataTypePriorityLow should normally be used. For example, a text editor is good at editing text/plain -files, and would be given a priority of EDataTypePriorityNormal for -that file type. A web browser is less good at handling text files, and would -be assigned the lower priority EDataTypePriorityLow. So, -either application can be launched to handle a text file, however if both -applications are present, the text editor is launched in preference.

    EDataTypePriorityHigh should -only be assigned under exceptional conditions, for instance if no other application -could ever handle a particular MIME type as well.

    EDataTypePriorityLastResort should -also be used sparingly. Text editors are terrible at displaying HTML, and -would either have the priority EDataTypePriorityLastResort, -or would not support the type at all.

    Given two applications with -the same MIME type priority, Symbian platform arbitrarily launches one of -them.

    -
    View-specific information

    For view-based applications, -as an alternative to using an application-wide caption and icons, each view -in the application can define its own icon and captions. This is so that specific -application views can be launched directly from the phone's application launcher/shell. -This feature may not be supported by all phone UIs.

    The following -view-specific properties can be specified, using a VIEW_DATA resource -struct, declared in appinfo.rh:

      -

    • The view's UID.

      This -uniquely identifies the view within the application (in C++ this corresponds -to TVwsViewId::iViewUid). This must be specified.

      • -

    • The screen mode that -the view uses.

      A screen mode is a combination of screen rotation and -screen size. Screen modes are identified by an index; the first one is zero. -For the Symbian emulator, screen modes are initialised in the window server -initialisation file, wsini.ini. -The default value is zero.

      For example, on phones that use a flip-down -keypad, the screen mode changes when the flip is opened or closed. On such -phones, there may be a flip open and flip closed version of each view.

      • -

    • The number of icons -for the view.

      The icons are contained in the icon file. If the icon -file is a vector graphics format, the number_of_icons value -is irrelevant.

      • -

    • The view's caption.

      • -

    The view-specific information is defined in the view_list which -is an array of VIEW_DATA structs, one for each view in the -application. It can be accessed in C++ through the RApaLsSession class, -see for example RApaLsSession::GetAppViews(), and RApaLsSession::GetAppViewIcon().

    -
    Service list

    Server applications implement services -on behalf of client applications, using a server. They are new in v9.0 and -the motivation behind them is platform security. Because the client and the -server applications run in separate processes, their memory areas and private -data files are protected from each other.

    The service list is a list -of services offered by a server application. Each entry in the list consists -of a uid, which identifies the service, and the ID of another -resource (opaque_data) that describes how the service is -implemented. The latter is called opaque data because how it is used is up -to the server application, not the UI framework. For example, it might contain -the ID of a localised text resource for display in the UI, or the ID of a -resource struct that allows client code to distinguish between different implementations -of the service.

    The information defined in the service list can be -retrieved using the RApaLsSession class. For example, clients -can find out which server applications implement a particular service by calling RApaLsSession::GetServiceImplementationsLC().

    The opaque data may be non-localisable and therefore defined as a resource -in the registration file, or localisable and therefore defined as a resource -in the localisable icon/caption definition file, if one exists, or in the -UI resource file. If the localisable icon/caption definition file is used, -it must include a four character NAME and an RSS_SIGNATURE resource, -like most other resource files, and as it would no longer be the only resource -defined in the file, the LOCALISABLE_APP_INFO resource must -be given an ID, which must be specified in the registration file's localisable_resource_id field.

    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-10-1-6-1-1-4-1-6-1-7-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-10-1-6-1-1-4-1-6-1-7-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Simple controls and compound controls

    In addition to being window-owning or non-window-owning, each control is either a simple control or a compound control.

    Simple controls

    A simple control, such as a label or an image, is one which contains no other controls. A simple control may be window-owning or non-window-owning. The majority of simple controls, in practice, are non-window-owning.

    Compound controls

    A compound control is one which contains one or more simple or compound controls. Compound controls are also known as container controls and may be window-owning or non-window-owning.

    The controls contained by a compound control are its component controls. Components may also be window-owning or non-window-owning. The majority, in practice, are non-window-owning.

    The implementation of compound controls changed in version 9.1 of Symbian OS. The previous APIs and the old 'way of working' are still supported but do not support new automated features such as background drawing, font provision, layout managers and accumulated zoom.

    The new 'way of working' is currently used by UIQ v3.

    S60, MOAP and older versions of UIQ use the old scheme.

    Under the old (pre 9.1) scheme the way in which a compound control stored its component controls is not mandated by the framework. Controls derived from CCoeControl are free to store their components as they see fit. They have to implement the virtual function CCoeControl::CountComponentControls() to return the number of components, and also to provide CCoeControl::ComponentControl() to return the CCoeControl* pointing to a particular component. This is very flexible but places a greater burden on application developers and means that it is impossible for tools or agents to make assumptions about the internal structure of controls.

    Under the new (9.1 and onwards) scheme CCoeControl provides a storage mechanism and an API for adding, retrieving and removing components. Besides simplifying the API and making life easier for developers this ensures consistency which allows run-time agents, such as layout managers and skins managers, to act across all of the controls in the UI. The CCoeControl::CountComponentControls() and CCoeControl::ComponentControl() functions are now implemented by the base class. By default, CCoeControl also now takes responsibility for deleting its lodgers.

    The new scheme provides two methods for identifying component controls - one to be used by the parent, which gives each sibling component a unique ID, and one which allows each control within a view to have a UniqueHandle. The latter is primarily to enable resource driven view construction but is also useful for automated testing.

    The control framework (both old and new) provides logic to handle redrawing and the distribution of pointer events to component controls. A compound control must handle distribution of key events to its components. Non-window owning lodger components should not overlap* and must be contained within the extent of the compound control. This does not pose a restriction for most UI elements, such as buttons and labels, as they never need to overlap and never need to be displayed outside their containers.

    Component controls may themselves be compound. There is no limit on the number of levels of compounding.

    *Overlapping controls may be used in conjunction with MCoeControlHitTest. See How to write controls

    See also

    Run-time control hierarchy

    How to write controls

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-10-1-7-1-1-4-1-6-1-7-1-4-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-A62E89DE-0762-5827-856D-F20EEF46EE4B-GENID-1-10-1-7-1-1-4-1-6-1-7-1-4-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Simple controls and compound controls

    In addition to being window-owning or non-window-owning, each control is either a simple control or a compound control.

    Simple controls

    A simple control, such as a label or an image, is one which contains no other controls. A simple control may be window-owning or non-window-owning. The majority of simple controls, in practice, are non-window-owning.

    Compound controls

    A compound control is one which contains one or more simple or compound controls. Compound controls are also known as container controls and may be window-owning or non-window-owning.

    The controls contained by a compound control are its component controls. Components may also be window-owning or non-window-owning. The majority, in practice, are non-window-owning.

    The implementation of compound controls changed in version 9.1 of Symbian OS. The previous APIs and the old 'way of working' are still supported but do not support new automated features such as background drawing, font provision, layout managers and accumulated zoom.

    The new 'way of working' is currently used by UIQ v3.

    S60, MOAP and older versions of UIQ use the old scheme.

    Under the old (pre 9.1) scheme the way in which a compound control stored its component controls is not mandated by the framework. Controls derived from CCoeControl are free to store their components as they see fit. They have to implement the virtual function CCoeControl::CountComponentControls() to return the number of components, and also to provide CCoeControl::ComponentControl() to return the CCoeControl* pointing to a particular component. This is very flexible but places a greater burden on application developers and means that it is impossible for tools or agents to make assumptions about the internal structure of controls.

    Under the new (9.1 and onwards) scheme CCoeControl provides a storage mechanism and an API for adding, retrieving and removing components. Besides simplifying the API and making life easier for developers this ensures consistency which allows run-time agents, such as layout managers and skins managers, to act across all of the controls in the UI. The CCoeControl::CountComponentControls() and CCoeControl::ComponentControl() functions are now implemented by the base class. By default, CCoeControl also now takes responsibility for deleting its lodgers.

    The new scheme provides two methods for identifying component controls - one to be used by the parent, which gives each sibling component a unique ID, and one which allows each control within a view to have a UniqueHandle. The latter is primarily to enable resource driven view construction but is also useful for automated testing.

    The control framework (both old and new) provides logic to handle redrawing and the distribution of pointer events to component controls. A compound control must handle distribution of key events to its components. Non-window owning lodger components should not overlap* and must be contained within the extent of the compound control. This does not pose a restriction for most UI elements, such as buttons and labels, as they never need to overlap and never need to be displayed outside their containers.

    Component controls may themselves be compound. There is no limit on the number of levels of compounding.

    *Overlapping controls may be used in conjunction with MCoeControlHitTest. See How to write controls

    See also

    Run-time control hierarchy

    How to write controls

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A64625D4-F101-5DB7-896B-F91A21BABE01.dita --- a/Symbian3/SDK/Source/GUID-A64625D4-F101-5DB7-896B-F91A21BABE01.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A64625D4-F101-5DB7-896B-F91A21BABE01.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,12 +1,127 @@ - - - - - -Reclaiming Free Space

    This document discusses the benefits to be had, such as performance improvements, from performing a compaction operation.

    Purpose

    Database compaction frees up diskspace and improves overall performance when performing certain database operations.

    Database compaction

    Databases using database compaction will experience a performance improvement for some operations, such as DELETE. There will also be a better trade-off between performance and disk usage.

    Legacy databases will be automatically migrated to use the new default free space reclaim policy when they are used with the 9.5 version of Symbian SQL. The migration takes place the first time the legacy database is opened with the new version of Symbian SQL. The database will be configured to use the default free space reclaim policy from then on. Note: Such migration will not be possible (or necessary) for databases that are on read-only media, but these databases will still be readable by Symbian SQL.

    Databases can be configured to use a free space reclaim policy of their choice. There are three modes of database compaction:

    • background,

    • synchronous,

    • manual.

    The compaction mode is set when the database is created and cannot be changed later. Only the database creator can specify the compaction mode. This avoids the possibility of conflicting policy change requests by clients of shared databases. When a database compaction mode is not specified, background mode is the default mode.

    Background compaction

    Compaction activities are deferred and scheduled by the server allowing client requests that delete records to complete more quickly. This mode offers clients no guarantees on when space will be reclaimed. When under high load the server will defer reclamation indefinitely.

    The server maintains an EPriorityIdle active object for each open database that is set to background compaction mode.

    The amount of reclaimable disk space is retrieved after an SQL statement is executed on a database. If this value exceeds the compaction threshold then the database is marked as dirty by setting its active object as ready to run:

    • The compaction threshold is a server-wide parameter that specifies the amount of reclaimable disk space (in bytes) that must exist in a database before the server compacts that database. A default value for this threshold is supplied by Symbian but device creators can override this in the server configuration file.

    • Each active object contains a free pages threshold that is derived from the compaction threshold. The free pages threshold is the number of pages that must be in the database for it to be marked as dirty.

    • Each time a RSqlDatabase::Exec() or RSqlStatement::Exec() operation has been completed the number of free pages in the database is checked against the free pages threshold. If the threshold is met then the database is marked as dirty.

    Whenever the Symbian SQL server is idle (not processing a client request) runnable idle active objects are processed that cause free space to be reclaimed from the dirty databases:

    • Each active object reclaims no more pages from its database than the single reclaim limit. This limit is a server-wide parameter specifying the maximum number of free pages that the server will attempt to reclaim in one step and should be small enough to ensure that the server can remain responsive to client requests. An appropriate default value is supplied by Symbian but device creators can override this in the server configuration file.

    • Following the reclaim action an active object will again set itself as ready to run if the number of free pages following the reclaim meets the free pages threshold.

    • The idle priority active objects for background compaction continues to be processed until either:

      • there is no more free space left to reclaim,

      • a higher priority active object becomes ready to run.

    Scheduling of background compaction

    The server’s active scheduler maintains a priority queue for servicing the active objects. The scheduling algorithm is such that following the successful execution of any active object's RunL(), the scheduler will reset to the beginning of the queue. This has two implications:

    • There is an implicit priority scheme among the active objects for background compaction – a database opened earlier will always be given priority over one opened later due to its location in the queue.

    • Compaction of a later database in the queue cannot begin until an earlier database has been fully compacted. This is because the active scheduler resets to the beginning of the queue following every active object execution.

    With this lack of fair scheduling it is advised that certain situations are avoided:

    • Background compaction is not intended to be an antidote for critical disk space rescue scenarios – a fairer scheduling algorithm may help but the system would already be in severe difficulties by this stage.

    • The compaction operation itself requires free disk space and thus would be inoperable in critically low disk space situations. Thus a fairer scheduling algorithm would not help here.

    • background compaction is not designed to work efficiently when the server load is such that idle periods do not occur in sufficient quantity.

    Synchronous compaction

    compaction occurs at the end of the client request. A request is not completed until compaction has finished. This mode is equivalent to the compaction profile of previous versions of Symbian SQL.

    Manual compaction

    No automatic compaction occurs. This mode is intended for clients that wish to manage compaction directly.

    Clients wishing to exercise direct control over database compaction may select manual mode. The server performs no automated compaction in manual mode.

    Clients can request database compaction with RSqlDatabase::Compact(). The client can specify a limit to the number of bytes to reclaim. Compaction can be performed as either a synchronous or an asynchronous operation. Compact() can be called on either a “manual” or a “background” database (it can also be called on a “synchronous” database although this will have no effect).

    The database file size and the amount of reclaimable free space in the database can be retrieved with RSqlDatabase::Size(). This API supports clients wishing to trigger compaction based on either absolute free space or a proportion of free space in the database.

    SQL Overview Handling Blobs     \ No newline at end of file + + + + + +Reclaiming Free Space +

    This document discusses the benefits to be had, such as performance +improvements, from performing a compaction operation.

    +
    Purpose

    Database compaction frees up diskspace +and improves overall performance when performing certain database +operations.

    +
    Database +compaction

    Databases using database compaction will experience +a performance improvement for some operations, such as DELETE. There +will also be a better trade-off between performance and disk usage.

    Legacy databases will be automatically migrated to use the new +default free space reclaim policy when they are used with the 9.5 +version of Symbian SQL. The migration takes place the first time the +legacy database is opened with the new version of Symbian SQL. The +database will be configured to use the default free space reclaim +policy from then on. Note: Such migration will not be possible +(or necessary) for databases that are on read-only media, but these +databases will still be readable by Symbian SQL.

    Databases +can be configured to use a free space reclaim policy of their choice. +There are three modes of database compaction:

      +

    • background,

      • +

    • synchronous,

      • +

    • manual.

      • +

    The compaction mode is set when the database is created and +cannot be changed later. Only the database creator can specify the +compaction mode. This avoids the possibility of conflicting policy +change requests by clients of shared databases. When a database compaction +mode is not specified, background mode is the default mode.

    Background compaction

    Compaction activities are deferred and scheduled by the +server allowing client requests that delete records to complete more +quickly. This mode offers clients no guarantees on when space will +be reclaimed. When under high load the server will defer reclamation +indefinitely.

    The server maintains an EPriorityIdle active object for each open database that is set to background compaction +mode.

    The amount of reclaimable disk space is retrieved after +an SQL statement is executed on a database. If this value exceeds +the compaction threshold then the database is marked as dirty by setting its active object as ready to run:

      +

    • The compaction +threshold is a server-wide parameter that specifies the amount of +reclaimable disk space (in bytes) that must exist in a database before +the server compacts that database. A default value for this threshold +is supplied by Symbian but device creators can override this in the +server configuration file.

      • +

    • Each active +object contains a free pages threshold that is derived from +the compaction threshold. The free pages threshold is the number +of pages that must be in the database for it to be marked as dirty.

      • +

    • Each time a RSqlDatabase::Exec() or RSqlStatement::Exec() operation has been completed the number of free pages in the database +is checked against the free pages threshold. If the threshold is met +then the database is marked as dirty.

      • +

    Whenever the Symbian SQL server is idle (not processing a +client request) runnable idle active objects are processed that cause +free space to be reclaimed from the dirty databases:

      +

    • Each active +object reclaims no more pages from its database than the single reclaim +limit. This limit is a server-wide parameter specifying the maximum +number of free pages that the server will attempt to reclaim in one +step and should be small enough to ensure that the server can remain +responsive to client requests. An appropriate default value is supplied +by Symbian but device creators can override this in the server configuration +file.

      • +

    • Following the +reclaim action an active object will again set itself as ready to +run if the number of free pages following the reclaim meets the free +pages threshold.

      • +

    • The idle priority +active objects for background compaction continues to be processed +until either:

        +

      • there is no +more free space left to reclaim,

        • +

      • a higher priority +active object becomes ready to run.

        • +
      • +

    Scheduling of background compaction

    The server’s active +scheduler maintains a priority queue for servicing the active objects. +The scheduling algorithm is such that following the successful execution +of any active object's RunL(), the scheduler will +reset to the beginning of the queue. This has two implications:

      +

    • There is an +implicit priority scheme among the active objects for background compaction +– a database opened earlier will always be given priority over one +opened later due to its location in the queue.

      • +

    • Compaction of +a later database in the queue cannot begin until an earlier database +has been fully compacted. This is because the active scheduler resets +to the beginning of the queue following every active object execution.

      • +

    With this lack of fair scheduling it is advised that +certain situations are avoided:

      +

    • Background compaction +is not intended to be an antidote for critical disk space rescue scenarios +– a fairer scheduling algorithm may help but the system would already +be in severe difficulties by this stage.

      • +

    • The compaction +operation itself requires free disk space and thus would be inoperable +in critically low disk space situations. Thus a fairer scheduling +algorithm would not help here.

      • +

    • background compaction +is not designed to work efficiently when the server load is such that +idle periods do not occur in sufficient quantity.

      • +

    Synchronous compaction

    compaction occurs at the end of the client request. A request +is not completed until compaction has finished. This mode is equivalent +to the compaction profile of previous versions of Symbian SQL.

    Manual compaction

    No automatic compaction occurs. This mode is intended for +clients that wish to manage compaction directly.

    Clients wishing +to exercise direct control over database compaction may select manual +mode. The server performs no automated compaction in manual mode.

    Clients can request database compaction with RSqlDatabase::Compact(). The client can specify a limit to the number of bytes to reclaim. +Compaction can be performed as either a synchronous or an asynchronous +operation. Compact() can be called on either a “manual” +or a “background” database (it can also be called on a “synchronous” +database although this will have no effect).

    The database +file size and the amount of reclaimable free space in the database +can be retrieved with RSqlDatabase::Size(). This +API supports clients wishing to trigger compaction based on either +absolute free space or a proportion of free space in the database.

    +     +SQL +Overview + +Handling Blobs +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A668442E-0768-5AF1-829B-A80864756A0B.dita --- a/Symbian3/SDK/Source/GUID-A668442E-0768-5AF1-829B-A80864756A0B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -bytepaircompresstarget

    bytepaircompresstarget

    Use the bytepaircompresstarget statement to specify that the target executable should be compressed using the bytepair algorithm.

    Bytepair compression allows faster decompression than the default Deflate, Huffman+LZ77 algorithm and supports demand paging by performing compression and decompression of code in independent 4kbyte pages.

    See also inflatecompresstarget.

    See also compresstarget.

    See also nocompresstarget.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e40575_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e40575_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e40733_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e40733_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e58819_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e58819_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e58962_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e58962_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e67789_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e67789_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e67853_href.png Binary file Symbian3/SDK/Source/GUID-A69D2707-CB47-42C2-A6E9-5FB9BD86A30B_d0e67853_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6C9E7DF-1ACF-4768-851E-350E3DADEC56_d0e57198_href.png Binary file Symbian3/SDK/Source/GUID-A6C9E7DF-1ACF-4768-851E-350E3DADEC56_d0e57198_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6C9E7DF-1ACF-4768-851E-350E3DADEC56_d0e57341_href.png Binary file Symbian3/SDK/Source/GUID-A6C9E7DF-1ACF-4768-851E-350E3DADEC56_d0e57341_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6EE8A2A-8B17-5D3A-A9B9-C8D25C92EA21_d0e359404_href.png Binary file Symbian3/SDK/Source/GUID-A6EE8A2A-8B17-5D3A-A9B9-C8D25C92EA21_d0e359404_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6EE8A2A-8B17-5D3A-A9B9-C8D25C92EA21_d0e388397_href.png Binary file Symbian3/SDK/Source/GUID-A6EE8A2A-8B17-5D3A-A9B9-C8D25C92EA21_d0e388397_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e393431_href.png Binary file Symbian3/SDK/Source/GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e393431_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e397226_href.png Binary file Symbian3/SDK/Source/GUID-A6F1F6AC-5D3C-5055-AEF1-B64671941BCB_d0e397226_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A719FDFA-903B-5340-AA47-9E5B22DBB253_d0e185379_href.png Binary file Symbian3/SDK/Source/GUID-A719FDFA-903B-5340-AA47-9E5B22DBB253_d0e185379_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A719FDFA-903B-5340-AA47-9E5B22DBB253_d0e190376_href.png Binary file Symbian3/SDK/Source/GUID-A719FDFA-903B-5340-AA47-9E5B22DBB253_d0e190376_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A780F684-0F67-4A7F-B766-E69A5223F917_d0e55415_href.png Binary file Symbian3/SDK/Source/GUID-A780F684-0F67-4A7F-B766-E69A5223F917_d0e55415_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A780F684-0F67-4A7F-B766-E69A5223F917_d0e55558_href.png Binary file Symbian3/SDK/Source/GUID-A780F684-0F67-4A7F-B766-E69A5223F917_d0e55558_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A837D8F6-B9D3-5119-8C63-51772B388999.dita --- a/Symbian3/SDK/Source/GUID-A837D8F6-B9D3-5119-8C63-51772B388999.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,15 +0,0 @@ - - - - - -Tools and -Utilities -

    The guide describe the tools for developing and building programs.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A869BA79-5916-5B60-A02B-EF7D7CCA8C45.dita --- a/Symbian3/SDK/Source/GUID-A869BA79-5916-5B60-A02B-EF7D7CCA8C45.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A869BA79-5916-5B60-A02B-EF7D7CCA8C45.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> How to control Application Level Roaming for SIP Profiles

    Application Level Roaming (ALR) is a facility which allows a SIP Profile to switch between service providers by using Internet Access Points (IAPs). By default, all SIP clients allow the SIP profiles they are using to roam across IAPs.

    To restrict roaming for a SIP profile to a set of IAPs, configure the profile with a Service Network Access Point (SNAP) ID. A SNAP ID is a unique identifier for a set of IAPs. The SIP profile store must include the SNAP ID that can be used by the SIP profile while roaming.

    Use the CSipProfileAlrController and MSipProfileAlrObserver classes to control ALR.

    To register for ALR events, use an instance of the CSipProfileAlrController class and implement the MSipProfileAlrObserver interface to register for ALR events. When registered for the ALR event, the MSipProfileAlrObserver interface notifies the client when a SIP profile used by the client tries to migrate to another IAP. Then the client can allow or disallow the migration request using the CSipProfileAlrController::AllowMigrationL() or CSipProfileAlrController::DisallowMigrationL() functions.

    The following illustration shows the call flow of enabling a SIP profile configured with a SNAP ID.

    Call flow of enabling a SIP profile with a SNAP ID -

    When the SIP profile is registered with a SNAP ID, you can allow the SIP profile to migrate to another IAP within the SNAP.

    In the following illustration, the SIP profile is deregistered after migrating to another IAP. To use it again, you must register the profile again.

    The following illustration shows the call flow of SIP profile migration.

    +

    When the SIP profile is registered with a SNAP ID, you can allow the SIP profile to migrate to another IAP within the SNAP.

    In the following illustration, the SIP profile is deregistered after migrating to another IAP. To use it again, you must register the profile again.

    The following illustration shows the call flow of SIP profile migration.

    Call flow of migrating a SIP profile to another IAP -     \ No newline at end of file + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A87610FF-2FBC-4BA3-8F6B-0BBB441F8066.dita --- a/Symbian3/SDK/Source/GUID-A87610FF-2FBC-4BA3-8F6B-0BBB441F8066.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A87610FF-2FBC-4BA3-8F6B-0BBB441F8066.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ Hardware Resource Manager's Architectural Relationships - +

    Client APIs

    HWRM provides client APIs that can control various hardware elements. It also provides callback pointers, so that the client applications can register to receive notification on the hardware status diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A89A50B6-2A3B-54E1-8157-6CC86AFE4A57_d0e357640_href.png Binary file Symbian3/SDK/Source/GUID-A89A50B6-2A3B-54E1-8157-6CC86AFE4A57_d0e357640_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A89A50B6-2A3B-54E1-8157-6CC86AFE4A57_d0e386633_href.png Binary file Symbian3/SDK/Source/GUID-A89A50B6-2A3B-54E1-8157-6CC86AFE4A57_d0e386633_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A8C80AA1-42CF-5866-B223-FCE1AEC9DF63_d0e304305_href.jpg Binary file Symbian3/SDK/Source/GUID-A8C80AA1-42CF-5866-B223-FCE1AEC9DF63_d0e304305_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A8C80AA1-42CF-5866-B223-FCE1AEC9DF63_d0e310777_href.jpg Binary file Symbian3/SDK/Source/GUID-A8C80AA1-42CF-5866-B223-FCE1AEC9DF63_d0e310777_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A8ECAA53-9094-5C0A-8893-2757559C15F0.dita --- a/Symbian3/SDK/Source/GUID-A8ECAA53-9094-5C0A-8893-2757559C15F0.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -epocstacksize

    epocstacksize stacksize

    Use the epocstacksize statement to specify a stack size for your executable other than the default 8KB.

    The maximum stack size is 80KB.

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

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A92CE0FF-113F-55BE-B5EF-7E5C629A4557_d0e169220_href.jpg Binary file Symbian3/SDK/Source/GUID-A92CE0FF-113F-55BE-B5EF-7E5C629A4557_d0e169220_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A92CE0FF-113F-55BE-B5EF-7E5C629A4557_d0e174234_href.jpg Binary file Symbian3/SDK/Source/GUID-A92CE0FF-113F-55BE-B5EF-7E5C629A4557_d0e174234_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A947B5A8-9138-4FA2-B8D8-2850AEB2F38C.dita --- a/Symbian3/SDK/Source/GUID-A947B5A8-9138-4FA2-B8D8-2850AEB2F38C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A947B5A8-9138-4FA2-B8D8-2850AEB2F38C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,9 +14,9 @@

    Battery pane displays the remaining energy level of the battery, using a graphical indicator. It also acts as a charging indicator. The battery indicator is visible in all applications.

    - + Battery pane - +

    The battery pane is not accessible to applications.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A950288B-D9D8-59E3-9F4C-0AEE2FC77E38_d0e276053_href.jpg Binary file Symbian3/SDK/Source/GUID-A950288B-D9D8-59E3-9F4C-0AEE2FC77E38_d0e276053_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A950288B-D9D8-59E3-9F4C-0AEE2FC77E38_d0e280892_href.jpg Binary file Symbian3/SDK/Source/GUID-A950288B-D9D8-59E3-9F4C-0AEE2FC77E38_d0e280892_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A95CDFDE-285F-5DE2-AADE-29B2B9663757.dita --- a/Symbian3/SDK/Source/GUID-A95CDFDE-285F-5DE2-AADE-29B2B9663757.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-A95CDFDE-285F-5DE2-AADE-29B2B9663757.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -The object index

    An object index is used to generate handle-numbers for reference counting objects.

    An object index is an instance of a CObjectIx class.

    An object index acts as a collector of reference counting objects but, unlike an object container, it does not act as a container for them. The difference is emphasised by the fact that removing a reference counting object from its object container causes that reference counting object to be destroyed, while removing it from an object index causes it to be closed.

    An object index can hold reference counting objects which belong to different object containers. The same reference counting object can also be added to an object index any number of times; each is regarded as a different instance of that object and each instance generates a different handle-number.

    CObjectIx::AddL() adds a reference counting object to an object index, and is the way in which a unique handle-number can be generated for that object. A handle-number is the way in which an object which is owned or managed by another thread or process can be identified. For example, on the server side, the object representing a thread (a DThread) maintains an object index for all objects which are open in that thread. Semaphores, mutexes and other threads are examples. Typically, user code running in that thread will have handles, RHandleBase derived types, open on those objects.

    The following drawing shows the idea.

    An object index is implemented as an array where each element of the array contains a pointer to the reference counting object. An object index can index up to 32,768 (0x8000) reference counting objects.

    See also:

    • CObjectIx

    • CObjectConIx

    • CObjectCon

    • CObject

    \ No newline at end of file +The object index

    An object index is used to generate handle-numbers for reference counting objects.

    An object index is an instance of a CObjectIx class.

    An object index acts as a collector of reference counting objects but, unlike an object container, it does not act as a container for them. The difference is emphasised by the fact that removing a reference counting object from its object container causes that reference counting object to be destroyed, while removing it from an object index causes it to be closed.

    An object index can hold reference counting objects which belong to different object containers. The same reference counting object can also be added to an object index any number of times; each is regarded as a different instance of that object and each instance generates a different handle-number.

    CObjectIx::AddL() adds a reference counting object to an object index, and is the way in which a unique handle-number can be generated for that object. A handle-number is the way in which an object which is owned or managed by another thread or process can be identified. For example, on the server side, the object representing a thread (a DThread) maintains an object index for all objects which are open in that thread. Semaphores, mutexes and other threads are examples. Typically, user code running in that thread will have handles, RHandleBase derived types, open on those objects.

    The following drawing shows the idea.

    An object index is implemented as an array where each element of the array contains a pointer to the reference counting object. An object index can index up to 32,768 (0x8000) reference counting objects.

    See also:

    • CObjectIx

    • CObjectConIx

    • CObjectCon

    • CObject

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A95FEDD4-106A-5E14-8B64-3E2882C76666_d0e246388_href.png Binary file Symbian3/SDK/Source/GUID-A95FEDD4-106A-5E14-8B64-3E2882C76666_d0e246388_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A95FEDD4-106A-5E14-8B64-3E2882C76666_d0e251347_href.png Binary file Symbian3/SDK/Source/GUID-A95FEDD4-106A-5E14-8B64-3E2882C76666_d0e251347_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A98F7AA2-A908-527E-9AEC-54DDD10A49C1.dita --- a/Symbian3/SDK/Source/GUID-A98F7AA2-A908-527E-9AEC-54DDD10A49C1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -secureid

    secureid secureid

    This keyword specifies the secure identifier of the executable.

    Each executable contains a secure identifier, which is guaranteed to be locally unique (i.e. in the phone where it is installed).

    The secure identifier (SID) may be used when verifying an executable's rights of access to system resources. It is also used to form the path name for an executable's private data area.

    The secureid need not be explicitly specified in the .mmp file, but if it is omitted, then the value of the UID3, specified elsewhere in the .mmp file, is used. If the UID3 is not specified, then the secureid will take the value KNullUID.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A9BFB95C-E2B0-5CD0-8B39-C448E3C81400_d0e333278_href.png Binary file Symbian3/SDK/Source/GUID-A9BFB95C-E2B0-5CD0-8B39-C448E3C81400_d0e333278_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A9BFB95C-E2B0-5CD0-8B39-C448E3C81400_d0e339744_href.png Binary file Symbian3/SDK/Source/GUID-A9BFB95C-E2B0-5CD0-8B39-C448E3C81400_d0e339744_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A9E610B7-505C-41C4-9079-BC83C094982E_d0e11841_href.png Binary file Symbian3/SDK/Source/GUID-A9E610B7-505C-41C4-9079-BC83C094982E_d0e11841_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-A9E610B7-505C-41C4-9079-BC83C094982E_d0e11944_href.png Binary file Symbian3/SDK/Source/GUID-A9E610B7-505C-41C4-9079-BC83C094982E_d0e11944_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AA5DEEB2-0B13-5FA8-8494-EC2F5C654FEF.dita --- a/Symbian3/SDK/Source/GUID-AA5DEEB2-0B13-5FA8-8494-EC2F5C654FEF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AA5DEEB2-0B13-5FA8-8494-EC2F5C654FEF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,56 +1,53 @@ - - - - - -CentRepExample: -Using Central Repository for Persistent StorageThis example application demonstrates the usage of Central Repository -API for persistent storage. -
    Description

    Several -Symbian platform components have state and settings information that need -to be persistent. There is also a global state that needs to persist, for -example, default filenames, locale settings, user preferences.

    The -CentRep example application first registers a group of settings with the central -repository server. It uses E80000AD.txt, a UTF-16 format -text file to initialise the repository. This text file contains access control -structure and the initial content of the repository. It is recommended to -convert the initialisation text file into a binary file using the central -repository converter tool to speed up the execution.

    The application -creates a CRepository object using the CRepository::NewLC() method -to access a repository using its UID. It resets the whole repository using CRepository::Reset() method -with the contents in the initialisation file.

    Each setting stored -in the repository will have a unique key to identify the setting. This unique -key is used to read and change the setting by calling the CRepository::Get() and CRepository::Set() methods -respectively. The application moves these keys to a different location using CRepository::Move() method -and deletes them from their original location.

    The application also -creates another CRepository object to demonstrate that, at -any given point a repository cannot be opened with READ/WRITE access -by more than one client. In such situations, it is recommended to start a -transaction before a write operation using CRepository::StartTransaction() method. -A transaction guarantees the consistency and persistence of all values read -and written during the transaction.

    Finally, the application requests -the central repository server to notify any changes to the original settings.

    Related -APIs

      -

    • CRepository - Provides access to a repository.

      • -

    • CRepository::Get()

      • -

    • CRepository::Move()

      • -

    • CRepository::NewLC()

      • -

    • CRepository::Reset()

      • -

    • CRepository::Set()

      • -

    • CRepository::StartTransaction()

      • -
    -
    Download

    Click -on the following link to download the example: CentRepExample.zip

    Click: browse to view the example code.

    -
    Build

    The Symbian build process describes -how to build an application.

    The CentRepExample builds -an executable called CentRepExample.exe in the standard -location (\epoc32\release\winscw\<build_variant > for CodeWarrior). -After launching the executable, depending on the emulator you are using, you -may need to task away from the app launcher/shell screen to view the console.

    + + + + + +CentRepExample: Using Central Repository for Persistent StorageThis example application demonstrates the usage of Central +Repository API for persistent storage. +
    Description

    Several Symbian platform components have state and settings information +that need to be persistent. There is also a global state that needs +to persist, for example, default filenames, locale settings, user +preferences.

    The CentRep example application first registers +a group of settings with the central repository server. It uses E80000AD.txt, a UTF-16 format text file to initialise +the repository. This text file contains access control structure and +the initial content of the repository. It is recommended to convert +the initialisation text file into a binary file using the central +repository converter tool to speed up the execution.

    The application +creates a CRepository object using the CRepository::NewLC() method to access a repository using +its UID. It resets the whole repository using CRepository::Reset() method with the contents in the initialisation file.

    Each +setting stored in the repository will have a unique key to identify +the setting. This unique key is used to read and change the setting +by calling the CRepository::Get() and CRepository::Set() methods respectively. The application +moves these keys to a different location using CRepository::Move() method and deletes them from their original location.

    The +application also creates another CRepository object +to demonstrate that, at any given point a repository cannot be opened +with READ/WRITE access by more than one client. In such situations, +it is recommended to start a transaction before a write operation +using CRepository::StartTransaction() method. A +transaction guarantees the consistency and persistence of all values +read and written during the transaction.

    Finally, the application +requests the central repository server to notify any changes to the +original settings.

    Related APIs

      +

    • CRepository - Provides access to a repository.

      • +

    • CRepository::Get()

      • +

    • CRepository::Move()

      • +

    • CRepository::NewLC()

      • +

    • CRepository::Reset()

      • +

    • CRepository::Set()

      • +

    • CRepository::StartTransaction()

      • +
    +
    Download

    Click on the following link to download the example: CentRepExample.zip

    Click: browse to view the example code.

    +
    Build

    The Symbian build process describes how to build an application.

    The CentRepExample builds an +executable called CentRepExample.exe in the standard +location (\epoc32\release\winscw\<build_variant > for CodeWarrior). +After launching the executable, depending on the emulator you are +using, you may need to task away from the app launcher/shell screen +to view the console.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AA820231-5C46-46A1-A310-ABBA45593B1F_d0e143085_href.png Binary file Symbian3/SDK/Source/GUID-AA820231-5C46-46A1-A310-ABBA45593B1F_d0e143085_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AA820231-5C46-46A1-A310-ABBA45593B1F_d0e148175_href.png Binary file Symbian3/SDK/Source/GUID-AA820231-5C46-46A1-A310-ABBA45593B1F_d0e148175_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AA9611C0-9AFC-530B-9B50-0D6E600C8D3E.dita --- a/Symbian3/SDK/Source/GUID-AA9611C0-9AFC-530B-9B50-0D6E600C8D3E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,26 +0,0 @@ - - - - - -systemresource -

    systemresource resource-file-list

    -

    From v9.0, platform security requires projects to -specify the directory for the built resource. You need to use the start resource syntax -to do this..

    -

    Use the systemresource statement to specify resource files -for system components.

    -

    The makefile will build the resource file into epoc32\release\ platform \ variant \z\system\data\ for a WINSCW, WINS -or WINC build.

    -

    Each resource file should be given with its extension, e.g. squash.rss.

    -

    If more than one language is specified with the lang, -then each resource will be compiled multiple times, once for each language -specified.

    -

    For application projects, use the resource statement.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AB35BA46-87DB-59F0-9342-75550AD338B7_d0e184946_href.png Binary file Symbian3/SDK/Source/GUID-AB35BA46-87DB-59F0-9342-75550AD338B7_d0e184946_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AB35BA46-87DB-59F0-9342-75550AD338B7_d0e189943_href.png Binary file Symbian3/SDK/Source/GUID-AB35BA46-87DB-59F0-9342-75550AD338B7_d0e189943_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AB9A3EA2-2B99-4502-A161-8EE5BF477D41.dita --- a/Symbian3/SDK/Source/GUID-AB9A3EA2-2B99-4502-A161-8EE5BF477D41.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AB9A3EA2-2B99-4502-A161-8EE5BF477D41.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ recorder utility of the Multimedia Framework (MMF) to develop your application. To make use of the onboard camera to capture a video clip, the application needs to repeat the steps described in the illustration below.

    -The steps required to capture a video clip +The steps required to capture a video clip

    Important implementation considerations include:

    • Make sure you include the VideoRecorder.h and mmfcontrollerpluginresolver.h header diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AB9D7D52-BCF0-5E89-8A99-A6590FAD7AF6.dita --- a/Symbian3/SDK/Source/GUID-AB9D7D52-BCF0-5E89-8A99-A6590FAD7AF6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AB9D7D52-BCF0-5E89-8A99-A6590FAD7AF6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,8 @@

      Purpose

      This example shows how to implement a data recogniser. For more information about this example, see the Data Recogniser tutorial.

      Download

      Click on the following link to download the example: ExampleRecognizer.zip

      Click: browse to view the example code.

      -
      Class Summary
        +
        Class +Summary

        • CApaDataRecognizerType

        • RApaLsSession

        @@ -26,8 +27,7 @@ use the command line, open a command prompt, and set the current directory to the source code directory of the example. You can then build the example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld -build

        How to use bldmake and How to -use abld describe how to use the SBSv1 build tools.

        +build

      • For the emulator, the example builds an dll called examplerecognizer.dll in the epoc32\release\winscw\<udeb or urel>\ folder.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ABC01315-D65D-55EA-9D42-4DE6384D517D.dita --- a/Symbian3/SDK/Source/GUID-ABC01315-D65D-55EA-9D42-4DE6384D517D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ABC01315-D65D-55EA-9D42-4DE6384D517D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Position data and info classesThis document describes the basic and extended classes that hold position data.

      The Location Acquisition API defines a set of position data classes. Some of these classes store the co-ordinates of a location fix and others store information about course and positioning satellites. The API also defines position info classes that wrap the position data classes. These classes are used to pass data across the Location Acquisition API. Figure 1 illustrates the position data and position info classes with some of the most important methods.

      Figure 1 Position data and info classes -
      The position data classes

      • TCoordinate is the base class for all the position data classes. It holds latitude, longitude and altitude data. All positioning modules must provide latitude and longitude information, but not all modules are guaranteed to provide altitude information.

      • TLocality adds accuracy information to co-ordinates.

      • TPosition adds the time at which the location fix was obtained and also allows the average speed between two positions to be calculated.

      There are two additional position data classes that are not part of this position data class inheritance hierarchy.

      • TCourse holds bearing and current speed data.

      • TSatelliteData holds information on one of the satellites used to obtain the location fix.

      Note that it is a position info object and not a position data object that is passed across the Location Acquisition API. Client applications extract the position data object from the wrapper position info object.

      See Position data for a description of how the location data is represented inside the position data classes.

      The position info classes

      Client applications use three position info classes that wrap the position data classes:

      • TPositionInfo wraps a TPosition class

      • TPositionCourseInfo wraps a TCourse class

      • TPositionSatelliteInfo wraps a TSatelliteData class

      To get location information, a reference to an object of a class derived from TPositionInfoBase is passed in a call to RPositioner::NotifyPositionUpdate() or RPositioner::GetLastKnownPosition(). The position info class hierarchy allows simple location information (TPositionInfo), course information (TCourse Info) or satellite information (TSatelliteInfo) to be obtained via the same calls to the Location Acquisition API.

      HPositionGenericInfo

      HPositionGenericInfo is an extended position info class that allocates memory on the heap. Applications can use the class to retrieve additional position information from positioning hardware that can provide it (such as NMEA strings provided by Bluetooth GPS hardware).

      HPositionGenericInfo is only supported by the Location Server eposserver.exe. It can only be used by applications that link with lbs.lib. Not all PSYs support this class.

      See also

      Position data

      \ No newline at end of file +
      The position data classes

      • TCoordinate is the base class for all the position data classes. It holds latitude, longitude and altitude data. All positioning modules must provide latitude and longitude information, but not all modules are guaranteed to provide altitude information.

      • TLocality adds accuracy information to co-ordinates.

      • TPosition adds the time at which the location fix was obtained and also allows the average speed between two positions to be calculated.

      There are two additional position data classes that are not part of this position data class inheritance hierarchy.

      • TCourse holds bearing and current speed data.

      • TSatelliteData holds information on one of the satellites used to obtain the location fix.

      Note that it is a position info object and not a position data object that is passed across the Location Acquisition API. Client applications extract the position data object from the wrapper position info object.

      See Position data for a description of how the location data is represented inside the position data classes.

      The position info classes

      Client applications use three position info classes that wrap the position data classes:

      • TPositionInfo wraps a TPosition class

      • TPositionCourseInfo wraps a TCourse class

      • TPositionSatelliteInfo wraps a TSatelliteData class

      To get location information, a reference to an object of a class derived from TPositionInfoBase is passed in a call to RPositioner::NotifyPositionUpdate() or RPositioner::GetLastKnownPosition(). The position info class hierarchy allows simple location information (TPositionInfo), course information (TCourse Info) or satellite information (TSatelliteInfo) to be obtained via the same calls to the Location Acquisition API.

      HPositionGenericInfo

      HPositionGenericInfo is an extended position info class that allocates memory on the heap. Applications can use the class to retrieve additional position information from positioning hardware that can provide it (such as NMEA strings provided by Bluetooth GPS hardware).

      HPositionGenericInfo is only supported by the Location Server eposserver.exe. It can only be used by applications that link with lbs.lib. Not all PSYs support this class.

      See also

      Position data

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ABE77283-EED8-5A33-B574-3B771EF11086.dita --- a/Symbian3/SDK/Source/GUID-ABE77283-EED8-5A33-B574-3B771EF11086.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ABE77283-EED8-5A33-B574-3B771EF11086.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,49 +9,44 @@ --> -How -to Use ULogger with Comms -

      This tutorial summarises one approach for enabling, retrieving and post-processing -the ULogger logs -for Comms. ULogger is part of the Unified Trace framework which replaces other -logging mechanisms for Symbian platform including Flogger and -CDU.

      +How to Use ULogger with Comms +

      This tutorial summarizes one approach for enabling, retrieving +and post-processing the ULogger logs for Comms. ULogger +is part of the Unified Trace framework which replaces other logging +mechanisms for Symbian platform including Flogger and CDU.

      The Unified Trace framework has greater flexibility and speed compared to Flogger and CDU.

      -
      Introduction

      The Comms logging which has been migrated -to ULogger is as follows:

        -

      • Comms Framework Node -messages - creation and destruction of Nodes and messages between Nodes.

        • -

      • Mesh Machine messages

        • -

      • data to support the -SVG generation

        • -

      This logging replaces some of what was logged through the "LOG -CFNode * ", "LOG Mesh * " and "LOG ESock -* " tags. In the case of the ESock tag, the logging -which is written to ULogger is also written to CDU.

      This usage description -assumes that the development tools already include ULogger support.

      -
      Procedure - Using ULogger

      Requirements

      - For this tutorial, the code under observation must be run from EShell.

      - The following binaries must include logging:

        -

      • nodemessages.dll -

        • -

      • meshmachine.dll -

        • -

      • commsfw.dll

        • -

      • serverden.dll

        • -

      • esocksvr.dll

        • -

      To enable logging for a binary either use the UDEB version of the - binary or rebuild the binary with the SYMBIAN_TRACE_ENABLED macro -defined.

      +
      Introduction

      The Comms logging which has been migrated to ULogger is as follows:

        +

      • Comms Framework +Node messages - creation and destruction of Nodes and messages between +Nodes.

        • +

      • Mesh Machine +messages

        • +

      • data to support +the SVG generation

        • +

      This logging replaces some of what was logged through the +"LOG CFNode * ", "LOG Mesh * " and +"LOG ESock * " tags. In the case of the ESock tag, the logging which is written to ULogger is also written to +CDU.

      This usage description assumes that the development tools +already include ULogger support.

      Note: For more information, +see Symbian^3 Tools Guide > Debugging.

      +
      Procedure +- Using ULogger

      Requirements

      For this tutorial, +the code under observation must be run from EShell.

      The following binaries must include logging:

        +

      • nodemessages.dll

        • +

      • meshmachine.dll

        • +

      • commsfw.dll

        • +

      • serverden.dll

        • +

      • esocksvr.dll

        • +

      To enable logging for a binary either use the UDEB version +of the binary or rebuild the binary with the SYMBIAN_TRACE_ENABLED macro defined.

      Steps
        -

      1. Start -Eshell - ULogger only supports asynchronous logging, so -from EShell start a second instance of EShell.

        start eshell

        - This allows ULogger to be stopped even if the code under - observation does not exit normally.

        2. -

      2. Set -the ULogger Filters - To allow Comms logging enable the -following filters:

        +

      3. Start Eshell - ULogger only supports asynchronous logging, so from EShell start +a second instance of EShell.

        start eshell

        This allows ULogger to be stopped even if the +code under observation does not exit normally.

        4. +

      4. + Set the ULogger Filters - To allow Comms logging enable +the following filters:

        5. @@ -62,22 +57,24 @@

        194

        -

        Node Messages

        +

        Node Messages +

        195

        -

        Mesh Machine

        +

        Mesh Machine +

        196

        -

        SVG Logging - provides extra logging so -that 194 and 195 can be displayed in an SVG file -

        +

        SVG Logging - provides extra logging +so that 194 and 195 can be displayed in an +SVG file

        -

        The following filter is also useful: -

        +

        The following filter is also useful: +

        @@ -88,69 +85,66 @@

        3

         -

        Kernel Thread ID's - Thread and process -creation

        +

        Kernel Thread ID's - Thread and +process creation

        -

        Set these filters with the following command: -

        ulogger -efv 194 195 3 196 -
        5. -

      5. Start -ULogger - The following command starts ULogger with the -filter:

        +

        Set these filters with the following command:

        ulogger -efv 194 195 3 196 +
        6. +

      6. + Start ULogger - The following command starts ULogger + with the filter:

        ulogger -rv
        7. -

      7. Run -the code under observation - In the first Eshell session, -run the code to be tested or debugged.

        8. -

      8. Stop -ULogger - To stop ULogger and generate the logs, use the -command:

        ulogger -qv
        9. -

      9. Process -the binary logs into text - The log file created by ULogger -is in a binary format and is located in the c:\logs folder -on the device.

        To use the log file, -the file must be converted to a text format. -

        The Comms software has a decoder to interpret the -ULogger output for Comms. This decoder is an MS Windows-compatible -application and is located in …\os\commsfw\commsfwtools\. -

        An example command to run the decoder -is:

        utracedecoder - -message-def esockmessages.definition.txt ulogger.log > log.txt

        - The decoder uses a definition file to decipher the binary data -in the log, and the decoder has definition files configured -for the current scope of Comms logging. This example uses -the ESock messages definition file, which is located in - …\os\commsfw\commsfwtools\commstools\utracedecoder\data\esockmessages.definition.txt. -

        The output in log.txt -contains an interpretation of the original binary logs. -

        10. -

      10. Generating -the SVG diagram - The exchange of messages between Nodes -can be rendered into a diagram.

        From …\os\commsfw\commsfwtools\commstools\svg run - parseit.bat specifying the path to the -generated log.txt file:

        parseit.bat /log M:\path_to_log_file\log.txt +

      11. + Run the code under observation - In the first Eshell + session, run the code to be tested or debugged. +

        12. +

      12. + Stop ULogger - To stop ULogger and generate the + logs, use the command:

        ulogger -qv
        13. +

      13. + Process the binary logs into text - The log file + created by ULogger is in a binary format and is located +in the c:\logs folder on the +device.

        To use the log file, +the file must be converted to a text format. +

        The Comms software has a decoder +to interpret the ULogger output for Comms. This decoder +is an MS Windows-compatible application and is located + in …\os\commsfw\commsfwtools\. +

        An example command to run the decoder +is:

        utracedecoder - -message-def esockmessages.definition.txt ulogger.log > log.txt

        The decoder uses a definition file to decipher +the binary data in the log, and the decoder has definition +files configured for the current scope of Comms logging. +This example uses the ESock messages definition file, which + is located in …\os\commsfw\commsfwtools\commstools\utracedecoder\data\esockmessages.definition.txt.

        The output +in log.txt contains an interpretation of the original + binary logs.

        14. +

      14. + Generating the SVG diagram - The exchange of + messages between Nodes can be rendered into a diagram. +

        From …\os\commsfw\commsfwtools\commstools\svg run parseit.bat specifying +the path to the generated log.txt file:

        parseit.bat /log M:\path_to_log_file\log.txt Example SVG output from the Message Sequence Display Tool - +

        Key to the SVG diagram:

          -

        1. - Vertical black lines are tagged with names to represent node - lifetimes. For example: IPCpr -

          2. -

        2. - Vertical lines forking from the node lifetime lines are - MeshMachine activity lifetimes.

          3. -

        3. - Black horizontal lines are message deliveries.

          4. -

        4. - Green horizontal lines are message postings.

          5. -

        New message types can be added to the definition -files. See the documentation with the utracedecoder component. -

        15. +

      15. + Vertical black lines are tagged with names to represent +node lifetimes. For example: IPCpr

        16. +

      16. + Vertical lines forking from the node lifetime lines are + MeshMachine activity lifetimes. +

        17. +

      17. + Black horizontal lines are message deliveries. +

        18. +

      18. + Green horizontal lines are message postings. +

        19. +

      New message types can be added to the +definition files. See the documentation with the utracedecoder component. +

    -     -Unified Trace -Solution -How to Use -the ULogger Configuration File -     \ No newline at end of file + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AC3F5010-ECA6-4257-98B5-77FB26B4987F_d0e5230_href.png Binary file Symbian3/SDK/Source/GUID-AC3F5010-ECA6-4257-98B5-77FB26B4987F_d0e5230_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AC3F5010-ECA6-4257-98B5-77FB26B4987F_d0e5351_href.png Binary file Symbian3/SDK/Source/GUID-AC3F5010-ECA6-4257-98B5-77FB26B4987F_d0e5351_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AC5ADA77-EBA1-597E-A6B7-80157E9DE2B2_d0e184188_href.png Binary file Symbian3/SDK/Source/GUID-AC5ADA77-EBA1-597E-A6B7-80157E9DE2B2_d0e184188_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AC5ADA77-EBA1-597E-A6B7-80157E9DE2B2_d0e189178_href.png Binary file Symbian3/SDK/Source/GUID-AC5ADA77-EBA1-597E-A6B7-80157E9DE2B2_d0e189178_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AC7069ED-8CA5-55FC-9DF6-595C0505C672.dita --- a/Symbian3/SDK/Source/GUID-AC7069ED-8CA5-55FC-9DF6-595C0505C672.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AC7069ED-8CA5-55FC-9DF6-595C0505C672.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,4 +12,4 @@ Positioning Module StatusThis document describes positioning technology module status, which applications access through the Location Acquisition API.
    Purpose

    This document describes Positioning Module status, which applications access through the Location Acquisition API.

    Positioning Module status

    A Positioning Module has a status which is represented by a TPositionModuleStatus object. The status describes the low-level state of a Positioning Module, such as whether it is disabled, initialising, or ready to retrieve location data, as well as its data quality status.

    A change in Positioning Module status is indicated by a status event. Details of the event are held in a TPositionModuleStatusEvent object. Client applications can receive notification of status events from the location server.

    Figure 1 illustrates Positioning Module status and event classes.

    Figure 1. TPositionModuleStatus and TPositionModuleStatusEvent classes -

    TPositionModuleStatus

    TPositionModuleStatus describes the status of a Positioning Module. An application gets information about a Positioning Module's current status by calling RPositionServer::GetModuleStatus(). There are two status types - device status and data quality status.

    Device status

    Device status is the status of the hardware device utilised by a Positioning Module, such as the chipset used by an A-GPS Positioning Module.

    TPositionModuleStatus::DeviceStatus() returns the device status as a TPositionModuleStatus::TDeviceStatus value. The value returned can indicate a transient device status, such as whether the hardware is disabled, initialising, or ready. It can also indicate a more serious device error state.

    Data quality status

    Data quality status describes the accuracy of the location data that a Positioning Module is able to provide at a point in time.

    TPositionModuleStatus::DataQualityStatus() returns the data quality status as a TPositionModuleStatus::TDataQualityStatus value. This value indicates whether the quality of location data is normal (the ideal condition), partially degraded or completely degraded. Location data quality can become degraded because the mobile device has moved out of range of any base stations or is in a position where it cannot receive signals from positioning satellites. Note that loss of information quality does not indicate a device error, which would be flagged by a change in the device status.

    Positioning Module status events

    When a Positioning Module's status changes, a Positioning Module status event occurs.

    There are three types of Positioning Module status events:

    • Device status events

    • Data quality status events

    • System level events. These events indicate that a Positioning Module has been added or removed in the system.

    TPositionModuleStatusEvent

    An object of class TPositionModuleStatusEvent has two functions:

    • As the object on which an application defines the types of Positioning Module status events for which it requests notification. These are set by calling TPositionModuleStatusEvent::SetRequestedEvents() passing a TPositionModuleStatusEventBase::TModuleEvent bitmask value as a parameter to define the combination of events

    • As the object on which the location framework sets the type of events that have occurred. These are retrieved by calling TPositionModuleStatusEvent::OccurredEvents() and checking the returned TPositionModuleStatusEventBase::TModuleEvent value.

    Event notification

    An application calls RPositionServer::NotifyModuleStatusEvent() to receive notification of Positioning Module status changes, passing a reference to a TPositionModuleStatusEvent object on which it has set the requested events. An application also supplies a TRequestStatus object and optionally a TPositionModuleId object if status changes from only one Positioning Module are required.

    When the status of a Positioning Module changes, the client application is notified. The TPositionModuleStatusEvent object that was supplied to the location server now also contains details of the events that have occurred and these are obtained by calling TPositionModuleStatusEvent::OccurredEvents().

    The Positioning Module status is obtained by calling TPositionModuleStatusEvent::GetModuleStatus() providing a TPositionModuleStatus reference as a parameter.

    See How to Get Positioning Module Status Changes for an example.

    Uses of Positioning Module status

    Quality status events are useful for applications that need to modify their behaviour based on the quality of location information that can be received. For example, an application may need to show a message when a user moves into an area where the accuracy of location information is degraded to a lower quality than is required because of distance from a base station or inability to receive satellite signals.

    Device status events and system Positioning Module events are most useful to software components that perform administrative operations, such as taking a Positioning Module online or offline. The events can be used to notify when such an administrative operation is complete.

    Device status events can also be used to keep a user informed as to the status of a particular Positioning Module. For example, a phone status bar could be updated to show that GPS is active when location information is being received.

    See also

    Positioning Modules

    \ No newline at end of file +

    TPositionModuleStatus

    TPositionModuleStatus describes the status of a Positioning Module. An application gets information about a Positioning Module's current status by calling RPositionServer::GetModuleStatus(). There are two status types - device status and data quality status.

    Device status

    Device status is the status of the hardware device utilised by a Positioning Module, such as the chipset used by an A-GPS Positioning Module.

    TPositionModuleStatus::DeviceStatus() returns the device status as a TPositionModuleStatus::TDeviceStatus value. The value returned can indicate a transient device status, such as whether the hardware is disabled, initialising, or ready. It can also indicate a more serious device error state.

    Data quality status

    Data quality status describes the accuracy of the location data that a Positioning Module is able to provide at a point in time.

    TPositionModuleStatus::DataQualityStatus() returns the data quality status as a TPositionModuleStatus::TDataQualityStatus value. This value indicates whether the quality of location data is normal (the ideal condition), partially degraded or completely degraded. Location data quality can become degraded because the mobile device has moved out of range of any base stations or is in a position where it cannot receive signals from positioning satellites. Note that loss of information quality does not indicate a device error, which would be flagged by a change in the device status.

    Positioning Module status events

    When a Positioning Module's status changes, a Positioning Module status event occurs.

    There are three types of Positioning Module status events:

    • Device status events

    • Data quality status events

    • System level events. These events indicate that a Positioning Module has been added or removed in the system.

    TPositionModuleStatusEvent

    An object of class TPositionModuleStatusEvent has two functions:

    • As the object on which an application defines the types of Positioning Module status events for which it requests notification. These are set by calling TPositionModuleStatusEvent::SetRequestedEvents() passing a TPositionModuleStatusEventBase::TModuleEvent bitmask value as a parameter to define the combination of events

    • As the object on which the location framework sets the type of events that have occurred. These are retrieved by calling TPositionModuleStatusEvent::OccurredEvents() and checking the returned TPositionModuleStatusEventBase::TModuleEvent value.

    Event notification

    An application calls RPositionServer::NotifyModuleStatusEvent() to receive notification of Positioning Module status changes, passing a reference to a TPositionModuleStatusEvent object on which it has set the requested events. An application also supplies a TRequestStatus object and optionally a TPositionModuleId object if status changes from only one Positioning Module are required.

    When the status of a Positioning Module changes, the client application is notified. The TPositionModuleStatusEvent object that was supplied to the location server now also contains details of the events that have occurred and these are obtained by calling TPositionModuleStatusEvent::OccurredEvents().

    The Positioning Module status is obtained by calling TPositionModuleStatusEvent::GetModuleStatus() providing a TPositionModuleStatus reference as a parameter.

    See How to Get Positioning Module Status Changes for an example.

    Uses of Positioning Module status

    Quality status events are useful for applications that need to modify their behaviour based on the quality of location information that can be received. For example, an application may need to show a message when a user moves into an area where the accuracy of location information is degraded to a lower quality than is required because of distance from a base station or inability to receive satellite signals.

    Device status events and system Positioning Module events are most useful to software components that perform administrative operations, such as taking a Positioning Module online or offline. The events can be used to notify when such an administrative operation is complete.

    Device status events can also be used to keep a user informed as to the status of a particular Positioning Module. For example, a phone status bar could be updated to show that GPS is active when location information is being received.

    See also

    Positioning Modules

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ACA2AFE8-4872-42FA-A871-34EB80197495_d0e148518_href.png Binary file Symbian3/SDK/Source/GUID-ACA2AFE8-4872-42FA-A871-34EB80197495_d0e148518_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ACA2AFE8-4872-42FA-A871-34EB80197495_d0e153600_href.png Binary file Symbian3/SDK/Source/GUID-ACA2AFE8-4872-42FA-A871-34EB80197495_d0e153600_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ACD9E338-DF75-5811-B696-C3900B498218.dita --- a/Symbian3/SDK/Source/GUID-ACD9E338-DF75-5811-B696-C3900B498218.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ACD9E338-DF75-5811-B696-C3900B498218.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ Location Acquisition API.

    Figure 1. Location Acquisition API privacy classes. - +

    A requester is defined as an agent that requests location information. There are two requester types:

    • Service requesters

      A diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ACDED56F-38FE-491D-B019-BE2C53A75D28.dita --- a/Symbian3/SDK/Source/GUID-ACDED56F-38FE-491D-B019-BE2C53A75D28.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ACDED56F-38FE-491D-B019-BE2C53A75D28.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,50 +1,45 @@ - - - - - -Data -caging -

      Data caging means that the applications and the users have access only -to certain areas of the file system. In practice the applications can access -their own private folders and folders that are marked as open. It means, for -example, that one application cannot access the private folder and data of -another application. There are restricted file storage areas for system, private, -and resource data.

      -

      The file system has the following structure:

      -
        -

      • The \sys folder is the restricted system -area. You need AllFiles capability to read the content, and -Trusted Computing Base (TCB) capability to modify the content.

        -

        The subfolder \sys\bin\ contains all binaries (exe, dll, -etc.). All binaries must have a different name. An application can only be -launched from this subfolder.

        • -

      • The \private\ folder includes folders -for all applications.

        The \private\<SID>\ subfolder -contains private data only to be accessed by the application itself. SID is -determined by the Secure -Identifier of the process. Without any capabilities you can read and -write only in the application's own directory. You need AllFiles capability -to access all private directories. Backup software can read and write to this -directory.

        The \private\<SID>\import\ subfolder -is for resource files, such as registration files, that are not directly related -to the application. You can write into this subfolder only after it is created -and named correctly.

        Application registration resource files should -be installed in the \private\10003a3f\import\apps subfolder.

        -
        • -

      • The \resource folder is for sharing -resource files. This data can be icons, bitmaps, and other material useful -for all the applications. You do not need any capabilities to read these files. -You need TCB capability to modify the content.

        ECom -registration resource files should be installed in the \resource\plugins subfolder.

        -
        • -
      -

      For more information, see File -locations.

      + + + + + +Data caging +

      Data caging means that the applications and the users have access +only to certain areas of the file system. In practice the applications +can access their own private folders and folders that are marked as +open. It means, for example, that one application cannot access the +private folder and data of another application. There are restricted +file storage areas for system, private, and resource data.

      +

      The file system has the following structure:

      +
        +

      • The \sys folder is the restricted +system area. You need AllFiles capability to read +the content, and Trusted Computing Base (TCB) capability +to modify the content.

        The subfolder \sys\bin\ contains all binaries (exe, dll, etc.). All binaries must have a different name. An application +can only be launched from this subfolder.

        • +

      • The \private\ folder includes +folders for all applications.

        The \private\<SID>\ subfolder contains private data only to be accessed by the application +itself. SID is determined by the Secure Identifier of the process. Without any capabilities +you can read and write only in the application's own directory. You +need AllFiles capability to access all private directories. +Backup software can read and write to this directory.

        The \private\<SID>\import\ subfolder is for resource +files, such as registration files, that are not directly related to +the application. You can write into this subfolder only after it is +created and named correctly.

        Application registration +resource files should be installed in the \private\10003a3f\import\apps subfolder.

        • +

      • The \resource folder is for +sharing resource files. This data can be icons, bitmaps, and other +material useful for all the applications. You do not need any capabilities +to read these files. You need TCB capability to modify +the content.

        ECom registration resource files should be +installed in the \resource\plugins subfolder.

        +
        • +
      +

      For more information, see File locations.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AD5C89AC-51CD-5CC0-961C-62F38E9BEA33.dita --- a/Symbian3/SDK/Source/GUID-AD5C89AC-51CD-5CC0-961C-62F38E9BEA33.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --verbose

      This option pipes to STDOUT the calls to tools that a particular build step is making, and can be useful in determining exactly where an error occurs during the build process.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AD95D78A-9323-5E97-96C4-FB4872B66755_d0e144346_href.png Binary file Symbian3/SDK/Source/GUID-AD95D78A-9323-5E97-96C4-FB4872B66755_d0e144346_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AD95D78A-9323-5E97-96C4-FB4872B66755_d0e149436_href.png Binary file Symbian3/SDK/Source/GUID-AD95D78A-9323-5E97-96C4-FB4872B66755_d0e149436_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADA36DA0-4E5D-483D-8AA7-C10A8E55ADD2_d0e68734_href.png Binary file Symbian3/SDK/Source/GUID-ADA36DA0-4E5D-483D-8AA7-C10A8E55ADD2_d0e68734_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADA36DA0-4E5D-483D-8AA7-C10A8E55ADD2_d0e68758_href.png Binary file Symbian3/SDK/Source/GUID-ADA36DA0-4E5D-483D-8AA7-C10A8E55ADD2_d0e68758_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADB3FA27-1DC0-4A04-A443-A174EDADF49D_d0e40470_href.png Binary file Symbian3/SDK/Source/GUID-ADB3FA27-1DC0-4A04-A443-A174EDADF49D_d0e40470_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADB3FA27-1DC0-4A04-A443-A174EDADF49D_d0e40628_href.png Binary file Symbian3/SDK/Source/GUID-ADB3FA27-1DC0-4A04-A443-A174EDADF49D_d0e40628_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADCDEFF9-4B1D-5E46-A63B-808192123E15_d0e168926_href.jpg Binary file Symbian3/SDK/Source/GUID-ADCDEFF9-4B1D-5E46-A63B-808192123E15_d0e168926_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADCDEFF9-4B1D-5E46-A63B-808192123E15_d0e173940_href.jpg Binary file Symbian3/SDK/Source/GUID-ADCDEFF9-4B1D-5E46-A63B-808192123E15_d0e173940_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ADDF9C0F-32D3-5CB1-B3B5-2FAD3A4EC278.dita --- a/Symbian3/SDK/Source/GUID-ADDF9C0F-32D3-5CB1-B3B5-2FAD3A4EC278.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Overview of GUI app building

      A Symbian platform GUI application has several components:

      • an application executable, which is an EXE that uses the GUI framework

      • a registration file, which contains non-localisable information

      • optional localisable information, provided by one or more localisable resource files and icon files

      To appear on the shell, a GUI application (e.g. AppName.exe) must be located in the sys\bin directory. Applications built into the ROM must provide their registration files (e.g. AppName_reg.rsc) in the \private\10003a3f\apps directory, whilst applications installed via Software Install must provide their registration files in \private\10003a3f\import\apps. Resource files (e.g. AppName.rss and AppName_loc.rss) should be located in the resource\apps directory.

      For further information on TARGETPATHs see this table.

      The following pages discuss the special configuration issues associated with building for GUI application targets.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE3BE603-21ED-5DEA-B1E9-0F1ADBED06D0.dita --- a/Symbian3/SDK/Source/GUID-AE3BE603-21ED-5DEA-B1E9-0F1ADBED06D0.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,16 +0,0 @@ - - - - - -Build-time variants

      It is a common requirement to be able to build more than one variant of a program from a single set of source code. For example, you might have evaluation and full variants of a program that are identical in most respects, but which differ in a few features; or might want to build a program for more than one platform, with some features being present on platform but not on the other.

      A traditional way to handle this requirement is to use the pre-preprocessor to conditionally include sections of code depending on whether a macro is set or not. For example:

      #ifdef MY_FLAG - // code that is compiled if MY_FLAG exists -#else - // code that is compiled if MY_FLAG doesn't exists -#endif

      Note that this is not always the best approach, as it can make code difficult to read and maintain. Alternative approaches to consider can include:

      • run-time detection: e.g. unless a file with a registration key is present, restrict the available options to those for the evaluation version

      • plug-in architectures: e.g. if you want to write a program that runs on platforms that may or may not have Bluetooth, then isolate all Bluetooth code in a plug-in that can be dynamically loaded at run-time if appropriate

      However, if conditional compilation is needed, you can configure the build tools to read a file that defines the macros to use. To do this:

      • create a file that defines the macros as #define statements. By Symbian platform convention, such files should have an .hrh extension. The file can be anywhere on the same drive as the epoc32\ directory.

      • create a sub-directory of epoc32\tools\ called variant\, and create in it a text file called variant.cfg. The file must specify the full path to the .hrh macro file. Perl-type comments (marked with #) are also allowed.

      When you use bldmake or abld on the command line, the build tools look for the variant.cfg file, and set any macros defined in the specified file. By adding/removing/changing the variant.cfg file in your build environment, you can alter which macros are set, and so how your project is built.

      For IDE builds, the macros are set when the IDE project file is created, and not changed unless you recreate the IDE project file.

      Note that you can use the macros in bld.inf and .mmp files as well as in C++ files: this allows you to conditionally specify projects, source files, etc.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE69AA42-E633-5B7A-BAA1-6896950E0E19_d0e429673_href.png Binary file Symbian3/SDK/Source/GUID-AE69AA42-E633-5B7A-BAA1-6896950E0E19_d0e429673_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE69AA42-E633-5B7A-BAA1-6896950E0E19_d0e433473_href.png Binary file Symbian3/SDK/Source/GUID-AE69AA42-E633-5B7A-BAA1-6896950E0E19_d0e433473_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE6F03EB-1430-4526-B4D0-57BC6C6029D4.dita --- a/Symbian3/SDK/Source/GUID-AE6F03EB-1430-4526-B4D0-57BC6C6029D4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AE6F03EB-1430-4526-B4D0-57BC6C6029D4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,62 +1,49 @@ - - - - -Touch UI - - - - -

      When designing a Symbian application, the UI must be designed so -that all tasks can be performed with touch. Therefore, the design -must not rely on hardware keys (except for turning the power ON and -OFF).

      -

      The touch UI in the Symbian platform involves various specific -touch components, component and UI behavior changes, layout changes -and additions to the user experience. The main differences or additions in touch UI include the following:

      -
        -

      • Resistive touch screen (HW).

        For more information, see Designing applications -for touch UI

        • -

      • Capacitive touch screen (HW).

        For more information, -see Designing -applications for touch UI

        • -

      • Single tap. For more information, see Single tap.

        • -

      • Multiple touch.

        For more information, see Multiple touch.

        • -

      • Toolbar component in touch UI

        For more information, see Toolbar.

        • -

      • Touch input component (virtual keyboard, hand-writing recognition -and virtual ITU-T)

        For more information, see Text input.

        • -

      • Stylus pop-up menu component

        For more information, see Stylus pop-up -menu.

        • -

      • On-screen dialer application

        • -

      • Additional touch functionality to some components (for example, -Preview pop-up)

        For more information, see Preview pop-up.

        • -

      • Touch-enabled components

        For more information, see Touch support -for UI components.

        • -
      -

      There are two generic layouts for touch UI -portrait orientation -and landscape orientation, see the following figure. The Status pane in Touch UI has three variants: extended, flat and small.

      - -Default Symbian Touch UI layouts for portrait and landscape - -       -       - + + + + + +Touch UI +

      When designing a Symbian application, the UI must be designed so +that all tasks can be performed with touch. Therefore, the design +must not rely on hardware keys (except for turning the power ON and +OFF).

      +

      The touch UI in the Symbian platform involves various specific +touch components, component and UI behavior changes, layout changes +and additions to the user experience. The main differences or additions in touch UI include the following:

      +
        +

      • Resistive touch screen (HW).

        For more information, see Designing applications +for touch UI

        • +

      • Capacitive touch screen (HW).

        For more information, +see Designing +applications for touch UI

        • +

      • Single tap. For more information, see Single tap.

        • +

      • Multiple touch.

        For more information, see Multiple touch.

        • + +

      • Toolbar component in touch UI

        For more information, see Toolbar.

        • +

      • Touch input component (virtual keyboard, hand-writing recognition +and virtual ITU-T)

        For +more information, see Text +input.

        • +

      • Stylus pop-up menu component

        For more information, see Stylus +pop-up menu.

        • +

      • On-screen dialer application

        • +

      • Additional touch functionality to some components (for example, +Preview pop-up)

        For more +information, see Preview +pop-up.

        • +

      • Touch-enabled components

        For more information, see Touch support for UI components.

        • +
      +

      There are two generic layouts for touch UI -portrait orientation +and landscape orientation, see the following figure. The Status pane in Touch UI has three variants: extended, flat and small.

      + +Default Symbian Touch UI layouts for portrait and landscape + + +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE85751A-77CA-5C41-AF61-C9C9D776B066_d0e160811_href.png Binary file Symbian3/SDK/Source/GUID-AE85751A-77CA-5C41-AF61-C9C9D776B066_d0e160811_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE85751A-77CA-5C41-AF61-C9C9D776B066_d0e165831_href.png Binary file Symbian3/SDK/Source/GUID-AE85751A-77CA-5C41-AF61-C9C9D776B066_d0e165831_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE8D314A-5381-5576-9B17-94BA029A7FEA_d0e287887_href.jpg Binary file Symbian3/SDK/Source/GUID-AE8D314A-5381-5576-9B17-94BA029A7FEA_d0e287887_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE8D314A-5381-5576-9B17-94BA029A7FEA_d0e292715_href.jpg Binary file Symbian3/SDK/Source/GUID-AE8D314A-5381-5576-9B17-94BA029A7FEA_d0e292715_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AE96F25E-45A2-5C00-9F27-BB3E17C8E6E5.dita --- a/Symbian3/SDK/Source/GUID-AE96F25E-45A2-5C00-9F27-BB3E17C8E6E5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AE96F25E-45A2-5C00-9F27-BB3E17C8E6E5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -97,7 +97,7 @@
      Architecture

      The following diagram shows the basic architecture of the Certificate and Key Management component. The blocks in blue are internal to the component.

      - +

      The various blocks in the basic architecture diagram of the Certificate and Key Management component are explained as follows:

      • Client Application: diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AEBB7F5D-E18E-4E1F-ADE0-C984084AC108_d0e12675_href.png Binary file Symbian3/SDK/Source/GUID-AEBB7F5D-E18E-4E1F-ADE0-C984084AC108_d0e12675_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AEBB7F5D-E18E-4E1F-ADE0-C984084AC108_d0e12778_href.png Binary file Symbian3/SDK/Source/GUID-AEBB7F5D-E18E-4E1F-ADE0-C984084AC108_d0e12778_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AECDAEBF-777A-579B-92F8-560FD7FF86E7.dita --- a/Symbian3/SDK/Source/GUID-AECDAEBF-777A-579B-92F8-560FD7FF86E7.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,40 +0,0 @@ - - - - - -NAME -statement -<name-statement> -name-statement ::= -NAME <short-name> -

        Use this statement to ensure that the resources in the file have a unique -ID so that an application can use multiple resource files without resource -ID conflict.

        -

        This statement must be the first non-comment statement in the file.

        -

        The short-name must be between one and four alphabetic -characters long and be unique (no other file may use the same one). For the -sake of consistency this constant should be in upper case although lower case -is allowed (and will be converted to upper case by the compiler). This short-name is -then converted into a number and shifted onto the leading 20 bits of the resource -ID, leaving the bottom 12 bits for the number of the resource in the file. -This allows a maximum of 4095 resources to be defined in a source file.

        -

        Since the NAME statement maps all resource IDs within -the file onto 32-bit numbers, only LLINK s may be used for -resource references in that file. Using the NAME statement -in a resource file means that any attempt to use a LINK will -generate an error.

        -

        With NAME set to AAAA, -if this resource is the first resource in the file

        RESOURCE STRING one - { - wd=5; - }

        the first entry in the generated header file will be

        #define ONE 0x04FD8001

        04FD8 -is the leading 20 bits for all IDs in the file and 001 is the reference of -that resource within the file.

         - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AF8280C0-20B2-5D68-BFF5-7D9D1CE989DD.dita --- a/Symbian3/SDK/Source/GUID-AF8280C0-20B2-5D68-BFF5-7D9D1CE989DD.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -debuglibrary

        debuglibrary filename-list

        Use the debuglibrary statement to specify the libraries that are only required in debug builds.

        Any number of files may be specified, and there may be many debuglibrary statements. Specify the entire filename, e.g. euser.lib.

        The keyword indicates libraries which are only required in debug builds; this situation can arise when complex functions are called from __ASSERT_DEBUG() macros, for example in the TSwizzleCBase constructor which calls a function in estor.lib.

        makmake constructs two lists of libraries, one for debug builds and the other for release builds. The library keyword contributes to both lists, but the debuglibrary keyword only contributes to the debug list. There is no support for libraries which are only used in release builds.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AFAD0F36-330B-50BD-B810-85BE7FA21179.dita --- a/Symbian3/SDK/Source/GUID-AFAD0F36-330B-50BD-B810-85BE7FA21179.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AFAD0F36-330B-50BD-B810-85BE7FA21179.dita Tue Jul 20 12:00:49 2010 +0100 @@ -33,7 +33,7 @@ the physical path of the file:

        K:/ws/direct/direct.mmp

        gives the following URI file:

        ///k/ws/direct/direct.mmp

        The screen output from this example is:

        - +

        Modifying a URI

        void CExampleInetProtUtil::ModifyUriComponents();

        Modifies URI components, which involves:

        1. Adding URI components, @@ -45,18 +45,18 @@

        2. port: 8080

      to get the complete URI:

      http://waterlang.org:8080/main_page.html

      The screen output from this example is:

      - +

    • Removing the specific URI component(s) from a constructed URI. For example, the above URI with the port number removed:

      http://waterlang.org/main_page.html

      The screen output from this example is:

      - +

      • Resolving a URI

      void CExampleInetProtUtil::ResolveUri();

      Resolves the URI, which involves creation of an absolute CUri object from a given reference URI.

      The screen output from this example is:

      - +

      Parsing a URI

      void CExampleInetProtUtil::ParseUri();

      Parses the URI into its components (as given in RFC2396). The five URI components are:

      • scheme

        • @@ -65,21 +65,21 @@

      • query

      • fragment.

      The screen output from this example is:

      - +

      Validating a URI

      void CExampleInetProtUtil::ValidateUriComponents();

      Validates a given URI. This function is usually used for URIs with SIP as the scheme.

      The screen output from this example is:

      - +

      Extracting URI components

      void CExampleInetProtUtil::ExtractUriComponents();

      Extracts URI components from the given URI.

      The screen output from this example is:

      - +

      Retrieving a filename from a URI

      void CExampleInetProtUtil::RetrieveFileName();

      Extracts the actual physical location of the file from its URI.

      The screen output from this example is:

      - +

      Adding and removing delimiters from a URI

      void CExampleInetProtUtil::ModifyDelimiter();

      Adds the delimiters to and removes the delimiters from a URI. Before doing this ensure that:

        @@ -88,16 +88,16 @@

      • the URI has already been parsed.

      The screen output from this example is:

      - +

      Removing whitespace from a URI

      void CExampleInetProtUtil::WhiteSpaceRemover();

      Removes the whitespace from the given URI and returns the number of white spaces that were removed.

      The screen output from this example is:

      - +

      Escape encoding and decoding a URI

      void CExampleInetProtUtil::EscapeEncodeDecode();

      Escape encodes the characters in a given URI as escape triplets and decodes it to the original one.

      The screen output from this example is:

      - +
    Class Summary

    CUri8

    TUriParser8

    EscapeUtils

    TDelimitedParserBase8

    InetProtTextUtils

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AFC49653-78E6-5639-911C-E02AEB08AFFC_d0e185333_href.png Binary file Symbian3/SDK/Source/GUID-AFC49653-78E6-5639-911C-E02AEB08AFFC_d0e185333_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AFC49653-78E6-5639-911C-E02AEB08AFFC_d0e190330_href.png Binary file Symbian3/SDK/Source/GUID-AFC49653-78E6-5639-911C-E02AEB08AFFC_d0e190330_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita --- a/Symbian3/SDK/Source/GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita Tue Jul 20 12:00:49 2010 +0100 @@ -37,7 +37,7 @@ requests the resolved client to connect to the SIP implementation.

    Call flow of resolving a target client implementation using CSIPResolvedClient2 - +

    The target clients must implement the CSIPResolvedClient2 interface to receive SIP requests including SIP dialogs and enable the client resolution mechanism. Note: The channel UIDs must be unique across all diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-AFF0B669-E0D8-5533-A105-0F5EBC6AF5E1.dita --- a/Symbian3/SDK/Source/GUID-AFF0B669-E0D8-5533-A105-0F5EBC6AF5E1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -List of Symbian tools

    This section provides links to the documentation for the tools provided with Symbian platform. Note that these lists are not exhaustive.

    Note: Additional tools for integrating and customising software to produce a Symbian-based platform or phone are supplied as part of Platform Developer Toolkit (PDT). The tools include Symbian Build System v2 (SBSv2), API Usage Report Analysis (AURA), Code Database (CDB), Component Based Release (CBR), EmulatorBuild, Symbian Test Automation Tool (STAT), Test Execute Framework (TEF), TestDriver, Use Case Controller (UCC) and WinTAP. Documentation for these tools is supplied with the PDT.

    Application development tools

    The application development tools help to speed up development of Symbian platform applications.

    Name Description Reference

    Application Resource Tools

    Tools for building resource files.

    Application resource tools guide

    Build Tools

    Tools used to build Symbian platform programs.

    Build tools guide

    In addition to these, the Symbian Build System v2 (SBSv2) provides tools for building Symbian platform and applications developed for Symbian platform. For more information about SBSv2, see Symbian Build System v2 provided with PDT.

    Analysis tools Name Description Reference

    Capability Management tools

    Allows you to compare the capabilities of binaries that are developed against Symbian platform.

    Capability Management tools

    Set capability test tool

    Allows you to make a copy of an executable and assign different capabilities to it.

    Set Capability Test tool

    In addition to these, Symbian provides more analysis tools as part of the PDT.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B002BA13-38FA-590C-A1A9-336867BBFDBE.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-B002BA13-38FA-590C-A1A9-336867BBFDBE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,20 @@ + + + + + +Time +Zone Localiser Example +
    Download

    Click +on the following link to download the example: TZLocExample.zip

    Click: browse to view the example code.

    +
    Description This +C++ code example demonstrates how to convert UTC time to local time using +the time zone server (RTz) and how to add, +remove, or find a city in the database using the TZLocalizer API.
    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B015C4A3-469E-5AC4-B9B9-A24AF7444E65.dita --- a/Symbian3/SDK/Source/GUID-B015C4A3-469E-5AC4-B9B9-A24AF7444E65.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B015C4A3-469E-5AC4-B9B9-A24AF7444E65.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,7 +40,7 @@ is no exposure to Message Server APIs on the client-side. The SendAs Server encapsulates the Message Server completely.

    SendAs architecture - +
    SendAs Server

    The SendAs Server maintains all SendAs entries and controls the access to a Message Store. It allows client diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B02C762B-C452-4184-ABEA-4753E6CD47D2.dita --- a/Symbian3/SDK/Source/GUID-B02C762B-C452-4184-ABEA-4753E6CD47D2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B02C762B-C452-4184-ABEA-4753E6CD47D2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ UI to function as designed in mobile devices with different screen resolutions or orientations. For example, in the figure below, the UI scales to fit both portrait and landscape orientations.

    -Scaling +Scaling

    When you enable scaling in your application, you allow your application to support the different display sizes, resolutions, and layouts for different devices based on the Symbian platform. The Symbian platform provides APIs diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0391618-0681-5E4E-94BE-C0E24B862AEF_d0e213571_href.png Binary file Symbian3/SDK/Source/GUID-B0391618-0681-5E4E-94BE-C0E24B862AEF_d0e213571_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0391618-0681-5E4E-94BE-C0E24B862AEF_d0e218569_href.png Binary file Symbian3/SDK/Source/GUID-B0391618-0681-5E4E-94BE-C0E24B862AEF_d0e218569_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0449B60-B78E-5CC1-8FAF-E5EE24D88EB2.dita --- a/Symbian3/SDK/Source/GUID-B0449B60-B78E-5CC1-8FAF-E5EE24D88EB2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B0449B60-B78E-5CC1-8FAF-E5EE24D88EB2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Advanced Audio Adaptation Framework Technology Guide

    This document provides additional information about the Advanced Audio Adaptation Framework.

    Purpose

    The Advanced Audio Adaptation Framework (A3F) provides a common interface for accessing audio resources, playing tones, and configuring audio for playing and recording.

    Understanding A3F

    A3F functionality is provided by the CAudioContextFactory class. CAudioContextFactory is responsible for creating audio contexts. The Audio Context API (MAudioContext) maintains all audio components created in a context, where audio components are instances of the MAudioStream and MAudioProcessingUnit classes.

    An MAudioProcessingUnit is created in a context by giving the type of the processing unit such as codec and source sink. MAudioProcessingUnit allows extension interfaces to set additional audio processing unit settings.

    The Audio Stream API (MAudioStream) is an audio component that links together processing units into an audio stream. MAudioStream manages the audio processing state requested by the client and interacts with the audio processing units added to the stream. MAudioStream provides runtime control over a stream's (composite) behaviour and lifetime management of the entities in a stream (whether the state of the stream is uninitialized, initialized, idle, primed, active or dead). For more information, see Stream States.

    The Audio Context API allows a grouping notion for multimedia allocations. MAudioContext groups component actions made inside a context. This means any allocation or loss of resources which occurs in any single audio component affects all of the components grouped in the context.

    The Commit Cycle

    Changes made to an audio stream are handled in a transactional manner. If changes fail to be applied, then any other changes made to the stream are considered to fail also. The application of changes is dependent on a successful commit cycle. If there is a failure, a “rollback" mechanism is executed and the stream states are reverted to their previous state.

    The client requests changes through various Set() calls and then calls the MAudioContext::Commit() function. The platform-specific implementation then decides whether the Commit() request is allowed, possibly dictates new values if needed, and then applies the changes. If successful, the client is informed through callbacks. If there is a need to modify the context because resources are needed in another context, then the platform-specific implementation can take the resources by pre-empting the context. In this case, the client is informed about the pre-emption.

    The following diagram shows this behaviour:

    A3F Commit / Pre-emption Cycle -

    Observers

    Most of the A3F API functions are asynchronous. For example, the functions Foo() or SetFoo() are followed with FooComplete(Tint aError) or FooSet(Tint aError).

    The following A3F observers are defined:

    • MAudioContextObserver

      Informs with ContextEvent() about the commit cycle. Note that ContextEvent() is in the same thread context as the A3F client.

    • MAudioStreamObserver

      Informs with StateEvent() about state changes

    • MAudioCodecObserver

      Informs about completion of setters and getters.

    • MAudioGainControlObserver

      Informs about changes in gain or changes in maximum gain values.

    • MAudioProcessingUnitObserver

      Informs about any additional errors in audio processing units.

    • MMMFAudioDataConsumer

      Informs about recorded buffer to be ready for storing. Also informs the client if there is a buffer to be ignored.

    • MMMFAudioDataSupplier

      Informs about new buffer ready to be filled with audio data. Also informs the client if any requested buffer should be ignored.

    Stream States

    Clients using A3F should be aware that requested audio resources can be lost at any time while they are being used. A client with a higher importance can cause requests for resources to be denied or available resources to become unavailable. In these cases, the commit cycle informs the client through pre-emption events and the resulted stream state is usually demoted to the highest non-disturbing state.

    The possible audio stream states are described in the following table:

    State Description

    EUninitialized

    This is the state of the chain before it is initialized. However, the settings in the logical chain cannot be related to the adaptation because no adaptation has been selected yet.

    EInitialized

    This state is set after a successful initialization request.

    The physical adaptation has been selected but may not be fully allocated.

    There should be no externally visible buffers allocated at this point

    Note: For zero copy and shared chunk buffers, a stream in the EInitialized state should not require buffer consumption. This is an important issue if the base port only has 16 addressable chunks per process.

    In terms of DevSound compatibility, some custom interfaces are available at this point (although others may require further construction before they are available).

    EIdle

    All the chain resources are allocated. However, no processing time (other than that expended to put the chain into the EIdle state) is consumed in this phase.

    In the EIdle state, any existing allocated buffers continue to exist.

    The codec is allocated in terms of hardware memory consumption.

    A stream in the EIdle state can be ‘mid-file position’. There is no implied reset of position or runtime settings (that is, time played) by returning to EIdle.

    EPrimed

    This state is the same as EIdle but the stream can consume processing time by filling its buffers. The purpose of this state is to prepare a stream such that it is ready to play in as short a time as possible (for example, low-latency for audio chains which can be pre-buffered).

    Note that once the buffer is full, the stream may continue to use some processing time.

    There will not be an automatic transition to the EIdle state when the buffer is full. If such behaviour is desired, the client must request it.

    There will not be an automatic transition to EActive when the buffer is full. If such behaviour is desired, the client must request it.

    EActive

    The chain has the resources as EIdle and EPrimed but also has started to process the actions requested by the client.

    Note: A chain can be in the EActive state and performing a wide range of operations. However the semantics are that it is processing the stream and that it is consuming both processing and memory resources.

    EDead

    The stream can no longer function due to a fatal error. The logical chain still exists, but any physical resources should be reclaimed by the adaptation.

    The following diagram shows the stream states:

    +

    Observers

    Most of the A3F API functions are asynchronous. For example, the functions Foo() or SetFoo() are followed with FooComplete(Tint aError) or FooSet(Tint aError).

    The following A3F observers are defined:

    • MAudioContextObserver

      Informs with ContextEvent() about the commit cycle. Note that ContextEvent() is in the same thread context as the A3F client.

    • MAudioStreamObserver

      Informs with StateEvent() about state changes

    • MAudioCodecObserver

      Informs about completion of setters and getters.

    • MAudioGainControlObserver

      Informs about changes in gain or changes in maximum gain values.

    • MAudioProcessingUnitObserver

      Informs about any additional errors in audio processing units.

    • MMMFAudioDataConsumer

      Informs about recorded buffer to be ready for storing. Also informs the client if there is a buffer to be ignored.

    • MMMFAudioDataSupplier

      Informs about new buffer ready to be filled with audio data. Also informs the client if any requested buffer should be ignored.

    Stream States

    Clients using A3F should be aware that requested audio resources can be lost at any time while they are being used. A client with a higher importance can cause requests for resources to be denied or available resources to become unavailable. In these cases, the commit cycle informs the client through pre-emption events and the resulted stream state is usually demoted to the highest non-disturbing state.

    The possible audio stream states are described in the following table:

    State Description

    EUninitialized

    This is the state of the chain before it is initialized. However, the settings in the logical chain cannot be related to the adaptation because no adaptation has been selected yet.

    EInitialized

    This state is set after a successful initialization request.

    The physical adaptation has been selected but may not be fully allocated.

    There should be no externally visible buffers allocated at this point

    Note: For zero copy and shared chunk buffers, a stream in the EInitialized state should not require buffer consumption. This is an important issue if the base port only has 16 addressable chunks per process.

    In terms of DevSound compatibility, some custom interfaces are available at this point (although others may require further construction before they are available).

    EIdle

    All the chain resources are allocated. However, no processing time (other than that expended to put the chain into the EIdle state) is consumed in this phase.

    In the EIdle state, any existing allocated buffers continue to exist.

    The codec is allocated in terms of hardware memory consumption.

    A stream in the EIdle state can be ‘mid-file position’. There is no implied reset of position or runtime settings (that is, time played) by returning to EIdle.

    EPrimed

    This state is the same as EIdle but the stream can consume processing time by filling its buffers. The purpose of this state is to prepare a stream such that it is ready to play in as short a time as possible (for example, low-latency for audio chains which can be pre-buffered).

    Note that once the buffer is full, the stream may continue to use some processing time.

    There will not be an automatic transition to the EIdle state when the buffer is full. If such behaviour is desired, the client must request it.

    There will not be an automatic transition to EActive when the buffer is full. If such behaviour is desired, the client must request it.

    EActive

    The chain has the resources as EIdle and EPrimed but also has started to process the actions requested by the client.

    Note: A chain can be in the EActive state and performing a wide range of operations. However the semantics are that it is processing the stream and that it is consuming both processing and memory resources.

    EDead

    The stream can no longer function due to a fatal error. The logical chain still exists, but any physical resources should be reclaimed by the adaptation.

    The following diagram shows the stream states:

    A3F State Machine -
    A3F Tutorials

    The following tutorials are provided to help you create A3F solutions:

    • Audio Component Framework Tutorial

    • Audio Processing Tutorial

    See Also

    Advanced Audio Adaptation Framework Overview

    Sound Device Overview

    \ No newline at end of file +
    A3F Tutorials

    The following tutorials are provided to help you create A3F solutions:

    • Audio Component Framework Tutorial

    • Audio Processing Tutorial

    See Also

    Advanced Audio Adaptation Framework Overview

    Sound Device Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B05B61B8-1217-441F-BAFA-C209C8F123C5.dita --- a/Symbian3/SDK/Source/GUID-B05B61B8-1217-441F-BAFA-C209C8F123C5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B05B61B8-1217-441F-BAFA-C209C8F123C5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ UI, and a floating toolbar which can also be used in non-touch UIs.

    Fixed toolbar, floating toolbar, and toolbar extension - +

    The fixed toolbar doesn’t have focus, whereas the floating toolbar owns the focus and it can be used also with navigation and selection keys. By default, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0797210-4EE3-557B-A5A6-D215D030BA0E_d0e184810_href.png Binary file Symbian3/SDK/Source/GUID-B0797210-4EE3-557B-A5A6-D215D030BA0E_d0e184810_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0797210-4EE3-557B-A5A6-D215D030BA0E_d0e189807_href.png Binary file Symbian3/SDK/Source/GUID-B0797210-4EE3-557B-A5A6-D215D030BA0E_d0e189807_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B0EF8500-0A49-5EA8-B7FF-8149E5F03693.dita --- a/Symbian3/SDK/Source/GUID-B0EF8500-0A49-5EA8-B7FF-8149E5F03693.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B0EF8500-0A49-5EA8-B7FF-8149E5F03693.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,9 +10,9 @@ How to use the SIP Client API

    Protocols

    The following sections describe how to do the following:

    • Starting the SIP Client

    • Closing SIP Client

    • Sending a SIP request

    • Receiving a SIP request

    • Receiving a SIP request and creating a session

    • Registration

    • Creating a dialog with INVITE

    • Generating a '100 SIP response'

    • Responding to a CANCEL request

    • Sending a SIP request and responding to a HTTP Digest challenge

    • Notification of a failed refresh

    • Error handling

    • Refreshing a Connection

    Starting the SIP Client

    To start the SIP Client:

    1. Create an instance of the CSIP class. The CSIP class creates a CSIP object and implements the callback functions defined by MSIPObserver. The CSIP object connects the client to a shared server.

      Note: The server is started if it is not active. This may take a short time while the server side resources are created and initialised.

    2. Create an instance of the CSIPConnection class to use an IAP. The CSIPConnection class must implement the callback functions defined by MSIPConnectionObserver. The CSIPConnection class creates CSIPConnection object. The CSIPConnection object forms a sub-session between the client and the server.

    3. Call the CSIPConnection::NewL() function to create an active connection. The CSIPConnection::EActive state indicates that the object can be used to send SIP messages and create registrations and dialogs. The current state is asked by calling CSIPConnection::State(). The MSIPConnectionObserver::ConnectionStateChanged(CSIPConnection:: - EActive) callback function is called.

    The following illustration shows the sequence of events involved in starting the SIP Client API.

    Closing the SIP Client

    To close the SIP Client:

    • Delete the CSIP object to close the connection to the SIP server.

    • Delete the CSIPConnection object to close the sub-session between the client and the server.

    • When the connection has been closed, operations on objects that depend on the connection fail with the KErrSIPResourceNotAvailable error code.

    For example, if an application has CSIPConnection and CSIPRegistrationBinding objects, and it deletes the CSIPConnection object, then subsequent attempts to use the CSIPRegistrationBinding object fails. This is because CSIPRegistrationBinding cannot communicate with the server side of the SIP stack without the CSIPConnection object.

    The following illustration shows the order for deleting SIP Client API objects.

    Sending a SIP request

    To send a SIP request:

    • Create a CSIPRequestElements object and enter the required fields of the request.

    • Call the CSIPConnection::SendRequestL(CSIPRequestElements*) function to take control of the CSIPRequestElements objects and communicate the request to the server side of the SIP stack.

      CSIPConnection creates a CSIPClientTransaction object and returns it to the application.

    Note: SendRequestL() starts the server side processing of sending the MESSAGE request. This task takes time as address resolving and socket operations are done only after the SendRequestL() call is returned. If an error occurs after SendRequestL() returns, then the error is communicated to the application through one of the MSIPConnectionObserver::ErrorOccured() callback functions. An example of such a failure is failure to resolve the address. When SendRequestL() returns, the MESSAGE request is not yet sent to the network, and is being processed on the server side of the SIP stack.

    After SendRequestL() returns and the sending of a MESSAGE request is in progress on the shared server, there is no way for the application to cancel that operation. This also applies to other operation types. However the CSIPClientTransaction::CancelL() function is used to send a CANCEL request after the application sends an INVITE request.

    When the SIP response is received from the server side, the CSIPConnection object:

    1. creates a CSIPResponseElements object to represent the SIP response

    2. attaches it to the CSIPClientTransaction object

    3. notifies the application through a call to one of the MSIPConnectionObserver:: IncomingResponse() callback functions.

    The application determines the kind of response received by accessing the CSIPResponseElements object through CSIPClientTransaction. As the response is provisional, the application does not delete the CSIPClientTransaction object. A '200 response' is received later, and the application then deletes the CSIPClientTransaction object.

    Then, create a CSIPResponseElements object to represent the SIP response, attach it to CSIPClientTransaction and notify the application with MSIPConnectionObserver:: - IncomingResponse.

    The following illustration shows the sequence of events involved in sending a MESSAGE request and receiving two responses to it.

    Receiving a SIP request

    A standalone SIP request is received through an existing CSIPConnection object. The CSIPConnection creates CSIPRequestElements and CSIPServerTransaction objects before notifying the application through the MSIPConnectionObserver::IncomingRequest() callback function. The CSIPRequestElements and CSIPServerTransaction represent the incoming SIP request

    The CSIPServerTransaction object is passed to the CSIPRequestElements object through the callback function. The application retrieves information about the request from the CSIPServerTransaction object.

    To send a response, the application creates a CSIPResponseElements object and passes it to CSIPServerTransaction::SendResponseL(). This passes the response to the server side for further processing. When SendResponseL() is returned, the application no longer needs the CSIPServerTransaction object and deletes it.

    The following illustration shows the sequence of events involved in receiving a MESSAGE request and sending a response to it.

    Receiving a SIP request and creating a session

    The SIP stack receives a SIP INVITE request from the network acting as a User Agent Server (UAS) and creates an invite server transaction for the received request. The SIP stack sends a '100 SIP response' to the remote UA. After comparing the received request with the stored application capabilities, the SIP stack routes the received INVITE request to the chosen application.

    The application creates a CSIPInviteDialogAssoc object and the SIP stack creates an instance of CSIPDialog. The application sends a '200 SIP response' to the remote UA. The remote UA acknowledges the '200 SIP' response with ACK and creates a SIP session is between the local and remote UA.

    The following illustration shows the sequence of events involved in receiving a SIP request and creating a SIP dialog.

    Registration

    An application creates a CSIPRefresh object to initiate a registration. It then creates a CSIPRegistrationBinding object, passing CSIPRefresh to it.

    Note: It is not mandatory to create a CSIPRefresh object. It is required if the registration is to be refreshed by the SIP stack.

    After the CSIPRegistrationBinding object exists, the application initiates the registration process by calling RegisterL() on the CSIPRegistrationBinding object. CSIPRegistrationBinding forms a REGISTER request and communicates it to the server side of the SIP stack, it instantiates the CSIPClientTransaction object and returns it to the application.

    When the '200 SIP response' is received from the server side, CSIPConnection creates the CSIPResponseElements object to contain the response, and then routes the response to CSIPRegistrationBinding. CSIPRegistrationBinding attaches the response to CSIPClientTransaction. The application is informed about the response through one of the MSIPConnectionObserver::IncomingResponse() callback functions.

    The application does not require the CSIPClientTransaction object and can delete it. The IsContextActive() finds out if the registration is successful.

    The following illustration shows the sequence of events involved in registering with a refresh and receiving a '200 OK response'.

    Configuring the registration

    When registering an SIP connection, applications have two options to configure the registration : outbound proxy caching and expiration value removal. To set each of these options, call CSIPRegistrationBinding::SetProperty() with the corresponding property constant, as explained below.

    The SIP stack resolves the IP address of the outbound proxy during registration. The default behavior is to resolve the address again for each SIP message sent using this registration context. However, you can also cache the address to optimise network traffic. If you set KSIPCacheOutboundProxyIP property to ETrue, the SIP stack reuses the proxy address that was resolved during registration. The proxy address is refreshed by successful REGISTER transactions, which always perform a DNS query.

    By default, the SIP stack sends the expiration value in the REGISTER request. In the '200 OK' answer to a REGISTER message, the registrar returns an expiration value that may be different from the value that was sent. The SIP stack validates the returned expiration value against the minimum and maximum expiration values: if the returned expiration value is out of range, the SIP stack uses the minimum value or the maximum value.

    • The minimum expiration value is 30 seconds, to reduce network activity and battery consumption.

    • The maximum expiration value is the expiration value that you specify for the REGISTER request. By default, the maximum expiration value is 3600 seconds, to protect the application from DOS attacks that provide '200 OK' responses with a very high expiration value.

    If you set KSIPSendWithExpires to EFalse, the SIP stack does not send the application's expiration value in the REGISTER message.

    Creating a dialog with INVITE

    To create a dialog with INVITE an application creates CSIPInviteDialogAssoc and CSIPMessageElements objects. The application must enter the relevant SIP headers in the CSIPMessageElements object before passing it to CSIPInviteDialogAssoc using the CSIPInviteDialogAssoc::SendInviteL() function.

    CSIPInviteDialogAssoc then forms an INVITE request and communicates it to the server side of the SIP stack. It then creates a CSIPClientTransaction object, and returns it to the application.

    When the server sends '180 response', the CSIPConnection creates a CSIPResponseElements object to contain the response, and then routes the response to CSIPDialog. CSIPDialog attaches the response to CSIPClientTransaction. The application is informed about the receipt of the '180 response' through a call to one of the MSIPConnectionObserver:: IncomingResponse() callback functions.

    When the '200 response' is received, processing similar to '180 response' occurs. Then the application responds by sending an ACK request. This is done by invoking the CSIPInviteDialogAssoc::SendAckL() function, which forms the ACK request and sends it to the server side of the SIP stack.

    The INVITE request might fork at a proxy, so the server side of the SIP stack waits for several possible responses. When the forking is does not happen, the server side of the SIP stack sends an InviteCompleted event. The SIP Client API forwards the InviteCompleted event to the application, indicating that the application can now delete the CSIPClientTransaction.

    The following figure shows the sequence of events involved in sending an INVITE, receiving a response and sending an ACK.

    Generating a '100 SIP response'

    The SIP stack generates a '100 response' automatically when it receives an INVITE request from the network. Applications are not allowed to send '100 responses'.

    Responding to a CANCEL request

    When the SIP stack receives a CANCEL request from the network, it automatically responds to it. CANCEL requests are never passed to an application.

    If the SIP stack:

    • does not find a matching transaction for a CANCEL request, it automatically generates a '481 response'.

    • finds a matching transaction for a CANCEL request, it automatically generates a '200 response'.

    • finds a matching INVITE server transaction that is in the Proceeding state (that is a final response is not yet sent), it also automatically generates a '487 response' to the INVITE transaction.

    After these actions are complete, the SIP stack informs the application by calling the MSIPConnectionObserver::InviteCanceled() callback function.

    Sending a SIP request and responding to a HTTP Digest challenge

    A SIP server in the signalling chain challenges any SIP request initiated by the application with an HTTP Digest challenge by responding with a '401 SIP response', '407 SIP response' or a '494 SIP response'. The responses contain details of the challenge. These responses are never passed directly to the application. Instead, they are passed to the application through a call to the callback function MSIPHttpDigestChallengeObserver::ChallengeReceived().

    To enable an application to respond to a challenge, it must:

    • create a CSIPHttpDigest object

    • provide an implementation of the callback function MSIPHttpDigestChallengeObserver::ChallengeReceived() .

    The application can either accept or reject the challenge:

    • If it accepts the challenge, the callback function must call CSIPHttpDigest::SetCredentialsL(), specifying the username, password, and the realm passed to the callback function.

      Then, SIP stack re-sends the original SIP request with the HTTP Digest response.

    • If it rejects the challenge, the callback function must call CSIPHttpDigest::IgnoreChallenge(), specifying the realm passed to the callback function.

      Then, SIP stack calls the callback function MSIPConnectionObserver::ErrorOccured(), by passing the error code KErrSIPForbidden.

    If an application does not want to receive the HTTP Digest challenge then it must not create a CSIPHttpDigest object. In this event, the SIP stack calls the callback function MSIPConnectionObserver::ErrorOccured(), passing the error code KErrSIPForbidden.

    Note:

    • If an application uses the SIP Profile Agent for SIP registration, the SIP Profile Agent handles the HTTP Digest challenges related to the registration procedure according to the SIP profile information.

    • The SIP stack maintains a HTTP Digest cache which stores username and password pairs for realms. If the username and password have been configured for a proxy, or if the application has already provided them after being asked through a MSIPHttpDigestChallengeObserver::ChallengeReceived() call, then the SIP stack uses them to answer subsequent challenges for a matching realm automatically.

      For example, if the application uses a SIP Profile whose proxy is configured with HTTP Digest passwords and then sends an INVITE, it does not need to provide the passwords for the proxy as the SIP stack gets it from the HTTP Digest cache.

    Notification of a failed refresh

    The following example shows how an application is notified when a refresh request within a dialog terminates after an error occurs. In this example the application sends a SUBSCRIBE request with refresh, and receives a 2xx class response. The SIP stack periodically sends a refreshed SUBSCRIBE message. After successfully refreshed SUBSCRIBE requests, the remote server responds with a '481 response', and the application receives the following callback:

    MSIPConnectionObserver::ErrorOccured(TInt aError, CSIPDialogAssocBase& aDialogAssoc)

    If the value of aError is KErrSIPTerminatedWithResponse, then the actual SIP response causing the refresh to end can be found as follows:

    • Check that aDialogAssoc.Type() returns "SUBSCRIBE".

    • Call the function with the following signature to get the refresh instance (CSIPRefresh object):

      const CSIPRefresh* CSIPSubscribeDialogAssoc::SIPRefresh() const

    • Use the CSIPRefresh object to get the associated transaction by calling the following function:

      const CSIPClientTransaction* CSIPRefresh::SIPTransaction() const

      Note: The returned CSIPClientTransaction object is not similar to the one returned from the call to SendSubscribeL(), that the application originally used to send the SUBSCRIBE request.

    • Call the following function to get the SIP response:

      const CSIPResponseElements* CSIPClientTransaction::ResponseElements() const
    Error handling

    Errors are passed to an application by calling the callback functions or by leaving. For more information, see Cleanup support overview. If an error occurs during the synchronous part of an operation is initiated by the application, functions leave with an error code. If an error occurs during the asynchronous processing stage, the error is passed to the application through one of the MSIPConnectionObserver::ErrorOccured() callback functions.

    There are several overloaded variants of ErrorOccured() functions. Each of them takes the error code and reference to the SIP Client API object that encountered the error:

    • A call to the variants of ErrorOccured() taking a CSIPTransactionBase or CSIPClientTransaction parameter means that transaction has entered the state CTransactionBase::ETerminated.

    • A call to the variant of ErrorOccured() taking a CSIPRegistrationBinding parameter means that the registration context is no longer active, that is CSIPRegistrationBinding::IsContextActive() == EFalse.

      If the registration was being refreshed, then the refresh has also ended and its state is CSIPRefresh::ETerminated.

    If the callback function MSIPConnectionObserver::ConnectionStateChanged() is called and the aState parameter is either CSIPConnection::EInactive or CSIPConnection::EUnavailable, then all dialogs, registrations, and standalone transactions using the CSIPConnection are terminated.

    To avoid an overload of callback calls in this type of situation, calls to ErrorOccured() for the individual dialog, registration and transaction objects are not sent to the application.

    When the connection state changes, the MSIPConnectionObserver::ConnectionStateChanged() callback function does not provide a reason. Call CSIPConnection::GetConnectionError() to get details about the connection error that caused the change.

    Refreshing a Connection

    To refresh a connection, do the following steps:

    1. Start the connection on the desired IAP.

    2. Monitor the status of the connection using the MSIPConnectionObserver::ConnectionStateChanged(CSIPConnection::TState - aState) function.

    3. If the connection is inactive, notify the EInactive state to the application through MSIPConnectionObserver::ConnectionStateChanged() function that is, if (CSIPConnection::TState == EInactive), then send a RefreshConnection() function to make it active.

      Note: This requires a bearer monitor on that IAP to which a refresh request is sent.

    4. Any changes to the state of the connection is notified through MSIPConnectionObserver::ConnectionStateChanged().

    The following sequence diagram shows how a client refreshes a connection.

    The following example code describes how to refresh a connection.

    // It is assumed that the connection is started and is in an Inactive state that is, + EActive) callback function is called.

    The following illustration shows the sequence of events involved in starting the SIP Client API.

    Closing the SIP Client

    To close the SIP Client:

    • Delete the CSIP object to close the connection to the SIP server.

    • Delete the CSIPConnection object to close the sub-session between the client and the server.

    • When the connection has been closed, operations on objects that depend on the connection fail with the KErrSIPResourceNotAvailable error code.

    For example, if an application has CSIPConnection and CSIPRegistrationBinding objects, and it deletes the CSIPConnection object, then subsequent attempts to use the CSIPRegistrationBinding object fails. This is because CSIPRegistrationBinding cannot communicate with the server side of the SIP stack without the CSIPConnection object.

    The following illustration shows the order for deleting SIP Client API objects.

    Sending a SIP request

    To send a SIP request:

    • Create a CSIPRequestElements object and enter the required fields of the request.

    • Call the CSIPConnection::SendRequestL(CSIPRequestElements*) function to take control of the CSIPRequestElements objects and communicate the request to the server side of the SIP stack.

      CSIPConnection creates a CSIPClientTransaction object and returns it to the application.

    Note: SendRequestL() starts the server side processing of sending the MESSAGE request. This task takes time as address resolving and socket operations are done only after the SendRequestL() call is returned. If an error occurs after SendRequestL() returns, then the error is communicated to the application through one of the MSIPConnectionObserver::ErrorOccured() callback functions. An example of such a failure is failure to resolve the address. When SendRequestL() returns, the MESSAGE request is not yet sent to the network, and is being processed on the server side of the SIP stack.

    After SendRequestL() returns and the sending of a MESSAGE request is in progress on the shared server, there is no way for the application to cancel that operation. This also applies to other operation types. However the CSIPClientTransaction::CancelL() function is used to send a CANCEL request after the application sends an INVITE request.

    When the SIP response is received from the server side, the CSIPConnection object:

    1. creates a CSIPResponseElements object to represent the SIP response

    2. attaches it to the CSIPClientTransaction object

    3. notifies the application through a call to one of the MSIPConnectionObserver:: IncomingResponse() callback functions.

    The application determines the kind of response received by accessing the CSIPResponseElements object through CSIPClientTransaction. As the response is provisional, the application does not delete the CSIPClientTransaction object. A '200 response' is received later, and the application then deletes the CSIPClientTransaction object.

    Then, create a CSIPResponseElements object to represent the SIP response, attach it to CSIPClientTransaction and notify the application with MSIPConnectionObserver:: + IncomingResponse.

    The following illustration shows the sequence of events involved in sending a MESSAGE request and receiving two responses to it.

    Receiving a SIP request

    A standalone SIP request is received through an existing CSIPConnection object. The CSIPConnection creates CSIPRequestElements and CSIPServerTransaction objects before notifying the application through the MSIPConnectionObserver::IncomingRequest() callback function. The CSIPRequestElements and CSIPServerTransaction represent the incoming SIP request

    The CSIPServerTransaction object is passed to the CSIPRequestElements object through the callback function. The application retrieves information about the request from the CSIPServerTransaction object.

    To send a response, the application creates a CSIPResponseElements object and passes it to CSIPServerTransaction::SendResponseL(). This passes the response to the server side for further processing. When SendResponseL() is returned, the application no longer needs the CSIPServerTransaction object and deletes it.

    The following illustration shows the sequence of events involved in receiving a MESSAGE request and sending a response to it.

    Receiving a SIP request and creating a session

    The SIP stack receives a SIP INVITE request from the network acting as a User Agent Server (UAS) and creates an invite server transaction for the received request. The SIP stack sends a '100 SIP response' to the remote UA. After comparing the received request with the stored application capabilities, the SIP stack routes the received INVITE request to the chosen application.

    The application creates a CSIPInviteDialogAssoc object and the SIP stack creates an instance of CSIPDialog. The application sends a '200 SIP response' to the remote UA. The remote UA acknowledges the '200 SIP' response with ACK and creates a SIP session is between the local and remote UA.

    The following illustration shows the sequence of events involved in receiving a SIP request and creating a SIP dialog.

    Registration

    An application creates a CSIPRefresh object to initiate a registration. It then creates a CSIPRegistrationBinding object, passing CSIPRefresh to it.

    Note: It is not mandatory to create a CSIPRefresh object. It is required if the registration is to be refreshed by the SIP stack.

    After the CSIPRegistrationBinding object exists, the application initiates the registration process by calling RegisterL() on the CSIPRegistrationBinding object. CSIPRegistrationBinding forms a REGISTER request and communicates it to the server side of the SIP stack, it instantiates the CSIPClientTransaction object and returns it to the application.

    When the '200 SIP response' is received from the server side, CSIPConnection creates the CSIPResponseElements object to contain the response, and then routes the response to CSIPRegistrationBinding. CSIPRegistrationBinding attaches the response to CSIPClientTransaction. The application is informed about the response through one of the MSIPConnectionObserver::IncomingResponse() callback functions.

    The application does not require the CSIPClientTransaction object and can delete it. The IsContextActive() finds out if the registration is successful.

    The following illustration shows the sequence of events involved in registering with a refresh and receiving a '200 OK response'.

    Configuring the registration

    When registering an SIP connection, applications have two options to configure the registration : outbound proxy caching and expiration value removal. To set each of these options, call CSIPRegistrationBinding::SetProperty() with the corresponding property constant, as explained below.

    The SIP stack resolves the IP address of the outbound proxy during registration. The default behavior is to resolve the address again for each SIP message sent using this registration context. However, you can also cache the address to optimise network traffic. If you set KSIPCacheOutboundProxyIP property to ETrue, the SIP stack reuses the proxy address that was resolved during registration. The proxy address is refreshed by successful REGISTER transactions, which always perform a DNS query.

    By default, the SIP stack sends the expiration value in the REGISTER request. In the '200 OK' answer to a REGISTER message, the registrar returns an expiration value that may be different from the value that was sent. The SIP stack validates the returned expiration value against the minimum and maximum expiration values: if the returned expiration value is out of range, the SIP stack uses the minimum value or the maximum value.

    • The minimum expiration value is 30 seconds, to reduce network activity and battery consumption.

    • The maximum expiration value is the expiration value that you specify for the REGISTER request. By default, the maximum expiration value is 3600 seconds, to protect the application from DOS attacks that provide '200 OK' responses with a very high expiration value.

    If you set KSIPSendWithExpires to EFalse, the SIP stack does not send the application's expiration value in the REGISTER message.

    Creating a dialog with INVITE

    To create a dialog with INVITE an application creates CSIPInviteDialogAssoc and CSIPMessageElements objects. The application must enter the relevant SIP headers in the CSIPMessageElements object before passing it to CSIPInviteDialogAssoc using the CSIPInviteDialogAssoc::SendInviteL() function.

    CSIPInviteDialogAssoc then forms an INVITE request and communicates it to the server side of the SIP stack. It then creates a CSIPClientTransaction object, and returns it to the application.

    When the server sends '180 response', the CSIPConnection creates a CSIPResponseElements object to contain the response, and then routes the response to CSIPDialog. CSIPDialog attaches the response to CSIPClientTransaction. The application is informed about the receipt of the '180 response' through a call to one of the MSIPConnectionObserver:: IncomingResponse() callback functions.

    When the '200 response' is received, processing similar to '180 response' occurs. Then the application responds by sending an ACK request. This is done by invoking the CSIPInviteDialogAssoc::SendAckL() function, which forms the ACK request and sends it to the server side of the SIP stack.

    The INVITE request might fork at a proxy, so the server side of the SIP stack waits for several possible responses. When the forking is does not happen, the server side of the SIP stack sends an InviteCompleted event. The SIP Client API forwards the InviteCompleted event to the application, indicating that the application can now delete the CSIPClientTransaction.

    The following figure shows the sequence of events involved in sending an INVITE, receiving a response and sending an ACK.

    Generating a '100 SIP response'

    The SIP stack generates a '100 response' automatically when it receives an INVITE request from the network. Applications are not allowed to send '100 responses'.

    Responding to a CANCEL request

    When the SIP stack receives a CANCEL request from the network, it automatically responds to it. CANCEL requests are never passed to an application.

    If the SIP stack:

    • does not find a matching transaction for a CANCEL request, it automatically generates a '481 response'.

    • finds a matching transaction for a CANCEL request, it automatically generates a '200 response'.

    • finds a matching INVITE server transaction that is in the Proceeding state (that is a final response is not yet sent), it also automatically generates a '487 response' to the INVITE transaction.

    After these actions are complete, the SIP stack informs the application by calling the MSIPConnectionObserver::InviteCanceled() callback function.

    Sending a SIP request and responding to a HTTP Digest challenge

    A SIP server in the signalling chain challenges any SIP request initiated by the application with an HTTP Digest challenge by responding with a '401 SIP response', '407 SIP response' or a '494 SIP response'. The responses contain details of the challenge. These responses are never passed directly to the application. Instead, they are passed to the application through a call to the callback function MSIPHttpDigestChallengeObserver::ChallengeReceived().

    To enable an application to respond to a challenge, it must:

    • create a CSIPHttpDigest object

    • provide an implementation of the callback function MSIPHttpDigestChallengeObserver::ChallengeReceived() .

    The application can either accept or reject the challenge:

    • If it accepts the challenge, the callback function must call CSIPHttpDigest::SetCredentialsL(), specifying the username, password, and the realm passed to the callback function.

      Then, SIP stack re-sends the original SIP request with the HTTP Digest response.

    • If it rejects the challenge, the callback function must call CSIPHttpDigest::IgnoreChallenge(), specifying the realm passed to the callback function.

      Then, SIP stack calls the callback function MSIPConnectionObserver::ErrorOccured(), by passing the error code KErrSIPForbidden.

    If an application does not want to receive the HTTP Digest challenge then it must not create a CSIPHttpDigest object. In this event, the SIP stack calls the callback function MSIPConnectionObserver::ErrorOccured(), passing the error code KErrSIPForbidden.

    Note:

    • If an application uses the SIP Profile Agent for SIP registration, the SIP Profile Agent handles the HTTP Digest challenges related to the registration procedure according to the SIP profile information.

    • The SIP stack maintains a HTTP Digest cache which stores username and password pairs for realms. If the username and password have been configured for a proxy, or if the application has already provided them after being asked through a MSIPHttpDigestChallengeObserver::ChallengeReceived() call, then the SIP stack uses them to answer subsequent challenges for a matching realm automatically.

      For example, if the application uses a SIP Profile whose proxy is configured with HTTP Digest passwords and then sends an INVITE, it does not need to provide the passwords for the proxy as the SIP stack gets it from the HTTP Digest cache.

    Notification of a failed refresh

    The following example shows how an application is notified when a refresh request within a dialog terminates after an error occurs. In this example the application sends a SUBSCRIBE request with refresh, and receives a 2xx class response. The SIP stack periodically sends a refreshed SUBSCRIBE message. After successfully refreshed SUBSCRIBE requests, the remote server responds with a '481 response', and the application receives the following callback:

    MSIPConnectionObserver::ErrorOccured(TInt aError, CSIPDialogAssocBase& aDialogAssoc)

    If the value of aError is KErrSIPTerminatedWithResponse, then the actual SIP response causing the refresh to end can be found as follows:

    • Check that aDialogAssoc.Type() returns "SUBSCRIBE".

    • Call the function with the following signature to get the refresh instance (CSIPRefresh object):

      const CSIPRefresh* CSIPSubscribeDialogAssoc::SIPRefresh() const

    • Use the CSIPRefresh object to get the associated transaction by calling the following function:

      const CSIPClientTransaction* CSIPRefresh::SIPTransaction() const

      Note: The returned CSIPClientTransaction object is not similar to the one returned from the call to SendSubscribeL(), that the application originally used to send the SUBSCRIBE request.

    • Call the following function to get the SIP response:

      const CSIPResponseElements* CSIPClientTransaction::ResponseElements() const
    Error handling

    Errors are passed to an application by calling the callback functions or by leaving. For more information, see Cleanup support overview. If an error occurs during the synchronous part of an operation is initiated by the application, functions leave with an error code. If an error occurs during the asynchronous processing stage, the error is passed to the application through one of the MSIPConnectionObserver::ErrorOccured() callback functions.

    There are several overloaded variants of ErrorOccured() functions. Each of them takes the error code and reference to the SIP Client API object that encountered the error:

    • A call to the variants of ErrorOccured() taking a CSIPTransactionBase or CSIPClientTransaction parameter means that transaction has entered the state CTransactionBase::ETerminated.

    • A call to the variant of ErrorOccured() taking a CSIPRegistrationBinding parameter means that the registration context is no longer active, that is CSIPRegistrationBinding::IsContextActive() == EFalse.

      If the registration was being refreshed, then the refresh has also ended and its state is CSIPRefresh::ETerminated.

    If the callback function MSIPConnectionObserver::ConnectionStateChanged() is called and the aState parameter is either CSIPConnection::EInactive or CSIPConnection::EUnavailable, then all dialogs, registrations, and standalone transactions using the CSIPConnection are terminated.

    To avoid an overload of callback calls in this type of situation, calls to ErrorOccured() for the individual dialog, registration and transaction objects are not sent to the application.

    When the connection state changes, the MSIPConnectionObserver::ConnectionStateChanged() callback function does not provide a reason. Call CSIPConnection::GetConnectionError() to get details about the connection error that caused the change.

    Refreshing a Connection

    To refresh a connection, do the following steps:

    1. Start the connection on the desired IAP.

    2. Monitor the status of the connection using the MSIPConnectionObserver::ConnectionStateChanged(CSIPConnection::TState + aState) function.

    3. If the connection is inactive, notify the EInactive state to the application through MSIPConnectionObserver::ConnectionStateChanged() function that is, if (CSIPConnection::TState == EInactive), then send a RefreshConnection() function to make it active.

      Note: This requires a bearer monitor on that IAP to which a refresh request is sent.

    4. Any changes to the state of the connection is notified through MSIPConnectionObserver::ConnectionStateChanged().

    The following sequence diagram shows how a client refreshes a connection.

    The following example code describes how to refresh a connection.

    // It is assumed that the connection is started and is in an Inactive state that is, // (CSIPConnection::TState == EInactive) // Refresh the IAP ID of the connection by sending a Refresh Request to the Bearer monitor of the IAP diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B1254526-3C72-59E7-88C0-667FC051379F.dita --- a/Symbian3/SDK/Source/GUID-B1254526-3C72-59E7-88C0-667FC051379F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B1254526-3C72-59E7-88C0-667FC051379F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Extended SMS Converter

    The Extended SMS Converter uses the lossy mechanism to extend the alphabet of the standard converter. It maps a wider set of input character codes, including commonly-used Eastern European Unicode characters, to the standard 7-bit alphabet. This section describes the Extended SMS Converter and the alphabet it supports.

    Introduction

    Languages supported by this converter include Croatian, Czech, Estonian, Hungarian, Icelandic, Latvian, Lithuanian, Polish, Romanian, Serbian, Slovak, Slovenian, Turkish, Portuguese and Spanish. This converter is identified by the KCharacterSetIdentifierExtendedSms7Bit UID, which is defined in the charconv.h file.

    Any undefined Unicode is converted to a question mark (?)–GSM code 0x37. Any code outside GSM 0x00 ~0x7F is converted to the Unicode replacement character 0xFFFD.

    Alphabet

    The highlighted boxes in Figure 1 illustrate the alphabet of the extended SMS converter:

    • GSM 7-bit default alphabet

    • GSM 7-bit default alphabet extension table

    • Extra lossy conversions–exclude 9 characters listed in Table 2

    • Extended lossy conversions–shown as Lossy Characters 2 in Figure 1.

    Figure 1

    Table 1 lists the extra lossy conversions supported by this converter in addition to those supported by the standard converter.

    Table 1

    Character

    Unicode

    GSM

    Converted Character

    Ώ GREEK CAPITAL LETTER OMEGA WITH TONOS

    U+038F

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    (NO-BREAK SPACE)

    U+00A0

    0x20

    (SPACE)

    « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK *

    U+00AB

    0x22

    " QUOTATION MARK

    » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK *

    U+00BB

    0x22

    " QUOTATION MARK

    ` GRAVE ACCENT

    U+0060

    0x27

    ' APOSTROPHE

    ´ ACUTE ACCENT

    U+00B4

    0x27

    ' APOSTROPHE

    ΄ GREEK TONOS

    U+0384

    0x27

    ' APOSTROPHE

    ΅ GREEK DIALYTIKA TONOS

    U+0385

    0x27

    ' APOSTROPHE

    × MULTIPLICATION SIGN

    U+00D7

    0x2A

    * ASTERISK

    ¸ CEDILLA

    U+00B8

    0x2C

    , COMMA

    SOFT HYPHEN

    U+00AD

    0x2D

    - HYPHEN-MINUS

    · MIDDLE DOT

    U+00B7

    0x2E

    . FULL STOP

    ÷ DIVISION SIGN

    U+00F7

    0x2F

    / SOLIDUS

    ¹ SUPERSCRIPT ONE

    U+00B9

    0x31

    1 DIGIT ONE

    ² SUPERSCRIPT TWO

    U+00B2

    0x32

    2 DIGIT TWO

    ³ SUPERSCRIPT THREE

    U+00B3

    0x33

    3 DIGIT THREE

    ; GREEK QUESTION MARK (Erotimatiko)

    U+037E

    0x3B

    ; SEMICOLON

    Ā LATIN CAPITAL LETTER A WITH MACRON

    U+0100

    0x41

    A LATIN CAPITAL LETTER A

    Ă LATIN CAPITAL LETTER A WITH BREVE

    U+0102

    0x41

    A LATIN CAPITAL LETTER A

    Ą LATIN CAPITAL LETTER A WITH OGONEK

    U+0104

    0x41

    A LATIN CAPITAL LETTER A

    Ć LATIN CAPITAL LETTER C WITH ACUTE

    U+0106

    0x43

    C LATIN CAPITAL LETTER C

    Ĉ LATIN CAPITAL LETTER C WITH CIRCUMFLEX

    U+0108

    0x43

    C LATIN CAPITAL LETTER C

    Ċ LATIN CAPITAL LETTER C WITH DOT ABOVE

    U+010A

    0x43

    C LATIN CAPITAL LETTER C

    Č LATIN CAPITAL LETTER C WITH CARON

    U+010C

    0x43

    C LATIN CAPITAL LETTER C

    Ð LATIN CAPITAL LETTER ETH (Icelandic)

    U+00D0

    0x44

    D LATIN CAPITAL LETTER D

    Ď LATIN CAPITAL LETTER D WITH CARON

    U+010E

    0x44

    D LATIN CAPITAL LETTER D

    Đ LATIN CAPITAL LETTER D WITH STROKE

    U+0110

    0x44

    D LATIN CAPITAL LETTER D

    Ē LATIN CAPITAL LETTER E WITH MACRON

    U+0112

    0x45

    E LATIN CAPITAL LETTER E

    Ĕ LATIN CAPITAL LETTER E WITH BREVE

    U+0114

    0x45

    E LATIN CAPITAL LETTER E

    Ė LATIN CAPITAL LETTER E WITH DOT ABOVE

    U+0116

    0x45

    E LATIN CAPITAL LETTER E

    Ę LATIN CAPITAL LETTER E WITH OGONEK

    U+0118

    0x45

    E LATIN CAPITAL LETTER E

    Ě LATIN CAPITAL LETTER E WITH CARON

    U+011A

    0x45

    E LATIN CAPITAL LETTER E

    Ĝ LATIN CAPITAL LETTER G WITH CIRCUMFLEX

    U+011C

    0x47

    G LATIN CAPITAL LETTER G

    Ğ LATIN CAPITAL LETTER G WITH BREVE

    U+011E

    0x47

    G LATIN CAPITAL LETTER G

    Ġ LATIN CAPITAL LETTER G WITH DOT ABOVE

    U+0120

    0x47

    G LATIN CAPITAL LETTER G

    Ģ LATIN CAPITAL LETTER G WITH CEDILLA

    U+0122

    0x47

    G LATIN CAPITAL LETTER G

    Ĥ LATIN CAPITAL LETTER H WITH CIRCUMFLEX

    U+0124

    0x48

    H LATIN CAPITAL LETTER H

    Ħ LATIN CAPITAL LETTER H WITH STROKE

    U+0126

    0x48

    H LATIN CAPITAL LETTER H

    Ĩ LATIN CAPITAL LETTER I WITH TILDE

    U+0128

    0x49

    I LATIN CAPITAL LETTER I

    Ī LATIN CAPITAL LETTER I WITH MACRON

    U+012A

    0x49

    I LATIN CAPITAL LETTER I

    Ĭ LATIN CAPITAL LETTER I WITH BREVE

    U+012C

    0x49

    I LATIN CAPITAL LETTER I

    Į LATIN CAPITAL LETTER I WITH OGONEK

    U+012E

    0x49

    I LATIN CAPITAL LETTER I

    İ LATIN CAPITAL LETTER I WITH DOT ABOVE

    U+0130

    0x49

    I LATIN CAPITAL LETTER I

    Ĵ LATIN CAPITAL LETTER J WITH CIRCUMFLEX

    U+0134

    0x4A

    J LATIN CAPITAL LETTER J

    Ķ LATIN CAPITAL LETTER K WITH CEDILLA

    U+0136

    0x4B

    K LATIN CAPITAL LETTER K

    Ĺ LATIN CAPITAL LETTER L WITH ACUTE

    U+0139

    0x4C

    L LATIN CAPITAL LETTER L

    Ļ LATIN CAPITAL LETTER L WITH CEDILLA

    U+013B

    0x4C

    L LATIN CAPITAL LETTER L

    Ľ LATIN CAPITAL LETTER L WITH CARON

    U+013D

    0x4C

    L LATIN CAPITAL LETTER L

    Ŀ LATIN CAPITAL LETTER L WITH MIDDLE DOT

    U+013F

    0x4C

    L LATIN CAPITAL LETTER L

    Ł LATIN CAPITAL LETTER L WITH STROKE

    U+0141

    0x4C

    L LATIN CAPITAL LETTER L

    Ń LATIN CAPITAL LETTER N WITH ACUTE

    U+0143

    0x4E

    N LATIN CAPITAL LETTER N

    Ņ LATIN CAPITAL LETTER N WITH CEDILLA

    U+0145

    0x4E

    N LATIN CAPITAL LETTER N

    Ň LATIN CAPITAL LETTER N WITH CARON

    U+0147

    0x4E

    N LATIN CAPITAL LETTER N

    Ŋ LATIN CAPITAL LETTER ENG (Sami)

    U+014A

    0x4E

    N LATIN CAPITAL LETTER N

    Ō LATIN CAPITAL LETTER O WITH MACRON

    U+014C

    0x4F

    O LATIN CAPITAL LETTER O

    Ŏ LATIN CAPITAL LETTER O WITH BREVE

    U+014E

    0x4F

    O LATIN CAPITAL LETTER O

    ΠLATIN CAPITAL LIGATURE OE

    U+0152

    0x4F

    O LATIN CAPITAL LETTER O

    Ŕ LATIN CAPITAL LETTER R WITH ACUTE

    U+0154

    0x52

    R LATIN CAPITAL LETTER R

    Ŗ LATIN CAPITAL LETTER R WITH CEDILLA

    U+0156

    0x52

    R LATIN CAPITAL LETTER R

    Ř LATIN CAPITAL LETTER R WITH CARON

    U+0158

    0x52

    R LATIN CAPITAL LETTER R

    Ś LATIN CAPITAL LETTER S WITH ACUTE

    U+015A

    0x53

    S LATIN CAPITAL LETTER S

    Ŝ LATIN CAPITAL LETTER S WITH CIRCUMFLEX

    U+015C

    0x53

    S LATIN CAPITAL LETTER S

    Ş LATIN CAPITAL LETTER S WITH CEDILLA *

    U+015E

    0x53

    S LATIN CAPITAL LETTER S

    Š LATIN CAPITAL LETTER S WITH CARON

    U+0160

    0x53

    S LATIN CAPITAL LETTER S

    Þ LATIN CAPITAL LETTER THORN (Icelandic)

    U+00DE

    0x54

    T LATIN CAPITAL LETTER T

    Ţ LATIN CAPITAL LETTER T WITH CEDILLA *

    U+0162

    0x54

    T LATIN CAPITAL LETTER T

    Ť LATIN CAPITAL LETTER T WITH CARON

    U+0164

    0x54

    T LATIN CAPITAL LETTER T

    Ŧ LATIN CAPITAL LETTER T WITH STROKE

    U+0166

    0x54

    T LATIN CAPITAL LETTER T

    Ũ LATIN CAPITAL LETTER U WITH TILDE

    U+0168

    0x55

    U LATIN CAPITAL LETTER U

    Ū LATIN CAPITAL LETTER U WITH MACRON

    U+016A

    0x55

    U LATIN CAPITAL LETTER U

    Ŭ LATIN CAPITAL LETTER U WITH BREVE

    U+016C

    0x55

    U LATIN CAPITAL LETTER U

    Ů LATIN CAPITAL LETTER U WITH RING ABOVE

    U+016E

    0x55

    U LATIN CAPITAL LETTER U

    Ų LATIN CAPITAL LETTER U WITH OGONEK

    U+0172

    0x55

    U LATIN CAPITAL LETTER U

    Ŵ LATIN CAPITAL LETTER W WITH CIRCUMFLEX

    U+0174

    0x57

    W LATIN CAPITAL LETTER W

    Ŷ LATIN CAPITAL LETTER Y WITH CIRCUMFLEX

    U+0176

    0x59

    Y LATIN CAPITAL LETTER Y

    Ÿ LATIN CAPITAL LETTER Y WITH DIAERESIS

    U+0178

    0x59

    Y LATIN CAPITAL LETTER Y

    Ź LATIN CAPITAL LETTER Z WITH ACUTE

    U+0179

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ż LATIN CAPITAL LETTER Z WITH DOT ABOVE

    U+017B

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ž LATIN CAPITAL LETTER Z WITH CARON

    U+017D

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    U+00D6

    0x5C

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    Ő LATIN CAPITAL LETTER O WITH DOUBLE ACUTE

    U+0150

    0x5C

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    Ű LATIN CAPITAL LETTER U WITH DOUBLE ACUTE

    U+0170

    0x5E

    Ü LATIN CAPITAL LETTER U WITH DIAERESIS

    ā LATIN SMALL LETTER A WITH MACRON

    U+0101

    0x61

    a LATIN SMALL LETTER A

    ă LATIN SMALL LETTER A WITH BREVE

    U+0103

    0x61

    a LATIN SMALL LETTER A

    ą LATIN SMALL LETTER A WITH OGONEK

    U+0105

    0x61

    a LATIN SMALL LETTER A

    ª FEMININE ORDINAL INDICATOR

    U+00AA

    0x61

    a LATIN SMALL LETTER A

    ć LATIN SMALL LETTER C WITH ACUTE

    U+0107

    0x63

    c LATIN SMALL LETTER C

    ĉ LATIN SMALL LETTER C WITH CIRCUMFLEX

    U+0109

    0x63

    c LATIN SMALL LETTER C

    ċ LATIN SMALL LETTER C WITH DOT ABOVE

    U+010B

    0x63

    c LATIN SMALL LETTER C

    č LATIN SMALL LETTER C WITH CARON

    U+010D

    0x63

    c LATIN SMALL LETTER C

    ¢ CENT SIGN

    U+00A2

    0x63

    c LATIN SMALL LETTER C

    © COPYRIGHT SIGN

    U+00A9

    0x63

    c LATIN SMALL LETTER C

    ð LATIN SMALL LETTER ETH (Icelandic)

    U+00F0

    0x64

    d LATIN SMALL LETTER D

    ď LATIN SMALL LETTER D WITH CARON

    U+010F

    0x64

    d LATIN SMALL LETTER D

    đ LATIN SMALL LETTER D WITH STROKE

    U+0111

    0x64

    d LATIN SMALL LETTER D

    ē LATIN SMALL LETTER E WITH MACRON

    U+0113

    0x65

    e LATIN SMALL LETTER E

    ĕ LATIN SMALL LETTER E WITH BREVE

    U+0115

    0x65

    e LATIN SMALL LETTER E

    ė LATIN SMALL LETTER E WITH DOT ABOVE

    U+0117

    0x65

    e LATIN SMALL LETTER E

    ę LATIN SMALL LETTER E WITH OGONEK

    U+0119

    0x65

    e LATIN SMALL LETTER E

    ě LATIN SMALL LETTER E WITH CARON

    U+011B

    0x65

    e LATIN SMALL LETTER E

    ĝ LATIN SMALL LETTER G WITH CIRCUMFLEX

    U+011D

    0x67

    g LATIN SMALL LETTER G

    ğ LATIN SMALL LETTER G WITH BREVE

    U+011F

    0x67

    g LATIN SMALL LETTER G

    ġ LATIN SMALL LETTER G WITH DOT ABOVE

    U+0121

    0x67

    g LATIN SMALL LETTER G

    ģ LATIN SMALL LETTER G WITH CEDILLA

    U+0123

    0x67

    g LATIN SMALL LETTER G

    ĥ LATIN SMALL LETTER H WITH CIRCUMFLEX

    U+0125

    0x68

    h LATIN SMALL LETTER H

    ħ LATIN SMALL LETTER H WITH STROKE

    U+0127

    0x68

    h LATIN SMALL LETTER H

    ĩ LATIN SMALL LETTER I WITH TILDE

    U+0129

    0x69

    i LATIN SMALL LETTER I

    ī LATIN SMALL LETTER I WITH MACRON

    U+012B

    0x69

    i LATIN SMALL LETTER I

    ĭ LATIN SMALL LETTER I WITH BREVE

    U+012D

    0x69

    i LATIN SMALL LETTER I

    į LATIN SMALL LETTER I WITH OGONEK

    U+012F

    0x69

    i LATIN SMALL LETTER I

    ı LATIN SMALL LETTER DOTLESS I

    U+0131

    0x69

    i LATIN SMALL LETTER I

    ĵ LATIN SMALL LETTER J WITH CIRCUMFLEX

    U+0135

    0x6A

    j LATIN SMALL LETTER J

    ķ LATIN SMALL LETTER K WITH CEDILLA

    U+0137

    0x6B

    k LATIN SMALL LETTER K

    ĸ LATIN SMALL LETTER KRA (Greenlandic)

    U+0138

    0x6B

    k LATIN SMALL LETTER K

    ĺ LATIN SMALL LETTER L WITH ACUTE

    U+013A

    0x6C

    l LATIN SMALL LETTER L

    ļ LATIN SMALL LETTER L WITH CEDILLA

    U+013C

    0x6C

    l LATIN SMALL LETTER L

    ľ LATIN SMALL LETTER L WITH CARON

    U+013E

    0x6C

    l LATIN SMALL LETTER L

    ŀ LATIN SMALL LETTER L WITH MIDDLE DOT

    U+0140

    0x6C

    l LATIN SMALL LETTER L

    ł LATIN SMALL LETTER L WITH STROKE

    U+0142

    0x6C

    l LATIN SMALL LETTER L

    ń LATIN SMALL LETTER N WITH ACUTE

    U+0144

    0x6E

    n LATIN SMALL LETTER N

    ņ LATIN SMALL LETTER N WITH CEDILLA

    U+0146

    0x6E

    n LATIN SMALL LETTER N

    ň LATIN SMALL LETTER N WITH CARON

    U+0148

    0x6E

    n LATIN SMALL LETTER N

    ʼn LATIN SMALL LETTER N PRECEDED BY APOSTROPHE

    U+0149

    0x6E

    n LATIN SMALL LETTER N

     ŋ LATIN SMALL LETTER ENG (Sami)

    U+014B

    0x6E

    n LATIN SMALL LETTER N

    ō LATIN SMALL LETTER O WITH MACRON

    U+014D

    0x6F

    o LATIN SMALL LETTER O

    ŏ LATIN SMALL LETTER O WITH BREVE

    U+014F

    0x6F

    o LATIN SMALL LETTER O

    ° DEGREE SIGN

    U+00B0

    0x6F

    o LATIN SMALL LETTER O

    º MASCULINE ORDINAL INDICATOR

    U+00BA

    0x6F

    o LATIN SMALL LETTER O

    œ LATIN SMALL LIGATURE OE

    U+0153

    0x6F

    o LATIN SMALL LETTER O

    ŕ LATIN SMALL LETTER R WITH ACUTE

    U+0155

    0x72

    r LATIN SMALL LETTER R

    ŗ LATIN SMALL LETTER R WITH CEDILLA

    U+0157

    0x72

    r LATIN SMALL LETTER R

    ř LATIN SMALL LETTER R WITH CARON

    U+0159

    0x72

    r LATIN SMALL LETTER R

    ® REGISTERED SIGN

    U+00AE

    0x72

    r LATIN SMALL LETTER R

    ś LATIN SMALL LETTER S WITH ACUTE

    U+015B

    0x73

    s LATIN SMALL LETTER S

    ŝ LATIN SMALL LETTER S WITH CIRCUMFLEX

    U+015D

    0x73

    s LATIN SMALL LETTER S

    ş LATIN SMALL LETTER S WITH CEDILLA *

    U+015F

    0x73

    s LATIN SMALL LETTER S

    š LATIN SMALL LETTER S WITH CARON

    U+0161

    0x73

    s LATIN SMALL LETTER S

    þ LATIN SMALL LETTER THORN (Icelandic)

    U+00FE

    0x74

    t LATIN SMALL LETTER T

    ţ LATIN SMALL LETTER T WITH CEDILLA *

    U+0163

    0x74

    t LATIN SMALL LETTER T

    ť LATIN SMALL LETTER T WITH CARON

    U+0165

    0x74

    t LATIN SMALL LETTER T

    ŧ LATIN SMALL LETTER T WITH STROKE

    U+0167

    0x74

    t LATIN SMALL LETTER T

    ũ LATIN SMALL LETTER U WITH TILDE

    U+0169

    0x75

    u LATIN SMALL LETTER U

    ū LATIN SMALL LETTER U WITH MACRON

    U+016B

    0x75

    u LATIN SMALL LETTER U

    ŭ LATIN SMALL LETTER U WITH BREVE

    U+016D

    0x75

    u LATIN SMALL LETTER U

    ů LATIN SMALL LETTER U WITH RING ABOVE

    U+016F

    0x75

    u LATIN SMALL LETTER U

    ų LATIN SMALL LETTER U WITH OGONEK

    U+0173

    0x75

    u LATIN SMALL LETTER U

    µ MICRO SIGN

    U+00B5

    0x75

    u LATIN SMALL LETTER U

    ŵ LATIN SMALL LETTER W WITH CIRCUMFLEX

    U+0175

    0x77

    w LATIN SMALL LETTER W

    ŷ LATIN SMALL LETTER Y WITH CIRCUMFLEX

    U+0177

    0x79

    y LATIN SMALL LETTER Y

    ź LATIN SMALL LETTER Z WITH ACUTE

    U+017A

    0x7A

    z LATIN SMALL LETTER Z

     ż LATIN SMALL LETTER Z WITH DOT ABOVE

    U+017C

    0x7A

    z LATIN SMALL LETTER Z

    ž LATIN SMALL LETTER Z WITH CARON

    U+017E

    0x7A

    z LATIN SMALL LETTER Z

    ő LATIN SMALL LETTER O WITH DOUBLE ACUTE

    U+0151

    0x7C

    ö LATIN SMALL LETTER O WITH DIAERESIS

    ű LATIN SMALL LETTER U WITH DOUBLE ACUTE

    U+0171

    0x7E

    ü LATIN SMALL LETTER U WITH DIAERESIS

    Table 2 lists the 9 characters in Lossy Character 1 supported by Standard SMS Converter but not by Extended SMS Converter.

    Table 2

    Character

    Unicode

    GSM

    Converted Character

    ϕ GREEK PHI SYMBOL

    0x03D5

    0x12

    Φ GREEK CAPITAL LETTER PHI

    Ω OHM SIGN

    0x2126

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ∏ N-ARY PRODUCT

    0x220F

    0x16

    Π GREEK CAPITAL LETTER PI

    ∑ N-ARY SUMMATION

    0x2211

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    ϑ GREEK THETA SYMBOL

    0x03D1

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ϐ GREEK BETA SYMBOL

    0x03D0

    0x42

    B LATIN CAPITAL LETTER B

    ϒ GREEK UPSILON WITH HOOK SYMBOL

    0x03D2

    0x59

    Y LATIN CAPITAL LETTER Y

    ϓ GREEK UPSILON WITH ACUTE AND HOOK SYMBOL

    0x03D3

    0x59

    Y LATIN CAPITAL LETTER Y

    ϔ GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL

    0x03D4

    0x59

    Y LATIN CAPITAL LETTER Y

    See also

    SMS Encodings and Converters Overview

    \ No newline at end of file +Extended SMS Converter

    The Extended SMS Converter uses the lossy mechanism to extend the alphabet of the standard converter. It maps a wider set of input character codes, including commonly-used Eastern European Unicode characters, to the standard 7-bit alphabet. This section describes the Extended SMS Converter and the alphabet it supports.

    Introduction

    Languages supported by this converter include Croatian, Czech, Estonian, Hungarian, Icelandic, Latvian, Lithuanian, Polish, Romanian, Serbian, Slovak, Slovenian, Turkish, Portuguese and Spanish. This converter is identified by the KCharacterSetIdentifierExtendedSms7Bit UID, which is defined in the charconv.h file.

    Any undefined Unicode is converted to a question mark (?)–GSM code 0x37. Any code outside GSM 0x00 ~0x7F is converted to the Unicode replacement character 0xFFFD.

    Alphabet

    The highlighted boxes in Figure 1 illustrate the alphabet of the extended SMS converter:

    • GSM 7-bit default alphabet

    • GSM 7-bit default alphabet extension table

    • Extra lossy conversions–exclude 9 characters listed in Table 2

    • Extended lossy conversions–shown as Lossy Characters 2 in Figure 1.

    Figure 1

    Table 1 lists the extra lossy conversions supported by this converter in addition to those supported by the standard converter.

    Table 1

    Character

    Unicode

    GSM

    Converted Character

    Ώ GREEK CAPITAL LETTER OMEGA WITH TONOS

    U+038F

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    (NO-BREAK SPACE)

    U+00A0

    0x20

    (SPACE)

    « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK *

    U+00AB

    0x22

    " QUOTATION MARK

    » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK *

    U+00BB

    0x22

    " QUOTATION MARK

    ` GRAVE ACCENT

    U+0060

    0x27

    ' APOSTROPHE

    ´ ACUTE ACCENT

    U+00B4

    0x27

    ' APOSTROPHE

    ΄ GREEK TONOS

    U+0384

    0x27

    ' APOSTROPHE

    ΅ GREEK DIALYTIKA TONOS

    U+0385

    0x27

    ' APOSTROPHE

    × MULTIPLICATION SIGN

    U+00D7

    0x2A

    * ASTERISK

    ¸ CEDILLA

    U+00B8

    0x2C

    , COMMA

    SOFT HYPHEN

    U+00AD

    0x2D

    - HYPHEN-MINUS

    · MIDDLE DOT

    U+00B7

    0x2E

    . FULL STOP

    ÷ DIVISION SIGN

    U+00F7

    0x2F

    / SOLIDUS

    ¹ SUPERSCRIPT ONE

    U+00B9

    0x31

    1 DIGIT ONE

    ² SUPERSCRIPT TWO

    U+00B2

    0x32

    2 DIGIT TWO

    ³ SUPERSCRIPT THREE

    U+00B3

    0x33

    3 DIGIT THREE

    ; GREEK QUESTION MARK (Erotimatiko)

    U+037E

    0x3B

    ; SEMICOLON

    Ā LATIN CAPITAL LETTER A WITH MACRON

    U+0100

    0x41

    A LATIN CAPITAL LETTER A

    Ă LATIN CAPITAL LETTER A WITH BREVE

    U+0102

    0x41

    A LATIN CAPITAL LETTER A

    Ą LATIN CAPITAL LETTER A WITH OGONEK

    U+0104

    0x41

    A LATIN CAPITAL LETTER A

    Ć LATIN CAPITAL LETTER C WITH ACUTE

    U+0106

    0x43

    C LATIN CAPITAL LETTER C

    Ĉ LATIN CAPITAL LETTER C WITH CIRCUMFLEX

    U+0108

    0x43

    C LATIN CAPITAL LETTER C

    Ċ LATIN CAPITAL LETTER C WITH DOT ABOVE

    U+010A

    0x43

    C LATIN CAPITAL LETTER C

    Č LATIN CAPITAL LETTER C WITH CARON

    U+010C

    0x43

    C LATIN CAPITAL LETTER C

    Ð LATIN CAPITAL LETTER ETH (Icelandic)

    U+00D0

    0x44

    D LATIN CAPITAL LETTER D

    Ď LATIN CAPITAL LETTER D WITH CARON

    U+010E

    0x44

    D LATIN CAPITAL LETTER D

    Đ LATIN CAPITAL LETTER D WITH STROKE

    U+0110

    0x44

    D LATIN CAPITAL LETTER D

    Ē LATIN CAPITAL LETTER E WITH MACRON

    U+0112

    0x45

    E LATIN CAPITAL LETTER E

    Ĕ LATIN CAPITAL LETTER E WITH BREVE

    U+0114

    0x45

    E LATIN CAPITAL LETTER E

    Ė LATIN CAPITAL LETTER E WITH DOT ABOVE

    U+0116

    0x45

    E LATIN CAPITAL LETTER E

    Ę LATIN CAPITAL LETTER E WITH OGONEK

    U+0118

    0x45

    E LATIN CAPITAL LETTER E

    Ě LATIN CAPITAL LETTER E WITH CARON

    U+011A

    0x45

    E LATIN CAPITAL LETTER E

    Ĝ LATIN CAPITAL LETTER G WITH CIRCUMFLEX

    U+011C

    0x47

    G LATIN CAPITAL LETTER G

    Ğ LATIN CAPITAL LETTER G WITH BREVE

    U+011E

    0x47

    G LATIN CAPITAL LETTER G

    Ġ LATIN CAPITAL LETTER G WITH DOT ABOVE

    U+0120

    0x47

    G LATIN CAPITAL LETTER G

    Ģ LATIN CAPITAL LETTER G WITH CEDILLA

    U+0122

    0x47

    G LATIN CAPITAL LETTER G

    Ĥ LATIN CAPITAL LETTER H WITH CIRCUMFLEX

    U+0124

    0x48

    H LATIN CAPITAL LETTER H

    Ħ LATIN CAPITAL LETTER H WITH STROKE

    U+0126

    0x48

    H LATIN CAPITAL LETTER H

    Ĩ LATIN CAPITAL LETTER I WITH TILDE

    U+0128

    0x49

    I LATIN CAPITAL LETTER I

    Ī LATIN CAPITAL LETTER I WITH MACRON

    U+012A

    0x49

    I LATIN CAPITAL LETTER I

    Ĭ LATIN CAPITAL LETTER I WITH BREVE

    U+012C

    0x49

    I LATIN CAPITAL LETTER I

    Į LATIN CAPITAL LETTER I WITH OGONEK

    U+012E

    0x49

    I LATIN CAPITAL LETTER I

    İ LATIN CAPITAL LETTER I WITH DOT ABOVE

    U+0130

    0x49

    I LATIN CAPITAL LETTER I

    Ĵ LATIN CAPITAL LETTER J WITH CIRCUMFLEX

    U+0134

    0x4A

    J LATIN CAPITAL LETTER J

    Ķ LATIN CAPITAL LETTER K WITH CEDILLA

    U+0136

    0x4B

    K LATIN CAPITAL LETTER K

    Ĺ LATIN CAPITAL LETTER L WITH ACUTE

    U+0139

    0x4C

    L LATIN CAPITAL LETTER L

    Ļ LATIN CAPITAL LETTER L WITH CEDILLA

    U+013B

    0x4C

    L LATIN CAPITAL LETTER L

    Ľ LATIN CAPITAL LETTER L WITH CARON

    U+013D

    0x4C

    L LATIN CAPITAL LETTER L

    Ŀ LATIN CAPITAL LETTER L WITH MIDDLE DOT

    U+013F

    0x4C

    L LATIN CAPITAL LETTER L

    Ł LATIN CAPITAL LETTER L WITH STROKE

    U+0141

    0x4C

    L LATIN CAPITAL LETTER L

    Ń LATIN CAPITAL LETTER N WITH ACUTE

    U+0143

    0x4E

    N LATIN CAPITAL LETTER N

    Ņ LATIN CAPITAL LETTER N WITH CEDILLA

    U+0145

    0x4E

    N LATIN CAPITAL LETTER N

    Ň LATIN CAPITAL LETTER N WITH CARON

    U+0147

    0x4E

    N LATIN CAPITAL LETTER N

    Ŋ LATIN CAPITAL LETTER ENG (Sami)

    U+014A

    0x4E

    N LATIN CAPITAL LETTER N

    Ō LATIN CAPITAL LETTER O WITH MACRON

    U+014C

    0x4F

    O LATIN CAPITAL LETTER O

    Ŏ LATIN CAPITAL LETTER O WITH BREVE

    U+014E

    0x4F

    O LATIN CAPITAL LETTER O

    ΠLATIN CAPITAL LIGATURE OE

    U+0152

    0x4F

    O LATIN CAPITAL LETTER O

    Ŕ LATIN CAPITAL LETTER R WITH ACUTE

    U+0154

    0x52

    R LATIN CAPITAL LETTER R

    Ŗ LATIN CAPITAL LETTER R WITH CEDILLA

    U+0156

    0x52

    R LATIN CAPITAL LETTER R

    Ř LATIN CAPITAL LETTER R WITH CARON

    U+0158

    0x52

    R LATIN CAPITAL LETTER R

    Ś LATIN CAPITAL LETTER S WITH ACUTE

    U+015A

    0x53

    S LATIN CAPITAL LETTER S

    Ŝ LATIN CAPITAL LETTER S WITH CIRCUMFLEX

    U+015C

    0x53

    S LATIN CAPITAL LETTER S

    Ş LATIN CAPITAL LETTER S WITH CEDILLA *

    U+015E

    0x53

    S LATIN CAPITAL LETTER S

    Š LATIN CAPITAL LETTER S WITH CARON

    U+0160

    0x53

    S LATIN CAPITAL LETTER S

    Þ LATIN CAPITAL LETTER THORN (Icelandic)

    U+00DE

    0x54

    T LATIN CAPITAL LETTER T

    Ţ LATIN CAPITAL LETTER T WITH CEDILLA *

    U+0162

    0x54

    T LATIN CAPITAL LETTER T

    Ť LATIN CAPITAL LETTER T WITH CARON

    U+0164

    0x54

    T LATIN CAPITAL LETTER T

    Ŧ LATIN CAPITAL LETTER T WITH STROKE

    U+0166

    0x54

    T LATIN CAPITAL LETTER T

    Ũ LATIN CAPITAL LETTER U WITH TILDE

    U+0168

    0x55

    U LATIN CAPITAL LETTER U

    Ū LATIN CAPITAL LETTER U WITH MACRON

    U+016A

    0x55

    U LATIN CAPITAL LETTER U

    Ŭ LATIN CAPITAL LETTER U WITH BREVE

    U+016C

    0x55

    U LATIN CAPITAL LETTER U

    Ů LATIN CAPITAL LETTER U WITH RING ABOVE

    U+016E

    0x55

    U LATIN CAPITAL LETTER U

    Ų LATIN CAPITAL LETTER U WITH OGONEK

    U+0172

    0x55

    U LATIN CAPITAL LETTER U

    Ŵ LATIN CAPITAL LETTER W WITH CIRCUMFLEX

    U+0174

    0x57

    W LATIN CAPITAL LETTER W

    Ŷ LATIN CAPITAL LETTER Y WITH CIRCUMFLEX

    U+0176

    0x59

    Y LATIN CAPITAL LETTER Y

    Ÿ LATIN CAPITAL LETTER Y WITH DIAERESIS

    U+0178

    0x59

    Y LATIN CAPITAL LETTER Y

    Ź LATIN CAPITAL LETTER Z WITH ACUTE

    U+0179

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ż LATIN CAPITAL LETTER Z WITH DOT ABOVE

    U+017B

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ž LATIN CAPITAL LETTER Z WITH CARON

    U+017D

    0x5A

    Z LATIN CAPITAL LETTER Z

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    U+00D6

    0x5C

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    Ő LATIN CAPITAL LETTER O WITH DOUBLE ACUTE

    U+0150

    0x5C

    Ö LATIN CAPITAL LETTER O WITH DIAERESIS

    Ű LATIN CAPITAL LETTER U WITH DOUBLE ACUTE

    U+0170

    0x5E

    Ü LATIN CAPITAL LETTER U WITH DIAERESIS

    ā LATIN SMALL LETTER A WITH MACRON

    U+0101

    0x61

    a LATIN SMALL LETTER A

    ă LATIN SMALL LETTER A WITH BREVE

    U+0103

    0x61

    a LATIN SMALL LETTER A

    ą LATIN SMALL LETTER A WITH OGONEK

    U+0105

    0x61

    a LATIN SMALL LETTER A

    ª FEMININE ORDINAL INDICATOR

    U+00AA

    0x61

    a LATIN SMALL LETTER A

    ć LATIN SMALL LETTER C WITH ACUTE

    U+0107

    0x63

    c LATIN SMALL LETTER C

    ĉ LATIN SMALL LETTER C WITH CIRCUMFLEX

    U+0109

    0x63

    c LATIN SMALL LETTER C

    ċ LATIN SMALL LETTER C WITH DOT ABOVE

    U+010B

    0x63

    c LATIN SMALL LETTER C

    č LATIN SMALL LETTER C WITH CARON

    U+010D

    0x63

    c LATIN SMALL LETTER C

    ¢ CENT SIGN

    U+00A2

    0x63

    c LATIN SMALL LETTER C

    © COPYRIGHT SIGN

    U+00A9

    0x63

    c LATIN SMALL LETTER C

    ð LATIN SMALL LETTER ETH (Icelandic)

    U+00F0

    0x64

    d LATIN SMALL LETTER D

    ď LATIN SMALL LETTER D WITH CARON

    U+010F

    0x64

    d LATIN SMALL LETTER D

    đ LATIN SMALL LETTER D WITH STROKE

    U+0111

    0x64

    d LATIN SMALL LETTER D

    ē LATIN SMALL LETTER E WITH MACRON

    U+0113

    0x65

    e LATIN SMALL LETTER E

    ĕ LATIN SMALL LETTER E WITH BREVE

    U+0115

    0x65

    e LATIN SMALL LETTER E

    ė LATIN SMALL LETTER E WITH DOT ABOVE

    U+0117

    0x65

    e LATIN SMALL LETTER E

    ę LATIN SMALL LETTER E WITH OGONEK

    U+0119

    0x65

    e LATIN SMALL LETTER E

    ě LATIN SMALL LETTER E WITH CARON

    U+011B

    0x65

    e LATIN SMALL LETTER E

    ĝ LATIN SMALL LETTER G WITH CIRCUMFLEX

    U+011D

    0x67

    g LATIN SMALL LETTER G

    ğ LATIN SMALL LETTER G WITH BREVE

    U+011F

    0x67

    g LATIN SMALL LETTER G

    ġ LATIN SMALL LETTER G WITH DOT ABOVE

    U+0121

    0x67

    g LATIN SMALL LETTER G

    ģ LATIN SMALL LETTER G WITH CEDILLA

    U+0123

    0x67

    g LATIN SMALL LETTER G

    ĥ LATIN SMALL LETTER H WITH CIRCUMFLEX

    U+0125

    0x68

    h LATIN SMALL LETTER H

    ħ LATIN SMALL LETTER H WITH STROKE

    U+0127

    0x68

    h LATIN SMALL LETTER H

    ĩ LATIN SMALL LETTER I WITH TILDE

    U+0129

    0x69

    i LATIN SMALL LETTER I

    ī LATIN SMALL LETTER I WITH MACRON

    U+012B

    0x69

    i LATIN SMALL LETTER I

    ĭ LATIN SMALL LETTER I WITH BREVE

    U+012D

    0x69

    i LATIN SMALL LETTER I

    į LATIN SMALL LETTER I WITH OGONEK

    U+012F

    0x69

    i LATIN SMALL LETTER I

    ı LATIN SMALL LETTER DOTLESS I

    U+0131

    0x69

    i LATIN SMALL LETTER I

    ĵ LATIN SMALL LETTER J WITH CIRCUMFLEX

    U+0135

    0x6A

    j LATIN SMALL LETTER J

    ķ LATIN SMALL LETTER K WITH CEDILLA

    U+0137

    0x6B

    k LATIN SMALL LETTER K

    ĸ LATIN SMALL LETTER KRA (Greenlandic)

    U+0138

    0x6B

    k LATIN SMALL LETTER K

    ĺ LATIN SMALL LETTER L WITH ACUTE

    U+013A

    0x6C

    l LATIN SMALL LETTER L

    ļ LATIN SMALL LETTER L WITH CEDILLA

    U+013C

    0x6C

    l LATIN SMALL LETTER L

    ľ LATIN SMALL LETTER L WITH CARON

    U+013E

    0x6C

    l LATIN SMALL LETTER L

    ŀ LATIN SMALL LETTER L WITH MIDDLE DOT

    U+0140

    0x6C

    l LATIN SMALL LETTER L

    ł LATIN SMALL LETTER L WITH STROKE

    U+0142

    0x6C

    l LATIN SMALL LETTER L

    ń LATIN SMALL LETTER N WITH ACUTE

    U+0144

    0x6E

    n LATIN SMALL LETTER N

    ņ LATIN SMALL LETTER N WITH CEDILLA

    U+0146

    0x6E

    n LATIN SMALL LETTER N

    ň LATIN SMALL LETTER N WITH CARON

    U+0148

    0x6E

    n LATIN SMALL LETTER N

    ʼn LATIN SMALL LETTER N PRECEDED BY APOSTROPHE

    U+0149

    0x6E

    n LATIN SMALL LETTER N

     ŋ LATIN SMALL LETTER ENG (Sami)

    U+014B

    0x6E

    n LATIN SMALL LETTER N

    ō LATIN SMALL LETTER O WITH MACRON

    U+014D

    0x6F

    o LATIN SMALL LETTER O

    ŏ LATIN SMALL LETTER O WITH BREVE

    U+014F

    0x6F

    o LATIN SMALL LETTER O

    ° DEGREE SIGN

    U+00B0

    0x6F

    o LATIN SMALL LETTER O

    º MASCULINE ORDINAL INDICATOR

    U+00BA

    0x6F

    o LATIN SMALL LETTER O

    œ LATIN SMALL LIGATURE OE

    U+0153

    0x6F

    o LATIN SMALL LETTER O

    ŕ LATIN SMALL LETTER R WITH ACUTE

    U+0155

    0x72

    r LATIN SMALL LETTER R

    ŗ LATIN SMALL LETTER R WITH CEDILLA

    U+0157

    0x72

    r LATIN SMALL LETTER R

    ř LATIN SMALL LETTER R WITH CARON

    U+0159

    0x72

    r LATIN SMALL LETTER R

    ® REGISTERED SIGN

    U+00AE

    0x72

    r LATIN SMALL LETTER R

    ś LATIN SMALL LETTER S WITH ACUTE

    U+015B

    0x73

    s LATIN SMALL LETTER S

    ŝ LATIN SMALL LETTER S WITH CIRCUMFLEX

    U+015D

    0x73

    s LATIN SMALL LETTER S

    ş LATIN SMALL LETTER S WITH CEDILLA *

    U+015F

    0x73

    s LATIN SMALL LETTER S

    š LATIN SMALL LETTER S WITH CARON

    U+0161

    0x73

    s LATIN SMALL LETTER S

    þ LATIN SMALL LETTER THORN (Icelandic)

    U+00FE

    0x74

    t LATIN SMALL LETTER T

    ţ LATIN SMALL LETTER T WITH CEDILLA *

    U+0163

    0x74

    t LATIN SMALL LETTER T

    ť LATIN SMALL LETTER T WITH CARON

    U+0165

    0x74

    t LATIN SMALL LETTER T

    ŧ LATIN SMALL LETTER T WITH STROKE

    U+0167

    0x74

    t LATIN SMALL LETTER T

    ũ LATIN SMALL LETTER U WITH TILDE

    U+0169

    0x75

    u LATIN SMALL LETTER U

    ū LATIN SMALL LETTER U WITH MACRON

    U+016B

    0x75

    u LATIN SMALL LETTER U

    ŭ LATIN SMALL LETTER U WITH BREVE

    U+016D

    0x75

    u LATIN SMALL LETTER U

    ů LATIN SMALL LETTER U WITH RING ABOVE

    U+016F

    0x75

    u LATIN SMALL LETTER U

    ų LATIN SMALL LETTER U WITH OGONEK

    U+0173

    0x75

    u LATIN SMALL LETTER U

    µ MICRO SIGN

    U+00B5

    0x75

    u LATIN SMALL LETTER U

    ŵ LATIN SMALL LETTER W WITH CIRCUMFLEX

    U+0175

    0x77

    w LATIN SMALL LETTER W

    ŷ LATIN SMALL LETTER Y WITH CIRCUMFLEX

    U+0177

    0x79

    y LATIN SMALL LETTER Y

    ź LATIN SMALL LETTER Z WITH ACUTE

    U+017A

    0x7A

    z LATIN SMALL LETTER Z

     ż LATIN SMALL LETTER Z WITH DOT ABOVE

    U+017C

    0x7A

    z LATIN SMALL LETTER Z

    ž LATIN SMALL LETTER Z WITH CARON

    U+017E

    0x7A

    z LATIN SMALL LETTER Z

    ő LATIN SMALL LETTER O WITH DOUBLE ACUTE

    U+0151

    0x7C

    ö LATIN SMALL LETTER O WITH DIAERESIS

    ű LATIN SMALL LETTER U WITH DOUBLE ACUTE

    U+0171

    0x7E

    ü LATIN SMALL LETTER U WITH DIAERESIS

    Table 2 lists the 9 characters in Lossy Character 1 supported by Standard SMS Converter but not by Extended SMS Converter.

    Table 2

    Character

    Unicode

    GSM

    Converted Character

    ϕ GREEK PHI SYMBOL

    0x03D5

    0x12

    Φ GREEK CAPITAL LETTER PHI

    Ω OHM SIGN

    0x2126

    0x15

    Ω GREEK CAPITAL LETTER OMEGA

    ∏ N-ARY PRODUCT

    0x220F

    0x16

    Π GREEK CAPITAL LETTER PI

    ∑ N-ARY SUMMATION

    0x2211

    0x18

    Σ GREEK CAPITAL LETTER SIGMA

    ϑ GREEK THETA SYMBOL

    0x03D1

    0x19

    Θ GREEK CAPITAL LETTER THETA

    ϐ GREEK BETA SYMBOL

    0x03D0

    0x42

    B LATIN CAPITAL LETTER B

    ϒ GREEK UPSILON WITH HOOK SYMBOL

    0x03D2

    0x59

    Y LATIN CAPITAL LETTER Y

    ϓ GREEK UPSILON WITH ACUTE AND HOOK SYMBOL

    0x03D3

    0x59

    Y LATIN CAPITAL LETTER Y

    ϔ GREEK UPSILON WITH DIAERESIS AND HOOK SYMBOL

    0x03D4

    0x59

    Y LATIN CAPITAL LETTER Y

    See also

    SMS Encodings and Converters Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B12AAA82-0534-5FBB-B9BA-33056B988575_d0e357005_href.png Binary file Symbian3/SDK/Source/GUID-B12AAA82-0534-5FBB-B9BA-33056B988575_d0e357005_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B12AAA82-0534-5FBB-B9BA-33056B988575_d0e385998_href.png Binary file Symbian3/SDK/Source/GUID-B12AAA82-0534-5FBB-B9BA-33056B988575_d0e385998_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B12EEEF5-311B-49F8-A2DA-D6EF6A705071_d0e53053_href.png Binary file Symbian3/SDK/Source/GUID-B12EEEF5-311B-49F8-A2DA-D6EF6A705071_d0e53053_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B12EEEF5-311B-49F8-A2DA-D6EF6A705071_d0e53196_href.png Binary file Symbian3/SDK/Source/GUID-B12EEEF5-311B-49F8-A2DA-D6EF6A705071_d0e53196_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B131AE10-B9B1-53D2-8CAA-A9045957D6F9_d0e213742_href.png Binary file Symbian3/SDK/Source/GUID-B131AE10-B9B1-53D2-8CAA-A9045957D6F9_d0e213742_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B131AE10-B9B1-53D2-8CAA-A9045957D6F9_d0e218740_href.png Binary file Symbian3/SDK/Source/GUID-B131AE10-B9B1-53D2-8CAA-A9045957D6F9_d0e218740_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B16E3A7D-FF14-559A-BF86-2A1A1A584CDC_d0e341463_href.png Binary file Symbian3/SDK/Source/GUID-B16E3A7D-FF14-559A-BF86-2A1A1A584CDC_d0e341463_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B16E3A7D-FF14-559A-BF86-2A1A1A584CDC_d0e347929_href.png Binary file Symbian3/SDK/Source/GUID-B16E3A7D-FF14-559A-BF86-2A1A1A584CDC_d0e347929_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B172B71E-10DE-5AC6-9F10-A7EC74CE0B7F_d0e363629_href.png Binary file Symbian3/SDK/Source/GUID-B172B71E-10DE-5AC6-9F10-A7EC74CE0B7F_d0e363629_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B172B71E-10DE-5AC6-9F10-A7EC74CE0B7F_d0e382778_href.png Binary file Symbian3/SDK/Source/GUID-B172B71E-10DE-5AC6-9F10-A7EC74CE0B7F_d0e382778_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B1800856-3516-5D22-B1C5-556866CDDF46.dita --- a/Symbian3/SDK/Source/GUID-B1800856-3516-5D22-B1C5-556866CDDF46.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,83 +0,0 @@ - - - - - -bldmake -command syntax -

    The bldmake tool processes the component description -file (bld.inf) in the current directory and generates -the batch file abld.bat and several build batch makefiles -(.make). The makefiles are used by abld to -perform the various stages of building the component.

    -

    Invocation syntax

    -

    bldmake [ options ] command [ platform ]

    -

    Details of command and options are -given in the following tables:

    -

    Command

    - - - - -Command -Description - - - - -

    bldfiles

    -

    Creates abld and the project makefiles.

    -     - -

    clean

    -

    Removes all files created by bldmake.

    -     - -

    inf

    -

    Displays basic bld.inf syntax.

    -     - -

    plat

    -

    Displays a list of the supported platforms, and the macros defined -for each for the preprocessing of prj_mmpfiles and prj_testmmpfiles sections -of bld.inf files.

    If a platform name is given, just the macros for -that platform are displayed: for example, bldmake plat thumb.

    -     - - -
    -

    Options

    - - - - -Options -Description - - - - -

    -v

    -

    Instructs bldmake to print progress messages.

    Only -error messages are printed by default.

    -     - -

    -k or -keepgoing

    -

    Instructs bldmake to continue with the process -even if the files specified in bld.inf -file are missing.

    -     - - -
    -

    Platform

    -

    Defines the target for which to create the makefiles. If not specified, -all the default targets are assumed.

    -

    For v9.1, the default targets are WINSCW, GCCXML, ARMV5, and CW_IDE.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B1C79738-0449-5C26-BA8A-4612C6BF652F.dita --- a/Symbian3/SDK/Source/GUID-B1C79738-0449-5C26-BA8A-4612C6BF652F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -prj_testexports

    prj_testexports

    source_file_1 [destination_file]

    source_file_n [destination_file]

    In the prj_testexports section, list the files to be copied from the source directories to the releasables’ directories for use with test programs.

    Specify each file on a separate line.

    Note that:

    • If the source file is listed with a relative path, the path will be considered relative to the directory containing the bld.inf file.

    • If a destination file is not specified, the source file will be copied to the directory containing the bld.inf file.

    • If a relative path is specified with the destination file, the path will be considered relative to directory containing the bld.inf file.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B1CB6374-2C2B-5D6C-9A7C-6E49D8F235B8.dita --- a/Symbian3/SDK/Source/GUID-B1CB6374-2C2B-5D6C-9A7C-6E49D8F235B8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B1CB6374-2C2B-5D6C-9A7C-6E49D8F235B8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -58,7 +58,7 @@ enabling display change event notifications (EEventDisplayChanged). The following diagram shows the class hierarchy.

    Display control class diagram - +

    Once you have obtained the MDisplayControl interface, you can call GetResolutions() on it. For example:

    // Get available resolutions @@ -167,7 +167,7 @@ so that the virtual keyboard can be drawn within the full UI area but outside of the application's extent.

    Display mapping class diagram - +

    The MDisplayMapping interface is very flexible. UIDs are used to signify the application UI coordinate space, the full UI space, the composition/display coordinate space (which may be a different @@ -182,7 +182,7 @@ rectangle represents the display area and the inner one represents the application space (screen mode).

    Display area and application extent - +

    The display resolution is 1280 x 720, the application size is 176 x 208 and a virtual resolution of 426 x 240 has been introduced, which gives a scaling factor of three in each direction. All pixels are approximately diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B1D63E7B-81EB-5F75-96C3-789E5C3E4C03.dita --- a/Symbian3/SDK/Source/GUID-B1D63E7B-81EB-5F75-96C3-789E5C3E4C03.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B1D63E7B-81EB-5F75-96C3-789E5C3E4C03.dita Tue Jul 20 12:00:49 2010 +0100 @@ -207,7 +207,7 @@ the text as shown:

    -<image href="GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e214249_href.png" placement="inline"/> +<image href="GUID-03AC137D-173A-558C-A2F3-9522870AC43C_d0e219247_href.png" placement="inline"/> </fig> <p>The following code destroys the list elements and the <codeph>CXy</codeph> object containing the list header and iterator:</p> diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B21141D4-3BFE-59C9-8D5F-147A93BE1C95.dita --- a/Symbian3/SDK/Source/GUID-B21141D4-3BFE-59C9-8D5F-147A93BE1C95.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> -<!-- This component and the accompanying materials are made available under the terms of the License -"Eclipse Public License v1.0" which accompanies this distribution, -and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> -<!-- Initial Contributors: - Nokia Corporation - initial contribution. -Contributors: ---> -<!DOCTYPE concept - PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept id="GUID-B21141D4-3BFE-59C9-8D5F-147A93BE1C95" xml:lang="en"><title>Build tools guide \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B21A4858-162A-50F1-8F88-4259B7F7238E_d0e113666_href.png Binary file Symbian3/SDK/Source/GUID-B21A4858-162A-50F1-8F88-4259B7F7238E_d0e113666_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B21A4858-162A-50F1-8F88-4259B7F7238E_d0e113898_href.png Binary file Symbian3/SDK/Source/GUID-B21A4858-162A-50F1-8F88-4259B7F7238E_d0e113898_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2523978-4262-4E32-B50D-4818AC561B6D_d0e63770_href.png Binary file Symbian3/SDK/Source/GUID-B2523978-4262-4E32-B50D-4818AC561B6D_d0e63770_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2523978-4262-4E32-B50D-4818AC561B6D_d0e63913_href.png Binary file Symbian3/SDK/Source/GUID-B2523978-4262-4E32-B50D-4818AC561B6D_d0e63913_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B26A4743-F331-5AC3-A40A-28B14B785857.dita --- a/Symbian3/SDK/Source/GUID-B26A4743-F331-5AC3-A40A-28B14B785857.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B26A4743-F331-5AC3-A40A-28B14B785857.dita Tue Jul 20 12:00:49 2010 +0100 @@ -91,8 +91,7 @@ use the command line, open a command prompt, and set the current directory to the source code directory of the example. You can then build the example with the SBSv1 build tools with the following commands:

    bldmake bldfiles

    abld -build

    How to use bldmake and How to -use abld describe how to use the SBSv1 build tools.

    +build

  • For the emulator, the example builds an executable called searchsortexample.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

    • @@ -100,7 +99,7 @@
    Running the example

    searchsortexample.exe takes user input from the console. The menu for the current example is as shown below:

    - +

    The user input is handled by CKeyReader::RunL().

    For simple and combined non-iterative search-sort, the user provides the following inputs: 1) the text in the "To" field to search for, 2) whether case sensitivity is on of off, 3) whether diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2B34DFF-6EBE-424A-9480-C9F1CB6E2D56_d0e4623_href.png Binary file Symbian3/SDK/Source/GUID-B2B34DFF-6EBE-424A-9480-C9F1CB6E2D56_d0e4623_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2B34DFF-6EBE-424A-9480-C9F1CB6E2D56_d0e4750_href.png Binary file Symbian3/SDK/Source/GUID-B2B34DFF-6EBE-424A-9480-C9F1CB6E2D56_d0e4750_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2D72405-590C-5AC5-9435-69D22528435D.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-B2D72405-590C-5AC5-9435-69D22528435D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,13 @@ + + + + + +ConceptsThis section describes the architecture and interface of the Secure +Sockets. \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2E63B13-7B72-5CBF-ACD0-1F2D2E1EEF19_d0e185390_href.png Binary file Symbian3/SDK/Source/GUID-B2E63B13-7B72-5CBF-ACD0-1F2D2E1EEF19_d0e185390_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B2E63B13-7B72-5CBF-ACD0-1F2D2E1EEF19_d0e190387_href.png Binary file Symbian3/SDK/Source/GUID-B2E63B13-7B72-5CBF-ACD0-1F2D2E1EEF19_d0e190387_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B3166752-9B99-5669-8AB4-078164144AA1_d0e176531_href.png Binary file Symbian3/SDK/Source/GUID-B3166752-9B99-5669-8AB4-078164144AA1_d0e176531_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B3166752-9B99-5669-8AB4-078164144AA1_d0e181556_href.png Binary file Symbian3/SDK/Source/GUID-B3166752-9B99-5669-8AB4-078164144AA1_d0e181556_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B32ED85A-913E-5C06-AEEB-1E2D6EF4CECF.dita --- a/Symbian3/SDK/Source/GUID-B32ED85A-913E-5C06-AEEB-1E2D6EF4CECF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B32ED85A-913E-5C06-AEEB-1E2D6EF4CECF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Drawing a Rounded Rectangle

    This topic provides an example that demonstrates how to draw a rounded rectangle using DrawRoundRect(). The dimensions of each corner (corner size and corner height) are given by a TSize argument.

    Rounded rectangle construction - ... + ... // draw a rectangle with rounded corners, centered in the rectangle TSize cornerSize(20,20); // set up the size of a rounded cornerSize gc.DrawRoundRect(box,cornerSize); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B3760707-2810-4CD9-82C7-6A40DE638D36.dita --- a/Symbian3/SDK/Source/GUID-B3760707-2810-4CD9-82C7-6A40DE638D36.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B3760707-2810-4CD9-82C7-6A40DE638D36.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,6 +18,6 @@ opened.

    Submenu indicators: radio buttons - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B409C23A-F89E-5D30-B172-1F39C3F6A57F_d0e49332_href.png Binary file Symbian3/SDK/Source/GUID-B409C23A-F89E-5D30-B172-1F39C3F6A57F_d0e49332_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B409C23A-F89E-5D30-B172-1F39C3F6A57F_d0e49490_href.png Binary file Symbian3/SDK/Source/GUID-B409C23A-F89E-5D30-B172-1F39C3F6A57F_d0e49490_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B452DBD8-F9EB-4DAB-9D0C-3B11D7C360F4.dita --- a/Symbian3/SDK/Source/GUID-B452DBD8-F9EB-4DAB-9D0C-3B11D7C360F4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B452DBD8-F9EB-4DAB-9D0C-3B11D7C360F4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,9 +16,9 @@ indicator is placed above the text setting field top right corner.

    Text setting pop-up - + -Default +<table id="GUID-4F77253E-5688-4642-98DD-04CB7FCF38E1-GENID-1-10-1-7-1-1-5-1-15-1-4-1-2-3"><title>Default touch events when editing text in a text setting pop-up diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B459E37A-BECE-5087-9827-C93310890674_d0e281229_href.png Binary file Symbian3/SDK/Source/GUID-B459E37A-BECE-5087-9827-C93310890674_d0e281229_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B459E37A-BECE-5087-9827-C93310890674_d0e286068_href.png Binary file Symbian3/SDK/Source/GUID-B459E37A-BECE-5087-9827-C93310890674_d0e286068_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B46C54AD-268C-58A0-B244-134C4D8BDFE1_d0e19466_href.png Binary file Symbian3/SDK/Source/GUID-B46C54AD-268C-58A0-B244-134C4D8BDFE1_d0e19466_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B46C54AD-268C-58A0-B244-134C4D8BDFE1_d0e19648_href.png Binary file Symbian3/SDK/Source/GUID-B46C54AD-268C-58A0-B244-134C4D8BDFE1_d0e19648_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B4834A49-587E-41AD-B0D3-0622B173B2AD_d0e75375_href.png Binary file Symbian3/SDK/Source/GUID-B4834A49-587E-41AD-B0D3-0622B173B2AD_d0e75375_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B4834A49-587E-41AD-B0D3-0622B173B2AD_d0e75413_href.png Binary file Symbian3/SDK/Source/GUID-B4834A49-587E-41AD-B0D3-0622B173B2AD_d0e75413_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B48F7684-76E6-51C1-B85A-08A1F1EBD807_d0e80459_href.png Binary file Symbian3/SDK/Source/GUID-B48F7684-76E6-51C1-B85A-08A1F1EBD807_d0e80459_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B48F7684-76E6-51C1-B85A-08A1F1EBD807_d0e80517_href.png Binary file Symbian3/SDK/Source/GUID-B48F7684-76E6-51C1-B85A-08A1F1EBD807_d0e80517_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B4F15CA3-CAD4-5A87-9610-A656CA337B72.dita --- a/Symbian3/SDK/Source/GUID-B4F15CA3-CAD4-5A87-9610-A656CA337B72.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B4F15CA3-CAD4-5A87-9610-A656CA337B72.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,9 +11,9 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Comms Buffers (MBuf) ans Comms ChainsThis topic describes Comms buffers (MBuf) and Comms chains.
    APIs

    The following diagram is a partial representation of the class hierarchy for RMBuf.

    Comms buffer -

    For more information about these classes, see the following table and the reference documentation:

    Class Description

    RMBuf

    Representation of a shared buffer designed to carry packets within the Comms Data Plane.

    It includes Comms metadata (such as the offset, the size and the type of the data within the buffer) and links to the next buffer in the buffer chain.

    Part of the API is located in the parent class : RCommsBuf.

    RMBufChain

    Chain of RMBuf objects.

    Part of the API is located in the parent class : RCommsBufChain.

    Buffer layout

    The following diagram shows the contents of a Comms buffer and the location of the metadata. The metadata is at the end so that the device drivers can ignore the metadata and write their payload at the beginning of the buffer.

    +

    For more information about these classes, see the following table and the reference documentation:

    Class Description

    RMBuf

    Representation of a shared buffer designed to carry packets within the Comms Data Plane.

    It includes Comms metadata (such as the offset, the size and the type of the data within the buffer) and links to the next buffer in the buffer chain.

    Part of the API is located in the parent class : RCommsBuf.

    RMBufChain

    Chain of RMBuf objects.

    Part of the API is located in the parent class : RCommsBufChain.

    Buffer layout

    The following diagram shows the contents of a Comms buffer and the location of the metadata. The metadata is at the end so that the device drivers can ignore the metadata and write their payload at the beginning of the buffer.

    Comms buffer contents -

    The metadata contains information about the payload: its length and offset, the type of data it contains, and references to the pond and the pool where the buffer's memory is located. Whenever you perform an operation on an MBuf, the chain or the pond update the metadata.

    The offset at the beginning of the buffer is an important optimisation when sending data downwards through the Comms Data Plane. Leaving enough space for the protocol headers enables Comms Framework components to prepend their data to the payload without requesting a new MBuf and its addition to the front of the buffer chain. Therefore, you should always define a pool according to the biggest packet that the bottom of the stack may receive : for example, 1518 bytes for Ethernet packets.

    The following diagram is an example illustrating how the Comms Data Plane removes the headers from the payload (on the way up the stack) or prepend header to the payload (on the way down):

    +

    The metadata contains information about the payload: its length and offset, the type of data it contains, and references to the pond and the pool where the buffer's memory is located. Whenever you perform an operation on an MBuf, the chain or the pond update the metadata.

    The offset at the beginning of the buffer is an important optimisation when sending data downwards through the Comms Data Plane. Leaving enough space for the protocol headers enables Comms Framework components to prepend their data to the payload without requesting a new MBuf and its addition to the front of the buffer chain. Therefore, you should always define a pool according to the biggest packet that the bottom of the stack may receive : for example, 1518 bytes for Ethernet packets.

    The following diagram is an example illustrating how the Comms Data Plane removes the headers from the payload (on the way up the stack) or prepend header to the payload (on the way down):

    Header manipulation example -

    For simplified code corresponding to this diagram, see Data Access Example.

    Overview Shared Buffers Advanced Pond +

    For simplified code corresponding to this diagram, see Data Access Example.

    Overview Shared Buffers Advanced Pond Guide \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B51A9A1F-8E80-4DF6-904A-7BD1A8976BBB.dita --- a/Symbian3/SDK/Source/GUID-B51A9A1F-8E80-4DF6-904A-7BD1A8976BBB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B51A9A1F-8E80-4DF6-904A-7BD1A8976BBB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,8 +30,9 @@ programs

    Symbian C++ Quick Start

    Going Beyond Hello: A Tutorial for Symbian C++ Applications

    The Application Layer provides application user interfaces -and application engines.

    Messaging Applications

    PIM

    The Middleware Layer provides application services, -including UI frameworks and high level communications.

    Application Installation

    Browsing and downloading

    Classic UI

    Generic Application +and application engines.

    Contacts

    Messaging +Applications

    Organizer

    The Middleware Layer provides application services, including +UI frameworks and high level communications.

    Application Installation

    Browsing and downloading

    Classic UI

    Generic Application Support

    Messaging Middleware

    Multimedia Protocols

     @@ -70,8 +71,7 @@

    These documents help you write better and safer programs.

    Security

    These links take you to full lists of packages and tools described in the library.

    Symbian Guide

    API -Specifications

    Reference

    Tools and -Utilities

     +Specifications

    Reference

    Tools and Utilities

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B51EA0DA-5BCE-4A8C-A7A7-1FE096F7FF27.dita --- a/Symbian3/SDK/Source/GUID-B51EA0DA-5BCE-4A8C-A7A7-1FE096F7FF27.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B51EA0DA-5BCE-4A8C-A7A7-1FE096F7FF27.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,73 +1,65 @@ - - - - - -Compilation -and Build Process on Symbian PlatformThis article discusses a few basic things about the compilation -and build process in Symbian platform. -

    The bldmake tool processes the component description file bld.inf in -the current directory and generates the batch file abld.bat and -several build batch makefiles (.make) -. The makefiles are used by abld to carry -out the various stages of building the component.

    -

    The basic usage of abld command is:

    -abld command[options][platform][build][program] -

    This enables the programmer to build for different platforms with varied -specifications. The parameter command specifies which action to perform to -the abld tool. The actions can be build, clean, cleanexport and -so on. The parameter options includes –c, -w and -so on, these enable the user to check for the presence of releasables. The -parameter platform specifies the platform for which the project will be built. -The platform can be WINSCW, GCCE, GCCXML, EDG, ARMV5, VS6, CW_IDE or VS2003. The parameter -build specifies whether to build for debug (udeb) or release -(urel) version. Finally the parameter program specifies which -project definition file or mmp file to build. If left unspecified, all the -MMP files mentioned in the bld.inf file are built. For -more information, see Build -tools reference.

    -

    The example below demonstrates the use of bldmake:

    -bldmake bldfiles -

    The abld build command compiles and links the target.

    -abld build -

    The abld freeze command freezes the project export. -This is needed only for DLLs.

    -abld freeze -
    Creating -PKG file and Installation file for the target

    A package (PKG) file -is a text file containing items or statements that define the information -required by the installation (SIS) file creation utility makesis. -The PKG file format can be broken down into the following items:

      -

    • Languages

      • -

    • Language code table

      • -

    • Package-header

      • -

    • Vendor

      • -

    • Logo

      • -

    • Package-signature

      • -

    • Package-body

      • -

    • Dependency

      • -

    • Properties

      • -

    For more information on PKG files, see PKG -File Format.

    The makesis utility creates software -installation packages (SIS files) based on the information and the file locations -on the source PC or target phone, defined in a package (PKG) file.

    For -example, consider the code snippet given below:

    makesis somefile.pkg

    The -code goes through the PKG file and by default creates somefile.sis in the -directory where the PKG file is present.

    For more information on the makesis utility, -see MakeSIS.

    After -creating the SIS file it, has to be signed using signsis to -install it on the phone. signsis is a Symbian supplied -tool to digitally sign software installation (SIS) files using a specified -certificate and private key. For example consider the code snippet given below:

    signsis somefile.sis somefile.sisx rd.cer rd-key.pem

    The parameter somefile.sis gives, the path to the -SIS file which is to be signed. The second parameter, somefile.sisx specifies -the name of the resultant signed SIS file. The third parameter, rd.cer specifies -the path to the certificate file and the last parameter, rd-key.pem specifies -the path to the file containing the private key.

    For more information -on signsis, see SignSIS.

    + + + + + +Compilation and Build Process on Symbian PlatformThis article discusses a few basic things about the compilation +and build process in Symbian platform. +

    The bldmake tool processes the component description +file bld.inf in the current directory and generates +the batch file abld.bat and several build batch makefiles (.make) . The makefiles are used by abld to carry out the various stages +of building the component.

    +

    The basic usage of abld command is:

    +abld command[options][platform][build][program] +

    This enables the programmer to build for different platforms with +varied specifications. The parameter command specifies which action +to perform to the abld tool. The actions can be build, +clean, cleanexport and so on. The parameter options +includes –c, -w and so on, these +enable the user to check for the presence of releasables. The parameter +platform specifies the platform for which the project will be built. +The platform can be WINSCW, GCCE, GCCXML, EDG, ARMV5, VS6, CW_IDE or VS2003. The parameter build specifies whether to build for debug (udeb) or release (urel) version. Finally +the parameter program specifies which project definition file or mmp +file to build. If left unspecified, all the MMP files mentioned in +the bld.inf file are built. For more information, +see Symbian^3 Tools Guide > Building.

    +

    The example below demonstrates the use of bldmake:

    +bldmake bldfiles +

    The abld build command compiles and links the +target.

    +abld build +

    The abld freeze command freezes the project +export. This is needed only for DLLs.

    +abld freeze +
    Creating PKG file and Installation file for the target

    A package (PKG) file is a text file containing items or statements +that define the information required by the installation (SIS) file +creation utility makesis. The PKG file format can +be broken down into the following items:

      +

    • Languages

      • +

    • Language code table

      • +

    • Package-header

      • +

    • Vendor

      • +

    • Logo

      • +

    • Package-signature

      • +

    • Package-body

      • +

    • Dependency

      • +

    • Properties

      • +

    For more information on PKG files, see PKG File Format.

    The makesis utility creates software installation +packages (SIS files) based on the information and the file locations +on the source PC or target phone, defined in a package (PKG) file.

    For example, consider the code snippet given below:

    makesis somefile.pkg

    The code goes through the PKG +file and by default creates somefile.sis in the directory where the +PKG file is present.

    For more information on the makesis utility, see MakeSIS.

    After creating the SIS file it, has to be signed +using signsis to install it on the phone. signsis is a Symbian supplied tool to digitally sign software +installation (SIS) files using a specified certificate and private +key. For example consider the code snippet given below:

    signsis somefile.sis somefile.sisx rd.cer rd-key.pem

    The parameter somefile.sis gives, the path to +the SIS file which is to be signed. The second parameter, somefile.sisx specifies the name of the resultant signed +SIS file. The third parameter, rd.cer specifies +the path to the certificate file and the last parameter, rd-key.pem specifies the path to the file containing the +private key.

    For more information on signsis, see SignSIS.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B541BD01-29BE-4CB7-9420-ABEE0BDC9BA4.dita --- a/Symbian3/SDK/Source/GUID-B541BD01-29BE-4CB7-9420-ABEE0BDC9BA4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B541BD01-29BE-4CB7-9420-ABEE0BDC9BA4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,8 +14,8 @@ resource file must be the same as that of the executable with .rss extension. All the registration resource structure types are defined in RegistryInfo.rh. This file has to be included in the registration resource file. - -Define a single REGISTRY_INFO resource. + +Define a single REGISTRY_INFO resource. Set the dll_uid diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B5576E47-CBB6-5E50-91BD-1CA1425EACE8.dita --- a/Symbian3/SDK/Source/GUID-B5576E47-CBB6-5E50-91BD-1CA1425EACE8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -Microsoft Visual Studio support

    The Microsoft Visual Studio IDE can be used to compile and debug applications built for Symbian OS v9.2 and above. The two versions of Visual Studio supported are:

    • Visual Studio 6

    • Visual Studio .NET 2003

    In summary, the steps for using Visual Studio are:

    • Make sure that your program has a bld.inf file and a mmp project file.

    • Use the Symbian platform bldmake and abld command to create a Visual Studio project file from the mmp file.

    • Open the created Visual Studio project file in the IDE, and build, run, and debug the program from there.

    The underlying compiler used for the Visual Studio support is the Nokia x86 standalone compiler, version 3.2.3. This compiler is provided on Symbian platform kits in the epoc32 tree under epoc32/tools/nokia_compiler/. Note that the C++ compiler supplied with Microsoft Visual Studio itself is not used.

    The Visual Studio support uses the operating system binaries that are created for the winscw platform. Support is provided by the introduction of two build targets, called vs6 and vs2003.

    Microsoft Visual C++ 6

    To use Visual C++ 6:

    1. Start a command line prompt

    2. Run the Visual Studio environment configuration batch file, vsvars32.bat, which is part of your Visual Studio installation. This ensures that the necessary Visual Studio environment variables are set up.

    3. Change directory to the directory that contains your program's bld.inf file, and use the following commands:

      bldmake bldfiles

      abld makefile vs6 [project-name]

      The vs6 argument here specifies to the tools that Visual C++ 6 project files should be produced. The project name is optional. If it is not mentioned, Visual Studio project files are created for all projects specified in the bld.inf file.

    These commands creates a Visual C++ workspace (.dsw) file generated under the kit's epoc32\build\<SOURCE_PATH>\<PROJECT_NAME>\WINSCW directory. For example, if the kit is installed in \Symbian\9.2\, and the project is helloworld, then the .dsw file is created in the directory \Symbian\9.2\epoc32\build\src\helloworld\helloworld\winscw.

    The workspace can then be opened in the IDE, and the project built and debugged from there.

    To both build the project and create the workspace, use the commands:

    bldmake bldfiles

    abld build vs6 [udeb | urel] [project-name]

    The vs6 platform can optionally be added to the prj_platforms section in the bld.inf file. If this is done, abld commands will use the vs6 target without it being explicity specified.

    Microsoft Visual Studio .NET2003

    To use Visual Studio .NET2003:

    1. Start a command line prompt

    2. Run the Visual Studio environment configuration batch file, vsvars32.bat, which is part of your Visual Studio installation. This ensures that the necessary Visual Studio environment variables are set up.

    3. Change directory to the directory that contains your program's bld.inf file, and use the following commands:

      bldmake bldfiles

      abld makefile vs2003 [project-name]

      The vs2003 argument here specifies to the tools that Visual Studio .NET2003 files should be produced. The project name is optional. If it is not mentioned, Visual Studio files are created for all projects specified in the bld.inf file.

    These commands create a Visual Studio solution file (.sln) file generated under the kit's epoc32\build\<SOURCE_PATH>\<PROJECT_NAME>\WINSCW directory. For example, if the kit is installed in \Symbian\9.2\, and the project is helloworld, then the .sln file is created in the directory \Symbian\9.2\epoc32\build\src\helloworld\helloworld\winscw.

    The solution file can then be opened in the IDE, and the project built and debugged from there.

    To both build the project and create the workspace, use the commands:

    bldmake bldfiles

    abld build vs2003 [udeb | urel] [project-name]

    The vs2003 platform can optionally be added to the prj_platforms section in the bld.inf file. If this is done, abld commands will use the vs2003 target without it being explictly specified.

    Limitations

    1. If you add a source file into the project directly from Visual Studio, the source file is not included in the build process. You must add the source file to the mmp project file, and then repeat the abld makefile step to recreate the workspace.

    2. There is no Edit-And-Continue support on the makefile project when debugging. This means that if you edit a file while debugging, you will have to exit the debugging session, rebuild the project, and then restart debugging session.

    3. If the project produces an EXE, and that EXE already exists, then when the debugger is started, Visual Studio doesn't call Make to check if all targets are up-to-date, but directly starts the program. So, to ensure that all targets are up-to-date during a debug session, a build should be done first before using the debugger.

    4. In .NET2003, a problem sometimes seen is that the Build - Solution command doesn't build the projects included in that solution, while the Build <project name> command builds correctly. This occurs when the Visual Studio program uuidgen.exe is not available in the path. Executing vsvars32.bat usually sets up the appropriate path.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B563AC07-A54B-50E2-A3B2-821E8BC2C863.dita --- a/Symbian3/SDK/Source/GUID-B563AC07-A54B-50E2-A3B2-821E8BC2C863.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B563AC07-A54B-50E2-A3B2-821E8BC2C863.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@ CDirScanThis topic describes about setting up the scan and parsing path.
    Setting up the scan using SetScanDataL() - +

    Taking the above directory structure, if SetScanData() is called as follows:

    _LIT(KDirText,"C:\\TopDir\\"); ... diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B574CC84-342C-4613-A628-B32B7876D595_d0e4720_href.png Binary file Symbian3/SDK/Source/GUID-B574CC84-342C-4613-A628-B32B7876D595_d0e4720_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B574CC84-342C-4613-A628-B32B7876D595_d0e4846_href.png Binary file Symbian3/SDK/Source/GUID-B574CC84-342C-4613-A628-B32B7876D595_d0e4846_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B58D3727-6E05-51C8-8EC2-52768A136BD5.dita --- a/Symbian3/SDK/Source/GUID-B58D3727-6E05-51C8-8EC2-52768A136BD5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B58D3727-6E05-51C8-8EC2-52768A136BD5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@
    Window server event types

    The Window Server generates events of three different classes, as shown in the following diagram.

    Window server event types - + diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B58D93D7-597C-5200-82ED-F434B297CAC9.dita --- a/Symbian3/SDK/Source/GUID-B58D93D7-597C-5200-82ED-F434B297CAC9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -strictdepend

    strictdepend

    If your project’s dependencies may differ with the variant, use the strictdepend statement.

    Without this statement, dependencies will be evaluated for one variant, and then used for all.

    With strictdepend, dependencies are evaluated explicitly—a sometimes lengthy process—for each variant.

    Use strictdepend if, for instance, you conditionally include a header file, e.g.

    #if defined(_DEBUG) -include <debug.h> -#endif     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B5DE1C86-2B16-4B22-887F-7079E54A8ED6.dita --- a/Symbian3/SDK/Source/GUID-B5DE1C86-2B16-4B22-887F-7079E54A8ED6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B5DE1C86-2B16-4B22-887F-7079E54A8ED6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@ Symbian UI application architecture

    The following image illustrates the components of the traditional architecture approach.

    -Traditional Symbian UI application architecture classes +Traditional Symbian UI application architecture classes

    Symbian platform applications that follow the traditional Symbian UI application architecture require:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B6088C0A-20AE-5108-A28C-9CA884205493.dita --- a/Symbian3/SDK/Source/GUID-B6088C0A-20AE-5108-A28C-9CA884205493.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,31 +0,0 @@ - - - - - -Resource initialisation punctuation

      A semicolon must follow all member initialisations. For longer, more complicated resources deciding where semicolons must be placed may become confusing. As shown in the following example, array lists are separated by commas and terminated without a semi-colon. Similarly, resources are not terminated by a semi-colon.

      RESOURCE DIALOG example_dialog - { - title="Example"; - topsection=DLAY_SECTION - { - control_list= - { - ACLIST - { - butlist_flags=BUTLIST_HORIZONTAL; - rid=R_HCIL_BUTTONS_OK_CANCEL; - }, // array member so comma needed - ACLIST - { - butlist_flags=BUTLIST_HORIZONTAL; - rid=R_HCIL_BUTTONS_OK_CANCEL; - } // last item in array so nothing needed - }; // end of struct member control_list so ‘;’ needed - }; // end of struct member topsection so ‘;’ needed - } // end of resource so nothing needed

      The rules to remember are as follows:

    Type of entity

    Punctuation needed after closing }

    resource

    nothing

    array member (not last one)

    ,

    last array member

    nothing

    struct member

    ;
    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B683496C-652E-5F48-924E-52D2FF3A78A7.dita --- a/Symbian3/SDK/Source/GUID-B683496C-652E-5F48-924E-52D2FF3A78A7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B683496C-652E-5F48-924E-52D2FF3A78A7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -55,7 +55,7 @@ the root stream.

    Streams linked in a store - +

    Direct file stores are encapsulated by the CDirectFileStore class.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B68FF699-923B-530E-A877-86507B1D42F1.dita --- a/Symbian3/SDK/Source/GUID-B68FF699-923B-530E-A877-86507B1D42F1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,37 +0,0 @@ - - - - - -mmp file syntax overview

    A .mmp project definition file specifies the properties of a project in a platform and compiler independent way. The makmake tool converts project definition files into makefiles for particular platforms. The abld tool wraps calls to makmake, and can be more convenient to use than makmake directly.

    A project definition file has extension .mmp.

    Note that:

    • Each statement occupies a single line.

    • Use the C++ style comment syntax for comments.

    • A trailing backslash is used to indicate a line continuation. Therefore, specify directories without their trailing backslash, for example: Do SYSTEMINCLUDE \epoc32\include, rather than SYSTEMINCLUDE - \epoc32\include\

    Example:

    An example of an .mmp file called hello.mmp:

    TARGET HelloWorld.exe -TARGETTYPE exe -UID 0x100039CE 0x10004299 -TARGETPATH \sys\bin -VENDORID 0x70000001 -SOURCEPATH . -SOURCE HelloWorld_Main.cpp -SOURCE HelloWorld_Application.cpp -SOURCE HelloWorld_Document.cpp -SOURCE HelloWorld_AppUi.cpp -SOURCE HelloWorld_AppView.cpp -USERINCLUDE . -SYSTEMINCLUDE \epoc32\include - -START RESOURCE HelloWorld.rss -HEADER -TARGETPATH \resource\apps -end - -START RESOURCE HelloWorld_reg.rss -TARGETPATH \private\10003a3f\apps -END - -LIBRARY euser.lib apparc.lib cone.lib eikcore.lib -
    See also

    Using makmake

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B6B54E07-3B34-5D5C-8815-93383FA8FB4B.dita --- a/Symbian3/SDK/Source/GUID-B6B54E07-3B34-5D5C-8815-93383FA8FB4B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,41 +0,0 @@ - - - - - -How -to use abld -

    The abld.bat batch file is used to control all aspects -of building a project. It is created in the current directory by the bldmake tool -from a component description file bld.inf.

    -

    The syntax reference for this tool exhaustively lists all of the possible -build operations which can be performed using abld. The -tool's flexibility obscures the fact that most Symbian developers will only -need to use two commands: one for cleaning up all files created in a previous -build, and another for building the current project.

    -
    Cleaning

    Cleaning removes all the intermediate -files created during compilation, and all the executables and import libraries -created by the linker. The simplest invocation of this operation deletes the -files for all platforms, and projects belonging to the component.

    abld -clean

    It is also possible to specify the platform and -build variant to be cleaned.

    -
    Building

    abld builds projects -based on the makefiles created by bldmake from the component -information file and project files.

    The simplest invocation of this -command builds the project for all possible build variants:

    abld -build

    However building for a platform can take some time, -and it is usual to only specify the platform required. For example, to build -the debug version on the WINSCW platform specify:

    abld -build winscw udeb

    or to build the release version for -ARMV5 use:

    abld build armv5 urel

    The build command -combines the other abld commands: export, makefile, library, resource, target and final, which are carried out -in turn.

    See also

    Abld -syntax

    Using -bldmake

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B707887A-E0FA-5DF6-A906-A91E31E17321.dita --- a/Symbian3/SDK/Source/GUID-B707887A-E0FA-5DF6-A906-A91E31E17321.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -start bitmap

    start bitmap target-file

    [targetpath targetpath]

    [header]

    [sourcepath sourcepath]

    source color-depth source-bitmap-list

    end

    A start bitmap section specifies how to compile bitmap (.bmp) files into a Symbian platform format multi-bitmap (.mbm) file.

    The target-file to be produced should be given with its extension, e.g. squash.mbm.

    If a target path is specified, that path will be interpreted as a location on the emulated z: drive; otherwise, the target file will be built into the same directory as the application.

    If the header keyword is supplied in the section, a bitmap header will be generated in directory epoc32\include, e.g. squash.mbg.

    Multiple sourcepath and source statements can be specified. Source bitmaps specified with each source statement will be expected to exist in the directory specified with the latest sourcepath statement above it.

    Just a single colour-depth must be specified for all the source bitmaps within a single source statement, and must be of the form [c]digit,digit, where the optional c denotes whether the bitmap is a colour bitmap and the digits represent the colour-depth of the bitmap and the bitmap mask respectively. It is recommended that the mask has a colour depth of 1 bit per pixel, to minimise memory usage.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B71AC5E3-8AA8-55AD-916F-9E873926011B.dita --- a/Symbian3/SDK/Source/GUID-B71AC5E3-8AA8-55AD-916F-9E873926011B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B71AC5E3-8AA8-55AD-916F-9E873926011B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ relationship between the components is :

    Architecture of the feature management system - +

    Feature Manager Client is not supplied with all versions of Symbian Platform. Feature Discovery, which is always supplied, provides a subset of the functionality of Feature Manager Client and offers superior performance diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7482AEB-9E7E-5F9C-A69D-60E1FE82CCE1.dita --- a/Symbian3/SDK/Source/GUID-B7482AEB-9E7E-5F9C-A69D-60E1FE82CCE1.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B7482AEB-9E7E-5F9C-A69D-60E1FE82CCE1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,212 +1,185 @@ - - - - - -dynamicarray: -Using Dynamic ArraysThis example application demonstrates how to construct and use -dynamic arrays. -

    The example includes both simple dynamic arrays and extended dynamic arrays. -You are likely to use simple dynamic arrays often. Extended dynamic arrays -are combinations of element properties and storage types.

    -

    The example implements the following operations for the RArray and RPointerArray classes:

    -
      -

    • Appends elements

      • -

    • Inserts elements

      • -

    • Accesses elements

      • -

    • Removes elements

      • -

    • Finds elements (in various -ways)

      • -

    • Sorts array

      • -

    • Destroys the array

      • -
    -
    Download

    Click -on the following link to download the example: DynamicArrays.zip

    Download some additional files -required by the example: CommonFramework.zip

    View the source code: browse . View the additional files:browse.

    -
    Description

    This -example demonstrates how to construct and use the following types of dynamic -arrays:

    CArrayFixFlat

    This example uses the CArrayFixFlat array -class to create an array of objects. These objects are of fixed length and -are stored in a flat buffer.

    The following operations are performed -on this array:

      -

    • Append elements: The -example uses the CArrayFix::AppendL() function to append -objects to the array.

      • -

    • Insert elements: The -example uses the CArrayFix::InsertL() function to insert -objects into the array at the specified position.

      • -

    • Remove elements: The -example uses the CArrayFixBase::Delete() function to delete -objects from the array.

      • -

    • Sort elements: The -example defines an array key to sort the array using the TKeyArrayFix class. -The CArrayFixBase::Sort() function is used to sort the -array using this array key.

      • -

    • Swap two elements: The -example implements the TSwap::Swap() function through the CMySwap class. -The CMySwap::Swap() function is used to swap two elements -of the array.

      • -

    • Find an element: The -example implements the TKeyElementFix class. This class is -a TKey derived class. It overrides the TKey::At() function. -The TKeyElementFix::At() function gets a pointer to the key -of a specified array element. This function is used by the CArrayFixFlat::Find() function -to find an element in the array.

      • -

    CArrayPtrFlat

    This example uses the CArrayPtrFlat array -class to create an array of pointers to CBase derived objects.

    The -following operations are performed on this array:

      -

    • Append elements: The -example uses the CArrayFix::AppendL() function to append -objects to the array.

      • -

    • Insert elements: The -example uses the CArrayFix::InsertL() function to insert -objects into the array at the specified position.

      • -

    • Remove elements: The -example uses the CArrayFixBase::Delete() function to delete -objects from the array.

      • -

    CArrayVarFlat

    This example uses the CArrayVarFlat array -class to create an array of objects. These objects are of different lengths. -Pointers to these elements are maintained in a flat dynamic buffer.

    The -following operations are performed on this array:

      -

    • Append elements: The -example uses the CArrayVar::AppendL() function to append -objects to the array.

      • -

    • Sort elements: The -example defines an array key to sort the array using the TKeyArrayVar class. -The CArrayVarBase::Sort() function is used to sort the -array using this array key.

      • -

    CArrayPakFlat

    This example uses the CArrayPakFlat array -class to create an array of objects. These objects are of variable lengths. -These are stored in a flat buffer. Each element is preceded by its length -information.

    The following operations are performed on this array:

      -

    • Append elements: The -example uses the CArrayPak::AppendL() function to append -objects to the array.

      • -

    • Find an element: The -example defines an array key to find an element in the array using the TKeyArrayPak class. -The CArrayPakBase::Find() function is used to find an element -in the array.

      • -

    RArray

    This example constructs a simple dynamic array -called RArray. It is an efficient array of fixed length -objects. The elements of this array are the instances of another class, so -this is specified as a template parameter T.

    This -example shows the following operations to this array:

      -

    • Append elements: The -example performs the following steps:

        -

      • Appends the objects into the array using RArray::AppendL().

        • -

      • Displays the number of objects and prints each object present in the -array.

        • -
      • -

    • Insert elements: The -example performs the following steps:

        -

      • Inserts the objects at a specified position using RArray::InsertL().

        • -

      • Passes the position of the object to the second parameter of RArray::InsertL().

        • -

      • Inserts objects in the beginning, middle, and at the end of the array.

        • -

      • Displays the number of objects and prints each object present in the -array.

        • -
      • -

    • Access elements: The -example accesses each object in the array and display into the console.

      • -

    • Remove elements: The -example removes an object at a specific position from the array using RArray::Remove().

      • -

    • Find elements: The -example performs the following steps:

        -

      • Finds the first object in the array that matches the specified object -using RArray::Find().

        • -

      • Finds the last object in the array that matches the specified object -using RArray::FindReverse().

        • -

      • Finds the object using a binary search technique in the array, which -matches the specified object using RArray::FindInSignedKeyOrder(). -It assumes that the existing objects within the array are in signed key order.

        • -

      • Finds the object using a binary search technique in the array, which -matches the specified object using RArray::FindInUnsignedKeyOrder(). -It assumes that the existing objects within the array are in unsigned key -order.

        • -

      • Finds the object using a binary search technique in the array, which -matches the specified object using RArray::SpecificFindInSignedKeyOrder(). -It passes the mode as the second parameter of this API to find the first, -last, or any match in case of multiple matches. It assumes that the existing -objects within the array are in signed key order.

        • -

      • Finds the object using a binary search technique in the array, which -matches the specified object using RArray::SpecificFindInUnsignedKeyOrder(). -It passes the mode as the second parameter of this API to find the first, -last, or any match in case of multiple matches. It assumes that the existing -objects within the array are in unsigned key order.

        • -
      • -

    • Sort elements: The -example performs the following steps:

        -

      • Constructs two arrays of 64-bit signed integer type objects.

        • -

      • Appends random objects to the first array using RArray::Append().

        • -

      • Inserts the data present in the first array to the second array.

        • -

      • Sorts the element of second array using RArray::sort().

        • -
      • -

    • Destroy the array: The -example performs the following steps:

        -

      • Destroys the array using delete operator.

        • -

      • Closes the array and removes all the memory allocated to the array -using RArray::Close().

        • -
      • -

    RPointerArray

    This example constructs a simple dynamic -array of pointers to objects called RPointerArray. It is -an efficient pointer array of fixed-length objects. The elements of this array -are the instances of another class so this is specified as a template parameter T.

    This -example shows the following operations to this array:

      -

    • Append elements: The -example performs the following steps:

        -

      • Appends the object pointers into the array using RPointerArray::AppendL().

        • -

      • Displays the number of object pointers and prints each object pointer -present in the array.

        • -

      • -

    • Insert elements: The -example performs the following steps:

        -

      • Inserts the objects pointer at a specified position using RpointerArray::InsertL().

        • -

      • Passes the position of the object pointer to the second parameter of RpointerArray::InsertL().

        • -

      • Inserts object pointer at the beginning, in the middle, and at the -end of the array.

        • -

      • Displays the number of object pointers and prints each object pointer -present in the array.

        • -
      • -

    • Access elements: The -example accesses each object pointer in the array and displays it to the console.

      • -

    • Remove elements: The -example removes an object pointer at a specific position from the array using RPointerArray::Remove().

      • -

    • Find elements: The -example performs the following steps:

        -

      • Finds the first object pointer in the array that matches the specified -object using RPointerArray::Find().

        • -

      • Finds the last object pointer in the array that matches the specified -object using RPointerArray::FindReverse().

        • -

      • Finds the object pointer in the array that matches the specified object -pointer, using RPointerArray::FindInAddressOrder(). It -assumes that object pointers in the array are in address order.

        • -
      • -

    • Sort elements: The -example performs the following steps:

        -

      • Constructs two arrays of TAny pointer objects.

        • -

      • Appends random objects to the first pointer array using RPointerArray::Append().

        • -

      • Inserts the data present in the first pointer array to the second pointer -array.

        • -

      • Sorts the element of the second pointer array using RPointerArray::sort().

        • -
      • -

    • Destroy the array: The -example performs the following steps:

        -

      • Destroys and resets the pointer array using RPointerArray::ResetAnddestroy().

        • -

      • Closes the pointer array and removes all the memory allocated to the -array using RPointerArray::Close().

        • -
      • -
    -
    Class summary

    CArrayFixFlat CArrayPtrFlat CArrayVarFlat CArrayPakFlat TSwap TKeyArrayFix TKeyArrayVar TKeyArrayPak TKey RArray TLinearOrder RPointerArray

    -
    Build

    The Symbian build process describes -how to build this example.

    For the emulator, the example builds an -executable file called DynamicArrays.exe in the standard -location (\epoc32\release\winscw\<build_variant> for -CodeWarrior) directory. After launching the executable file, depending on -the emulator you are using, you can task away from the application launcher -or shell screen to view the console.

    + + + + + +dynamicarray: Using Dynamic ArraysThis example application demonstrates how to construct +and use dynamic arrays. +

    The example includes both simple dynamic arrays and extended dynamic +arrays. You are likely to use simple dynamic arrays often. Extended +dynamic arrays are combinations of element properties and storage +types.

    +

    The example implements the following operations for the RArray and RPointerArray classes:

    +
      +

    • Appends elements

      • +

    • Inserts elements

      • +

    • Accesses elements

      • +

    • Removes elements

      • +

    • Finds elements +(in various ways)

      • +

    • Sorts array

      • +

    • Destroys the +array

      • +
    +
    Download

    Click on the following link to download the example: DynamicArrays.zip

    Download some additional +files required by the example: CommonFramework.zip

    View the source +code: browse . View the additional files:browse.

    +
    Description

    This example demonstrates how to construct and use the following +types of dynamic arrays:

    CArrayFixFlat

    This +example uses the CArrayFixFlat array class to create +an array of objects. These objects are of fixed length and are stored +in a flat buffer.

    The following operations are performed on +this array:

      +

    • Append elements: The example uses the CArrayFix::AppendL() function +to append objects to the array.

      • +

    • Insert elements: The example uses the CArrayFix::InsertL() function +to insert objects into the array at the specified position.

      • +

    • Remove elements: The example uses the CArrayFixBase::Delete() function +to delete objects from the array.

      • +

    • Sort elements: The example defines an array key to sort the array using the TKeyArrayFix class. The CArrayFixBase::Sort() function is used to sort the array using this array key.

      • +

    • Swap two +elements: The example implements the TSwap::Swap() function through the CMySwap class. The CMySwap::Swap() function is used to swap two elements of +the array.

      • +

    • Find an +element: The example implements the TKeyElementFix class. This class is a TKey derived class. It +overrides the TKey::At() function. The TKeyElementFix::At() function gets a pointer to the key +of a specified array element. This function is used by the CArrayFixFlat::Find() function to find an element in the +array.

      • +

    CArrayPtrFlat

    This example uses the CArrayPtrFlat array class to create an array of pointers +to CBase derived objects.

    The following operations +are performed on this array:

      +

    • Append elements: The example uses the CArrayFix::AppendL() function +to append objects to the array.

      • +

    • Insert elements: The example uses the CArrayFix::InsertL() function +to insert objects into the array at the specified position.

      • +

    • Remove elements: The example uses the CArrayFixBase::Delete() function +to delete objects from the array.

      • +

    CArrayVarFlat

    This example uses the CArrayVarFlat array class to create an array of objects. +These objects are of different lengths. Pointers to these elements +are maintained in a flat dynamic buffer.

    The following operations +are performed on this array:

      +

    • Append elements: The example uses the CArrayVar::AppendL() function +to append objects to the array.

      • +

    • Sort elements: The example defines an array key to sort the array using the TKeyArrayVar class. The CArrayVarBase::Sort() function is used to sort the array using this array key.

      • +

    CArrayPakFlat

    This example uses the CArrayPakFlat array class to create an array of objects. +These objects are of variable lengths. These are stored in a flat +buffer. Each element is preceded by its length information.

    The following operations are performed on this array:

      +

    • Append elements: The example uses the CArrayPak::AppendL() function +to append objects to the array.

      • +

    • Find an +element: The example defines an array key to find an element in +the array using the TKeyArrayPak class. The CArrayPakBase::Find() function is used to find an element +in the array.

      • +

    RArray

    This example constructs a simple dynamic +array called RArray. It is an efficient array of +fixed length objects. The elements of this array are the instances +of another class, so this is specified as a template parameter T.

    This example shows the following operations to +this array:

      +

    • Append elements: The example performs the following steps:

        +

      • Appends the objects into the array using RArray::AppendL().

        • +

      • Displays the number of objects and prints each object present +in the array.

        • +
      • +

    • Insert elements: The example performs the following steps:

        +

      • Inserts the objects at a specified position using RArray::InsertL().

        • +

      • Passes the position of the object to the second parameter of RArray::InsertL().

        • +

      • Inserts objects in the beginning, middle, and at the end of +the array.

        • +

      • Displays the number of objects and prints each object present +in the array.

        • +
      • +

    • Access elements: The example accesses each object in the array and display into the +console.

      • +

    • Remove elements: The example removes an object at a specific position from the array +using RArray::Remove().

      • +

    • Find elements: The example performs the following steps:

        +

      • Finds the first object in the array that matches the specified +object using RArray::Find().

        • +

      • Finds the last object in the array that matches the specified +object using RArray::FindReverse().

        • +

      • Finds the object using a binary search technique in the array, +which matches the specified object using RArray::FindInSignedKeyOrder(). It assumes that the existing objects within the array are in signed +key order.

        • +

      • Finds the object using a binary search technique in the array, +which matches the specified object using RArray::FindInUnsignedKeyOrder(). It assumes that the existing objects within the array are in unsigned +key order.

        • +

      • Finds the object using a binary search technique in the array, +which matches the specified object using RArray::SpecificFindInSignedKeyOrder(). It passes the mode as the second parameter of this API to find +the first, last, or any match in case of multiple matches. It assumes +that the existing objects within the array are in signed key order.

        • +

      • Finds the object using a binary search technique in the array, +which matches the specified object using RArray::SpecificFindInUnsignedKeyOrder(). It passes the mode as the second parameter of this API to find +the first, last, or any match in case of multiple matches. It assumes +that the existing objects within the array are in unsigned key order.

        • +
      • +

    • Sort elements: The example performs the following steps:

        +

      • Constructs two arrays of 64-bit signed integer type objects.

        • +

      • Appends random objects to the first array using RArray::Append().

        • +

      • Inserts the data present in the first array to the second array.

        • +

      • Sorts the element of second array using RArray::sort().

        • +
      • +

    • Destroy +the array: The example performs the following steps:

        +

      • Destroys the array using delete operator.

        • +

      • Closes the array and removes all the memory allocated to the +array using RArray::Close().

        • +
      • +

    RPointerArray

    This example constructs a simple +dynamic array of pointers to objects called RPointerArray. It is an efficient pointer array of fixed-length objects. The elements +of this array are the instances of another class so this is specified +as a template parameter T.

    This example shows +the following operations to this array:

      +

    • Append elements: The example performs the following steps:

        +

      • Appends the object pointers into the array using RPointerArray::AppendL().

        • +

      • Displays the number of object pointers and prints each object +pointer present in the array.

        • +

      • +

    • Insert elements: The example performs the following steps:

        +

      • Inserts the objects pointer at a specified position using RpointerArray::InsertL().

        • +

      • Passes the position of the object pointer to the second parameter +of RpointerArray::InsertL().

        • +

      • Inserts object pointer at the beginning, in the middle, and +at the end of the array.

        • +

      • Displays the number of object pointers and prints each object +pointer present in the array.

        • +
      • +

    • Access elements: The example accesses each object pointer in the array and displays +it to the console.

      • +

    • Remove elements: The example removes an object pointer at a specific position from +the array using RPointerArray::Remove().

      • +

    • Find elements: The example performs the following steps:

        +

      • Finds the first object pointer in the array that matches the +specified object using RPointerArray::Find().

        • +

      • Finds the last object pointer in the array that matches the +specified object using RPointerArray::FindReverse().

        • +

      • Finds the object pointer in the array that matches the specified +object pointer, using RPointerArray::FindInAddressOrder(). It assumes that object pointers in the array are in address order.

        • +
      • +

    • Sort elements: The example performs the following steps:

        +

      • Constructs two arrays of TAny pointer objects.

        • +

      • Appends random objects to the first pointer array using RPointerArray::Append().

        • +

      • Inserts the data present in the first pointer array to the +second pointer array.

        • +

      • Sorts the element of the second pointer array using RPointerArray::sort().

        • +
      • +

    • Destroy +the array: The example performs the following steps:

        +

      • Destroys and resets the pointer array using RPointerArray::ResetAnddestroy().

        • +

      • Closes the pointer array and removes all the memory allocated +to the array using RPointerArray::Close().

        • +
      • +
    +
    Class +summary

    CArrayFixFlat CArrayPtrFlat CArrayVarFlat CArrayPakFlat TSwap TKeyArrayFix TKeyArrayVar TKeyArrayPak TKey RArray TLinearOrder RPointerArray

    +
    Build

    The Symbian build process describes how to build this example.

    For the emulator, the example builds an executable +file called DynamicArrays.exe in the standard +location (\epoc32\release\winscw\<build_variant> for CodeWarrior) directory. After launching the executable file, +depending on the emulator you are using, you can task away from the +application launcher or shell screen to view the console.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7542EA6-6188-5A3D-A287-0766F7B42DC0_d0e357387_href.png Binary file Symbian3/SDK/Source/GUID-B7542EA6-6188-5A3D-A287-0766F7B42DC0_d0e357387_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7542EA6-6188-5A3D-A287-0766F7B42DC0_d0e376536_href.png Binary file Symbian3/SDK/Source/GUID-B7542EA6-6188-5A3D-A287-0766F7B42DC0_d0e376536_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B756AB28-A0EA-5AA3-86E3-CCFFCD642F08.dita --- a/Symbian3/SDK/Source/GUID-B756AB28-A0EA-5AA3-86E3-CCFFCD642F08.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B756AB28-A0EA-5AA3-86E3-CCFFCD642F08.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@

    A link is represented by the templated class CMDBRecordLink<T>. The template parameter defines the type of record to which the link refers.

    - +

    A link is a public data member of a class. The class defines the structure of record. This record is the 'parent' record of the linked record. For example, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B783AF18-FF14-5864-A92C-8BE62E07C68D_d0e204842_href.png Binary file Symbian3/SDK/Source/GUID-B783AF18-FF14-5864-A92C-8BE62E07C68D_d0e204842_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B783AF18-FF14-5864-A92C-8BE62E07C68D_d0e209849_href.png Binary file Symbian3/SDK/Source/GUID-B783AF18-FF14-5864-A92C-8BE62E07C68D_d0e209849_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita --- a/Symbian3/SDK/Source/GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B7A40638-BA80-5175-B23D-2F3964C274A0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -50,7 +50,7 @@ as the Transport.

    Separation of Data Flows and Control in the Comms Architecture - +

    In fact the Comms Architecture actually divides the area marked Control above into two areas, Control and Management. This is the reason that this Comms Architecture is also known as the Three-Plane @@ -77,7 +77,7 @@ the same protocols.

    In this example IP and TCP are used in three different stacks. A combination of these Stacks could be running concurrently.

    - +

    Each stack requires a configuration that details how these protocols find and work with each other; the protocols themselves need to know how to talk with the other protocols. To allow flexibility, each protocol must avoid @@ -97,7 +97,7 @@ The Comms Architecture shown in the scope of a complete protocol stack and the end-to-end path between the applications on each device. - +

    Performance

    A key requirement of the Comms Architecture is the performance of data transfer. diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7D1D1ED-932C-4A17-AE80-EDF163FC789A_d0e53483_href.png Binary file Symbian3/SDK/Source/GUID-B7D1D1ED-932C-4A17-AE80-EDF163FC789A_d0e53483_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7D1D1ED-932C-4A17-AE80-EDF163FC789A_d0e53626_href.png Binary file Symbian3/SDK/Source/GUID-B7D1D1ED-932C-4A17-AE80-EDF163FC789A_d0e53626_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7E55764-C137-4877-9083-63ACEAF30BE5_d0e58076_href.png Binary file Symbian3/SDK/Source/GUID-B7E55764-C137-4877-9083-63ACEAF30BE5_d0e58076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7E55764-C137-4877-9083-63ACEAF30BE5_d0e58219_href.png Binary file Symbian3/SDK/Source/GUID-B7E55764-C137-4877-9083-63ACEAF30BE5_d0e58219_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7E5C7C1-E02F-575C-981B-E14DA10C63D2.dita --- a/Symbian3/SDK/Source/GUID-B7E5C7C1-E02F-575C-981B-E14DA10C63D2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B7E5C7C1-E02F-575C-981B-E14DA10C63D2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,5 +10,5 @@ ArchitectureThis topic describes the architecture of the Root Server and the C32exe process. Figure 1 - The architecture of Root Server and - the C32exe process

    Figure 1 shows that the Root Server is a thread in the C32 process. The Root Server provider a Client library which other applications can use to request services of the Root Server. This client library is the only interaction the Root Server has outside the C32 process.

    The Root Server contains the functionality to manage the MBufs and Bindings of the C32 process. The Root Server creates Comms Provider Modules within the C32 process only. These Comms Provider Modules may have client libraries outside the C32 process. For example, the Socket Server Comms Provider Module loads esocksvr.dll. The esocksvr DLL has a client library esock.lib which applications use to request services from the Socket Server.

    Figure 2 shows the C32 process and Root Server with some example Comms Provider Modules and the Comms Configurator using the Root Server client API.

    Figure 2 - Comms Process with example CPMs - loaded \ No newline at end of file + the C32exe process

    Figure 1 shows that the Root Server is a thread in the C32 process. The Root Server provider a Client library which other applications can use to request services of the Root Server. This client library is the only interaction the Root Server has outside the C32 process.

    The Root Server contains the functionality to manage the MBufs and Bindings of the C32 process. The Root Server creates Comms Provider Modules within the C32 process only. These Comms Provider Modules may have client libraries outside the C32 process. For example, the Socket Server Comms Provider Module loads esocksvr.dll. The esocksvr DLL has a client library esock.lib which applications use to request services from the Socket Server.

    Figure 2 shows the C32 process and Root Server with some example Comms Provider Modules and the Comms Configurator using the Root Server client API.

    Figure 2 - Comms Process with example CPMs + loaded \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7F3F71A-2E05-58A5-98B2-0C62C65286D1_d0e108503_href.png Binary file Symbian3/SDK/Source/GUID-B7F3F71A-2E05-58A5-98B2-0C62C65286D1_d0e108503_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B7F3F71A-2E05-58A5-98B2-0C62C65286D1_d0e108735_href.png Binary file Symbian3/SDK/Source/GUID-B7F3F71A-2E05-58A5-98B2-0C62C65286D1_d0e108735_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B80E3FB0-C26F-52A8-B4DE-0A219B974ABC_d0e201451_href.png Binary file Symbian3/SDK/Source/GUID-B80E3FB0-C26F-52A8-B4DE-0A219B974ABC_d0e201451_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B80E3FB0-C26F-52A8-B4DE-0A219B974ABC_d0e206458_href.png Binary file Symbian3/SDK/Source/GUID-B80E3FB0-C26F-52A8-B4DE-0A219B974ABC_d0e206458_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita --- a/Symbian3/SDK/Source/GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita Tue Jul 20 12:00:49 2010 +0100 @@ -484,7 +484,7 @@ and associating it with each of the controls. The class that implements the hit-test region must implement the MCoeControlHitTest interface.

    Hit-test region example - + class MCoeControlHitTest ... diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B861091F-DFD7-5BDD-B73C-52833F972CBD.dita --- a/Symbian3/SDK/Source/GUID-B861091F-DFD7-5BDD-B73C-52833F972CBD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B861091F-DFD7-5BDD-B73C-52833F972CBD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -81,5 +81,5 @@ header end source filename.cpp -library ECOM.LIB
    Using the extended notifier +library ECOM.LIB
    Using the extended notifier framework     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B8BCC4F0-7F55-4728-B7EA-3280CA822C91.dita --- a/Symbian3/SDK/Source/GUID-B8BCC4F0-7F55-4728-B7EA-3280CA822C91.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B8BCC4F0-7F55-4728-B7EA-3280CA822C91.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ pop-up menu. Stylus pop-up menu displayed - +

    A stylus pop up menu (CAknStylusPopUpMenu, defined in AknStylusPopUpMenu.h) is a floating menu component that contains stylus-specific menu content. As diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B8C3E562-EE45-47F2-BC00-F6C10ADD3026.dita --- a/Symbian3/SDK/Source/GUID-B8C3E562-EE45-47F2-BC00-F6C10ADD3026.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B8C3E562-EE45-47F2-BC00-F6C10ADD3026.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,47 +1,47 @@ - - - - - -Definitions - - - -Area registry based feedback -Feedback is triggered by centralized registry, which is hosted by the -feedback system. When some area with defined feedback is touched, the feedback -is triggered by the system before any application even receives the pointer -event.

    For this kind of feedback it is on application’s responsibility -to add, update and remove areas to the registry according to application state.

    Area -registry’s main purpose is to minimize the feedback latency by processing -the pointer event faster than what would be possible from a normal GUI application. - - -Direct feedback -Feedback is triggered directly from the application, which receives -the pointer event. - - -Feedback latency -The time that it takes from the moment when user touches the screen, -until feedback is generated. This includes all the processing in touch driver -and window server, as well as the time that it takes for actually starting -the feedback. - - -Logical feedback type -Defines the nature of the feedback effect (for example, “basic” or -“sensitive”), but does not tell which type of physical feedback effect (vibrator -pulse, sound effect and so on) is produced. Logical feedback -type is decided by the UI component or application, which is using Tactile -Feedback Client API for producing feedback. - -

     - + + + + + +Definitions
    + + + +Area registry based feedback +Feedback is triggered by centralized registry, which is hosted by the +feedback system. When some area with defined feedback is touched, the feedback +is triggered by the system before any application even receives the pointer +event.

    For this kind of feedback it is on application’s responsibility +to add, update and remove areas to the registry according to application state.

    Area +registry’s main purpose is to minimize the feedback latency by processing +the pointer event faster than what would be possible from a normal GUI application. + + +Direct feedback +Feedback is triggered directly from the application, which receives +the pointer event. + + +Feedback latency +The time that it takes from the moment when user touches the screen, +until feedback is generated. This includes all the processing in touch driver +and window server, as well as the time that it takes for actually starting +the feedback. + + +Logical feedback type +Defines the nature of the feedback effect (e.g. “basic” or “sensitive”), +but does not tell which type of physical feedback effect (vibrator pulse, +sound effect etc.) is produced. Logical feedback type is decided by the UI +component or application, which is using Tactile Feedback Client API for producing +feedback. + +

     +
     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B913762A-2C87-4218-8D20-EBF88F9756DC_d0e12601_href.png Binary file Symbian3/SDK/Source/GUID-B913762A-2C87-4218-8D20-EBF88F9756DC_d0e12601_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B913762A-2C87-4218-8D20-EBF88F9756DC_d0e12704_href.png Binary file Symbian3/SDK/Source/GUID-B913762A-2C87-4218-8D20-EBF88F9756DC_d0e12704_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B92B7DF8-0086-431F-91CE-6F193C045FB5_d0e2868_href.png Binary file Symbian3/SDK/Source/GUID-B92B7DF8-0086-431F-91CE-6F193C045FB5_d0e2868_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B92B7DF8-0086-431F-91CE-6F193C045FB5_d0e2872_href.png Binary file Symbian3/SDK/Source/GUID-B92B7DF8-0086-431F-91CE-6F193C045FB5_d0e2872_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B9306D01-1DE5-511A-AC1A-6E3E9749BA89_d0e246991_href.png Binary file Symbian3/SDK/Source/GUID-B9306D01-1DE5-511A-AC1A-6E3E9749BA89_d0e246991_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B9306D01-1DE5-511A-AC1A-6E3E9749BA89_d0e251942_href.png Binary file Symbian3/SDK/Source/GUID-B9306D01-1DE5-511A-AC1A-6E3E9749BA89_d0e251942_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B9414AE8-820E-4CA5-A9C4-29560CD6F2EF.dita --- a/Symbian3/SDK/Source/GUID-B9414AE8-820E-4CA5-A9C4-29560CD6F2EF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-B9414AE8-820E-4CA5-A9C4-29560CD6F2EF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,45 +9,38 @@ --> -Application -signing +Application signing

    All Symbian applications must be signed before they can be installed. -All applications which use capability-protected -APIs, where the capability cannot be granted by the end user, have to be certified. -Such certification can be obtained through Symbian -Signed.

    -

    Signing is a means of encoding a digital certificate into the application -installation file. The certificate identifies the application’s vendor, and -grants access to capabilities defined during the build process.

    -

    The signing process is described in detail on the Symbian -Signed website.

    -
    Signing options -

    If your application only needs user capabilities (LocalServices, NetworkServices, ReadUserData, WriteUserData, UserEnvironment, andLocation), -you can self-sign the application.

    +All applications which use capability-protected APIs, where the capability cannot be granted by the end +user, have to be certified. Such certification can be obtained through Symbian Signed.

    +

    Signing is a means of encoding a digital certificate into the +application installation file. The certificate identifies the application’s +vendor, and grants access to capabilities defined during the build +process.

    +

    The signing process is described in detail on the Symbian Signed website.

    +
    Signing +options +

    If your application only needs user capabilities (LocalServices, NetworkServices, ReadUserData, WriteUserData, UserEnvironment, andLocation), you can self-sign the application.

    -

    When the end users are installing a self-signed application, they are -informed that the application is untrusted and may decide to abort the installation. -In Nokia E-series devices the user must change a setting to allow self-signed -applications to install.

    +

    When the end users are installing a self-signed application, +they are informed that the application is untrusted and may decide +to abort the installation. In Nokia E-series devices the user must +change a setting to allow self-signed applications to install.

     -

    Sign the sis installation -file with any private key. You can use the MakeKeys application +

    Sign the sis installation file with any private key. You can use the MakeKeys application to create the needed private key and, for example, SignSIS to -sign the application. Both applications are delivered with the SDK. For more -information, see How -to sign a .Sis file with Self-Sign Certificate in the Forum Nokia -Developer Community Wiki.

    +sign the application. Both applications are delivered with the SDK. +For more information, see How to sign a .Sis file with Self-Sign Certificate in the +Forum Nokia Developer Community Wiki.

    The other signing options (Open Signed, Express Signed and Certified -Signed) are described in detail in The -Complete Guide to Symbian Signed.

    +Signed) are described in detail in The Complete Guide to Symbian Signed.

    -
    Additional information -on signing +
    Additional +information on signing -

    The UID value you need to use for -your application depends on whether your application is signed or self-signed. -For more information, see How -to use UIDs.

    +

    The UID value you need to +use for your application depends on whether your application is signed +or self-signed.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B94B394F-E243-5AB0-BAF7-AF68982A3EA8_d0e330077_href.png Binary file Symbian3/SDK/Source/GUID-B94B394F-E243-5AB0-BAF7-AF68982A3EA8_d0e330077_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B94B394F-E243-5AB0-BAF7-AF68982A3EA8_d0e336547_href.png Binary file Symbian3/SDK/Source/GUID-B94B394F-E243-5AB0-BAF7-AF68982A3EA8_d0e336547_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B96A7D1B-957C-5050-9D1D-5439A13A5CED_d0e323931_href.png Binary file Symbian3/SDK/Source/GUID-B96A7D1B-957C-5050-9D1D-5439A13A5CED_d0e323931_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B96A7D1B-957C-5050-9D1D-5439A13A5CED_d0e330401_href.png Binary file Symbian3/SDK/Source/GUID-B96A7D1B-957C-5050-9D1D-5439A13A5CED_d0e330401_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B985B750-9B42-55ED-B7E4-41B06B44C365_d0e304465_href.jpg Binary file Symbian3/SDK/Source/GUID-B985B750-9B42-55ED-B7E4-41B06B44C365_d0e304465_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-B985B750-9B42-55ED-B7E4-41B06B44C365_d0e310937_href.jpg Binary file Symbian3/SDK/Source/GUID-B985B750-9B42-55ED-B7E4-41B06B44C365_d0e310937_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA0D9DA9-3B54-4964-A4D6-9ADA4DEB7231.dita --- a/Symbian3/SDK/Source/GUID-BA0D9DA9-3B54-4964-A4D6-9ADA4DEB7231.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BA0D9DA9-3B54-4964-A4D6-9ADA4DEB7231.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@

    Before listening for sensor channel data, you must open the sensor channel.

     - + Implement the data listener.

    Inherit from the MSensrvDataListener interface diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA1071D5-E358-5B33-9204-CDCD0CECEF0A_d0e299317_href.png Binary file Symbian3/SDK/Source/GUID-BA1071D5-E358-5B33-9204-CDCD0CECEF0A_d0e299317_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA1071D5-E358-5B33-9204-CDCD0CECEF0A_d0e305789_href.png Binary file Symbian3/SDK/Source/GUID-BA1071D5-E358-5B33-9204-CDCD0CECEF0A_d0e305789_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA2EEEC3-86AC-5B1C-81E2-CC571EB5AB3E.dita --- a/Symbian3/SDK/Source/GUID-BA2EEEC3-86AC-5B1C-81E2-CC571EB5AB3E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to use audio recorder utility \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA49FDC0-808B-5E05-81AC-98637214F304.dita --- a/Symbian3/SDK/Source/GUID-BA49FDC0-808B-5E05-81AC-98637214F304.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BA49FDC0-808B-5E05-81AC-98637214F304.dita Tue Jul 20 12:00:49 2010 +0100 @@ -39,7 +39,7 @@ degrees of latitude one degree of longitude is only 55.8 km, which is more difficult to see.

    - +
    Getting started with LBS

    This section provides links to the most important documentation.

    For @@ -65,7 +65,7 @@ Services using IP bearers to connect handsets and network hosts. The Symbian LBS subsystem contains a SUPL Protocol Module to support SUPL.

    - +

    The above figure illustrates how the location information can be provided to the device. Access to these location methods is provided through the positioning modules.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BA7B9BA6-B840-5182-90B0-A4914592A40D.dita --- a/Symbian3/SDK/Source/GUID-BA7B9BA6-B840-5182-90B0-A4914592A40D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BA7B9BA6-B840-5182-90B0-A4914592A40D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@
    SendAs Server process and data flow

    The following figure details the processes and data flow with SendAs Server.

    SendAs Server process and data flow - +
    SendAs Server functionality

    The following sections give detailed information about the SendAs sever functionality:

    Creating diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BAABB057-5C48-4991-A283-DAC5D54562C1_d0e40442_href.png Binary file Symbian3/SDK/Source/GUID-BAABB057-5C48-4991-A283-DAC5D54562C1_d0e40442_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BAABB057-5C48-4991-A283-DAC5D54562C1_d0e40600_href.png Binary file Symbian3/SDK/Source/GUID-BAABB057-5C48-4991-A283-DAC5D54562C1_d0e40600_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BADAAC2D-8614-5036-95BC-3889457F7ED0.dita --- a/Symbian3/SDK/Source/GUID-BADAAC2D-8614-5036-95BC-3889457F7ED0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BADAAC2D-8614-5036-95BC-3889457F7ED0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Positioning ModulesThis document describes the classes that give information about Positioning Modules.

    Purpose

    This document is an overview of the Positioning Module information that is available to client applications using the Location Acquisition API. A Positioning Module is a software component that allows the Location Server to communicate with the mobile device hardware that obtains position data.

    See How to Use Positioning Module Information for an example of how to get Positioning Module information using the Location Acquisition API.

    Types of Positioning Modules

    In mobile devices there may be several Positioning Modules:

    • A Positioning Module that use GPS and/or A-GPS.

    • A Positioning Module that uses the network to obtain cell-based positions.

    • Positioning Modules that use other technologies, such as WLAN positioning.

    Positioning Module information classes

    The classes TPositionModuleInfo and TPositionQuality hold information about the capabilities of Positioning Modules and the quality of position information that they can provide. Figure 1 illustrates these classes.

    Figure 1. TPositionModuleInfo and TPositionQuality classes -
    TPositionModuleInfo

    TPositionModuleInfo describes a Positioning Module. This description includes:

    • The technology type used by the Positioning Module.

      A Positioning Module can use positioning technology which is terminal-based (such as GPS), network based, or a combination of the two (such as A-GPS). The method TPositionModuleInfo::TechnologyType() returns this information.

    • The capabilities of the Positioning Module.

      Different Positioning Modules have different capabilities which depend on the Positioning Module technology type. Most Positioning Modules have the capability to provide latitude and longitude information. Some Positioning Modules can also supply altitude information, course information and satellite data. This information is returned by the method TPositionModuleInfo::Capabilities() as a bit mask of type TPositionModuleInfo::TCapabilities.

    • A unique identifier returned by TPositionModule::ModuleId().

      This identifier is used to select a specific Positioning Module when a client application wishes to use a specific positioning technology to obtain a location fix.

    A TPositionModuleInfo object obtains a reference to its TPositionQuality object by calling TPositionModuleInfo::GetPositionQuality().

    TPositionQuality

    TPositionQuality describes the quality of information that a Positioning Module can provide. The quality describes the accuracy of information, the time to obtain a location fix, the cost of obtaining the fix and power consumption:

    • TPositionQuality::HorizontalAccuracy() and TPositionQuality::VerticalAccuracy() return location accuracy information.

    • TPositionQuality::TimeToFirstFix() and TPositionQuality::TimeToNextFix() return a typical time to get a location fix as a TTimeIntervalMicroSeconds value.

    • TPositionQuality::CostIndicator() returns a cost for using the Positioning Module to get location information. The value returned is an estimate, not a precise cost value and is of type TPositionQuality::TCostIndicator. The cost estimate helps the location server to make a choice of the Positioning Module to use to get a location fix when a specific Positioning Module is not chosen by a client application.

    • TPositionQuality::PowerConsumption() returns an estimate of power consumption for using a Positioning Module. This estimate is of type TPositionQuality::TPowerConsumption and as with cost, it helps the Location Server make a choice of Positioning Module to use to get a location fix.

    See also

    How to Use Positioning Module Information

    \ No newline at end of file +
    TPositionModuleInfo

    TPositionModuleInfo describes a Positioning Module. This description includes:

    • The technology type used by the Positioning Module.

      A Positioning Module can use positioning technology which is terminal-based (such as GPS), network based, or a combination of the two (such as A-GPS). The method TPositionModuleInfo::TechnologyType() returns this information.

    • The capabilities of the Positioning Module.

      Different Positioning Modules have different capabilities which depend on the Positioning Module technology type. Most Positioning Modules have the capability to provide latitude and longitude information. Some Positioning Modules can also supply altitude information, course information and satellite data. This information is returned by the method TPositionModuleInfo::Capabilities() as a bit mask of type TPositionModuleInfo::TCapabilities.

    • A unique identifier returned by TPositionModule::ModuleId().

      This identifier is used to select a specific Positioning Module when a client application wishes to use a specific positioning technology to obtain a location fix.

    A TPositionModuleInfo object obtains a reference to its TPositionQuality object by calling TPositionModuleInfo::GetPositionQuality().

    TPositionQuality

    TPositionQuality describes the quality of information that a Positioning Module can provide. The quality describes the accuracy of information, the time to obtain a location fix, the cost of obtaining the fix and power consumption:

    • TPositionQuality::HorizontalAccuracy() and TPositionQuality::VerticalAccuracy() return location accuracy information.

    • TPositionQuality::TimeToFirstFix() and TPositionQuality::TimeToNextFix() return a typical time to get a location fix as a TTimeIntervalMicroSeconds value.

    • TPositionQuality::CostIndicator() returns a cost for using the Positioning Module to get location information. The value returned is an estimate, not a precise cost value and is of type TPositionQuality::TCostIndicator. The cost estimate helps the location server to make a choice of the Positioning Module to use to get a location fix when a specific Positioning Module is not chosen by a client application.

    • TPositionQuality::PowerConsumption() returns an estimate of power consumption for using a Positioning Module. This estimate is of type TPositionQuality::TPowerConsumption and as with cost, it helps the Location Server make a choice of Positioning Module to use to get a location fix.

    See also

    How to Use Positioning Module Information

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB0C4204-3C31-57D1-B1C5-6D2FCF571931.dita --- a/Symbian3/SDK/Source/GUID-BB0C4204-3C31-57D1-B1C5-6D2FCF571931.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -epocprocesspriority

    epocprocesspriority priority

    Use the epocprocesspriority statement to specify the process priority for your executable EXE.

    Specify low, background, foreground, high, windowserver, fileserver, realtimeserver or supervisor.

    The value specified will be passed on to petran via its -priority switch.

    Use of this statement will have no effect under Win32 platforms.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB35DBCC-FE56-547F-BADA-9EF854691ADC.dita --- a/Symbian3/SDK/Source/GUID-BB35DBCC-FE56-547F-BADA-9EF854691ADC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BB35DBCC-FE56-547F-BADA-9EF854691ADC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,19 +9,16 @@ --> -POP/IMAP -Example -
    Description This -C++ application shows how to retrieve e-mail from a remote mailbox to a device -using IMAP and POP protocols. The usual e-mail features such as sending, editing, -and deleting e-mail messages are demonstrated.
    -
    Download

    Click -on the following link to download the example: InternetEmai.zip

    Click: browse to view the example code.

    -
    Build

    The Symbian build process describes -how to build an application.

    The InternetEmail example builds an executable -called InternetEmail.exe in the standard location (\epoc32\release\winscw\ <build_variant> for -CodeWarrior). After launching the executable, depending on the emulator you -are using, you may need to task away from the app launcher/shell screen to -view the console.

    -
    See also

    POP3 MTM Overview

    SMTP MTM Overview

    +POP/IMAP Example +
    Description This C++ application shows how to retrieve e-mail from a remote +mailbox to a device using IMAP and POP protocols. The usual e-mail +features such as sending, editing, and deleting e-mail messages are +demonstrated.
    +
    Download

    Click on the following link to download the example: InternetEmai.zip

    Click: browse to view the example code.

    +
    Build

    The InternetEmail example builds an executable called InternetEmail.exe in the standard location (\epoc32\release\winscw\ <build_variant> for +CodeWarrior). After launching the executable, depending on the emulator +you are using, you may need to task away from the app launcher/shell +screen to view the console.

    +
    See +also

    POP3 MTM Overview

    SMTP MTM Overview

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB38AFE5-56FE-552D-8715-438936865B69_d0e322770_href.jpg Binary file Symbian3/SDK/Source/GUID-BB38AFE5-56FE-552D-8715-438936865B69_d0e322770_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB38AFE5-56FE-552D-8715-438936865B69_d0e329240_href.jpg Binary file Symbian3/SDK/Source/GUID-BB38AFE5-56FE-552D-8715-438936865B69_d0e329240_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB39DE14-B314-59CB-A8EC-BBD2A5C1BCD9.dita --- a/Symbian3/SDK/Source/GUID-BB39DE14-B314-59CB-A8EC-BBD2A5C1BCD9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BB39DE14-B314-59CB-A8EC-BBD2A5C1BCD9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,131 +1,122 @@ - - - - - -GUI App: Porting -an Engine for Use in a Symbian ApplicationThis section describes the steps to port an engine for use in a -Symbian application. -

    The application uses the FreeBSD cksum utility as its - engine. The checksum example is an application with a user interface and -an engine written in C.

    -

    The first stage in porting this program is to split the project into - the engine (GUIAppEng) and the application (GUIApp).

    -
    The engine

    The -engine is written in C. At its core is the crc() function. -This function accepts a file descriptor and returns the checksum and the -file size.

    The engine's project specification file (GUIAppEng.mmp) - is as follows:

    TARGET GUIAppEng.dll -TARGETTYPE dll -UID 0x1000008d 0x01000a02 -VENDORID 0x70000001 -SOURCEPATH . -SOURCE crc.c -SYSTEMINCLUDE \epoc32\include\libc \epoc32\include -LIBRARY estlib.lib euser.lib - -#if defined(WINS) - deffile GuiAppEngWINS.def -#else if defined(ARM) - deffile GuiAppEngARM.def -#endif -nostrictdef

    The output file is GUIAppEng.dll, -whose import library will be included by the UI.

    - The first UID specified (0x1000008d) is the standard UID - for an interface DLL. The second UID (0x01100a02) is -unique to the GUIApp project.

    - Splitting the project into engine and UI means that the definition of - crc() in crc.c must be marked EXPORT_C - because this function will be exported from the engine's DLL.

    -

    For more information on DLLs, see DLLs. -

    -
    Porting checksum - the GUI app

    The implementation -of checksum (GUIApp.app) limits the user to the selection -of a single file at a time and uses the default algorithm crc(), -defined in crc.c, to produce a 32-bit value.

    -

    The user interface provides two main menu commands; Calculate - checksum (invokes a file selection dialog) and View - checksums. When a file is selected and OK is -pressed, the selected file name is retrieved and opened as shown in the -following code:

    const TUint16* fn = iFileName->PtrZ(); -int fd = wopen( ( const wchar_t* )fn, O_RDONLY, 0 );

    - This code fragment is taken from examples\stdlib\GUIApp.cpp. -

    open() returns a file descriptor which -the engine's crc() function uses to identify the file. -The checksum is calculated (unless an error occurred in attempting to -open or read the file), and is displayed. The file is closed.

    -

    The file name and checksum are appended to an array, the contents -of which may be viewed by selecting View checksums. -

    -
    Linking -to STDLIB - The project specification

    The application -program includes several STDLIB header files, located in \epoc32\include\libc\. -At link time, the program includes estlib.lib and -the engine DLL's .lib (GUIAppEng.lib). -Unlike the previous examples, this application does not link to ecrt0.lib. -In this application there is no main() and the Symbian -platform provides its own E32Main().

    - For information on Symbian applications, their project specification, - and resource files, see How -to build GUI applications.

    -
    Some potential issues
      -

    • Removing writeable static

      The PETRAN stage -of building may report a message similar to the following:

      - WARNING: Dll 'SLSUMENG[0x01000a02].DLL' has initialised data. -

      This warning, which is not reported when building for the Emulator, - indicates that the DLL contains non-const static data. This is not allowed -in ARM builds. If it is not obvious where the problem occurs, the associated - .map file (epoc32\release\<target>\urel\<dllname>.map) -contains information which can help to track down the source file involved. -A search for from *(.bss) (to find uninitialised data) -or from *(.data) (to find initialised data) in GUIAPPEng.map will - reveal the file in which the problem occurs, and the names of the offending - variables, although static variables will not be named.

      • -

    • Include file clashes

      - In C++ source files which use STDLIB routines, the Symbian platform - C++ include files must be included before any of the STDLIB files. Failure -to do this will result in the following warning:

      'NULL' : macro redefinition"
      • -

    • Mixing C and C++

      C and C++ have different views -about the names of functions. If you refer to a C function from C++, ensure -that its prototype is declared as extern "C". If there -are several such function declarations, it may be more convenient to enclose -them within the following:

      #ifdef __cplusplus -extern "C" - { - #endif - ... - #ifdef __cplusplus - } -#endif

      See for example examples\stdlib\GUIApp\extern.h. -

      • -

    • Stack usage

      - Some programs produce the following error:

      unresolved external symbol __chkstk -

      unless the amount of stack they use is reduced. Symbian threads -have only 8k stack by default.

      • -

    • Resource cleanup

      The Symbian platform -has a requirement that all resources which were allocated by an application -must be cleaned up by the time the program terminates. On the Emulator, -in debug builds, failure to do this will cause a panic from the __UHEAP_MARKEND macro. -

      Because the data allocated in the thread-local storage -for STDLIB's DLL (the _reent structure) is not automatically -cleaned up when the environment is destroyed, it must be cleaned up by -the user of STDLIB.

      The function to achieve this is CloseSTDLIB(). -To use this function, file epoc32\include\libc\sys\reent.h must -be included in the project. Call CloseSTDLIB() after -the point at which it is known that code in STDLIB's DLL will no longer -be called and its thread-local storage no longer needed.

      -

      For example, see the destructor for CExampleDocument in - examples\stdlib\GUIApp\GUIApp.cpp.

      • -
    -     -DLLs - -How to build -GUI applications + + + + + +GUI +App: Porting an Engine for Use in a Symbian ApplicationThis section describes the steps to port an engine for +use in a Symbian application. +

    The application uses the FreeBSD cksum utility +as its engine. The checksum example is an application with a user +interface and an engine written in C.

    +

    The first stage in porting this program is to split the project +into the engine (GUIAppEng) and the application (GUIApp).

    +
    The +engine

    The engine is written in C. At its core is the crc() function. This function accepts a file descriptor +and returns the checksum and the file size.

    The engine's +project specification file (GUIAppEng.mmp) +is as follows:

    TARGET GUIAppEng.dll +TARGETTYPE dll +UID 0x1000008d 0x01000a02 +VENDORID 0x70000001 +SOURCEPATH . +SOURCE crc.c +SYSTEMINCLUDE \epoc32\include\libc \epoc32\include +LIBRARY estlib.lib euser.lib + +#if defined(WINS) + deffile GuiAppEngWINS.def +#else if defined(ARM) + deffile GuiAppEngARM.def +#endif +nostrictdef

    The output file is GUIAppEng.dll, whose import library will be included by the UI.

    +

    The first UID specified (0x1000008d) +is the standard UID for an interface DLL. The second UID (0x01100a02) is unique to the GUIApp project.

    Splitting the project into engine +and UI means that the definition of crc() in crc.c must be marked EXPORT_C because +this function will be exported from the engine's DLL.

    +

    For more information on DLLs, see DLLs. +

    +
    Porting +checksum - the GUI app

    The implementation of checksum +(GUIApp.app) limits the user to the selection +of a single file at a time and uses the default algorithm crc(), defined in crc.c, to produce +a 32-bit value.

    The user interface provides +two main menu commands; Calculate checksum (invokes +a file selection dialog) and View checksums. +When a file is selected and OK is pressed, the +selected file name is retrieved and opened as shown in the following +code:

    const TUint16* fn = iFileName->PtrZ(); +int fd = wopen( ( const wchar_t* )fn, O_RDONLY, 0 ); +

    This code fragment is taken from examples\stdlib\GUIApp.cpp.

    open() returns a file descriptor +which the engine's crc() function uses to identify +the file. The checksum is calculated (unless an error occurred +in attempting to open or read the file), and is displayed. The +file is closed.

    The file name and checksum +are appended to an array, the contents of which may be viewed +by selecting View checksums.

    +
    Linking to STDLIB - The project specification

    +The application program includes several STDLIB header files, located + in \epoc32\include\libc\. At link time, the +program includes estlib.lib and the engine +DLL's .lib (GUIAppEng.lib). Unlike the previous examples, this application does not link +to ecrt0.lib. In this application there is no + main() and the Symbian platform provides its +own E32Main().

    +
    Some potential issues
      +

    • Removing writeable static

      The PETRAN +stage of building may report a message similar to the following: +

      WARNING: Dll 'SLSUMENG[0x01000a02].DLL' has initialised data.

      This warning, which is not reported when building for +the Emulator, indicates that the DLL contains non-const static +data. This is not allowed in ARM builds. If it is not obvious +where the problem occurs, the associated .map file (epoc32\release\<target>\urel\<dllname>.map) contains information which can help to track down the source +file involved. A search for from *(.bss) (to +find uninitialised data) or from *(.data) (to +find initialised data) in GUIAPPEng.map will + reveal the file in which the problem occurs, and the names of +the offending variables, although static variables will not be +named.

      • +

    • Include file clashes

      In C++ source files which use STDLIB routines, the Symbian +platform C++ include files must be included before any of the +STDLIB files. Failure to do this will result in the following +warning:

      'NULL' : macro redefinition"
      • +

    • Mixing C and C++

      C and C++ have different +views about the names of functions. If you refer to a C function +from C++, ensure that its prototype is declared as extern +"C". If there are several such function declarations, it + may be more convenient to enclose them within the following: +

      #ifdef __cplusplus +extern "C" + { + #endif + ... + #ifdef __cplusplus + } +#endif

      See for example examples\stdlib\GUIApp\extern.h.

      • +

    • Stack usage

      Some programs produce the following error:

      unresolved external symbol __chkstk +

      unless the amount of stack they use is reduced. Symbian +threads have only 8k stack by default.

      • +

    • Resource cleanup

      The Symbian platform has +a requirement that all resources which were allocated by an application +must be cleaned up by the time the program terminates. On the +Emulator, in debug builds, failure to do this will cause a panic +from the __UHEAP_MARKEND macro.

      Because the data allocated in the thread-local storage for STDLIB's + DLL (the _reent structure) is not automatically +cleaned up when the environment is destroyed, it must be cleaned +up by the user of STDLIB.

      The function to achieve +this is CloseSTDLIB(). To use this function, +file epoc32\include\libc\sys\reent.h must be + included in the project. Call CloseSTDLIB() after +the point at which it is known that code in STDLIB's DLL will +no longer be called and its thread-local storage no longer needed. +

      For example, see the destructor for CExampleDocument in examples\stdlib\GUIApp\GUIApp.cpp.

      • +
    +     +DLLs +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BB8B3A11-0BBC-4759-A7F4-A28C9E70573F.dita --- a/Symbian3/SDK/Source/GUID-BB8B3A11-0BBC-4759-A7F4-A28C9E70573F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BB8B3A11-0BBC-4759-A7F4-A28C9E70573F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@

    This table is filtered for SDK, PDK and internal publications. To view the conditions, see document map on the left hand pane. They have attribute marks

    - +
    @@ -31,14 +31,14 @@

    Stylus pop-up menu

     - +

    Long tap activates the item.

    Toolbar

     - +

    A short tap activates the item (emulates a selection key press).

     @@ -47,14 +47,14 @@

    Choice list

     - +

    A short tap activates the item.

    Forms

     - +

    In the view state (a normal two-row list item), a short tap activates it (emulates a selection key press).

    In the edit @@ -69,7 +69,7 @@

  • Slider

    •  - +

    Same as for equivalent setting items

     @@ -78,7 +78,7 @@

    Grouped soft notification, List query, Grid query

     - +

    A short tap activates the item (emulates a selection key press).

     @@ -86,7 +86,7 @@

    Left/Right arrows in the Navi pane

     - +

    A short tap activates the item and navigates between the @@ -96,7 +96,7 @@

    Markable list

    Selection list

     - +

    A short tap activates the item (emulates a selection key press).

    @@ -104,7 +104,7 @@

    Menu list (for example,Options menu and submenus)

     - +

    A short tap activates the item (emulates a selection key press).

     @@ -113,7 +113,7 @@

    Multi-selection list

     - +

    A short tap marks/unmarks the item.

    @@ -121,14 +121,14 @@

    Preview pop-up

     - +

    Scrollbar.

     - +     @@ -140,7 +140,7 @@

    Pop-up setting

     - +

    A short tap activates the item (emulates a selection key press).

     @@ -148,7 +148,7 @@

    Multi-selection list setting

     - +

    A short tap activates the item.

         @@ -156,7 +156,7 @@

    Text setting

     - +

    The cursor can be moved with the text field. Dragging selects a block of text.

     @@ -165,7 +165,7 @@

    Slider setting

     - +

    The slider thumb is draggable.

         @@ -173,7 +173,7 @@

    Setting list

     - +

    A short tap activates the item(emulates a selection key press).

     @@ -181,7 +181,7 @@

    Softkeys (left and right) in the Control pane

    There is no middle softkey label in Touch UI     - +     @@ -202,7 +202,7 @@ Pane

    - +

    A short tap activates the functionality if the sub-pane has one (the signal and battery panes are inactive).

     @@ -213,7 +213,7 @@ Controller

    - +

    Draggable slider thumb. Icons can be set as tappable.

    Volume slider thumb is draggable, and muting can be done directly by tapping the speaker icon.

     @@ -222,7 +222,7 @@

    Universal indicator pop-up

     - +

    Tapping the link performs the application-specific functionality. Most commonly, opens the application. Tapping the description text diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BBBA5C6C-4E8B-513A-8FA1-C7A04C54C140.dita --- a/Symbian3/SDK/Source/GUID-BBBA5C6C-4E8B-513A-8FA1-C7A04C54C140.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BBBA5C6C-4E8B-513A-8FA1-C7A04C54C140.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,13 +27,13 @@ of the store.

    The essential features of the CClipboard class are shown in the following diagram:

    Clipboard class structure - +

    Any type of data can be placed on the clipboard. When retrieving data, applications check the UID in the stream dictionary to determine whether there is any data relevant to them. The following diagram illustrates a typical situation:

    Clipboard store - + Using Clipboard diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BBBB5000-90A2-503A-9521-2FC6DEC69DC8.dita --- a/Symbian3/SDK/Source/GUID-BBBB5000-90A2-503A-9521-2FC6DEC69DC8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -MMP file syntax \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita --- a/Symbian3/SDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ functions are virtual and implemented in the derived AppUi classes.

    - +

    • View Management

      The diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BBDC3880-DFC3-42C0-913D-E90AB318E015_d0e38273_href.png Binary file Symbian3/SDK/Source/GUID-BBDC3880-DFC3-42C0-913D-E90AB318E015_d0e38273_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BBDC3880-DFC3-42C0-913D-E90AB318E015_d0e38441_href.png Binary file Symbian3/SDK/Source/GUID-BBDC3880-DFC3-42C0-913D-E90AB318E015_d0e38441_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BC498630-E802-5A36-8DB1-D67F739CAD64_d0e317327_href.png Binary file Symbian3/SDK/Source/GUID-BC498630-E802-5A36-8DB1-D67F739CAD64_d0e317327_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BC498630-E802-5A36-8DB1-D67F739CAD64_d0e323797_href.png Binary file Symbian3/SDK/Source/GUID-BC498630-E802-5A36-8DB1-D67F739CAD64_d0e323797_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BC7AFCC5-0052-479E-99AE-F3F982ED1F84-master.png Binary file Symbian3/SDK/Source/GUID-BC7AFCC5-0052-479E-99AE-F3F982ED1F84-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BC7AFCC5-0052-479E-99AE-F3F982ED1F84_d0e67137_href.png Binary file Symbian3/SDK/Source/GUID-BC7AFCC5-0052-479E-99AE-F3F982ED1F84_d0e67137_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BCDCB147-865F-58B0-816F-5FBF0E7CCDD7.dita --- a/Symbian3/SDK/Source/GUID-BCDCB147-865F-58B0-816F-5FBF0E7CCDD7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BCDCB147-865F-58B0-816F-5FBF0E7CCDD7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -56,7 +56,7 @@ The plug-ins and cryptospi.dll have a dependency on cryptography.dll because it implements big integers.

      CryptoSPI dependencies - +
      API summary

      The CryptoSpi namespace is defined for all CryptoSPI classes to differentiate them from the legacy diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BD1DBD2B-A4C1-4769-B454-2A9B4D056446_d0e4811_href.png Binary file Symbian3/SDK/Source/GUID-BD1DBD2B-A4C1-4769-B454-2A9B4D056446_d0e4811_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BD1DBD2B-A4C1-4769-B454-2A9B4D056446_d0e4934_href.png Binary file Symbian3/SDK/Source/GUID-BD1DBD2B-A4C1-4769-B454-2A9B4D056446_d0e4934_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BD649ABC-4DBC-5E37-B80D-2BB86F94F26A.dita --- a/Symbian3/SDK/Source/GUID-BD649ABC-4DBC-5E37-B80D-2BB86F94F26A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BD649ABC-4DBC-5E37-B80D-2BB86F94F26A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,101 +1,97 @@ - - - - - -How to -use the non-modifiable buffer descriptor — TBufC<TInt>Non-modifiable buffer descriptors are useful for holding constant -strings or data and providing safe ways to access that data. -

        -

      • For text data, it is -usual to construct a TBufC<TInt> type and allow the appropriate -variant, either a TBufC8<TInt> or a TBufC16<TInt> to -be selected at build time.

        • -

      • For binary data, an -explicit TBufC8<TInt> is used.

        • -

      • It is rare to use an -explicit TBufC16<TInt>.

        • -
      -

      Data cannot be changed through this descriptor although it can be replaced -using the assignment operators.

      -

      By using the Des() function to construct a TPtr/TPtr8/TPtr16 modifiable -pointer descriptor for the buffer's data, it becomes possible to modify that -data.

      -

      Although, the following notes refer to the build independent types; they -are equally valid for the explicit 8 bit and 16 bit types.

      -
      Constructing a TBufC<TInt>

      A non-modifiable -buffer descriptor can be constructed in a number of ways:

        -

      • as an empty buffer descriptor.

        • -

      • by copying data from -any other type of descriptor.

        • -

      • by copying data from -another non-modifiable buffer descriptor of the same size.

        • -

      The following code fragment constructs a TBufC<16> object. -The buffer descriptor is uninitialised, i.e. it contains no data. The assignment -operator can be used to put data into the buffer descriptor after construction:

      _LIT(KText,"Hello World!"); -... -TBufC<16> buf1; // length of buf1 is 0 -... -buf1 = KText; // data assigned

      The following code fragment -constructs a TBufC<16> object, initialised with the 12 -characters making up the English language phrase "Hello World!".

      The -source descriptor is a literal which is converted to descriptor type.

      _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); // length of buf1 is 12

      The following -code fragment constructs a TBufC<16> object, initialised -with the content of another TBufC<16> object.

      _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); -TBufC<16> buf2(buf1); // data copied from descriptor buf1 - // length of buf2 is 12
      -
      Replacing data

      Data within a non-modifiable buffer -descriptor can be completely replaced by using the assignment operator:

      _LIT(KText,"Hello World!"); -_LIT(KNewText,"New text"); -... -TBufC<16> buf1(KText); -TBufC<16> buf2; -... -buf2 = buf1; // buf2 now contains "Hello World!" -... -buf2 = KNewText; // buf2 now contains "New text". - // the literal is converted to a descriptor - // type.

      To prevent data replacement, -declare buf2 as const.

      -
      Constructing a modifiable pointer descriptor to change the -data

      The data contained in non-modifiable buffer descriptor TBufC<TInt> can be -changed by constructing a TPtr modifiable pointer descriptor -using theDes() member function and then changing the data -through that TPtr.

      The maximum length of the TPtr is -the value of the TBufC<TInt> template parameter.

      The -following code fragment shows data being changed:

      _LIT(KText,"Hello World!"); -_LIT(KExtraText," & Hi"); -... -TBufC<16> buf1(KText); -... -TPtr ptr = buf1.Des(); -... -ptr.Delete((ptr.Length()-1),1); -ptr.Append(KExtraText); -...

      This deletes the last character in buf1 and -adds the characters " & Hi" so that buf1 now contains -the text "Hello World & Hi" and its length is 16. Note that the length -of both buf1 and ptr change to reflect the -data that they now both represent.

      Note that any attempt to append -more data raises a panic.

      -
      Accessing data

      Once a non-modifiable buffer descriptor -has been constructed, the functions in the base class, TDesC, -are available to access the data.

      _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); -... buf1.Length();
      - - -Literal Descriptors - + + + + + +How to use the non-modifiable buffer descriptor — TBufC<TInt>Non-modifiable buffer descriptors are useful for holding +constant strings or data and providing safe ways to access that data. +
        +

      • For text data, +it is usual to construct a TBufC<TInt> type and +allow the appropriate variant, either a TBufC8<TInt> or a TBufC16<TInt> to be selected at build time.

        • +

      • For binary data, +an explicit TBufC8<TInt> is used.

        • +

      • It is rare to +use an explicit TBufC16<TInt>.

        • +
      +

      Data cannot be changed through this descriptor although it can +be replaced using the assignment operators.

      +

      By using the Des() function to construct a TPtr/TPtr8/TPtr16 modifiable pointer descriptor for the +buffer's data, it becomes possible to modify that data.

      +

      Although, the following notes refer to the build independent types; +they are equally valid for the explicit 8 bit and 16 bit types.

      +
      Constructing +a TBufC<TInt>

      A non-modifiable buffer descriptor can +be constructed in a number of ways:

        +

      • as an empty +buffer descriptor.

        • +

      • by copying data +from any other type of descriptor.

        • +

      • by copying data +from another non-modifiable buffer descriptor of the same size.

        • +

      The following code fragment constructs a TBufC<16> object. The buffer descriptor is uninitialised, i.e. it contains +no data. The assignment operator can be used to put data into the +buffer descriptor after construction:

      _LIT(KText,"Hello World!"); +... +TBufC<16> buf1; // length of buf1 is 0 +... +buf1 = KText; // data assigned

      The following code +fragment constructs a TBufC<16> object, initialised +with the 12 characters making up the English language phrase "Hello +World!".

      The source descriptor is a literal which is converted +to descriptor type.

      _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); // length of buf1 is 12

      The following code fragment constructs a TBufC<16> object, initialised with the content of another TBufC<16> object.

      _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); +TBufC<16> buf2(buf1); // data copied from descriptor buf1 + // length of buf2 is 12
      +
      Replacing +data

      Data within a non-modifiable buffer descriptor can +be completely replaced by using the assignment operator:

      _LIT(KText,"Hello World!"); +_LIT(KNewText,"New text"); +... +TBufC<16> buf1(KText); +TBufC<16> buf2; +... +buf2 = buf1; // buf2 now contains "Hello World!" +... +buf2 = KNewText; // buf2 now contains "New text". + // the literal is converted to a descriptor + // type.

      To prevent data +replacement, declare buf2 as const.

      +
      Constructing +a modifiable pointer descriptor to change the data

      The +data contained in non-modifiable buffer descriptor TBufC<TInt> can be changed by constructing a TPtr modifiable +pointer descriptor using theDes() member function +and then changing the data through that TPtr.

      The maximum length of the TPtr is the value +of the TBufC<TInt> template parameter.

      The following code fragment shows data being changed:

      _LIT(KText,"Hello World!"); +_LIT(KExtraText," & Hi"); +... +TBufC<16> buf1(KText); +... +TPtr ptr = buf1.Des(); +... +ptr.Delete((ptr.Length()-1),1); +ptr.Append(KExtraText); +...

      This deletes the last character in buf1 and adds the characters " & Hi" so that buf1 now contains the text "Hello World & Hi" and +its length is 16. Note that the length of both buf1 and ptr change to reflect the data that they now +both represent.

      Note that any attempt to append more data raises +a panic.

      +
      Accessing +data

      Once a non-modifiable buffer descriptor has been constructed, +the functions in the base class, TDesC, are available +to access the data.

      _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); +... buf1.Length();
      +       + +Literal Descriptors       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BDAC640A-FBFE-4DC2-BB29-1A780BCA8ADA_d0e52653_href.png Binary file Symbian3/SDK/Source/GUID-BDAC640A-FBFE-4DC2-BB29-1A780BCA8ADA_d0e52653_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BDAC640A-FBFE-4DC2-BB29-1A780BCA8ADA_d0e52796_href.png Binary file Symbian3/SDK/Source/GUID-BDAC640A-FBFE-4DC2-BB29-1A780BCA8ADA_d0e52796_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BDDDF68F-F7C3-43AF-8B6C-C77C701FD2A9.dita --- a/Symbian3/SDK/Source/GUID-BDDDF68F-F7C3-43AF-8B6C-C77C701FD2A9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BDDDF68F-F7C3-43AF-8B6C-C77C701FD2A9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ in GUI-based applications. In this approach, the application is split into three separate logical parts. Each part contains a different aspect of the entire application, and has a specific role.

      -Logical dependencies in the MVC pattern +Logical dependencies in the MVC pattern

      In this approach, the model:

      • contains and manipulates the data in the application

        @@ -53,7 +53,7 @@ classes.

      The pattern is implemented with the following classes.

      -Relationship between the classes that make up a typical Symbian application +Relationship between the classes that make up a typical Symbian application

      The CAknApplication-derived class:

      • provides the application object expected by the application diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE11D652-3B39-51D2-ACE9-571E8EB71E94_d0e321954_href.png Binary file Symbian3/SDK/Source/GUID-BE11D652-3B39-51D2-ACE9-571E8EB71E94_d0e321954_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE11D652-3B39-51D2-ACE9-571E8EB71E94_d0e328424_href.png Binary file Symbian3/SDK/Source/GUID-BE11D652-3B39-51D2-ACE9-571E8EB71E94_d0e328424_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE2D9AAB-203B-471A-984D-91E917611641.dita --- a/Symbian3/SDK/Source/GUID-BE2D9AAB-203B-471A-984D-91E917611641.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BE2D9AAB-203B-471A-984D-91E917611641.dita Tue Jul 20 12:00:49 2010 +0100 @@ -34,7 +34,7 @@ for the IP address change.

      Process Flow Application-level roaming - +
      Additional information

      The following APIs are used to implement application-level diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE3B53A8-B06D-53C4-8FC0-85B3BA4F39EF.dita --- a/Symbian3/SDK/Source/GUID-BE3B53A8-B06D-53C4-8FC0-85B3BA4F39EF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,15 +0,0 @@ - - - - - -PIM Application Engines -and Services GuideThese topics provide information about the Personal Information -Management components. Functionality includes Calendar, Contacts and Time -zone. \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE3F31A9-959C-5854-8515-052774D8358E_d0e308465_href.png Binary file Symbian3/SDK/Source/GUID-BE3F31A9-959C-5854-8515-052774D8358E_d0e308465_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE3F31A9-959C-5854-8515-052774D8358E_d0e314935_href.png Binary file Symbian3/SDK/Source/GUID-BE3F31A9-959C-5854-8515-052774D8358E_d0e314935_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE66CF87-E750-40BE-A5EB-18A43E927257_d0e63571_href.png Binary file Symbian3/SDK/Source/GUID-BE66CF87-E750-40BE-A5EB-18A43E927257_d0e63571_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE66CF87-E750-40BE-A5EB-18A43E927257_d0e63714_href.png Binary file Symbian3/SDK/Source/GUID-BE66CF87-E750-40BE-A5EB-18A43E927257_d0e63714_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BE893F87-E7F6-56E5-BD27-328B532F8332.dita --- a/Symbian3/SDK/Source/GUID-BE893F87-E7F6-56E5-BD27-328B532F8332.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BE893F87-E7F6-56E5-BD27-328B532F8332.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,68 +1,55 @@ - - - - - -Hello -World Example: Using P.I.P.S. -

      This example application shows a simple EXE and DLL written using P.I.P.S. -(P.I.P.S. Is POSIX on Symbian Platform). It also shows the dynamic lookup -of symbols by name mechanism used in Unix-like operating systems, instead -of the native Symbian Platform lookup by ordinal mechanism. P.I.P.S., from -Symbian OS v9.3, provides APIs from libdl library to -implement this lookup by name mechanism.

      -

      The example defines a simple DLL using the P.I.P.S. STDDLL target -type, with an exported function. It also creates a simple EXE, using the STDEXE target -type, which calls the DLL's exported function using the lookup by name mechanism. -These P.I.P.S. specific target types are required to enable the specific options -for compilers and linkers to generate P.I.P.S. executables and to make symbol -information available in the executable image.

      -
      Download

      Click on the following link to download -the example: HelloWorldExample.zip

      Click: browse to view the example code.

      -
      Description

      The following sections provide more -information about the example.

      Creating a simple DLL using P.I.P.S. -STDDLL target type

      The example creates a DLL file that declares -and defines an exported function. The target type of this DLL file is STDDLL. -It contains a header and a source file:

        -

      • helloworlddllexample.h: -this declares a function with external linkage. Note that for a STDDLL library, -functions and data with external linkage are exported by default, without -any requirement for IMPORT_C and EXPORT_C declarations -in header or source files.

        • -

      • helloworlddllexample.cpp: -this defines the function declared in the header file, which displays a hello -world message to the console.

        • -

      Creating a simple EXE using P.I.P.S. STDEXE target type

      The -example creates an EXE file which calls the exported function of the loaded -DLL. The target type of this EXE file is STDEXE. It calls -the following libdl functions to use the lookup by name -mechanism:

        -

      • dlopen(): -This function is used to load the DLL file which contains an exported function.

        • -
        -

      • dlsysm(): -This function gets the address of a symbol defined within the DLL loaded by -the dlopen() call.

        • -
        -

      • dlclose(): -This function informs the system that the DLL loaded by a previous dlopen() call -is no longer needed by the application.

        • -
        -

      • dlerror(): -This function is used to get the last error that occurred from any of the libdl APIs.

        • -

      The EXE links to libdl.lib to use these functions.

      -
      Build

      The Symbian -build process describes how to build this example application.

      The HelloWorldExample builds -two files, a DLL file helloworlddllexample.dll, and an -EXE file helloworldexeexample.exe, in the standard locations.

      To -run the example, start helloworldexeexample.exe from -the file system or from your IDE. After launching the executable, depending -on the emulator you are using, you may need to navigate away from the application -launcher or shell screen to view the console.

      + + + + + +Hello World Example: Using P.I.P.S. +

      This example application shows a simple EXE and DLL written using +P.I.P.S. (P.I.P.S. Is POSIX on Symbian Platform). It also shows the +dynamic lookup of symbols by name mechanism used in Unix-like operating +systems, instead of the native Symbian Platform lookup by ordinal +mechanism. P.I.P.S., from Symbian OS v9.3, provides APIs from libdl library to implement this lookup by name mechanism.

      +

      The example defines a simple DLL using the P.I.P.S. STDDLL target type, with an exported function. It also creates a simple +EXE, using the STDEXE target type, which calls the +DLL's exported function using the lookup by name mechanism. These +P.I.P.S. specific target types are required to enable the specific +options for compilers and linkers to generate P.I.P.S. executables +and to make symbol information available in the executable image.

      +
      Download

      Click on the following link to +download the example: HelloWorldExample.zip

      Click: browse to view the example code.

      +
      Description

      The following sections provide +more information about the example.

      Creating a simple +DLL using P.I.P.S. STDDLL target type

      The example creates +a DLL file that declares and defines an exported function. The target +type of this DLL file is STDDLL. It contains a header +and a source file:

        +

      • helloworlddllexample.h: this declares a function with external linkage. Note that for a STDDLL library, functions and data with external linkage +are exported by default, without any requirement for IMPORT_C and EXPORT_C declarations in header or source files.

        • +

      • helloworlddllexample.cpp: this defines the function declared in the header file, which displays +a hello world message to the console.

        • +

      Creating a simple EXE using P.I.P.S. STDEXE target type

      The example creates an EXE file which calls the exported +function of the loaded DLL. The target type of this EXE file is STDEXE. It calls the following libdl functions to use the lookup by name mechanism:

        +

      • dlopen(): This function is used to load the DLL file which contains an exported +function.

        • +
        +

      • dlsysm(): This function gets the address of a symbol defined within the DLL +loaded by the dlopen() call.

        • +
        +

      • dlclose(): This function informs the system that the DLL loaded by a previous dlopen() call is no longer needed by the application.

        • +
        +

      • dlerror(): This function is used to get the last error that occurred from +any of the libdl APIs.

        • +

      The EXE links to libdl.lib to use these +functions.

      +
      Build

      The HelloWorldExample builds two files, a DLL file helloworlddllexample.dll, and an EXE file helloworldexeexample.exe, +in the standard locations.

      To run the example, start helloworldexeexample.exe from the file system or from +your IDE. After launching the executable, depending on the emulator +you are using, you may need to navigate away from the application +launcher or shell screen to view the console.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BEA8B4D3-992B-591E-8E2A-BCAC847E0B6E_d0e322969_href.jpg Binary file Symbian3/SDK/Source/GUID-BEA8B4D3-992B-591E-8E2A-BCAC847E0B6E_d0e322969_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BEA8B4D3-992B-591E-8E2A-BCAC847E0B6E_d0e329439_href.jpg Binary file Symbian3/SDK/Source/GUID-BEA8B4D3-992B-591E-8E2A-BCAC847E0B6E_d0e329439_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BEDF6765-4BF4-532F-A2C7-F052FE8A9CA2_d0e233010_href.png Binary file Symbian3/SDK/Source/GUID-BEDF6765-4BF4-532F-A2C7-F052FE8A9CA2_d0e233010_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BEDF6765-4BF4-532F-A2C7-F052FE8A9CA2_d0e237990_href.png Binary file Symbian3/SDK/Source/GUID-BEDF6765-4BF4-532F-A2C7-F052FE8A9CA2_d0e237990_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF155E49-35AF-5BC1-80C5-8D6C68C464F8_d0e214905_href.png Binary file Symbian3/SDK/Source/GUID-BF155E49-35AF-5BC1-80C5-8D6C68C464F8_d0e214905_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF155E49-35AF-5BC1-80C5-8D6C68C464F8_d0e219903_href.png Binary file Symbian3/SDK/Source/GUID-BF155E49-35AF-5BC1-80C5-8D6C68C464F8_d0e219903_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF1AAA0D-DF2F-4E1D-A0D2-F419BD32F97A.dita --- a/Symbian3/SDK/Source/GUID-BF1AAA0D-DF2F-4E1D-A0D2-F419BD32F97A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BF1AAA0D-DF2F-4E1D-A0D2-F419BD32F97A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,112 +1,112 @@ - - - - - -Creating -registration resource files - -

      You need to register your applications -in order to make them visible to the application menu and to provide other -information to the underlying system. To register, you need to provide a registration -resource file, typically named <application_name>_reg.rss, -that contains the non-localized information for your application. You also -need to provide the localizable -registration information. The registration resource file is compiled -during the build process and included in the pkg file -used to make the sis installation file.

      - -

      To create a registration resource file:

      -
        -

      1. Determine -the requirements of your application.

        2. -

      2. Create a text -file with the name <application_name>_reg.rss.

        -
        3. -

      3. Include the -appropriate header files. Typically, you need to include the following files:

        - -
          -

        • appinfo.rh, which is the resource header -file that includes the data structure declaration for the resource statement -used in the registration resource file.

          • -

        • compiled resource header file for the resource file with -the symbolic ID for the localizable -registration information.

          • -

        • localization file, depending on you implementation of the -registration resource file.

          • -
        -

        For more information on pre-processor statement syntax, see C++ pre-processor statements.

        -         -
        4. -

      4. Add a statement -for the UID2 value for the registration resource file as follows:

        - -UID2 KUidAppRegistrationResourceFile -

        UID2 always has the same value in registration resource files.

        -         -
        5. -

      5. Add a statement -for the UID3 value -of the application as follows:

        - -UID3 <uid3 value for application> - -
        6. -

      6. Create a APP_REGISTRATION_INFO resource -for your application. The definition for the registration code block is as -follows:

        - - -RESOURCE APP_REGISTRATION_INFO - { - app_file = ""; // name of application binary file (not including extension) - mandatory - attributes = 0; - localisable_resource_file = ""; // path (not including drive) and name of localisable resource file - localisable_resource_id = r_name36; - hidden = KAppNotHidden; - embeddability = KAppNotEmbeddable; - newfile = KAppDoesNotSupportNewFile; - launch = KAppLaunchInForeground; - group_name(KAppMaxGroupName) = ""; - default_screen_number = 0; - datatype_list[]; // SUPPORTED DATATYPES - file_ownership_list[]; // FILE_OWNERSHIP_INFO - service_list[]; // SERVICE_INFO - opaque_data = 0; // use for opaque data to send to non-native application launchers i.e. MIDlet id - } -

        where,

        -
          -

        • app_file indicates the name of the application -executable binary file without the extension.

          • -

        • localisable_resource_file indicates -the path and name of the localizable resource file for the application.

          -
          • -

        • localisable_resource_id indicates the -symbolic name of the resource for the localizable -registration resource.

          • -

        • newfile indicates whether the application -is document-based and supports the creation of new files. The default value -is KAppDoesNotSupportNewFile.

          • -

        • embeddability indicates whether an application -is embeddable.

          - -

          The default value is KAppNotEmbeddable.

          -

          For more information on embeddability, see FAQ-1129 What is an embeddable application?.

          -           -
          • -
        -

        The header file for the registration resource files is appinfo.rh and -is located in the ./epoc32/include folder.

        -

        For more information on the other values in the resource, see Defining application icons, captions and properties.

        -         -
        7. -
      -

      For a commented example, see HelloWorldBasic_reg.rss.

      + + + + + +Creating registration resource files + +

      You need to register your +applications in order to make them visible to the application menu +and to provide other information to the underlying system. To register, +you need to provide a registration resource file, typically named <application_name>_reg.rss, that contains the non-localized +information for your application. You also need to provide the localizable registration +information. The registration resource file is compiled during +the build process and included in the pkg file +used to make the sis installation file.

      + +

      To create a registration resource file:

      +
        +

      1. Determine +the requirements of your application.

        2. +

      2. Create +a text file with the name <application_name>_reg.rss.

        3. +

      3. Include +the appropriate header files. Typically, you need to include the following +files:

        + +
          +

        • appinfo.rh, which is the resource +header file that includes the data structure declaration for the resource +statement used in the registration resource file.

          • +

        • compiled resource header file for the resource file +with the symbolic ID for the localizable registration +information.

          • +

        • localization file, depending on you implementation +of the registration resource file.

          • +
        +

        For more information on pre-processor statement syntax, see C++ pre-processor statements.

        +         +
        4. +

      4. Add +a statement for the UID2 value for the registration resource file +as follows:

        + +UID2 KUidAppRegistrationResourceFile +

        UID2 always has the same value in registration resource files.

        +         +
        5. +

      5. Add +a statement for the UID3 value +of the application as follows:

        + +UID3 <uid3 value for application> + +
        6. +

      6. Create +a APP_REGISTRATION_INFO resource for your application. +The definition for the registration code block is as follows:

        + + +RESOURCE APP_REGISTRATION_INFO + { + app_file = ""; // name of application binary file (not including extension) - mandatory + attributes = 0; + localisable_resource_file = ""; // path (not including drive) and name of localisable resource file + localisable_resource_id = r_name36; + hidden = KAppNotHidden; + embeddability = KAppNotEmbeddable; + newfile = KAppDoesNotSupportNewFile; + launch = KAppLaunchInForeground; + group_name(KAppMaxGroupName) = ""; + default_screen_number = 0; + datatype_list[]; // SUPPORTED DATATYPES + file_ownership_list[]; // FILE_OWNERSHIP_INFO + service_list[]; // SERVICE_INFO + opaque_data = 0; // use for opaque data to send to non-native application launchers i.e. MIDlet id + } +

        where,

        +
          +

        • app_file indicates the name +of the application executable binary file without the extension.

          +
          • +

        • localisable_resource_file indicates +the path and name of the localizable resource file for the application.

          +
          • +

        • localisable_resource_id indicates +the symbolic name of the resource for the localizable registration +resource.

          • +

        • newfile indicates whether the +application is document-based and supports the creation of new files. +The default value is KAppDoesNotSupportNewFile.

          • +

        • embeddability indicates whether +an application is embeddable.

          + +

          The default value is KAppNotEmbeddable.

          +

          For more information on embeddability, see FAQ-1129 What is an embeddable +application?.

          +           +
          • +
        +

        The header file for the registration resource files is appinfo.rh and is located in the ./epoc32/include folder.

        +

        For more information on the other values in the resource, see Defining application icons, captions and properties.

        +         +
        7. +
      +

      For a commented example, see HelloWorldBasic_reg.rss.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF4E220C-2388-517B-87D8-78AB1EA6382E.dita --- a/Symbian3/SDK/Source/GUID-BF4E220C-2388-517B-87D8-78AB1EA6382E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BF4E220C-2388-517B-87D8-78AB1EA6382E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ ArchitectureThis topic describes the Network Interface Manager (NifMan) architecture.
      NifMan Architecture

      The following diagram outlines the main components in the NifMan architecture:

      - +

      As shown, the NIFMAN configuration daemon architecture consists of two parts:

      • An ECom plug-in for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF626AFA-F8E5-4049-BC3E-E947AD2D39A1_d0e2680_href.png Binary file Symbian3/SDK/Source/GUID-BF626AFA-F8E5-4049-BC3E-E947AD2D39A1_d0e2680_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF626AFA-F8E5-4049-BC3E-E947AD2D39A1_d0e2684_href.png Binary file Symbian3/SDK/Source/GUID-BF626AFA-F8E5-4049-BC3E-E947AD2D39A1_d0e2684_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF822A89-F932-400F-82FC-FB998B768EBF_d0e129372_href.png Binary file Symbian3/SDK/Source/GUID-BF822A89-F932-400F-82FC-FB998B768EBF_d0e129372_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BF822A89-F932-400F-82FC-FB998B768EBF_d0e132992_href.png Binary file Symbian3/SDK/Source/GUID-BF822A89-F932-400F-82FC-FB998B768EBF_d0e132992_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BFCFD93E-D591-50D2-8263-D13D08DD9F15.dita --- a/Symbian3/SDK/Source/GUID-BFCFD93E-D591-50D2-8263-D13D08DD9F15.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -uid

        uid [uid2] [uid3 ]

        Use the uid statement to specify the UIDs for a project.

        Each executable has three UIDs. The first is dictated by the target type of the project (whether an EXE or DLL), so is never specified in an MMP file. The second and third are optional. An MMP file may define none, one or two. See How to use UIDs for details.

        UIDs may be specified in either hex or decimal.

        Under WINSCW, a separate source file is created with the generated makefile containing code to incorporate UIDs into the executable. The name of this file is created by taking the basename of the executable and adding the extension .uid.cpp.

        In OS versions with platform security, the Secure ID for a binary is taken to be the same as the third UID for that file. If no UID statement appears in an MMP file, then zero is used for uid3. If an application (EXE) has a Secure ID of zero, this means 'undefined', and has several consequences, including lack of privacy for data used by that application.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-BFEEECCA-190B-4DDE-8A04-4FE918BE8690.dita --- a/Symbian3/SDK/Source/GUID-BFEEECCA-190B-4DDE-8A04-4FE918BE8690.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-BFEEECCA-190B-4DDE-8A04-4FE918BE8690.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ labeled Options opens the Options menu.

        Options menu - +

        The Options menu is a menu list displayed in a pop-up window. An item is selected by pressing either the left softkey (Select) diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C014FC75-732F-558F-8E6A-77DDAA032930_d0e214465_href.png Binary file Symbian3/SDK/Source/GUID-C014FC75-732F-558F-8E6A-77DDAA032930_d0e214465_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C014FC75-732F-558F-8E6A-77DDAA032930_d0e219463_href.png Binary file Symbian3/SDK/Source/GUID-C014FC75-732F-558F-8E6A-77DDAA032930_d0e219463_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C07B506E-A1C8-537C-A7BF-DD7F449DF8A5.dita --- a/Symbian3/SDK/Source/GUID-C07B506E-A1C8-537C-A7BF-DD7F449DF8A5.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to write an extension makefile template

        A makefile can be defined as a collection of instructions (build steps) that are needed to build a program. The Symbian build process generates the required makefiles from project (.mmp) files, and these makefiles cater to all the usual build steps. There might be few build steps which are specific to your project, and are not catered for by the generated makefiles. These build steps are addressed by separate set of makefiles called extension makefiles. The need for extension makefiles purely depend on requirements of the project you are working with.

        Since Symbian OS v9.3 the functionality and data for extension makefiles are kept separate. That is, extension makefiles with similar functionality can be generalised into a template makefile, which contains only the basic functionality. The same template can be used for various use cases by passing appropriate parameters (data). The parameters can be passed using the prj_extensions and prj_testextensions call mechanism in the bld.inf file, which deprecates the old approach of referring to the extension makefiles using the makefile or gnumakefile directive.

        This template makefile approach reduces the number of makefiles, as the extension makefiles with similar functionality are generalized into a single template.

        The following provides an overview of designing an extension makefile template. Details of the syntax are given in the reference topic Template extension makefiles.

        1. Define the input variables used by the template. The values for these variables are passed through a component's bld.inf file. If necessary, assign the default values for these variables in the corresponding meta file (see Meta files).

        2. Specify the set of targets that the makefile should respond to. An extension makefile responds to a few mandatory targets, apart from the project-specific targets. For more information on mandatory targets, refer to Extension makefile targets.

        3. Specify the build steps to create/update the target. These build steps can include basic shell operations, called through platform independent variables, such as CP to copy a file, and RM to delete a file. Other than calling these basic shell commands, the makefile can call other tools required to complete the build step, such as calling a Perl program.

        For more information on the syntax of template extension makefiles and variables, refer to Template extension makefiles.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C08C9AE9-99A6-4EB7-B665-41E92EDD9747.dita --- a/Symbian3/SDK/Source/GUID-C08C9AE9-99A6-4EB7-B665-41E92EDD9747.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C08C9AE9-99A6-4EB7-B665-41E92EDD9747.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ device. It is a general purpose component and does not directly control device volume. Volume setting item - + Text

    Default touch events for volume setting item diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C0A4DA51-3168-4F99-9A8E-66A326186E29_d0e65898_href.png Binary file Symbian3/SDK/Source/GUID-C0A4DA51-3168-4F99-9A8E-66A326186E29_d0e65898_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C0A4DA51-3168-4F99-9A8E-66A326186E29_d0e66041_href.png Binary file Symbian3/SDK/Source/GUID-C0A4DA51-3168-4F99-9A8E-66A326186E29_d0e66041_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C0CFFE13-579C-5A93-9B63-DC2DCF98EC61_d0e216896_href.png Binary file Symbian3/SDK/Source/GUID-C0CFFE13-579C-5A93-9B63-DC2DCF98EC61_d0e216896_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C0CFFE13-579C-5A93-9B63-DC2DCF98EC61_d0e221894_href.png Binary file Symbian3/SDK/Source/GUID-C0CFFE13-579C-5A93-9B63-DC2DCF98EC61_d0e221894_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C156607A-5929-5971-8077-E8974FA43B3C.dita --- a/Symbian3/SDK/Source/GUID-C156607A-5929-5971-8077-E8974FA43B3C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C156607A-5929-5971-8077-E8974FA43B3C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Basics: Store and Restore Object using Clipboard -
    Download

    Click +

    Download

    Click on the following link to download the example: Clipboard.zip

    Download some additional files required by the example: CommonFramework

    Click: browse to view the example code.

    View the additional files: browse.
    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C1612638-4C5A-5C37-AF1A-16F9EBEF09FD.dita --- a/Symbian3/SDK/Source/GUID-C1612638-4C5A-5C37-AF1A-16F9EBEF09FD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C1612638-4C5A-5C37-AF1A-16F9EBEF09FD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,182 +1,159 @@ - - - - - -transient: -transient server exampleThis example demonstrates the use of transient servers that are -started on demand when a client needs to use the server, and exit after the -last client has disconnected, sometimes after a short delay. It demonstrates -how to handle startup and shutdown situations correctly. -
    Class summary
      -

    • RSessionBase - Client-side handle to a session with -a server.

      • -

    • CTimer - Base class for a timer active object.

      • -

    • CServer2 - Abstract base class for servers (version -2).

      • -

    • CSession2 - Represents a session (version 2) for -a client thread on the server-side.

      • -
    -
    Download

    Click -on the following link to download the example: transient.zip

    click: browse to view the example code.

    -
    Background

    The -client-server framework is an important part of the Symbian platform. There -is a level of complexity in implementing a server for an application, but -this example provides client interface code and server code that can be re-used -in your own implementations.

    Symbian platform servers are of three -basic types:

      -

    • Transient servers: these -are started on demand when a client needs the server, and exit after the last -client has disconnected - sometimes after a short delay, for example, the -socket server.

      • -

    • System servers: these -are started as part of the system boot process, for example, the kernel, the -file server, the window server etc.

      • -

    • Local servers: these -are "local" to a process to provide multi-threaded access to thread-specific -resources, for example, the posix server (in the C Standard Library).

      • -
    -
    Description

    The -transient server supplied here runs in a thread in its own process. This gives -the server independence from its clients. This is important because if the -client were to create the server as a separate thread within its own process, -then the server would exit, i.e. terminate, if its owning process terminated. -This would be true even if clients in other processes were still connected -to it.

    Equally as important:

      -

    • a client does not explicitly -need to start the server prior to connecting; this is done by the client interface.

      • -

    • the server terminates -when not in use shortly after the last client disconnects.

      • -

    • the code handles concurrency -issues, the most common of which is handling the case where the server is -closing down or exiting at the same time that another client is trying to -connect.

      • -

    The example consists of four main parts:

      -

    • Client interface: this -is a DLL (t-client.dll) that is used by clients.

      The -client interface effectively forms the gateway to the server. All requests -to the server, including requests to connect to it are routed through this.

      The -client interface defines just one class: RMySession, derived -from RSessionBase. An RSessionBase (derived) -object represents the client side session and forms a channel of communication -between the client and the server. Requests to the server, and information -received from the server are channelled through this object. Note that the -client side session object is mirrored by a server side session object; an -instance of a class derived from CSession2, which in this -server is called CMySession.

      The client calls Connect() to -set up a connection to the server. This function attempts to start the server -if necessary and then issues a request to create a session with the server. -If the server fails to start, or a session cannot be created then this is -reported back.Simultaneous launching of two server processes is also detected, -with the second attempt failing with KErrAlreadyExists. -On successful completion the connection is established, and a session is created -with the server.

      The client uses the Send() method -to send messages to the server and the Receive() method to -request information from the server. Send() is implemented -by calling down to the synchronous variant of RSessionBase::SendReceive() in -the base class. Synchronous means that it does not return until the server -has dealt with the request.

      Send() passes an operation -code (or function number) identifying the request and a descriptor containing -information to the server. The descriptor is wrapped into a TIpcArgs object. -In practice, your client interface would probably be richer, having variants -of the Send() function that take more than one parameter. -You might also choose to have asynchronous variants of Send(); -your client code (not the client interface) would then need to use active -objects to deal with this.

      Receive() is implemented -by calling down to the asynchronous variant of RSessionBase::SendReceive() in -the base class. Asynchronous means that the call returns immediately, but -the request itself may not complete until some time later.

      Receive() passes -an operation code (or function number) identifying the request, a descriptor -into which the server will place the information, and a TRequestStatus object, -which the server will use to report how the request completes. The descriptor -is wrapped into a TIpcArgs object. Again, you might want -a richer client interface; perhaps different function names to represent different -request types.

      CancelReceive() allows the client -to cancel a pending Receive() request. It is usual to provide -some mechanism to cancel asynchronous requests. This is implemented by calling -down into the asynchronous variant of RSessionBase::SendReceive() in -the base class. Note: the Receive() method simply passes -an operation code (or function number) and no data.

      The operation -codes (or function numbers) are defined by an enum in the header file clientserver.h. -This file is included in both the client interface code and server code as -both need access to these common symbols.

      • -

    • Server: this is an EXE -(t-server.exe) that runs in its own process, and E32Main() -is the entry point. After setting up heap checking (in debug builds only) -the implementation creates a cleanup stack and then executes the main body -of the code inside a trap harness.

      The server code implements several -classes:

      CMyServer: this class derives from the -class CServer2. The main role of this class is to handle -messages sent by client threads; this includes requests from clients for connection -to the server. The connection is established by starting a session with the -server. The session is represented by a session object, in this case the CMySession object.

      Once -the CMyServer object has been created, the active scheduler -can be started by the call to CActiveScheduler::Start(). -This call will not return until the active scheduler is stopped by the CShutdown timer, -which is primed after the last client has disconnected. In simple terms, the -active scheduler is a wait loop. It sits inactive until it receives a message -from (potential) clients (or until the timer completes and stops the active -scheduler). Messages that represent requests for connection result in the -creation of a session. Other messages are passed to the relevant CMySession active -object.

      CMySession: one of these objects is created -for each session, i.e. as a result of a request by a client for connection -to the server. Once sessions have been created, requests received by CMyServer are -then forwarded to the corresponding session, and specifically to the virtual -function ServiceL(), which handles Send(), Receive() and CancelReceive() requests.

      CShutdown: this class represents a timer that is started -before the first client has connected, and after the last client has disconnected. -The timer is stopped once the server has at least one client attached to it. -If the server has no clients, then there is 2 second interval before the server -terminates. This is implemented as an active object.

      • -

    • Test code:this corresponds -to the client, and uses the client interface to communicate with the server -- application developers should make use of the principles applied here and -include them into their own client code.

      • -

    • bld.inf: which is a -component description file.

      • -

    Related APIs

      -

    • CActiveScheduler::Start()

      • -

    • CMySession

      • -

    • CServer2 - Abstract base class for servers (version -2).

      • -

    • CSession2 - Represents a session (version 2) for -a client thread on the server-side.

      • -

    • KErrAlreadyExists - System wide error code -11 : -an object already exists.

      • -

    • RSessionBase - Client-side handle to a session with -a server.

      • -

    • RSessionBase::SendReceive()

      • -

    • TIpcArgs - A Version 2 client/server class that -clients use to package the arguments to be sent to a server.

      • -

    • TRequestStatus - Indicates the completion status -of a request made to a service provider.

      • -
    -
    Building and -configuring

    To build the example:

      -

    • You can build the example -from your IDE or the command line.

      If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

      If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

      bldmake -bldfiles

      abld build

      How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

      • -

    • For the emulator, the -example builds the following executables :

      t-client.dll

      t-server.exe

      t-test.exe (test executable)

      t-testc.dll (test -client)

      in the epoc32\release\winscw\<udeb or urel>\ folder.

      • -
    -     -Platform -security -Build tools -guide -How - to build DLLs -MMP file -syntax + + + + + +transient: transient server exampleThis example demonstrates the use of transient servers +that are started on demand when a client needs to use the server, +and exit after the last client has disconnected, sometimes after a +short delay. It demonstrates how to handle startup and shutdown situations +correctly. +
    Class +summary
      +

    • RSessionBase - Client-side handle to a session +with a server.

      • +

    • CTimer - Base class for a timer active object.

      • +

    • CServer2 - Abstract base class for servers +(version 2).

      • +

    • CSession2 - Represents a session (version +2) for a client thread on the server-side.

      • +
    +
    Download

    Click on the following link to download the example: transient.zip

    click: browse to view the example code.

    +
    Background

    The client-server framework is an important part of the Symbian +platform. There is a level of complexity in implementing a server +for an application, but this example provides client interface code +and server code that can be re-used in your own implementations.

    Symbian platform servers are of three basic types:

      +

    • Transient +servers: these are started on demand when a client needs the server, +and exit after the last client has disconnected - sometimes after +a short delay, for example, the socket server.

      • +

    • System servers: these are started as part of the system boot process, for example, +the kernel, the file server, the window server etc.

      • +

    • Local servers: these are "local" to a process to provide multi-threaded access +to thread-specific resources, for example, the posix server (in the +C Standard Library).

      • +
    +
    Description

    The transient server supplied here runs in a thread in its own +process. This gives the server independence from its clients. This +is important because if the client were to create the server as a +separate thread within its own process, then the server would exit, +i.e. terminate, if its owning process terminated. This would be true +even if clients in other processes were still connected to it.

    Equally as important:

      +

    • a client does +not explicitly need to start the server prior to connecting; this +is done by the client interface.

      • +

    • the server terminates +when not in use shortly after the last client disconnects.

      • +

    • the code handles +concurrency issues, the most common of which is handling the case +where the server is closing down or exiting at the same time that +another client is trying to connect.

      • +

    The example consists of four main parts:

      +

    • Client interface: +a DLL (t-client.dll) that is used by clients.

      The client interface effectively forms the gateway to the server. +All requests to the server, including requests to connect to it are +routed through this.

      The client interface defines just one +class: RMySession, derived from RSessionBase. An RSessionBase (derived) object represents the +client side session and forms a channel of communication between the +client and the server. Requests to the server, and information received +from the server are channelled through this object. Note that the +client side session object is mirrored by a server side session object; +an instance of a class derived from CSession2, +which in this server is called CMySession.

      The client calls Connect() to set up a connection +to the server. This function attempts to start the server if necessary +and then issues a request to create a session with the server. If +the server fails to start, or a session cannot be created then this +is reported back.Simultaneous launching of two server processes is +also detected, with the second attempt failing with KErrAlreadyExists. On successful completion the connection is established, and a session +is created with the server.

      The client uses the Send() method to send messages to the server and the Receive() method to request information from the server. Send() is implemented by calling down to the synchronous variant of RSessionBase::SendReceive() in the base class. Synchronous +means that it does not return until the server has dealt with the +request.

      Send() passes an operation code +(or function number) identifying the request and a descriptor containing +information to the server. The descriptor is wrapped into a TIpcArgs object. In practice, your client interface would +probably be richer, having variants of the Send() function that take more than one parameter. You might also choose +to have asynchronous variants of Send(); your client +code (not the client interface) would then need to use active objects +to deal with this.

      Receive() is implemented +by calling down to the asynchronous variant of RSessionBase::SendReceive() in the base class. Asynchronous means that the call returns immediately, +but the request itself may not complete until some time later.

      Receive() passes an operation code (or function +number) identifying the request, a descriptor into which the server +will place the information, and a TRequestStatus object, which the server will use to report how the request completes. +The descriptor is wrapped into a TIpcArgs object. +Again, you might want a richer client interface; perhaps different +function names to represent different request types.

      CancelReceive() allows the client to cancel a pending Receive() request. It is usual to provide some mechanism +to cancel asynchronous requests. This is implemented by calling down +into the asynchronous variant of RSessionBase::SendReceive() in the base class. Note: the Receive() method simply +passes an operation code (or function number) and no data.

      The operation codes (or function numbers) are defined by an enum +in the header file clientserver.h. This file +is included in both the client interface code and server code as both +need access to these common symbols.

      • +

    • Server: an EXE +(t-server.exe) that runs in its own process, +and E32Main() is the entry point. After setting up heap checking (in +debug builds only) the implementation creates a cleanup stack and +then executes the main body of the code inside a trap harness.

      The server code implements several classes:

      CMyServer: this class derives from the class CServer2. The main role of this class is to handle messages sent by client +threads; this includes requests from clients for connection to the +server. The connection is established by starting a session with the +server. The session is represented by a session object, in this case +the CMySession object.

      Once the CMyServer object has been created, the active scheduler +can be started by the call to CActiveScheduler::Start(). This call will not return until the active scheduler is stopped +by the CShutdown timer, which is primed after the +last client has disconnected. In simple terms, the active scheduler +is a wait loop. It sits inactive until it receives a message from +(potential) clients (or until the timer completes and stops the active +scheduler). Messages that represent requests for connection result +in the creation of a session. Other messages are passed to the relevant CMySession active object.

      CMySession: one of these objects is created for each session, i.e. as a result +of a request by a client for connection to the server. Once sessions +have been created, requests received by CMyServer are then forwarded to the corresponding session, and specifically +to the virtual function ServiceL(), which handles Send(), Receive() and CancelReceive() requests.

      CShutdown: this class represents +a timer that is started before the first client has connected, and +after the last client has disconnected. The timer is stopped once +the server has at least one client attached to it. If the server has +no clients, then there is 2 second interval before the server terminates. +This is implemented as an active object.

      • +

    • Test code: corresponds +to the client, and uses the client interface to communicate with the +server - application developers should make use of the principles +applied here and include them into their own client code.

      • +

    • bld.inf: a component +description file.

      • +

    Related APIs

      +

    • CActiveScheduler::Start()

      • +

    • CMySession

      • +

    • CServer2 - Abstract base class for servers +(version 2).

      • +

    • CSession2 - Represents a session (version +2) for a client thread on the server-side.

      • +

    • KErrAlreadyExists - System wide error code +-11 : an object already exists.

      • +

    • RSessionBase - Client-side handle to a session +with a server.

      • +

    • RSessionBase::SendReceive()

      • +

    • TIpcArgs - A Version 2 client/server class +that clients use to package the arguments to be sent to a server.

      • +

    • TRequestStatus - Indicates the completion +status of a request made to a service provider.

      • +
    +
    Building +and configuring

    To build the example:

      +

    • You can build +the example from your IDE or the command line.

      If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

      If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld +build

      • +

    • For the emulator, +the example builds the following executables :

      t-client.dll

      t-server.exe

      t-test.exe (test executable)

      t-testc.dll (test client)

      in the epoc32\release\winscw\<udeb or urel>\ folder.

      • +
    +     +Platform +security     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C193535D-8756-5A2C-BD3A-280F7DDAF73E_d0e396840_href.jpg Binary file Symbian3/SDK/Source/GUID-C193535D-8756-5A2C-BD3A-280F7DDAF73E_d0e396840_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C193535D-8756-5A2C-BD3A-280F7DDAF73E_d0e400635_href.jpg Binary file Symbian3/SDK/Source/GUID-C193535D-8756-5A2C-BD3A-280F7DDAF73E_d0e400635_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C1A6477D-2130-5664-A845-898212F96381_d0e290246_href.png Binary file Symbian3/SDK/Source/GUID-C1A6477D-2130-5664-A845-898212F96381_d0e290246_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C1A6477D-2130-5664-A845-898212F96381_d0e296718_href.png Binary file Symbian3/SDK/Source/GUID-C1A6477D-2130-5664-A845-898212F96381_d0e296718_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C1B080D9-9C6C-520B-B73E-4EB344B1FC5E.dita --- a/Symbian3/SDK/Source/GUID-C1B080D9-9C6C-520B-B73E-4EB344B1FC5E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C1B080D9-9C6C-520B-B73E-4EB344B1FC5E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -62,7 +62,7 @@ holds settings and supports drawing to bitmapped devices and screens independent of the display.

    - +
    Colour Palette

    The Colour diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C213B26D-32EC-5CD9-956E-1C2143E5D0CA_d0e272131_href.jpg Binary file Symbian3/SDK/Source/GUID-C213B26D-32EC-5CD9-956E-1C2143E5D0CA_d0e272131_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C213B26D-32EC-5CD9-956E-1C2143E5D0CA_d0e276977_href.jpg Binary file Symbian3/SDK/Source/GUID-C213B26D-32EC-5CD9-956E-1C2143E5D0CA_d0e276977_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C218732C-E675-5116-96FE-2604495C2C92_d0e364076_href.png Binary file Symbian3/SDK/Source/GUID-C218732C-E675-5116-96FE-2604495C2C92_d0e364076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C218732C-E675-5116-96FE-2604495C2C92_d0e383225_href.png Binary file Symbian3/SDK/Source/GUID-C218732C-E675-5116-96FE-2604495C2C92_d0e383225_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C21BB0E4-7AF7-58E5-AAD6-8CE67399460C.dita --- a/Symbian3/SDK/Source/GUID-C21BB0E4-7AF7-58E5-AAD6-8CE67399460C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C21BB0E4-7AF7-58E5-AAD6-8CE67399460C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ More information about running the example is given in the build section of this document.

    Design

    The following block diagram describes the example in more detail.

    - +

    CCollector.exe is the Collector process. The user starts the Collector and creates an active scheduler and two global message queues. It also starts the Inverter process called Inverter.exe. The Collector creates one active object @@ -46,8 +46,9 @@ result to InverterOutQ.

    In the Collector process, the active object that monitors the InveterOutQ opens the message queue, receives the received words and displays them -in its console. It uses the NotifyDataAvailable(TRequestStatus&) API to monitor the queue for the next set of data.

    The Class diagram of the example is shown below

    - +in its console. It uses the NotifyDataAvailable(TRequestStatus&) API to monitor the queue for the next set of data.

    The Class +diagram of the example is shown below

    +
    Class summary
      @@ -57,8 +58,7 @@

    • CActive - The core class of the active object abstraction.

    -
    Build

    The Symbian -build process describes how to build this example application.

    The example builds an executable called Inverter.exe and Collector.exe in the standard locations.

    To run the example, first build Inverter.exe and start Collector.exe from the file system +

    Build

    The example builds an executable called Inverter.exe and Collector.exe in the standard locations.

    To run the example, first build Inverter.exe and start Collector.exe from the file system or from your IDE. After launching the .exes (and depending on the emulator you are using) you may need to navigate away from the application launcher or shell screen to view the console.

    A message input diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C23196E8-FDD3-4A10-9DA2-DA83A2AD49D9.dita --- a/Symbian3/SDK/Source/GUID-C23196E8-FDD3-4A10-9DA2-DA83A2AD49D9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C23196E8-FDD3-4A10-9DA2-DA83A2AD49D9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,26 +9,27 @@ --> -Applications -with a user interface -

    If you are developing an application with a user interface, consider -the following issues:

    +Applications with a user interface +

    If you are developing an application with a user interface, +consider the following issues:

      -

    • Other applications may have access to the information that -the user inputs.

      • -

    • A hostile application may lure the user to enter information -that belongs to another application.

      • +

    • Other applications may have access to the information +that the user inputs.

      • +

    • A hostile application may lure the user to enter +information that belongs to another application.

    -

    Password dialogs in particular should be designed so that the user easily -recognizes the currently running application.

    -
    User input -

    It is possible for the user to unintentionally enter incorrect data -that can interfere with the normal operation of the application. All input -should be checked and validated before processing. A one-time check may not -be enough because the content of data can change during processing, so it -is therefore advisable to quickly check the data every time it is used.

    +

    Password dialogs in particular should be designed so that the +user easily recognizes the currently running application.

    +
    User +input +

    It is possible for the user to unintentionally enter incorrect +data that can interfere with the normal operation of the application. +All input should be checked and validated before processing. A one-time +check may not be enough because the content of data can change during +processing, so it is therefore advisable to quickly check the data +every time it is used.

    The following figure shows an example of input processing phases.

    -Examples of input processing +Examples of input processing

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C253D792-7470-5D9F-B39B-1CF42438215A_d0e16601_href.png Binary file Symbian3/SDK/Source/GUID-C253D792-7470-5D9F-B39B-1CF42438215A_d0e16601_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C253D792-7470-5D9F-B39B-1CF42438215A_d0e16783_href.png Binary file Symbian3/SDK/Source/GUID-C253D792-7470-5D9F-B39B-1CF42438215A_d0e16783_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2709212-FD91-5245-9A1D-0E8114D7B202.dita --- a/Symbian3/SDK/Source/GUID-C2709212-FD91-5245-9A1D-0E8114D7B202.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -cleanexport

    abld cleanexport ( ( [-c] | [-w] ) | ( [-k] [-v] ) )

    This command will erase the files created by the corresponding abld - export command.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C28FDA4B-0099-4258-8255-6CF7C44FD4E8_d0e67775_href.png Binary file Symbian3/SDK/Source/GUID-C28FDA4B-0099-4258-8255-6CF7C44FD4E8_d0e67775_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C28FDA4B-0099-4258-8255-6CF7C44FD4E8_d0e67839_href.png Binary file Symbian3/SDK/Source/GUID-C28FDA4B-0099-4258-8255-6CF7C44FD4E8_d0e67839_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C29FE12C-C412-40A8-A067-27C63A519D71.dita --- a/Symbian3/SDK/Source/GUID-C29FE12C-C412-40A8-A067-27C63A519D71.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C29FE12C-C412-40A8-A067-27C63A519D71.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ items. Choice list - +

    You can use the Choice list API in all GUI applications. It is a library API that provides an interface for constructing and using the choice list diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2D6BAB9-89BA-4E8D-82B4-2FAE04B9086C_d0e48752_href.png Binary file Symbian3/SDK/Source/GUID-C2D6BAB9-89BA-4E8D-82B4-2FAE04B9086C_d0e48752_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2D6BAB9-89BA-4E8D-82B4-2FAE04B9086C_d0e48910_href.png Binary file Symbian3/SDK/Source/GUID-C2D6BAB9-89BA-4E8D-82B4-2FAE04B9086C_d0e48910_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2D99C88-09C7-55FA-AF95-3F689BA27484_d0e304448_href.jpg Binary file Symbian3/SDK/Source/GUID-C2D99C88-09C7-55FA-AF95-3F689BA27484_d0e304448_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2D99C88-09C7-55FA-AF95-3F689BA27484_d0e310920_href.jpg Binary file Symbian3/SDK/Source/GUID-C2D99C88-09C7-55FA-AF95-3F689BA27484_d0e310920_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C2FAEBB2-4A1A-5BB0-9670-4801525CBC6A.dita --- a/Symbian3/SDK/Source/GUID-C2FAEBB2-4A1A-5BB0-9670-4801525CBC6A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C2FAEBB2-4A1A-5BB0-9670-4801525CBC6A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,461 +1,477 @@ - - - - - -SQL Index -TipsThis document includes several tips for using SQL indexes. -

    Introduction

    You can use indexes to speed up access. -You create indexes automatically using PRIMARY KEY and UNIQUE.

    Intended -audience:

    This document is intended to be used by Symbian platform -licensees and third party application developers.

    -
    Use an Index -to Speed up Access

    Suppose you have a table like this:

    -CREATE TABLE demo5( - id INTEGER, - content BLOB -); -

    Further suppose that this table contains thousands or millions -of rows and you want to access a single row with a particular ID:

    -SELECT content FROM demo5 WHERE id=? -

    The only want that SQLite can perform this query, and be certain -to get every row with the chosen ID, is to examine every single row, check -the ID of that row, and return the content if the ID matches. Examining every -single row this way is called a full table scan.

    Reading and -checking every row of a large table can be very slow, so you want to avoid -full table scans. The usual way to do this is to create an index on the column -you are searching against. In the example above, an appropriate index would -be this:

    -CREATE INDEX demo5_idx1 ON demo5(id); -

    With an index on the ID column, SQLite is able to use a binary -search to locate entries that contain a particular value of ID. So if the -table contains a million rows, the query can be satisfied with about 20 accesses -rather than 1000000 accesses. This is a huge performance improvement.

    One -of the features of the SQL language is that you do not have to figure out -what indexes you may need in advance of coding your application. It is perfectly -acceptable, even preferable, to write the code for your application using -a database without any indexes. Then once the application is running and you -can make speed measurements, add whatever indexes are needed in order to make -it run faster.

    When you add indexes, the query optimizer within the -SQL compiler is able to find new more efficient bytecode procedures for carrying -out the operations that your SQL statements specify. In other words, by adding -indexes late in the development cycle you have the power to completely reorganize -your data access patterns without changing a single line of code.

    -
    Create Indexes -Automatically Using PRIMARY KEY and UNIQUE

    Any column of a table -that is declared to be the PRIMARY KEY or that is declared UNIQUE will be -indexed automatically. There is no need to create a separate index on that -column using the CREATE INDEX statement. So, for example, this table declaration:

    -CREATE TABLE demo39a( - id INTEGER, - content BLOB -); - -CREATE INDEX demo39_idx1 ON demo39a(id); -

    Is roughly equivalent to the following:

    -CREATE TABLE demo39b( - id INTEGER UNIQUE, - content BLOB -); -

    The two examples above are “roughly” equivalent, but not exactly -equivalent. Both tables have an index on the ID column. In the first case, -the index is created explicitly. In the second case, the index is implied -by the UNIQUE keyword in the type declaration of the ID column. Both table -designs use exactly the same amount of disk space, and both will run queries -such as

    -SELECT content FROM demo39 WHERE id=? -

    using exactly the same bytecode. The only difference is that -table demo39a lets you insert multiple rows with the same ID whereas table -demo39b will raise an exception if you try to insert a new row with the same -ID as an existing row.

    If you use the UNIQUE keyword in the CREATE -INDEX statement of demo39a, like this:

    -CREATE UNIQUE INDEX demo39_idx1 ON demo39a(id); -

    Then both table designs really would be exactly the same in -every way. In fact, whenever SQLite sees the UNIQUE keyword on a column type -declaration, all it does is create an automatic unique index on that column.

    The -PRIMARY KEY modifier on a column type declaration works like UNIQUE; it causes -a unique index to be created automatically. The main difference is that you -are only allowed to have a single PRIMARY KEY. This restriction of only allowing -a single PRIMARY KEY is part of the official SQL language definition.

    The -idea is that a PRIMARY KEY is used to order the rows on disk. Some SQL database -engines actually implement PRIMARY KEYs this way. But with SQLite, a PRIMARY -KEY is like any other UNIQUE column, with only one exception: INTEGER PRIMARY -KEY is a special case which is handled differently, as described in the next -section.

    -
    Use Multi-Column -Indexes

    SQLite is able to make use of multi-column indexes. The -rule is that if an index is over columns X 0 , X 1 , X 2 , -..., X n of some table, then the index can be used if the -WHERE clause contains equality constraints for some prefix of those columns X 0 , X 1 , X 2 , -..., X i where i is less than n.

    As -an example, suppose you have a table and index declared as follows:

    -CREATE TABLE demo314(a,b,c,d,e,f,g); -CREATE INDEX demo314_idx ON demo314(a,b,c,d,e,f); -

    Then the index might be used to help with a query that contained -a WHERE clause like this:

    -... WHERE a=1 AND b='Smith' AND c=1 -

    All three terms of the WHERE clause would be used together -with the index in order to narrow the search. But the index could not be used -if there WHERE clause said:

    -... WHERE b='Smith' AND c=1 -

    The second WHERE clause does not contain equality terms for -a prefix of the columns in the index because it omits a term for the “a” column.

    In -a case like this:

    -... WHERE a=1 AND c=1 -

    Only the “a=1” term in the WHERE clause could be used to help -narrow the search. The “c=1” term is not part of the prefix of terms in the -index which have equality constraints because there is no equality constraint -on the “b” column.

    SQLite only allows a single index to be used per -table within a simple SQL statement. For UPDATE and DELETE statements, this -means that only a single index can ever be used, since those statements can -only operate on a single table at a time.

    In a simple SELECT statement -multiple indexes can be used if the SELECT statement is a join – one index -per table in the join. In a compound SELECT statement (two or more SELECT -statements connected by UNION or INTERSECT or EXCEPT) each SELECT statement -is treated separately and can have its own indexes. Likewise, SELECT statements -that appear in subexpressions are treated separately.

    Some other SQL -database engines (for example PostgreSQL) allow multiple indexes to be used -for each table in a SELECT. For example, if you had a table and index in PostgreSQL -like this:

    -CREATE TABLE pg1(a INT, b INT, c INT, d INT); -CREATE INDEX pg1_ix1 ON pg1(a); -CREATE INDEX pg1_ix2 ON pg1(b); -CREATE INDEX pg1_ix3 ON pg1(c); -

    And if you were to run a query like the following:

    -SELECT d FROM pg1 WHERE a=5 AND b=11 AND c=99; -

    Then PostgreSQL might attempt to optimize the query by using -all three indexes, one for each term of the WHERE clause.

    SQLite does -not work this way. SQLite is compelled to select a single index to use in -the query. It might select any of the three indexes shown, depending on which -one the optimizer things will give the best speedup. But in every case it -will only select a single index and only a single term of the WHERE clause -will be used.

    SQLite prefers to use a multi-column index such as this:

    -CREATE INDEX pg1_ix_all ON pg1(a,b,c); -

    If the pg1_ix_all index is available for use when the SELECT -statement above is prepared, SQLite will likely choose it over any of the -single-column indexes because the multi-column index is able to make use of -all 3 terms of the WHERE clause.

    You can trick SQLite into using multiple -indexes on the same table by rewriting the query. Instead of the SELECT statement -shown above, if you rewrite it as this:

    -SELECT d FROM pg1 WHERE RowID IN ( - SELECT RowID FROM pg1 WHERE a=5 - INTERSECT - SELECT RowID FROM pg1 WHERE b=11 - INTERSECT - SELECT RowID FROM pg1 WHERE c=99 -) -

    Then each of the individual SELECT statements will using a -different single-column index and their results will be combined by the outer -SELECT statement to give the correct result. The other SQL database engines -like PostgreSQL that are able to make use of multiple indexes per table do -so by treating the simpler SELECT statement shown first as if they where the -more complicated SELECT statement shown here.

    -
    Use Inequality -Constraints on the Last Index Term

    Terms in the WHERE clause of -a query or UPDATE or DELETE statement are mostly likely to trigger the use -of an index if they are an equality constraint – in other words if the term -consists of the name of an indexed column, an equal sign (“=”), and an expression.

    So, -for example, if you have a table and index that look like this:

    -CREATE TABLE demo315(a,b,c,d); -CREATE INDEX demo315_idx1 ON demo315(a,b,c); -

    And a query like this:

    -SELECT d FROM demo315 WHERE a=512; -

    The single “a=512” term of the WHERE clause qualifies as an -equality constraint and is likely to provoke the use of the demo315_idx1 index.

    SQLite -supports two other kinds of equality constraints. One is the IN operator:

    -SELECT d FROM demo315 WHERE a IN (512,1024); -SELECT d FROM demo315 WHERE a IN (SELECT x FROM someothertable); -

    There other is the IS NULL constraint:

    -SELECT d FROM demo315 WHERE a IS NULL; -

    SQLite allows at most one term of an index to be constrained -by an inequality such as less than “<”, greater than “>”, less than or -equal to “<=”, or greater than or equal to “>=”.

    The column that -the inequality constrains will be the right-most term of the index that is -used. So, for example, in this query:

    -SELECT d FROM demo315 WHERE a=5 AND b>11 AND c=1; -

    Only the first two terms of the WHERE clause will be used -with the demo315_idx1 index. The third term, the “c=1” constraint, cannot -be used because the “c” column occurs to the right of the “b” column in the -index and the “b” column is constrained by an inequality.

    SQLite allows -up to two inequalities on the same column as long as the two inequalities -provide an upper and lower bound on the column. For example, in this query:

    -SELECT d FROM demo315 WHERE a=5 AND b>11 AND b<23; -

    All three terms of the WHERE clause will be used because the -two inequalities on the “b” column provide an upper and lower bound on the -value of “b”.

    SQLite will only use the four inequalities mentioned -above to help constrain a search: “<”, “>”, “<=”, and “>=”. Other inequality -operators such as not equal to (“!=” or “<>”) and NOT NULL are not helpful -to the query optimizer and will never be used to control an index and help -make the query run faster.

    -
    Use Indexes -To Help ORDER BY Clauses Evaluate Faster

    The default method for -evaluating an ORDER BY clause in a SELECT statement is to first evaluate the -SELECT statement and store the results in a temporary tables, then sort the -temporary table according to the ORDER BY clause and scan the sorted temporary -table to generate the final output.

    This method always works, but -it requires three passes over the data (one pass to generate the result set, -a second pass to sort the result set, and a third pass to output the results) -and it requires a temporary storage space sufficiently large to contain the -entire results set.

    Where possible, SQLite will avoid storing and -sorting the result set by using an index that causes the results to emerge -from the query in sorted order in the first place.

    The way to get -SQLite to use an index for sorting is to provide an index that covers the -same columns specified in the ORDER BY clause. For example, if the table and -index are like this:

    -CREATE TABLE demo316(a,b,c,data); -CREATE INDEX idx316 ON demo316(a,b,c); -

    And you do a query like this:

    -SELECT data FROM demo316 ORDER BY a,b,c; -

    SQLite will use the idx316 index to implement the ORDER BY -clause, obviating the need for temporary storage space and a separate sorting -pass.

    An index can be used to satisfy the search constraints of a -WHERE clause and to impose the ORDER BY ordering of outputs all at once. The -trick is for the ORDER BY clause terms to occur immediately after the WHERE -clause terms in the index. For example, one can write:

    -SELECT data FROM demo316 WHERE a=5 ORDER BY b,c; -

    The “a” column is used in the WHERE clause and the immediately -following terms of the index, “b” and “c” are used in the ORDER BY clause. -So in this case the idx316 index would be used both to speed up the search -and to satisfy the ORDER BY clause.

    This query also uses the idx316 -index because, once again, the ORDER BY clause term “c” immediate follows -the WHERE clause terms “a” and “b” in the index:

    -SELECT data FROM demo316 WHERE a=5 AND b=17 ORDER BY c; -

    But now consider this:

    -SELECT data FROM demo316 WHERE a=5 ORDER BY c; -

    Here there is a gap between the ORDER BY term “c” and the -WHERE clause term “a”. So the idx316 index cannot be used to satisfy both -the WHERE clause and the ORDER BY clause. The index will be used on the WHERE -clause and a separate sorting pass will occur to put the results in the correct -order.

    -
    Add Result -Columns To The End Of Indexes

    Queries will sometimes run faster -if their result columns appear in the right-most entries of an index. Consider -the following example:

    -CREATE TABLE demo317(a,b,c,data); -CREATE INDEX idx317 ON demo316(a,b,c); -

    A query where all result column terms appears in the index, -such as

    -SELECT c FROM demo317 WHERE a=5 ORDER BY b; -

    will typically run about twice as fast or faster than a query -that uses columns that are not in the index, e.g.

    -SELECT data FROM demo317 WHERE a=5 ORDER BY b; -

    The reason for this is that when all information is contained -within the index entry only a single search has to be made for each row of -output. But when some of the information is in the index and other parts are -in the table, first there must be a search for the appropriate index entry -then a separate search is made for the appropriate table row based on the -RowID found in the index entry. Twice as much searching has to be done for -each row of output generated.

    The extra query speed does not come -for free, however. Adding additional columns to an index makes the database -file larger. So when developing an application, the programmer will need to -make a space versus time trade-off to determine whether the extra columns -should be added to the index or not.

    Note that if any column of the -result must be obtained from the original table, then the table row will have -to be searched for anyhow. There will be no speed advantage, so you might -as well omit the extra columns from the end of the index and save on storage -space. The speed-up described in this section can only be realized when every -column in a table is obtainable from the index.

    Taking into account -the results of the previous few sections, the best set of columns to put in -an index can be described as follows:

      -

    • The first columns in -the index should be columns that have equality constraints in the WHERE clause -of the query.

      • -

    • The second group of -columns should match the columns specified in the ORDER BY clause.

      • -

    • Add additional columns -to the end of the index that are used in the result set of the query.

      • -
    -
    Resolve Indexing -Ambiguities Using the Unary “+” Operator

    The SQLite query optimizer -usually does a good job of choosing the best index to use for a particular -query, especially if ANALYZE has been run to provide it with index performance -statistics. But occasions do arise where it is useful to give the optimizer -hints.

    One of the easiest ways to control the operation of the optimizer -is to disqualify terms in the WHERE clause or ORDER BY clause as candidates -for optimization by using the unary “+” operator.

    In SQLite, a unary -“+” operator is a no-op. It makes no change to its operand, even if the operand -is something other than a number. So you can always prefix a “+” to an expression -in without changing the meaning of the expression. As the optimizer will only -use terms in WHERE, HAVING, or ON clauses that have an index column name on -one side of a comparison operator, you can prevent such a term from being -used by the optimizer by prefixing the column name with a “+”.

    For -example, suppose you have a database with a schema like this:

    -CREATE TABLE demo321(a,b,c,data); -CREATE INDEX idx321a ON demo321(a); -CREATE INDEX idx321b ON demo321(b); -

    If you issue a query such as this:

    -SELECT data FROM demo321 WHERE a=5 AND b=11; -

    The query optimizer might use the “a=5” term with idx321a -or it might use the “b=11” term with the idx321b index. But if you want to -force the use of the idx321a index you can accomplish that by disqualifying -the second term of the WHERE clause as a candidate for optimization using -a unary “+” like this:

    -SELECT data FROM demo321 WHERE a=5 AND +b=11; -

    The “+” in front of the “b=11” turns the left-hand side of -the equals comparison operator into an expression instead of an indexed column -name. The optimizer will then not recognize that the second term can be used -with an index and so the optimizer is compelled to use the first “a=5” term.

    The -unary “+” operator can also be used to disable ORDER BY clause optimizations. -Consider this query:

    -SELECT data FROM demo321 WHERE a=5 ORDER BY b; -

    The optimizer has the choice of using the “a=5” term of the -WHERE clause with idx321a to restrict the search. Or it might choose to use -do a full table scan with idx321b to satisfy the ORDER BY clause and thus -avoid a separate sorting pass. You can force one choice or the other using -a unary “+”.

    To force the use of idx321a on the WHERE clause, add -the unary “+” in from of the “b” in the ORDER BY clause:

    -SELECT data FROM demo321 WHERE a=5 ORDER BY +b; -

    To go the other way and force the idx321b index to be used -to satisfy the ORDER BY clause, disqualify the WHERE term by prefixing with -a unary “+”:

    -SELECT data FROM demo321 WHERE +a=5 ORDER BY b; -

    The reader is cautioned not to overuse the unary “+” operator. -The SQLite query optimizer usually picks the best index without any outside -help. Premature use of unary “+” can confuse the optimizer and cause less -than optimal performance. But in some cases it is useful to be able override -the decisions of the optimizer, and the unary “+” operator is an excellent -way to do this when it becomes necessary.

    -
    Avoid Indexing -Large BLOBs and CLOBs

    SQLite stores indexes as b-trees. Each b-tree -node uses one page of the database file. In order to maintain an acceptable -fan-out, the b-tree module within SQLite requires that at least 4 entries -must fit on each page of a b-tree. There is also some overhead associated -with each b-tree page. So at the most there is about 250 bytes of space available -on the main b-tree page for each index entry.

    If an index entry exceeds -this allotment of approximately 250 bytes excess bytes are spilled to overflow -pages. There is no arbitrary limit on the number of overflow pages or on the -length of a b-tree entry, but for maximum efficiency it is best to avoid overflow -pages, especially in indexes. This means that you should strive to keep the -number of bytes in each index entry below 250.

    If you keep the size -of indexes significantly smaller than 250 bytes, then the b-tree fan-out is -increased and the binary search algorithm used to search for entries in an -index has fewer pages to examine and therefore runs faster. So the fewer bytes -used in each index entry the better, at least from a performance perspective.

    For -these reasons, it is recommended that you avoid indexing large BLOBs and CLOBs. -SQLite will continue to work when large BLOBs and CLOBs are indexed, but there -will be a performance impact.

    On the other hand, if you need to lookup -entries using a large BLOB or CLOB as the key, then by all means use an index. -An index on a large BLOB or CLOB is not as fast as an index using more compact -data types such as integers, but it is still many order of magnitude faster -than doing a full table scan. So to be more precise, the advice of this section -is that you should design your applications so that you do not need to lookup -entries using a large BLOB or CLOB as the key. Try to arrange to have compact -keys consisting of short strings or integers.

    Note that many other -SQL database engines disallow the indexing of BLOBs and CLOBs in the first -place. You simple cannot do it. SQLite is more flexible that most in that -it does allow BLOBs and CLOBs to be indexed and it will use those indexes -when appropriate. But for maximum performance, it is best to use smaller search -keys.

    -
    Avoid Excess -Indexes

    Some developers approach SQL-based application development -with the attitude that indexes never hurt and that the more indexes you have, -the faster your application will run. This is definitely not the case. There -is a costs associated with each new index you create:

      -

    • Each new index takes -up additional space in the database file. The more indexes you have, the larger -your database files will become for the same amount of data.

      • -

    • Every INSERT and UPDATE -statement modifies both the original table and all indexes on that table. -So the performance of INSERT and UPDATE decreases linearly with the number -of indexes.

      • -

    • Compiling new SQL statements -using Prepare() takes longer when there are more indexes -for the optimizer to choose between.

      • -

    • Surplus indexes give -the optimizer more opportunities to make a bad choice.

      • -

    Your policy on indexes should be to avoid them wherever you can. -Indexes are powerful medicine and can work wonders to improve the performance -of a program. But just as too many drugs can be worse than none at all, so -also can too many indexes cause more harm than good.

    When building -a new application, a good approach is to omit all explicitly declared indexes -in the beginning and only add indexes as needed to address specific performance -problems.

    Take care to avoid redundant indexes. For example, consider -this schema:

    -CREATE TABLE demo323a(a,b,c); -CREATE INDEX idx323a1 ON demo323(a); -CREATE INDEX idx323a2 ON demo323(a,b); -

    The idx323a1 index is redundant and can be eliminated. Anything -that the idx323a1 index can do the idx323a2 index can do better.

    Other -redundancies are not quite as apparent as the above. Recall that any column -or columns that are declared UNIQUE or PRIMARY KEY (except for the special -case of INTEGER PRIMARY KEY) are automatically indexed. So in the following -schema:

    -CREATE TABLE demo323b(x TEXT PRIMARY KEY, y INTEGER UNIQUE); -CREATE INDEX idx323b1 ON demo323b(x); -CREATE INDEX idx323b2 ON demo323b(y); -

    Both indexes are redundant and can be eliminated with no loss -in query performance. Occasionally one sees a novice SQL programmer use both -UNIQUE and PRIMARY KEY on the same column:

    -CREATE TABLE demo323c(p TEXT UNIQUE PRIMARY KEY, q); -

    This has the effect of creating two indexes on the “p” column -– one for the UNIQUE keywords and another for the PRIMARY KEY keyword. Both -indexes are identical so clearly one can be omitted. A PRIMARY KEY is guaranteed -to always be unique so the UNIQUE keyword can be removed from the demo323c -table definition with no ambiguity or loss of functionality.

    It is -not a fatal error to create too many indexes or redundant indexes. SQLite -will continue to generate the correct answers but it may take longer to produce -those answers and the resulting database files might be a little larger. So -for best results, keep the number of indexes to a minimum.

    -
    Avoid Tables -and Indexes with an Excessive Number of Columns

    SQLite places no -arbitrary limits on the number of columns in a table or index. There are known -commercial applications using SQLite that construct tables with tens of thousands -of columns each. And these applications actually work.

    However the -database engine is optimized for the common case of tables with no more than -a few dozen columns. For best performance you should try to stay in the optimized -region. Furthermore, we note that relational databases with a large number -of columns are usually not well normalized. So even apart from performance -considerations, if you find your design has tables with more than a dozen -or so columns, you really need to rethink how you are building your application.

    There -are a number of places in Prepare() that run in time O(N2) -where N is the number of columns in the table. The constant of proportionality -is small in these cases so you should not have any problems for N of less -than one hundred but for N on the order of a thousand, the time to run Prepare() can -start to become noticeable.

    When the bytecode is running and it needs -to access the i-th column of a table, the values of the previous i-1 columns -must be accessed first. So if you have a large number of columns, accessing -the last column can be an expensive operation. This fact also argues for putting -smaller and more frequently accessed columns early in the table.

    There -are certain optimizations that will only work if the table has 30 or fewer -columns. The optimization that extracts all necessary information from an -index and never refers to the underlying table works this way. So in some -cases, keeping the number of columns in a table at or below 30 can result -in a 2-fold speed improvement.

    Indexes will only be used if they contain -30 or fewer columns. You can put as many columns in an index as you want, -but if the number is greater than 30, the index will never improve performance -and will never do anything but take up space in your database file.

    -     -SQL Overview - -SQL Server -Guide -SQLite - -SQL DB Overview - -Avoid Transient -Tables -Prevent Datafile -Corruption - -SQL Insertion -Tips -SQL Schema -Tips -SQL Expressions - -SQL Statement -Tips -SQL Joins - - ANALYZE -Command - SQL WHERE -CLause Tips + + + + + +SQL Index TipsThis document includes several tips for using SQL indexes. +
    Introduction

    You can use indexes to speed up access. You create indexes automatically +using PRIMARY KEY and UNIQUE.

    Intended audience:

    This document is intended to be +used by Symbian platform licensees and third party application developers.

    +
    Use +an Index to Speed up Access

    Suppose you have a table like +this:

    +CREATE TABLE demo5( + id INTEGER, + content BLOB +); +

    Further suppose that this table contains thousands +or millions of rows and you want to access a single row with a particular +ID:

    +SELECT content FROM demo5 WHERE id=? +

    The only want that SQLite can perform this query, +and be certain to get every row with the chosen ID, is to examine +every single row, check the ID of that row, and return the content +if the ID matches. Examining every single row this way is called a full table scan.

    Reading and checking every row of a +large table can be very slow, so you want to avoid full table scans. +The usual way to do this is to create an index on the column you are +searching against. In the example above, an appropriate index would +be this:

    +CREATE INDEX demo5_idx1 ON demo5(id); +

    With an index on the ID column, SQLite is able to +use a binary search to locate entries that contain a particular value +of ID. So if the table contains a million rows, the query can be satisfied +with about 20 accesses rather than 1000000 accesses. This is a huge +performance improvement.

    One of the features of the SQL language +is that you do not have to figure out what indexes you may need in +advance of coding your application. It is perfectly acceptable, even +preferable, to write the code for your application using a database +without any indexes. Then once the application is running and you +can make speed measurements, add whatever indexes are needed in order +to make it run faster.

    When you add indexes, the query optimizer +within the SQL compiler is able to find new more efficient bytecode +procedures for carrying out the operations that your SQL statements +specify. In other words, by adding indexes late in the development +cycle you have the power to completely reorganize your data access +patterns without changing a single line of code.

    +
    Create +Indexes Automatically Using PRIMARY KEY and UNIQUE

    Any +column of a table that is declared to be the PRIMARY KEY or that is +declared UNIQUE will be indexed automatically. There is no need to +create a separate index on that column using the CREATE INDEX statement. +So, for example, this table declaration:

    +CREATE TABLE demo39a( + id INTEGER, + content BLOB +); + +CREATE INDEX demo39_idx1 ON demo39a(id); +

    Is roughly equivalent to the following:

    +CREATE TABLE demo39b( + id INTEGER UNIQUE, + content BLOB +); +

    The two examples above are “roughly” equivalent, but +not exactly equivalent. Both tables have an index on the ID column. +In the first case, the index is created explicitly. In the second +case, the index is implied by the UNIQUE keyword in the type declaration +of the ID column. Both table designs use exactly the same amount of +disk space, and both will run queries such as

    +SELECT content FROM demo39 WHERE id=? +

    using exactly the same bytecode. The only difference +is that table demo39a lets you insert multiple rows with the same +ID whereas table demo39b will raise an exception if you try to insert +a new row with the same ID as an existing row.

    If you use +the UNIQUE keyword in the CREATE INDEX statement of demo39a, like +this:

    +CREATE UNIQUE INDEX demo39_idx1 ON demo39a(id); +

    Then both table designs really would be exactly the +same in every way. In fact, whenever SQLite sees the UNIQUE keyword +on a column type declaration, all it does is create an automatic unique +index on that column.

    The PRIMARY KEY modifier on a column +type declaration works like UNIQUE; it causes a unique index to be +created automatically. The main difference is that you are only allowed +to have a single PRIMARY KEY. This restriction of only allowing a +single PRIMARY KEY is part of the official SQL language definition.

    The idea is that a PRIMARY KEY is used to order the rows on disk. +Some SQL database engines actually implement PRIMARY KEYs this way. +But with SQLite, a PRIMARY KEY is like any other UNIQUE column, with +only one exception: INTEGER PRIMARY KEY is a special case which is +handled differently, as described in the next section.

    +
    Use +Multi-Column Indexes

    SQLite is able to make use of multi-column +indexes. The rule is that if an index is over columns X 0 , X 1 , X 2 , ..., X n of some table, then the index can be used if the WHERE +clause contains equality constraints for some prefix of those columns X 0 , X 1 , X 2 , ..., X i where i is less than n.

    As +an example, suppose you have a table and index declared as follows:

    +CREATE TABLE demo314(a,b,c,d,e,f,g); +CREATE INDEX demo314_idx ON demo314(a,b,c,d,e,f); +

    Then the index might be used to help with a query +that contained a WHERE clause like this:

    +... WHERE a=1 AND b='Smith' AND c=1 +

    All three terms of the WHERE clause would be used +together with the index in order to narrow the search. But the index +could not be used if there WHERE clause said:

    +... WHERE b='Smith' AND c=1 +

    The second WHERE clause does not contain equality +terms for a prefix of the columns in the index because it omits a +term for the “a” column.

    In a case like this:

    +... WHERE a=1 AND c=1 +

    Only the “a=1” term in the WHERE clause could be used +to help narrow the search. The “c=1” term is not part of the prefix +of terms in the index which have equality constraints because there +is no equality constraint on the “b” column.

    SQLite only allows +a single index to be used per table within a simple SQL statement. +For UPDATE and DELETE statements, this means that only a single index +can ever be used, since those statements can only operate on a single +table at a time.

    In a simple SELECT statement multiple indexes +can be used if the SELECT statement is a join – one index per table +in the join. In a compound SELECT statement (two or more SELECT statements +connected by UNION or INTERSECT or EXCEPT) each SELECT statement is +treated separately and can have its own indexes. Likewise, SELECT +statements that appear in subexpressions are treated separately.

    Some other SQL database engines (for example PostgreSQL) allow +multiple indexes to be used for each table in a SELECT. For example, +if you had a table and index in PostgreSQL like this:

    +CREATE TABLE pg1(a INT, b INT, c INT, d INT); +CREATE INDEX pg1_ix1 ON pg1(a); +CREATE INDEX pg1_ix2 ON pg1(b); +CREATE INDEX pg1_ix3 ON pg1(c); +

    And if you were to run a query like the following:

    +SELECT d FROM pg1 WHERE a=5 AND b=11 AND c=99; +

    Then PostgreSQL might attempt to optimize the query +by using all three indexes, one for each term of the WHERE clause.

    SQLite does not work this way. SQLite is compelled to select +a single index to use in the query. It might select any of the three +indexes shown, depending on which one the optimizer things will give +the best speedup. But in every case it will only select a single index +and only a single term of the WHERE clause will be used.

    SQLite +prefers to use a multi-column index such as this:

    +CREATE INDEX pg1_ix_all ON pg1(a,b,c); +

    If the pg1_ix_all index is available for use when +the SELECT statement above is prepared, SQLite will likely choose +it over any of the single-column indexes because the multi-column +index is able to make use of all 3 terms of the WHERE clause.

    You can trick SQLite into using multiple indexes on the same +table by rewriting the query. Instead of the SELECT statement shown +above, if you rewrite it as this:

    +SELECT d FROM pg1 WHERE RowID IN ( + SELECT RowID FROM pg1 WHERE a=5 + INTERSECT + SELECT RowID FROM pg1 WHERE b=11 + INTERSECT + SELECT RowID FROM pg1 WHERE c=99 +) +

    Then each of the individual SELECT statements will +using a different single-column index and their results will be combined +by the outer SELECT statement to give the correct result. The other +SQL database engines like PostgreSQL that are able to make use of +multiple indexes per table do so by treating the simpler SELECT statement +shown first as if they where the more complicated SELECT statement +shown here.

    +
    Use +Inequality Constraints on the Last Index Term

    Terms in +the WHERE clause of a query or UPDATE or DELETE statement are mostly +likely to trigger the use of an index if they are an equality constraint +– in other words if the term consists of the name of an indexed column, +an equal sign (“=”), and an expression.

    So, for example, if +you have a table and index that look like this:

    +CREATE TABLE demo315(a,b,c,d); +CREATE INDEX demo315_idx1 ON demo315(a,b,c); +

    And a query like this:

    +SELECT d FROM demo315 WHERE a=512; +

    The single “a=512” term of the WHERE clause qualifies +as an equality constraint and is likely to provoke the use of the +demo315_idx1 index.

    SQLite supports two other kinds of equality +constraints. One is the IN operator:

    +SELECT d FROM demo315 WHERE a IN (512,1024); +SELECT d FROM demo315 WHERE a IN (SELECT x FROM someothertable); +

    There other is the IS NULL constraint:

    +SELECT d FROM demo315 WHERE a IS NULL; +

    SQLite allows at most one term of an index to be constrained +by an inequality such as less than “<”, greater than “>”, less +than or equal to “<=”, or greater than or equal to “>=”.

    The column that the inequality constrains will be the right-most +term of the index that is used. So, for example, in this query:

    +SELECT d FROM demo315 WHERE a=5 AND b>11 AND c=1; +

    Only the first two terms of the WHERE clause will +be used with the demo315_idx1 index. The third term, the “c=1” constraint, +cannot be used because the “c” column occurs to the right of the “b” +column in the index and the “b” column is constrained by an inequality.

    SQLite allows up to two inequalities on the same column as long +as the two inequalities provide an upper and lower bound on the column. +For example, in this query:

    +SELECT d FROM demo315 WHERE a=5 AND b>11 AND b<23; +

    All three terms of the WHERE clause will be used because +the two inequalities on the “b” column provide an upper and lower +bound on the value of “b”.

    SQLite will only use the four inequalities +mentioned above to help constrain a search: “<”, “>”, “<=”, +and “>=”. Other inequality operators such as not equal to (“!=” or +“<>”) and NOT NULL are not helpful to the query optimizer and will +never be used to control an index and help make the query run faster.

    +
    Use +Indexes To Help ORDER BY Clauses Evaluate Faster

    The default +method for evaluating an ORDER BY clause in a SELECT statement is +to first evaluate the SELECT statement and store the results in a +temporary tables, then sort the temporary table according to the ORDER +BY clause and scan the sorted temporary table to generate the final +output.

    This method always works, but it requires three passes +over the data (one pass to generate the result set, a second pass +to sort the result set, and a third pass to output the results) and +it requires a temporary storage space sufficiently large to contain +the entire results set.

    Where possible, SQLite will avoid +storing and sorting the result set by using an index that causes the +results to emerge from the query in sorted order in the first place.

    The way to get SQLite to use an index for sorting is to provide +an index that covers the same columns specified in the ORDER BY clause. +For example, if the table and index are like this:

    +CREATE TABLE demo316(a,b,c,data); +CREATE INDEX idx316 ON demo316(a,b,c); +

    And you do a query like this:

    +SELECT data FROM demo316 ORDER BY a,b,c; +

    SQLite will use the idx316 index to implement the +ORDER BY clause, obviating the need for temporary storage space and +a separate sorting pass.

    An index can be used to satisfy the +search constraints of a WHERE clause and to impose the ORDER BY ordering +of outputs all at once. The trick is for the ORDER BY clause terms +to occur immediately after the WHERE clause terms in the index. For +example, one can write:

    +SELECT data FROM demo316 WHERE a=5 ORDER BY b,c; +

    The “a” column is used in the WHERE clause and the +immediately following terms of the index, “b” and “c” are used in +the ORDER BY clause. So in this case the idx316 index would be used +both to speed up the search and to satisfy the ORDER BY clause.

    This query also uses the idx316 index because, once again, the +ORDER BY clause term “c” immediate follows the WHERE clause terms +“a” and “b” in the index:

    +SELECT data FROM demo316 WHERE a=5 AND b=17 ORDER BY c; +

    But now consider this:

    +SELECT data FROM demo316 WHERE a=5 ORDER BY c; +

    Here there is a gap between the ORDER BY term “c” +and the WHERE clause term “a”. So the idx316 index cannot be used +to satisfy both the WHERE clause and the ORDER BY clause. The index +will be used on the WHERE clause and a separate sorting pass will +occur to put the results in the correct order.

    +
    Add +Result Columns To The End Of Indexes

    Queries will sometimes +run faster if their result columns appear in the right-most entries +of an index. Consider the following example:

    +CREATE TABLE demo317(a,b,c,data); +CREATE INDEX idx317 ON demo316(a,b,c); +

    A query where all result column terms appears in the +index, such as

    +SELECT c FROM demo317 WHERE a=5 ORDER BY b; +

    will typically run about twice as fast or faster than +a query that uses columns that are not in the index, e.g.

    +SELECT data FROM demo317 WHERE a=5 ORDER BY b; +

    The reason for this is that when all information is +contained within the index entry only a single search has to be made +for each row of output. But when some of the information is in the +index and other parts are in the table, first there must be a search +for the appropriate index entry then a separate search is made for +the appropriate table row based on the RowID found in the index entry. +Twice as much searching has to be done for each row of output generated.

    The extra query speed does not come for free, however. Adding +additional columns to an index makes the database file larger. So +when developing an application, the programmer will need to make a +space versus time trade-off to determine whether the extra columns +should be added to the index or not.

    Note that if any column +of the result must be obtained from the original table, then the table +row will have to be searched for anyhow. There will be no speed advantage, +so you might as well omit the extra columns from the end of the index +and save on storage space. The speed-up described in this section +can only be realized when every column in a table is obtainable from +the index.

    Taking into account the results of the previous +few sections, the best set of columns to put in an index can be described +as follows:

      +

    • The first columns +in the index should be columns that have equality constraints in the +WHERE clause of the query.

      • +

    • The second group +of columns should match the columns specified in the ORDER BY clause.

      • +

    • Add additional +columns to the end of the index that are used in the result set of +the query.

      • +
    +
    Resolve +Indexing Ambiguities Using the Unary “+” Operator

    The SQLite +query optimizer usually does a good job of choosing the best index +to use for a particular query, especially if ANALYZE has been run +to provide it with index performance statistics. But occasions do +arise where it is useful to give the optimizer hints.

    One +of the easiest ways to control the operation of the optimizer is to +disqualify terms in the WHERE clause or ORDER BY clause as candidates +for optimization by using the unary “+” operator.

    In SQLite, +a unary “+” operator is a no-op. It makes no change to its operand, +even if the operand is something other than a number. So you can always +prefix a “+” to an expression in without changing the meaning of the +expression. As the optimizer will only use terms in WHERE, HAVING, +or ON clauses that have an index column name on one side of a comparison +operator, you can prevent such a term from being used by the optimizer +by prefixing the column name with a “+”.

    For example, suppose +you have a database with a schema like this:

    +CREATE TABLE demo321(a,b,c,data); +CREATE INDEX idx321a ON demo321(a); +CREATE INDEX idx321b ON demo321(b); +

    If you issue a query such as this:

    +SELECT data FROM demo321 WHERE a=5 AND b=11; +

    The query optimizer might use the “a=5” term with +idx321a or it might use the “b=11” term with the idx321b index. But +if you want to force the use of the idx321a index you can accomplish +that by disqualifying the second term of the WHERE clause as a candidate +for optimization using a unary “+” like this:

    +SELECT data FROM demo321 WHERE a=5 AND +b=11; +

    The “+” in front of the “b=11” turns the left-hand +side of the equals comparison operator into an expression instead +of an indexed column name. The optimizer will then not recognize that +the second term can be used with an index and so the optimizer is +compelled to use the first “a=5” term.

    The unary “+” operator +can also be used to disable ORDER BY clause optimizations. Consider +this query:

    +SELECT data FROM demo321 WHERE a=5 ORDER BY b; +

    The optimizer has the choice of using the “a=5” term +of the WHERE clause with idx321a to restrict the search. Or it might +choose to use do a full table scan with idx321b to satisfy the ORDER +BY clause and thus avoid a separate sorting pass. You can force one +choice or the other using a unary “+”.

    To force the use of +idx321a on the WHERE clause, add the unary “+” in from of the “b” +in the ORDER BY clause:

    +SELECT data FROM demo321 WHERE a=5 ORDER BY +b; +

    To go the other way and force the idx321b index to +be used to satisfy the ORDER BY clause, disqualify the WHERE term +by prefixing with a unary “+”:

    +SELECT data FROM demo321 WHERE +a=5 ORDER BY b; +

    The reader is cautioned not to overuse the unary “+” +operator. The SQLite query optimizer usually picks the best index +without any outside help. Premature use of unary “+” can confuse the +optimizer and cause less than optimal performance. But in some cases +it is useful to be able override the decisions of the optimizer, and +the unary “+” operator is an excellent way to do this when it becomes +necessary.

    +
    Avoid +Indexing Large BLOBs and CLOBs

    SQLite stores indexes as +b-trees. Each b-tree node uses one page of the database file. In order +to maintain an acceptable fan-out, the b-tree module within SQLite +requires that at least 4 entries must fit on each page of a b-tree. +There is also some overhead associated with each b-tree page. So at +the most there is about 250 bytes of space available on the main b-tree +page for each index entry.

    If an index entry exceeds this +allotment of approximately 250 bytes excess bytes are spilled to overflow +pages. There is no arbitrary limit on the number of overflow pages +or on the length of a b-tree entry, but for maximum efficiency it +is best to avoid overflow pages, especially in indexes. This means +that you should strive to keep the number of bytes in each index entry +below 250.

    If you keep the size of indexes significantly smaller +than 250 bytes, then the b-tree fan-out is increased and the binary +search algorithm used to search for entries in an index has fewer +pages to examine and therefore runs faster. So the fewer bytes used +in each index entry the better, at least from a performance perspective.

    For these reasons, it is recommended that you avoid indexing +large BLOBs and CLOBs. SQLite will continue to work when large BLOBs +and CLOBs are indexed, but there will be a performance impact.

    On the other hand, if you need to lookup entries using a large +BLOB or CLOB as the key, then by all means use an index. An index +on a large BLOB or CLOB is not as fast as an index using more compact +data types such as integers, but it is still many order of magnitude +faster than doing a full table scan. So to be more precise, the advice +of this section is that you should design your applications so that +you do not need to lookup entries using a large BLOB or CLOB as the +key. Try to arrange to have compact keys consisting of short strings +or integers.

    Note that many other SQL database engines disallow +the indexing of BLOBs and CLOBs in the first place. You simple cannot +do it. SQLite is more flexible that most in that it does allow BLOBs +and CLOBs to be indexed and it will use those indexes when appropriate. +But for maximum performance, it is best to use smaller search keys.

    +
    Avoid +Excess Indexes

    Some developers approach SQL-based application +development with the attitude that indexes never hurt and that the +more indexes you have, the faster your application will run. This +is definitely not the case. There is a costs associated with each +new index you create:

      +

    • Each new index +takes up additional space in the database file. The more indexes you +have, the larger your database files will become for the same amount +of data.

      • +

    • Every INSERT +and UPDATE statement modifies both the original table and all indexes +on that table. So the performance of INSERT and UPDATE decreases linearly +with the number of indexes.

      • +

    • Compiling new +SQL statements using Prepare() takes longer when +there are more indexes for the optimizer to choose between.

      • +

    • Surplus indexes +give the optimizer more opportunities to make a bad choice.

      • +

    Your policy on indexes should be to avoid them wherever you +can. Indexes are powerful medicine and can work wonders to improve +the performance of a program. But just as too many drugs can be worse +than none at all, so also can too many indexes cause more harm than +good.

    When building a new application, a good approach is +to omit all explicitly declared indexes in the beginning and only +add indexes as needed to address specific performance problems.

    Take care to avoid redundant indexes. For example, consider this +schema:

    +CREATE TABLE demo323a(a,b,c); +CREATE INDEX idx323a1 ON demo323(a); +CREATE INDEX idx323a2 ON demo323(a,b); +

    The idx323a1 index is redundant and can be eliminated. +Anything that the idx323a1 index can do the idx323a2 index can do +better.

    Other redundancies are not quite as apparent as the +above. Recall that any column or columns that are declared UNIQUE +or PRIMARY KEY (except for the special case of INTEGER PRIMARY KEY) +are automatically indexed. So in the following schema:

    +CREATE TABLE demo323b(x TEXT PRIMARY KEY, y INTEGER UNIQUE); +CREATE INDEX idx323b1 ON demo323b(x); +CREATE INDEX idx323b2 ON demo323b(y); +

    Both indexes are redundant and can be eliminated with +no loss in query performance. Occasionally one sees a novice SQL programmer +use both UNIQUE and PRIMARY KEY on the same column:

    +CREATE TABLE demo323c(p TEXT UNIQUE PRIMARY KEY, q); +

    This has the effect of creating two indexes on the +“p” column – one for the UNIQUE keywords and another for the PRIMARY +KEY keyword. Both indexes are identical so clearly one can be omitted. +A PRIMARY KEY is guaranteed to always be unique so the UNIQUE keyword +can be removed from the demo323c table definition with no ambiguity +or loss of functionality.

    It is not a fatal error to create +too many indexes or redundant indexes. SQLite will continue to generate +the correct answers but it may take longer to produce those answers +and the resulting database files might be a little larger. So for +best results, keep the number of indexes to a minimum.

    +
    Avoid +Tables and Indexes with an Excessive Number of Columns

    SQLite places no arbitrary limits on the number of columns in a table +or index. There are known commercial applications using SQLite that +construct tables with tens of thousands of columns each. And these +applications actually work.

    However the database engine is +optimized for the common case of tables with no more than a few dozen +columns. For best performance you should try to stay in the optimized +region. Furthermore, we note that relational databases with a large +number of columns are usually not well normalized. So even apart from +performance considerations, if you find your design has tables with +more than a dozen or so columns, you really need to rethink how you +are building your application.

    There are a number of places +in Prepare() that run in time O(N2) where +N is the number of columns in the table. The constant of proportionality +is small in these cases so you should not have any problems for N +of less than one hundred but for N on the order of a thousand, the +time to run Prepare() can start to become noticeable.

    When the bytecode is running and it needs to access the i-th +column of a table, the values of the previous i-1 columns must be +accessed first. So if you have a large number of columns, accessing +the last column can be an expensive operation. This fact also argues +for putting smaller and more frequently accessed columns early in +the table.

    There are certain optimizations that will only +work if the table has 30 or fewer columns. The optimization that extracts +all necessary information from an index and never refers to the underlying +table works this way. So in some cases, keeping the number of columns +in a table at or below 30 can result in a 2-fold speed improvement.

    Indexes will only be used if they contain 30 or fewer columns. +You can put as many columns in an index as you want, but if the number +is greater than 30, the index will never improve performance and will +never do anything but take up space in your database file.

    +     +SQL +Overview +SQL +Server Guide +SQLite + +SQL +DB Overview +Avoid +Transient Tables +Prevent +Datafile Corruption + +SQL Insertion Tips +SQL +Schema Tips +SQL +Expressions +SQL +Statement Tips +SQL +Joins + ANALYZE +Command + SQL +WHERE CLause Tips     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C31DA918-8DEA-5816-B0A6-4AE90B06DD0D_d0e169089_href.jpg Binary file Symbian3/SDK/Source/GUID-C31DA918-8DEA-5816-B0A6-4AE90B06DD0D_d0e169089_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C31DA918-8DEA-5816-B0A6-4AE90B06DD0D_d0e174103_href.jpg Binary file Symbian3/SDK/Source/GUID-C31DA918-8DEA-5816-B0A6-4AE90B06DD0D_d0e174103_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C37790B3-967C-489C-8753-0434938CBE2B.dita --- a/Symbian3/SDK/Source/GUID-C37790B3-967C-489C-8753-0434938CBE2B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C37790B3-967C-489C-8753-0434938CBE2B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,5 +17,5 @@ interface.

    The following figure shows the relationship between applications, secure socket classes, and secure socket plug-ins.

    -Relationship between applications and secure socket +Relationship between applications and secure socket \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C39CA508-86F7-5B99-9390-56980DD0EFFB.dita --- a/Symbian3/SDK/Source/GUID-C39CA508-86F7-5B99-9390-56980DD0EFFB.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,18 +0,0 @@ - - - - - -Lexical conventions

    Resource files obey the following lexical conventions:

    • Whitespace, except when enclosed in quotes for strings, is ignored by the compiler.

    • Both C-style (/* */) and C++-style (//) comments are supported.

    • Strings must be enclosed with double-quotes.

    • To include a double-quote within a string, enter a double-quote preceded by a backslash. The following resource:

      RESOURCE SIMPLE quote_example - { - string="\"text\""; - }

      where string is of type BUF, generates the output string "text".

    • To include a backslash within a string, enter two backslash characters. The following resource:

      RESOURCE SIMPLE backslash_example - { - string="\\text\\"; - }

      generates the output string \text\.

    • You can use the syntax number, to specify a character by character code. If a Unicode resource is being created, this must be a Unicode character value.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3A3D9CF-4826-4BEB-8778-ECD8E6B6463C.dita --- a/Symbian3/SDK/Source/GUID-C3A3D9CF-4826-4BEB-8778-ECD8E6B6463C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C3A3D9CF-4826-4BEB-8778-ECD8E6B6463C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -43,7 +43,7 @@ required.

    The diagrammatic representation of the Image Processor library is as follows:

    The architectural relationship diagram for the Image Processor library

    - +
    Image Processor

    Image Processor is a high-level library and framework. Image Processor encapsulates all the internal processing diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3A8290D-44BA-5AAD-8F0D-745FF3F10E0B_d0e308998_href.png Binary file Symbian3/SDK/Source/GUID-C3A8290D-44BA-5AAD-8F0D-745FF3F10E0B_d0e308998_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3A8290D-44BA-5AAD-8F0D-745FF3F10E0B_d0e315468_href.png Binary file Symbian3/SDK/Source/GUID-C3A8290D-44BA-5AAD-8F0D-745FF3F10E0B_d0e315468_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3B6E5F6-74DC-5C0E-94C8-B4822F4A2EB6.dita --- a/Symbian3/SDK/Source/GUID-C3B6E5F6-74DC-5C0E-94C8-B4822F4A2EB6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C3B6E5F6-74DC-5C0E-94C8-B4822F4A2EB6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -55,9 +55,9 @@ a NewL() function. Call the dedicated function, CHRMPower::SetBatteryChargingObserver().

    Procedure
      -

    1. Derive +

    2. Derive a class from one or more of the above interfaces.

      3. -

    3. Implement +

    4. Implement the appropriate observer functions.

    5. Create a power client using CHWRMPower::NewL() or NewLC().

      You diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3D0BA4A-AEC5-5002-916E-CB3F9FE5AC27_d0e200042_href.png Binary file Symbian3/SDK/Source/GUID-C3D0BA4A-AEC5-5002-916E-CB3F9FE5AC27_d0e200042_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C3D0BA4A-AEC5-5002-916E-CB3F9FE5AC27_d0e205051_href.png Binary file Symbian3/SDK/Source/GUID-C3D0BA4A-AEC5-5002-916E-CB3F9FE5AC27_d0e205051_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C47514B1-2DD2-5E75-962A-B8E6358E9880_d0e244786_href.png Binary file Symbian3/SDK/Source/GUID-C47514B1-2DD2-5E75-962A-B8E6358E9880_d0e244786_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C47514B1-2DD2-5E75-962A-B8E6358E9880_d0e249745_href.png Binary file Symbian3/SDK/Source/GUID-C47514B1-2DD2-5E75-962A-B8E6358E9880_d0e249745_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e58870_href.png Binary file Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e58870_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59013_href.png Binary file Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59013_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59093_href.png Binary file Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59093_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59236_href.png Binary file Symbian3/SDK/Source/GUID-C4805C18-9BE7-47BA-9E50-D5F9CAAD36B7_d0e59236_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4C8395E-F982-4D6A-88D3-28EDC494817F.dita --- a/Symbian3/SDK/Source/GUID-C4C8395E-F982-4D6A-88D3-28EDC494817F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C4C8395E-F982-4D6A-88D3-28EDC494817F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,8 +18,8 @@

      Requesting free RAM asynchronously is recommended as the application is not blocked during the method call handling.

      - -Start an asynchronous + +Start an asynchronous request for a block of memory. CMemoryAllocatingObject::StartFunctionalityRequiringAllocationL() { @@ -29,7 +29,7 @@ } -Implement the active +Implement the active object and request for free memory. void CMemoryRequester::Start(TInt aBytesRequested) { diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4D0B083-CCF9-52BD-A6BC-5187BEF3B0CB_d0e165576_href.png Binary file Symbian3/SDK/Source/GUID-C4D0B083-CCF9-52BD-A6BC-5187BEF3B0CB_d0e165576_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4D0B083-CCF9-52BD-A6BC-5187BEF3B0CB_d0e170590_href.png Binary file Symbian3/SDK/Source/GUID-C4D0B083-CCF9-52BD-A6BC-5187BEF3B0CB_d0e170590_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4D0F943-442D-5F3B-BB5E-6B52C33ABBC6_d0e169146_href.jpg Binary file Symbian3/SDK/Source/GUID-C4D0F943-442D-5F3B-BB5E-6B52C33ABBC6_d0e169146_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4D0F943-442D-5F3B-BB5E-6B52C33ABBC6_d0e174160_href.jpg Binary file Symbian3/SDK/Source/GUID-C4D0F943-442D-5F3B-BB5E-6B52C33ABBC6_d0e174160_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C4E728B4-3E84-49A4-83CB-DF146420D78A.dita --- a/Symbian3/SDK/Source/GUID-C4E728B4-3E84-49A4-83CB-DF146420D78A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C4E728B4-3E84-49A4-83CB-DF146420D78A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ be attached to almost all the items.

      Stylus pop-up menu opened from a list. - +

      Stylus pop-up is mainly used to offer dynamic functions, and the functions supported by touch-enabled devices. The stylus pop-up menu can also be used diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5103B39-6F67-47E3-938A-32933E75F98E.dita --- a/Symbian3/SDK/Source/GUID-C5103B39-6F67-47E3-938A-32933E75F98E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C5103B39-6F67-47E3-938A-32933E75F98E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,25 +1,24 @@ - - - - - -C++ -Standard Library (STLport v4)C++ Standard Library is a Symbian platform port of STLport v4. -It enables applications written using Standard C++ to be ported to Symbian -platform. -

      Notes:

        -

      • It is recommended that you use the latest version of Standard -C++ Library (STLport v5) to take advantage of it's latest features. -For more information about STLport, see http://www.stlport.org/. -For information about how to migrate to STLport v5, see Migrating from STLport v4 -to v5.

        • -

      • For more information about Open C++ (C++ Standard Library - STLport -v4) API reference and examples, see Forum Nokia Library.

        • -

      + + + + + +C++ Standard Library (STLport v4)C++ Standard Library is a Symbian platform port of STLport +v4. It enables applications written using Standard C++ to be ported +to Symbian platform. +

      Notes:

        +

      • It is recommended that you use the latest version of Standard C++ Library +(STLport v5) to take advantage of it's latest features. For +more information about STLport, see http://www.stlport.org/. For information about +how to migrate to STLport v5, see Migrating from STLport +v4 to v5.

        • +

      • For more information about Open C++ (C++ Standard Library - +STLport v4) API reference and examples, see Forum Nokia Library.

        • +

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C549EC51-D81F-5AEC-80EA-EF83B2D9AF51.dita --- a/Symbian3/SDK/Source/GUID-C549EC51-D81F-5AEC-80EA-EF83B2D9AF51.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C549EC51-D81F-5AEC-80EA-EF83B2D9AF51.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,6 +22,6 @@

      The following diagram shows a typical mix of free and allocated cells.

      Example of the allocated and free cells in a heap - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C588B869-6940-42B2-84F9-71467F6A4306_d0e5972_href.png Binary file Symbian3/SDK/Source/GUID-C588B869-6940-42B2-84F9-71467F6A4306_d0e5972_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C588B869-6940-42B2-84F9-71467F6A4306_d0e6093_href.png Binary file Symbian3/SDK/Source/GUID-C588B869-6940-42B2-84F9-71467F6A4306_d0e6093_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5C42C02-1C22-5537-B966-0F5F78E4D7BE_d0e230564_href.png Binary file Symbian3/SDK/Source/GUID-C5C42C02-1C22-5537-B966-0F5F78E4D7BE_d0e230564_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5C42C02-1C22-5537-B966-0F5F78E4D7BE_d0e235544_href.png Binary file Symbian3/SDK/Source/GUID-C5C42C02-1C22-5537-B966-0F5F78E4D7BE_d0e235544_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5DDFD3F-7778-56D6-A10B-741959206C5F_d0e314550_href.png Binary file Symbian3/SDK/Source/GUID-C5DDFD3F-7778-56D6-A10B-741959206C5F_d0e314550_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5DDFD3F-7778-56D6-A10B-741959206C5F_d0e321020_href.png Binary file Symbian3/SDK/Source/GUID-C5DDFD3F-7778-56D6-A10B-741959206C5F_d0e321020_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C5F4CF0F-EC1B-595D-8C95-41891CB5930D.dita --- a/Symbian3/SDK/Source/GUID-C5F4CF0F-EC1B-595D-8C95-41891CB5930D.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -resource

      abld [ test ] resource [-k] [-v] [ platform ] [ build [ program ] ]

      This command builds the resource files, bitmaps and application information files for a component by calling the RESOURCE targets in makefiles generated by makmake.

      These resources are created implicitly when abld - target (and thus, abld build) is called. The resources will not be regenerated if they have later datestamps than their source dependencies.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C6086C67-963B-455F-8BA6-58DC568084F0_d0e67627_href.png Binary file Symbian3/SDK/Source/GUID-C6086C67-963B-455F-8BA6-58DC568084F0_d0e67627_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C60DAE3D-7FB9-5619-9E5D-476A430705AF.dita --- a/Symbian3/SDK/Source/GUID-C60DAE3D-7FB9-5619-9E5D-476A430705AF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C60DAE3D-7FB9-5619-9E5D-476A430705AF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -72,7 +72,7 @@ record

      only. Getting all matches in a database is briefly discussed at the end of this

      section.

    -

    Now that you have +

    Now that you have performed a basic database query you can start thinking about more advanced querying options. The following will show you how:

    • Querying diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C60DC070-572B-5960-B394-550426FDB909.dita --- a/Symbian3/SDK/Source/GUID-C60DC070-572B-5960-B394-550426FDB909.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C60DC070-572B-5960-B394-550426FDB909.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,262 +1,188 @@ - - - - - Advanced Pointer Tutorial -This tutorial provides step-by-step instructions and sample -code to help you write applications using advanced pointers. - - - - -

      Variant: ScreenPlay. Target audience: Application developers.

      -
      Required background

      This topic builds -on the material in the following topics:

        -

      • Advanced Pointer -Overview

        • -

      • Advanced Pointer -States and Event Communication

        • -
      -
      Using advanced pointers

      This topic covers -the following:

        -

      • Enabling multiple pointers for a window

        • -

      • Getting Z coordinates from TPointerEvent

        • -

      • Pinch zooming

        • -
      -
      Enabling -multiple pointers in a window
        -

      1. RWindow provides a handle to a standard window. Call RWindow to create an instance of a window.

        -RWindow window(ws); - -User::LeaveIfError(window.Construct(wg, reinterpret_cast<TUint32>(&wg) + 1)); -
        2. -

      2. Call RWindow::EnableAdvancedPointers() to enable -advanced pointers. Then call RWindowBase::Activate() to display the -window and enable the window to receive events. RWindow inherits from RWindowBase, so you can call the Activate() function -on RWindow.

        -window.EnableAdvancedPointers(); -window.Activate(); -

        When an application needs to receive advanced pointer -events in a window, it must call RWindowBase::EnableAdvancedPointers() for the window before it is activated.

        If advanced -pointers are not enabled for a window, it receives only standard TPointerEvent information from a single pointer with no pressure and proximity -data. The single pointer environment rules describe the way in which -pointer events coming from many pointers in the multiple pointer model -are transformed into events of one pointer. They are necessary to -ensure that old single-pointer applications work in a multiple pointer -environment intuitively and as expected by the user.

        However, the new TPointerEvent types, EEnterCloseProximity, EExitCloseProximity, EEnterHighPressure and EExitHighPressure, are delivered to all -windows, even to those that do not enable advanced pointers.

        3. -
      -
      Getting -Z coordinates from TPointerEvent
        -

      1. Call TPointerEvent::AdvancedPointerEvent() on -a TPointerEvent to return a pointer to a TAdvancedPointerEvent.

        -TZType aZType; -TPointerEvent& aPointerEvent; -TInt* aZ; -TInt* aPoint3D; - -TAdvancedPointerEvent *advancedP = aPointerEvent.AdvancedPointerEvent(); -

        TPointerEvent is a struct that contains -details of a pointer event. TZType is a struct provided -by the programmer containing members to hold proximity, pressure, -and "proximity and pressure" data.

        2. -

      2. Now we need -to test whether the pointer event contains advanced pointer data. -If it is not an advanced pointer, the code leaves.

        If it is -an advanced pointer, we call functions to detect proximity, pressure, -"proximity and pressure" data and coordinates.

        -if(!advancedP) - { - // The TPointerEvent isn't an instance of TAdvancedPointerEvent - User::Leave(KErrArgument); - } - -switch(aZType) - { - case EZTypeProximity: - aZ = advancedP->Proximity(); - aPoint3D = advancedP->Proximity3D(); - break; - case EZTypePressure: - aZ = advancedP->Pressure(); - aPoint3D = advancedP->Pressure3D(); - break; - case EZTypeProximityAndPressure: - aZ = advancedP->ProximityAndPressure(); - aPoint3D = advancedP->ProximityAndPressure3D(); - break; - default: - User::Leave(KErrArgument); - break; - } -
          -

        • TAdvancedPointerEvent::Proximity() returns -the proximity.

          • -

        • TAdvancedPointerEvent::Pressure() returns -the pressure.

          • -

        • TAdvancedPointerEvent::ProximityAndPressure() returns the proximity and pressure combined.

          • -

        • TAdvancedPointerEvent:: Position3D() returns -the proximity and the X, Y and Z coordinates.

          • -

        • TAdvancedPointerEvent::Pressure3D() returns -the pressure and the X and Y coordinates.

          • -

        Proximity is always negative and pressure is always positive. Internally they are combined together as a Z coordinate. -When Z > 0, the proximity is 0 and the Z value represents the pressure. -When Z < 0, the pressure is 0 and the Z value represents the proximity. -Some APIs use only a Z coordinate (such as the threshold getters and -setters and TAdvancedPointerEvent::ProximityAndPressure()). In these, the Z coordinate is interpreted in terms of pressure -and proximity.

        3. -
      - Relationships between the pointer proximity, pressure and -Z coordinate -
      -
      Pinch -zooming

      This example shows an easy way to pinch zoom an -image when the screen receives pointer events from two pointers. There -are two functions in this code that must be implemented by the programmer: BitmapCoordinates() and MoveBitmap(). They -are not included in the example because they involve complex calculations -that are not related to advanced pointers.

      The high-level -steps to perform pinch zooming are:

        -

      1. Define the coordinates, -equivalent to the given on-screen coordinates. In the code example, -this is done using the function BitmapCoordinates().

        2. -

      2. Define the ID -of the pointer by using TAdvancedPointerEvent::PointerNumber(). -If the device can handle two pointers (two fingers) at the same time, -their numbers are 0 and 1. The pointer number enables you to distinguish -a given pointer from other pointers.

        3. -

      3. For each pointer -assign its coordinates to a local variable. We assume there are only -two pointers handled by the system here.

        4. -

      4. Use the MoveBitmap() function to achieve the zoom effect.

        -/** -Receives pointer events from two pointers to perform Pinch Zoom of the image. -Function will finish when EButton1Up is received for any of the pointers. -@param aPointer1 Coordinates of pointer number 1 when zoom is started -@param aPointer2 Coordinates of pointer number 2 when zoom is started -*/ - -void PinchZoom(TPoint aPointer1, TPoint aPointer2) - { - TPoint actualP1 = aPointer1; - TPoint actualP2 = aPointer2; - - // translate on-screen pointer coordinates to coordinates of displayed bitmap - TPoint bitmapCatching1 = BitmapCoordinates(aPointer1); - TPoint bitmapCatching2 = BitmapCoordinates(aPointer2); - - TBool repaint = EFalse; - - while (ETrue) - { - TAdvancedPointerEvent event = GetNextPointerEvent(); - - if (event.iType == TPointerEvent::EDrag) - { - if (event.PointerNumber() == 1) - { - actualP1 = event.iPosition; - repaint = ETrue; - } - else if (event.PointerNumber() == 2) - { - actualP2 = event.iPosition; - repaint = ETrue; - } - } - else if (event.iType == TPointerEvent::EButton1Up) - { - break; - } - - if (repaint) - { - // move bitmap on the screen in the way that - // bitmapCatching1 point of the bitmap will be displayed at actualP1 screen coordinate, - // bitmapCatching2 point of the bitmap will be displayed at actualP2 screen coordinate. - MoveBitmap(bitmapCatching1, actualP1, bitmapCatching2, actualP2); - repaint = EFalse; - } - } - } -
        5. -
      - - -Advanced Pointer Overview -Advanced Pointer States and Event Communication - - - - + + + + + + Advanced Pointer TutorialThis tutorial provides step-by-step instructions and sample +code to help you write applications using advanced pointers. +

      Variant: ScreenPlay. Target audience: Application developers.

      +
      Required background

      This topic builds +on the material in the following topics:

        +

      • Advanced Pointer +Overview

        • +

      • Advanced Pointer +States and Event Communication

        • +
      +
      Using advanced pointers

      This topic covers +the following:

        +

      • Enabling multiple pointers in a window

        • +

      • Getting Z coordinates from TPointerEvent

        • +

      • Pinch zooming

        • +
      +
      Enabling +multiple pointers in a window
        +

      1. RWindow provides +a handle to a standard window. Call RWindow to create +an instance of a window.

        +RWindow window(ws); + +User::LeaveIfError(window.Construct(wg, reinterpret_cast<TUint32>(&wg) + 1)); +
        2. +

      2. Call RWindow::EnableAdvancedPointers() to enable advanced pointers. +Then call RWindowBase::Activate() to display the +window and enable the window to receive events. RWindow inherits from RWindowBase, so you can call the Activate() function on RWindow.

        +window.EnableAdvancedPointers(); +window.Activate(); +

        When an application needs to receive advanced pointer +events in a window, it must call RWindowBase::EnableAdvancedPointers() for the window before it is activated.

        If advanced +pointers are not enabled for a window, it receives only standard TPointerEvent information from a single pointer with no +pressure and proximity data. The single pointer environment rules +describe the way in which pointer events coming from many pointers +in the multiple pointer model are transformed into events of one pointer. +They are necessary to ensure that old single-pointer applications +work in a multiple pointer environment intuitively and +as expected by the user.

        However, the new TPointerEvent types, EEnterCloseProximity, EExitCloseProximity, EEnterHighPressure and EExitHighPressure, are delivered to all windows, even to those that do not enable +advanced pointers.

        3. +
      +
      Getting +Z coordinates from TPointerEvent
        +

      1. Call TPointerEvent::AdvancedPointerEvent() on a TPointerEvent to return a pointer to a TAdvancedPointerEvent.

        +TZType aZType; +TPointerEvent& aPointerEvent; +TInt* aZ; +TInt* aPoint3D; + +TAdvancedPointerEvent *advancedP = aPointerEvent.AdvancedPointerEvent(); +

        TPointerEvent is a struct that contains +details of a pointer event. TZType is a struct provided +by the programmer containing members to hold proximity, pressure, +and "proximity and pressure" data.

        2. +

      2. Now we need +to test whether the pointer event contains advanced pointer data. +If it is not an advanced pointer, the code leaves.

        If it is +an advanced pointer, we call functions to detect proximity, pressure, +"proximity and pressure" data and coordinates.

        +if(!advancedP) + { + // The TPointerEvent isn't an instance of TAdvancedPointerEvent + User::Leave(KErrArgument); + } + +switch(aZType) + { + case EZTypeProximity: + aZ = advancedP->Proximity(); + aPoint3D = advancedP->Proximity3D(); + break; + case EZTypePressure: + aZ = advancedP->Pressure(); + aPoint3D = advancedP->Pressure3D(); + break; + case EZTypeProximityAndPressure: + aZ = advancedP->ProximityAndPressure(); + aPoint3D = advancedP->ProximityAndPressure3D(); + break; + default: + User::Leave(KErrArgument); + break; + } +
          +

        • TAdvancedPointerEvent::Proximity() returns the proximity.

          • +

        • TAdvancedPointerEvent::Pressure() returns the pressure.

          • +

        • TAdvancedPointerEvent::ProximityAndPressure() returns the proximity and pressure combined.

          • +

        • TAdvancedPointerEvent:: +Position3D() returns the proximity and the X, Y and Z coordinates.

          • +

        • TAdvancedPointerEvent::Pressure3D() returns the pressure and the X and Y coordinates.

          • +

        Proximity is always negative and pressure is always positive. Internally they are combined together as a Z coordinate. +When Z > 0, the proximity is 0 and the Z value represents the pressure. +When Z < 0, the pressure is 0 and the Z value represents the proximity. +Some APIs use only a Z coordinate (such as the threshold getters and +setters and TAdvancedPointerEvent::ProximityAndPressure()). In these, the Z coordinate is interpreted in terms of pressure +and proximity.

        3. +
      + Relationships between the pointer proximity, pressure and +Z coordinate + +
      +
      Pinch +zooming

      This example shows an easy way to pinch zoom an +image when the screen receives pointer events from two pointers. There +are two functions in this code that must be implemented by the programmer: BitmapCoordinates() and MoveBitmap(). They +are not included in the example because they involve complex calculations +that are not related to advanced pointers.

      The high-level +steps to perform pinch zooming are:

        +

      1. Define the coordinates, +equivalent to the given on-screen coordinates. In the code example, +this is done using the function BitmapCoordinates().

        2. +

      2. Define the ID +of the pointer by using TAdvancedPointerEvent::PointerNumber(). If the device can handle two pointers (two fingers) at the same +time, their numbers are 0 and 1. The pointer number enables you to +distinguish a given pointer from other pointers.

        3. +

      3. For each pointer +assign its coordinates to a local variable. We assume there are only +two pointers handled by the system here.

        4. +

      4. Use the MoveBitmap() function to achieve the zoom effect.

        +/** +Receives pointer events from two pointers to perform Pinch Zoom of the image. +Function will finish when EButton1Up is received for any of the pointers. +@param aPointer1 Coordinates of pointer number 1 when zoom is started +@param aPointer2 Coordinates of pointer number 2 when zoom is started +*/ + +void PinchZoom(TPoint aPointer1, TPoint aPointer2) + { + TPoint actualP1 = aPointer1; + TPoint actualP2 = aPointer2; + + // translate on-screen pointer coordinates to coordinates of displayed bitmap + TPoint bitmapCatching1 = BitmapCoordinates(aPointer1); + TPoint bitmapCatching2 = BitmapCoordinates(aPointer2); + + TBool repaint = EFalse; + + while (ETrue) + { + TAdvancedPointerEvent event = GetNextPointerEvent(); + + if (event.iType == TPointerEvent::EDrag) + { + if (event.PointerNumber() == 1) + { + actualP1 = event.iPosition; + repaint = ETrue; + } + else if (event.PointerNumber() == 2) + { + actualP2 = event.iPosition; + repaint = ETrue; + } + } + else if (event.iType == TPointerEvent::EButton1Up) + { + break; + } + + if (repaint) + { + // move bitmap on the screen in the way that + // bitmapCatching1 point of the bitmap will be displayed at actualP1 screen coordinate, + // bitmapCatching2 point of the bitmap will be displayed at actualP2 screen coordinate. + MoveBitmap(bitmapCatching1, actualP1, bitmapCatching2, actualP2); + repaint = EFalse; + } + } + } +
        5. +
      +       +Advanced +Pointer Overview +Advanced +Pointer States and Event Communication +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C64D200D-32A9-5F50-ACF1-4D93DDD0B0A4_d0e333524_href.png Binary file Symbian3/SDK/Source/GUID-C64D200D-32A9-5F50-ACF1-4D93DDD0B0A4_d0e333524_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C64D200D-32A9-5F50-ACF1-4D93DDD0B0A4_d0e339990_href.png Binary file Symbian3/SDK/Source/GUID-C64D200D-32A9-5F50-ACF1-4D93DDD0B0A4_d0e339990_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C6DDF01D-DF54-5C65-9FAC-D3693D30819F_d0e268483_href.png Binary file Symbian3/SDK/Source/GUID-C6DDF01D-DF54-5C65-9FAC-D3693D30819F_d0e268483_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C6DDF01D-DF54-5C65-9FAC-D3693D30819F_d0e273338_href.png Binary file Symbian3/SDK/Source/GUID-C6DDF01D-DF54-5C65-9FAC-D3693D30819F_d0e273338_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C6E29524-AD59-4EBB-9004-13F731FA1F3C.dita --- a/Symbian3/SDK/Source/GUID-C6E29524-AD59-4EBB-9004-13F731FA1F3C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C6E29524-AD59-4EBB-9004-13F731FA1F3C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -62,7 +62,7 @@ such as an incoming call, occurs when a menu list is open, the list is cancelled and the new event takes control.

      Menu list - +

      The API to use for menu lists is the Lists API. For implementation information, see Using the Lists API.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C71311A7-F747-57EB-B31F-6E634D5976A3.dita --- a/Symbian3/SDK/Source/GUID-C71311A7-F747-57EB-B31F-6E634D5976A3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C71311A7-F747-57EB-B31F-6E634D5976A3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ Device creators can write additional plug-in converters by implementing the CCharacterSetConverterPluginInterface interface.

    Charconv Framework collection - +

    Using the Character Conversion Framework

    Application developers can use the Charconv API to convert text between various encodings diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C7560CDB-E8F4-55E8-953C-3731B690CF76_d0e272103_href.jpg Binary file Symbian3/SDK/Source/GUID-C7560CDB-E8F4-55E8-953C-3731B690CF76_d0e272103_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C7560CDB-E8F4-55E8-953C-3731B690CF76_d0e276949_href.jpg Binary file Symbian3/SDK/Source/GUID-C7560CDB-E8F4-55E8-953C-3731B690CF76_d0e276949_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C75726D3-E815-503D-8267-26DA27AD4787.dita --- a/Symbian3/SDK/Source/GUID-C75726D3-E815-503D-8267-26DA27AD4787.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C75726D3-E815-503D-8267-26DA27AD4787.dita Tue Jul 20 12:00:49 2010 +0100 @@ -57,7 +57,7 @@ The color of the boxes indicates the type of Symbian class, that is, M, C, R or T class. For detailed information on each component see the Cryptography API Reference material.

    The inheritance diagram above shows the <codeph>TInteger</codeph> and <codeph>RInteger</codeph> classes. - +

    RInteger class

    RInteger is a TInteger derived class allowing the construction of variable length big integers.

    This class follows standard R class diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C762E5B4-A7E3-5CAD-B639-A31F5D1899D3.dita --- a/Symbian3/SDK/Source/GUID-C762E5B4-A7E3-5CAD-B639-A31F5D1899D3.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Overview of DLL building

    Building a DLL target generates two files:

    • The compiled DLL binary: this file contains the executable code that is called at run-time. It often has the extension .DLL, though some DLLs have extensions that indicate their particular purpose, e.g. .ANI for animation DLLs.

    • Import library: represents the exported interface of the DLL. This allows other programs to use the DLL, by linking against the import library at build time.

      Import libraries have the extension .lib in the Symbian emulator and ARM ABIv1 builds, or .dso in the ARM ABIv2 builds.

    Other programs can use DLLs in two ways:

    • By linking against them at build time, using the interface defined in a C++ header file, and in the DLL's import library.

      DLLs designed to be used in this way are called static interface DLLs.

    • By using an API to dynamically load and call the DLL at run-time. DLLs designed to be used in this way are called polymorphic interface DLLs.

      See Frameworks, libraries and DLLs for more on this idiom, and Dynamically Loading Link Libraries API for details of the API.

    The following pages discuss the special configuration issues associated with building for DLL targets.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C7C5F7B8-F024-57F0-968B-1839E1E07DAA.dita --- a/Symbian3/SDK/Source/GUID-C7C5F7B8-F024-57F0-968B-1839E1E07DAA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C7C5F7B8-F024-57F0-968B-1839E1E07DAA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,8 @@ Overview which is based around code snippets taken from the example.

    Download

    Click on the following link to download the example: BmpAnimGui.zip

    Click: browse to view the example code.

    -
    Class Summary
      +
      Class +Summary

      • CFbsBitmapNote

      • CBitmapFrameDataEncapsulates

      • CBitmapAnimClientDataEncapsulates

        • @@ -32,8 +33,7 @@ use the command line, open a command prompt, and set the current directory to the source code directory of the example. You can then build the example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld -build

        How to use bldmake and How to -use abld describe how to use the SBSv1 build tools.

        +build

      • For the emulator, the example builds an executable called bmpanimgui.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C7D026AF-9C07-4221-AEDE-8CC0654A9D57.dita --- a/Symbian3/SDK/Source/GUID-C7D026AF-9C07-4221-AEDE-8CC0654A9D57.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C7D026AF-9C07-4221-AEDE-8CC0654A9D57.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ that have one.

      Text selection in an editor - +

      If the user presses an Arrow key alone when there is a text selection, the selection disappears and the cursor reappears in the respective position.

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C7F900F4-7C8E-4922-8785-D6EF9AE23B22.dita --- a/Symbian3/SDK/Source/GUID-C7F900F4-7C8E-4922-8785-D6EF9AE23B22.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C7F900F4-7C8E-4922-8785-D6EF9AE23B22.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,9 +17,9 @@ first touch down and release only checks or unchecks the item. Touch down and release second time activates the item and the pop-up closes.

      - + -
    The default touch +<table id="GUID-4F77253E-5688-4642-98DD-04CB7FCF38E1-GENID-1-10-1-7-1-1-5-1-15-1-3-1-2-3"><title>The default touch events for list selection item diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C85EECD6-2CFD-5BA9-A60B-F7AF3A74E832.dita --- a/Symbian3/SDK/Source/GUID-C85EECD6-2CFD-5BA9-A60B-F7AF3A74E832.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C85EECD6-2CFD-5BA9-A60B-F7AF3A74E832.dita Tue Jul 20 12:00:49 2010 +0100 @@ -62,9 +62,9 @@

  • RBuf::Swap(RBuf8&)

    • Copying data to an RBuf using the assignment operator

    The example -creates two resizable buffers and allocates memory using RBuf::Create(const TDesC8&). It then copies -data to these buffers. It also copies data from the first buffer to -the second buffer using the assignment operator.

    Notes:

      +creates two resizable buffers and allocates memory using RBuf::Create(const TDesC8&). It then copies data to +these buffers. It also copies data from the first buffer to the second +buffer using the assignment operator.

      Notes:

      • When you use RBuf::Assign(const RBuf8&), ownership of the buffer is transferred. Assign(const RBuf8&) neither checks nor frees any pre-existing owned allocated memory. If this @@ -108,9 +108,7 @@ a stream from a file.

      • RFs

      -
      Build

      The Symbian -build process describes how to build this example application. -The example builds an executable file called rbufexample.exe in the standard location (\epoc32\release\winscw\<build_variant> for the emulator). After launching the executable, depending on +

      Build

      The example builds an executable file called rbufexample.exe in the standard location (\epoc32\release\winscw\<build_variant> for the emulator). After launching the executable, depending on the emulator you are using, you may need to navigate away from the application launcher/shell screen to view the console.

      See diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8938826-52F7-5040-B59C-3C06DAEB6F03_d0e134273_href.jpg Binary file Symbian3/SDK/Source/GUID-C8938826-52F7-5040-B59C-3C06DAEB6F03_d0e134273_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8938826-52F7-5040-B59C-3C06DAEB6F03_d0e137877_href.jpg Binary file Symbian3/SDK/Source/GUID-C8938826-52F7-5040-B59C-3C06DAEB6F03_d0e137877_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8C804F9-860D-590D-B247-FBB1714604B7_d0e185271_href.png Binary file Symbian3/SDK/Source/GUID-C8C804F9-860D-590D-B247-FBB1714604B7_d0e185271_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8C804F9-860D-590D-B247-FBB1714604B7_d0e190268_href.png Binary file Symbian3/SDK/Source/GUID-C8C804F9-860D-590D-B247-FBB1714604B7_d0e190268_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8D04D54-D391-5505-9E80-596589410179_d0e333754_href.png Binary file Symbian3/SDK/Source/GUID-C8D04D54-D391-5505-9E80-596589410179_d0e333754_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8D04D54-D391-5505-9E80-596589410179_d0e340220_href.png Binary file Symbian3/SDK/Source/GUID-C8D04D54-D391-5505-9E80-596589410179_d0e340220_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8D5B104-3F34-513B-BA08-5F2FEE60265C_d0e8346_href.png Binary file Symbian3/SDK/Source/GUID-C8D5B104-3F34-513B-BA08-5F2FEE60265C_d0e8346_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C8D5B104-3F34-513B-BA08-5F2FEE60265C_d0e8468_href.png Binary file Symbian3/SDK/Source/GUID-C8D5B104-3F34-513B-BA08-5F2FEE60265C_d0e8468_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C9429505-EEE7-4E64-BE0A-BC5D57D5B42C_d0e37243_href.png Binary file Symbian3/SDK/Source/GUID-C9429505-EEE7-4E64-BE0A-BC5D57D5B42C_d0e37243_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C9429505-EEE7-4E64-BE0A-BC5D57D5B42C_d0e37411_href.png Binary file Symbian3/SDK/Source/GUID-C9429505-EEE7-4E64-BE0A-BC5D57D5B42C_d0e37411_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C99BA704-4E9F-482C-942F-1B4D7F385BD8.dita --- a/Symbian3/SDK/Source/GUID-C99BA704-4E9F-482C-942F-1B4D7F385BD8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C99BA704-4E9F-482C-942F-1B4D7F385BD8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,77 +1,76 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> -<!-- This component and the accompanying materials are made available under the terms of the License -"Eclipse Public License v1.0" which accompanies this distribution, -and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> -<!-- Initial Contributors: - Nokia Corporation - initial contribution. -Contributors: ---> -<!DOCTYPE concept - PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept id="GUID-C99BA704-4E9F-482C-942F-1B4D7F385BD8" xml:lang="en"><title>HelloWorldBasic_reg.rss -

      You need to register your applications in order to make them visible -to the application launcher and to provide other information to the underlying -system. To register, you need to provide a registration resource file, typically -named <application_name>_reg.rss, that contains the -non-localized information for your application. This section contains an example -of such a file.

      -

      For more information on registration files in general, see Registration.

      -

      For information on creating your own registration resource files, see Creating -registration resource files.

      -#include "Helloworldbasic.rls" - -

      This pre-processor statement adds the rls project -file that controls the strings loaded for different languages based on the -Symbian platform language setting to the preprocessing path. For more information -on localization, see Internationalization -and localization.

      -#include <appinfo.rh> - -

      This preprocessor statement adds the resource header file that provides -the data structure used for the RESOURCE statement in -this registration resource file.

      -#include <HelloWorldBasic.rsg> - - -

      This preprocessor statement adds the generated resource header file -for the HelloWorldBasic application to the preprocessor path to allow -access to the R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO resource.

      -UID2 KUidAppRegistrationResourceFile - -

      This required statement defines the UID2 value for a registration resource -file.

      -UID3 0xA000017F - - -

      This required statement defines the UID3 of -the application.

      -RESOURCE APP_REGISTRATION_INFO - { - app_file="HelloWorldBasic"; - localisable_resource_file = STRING_r_helloworldbasic_loc_resource_file_1; - localisable_resource_id = R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO; - - embeddability=KAppNotEmbeddable; - newfile=KAppDoesNotSupportNewFile; - } - - -

      This RESOURCE definition contains the non-localizable -properties of the HelloWorldBasic application, where

      -
        -

      • HelloWorldBasic is the name of the application -executable

        • -

      • STRING_r_helloworldbasic_loc_resource_file_1 contains -the value \\resource\\apps\\HelloWorldBasic in all rls files. -This is the location of the HelloWorldBasic resource files.

        -
        • -

      • R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO is -the identifier for the resource declared in helloworldbasic.rss that -contains the short caption, caption, and icon information

        • -

      • KAppNotEmbeddable indicates that HelloWorldBasic is -not embeddable

        • -

      • KAppDoesNotSupportNewFile indicates -that HelloWorldBasic does not support new files

        • -
      + + + + + +HelloWorldBasic_reg.rss +

      You need to register your applications in order to make them visible +to the application launcher and to provide other information to the underlying +system. To register, you need to provide a registration resource file, typically +named <application_name>_reg.rss, that contains the +non-localized information for your application. This section contains an example +of such a file.

      +

      For more information on registration files in general, see Registration.

      +

      For information on creating your own registration resource files, see Creating registration resource files.

      +#include "Helloworldbasic.rls" + +

      This pre-processor statement adds the rls project +file that controls the strings loaded for different languages based on the +Symbian platform language setting to the preprocessing path. For more information +on localization, see Internationalization +and localization.

      +#include <appinfo.rh> + +

      This preprocessor statement adds the resource header file that provides +the data structure used for the RESOURCE statement in +this registration resource file.

      +#include <HelloWorldBasic.rsg> + + +

      This preprocessor statement adds the generated resource header file +for the HelloWorldBasic application to the preprocessor path to allow +access to the R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO resource.

      +UID2 KUidAppRegistrationResourceFile + +

      This required statement defines the UID2 value for a registration resource +file.

      +UID3 0xA000017F + + +

      This required statement defines the UID3 of +the application.

      +RESOURCE APP_REGISTRATION_INFO + { + app_file="HelloWorldBasic"; + localisable_resource_file = STRING_r_helloworldbasic_loc_resource_file_1; + localisable_resource_id = R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO; + + embeddability=KAppNotEmbeddable; + newfile=KAppDoesNotSupportNewFile; + } + + +

      This RESOURCE definition contains the non-localizable +properties of the HelloWorldBasic application, where

      +
        +

      • HelloWorldBasic is the name of the application +executable

        • +

      • STRING_r_helloworldbasic_loc_resource_file_1 contains +the value \\resource\\apps\\HelloWorldBasic in all rls files. +This is the location of the HelloWorldBasic resource files.

        +
        • +

      • R_HELLOWORLDBASIC_LOCALISABLE_APP_INFO is +the identifier for the resource declared in helloworldbasic.rss that +contains the short caption, caption, and icon information

        • +

      • KAppNotEmbeddable indicates that HelloWorldBasic is +not embeddable

        • +

      • KAppDoesNotSupportNewFile indicates +that HelloWorldBasic does not support new files

        • +
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-C9BEF1C4-F14A-5386-9DA8-29358694D7AA.dita --- a/Symbian3/SDK/Source/GUID-C9BEF1C4-F14A-5386-9DA8-29358694D7AA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-C9BEF1C4-F14A-5386-9DA8-29358694D7AA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,32 +1,29 @@ - - - - - -CClasses: -typical ‘C’ class -
      Description

      This shows a typical ‘C’ class, derived -from CBase, and highlights the use of two phase construction -and use of the cleanup stack to implement the complete construction of an -instance of that class on the heap.

      -
      Download

      Click on the following link to download -the example: CClasses.zip

      Click on the following link to -download additional files: CommonFramework.zip.

      Click browse CClasses to view the example code.

      Click browse CommonFramework to view additional -files.

      -
      Class summary

      CBase CleanupStack

      -
      Build

      The example source code includes the two -project files needed for building: bld.inf and the .mmp file.

      The Symbian platform build -process describes how to build this application, which results in an -executable called:

      \epoc32\release\<target>\<urel -or udeb>\CCLASSES.EXE.

      -
      Usage

      Run the executable CCLASSES.EXE.

      Executables -for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

      + + + + + +CClasses: typical ‘C’ class +
      Description

      This shows a typical ‘C’ class, +derived from CBase, and highlights the use of two +phase construction and use of the cleanup stack to implement the complete +construction of an instance of that class on the heap.

      +
      Download

      Click on the following link to +download the example: CClasses.zip

      Click on the following +link to download additional files: CommonFramework.zip.

      Click browse CClasses to view the example code.

      Click browse CommonFramework to view additional files.

      +
      Class summary

      CBase CleanupStack

      +
      Build

      The example source code includes +the two project files needed for building: bld.inf and the .mmp file.

      The Symbian platform +build process describes how to build this application, which results +in an executable called:

      \epoc32\release\<target>\<urel +or udeb>\CCLASSES.EXE.

      +
      Usage

      Run the executable CCLASSES.EXE.

      Executables for the emulator targets wins and winscw can be run on your PC. Executables +for ARM targets must be copied to your target platform before being +run.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CA1CE18E-DB40-5608-BE09-3767FB094AB2_d0e432235_href.png Binary file Symbian3/SDK/Source/GUID-CA1CE18E-DB40-5608-BE09-3767FB094AB2_d0e432235_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CA1CE18E-DB40-5608-BE09-3767FB094AB2_d0e436035_href.png Binary file Symbian3/SDK/Source/GUID-CA1CE18E-DB40-5608-BE09-3767FB094AB2_d0e436035_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CA2AACD9-A99D-4C34-80AF-C1B61AC9331F.dita --- a/Symbian3/SDK/Source/GUID-CA2AACD9-A99D-4C34-80AF-C1B61AC9331F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CA2AACD9-A99D-4C34-80AF-C1B61AC9331F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,9 +15,9 @@ pane is with touch.

      Clock pane - + -
    Default +<table id="GUID-D5917E40-42B1-461B-8722-C7AD66482078-GENID-1-10-1-7-1-1-5-1-21-1-1-4-1-5-1-3-3"><title>Default touch events for clock pane diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CA7B2B53-B0DD-4830-90CF-15FD101C66F1_d0e40313_href.png Binary file Symbian3/SDK/Source/GUID-CA7B2B53-B0DD-4830-90CF-15FD101C66F1_d0e40313_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CA7B2B53-B0DD-4830-90CF-15FD101C66F1_d0e40471_href.png Binary file Symbian3/SDK/Source/GUID-CA7B2B53-B0DD-4830-90CF-15FD101C66F1_d0e40471_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CAB2A21A-B2EE-4B49-AC97-7F70BDC95755_d0e2687_href.png Binary file Symbian3/SDK/Source/GUID-CAB2A21A-B2EE-4B49-AC97-7F70BDC95755_d0e2687_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CAB2A21A-B2EE-4B49-AC97-7F70BDC95755_d0e2691_href.png Binary file Symbian3/SDK/Source/GUID-CAB2A21A-B2EE-4B49-AC97-7F70BDC95755_d0e2691_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CAB30473-7829-5F2E-9F45-A2344DEDFC35_d0e250496_href.jpg Binary file Symbian3/SDK/Source/GUID-CAB30473-7829-5F2E-9F45-A2344DEDFC35_d0e250496_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CAB30473-7829-5F2E-9F45-A2344DEDFC35_d0e255432_href.jpg Binary file Symbian3/SDK/Source/GUID-CAB30473-7829-5F2E-9F45-A2344DEDFC35_d0e255432_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CAC07A47-1475-5152-83AA-E59FD3AFF321.dita --- a/Symbian3/SDK/Source/GUID-CAC07A47-1475-5152-83AA-E59FD3AFF321.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,421 +0,0 @@ - - - - - -elf2e32 -command syntax -
    Overview

    The elf2e32 tool's -primary function is to create executables (DLLs and EXEs) in the format required -by Symbian platform, known as the E32Image format. The tool takes as input, -the executables produced by a compiler in the standard Executable and Linking -Format (ELF), and Symbian platform-specific options specified as command-line -arguments to the tool. The tool is located in at epoc32\tools\elf2e32.exe.

    Invocation -syntax

    elf2e32 [--capability=<capabilities>] [--compressionmethod - [none | inflate | bytepair]] [--debuggable] [--dlldata] - [--definput=<file-path>] [--defoutput=<file-path>] [--dso=<file-path>] -[--dump=<dump-options>] [--e32input=<file-path>] [--elfinput=<file-path>] -[--fixedaddress] [--heap=<committed-size>[,<reserved-size>]] -[--help] [--libpath=<search-paths>] [--linkas=<name>] [--namedlookup] - [--noexportlibrary] [--output=<file-path>] [--sid=<secure-ID>] - [--stack=<size>] [--sysdef=<ordinal-number>,<symbol>] - [--targettype=<target-type>] [--uid1=<UID>] [--uid2=<UID>] - [--uid3=<UID>] [--uncompressed]

    -
    Options
    - - - -

    Option

    -

    Description

    -     - -

    capability=<capabilities>

    -

    Platform security capabilities to be assigned to the executable.

    Capabilities -can be specified by name using the set of identifiers used in mmp files, i.e.: TCB, CommDD, PowerMgmt, MultimediaDD, ReadDeviceData, WriteDeviceData, DRM, TrustedUI, ProtServ, DiskAdmin, NetworkControl, AllFiles, SwEvent, NetworkServices, LocalServices, ReadUserData, WriteUserData, Location, SurroundingsDD, and UserEnvironment.

    Multiple -capabilities can be specified using "+" as a separator. For example:

    --capability=LocalServices+ReadDeviceData+ReadUserData

    The -special capability name ALL can be used to represent all -capabilities supported by the current version of Symbian platform. This can -also be used together with capability names prefixed with a '-' to indicate -which capabilities to exclude. For example:

    --capability=ALL-TCB-TrustedUI

    The default is no capabilities though the word NONE can -be used explicitly.

    -     - -

    debuggable

    -

    Specifies that the application can be debugged using the run-mode -debug subsystem. Only executables (EXEs and EXEXPs) can be specified as debuggable.

    -     - -

    definput=<file-path>

    -

    Input DEF file.

    This is used to specify a DEF file when -constructing a DLL and/or import library.

    -     - -

    defoutput=<file-path>

    -

    Output DEF file.

    Specifies a DEF file to be constructed -by the tool.

    -     - -

    dlldata

    -

    Allow writable static data in the DLL.

    The default is that -a DLL may not have writable static data. For more information, see Static -data.

    -     - -

    dso=<file-path>

    -

    Output DSO (or library) file.

    Specifies the LIB file to -be constructed by the tool.

    -     - -

    dump=<dump-options>

    -

    Used to specify the information generated when the e32input option -is used. The sections to include are specified as follows:

      -

    • h: -Header

      • -

    • s: -Security information

      • -

    • c: -Code section

      • -

    • d: -Data section

      • -

    • e: -Export information

      • -

    • I: -Import table

      • -
     -     - -

    e32input=<file-path>

    -

    Dumps a description of the specified E32Image file to standard output. -The output describes the executable's properties such as its header, its imports -and exports, and the contents of its code and data sections. Output options -are specified using the --dump parameter.

    -     - -

    elfinput=<file-path>

    -

    Input ELF file.

    Specifies a compiler-generated executable -in ELF format to be converted into E32Image format by the tool.

    -     - -

    fixedaddress

    -

    Indicates that the process must have a fixed address.

    See Fixed processes for -more information.

    The default is no fixed address.

    -     - -

    heap=<committed-size>[,<reserved-size>]

    -

    The committed size and reserved size of the heap for the process, -specified in bytes.

    The first value given is the committed size, followed -by the reserved size which is optional.

    The default committed size -is 0x1000 and the default reserved size is 0x100000.

    See Memory -Management concepts for more information.

    -     - -

    help

    -

    Displays help text for the tool.

    -     - -

    libpath=<search-paths>

    -

    A semi-colon separated list of search paths that the tool should -use to locate import libraries.

    -     - -

    linkas=<name>

    -

    The internal name used in the image file for the executable. This -can include information that specifies the executable version (in braces) -and the UID3 (in square brackets). For example, foo{00020001}[10011235].exe, -would be used for an executable foo.exe, at version 2.1, -with UID3 0x10011235.

    -     - -

    log=<file-path>

    -

    Redirects console log messages to the specified file

    -     - -

    compressionmethod [none | inflate | bytepair]

    -

    The compression method to be used to compress the files. The tool -uses the inflate method by default.

    The following -compression methods can be used:

    - - - -

    none

    -

    The files are not compressed. This is equivalent to using the uncompressed keyword.

    Note: -The uncompressed keyword, when specified, takes precedence -over any compressionmethod.

    -     - -

    inflate

    -

    Compresses executable files using the default (Deflate, Huffman+LZ77) -algorithm.

    -     - -

    bytepair

    -

    Compresses executable files using the bytepair algorithm. Bytepair -compression allows faster decompression than the default Deflate, Huffman+LZ77 -algorithm and supports demand paging by performing compression and decompression -of code in independent 4KB pages.

    -     - - -

    - - -

    namedlookup

    -

    Enables symbol lookup by name using the dlsym Open Group API. This option has an impact on -the binary size as Symbian platform binaries do not include symbol information -by default.

    Note: If the tool is invoked by the Symbian platform -build toolchain, symbol lookup is enabled for the STDEXE and STDDLL target -types only. To enable symbol lookup for other target types, the tool must -be invoked independently.

    -     - -

    noexportlibrary

    -

    Suppress implicit exports.

    As part of the library exports, -the RVCT tools generate items not marked as EXPORT_C in the -source code. These include Virtual Table and Run-time Type Information entries. -Specifying this option causes the tool not to include these exports.

    For -background information, see cedar\generic\tools\documentation\Migrating_from_RVCT21_build_328_to_build_416_v1.0.doc.

    The default is to include these items generated by RVCT.

    -     - -

    output=<file-path>

    -

    Output E32 image file name.

    -     - -

    sid=<secure-ID>

    -

    Secure ID (SID) of the executable.

    An SID identifies an -executable uniquely on a phone. This allows service providers such as servers -to make security checks on the basis of the executable making the request.

    -     - -

    stack=<size>

    -

    Specifies the stack size for a process in bytes.

    The default -is 0.

    -     - -

    sysdef=<ordinal-number>, <symbol>

    -

    This option forces the specified symbol to be exported at the specified -ordinal position.

    This is required for some target types (polymorphic -DLLs).

    -     - -

    targettype=<target-type>

    -

    Target type. The vaild types are as specified by the mmp targettype keyword.

    If elfinput is specified and there is no targettype, -a Custom -target is assumed.

    An IMPLIB target is assumed -if --elfinput is not specified and -deffilein is -specified.

    -     - -

    uid1=<UID>

    -

    UID 1 value for output executable.

    -     - -

    uid2=<UID>

    -

    UID 2 value for output executable.

    The default is 0.

    -     - -

    uid3=<UID>

    -

    UID 3 value for output executable.

    The default is 0.

    -     - -

    uncompressed

    -

    Specifies that the target executable must not be compressed.

    By -default, the target executable is compressed.

    -     - -

    unfrozen

    -

    Specifies that the input DEF file (specified with --definput) -is not treated as frozen. This means that the tool will not report errors -if the executable does not contain symbols that are specified in the DEF file.

    -     - -

    vid

    -

    Vendor ID (VID) of the executable.

    A VID allows service -providers such as servers to make security checks on the basis of the supplier -of the executable making the request.

    -     - - -

    The following table specifies whether an option is required, optional -or not applicable (N/A) for the main use cases of the tool (namely creating -DLLs, EXEs, EXEs with exports (EXEXP target), and import libraries (IMPLIB -target)).

    - - - -

    Option

    -

    DLL (static/polymorphic)

    -

    EXE

    -

    EXEXP

    -

    IMPORT LIB

    -     - -

    capability

    -

    optional

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    debuggable

    -

    N/A

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    dlldata

    -

    optional

    -

    N/A

    -

    N/A

    -

    N/A

    -     - -

    definput

    -

    optional

    -

    N/A

    -

    optional

    -

    required

    -     - -

    defoutput

    -

    required

    -

    N/A

    -

    required

    -

    N/A

    -     - -

    dso

    -

    required

    -

    N/A

    -

    required

    -

    required

    -     - -

    elfinput

    -

    required

    -

    required

    -

    required

    -

    N/A

    -     - -

    fixedaddress

    -

    N/A

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    heap

    -

    N/A

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    libpath

    -

    optional

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    linkas

    -

    required

    -

    required

    -

    required

    -

    required

    -     - -

    noexportlibrary

    -

    optional

    -

    N/A

    -

    optional

    -

    N/A

    -     - -

    output

    -

    required

    -

    required

    -

    required

    -

    N/A

    -     - -

    sid

    -

    required

    -

    required

    -

    required

    -

    N/A

    -     - -

    stack

    -

    N/A

    -

    optional

    -

    optional

    -

    no

    -     - -

    sysdef

    -

    Required for polymorphic DLL target types only

    -

    N/A

    -

    N/A

    -

    N/A

    -     - -

    targettype

    -

    DLL, or polymorphic DLL target type

    -

    EXE

    -

    EXEXP

    -

    IMPLIB

    -     - -

    uid1

    -

    required

    -

    required

    -

    required

    -

    N/A

    -     - -

    uid2

    -

    optional

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    uid3

    -

    optional

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    uncompressed

    -

    optional

    -

    optional

    -

    optional

    -

    N/A

    -     - -

    unfrozen

    -

    optional

    -

    N/A

    -

    optional

    -

    N/A

    -     - -

    vid

    -

    required

    -

    required

    -

    required

    -

    N/A

    -     - - -
    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CADAFAF2-24E9-5007-9C2F-5453E8062074.dita --- a/Symbian3/SDK/Source/GUID-CADAFAF2-24E9-5007-9C2F-5453E8062074.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CADAFAF2-24E9-5007-9C2F-5453E8062074.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ audio resources, initialization and configuration of hardware devices, and playing and recording audio. -
    Required background

    Before +

    Required background

    Before you start, you must:

    • Understand the A3F DevSound Component to which the DevSound library belongs.

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CB163645-CB5E-4DB5-9830-B97D12FDCBF5.dita --- a/Symbian3/SDK/Source/GUID-CB163645-CB5E-4DB5-9830-B97D12FDCBF5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CB163645-CB5E-4DB5-9830-B97D12FDCBF5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ In this case it is fixed in the layout.

      Volume control UI component - + Default touch events for volume pop-up diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CB3FC449-7994-5510-BD78-F1638CD48A9D.dita --- a/Symbian3/SDK/Source/GUID-CB3FC449-7994-5510-BD78-F1638CD48A9D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CB3FC449-7994-5510-BD78-F1638CD48A9D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -87,7 +87,7 @@ it is not recommended.

      If required, the client can disable a profile. The client can then delete the CSIPProfile object.

      The following illustration shows the SDP Profile API class structure.

      - +
      Memory used

      The amount of memory used by a profile depends on its content. A normal usage diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CB4E1B33-470F-581A-BC32-99752C2A0DFE_d0e323040_href.jpg Binary file Symbian3/SDK/Source/GUID-CB4E1B33-470F-581A-BC32-99752C2A0DFE_d0e323040_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CB4E1B33-470F-581A-BC32-99752C2A0DFE_d0e329510_href.jpg Binary file Symbian3/SDK/Source/GUID-CB4E1B33-470F-581A-BC32-99752C2A0DFE_d0e329510_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CB548959-A1D6-4585-B8E3-B09E37E0CB43.dita --- a/Symbian3/SDK/Source/GUID-CB548959-A1D6-4585-B8E3-B09E37E0CB43.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CB548959-A1D6-4585-B8E3-B09E37E0CB43.dita Tue Jul 20 12:00:49 2010 +0100 @@ -32,7 +32,7 @@ but application can decide to disable it.

      Two row list in stretched mode in landscape layout - +
      Using list layouts in applications

      The API to use for lists is the Lists API. For implementation information, see Using the Lists API.

      For grids, the APIs to use diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBB00F6A-CBA7-4872-B0A1-A86A863725F5.dita --- a/Symbian3/SDK/Source/GUID-CBB00F6A-CBA7-4872-B0A1-A86A863725F5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CBB00F6A-CBA7-4872-B0A1-A86A863725F5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,43 +1,39 @@ - - - - - -Precompiled -resource values available from the Symbian platform -

      The Symbian platform provides a generated resource header file that -contains symbolic IDs to resources in the Symbian platform for use in your -code. The file with the symbolic IDs is the avkon.rsg file -and it is in the ./epoc32/include folder. The file contains -commonly used resource structures for your resource file declarations.

      -

      A common example is the R_AVKON_SOFTKEYS_OPTIONS_EXIT symbolic -ID, which maps to the CBA resource that results in the -softkeys Options and Exit. The Options softkey -is bound to a command that results in the application framework opening the -options menu based on the MENU_PANE resource. The Exit softkey -returns the EAknSoftkeyExit command, which would need -to be handled in the appropriate place for command -handling in your application architecture.

      - -

      The Symbian platform enumerations are in the avkon.hrh file, -which is in the /epoc32/include folder.

      -       -

      In general, you can map the commands returned from the CBA options by -comparing the names of the symbolic IDs to the symbolic names in the enumerated -list.

      -

      Other symbolic IDs for other purposes are also available in the avkon.rsg file.

      -

      When the precompiled resources fit the needs of your application, you -can use them to access already existing resource structures.

      -

      For examples of how these symbolic IDs are used, see

      -
        -

      • Using -precompiled CBA button resources

        -
        • -
      + + + + + +Precompiled resource values available from the Symbian platform +

      The Symbian platform provides a generated resource header file +that contains symbolic IDs to resources in the Symbian platform for +use in your code. The file with the symbolic IDs is the avkon.rsg file and it is in the ./epoc32/include folder. The file contains commonly used resource structures for +your resource file declarations.

      +

      A common example is the R_AVKON_SOFTKEYS_OPTIONS_EXIT symbolic ID, which maps to the CBA resource +that results in the softkeys Options and Exit. The Options softkey is bound +to a command that results in the application framework opening the +options menu based on the MENU_PANE resource. +The Exit softkey returns the EAknSoftkeyExit command, which would need to be handled in the appropriate place +for command +handling in your application architecture.

      + +

      The Symbian platform enumerations are in the avkon.hrh file, which is in the /epoc32/include folder.

      +       +

      In general, you can map the commands returned from the CBA options +by comparing the names of the symbolic IDs to the symbolic names in +the enumerated list.

      +

      Other symbolic IDs for other purposes are also available in +the avkon.rsg file.

      +

      When the precompiled resources fit the needs of your application, +you can use them to access already existing resource structures.

      +

      For examples of how these symbolic IDs are used, see

      +
        +

      • Using +precompiled CBA button resources

        • +
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBD78250-3EF4-5DF0-B356-19996E15BBBD_d0e172711_href.png Binary file Symbian3/SDK/Source/GUID-CBD78250-3EF4-5DF0-B356-19996E15BBBD_d0e172711_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBD78250-3EF4-5DF0-B356-19996E15BBBD_d0e177724_href.png Binary file Symbian3/SDK/Source/GUID-CBD78250-3EF4-5DF0-B356-19996E15BBBD_d0e177724_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4697_href.png Binary file Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4697_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4818_href.png Binary file Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4818_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4823_href.png Binary file Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4823_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4941_href.png Binary file Symbian3/SDK/Source/GUID-CBE1CE3A-5C8B-475D-9F5E-8ACD839EB7E6_d0e4941_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBF1D046-92D4-5936-9946-71BB8FC51AB2_d0e205483_href.png Binary file Symbian3/SDK/Source/GUID-CBF1D046-92D4-5936-9946-71BB8FC51AB2_d0e205483_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CBF1D046-92D4-5936-9946-71BB8FC51AB2_d0e210490_href.png Binary file Symbian3/SDK/Source/GUID-CBF1D046-92D4-5936-9946-71BB8FC51AB2_d0e210490_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CC4CA423-0A14-457C-8CBE-4A9F0E8D0B96_d0e36616_href.png Binary file Symbian3/SDK/Source/GUID-CC4CA423-0A14-457C-8CBE-4A9F0E8D0B96_d0e36616_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CC4CA423-0A14-457C-8CBE-4A9F0E8D0B96_d0e36784_href.png Binary file Symbian3/SDK/Source/GUID-CC4CA423-0A14-457C-8CBE-4A9F0E8D0B96_d0e36784_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCC5BE18-E90D-4B81-AE6F-333B96E7A3F7.dita --- a/Symbian3/SDK/Source/GUID-CCC5BE18-E90D-4B81-AE6F-333B96E7A3F7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CCC5BE18-E90D-4B81-AE6F-333B96E7A3F7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ user can browse through the list with scroll keys or with the touch event.

      Example of Choice list - +
      Default key events in a choice list diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCE5DBCC-41D6-53D0-B929-ADB478B53F12.dita --- a/Symbian3/SDK/Source/GUID-CCE5DBCC-41D6-53D0-B929-ADB478B53F12.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CCE5DBCC-41D6-53D0-B929-ADB478B53F12.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ MAKEDEF WARNING: 1 export(s) not yet Frozen in \src\example\MyDLLU.DEF: ..\..\..\EPOC32\BUILD\src\example\group\MyDLL\ARMV5\MyDll{000a0000}.def(7) : _ZThn12_N7Derived3fooEv @6

      This shows a problem with a frozen DEF file: the export at ordinal 2 is missing, and a new unfrozen export has been added at ordinal 6. When comparing the two symbols, they look suspiciously similar to each other, and to a third symbol in the DEF file:

      _ZN7Derived3fooEv @1 _ZThn8_N7Derived3fooEv @2 // this one is missing -_ZThn12_N7Derived3fooEv @6 // this one has appeared

      The exports beginning with _ZTh are compiler generated functions called thunks (see Class Impedimenta), and the information between _ZTh and the next underscore is the offset associated with the thunk. Our problem is that for some reason, the offset associated with the thunk has changed from –8 to –12 (the n denotes a negative offset). Note that there is another variant of this problem that involves thunks beginning with _ZTv.

      These generated functions are a feature of the Itanium C++ ABI, on which the ABI for the ARM architecture builds upon. Hence the name "ARM ABI Thunk Offset Problem".

      What causes this problem?

      The problem is caused because the symbol name generated for the thunk contains an offset number. More details can be found in http://www.codesourcery.com/cxx-abi/abi.html under section 5.1.4. This offset may change, when the signature of the base class is changed. For example when a data member is added or removed.

      Another condition to trigger the problem needs to hold as well: multiple inheritance with virtual functions in more than one of the base classes. If this condition does not hold, the compiler will not generate a thunk and thus there is no problem.

      Note that this is always a Binary Compatibility break, which shows up as a change to symbols in DEF files.

      How do I fix it?

      There are three choices to fix it:

      1. The first option is to refreeze the DEF file: this would be OK if you are not maintaining a frozen interface, and your customers will in any case need to rebuild because of the Binary Compatibility break. The easiest way to refreeze is to delete all of the exports from your existing DEF file, build again, and then use "abld freeze armv5 " to update the DEF file. After updating the DEF file, build again: this time it should build cleanly.

      2. The second option is to use the attached script to fix the ABI Thunk Offsets. It expects to read a build log containing the MAKEDEF errors and warnings and will modify the DEF file to replace each missing export with the corresponding unfrozen export. Run the script with no arguments to get further details.

        After fixing the DEF file, you will need to rebuild the DLL which uses the DEF file.

      3. The last option is that you could change your mind about adding that extra member data. This will only be an option if it is your change which causes the problem: if your supplier has changed the size of a class that they own and caused this problem, then you are forced to change your DEF file.

        If you own the class which has the extra member data, it is worth noting that this change is likely to affect your customers as well. They will have to rebuild because of the BC break. Adding to this they will also see the ABI Thunk Offset Problem if they derive from your class. This includes simple inheritance from a class which shows the problem, if it re-implements any of the virtual functions which require thunks.

        When Symbian breaks compatibility in a way likely to cause this problem, the corresponding entry in the Compatibility Break spreadsheet will say "BC+ Break: Rebuild & Check/Fix Def-File EABI Thunk Offsets".

      Tell me the full details: What is a thunk? What causes its offset to change?

      In a C++ class hierarchy involving both virtual functions and multiple inheritance, objects can be accessed as though they were several different types. A typical Symbian platform example would be a CBase-derived class which also derives from an M-class, perhaps to provide an observer interface: for example CCoeControl, which derives from both CBase and MObjectProvider.

      The virtual functions which can be called on an object depends on the type it currently appears to be.A CCoeControl object can be viewed as a CBase object, in which case it has one set of virtual functions, or as an MObjectProvider, in which case it has another. The compiler constructs separate virtual tables for each of the possible interfaces, and these tables contain information about how to convert back to the underlying CCoeControl object. When converting from a CCoeControl pointer to an MObjectProvider pointer, the compiler will adjust the value of the pointer, so that it points to the "MObjectProvider" part of the object, and not the full CCoeControl object.

      The MObjectProvider class defines a pure virtual function MopSupplyObject, which is implemented in CCoeControl. Even when the object is presenting it's MObjectProvider interface, the vtable must use the correct implementation of MopSupplyObject, which expects to be used in the context of a CCoeControl. The solution used by the compiler is to create a virtual function override thunk function which makes any necessary adjustments between the calling context (a pointer to MObjectProvider) and the execution context (a pointer to CCoeControl).

      This could have been implemented using the names of the two contexts, but instead the ABI uses the amount by which the this pointer needs to be adjusted to make the switch: this is the offset encoded in the name.

      Here is a small example:

      eabi_thunk_offset_problem.cpp

      #ifndef COUNT +_ZThn12_N7Derived3fooEv @6 // this one has appeared

      The exports beginning with _ZTh are compiler generated functions called thunks (see Class Impedimenta), and the information between _ZTh and the next underscore is the offset associated with the thunk. Our problem is that for some reason, the offset associated with the thunk has changed from –8 to –12 (the n denotes a negative offset). Note that there is another variant of this problem that involves thunks beginning with _ZTv.

      These generated functions are a feature of the Itanium C++ ABI, on which the ABI for the ARM architecture builds upon. Hence the name "ARM ABI Thunk Offset Problem".

      What causes this problem?

      The problem is caused because the symbol name generated for the thunk contains an offset number. More details can be found in http://www.codesourcery.com/cxx-abi/abi.html under section 5.1.4. This offset may change, when the signature of the base class is changed. For example when a data member is added or removed.

      Another condition to trigger the problem needs to hold as well: multiple inheritance with virtual functions in more than one of the base classes. If this condition does not hold, the compiler will not generate a thunk and thus there is no problem.

      Note that this is always a Binary Compatibility break, which shows up as a change to symbols in DEF files.

      How do I fix it?

      There are three choices to fix it:

      1. The first option is to refreeze the DEF file: this would be OK if you are not maintaining a frozen interface, and your customers will in any case need to rebuild because of the Binary Compatibility break. The easiest way to refreeze is to delete all of the exports from your existing DEF file, build again, and then use "abld freeze armv5 " to update the DEF file. After updating the DEF file, build again: this time it should build cleanly.

      2. The second option is to use the attached script to fix the ABI Thunk Offsets. It expects to read a build log containing the MAKEDEF errors and warnings and will modify the DEF file to replace each missing export with the corresponding unfrozen export. Run the script with no arguments to get further details.

        After fixing the DEF file, you will need to rebuild the DLL which uses the DEF file.

      3. The last option is that you could change your mind about adding that extra member data. This will only be an option if it is your change which causes the problem: if your supplier has changed the size of a class that they own and caused this problem, then you are forced to change your DEF file.

        If you own the class which has the extra member data, it is worth noting that this change is likely to affect your customers as well. They will have to rebuild because of the BC break. Adding to this they will also see the ABI Thunk Offset Problem if they derive from your class. This includes simple inheritance from a class which shows the problem, if it re-implements any of the virtual functions which require thunks.

        When Symbian breaks compatibility in a way likely to cause this problem, the corresponding entry in the Compatibility Break spreadsheet will say "BC+ Break: Rebuild & Check/Fix Def-File EABI Thunk Offsets".

      Tell me the full details: What is a thunk? What causes its offset to change?

      In a C++ class hierarchy involving both virtual functions and multiple inheritance, objects can be accessed as though they were several different types. A typical Symbian platform example would be a CBase-derived class which also derives from an M-class, perhaps to provide an observer interface: for example CCoeControl, which derives from both CBase and MObjectProvider.

      The virtual functions which can be called on an object depends on the type it currently appears to be.A CCoeControl object can be viewed as a CBase object, in which case it has one set of virtual functions, or as an MObjectProvider, in which case it has another. The compiler constructs separate virtual tables for each of the possible interfaces, and these tables contain information about how to convert back to the underlying CCoeControl object. When converting from a CCoeControl pointer to an MObjectProvider pointer, the compiler will adjust the value of the pointer, so that it points to the "MObjectProvider" part of the object, and not the full CCoeControl object.

      The MObjectProvider class defines a pure virtual function MopSupplyObject, which is implemented in CCoeControl. Even when the object is presenting it's MObjectProvider interface, the vtable must use the correct implementation of MopSupplyObject, which expects to be used in the context of a CCoeControl. The solution used by the compiler is to create a virtual function override thunk function which makes any necessary adjustments between the calling context (a pointer to MObjectProvider) and the execution context (a pointer to CCoeControl).

      This could have been implemented using the names of the two contexts, but instead the ABI uses the amount by which the this pointer needs to be adjusted to make the switch: this is the offset encoded in the name.

      Here is a small example:

      eabi_thunk_offset_problem.cpp

      #ifndef COUNT #define COUNT 1 #endif @@ -68,7 +68,7 @@ int MoreDerived::foo() { return iMoreDerived; } MoreDerived* fun3() { return new MoreDerived; } MInterface* fun4() { return new MoreDerived; } -

      Compile this with armcc -S eabi_thunk_offset_problem.cpp to get an assembly listing. Compile it again with an extra argument "-DCOUNT=2" to change the size of the base class, and compare the two files: there will be various differences in the code, but also differences in the _ZTh symbols - including the differences used in the "typical symptom" above.

      If you use virtual inheritance, then you may see another version of the problem. With virtual inheritance, there are two offsets involved and the thunk symbols will begin with _ZTv. The same symbol may appear in several thunks, each with different offsets.

      The Shared DEF File Problem

      What is the Problem with Shared DEF Files?

      The class exporting rules (see Class Exporting Rules) by default will generate non-callable exports for all classes that are not marked non-sharable in source. Say two DLLs, A and B share one DEF file, in effect implementing similar but different functionality towards the same public interface. Further say, no classes are marked non-sharable. Say there are some classes that are shared between DLL A and DLL B and that these classes have names of the form CShared<xyz>. Classes that are specific to DLL A have names of the form CA<xyz>, classes specific to DLL B have names of the form CB<xyz>. When DLL A is built, DEF file entries for non-callable exports from CShared<xyz> and CA<XYZ> are automatically added to the DEF file. When DLL B is built, exports from CShared<xyz> and CB<XYZ> are added. So in fact the DEF file would be the sum of all non-callable exports from CShared<xyz>, CA<xyz> and CB<XYZ>. It also will contain symbols from functions that are marked for export using EXPORT_C. However, this means that neither A or B can be linked. This is because when A is built, the code linking against the non-callable exports of CB<XYZ> do not exist in A and vice versa.

      Use-cases for Fixing Shared DEF Files

      Use-Case 1: Polymorphic “Plug-ins”

      Several DLLs are built using the same DLL interface (DEF file). Typically the DEF file has very few entries (1 or 2) and is maintained manually. This means that new functions are added by editing the shared DEF file. Also typically no import libraries are needed as the knowledge about the DLL interface is hard-coded into the client code of the "plug-in". The plug-ins do not have to be loaded at run-time. Some are always built but not always included in the ROM.

      The Fix:

      1. If the shared DEF file is in \epoc32\include\def\EABI then locate the original DEF file by searching all BLD.INF files for the appropriate line in PRJ_EXPORTS

      2. Remove all non-callable exports that have caused warnings or errors from the original DEF file.

      3. Add NOEXPORTLIBRARY to all MMP files that share that component, ensuring that the build system does NOT try and re-freeze these automatically the next time you build. Otherwise the build system will re-introduce these non-callable exports.

      Note:

      If you want to use the re-freeze mechanism – say to add a new export, you have to temporarily remove NOEXPORTLIBRARY from the MMP file, then generate a new DEF file by re-building the component, re-freeze, possibly edit (to remove unwanted non-callable exports) and then insert the keyword NOEXPORTLIBRARY into the MMP file again.

      Use-Case 2: Polymorphic “Plug-ins” on which Other Components Depend

      This is very similar to use-case 1, except that some other component depends on one of the plug-ins. This means that an import library is required.

      The Fix: The build structure must be such that

      • One MMP file generates the import library from the shared DEF file using the target type IMPLIB. It may be necessary to create a new MMP file which does this.

      • All the other MMP files use NOEXPORTLIBRARY as described in use-case 1

      Note:

      If you want to use the re-freeze mechanism – say to add a new export, you have to temporarily remove NOEXPORTLIBRARY from the MMP file, then generate a new DEF file by re-building the component, re-freeze, possibly edit (to remove unwanted non-callable exports) and then insert the keyword NOEXPORTLIBRARY into the MMP file again.

      Use-Case 3: Annotate Classes as Non-sharable

      Where a DEF file must be shared between components for whatever reason and none of the above use-cases can be applied, the build would fail for at least one component. An example of this may be a class MyPrivateClass that exists in the debug build (UDEV) of the OS, but not in the release build (UREL).

      In such a case all classes that should not contribute to the DEF file, i.e. that are really private to the implementation of a component, must be annotated in the source as NONSHARABLE_CLASS(X) or NONSHARABLE_STRUCT(X). As a result no non-callable exports will be generated for such a class. Say for example, class MyPrivateClass is truly private to a component that must share a DEF file with another component. Then it should be declared:

      NONSHARABLE_CLASS(MyPrivateClass) +

      Compile this with armcc -S eabi_thunk_offset_problem.cpp to get an assembly listing. Compile it again with an extra argument "-DCOUNT=2" to change the size of the base class, and compare the two files: there will be various differences in the code, but also differences in the _ZTh symbols - including the differences used in the "typical symptom" above.

      If you use virtual inheritance, then you may see another version of the problem. With virtual inheritance, there are two offsets involved and the thunk symbols will begin with _ZTv. The same symbol may appear in several thunks, each with different offsets.

      The Shared DEF File Problem

      What is the Problem with Shared DEF Files?

      The class exporting rules (see Class Exporting Rules) by default will generate non-callable exports for all classes that are not marked non-sharable in source. Say two DLLs, A and B share one DEF file, in effect implementing similar but different functionality towards the same public interface. Further say, no classes are marked non-sharable. Say there are some classes that are shared between DLL A and DLL B and that these classes have names of the form CShared<xyz>. Classes that are specific to DLL A have names of the form CA<xyz>, classes specific to DLL B have names of the form CB<xyz>. When DLL A is built, DEF file entries for non-callable exports from CShared<xyz> and CA<XYZ> are automatically added to the DEF file. When DLL B is built, exports from CShared<xyz> and CB<XYZ> are added. So in fact the DEF file would be the sum of all non-callable exports from CShared<xyz>, CA<xyz> and CB<XYZ>. It also will contain symbols from functions that are marked for export using EXPORT_C. However, this means that neither A or B can be linked. This is because when A is built, the code linking against the non-callable exports of CB<XYZ> do not exist in A and vice versa.

      Use-cases for Fixing Shared DEF Files

      Use-Case 1: Polymorphic “Plug-ins”

      Several DLLs are built using the same DLL interface (DEF file). Typically the DEF file has very few entries (1 or 2) and is maintained manually. This means that new functions are added by editing the shared DEF file. Also typically no import libraries are needed as the knowledge about the DLL interface is hard-coded into the client code of the "plug-in". The plug-ins do not have to be loaded at run-time. Some are always built but not always included in the ROM.

      The Fix:

      1. If the shared DEF file is in \epoc32\include\def\EABI then locate the original DEF file by searching all BLD.INF files for the appropriate line in PRJ_EXPORTS

      2. Remove all non-callable exports that have caused warnings or errors from the original DEF file.

      3. Add NOEXPORTLIBRARY to all MMP files that share that component, ensuring that the build system does NOT try and re-freeze these automatically the next time you build. Otherwise the build system will re-introduce these non-callable exports.

      Note:

      If you want to use the re-freeze mechanism – say to add a new export, you have to temporarily remove NOEXPORTLIBRARY from the MMP file, then generate a new DEF file by re-building the component, re-freeze, possibly edit (to remove unwanted non-callable exports) and then insert the keyword NOEXPORTLIBRARY into the MMP file again.

      Use-Case 2: Polymorphic “Plug-ins” on which Other Components Depend

      This is very similar to use-case 1, except that some other component depends on one of the plug-ins. This means that an import library is required.

      The Fix: The build structure must be such that

      • One MMP file generates the import library from the shared DEF file using the target type IMPLIB. It may be necessary to create a new MMP file which does this.

      • All the other MMP files use NOEXPORTLIBRARY as described in use-case 1

      Note:

      If you want to use the re-freeze mechanism – say to add a new export, you have to temporarily remove NOEXPORTLIBRARY from the MMP file, then generate a new DEF file by re-building the component, re-freeze, possibly edit (to remove unwanted non-callable exports) and then insert the keyword NOEXPORTLIBRARY into the MMP file again.

      Use-Case 3: Annotate Classes as Non-sharable

      Where a DEF file must be shared between components for whatever reason and none of the above use-cases can be applied, the build would fail for at least one component. An example of this may be a class MyPrivateClass that exists in the debug build (UDEV) of the OS, but not in the release build (UREL).

      In such a case all classes that should not contribute to the DEF file, i.e. that are really private to the implementation of a component, must be annotated in the source as NONSHARABLE_CLASS(X) or NONSHARABLE_STRUCT(X). As a result no non-callable exports will be generated for such a class. Say for example, class MyPrivateClass is truly private to a component that must share a DEF file with another component. Then it should be declared:

      NONSHARABLE_CLASS(MyPrivateClass) { ... };

      This will prevent the compiler from exporting non-callables for MyPrivateClass. However this means that it is not possible to DLL-derive (for the definition of DLL-derive see Terminology and Background) from MyPrivateClass and that all classes derived from MyPrivateClass must also be marked non-sharable (see Terminology and Background).

      Use-Case 4: Optimisation

      A consequence of the Simple Rule (see The Simple Rule – Sharable Classes) is that some components may emit entries in their DEF files which are not needed. In the worst case the overhead is 8 bytes of ROM size per class (2 DLL entry points). In the typical case an increase of 4 bytes will occur and in some cases no increase at all.

      For code that is private to an implementation, i.e. where it is known that a class would never be used outside of that component, this footprint increase is unnecessary. In order to avoid the footprint increase mark all private classes (and classes derived from them) in the source as NONSHARABLE_CLASS(X) or NONSHARABLE_STRUCT(X) as described for use-case 3.

      Use-Case 5: The Build Tools Automatically Ignore Non-callable Exports

      For most components the build tools automatically ignore all non-callable exports. This is the case because the build tools know the situations when non-callable exports cannot be needed. Non-callable exports are only needed, if:

      • The target type is either DLL, EXEDLL or EXEXP and the MMP file has no NOEXPORTLIBRARY keyword

      • If the MMP file contains the DEFFILE keyword and the MMP file has no NOEXPORTLIBRARY keyword

      The reason for this is that target types, such as APP, always map directly onto one of the above use-cases. For example the target type APP is an example of use-case 1, i.e. the APP is a DLL that always has the same DEF file. However no other DLL but the APP loader will ever link against this binary, unless its MMP file contains the DEFFILE keyword.

      Use-Case 6: Best Practice

      Note that it is good practice to avoid unnecessary footprint increases by marking private classes as non-sharable as outlined in use-case 4. Further note, that at some point in the future Symbian may add this to the Symbian Coding Standards or withdraw tools support for some of the cases described above.

      Optimisation

      This section discusses advantages of marking “private” classes as described in use-cases 4 and 6 in the previous section as non-sharable

      Reasons for Optimisation:

      • Small footprint saving

      • DEF files are more “pretty”, i.e. they will have fewer entries for non-callable exports in it and may have fewer holes in them.

      • When changing code that is private to a module as described in use-case 4 and not marked non-sharable, DEF file changes are required when:

        • Renaming a private class

        • Removing a private class

        • Adding a private class

        This makes it harder to maintain DEF files and will ultimately lead to less “pretty” DEF files when Binary Compatibility must be maintained.

      • More non-sharable classes mean that it is less likely to have problems with shared DEF files as outlined in use-cases 1 and 2 in the previous section.

      When not to use Optimisation:

      It is not advisable to use optimisation in the following circumstances, as the build tools suppress non-callable exports automatically in these cases:

      • The target type of the component containing private classes is neither DLL, EXEDLL nor EXEXP and no DEFFILE keyword is contained the components MMP file

      • The MMP file of the component contains the NOEXPORTLIBRARY keyword.

        If the NOEXPORTLIBRARY keyword has been introduced to work around problems introduced by shared DEF files and the Simple Rule it may be better to remove the NOEXPORTLIBRARY keyword and mark private classes as non-sharable instead.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCE61F55-DDCC-566B-B4C6-E094E8E8B073_d0e316250_href.png Binary file Symbian3/SDK/Source/GUID-CCE61F55-DDCC-566B-B4C6-E094E8E8B073_d0e316250_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCE61F55-DDCC-566B-B4C6-E094E8E8B073_d0e322720_href.png Binary file Symbian3/SDK/Source/GUID-CCE61F55-DDCC-566B-B4C6-E094E8E8B073_d0e322720_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCE6DC36-625C-487C-9AD8-F1BF8E36080A.dita --- a/Symbian3/SDK/Source/GUID-CCE6DC36-625C-487C-9AD8-F1BF8E36080A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CCE6DC36-625C-487C-9AD8-F1BF8E36080A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -13,7 +13,7 @@

      This table has been filtered for PDK, SDK and Internal publications. The conditions applied for each row can be viewed in the Document Map on the left hand pane (they have attribute mark).

      -
      +
      @@ -37,7 +37,7 @@

      Toolbar

       - +

      Toolbar API, Generic @@ -46,7 +46,7 @@

      Choice list

       - +

      Choice list API

       @@ -55,7 +55,7 @@

      Forms

       - +

      Form API

             @@ -67,7 +67,7 @@

    • Slider

      • - +

      Form API

       @@ -77,7 +77,7 @@ query, Grid query

      - +

      Queries API

       @@ -85,7 +85,7 @@

      Left/Right arrows in the Navi pane

       - +

      Navigation pane API

       @@ -94,7 +94,7 @@ list

      Selection list

      - +

      Lists API

       @@ -102,7 +102,7 @@

      Multi-selection list

       - +

      Lists API

       @@ -110,7 +110,7 @@

      Scrollbar

       - +

      Scroller API

       @@ -122,28 +122,28 @@

      Pop-up setting

       - +

      Multi-selection list setting

       - +

      Text setting

       - +

      Slider setting

       - +

      @@ -151,7 +151,7 @@

      Setting list

       - +

      Setting pages API, Lists API

             @@ -160,7 +160,7 @@ pane

      There is no middle softkey label in Touch UI - +

      Buttons API

       @@ -180,7 +180,7 @@

    • Clock Pane

      • - +

      • Status pane API for the entire status pane

        • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCEE3988-C10A-538A-8107-E2636594443B_d0e320575_href.png Binary file Symbian3/SDK/Source/GUID-CCEE3988-C10A-538A-8107-E2636594443B_d0e320575_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CCEE3988-C10A-538A-8107-E2636594443B_d0e327045_href.png Binary file Symbian3/SDK/Source/GUID-CCEE3988-C10A-538A-8107-E2636594443B_d0e327045_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CD2BF0EE-5437-4ADA-A447-4B06147754A8.dita --- a/Symbian3/SDK/Source/GUID-CD2BF0EE-5437-4ADA-A447-4B06147754A8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CD2BF0EE-5437-4ADA-A447-4B06147754A8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ illustrates the relationships between the different Symbian Bluetooth classes.

        For more information, see Bluetooth Management Collection.

        -Bluetooth API +Bluetooth API

        Use the Bluetooth Security Manager to set the appropriate security requirements (authentication, authorization, and encryption) that incoming connections to the device's Bluetooth services must meet. For more information, see Using Bluetooth Security diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CD506806-FC59-547A-B5CD-03314DF847F7.dita --- a/Symbian3/SDK/Source/GUID-CD506806-FC59-547A-B5CD-03314DF847F7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CD506806-FC59-547A-B5CD-03314DF847F7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,61 +1,58 @@ - - - - - -Date And -Time Handling OverviewFunctions that manipulates date and time values. -

        Architectural relationships

        The system maintains -two clocks:

          -

        • a secure clock that -can only be set by kernel code or by an application that has TCB capability. -This is a clock that can be used by secure DRM applications.

          • -

        • a non-secure clock that -can be set by applications that require no specific capability. This is the -clock that is used for user-visible time displays.

          • -

        The non-secure clock is implemented in terms of an offset from the -secure clock.

        Both the secure time and the non-secure time can be -set using the System Static Functions API, and specifically:

        -
        Secure time
          -

        • User::SetHomeTimeSecure(0

          • -

        • User::SetUTCTimeSecure()

          • -
        -
        Non-secure time
          -

        • User::SetHomeTime()

          • -

        • User::SetUTCTime()

          • -

        System locale settings, which affect date and time formatting, are -set through TLocale in the Locale Settings API.

        -
        Description

        The API has three key concepts: point -in time, time utilities, and time interval.

        Point -in time

        The point in time is a 64-bit integer that represents -time as the number of microseconds since midnight on 1st January 0 AD, using -a nominal Gregorian calendar. It can be set to the current system time, can -have arithmetic and comparison operations performed on it, and can be converted -into a string formatted according to the locale and other options.

        The -main point in time interface is provided by TTime. A support -class TDateTime is provided that allows time values to -be get and set in an easy-to-use format, such as year, month, day, rather -than as an integer.

        The time value in a TTime object -can be set using either the secure time or the non-secure time.

        Time utilities

        The time utilities provides miscellaneous time -functions, for such things as checking for leap years.

        The time utilities -interface is provided by Time.

        Time interval

        The time interval represents a period between -two points in time. Time intervals can be added or subtracted, either to or -from each other or to or from points in time.

        The time interval interface -is provided by a base class TTimeIntervalBase and by a -family of derived classes for second, minute, hour, etc. intervals. A class -outside this hierarchy, TTimeIntervalMicroSeconds, is provided -for efficiency reasons (it alone stores its value as a 64-bit number).

        - - -Locale Settings -Overview - -System Static -Functions Overview + + + + + +Date And Time Handling OverviewFunctions that manipulates date and time values. +
        Architectural +relationships

        The system maintains two clocks:

          +

        • a secure clock +that can only be set by kernel code or by an application that has +TCB capability. This is a clock that can be used by secure DRM applications.

          • +

        • a non-secure +clock that can be set by applications that require no specific capability. +This is the clock that is used for user-visible time displays.

          • +

        The non-secure clock is implemented in terms of an offset +from the secure clock.

        Both the secure time and the non-secure +time can be set using the System Static Functions API, and specifically:

        +
        Secure +time
          +

        • User::SetHomeTimeSecure(0

          • +

        • User::SetUTCTimeSecure()

          • +
        +
        Non-secure +time
          +

        • User::SetHomeTime()

          • +

        • User::SetUTCTime()

          • +

        System locale settings, which affect date and time formatting, +are set through TLocale in the Locale Settings +API.

        +
        Description

        The API has three key concepts: point in time, time utilities, +and time interval.

        Point in time

        The point in time is a 64-bit integer +that represents time as the number of microseconds since midnight +on 1st January 0 AD, using a nominal Gregorian calendar. It can be +set to the current system time, can have arithmetic and comparison +operations performed on it, and can be converted into a string formatted +according to the locale and other options.

        The main point +in time interface is provided by TTime. A support +class TDateTime is provided that allows time values +to be get and set in an easy-to-use format, such as year, month, day, +rather than as an integer.

        The time value in a TTime object can be set using either the secure time or the non-secure +time.

        Time utilities

        The time utilities provides miscellaneous +time functions, for such things as checking for leap years.

        The time utilities interface is provided by Time.

        Time interval

        The time interval represents a period +between two points in time. Time intervals can be added or subtracted, +either to or from each other or to or from points in time.

        The time interval interface is provided by a base class TTimeIntervalBase and by a family of derived classes for +second, minute, hour, etc. intervals. A class outside this hierarchy, TTimeIntervalMicroSeconds, is provided for efficiency reasons +(it alone stores its value as a 64-bit number).

        +         + +System Static Functions Overview +Locale +Settings Overview         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CD7F507C-CDD5-5612-BA1B-72641D28FA4A_d0e254198_href.png Binary file Symbian3/SDK/Source/GUID-CD7F507C-CDD5-5612-BA1B-72641D28FA4A_d0e254198_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CD7F507C-CDD5-5612-BA1B-72641D28FA4A_d0e259109_href.png Binary file Symbian3/SDK/Source/GUID-CD7F507C-CDD5-5612-BA1B-72641D28FA4A_d0e259109_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345485_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345485_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345918_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345918_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345997_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e345997_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e346170_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e346170_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374486_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374486_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374919_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374919_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374998_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e374998_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e375171_href.png Binary file Symbian3/SDK/Source/GUID-CE79D1B9-2770-5494-A741-D98DE3EBFA05_d0e375171_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE7C84A5-D2E6-5151-BBC7-6AF9C8A0D978.dita --- a/Symbian3/SDK/Source/GUID-CE7C84A5-D2E6-5151-BBC7-6AF9C8A0D978.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CE7C84A5-D2E6-5151-BBC7-6AF9C8A0D978.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ The binaries are linked to the etul.lib (Text Utilities - part of Egul component) library.

        Subsystem dependencies - +
        Description

        Usage

        In order to use the Address String Tokenizer, the user has to create an instance @@ -84,6 +84,6 @@ delete multiSearch;

        Sequence Diagram

        Sequence of events for <codeph>CTulAddressStringTokenizer</codeph> - +
        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE7CF024-4898-551A-841B-38EC57A3EC82.dita --- a/Symbian3/SDK/Source/GUID-CE7CF024-4898-551A-841B-38EC57A3EC82.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CE7CF024-4898-551A-841B-38EC57A3EC82.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ shows three windows, A, B and C, all belonging to the same window group. Their ordinal positions are as follows: A=0; B=1; C=2.

        - +

        This would be the default ordering of the windows if they were created in the order CBA. Many sibling windows within an application may not overlap @@ -49,16 +49,16 @@ ordinal position of 0. The diagram below shows windows A, B and C, but window B has now been given an ordinal position of 0. A’s position has been incremented to 1, and C’s remains as 2.

        - +

        The diagram below shows the same three windows as above, except that window B now contains a child window, D. Window D’s ordinal position is 0, relative to its parent window, B.

        - +

        If window A is now moved to the front, window B moves behind it, as shown in the diagram below. Window D’s ordinal position is still 0, but because its position is relative to its parent window, it moves with window B to behind window A.

        - +
        Moving a window to the back

        If a window is given an ordinal position greater than all its siblings, it is moved to the back diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE7DA679-D441-4843-A81B-2A60440B50E8-master.png Binary file Symbian3/SDK/Source/GUID-CE7DA679-D441-4843-A81B-2A60440B50E8-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE7DA679-D441-4843-A81B-2A60440B50E8_d0e146989_href.png Binary file Symbian3/SDK/Source/GUID-CE7DA679-D441-4843-A81B-2A60440B50E8_d0e146989_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CE94AD48-B79B-403A-98E9-F69494D052F9.dita --- a/Symbian3/SDK/Source/GUID-CE94AD48-B79B-403A-98E9-F69494D052F9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CE94AD48-B79B-403A-98E9-F69494D052F9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -65,7 +65,7 @@ below shows the subsystems that need to be modified in order to adapt HDMI in the Symbian platform by the device creator.

        HDMI architectural relationship with the subsystem - +

        1. Application layer

          To use HDMI in an application no changes are required @@ -102,7 +102,7 @@

      For example in order to play a video the following diagram demonstrates the HDMI feature implementation:

      HDMI video play use-case - +

      In order to play video the CVideoPlayerUtility2 API is used as the Video Client library, which plays sampled video data on graphics surfaces. In the MMF layer, the RMMFController and the CHXNGAUtility APIs are used as the MMF controller framework, which initializes the DevVideo API. The DevVideo uses the CMMFDevVideoPlay API diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF17532E-5E90-5124-8F05-AA72B848F17F.dita --- a/Symbian3/SDK/Source/GUID-CF17532E-5E90-5124-8F05-AA72B848F17F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CF17532E-5E90-5124-8F05-AA72B848F17F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ that use two different machines. The following figure illustrates the sample application.

      - +

      All users who want to play the game must register to the server with their identities. This informs the server that the user is active and prepared to @@ -55,7 +55,7 @@

      How to play the game

      The following snapshot shows the different tabs available in the game.

      - +

      The following list describes the different tabs available in the game:

      • Invite for game - diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF34E1C9-48E5-5B91-A48E-C68E647116A0_d0e47970_href.png Binary file Symbian3/SDK/Source/GUID-CF34E1C9-48E5-5B91-A48E-C68E647116A0_d0e47970_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF34E1C9-48E5-5B91-A48E-C68E647116A0_d0e48128_href.png Binary file Symbian3/SDK/Source/GUID-CF34E1C9-48E5-5B91-A48E-C68E647116A0_d0e48128_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF8287B9-2063-5316-A1BF-7DFC58FCDE30.dita --- a/Symbian3/SDK/Source/GUID-CF8287B9-2063-5316-A1BF-7DFC58FCDE30.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,60 +0,0 @@ - - - - - -How -to freeze exports -

        Released versions of DLLs should freeze their exports, so as to ensure -the backward compatibility of new releases of a library. While you are developing -a DLL, you can use the exportunfrozen keyword in the project's -mmp file, to tell the build process that exports are not yet frozen. When -you are ready to freeze, remove the exportunfrozen keyword, -and supply a .def file listing the exports.

        -

        To create a .def file, build the project in the normal -way. A warning will be generated to the effect that the frozen .def file -does not yet exist. Once the project has been built you can freeze it by calling -the freeze target in the makefiles. You can do this with abld by -using:

        -

        abld freeze

        -

        Either method will create the frozen .def file containing -the project’s exported functions. Note that the Symbian emulator targets and -ARM targets have different .def file formats, so that -if you build for both of these, you will need to store two def files.

        -

        Once the project is frozen, regenerate the makefiles so that the import -library will be created directly from the frozen .def file.

        -

        The project can be frozen in this way even if the exportunfrozen statement -is specified, but the import library will be created as a side-effect of linking -rather than from the frozen .def file, and this import -library will be created whether the project is frozen or not.

        -
        Storing deffiles

        By default, the build tools look -for the Symbian emulator build def file in a BWINS directory -(at the same level as the directory containing the mmp file), and the ARM -def file in a EABI directory. If def files are stored in -these locations, the project files does not need to specify the location of -the def files explicitly. If you want to store the def files in some other -location, you will need to specify in the project file where the .def files -are using the deffile keyword.

        Because the .def files -are different for different targets, it's necessary to use #if defined macros -to select the correct def file, depending on the target for which the project -is being built. The following example does this:

        #if defined(WINS) -deffile ..\freeze\CONVPLUG-WINS.DEF -#else -deffile ..\freeze\CONVPLUG-EABI.DEF -#endif

        A more succinct syntax is also available:

        deffile ..\~\x.def

        A -directory named ~ in a deffile path is automatically replaced with bwins or -eabi as necessary depending on which target is being built.

        -
        Adding new exports

        New exports can be added to -the frozen .def file by calling the freeze target -in the makefiles once the project has been built with the new exports incorporated.

        The freeze target -calls a tool, efreeze, to compare the frozen .def file, -if it exists, with the one generated by the two-stage link process in directory: epoc32\build\ absolute_path_to_mmp_file \ mmp_basename \ platform \

        efreeze checks that the frozen exports are all present and correct -in the generated .def file, and appends any new exports -to the end of the frozen .def file.

        - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0.dita --- a/Symbian3/SDK/Source/GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,10 +11,10 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Nodes in the Communications FrameworkThis topic describes the concept of a Node in the Communications Framework.

        The Communications Framework separates its implementation into horizontal and vertical divisions - the concept of Layers and Planes. Each of the separate entities is a Node. These entities form part of the Communications stack and are named Stack Nodes. Stack Nodes belong to a single Layer and a single Plane. Stack Nodes also provide Access Point services.

        Stack Nodes

        There are four Stack Nodes:

        MetaConnection Provider (MCPR) Node

        The MCPR Node uses the configuration and policy specifications to manage the Layer. A phone creator can replace this Node. The replacement or the configuration of this Node allows a phone creator to change the configuration of the Communications Infrastructure without a change to the software.

        Connection Provider (CPR) Node

        The CPR Node manages the connections.

        SubConnection Provider (SCPR) Node

        The SCPR Node manages the subconnections. Each subconnection represents a logical data channel. The Communications Framework has the concept of a default subconnection. A default SCPR always exists to represent the default subconnection. A connection uses the default subconnection if a subconnection is not specified.

        Flow Node

        The Flow Node manages the data stream.

        Stack Nodes -

        Each type of Node is related to a specific Plane in the Comms Stack. The following diagram shows that:

        • the Flow Node has a one-to-one relationship with the Data Plane.

        • the MCPR (MetaConnection Provider) Node has a one-to-one relationship with the Management Plane.

        • the Control Plane contains both the SCPR Node and the CPR Node.

        • the SCPR Node can have many instances in operation at the same time.

        • the MCPR Node can connect to resources outside the Communications stack. The offset grey box around the text MCPR represents this fact.

        +

        Each type of Node is related to a specific Plane in the Comms Stack. The following diagram shows that:

        • the Flow Node has a one-to-one relationship with the Data Plane.

        • the MCPR (MetaConnection Provider) Node has a one-to-one relationship with the Management Plane.

        • the Control Plane contains both the SCPR Node and the CPR Node.

        • the SCPR Node can have many instances in operation at the same time.

        • the MCPR Node can connect to resources outside the Communications stack. The offset grey box around the text MCPR represents this fact.

        How Nodes related to Planes in the Comms Stack -
        Other Nodes

        The Communications Framework has two other types of Node: Tier Manager and Factory Container.

        Tier manager Node

        A Tier is an alternative to Access Points. A Tier gives users a different method to access the services of the Communications Infrastructure. A Tier represents a higher level communications technology or a collection of technologies. Each communications technology belongs to a Tier, but a Tier can contain more than one technology. When a user selects a technology, a Tier shows the appropriate group of technologies from which the user can select. The Tier handles the selection of the Access Point. A Tier manager Node manages each Tier in the Communications Framework.

        Factory Container Node

        Factory Containers create Nodes. The Communications Framework supplies a Factory Container for each type of Node. The Factory Containers have published addresses and Nodes use these addresses to find and communicate with the Factory Containers. A Node can create another Node. A Node sends a request to the correct Factory Container to create the other Node. The Factory Container tries to create the new Node and reports status to the Node that made the request.

        The following diagram shows the connection between the Stack Nodes and the Tier Manager and Factory Container Nodes.

        +
        Other Nodes

        The Communications Framework has two other types of Node: Tier Manager and Factory Container.

        Tier manager Node

        A Tier is an alternative to Access Points. A Tier gives users a different method to access the services of the Communications Infrastructure. A Tier represents a higher level communications technology or a collection of technologies. Each communications technology belongs to a Tier, but a Tier can contain more than one technology. When a user selects a technology, a Tier shows the appropriate group of technologies from which the user can select. The Tier handles the selection of the Access Point. A Tier manager Node manages each Tier in the Communications Framework.

        Factory Container Node

        Factory Containers create Nodes. The Communications Framework supplies a Factory Container for each type of Node. The Factory Containers have published addresses and Nodes use these addresses to find and communicate with the Factory Containers. A Node can create another Node. A Node sends a request to the correct Factory Container to create the other Node. The Factory Container tries to create the new Node and reports status to the Node that made the request.

        The following diagram shows the connection between the Stack Nodes and the Tier Manager and Factory Container Nodes.

        Connection between the Stack Nodes and the Tier Manager and Factory Container Nodes -
        Access +
      Access Points Layers Planes Tiers \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF8FA653-5A3B-5D57-8875-0BC6BDCC1D0A.dita --- a/Symbian3/SDK/Source/GUID-CF8FA653-5A3B-5D57-8875-0BC6BDCC1D0A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-CF8FA653-5A3B-5D57-8875-0BC6BDCC1D0A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ Send executable, it unpacks the schedule information and uses the messaging client API to request the Server MTM to perform an operation.

      Schedule Send architecture - +

      The executable to run by the Task Scheduler is specified in the schedule send settings. This allows different executables for different message types, as a set of schedule send settings are defined for each message type diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e206241_href.png Binary file Symbian3/SDK/Source/GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e206241_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e211248_href.png Binary file Symbian3/SDK/Source/GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e211248_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CFD3CD78-D99A-57B8-80EB-8C67899E5D27_d0e427383_href.png Binary file Symbian3/SDK/Source/GUID-CFD3CD78-D99A-57B8-80EB-8C67899E5D27_d0e427383_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-CFD3CD78-D99A-57B8-80EB-8C67899E5D27_d0e431183_href.png Binary file Symbian3/SDK/Source/GUID-CFD3CD78-D99A-57B8-80EB-8C67899E5D27_d0e431183_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D04DD8E6-804F-539E-8BD1-146210F4A51C_d0e195099_href.png Binary file Symbian3/SDK/Source/GUID-D04DD8E6-804F-539E-8BD1-146210F4A51C_d0e195099_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D04DD8E6-804F-539E-8BD1-146210F4A51C_d0e200108_href.png Binary file Symbian3/SDK/Source/GUID-D04DD8E6-804F-539E-8BD1-146210F4A51C_d0e200108_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D0BD34C9-7793-5FA0-8864-FD7444D62F90.dita --- a/Symbian3/SDK/Source/GUID-D0BD34C9-7793-5FA0-8864-FD7444D62F90.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D0BD34C9-7793-5FA0-8864-FD7444D62F90.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ ... }; - +

      Although any kind of object can be an element of a linked list, most lists consist of elements which are all of the same type.

      @@ -36,7 +36,7 @@ TDblQueLink iDlink2; }; - +

      Elements can also be objects constructed from a variety of classes, all ultimately derived from the same base class, where that base class includes @@ -60,7 +60,7 @@ } - +

      New link elements are inserted into an existing list using either TDblQueLink::Enque() or TDblQueLink::AddBefore() function. Note that AddBefore() is not available in v5. These are prototyped as:

      @@ -71,13 +71,13 @@ is added to the list so that its position follows the element aLink, as the following figure shows.

      - +

      Calling AddBefore() on an element means that this element is added to the list so that its position precedes the element aLink, as the following figure shows.

      - +

      Note that new elements cannot be inserted at the beginning or end of a list using these functions. The AddFirst() and AddLast() members diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D0C1493F-BA2F-517B-9D96-073DCF3D7923.dita --- a/Symbian3/SDK/Source/GUID-D0C1493F-BA2F-517B-9D96-073DCF3D7923.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -ARMV6 build targets

      The ARMV6 build target builds to the ARMV6 architecture. Like the ARMV5 target, the target requires the ARM's RealView Compilation Tools (RVCT) v2.2 build 616 from Symbian OS v9.4 onwards.

      Building binaries for ARMV6

      To build for ARMV6 with abld, use:

      abld build ARMV6 | ARMV6_ABIv2 [udeb | urel]

      Binaries are generated in the udeb and/or urel sub-directories of the epoc32\release\ARMV6\ directory for ABI v1 and epoc32\release\ARMV6_ABIv2\ directory for ABI v2.

      As per the conventional approach mentioned above, the build targets ARMV6 and ARMV6_ABIv2 are used to build binaries conforming to ARMV6 ABI v1 and ABI v2 respectively. From Symbian OS v9.4 onwards, the behaviour of these native build targets (ARMV6 and ARMV6_ABIv2) has changed. The build target ARMV6 is used to build binaries conforming to ABI v2 instead of ABI v1, and ARMV6_ABIv1 is used to build binaries conforming to ABI v1. Also, the release directories have changed to epoc32\release\ARMV6\ for ABI v2 binaries and epoc32\release\ARMV6_ABIv1\ for ABI v1 binaries.

      You can switch back to the old approach, where the targets ARMV6 and ARMV6_ABIv2 will build binaries conforming to ABI v1 and ABI v2 respectively. For more details on this, refer to Switching between ABI modes.

      Library export (.lib or .dso) files are generated in the epoc32\release\ARMV5\lib\ directory. This directory is used, as the library file format has not changed since ARMV5.

      Note: Code is not built for ARMV6 target by default. It has to be explicitly specified on the command line or with a prj_platforms statement in the component's BLD.INF file.

      Building binaries for ARMV6t2

      To build binaries for ARMV6t2 with abld, use:

      abld build ARMV6t2 [udeb | urel]

      The command builds binaries conforming to ABIv2 for ARMV6 architecture supporting Thumb-2 instruction set.

      IDE (CodeWarrior) support for ARMV6

      To build for ARMV6 or ARMV6t2 from the CodeWarrior IDE, specify ARMV6 or ARMV6t2 as the target in the Platform Selection field, when importing a project from an .mmp file. The binaries can then be built by setting the target to ARMV6 or ARMV6t2 for UREL or UDEB.

      From the command line, to generate a CodeWarrior XML project file for ARMV6 or ARMV6t2, use the following command:

      makmake <project>.mmp CW_IDE:ARMV6 | ARMV6t2

      and then import the generated XML file from the IDE.

      Note: The binaries for ARMV6 or ARMV6t2 target are not created by default. You must explicitly specify these targets either on the command line using makmake or in the Platform Selection field.

      Customisation for ARMV6

      The build system provides the ARMV6 target by providing a build specialization file (BSF) in the epoc32\tools\ directory. For ABI v1 builds this is ARMV6.BSF; for ABI v2 builds, ARMV6_ABIv2.bsf. From Symbian OS v9.4 onwards, for ABI v1 builds the BSF file is ARMV6_ABIv1.bsf and for ABI v2 builds it is ARMV6.bsf. For more information about BSF mechanism, refer to ARMV5 build customisation.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D0C84E1D-A625-4F79-8515-399B8153727B.dita --- a/Symbian3/SDK/Source/GUID-D0C84E1D-A625-4F79-8515-399B8153727B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D0C84E1D-A625-4F79-8515-399B8153727B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,88 +1,105 @@ - - - - - -What's -New in Graphics in Symbian^3This section describes the changes introduced in the Graphics package -in Symbian^3. -
      ScreenPlay

      ScreenPlay -is a new graphics architecture which enables device creators to take advantage -of improved software performance, hardware acceleration and third party graphics -engines. For more information, see:

        -
      • The ScreenPlay -Graphics Architecture
        • -
      • The NonScreenPlay -Graphics Architecture
        • - -
      • Graphics Composition
        • -
      • Graphics Hardware -Acceleration
        • -
      • Dynamic Resolution -Switching
        • - - -
      • Advanced Pointer -Overview
        • -
      • External Surfaces -Overview
        • - - -
      -
      Khronos APIs

      For -information about the supported Khronos APIs, see:

        -
      • Khronos API Support
        • -
      • OpenVG Collection
        • -
      • OpenGLES Collection
        • -
      • EGL Collection
        • - -
      - -
      Interface breaks -and deprecated functionality

      The following functionality is deprecated in Symbian^3:

        - - -

      • Creating transparent windows using a mask and RWindow is -deprecated. See Transparent -Windows for more information.

        • -

      • Backed-up windows are deprecated. See Displayable -Windows for more information.

        • -
      -
      Guide documentation -changes

      The following documentation has been added to the Windowing collection:

        -
      • Window Server Component -Overview
        • -
      • Display Control -and Mapping in the Window Server Client
        • -
      • Transparent Windows
        • -
      • Redraw Drawing
        • -
      • Advanced Pointers
        • -
      • External Surfaces
        • - - - -
      • Window Server Internals -Concepts
        • -
      • The wsini.ini File
        • - -

      The following documentation has been added to the OpenGLES collection:

        -

      • OpenGLES Collection

        • -

      The following documentation has been added to the OpenVG collection:

        -

      • OpenVG Collection

        • -

      The following documentation has been added to the EGL collection:

        -

      • EGL Collection

        • -

      The following documentation has been updated:

        -
      • Graphics and Drawing
        • -
      • The Font and Bitmap -Server Overview
        • -
      -       -Graphics -Guide + + + + + +What's New in Graphics in Symbian^3This section describes the changes introduced in the Graphics +package in Symbian^3. +
      ScreenPlay

      ScreenPlay is a new graphics architecture which enables device +creators to take advantage of improved software performance, hardware +acceleration and third party graphics engines. For more information, +see:

        +
      • The ScreenPlay +Graphics Architecture
        • +
      • The NonScreenPlay +Graphics Architecture
        • + +
      • Graphics +Composition
        • +
      • Graphics +Hardware Acceleration
        • +
      • Dynamic +Resolution Switching
        • + + +
      • Advanced +Pointer Overview
        • +
      • External +Surfaces Overview
        • + + +
      +
      Khronos +APIs

      For information about the supported Khronos APIs, see:

        +
      • Khronos +API Support
        • +
      • OpenVG +Collection
        • +
      • OpenGLES +Collection
        • +
      • EGL Collection
        • + +
      + +
      Interface +breaks and deprecated functionality

      On ScreenPlay, support +for direct screen access (DSA) is maintained for backward compatibility +reasons, although Symbian recommends the use of external surfaces +in preference to DSA. However, whereas on some earlier +devices, applications might work without fully conforming to the rules +of DSA, these rules are now necessarily enforced. See DSA Migration Guide for information about the guidelines applications must follow in +order to be able to run correctly on a ScreenPlay device.

      The following functionality is deprecated in Symbian^3:

        + + +

      • Creating transparent windows using a mask and RWindow is deprecated. See Transparent Windows for more information.

        • +

      • Backed-up windows are deprecated. See Displayable Windows for more information.

        • +
      +
      Guide +documentation changes

      The following documentation has been added to the Windowing +collection:

        +
      • Window +Server Component Overview
        • +
      • Display +Control and Mapping in the Window Server Client
        • +
      • Transparent +Windows
        • +
      • Redraw +Drawing
        • +
      • Advanced +Pointers
        • +
      • External +Surfaces
        • + + + +
      • Window +Server Internals Concepts
        • +
      • The wsini.ini +File
        • + +

      The following documentation has been added to the OpenGLES +collection:

        +

      • OpenGLES +Collection

        • +

      The following documentation has been added to the OpenVG collection:

        +

      • OpenVG +Collection

        • +

      The following documentation has been added to the EGL collection:

        +

      • EGL +Collection

        • +

      The following documentation has been updated:

        +
      • Graphics +and Drawing
        • +
      • The Font +and Bitmap Server Overview
        • +
      +       +Graphics +Guide       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D0F6E95B-B35A-4EA1-8CC3-D86D1E0E6DD3.dita --- a/Symbian3/SDK/Source/GUID-D0F6E95B-B35A-4EA1-8CC3-D86D1E0E6DD3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D0F6E95B-B35A-4EA1-8CC3-D86D1E0E6DD3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,60 +21,52 @@ resource that defines the menu items:

      The menu is constructed only once: when HandlePointerEventL runs for the first time. Later the already constructed menu is shown again.

       -

      The following code snippets explain how to create and display Stylus pop-up -menu:

        -

      • Creating directly:

        // member variable point to the stylus Popup menu -CAknStylusPopUpMenu * iPopupMenu ; -_LIT(KItem1, "Item 1"); -_LIT(KItem2, "Item 2"); -_LIT(KItem3, "Item 3"); -_LIT(KItem4, "Item 4"); -enum StylusPopupMenuCommand - { - StylusMenuCommand1 = 0 , - StylusMenuCommand2, - StylusMenuCommand3, - StylusMenuCommand4 - }; -// create object , “this” is a object implement the interface -// MEikMenuObserver -iPopupMenu = CAknStylusPopUpMenu::NewL( this , TPoint( 0 , 0 ) ); -// add menu item -iPopupMenu->AddMenuItemL( KItem1 , StylusMenuCommand1 ); -iPopupMenu->AddMenuItemL( KItem2 , StylusMenuCommand2 ); -iPopupMenu->AddMenuItemL( KItem3 , StylusMenuCommand3 ); -iPopupMenu->AddMenuItemL( KItem4 , StylusMenuCommand4 ); -
        • -

      • Creating through resource file:

        RESOURCE STYLUS_POPUP_MENU r_stylus_popup_menu - { - items = - { - STYLUS_POPUP_MENU_ITEM - { - txt = "Menu Item 1"; - command = EStylusPopupCommand1; }, - STYLUS_POPUP_MENU_ITEM - { - txt = "Menu Item 2"; - command = EStylusPopupCommand2; }, - STYLUS_POPUP_MENU_ITEM - { - txt = "Menu Item 3"; - command = EStylusPopupCommand3; - } - }; - } -// create object -iPopupMenu = CAknStylusPopUpMenu::NewL( this , TPoint( 0 , 0 ) ); -{ - TResourceReader reader; - iCoeEnv->CreateResourceReaderLC( - reader , - R_STYLUS_POPUP_MENU ); - iPopupMenu->ConstructFromResourceL( reader ); - // destroy reader - CleanupStack::PopAndDestroy(); -} -
        • -

      +void CMyAppView::HandlePointerEventL + ( const TPointerEvent& aPointerEvent ) + { + if ( aPointerEvent.iType == TPointerEvent::EButton1Down ) + { + if ( !iMenu ) + { + iMenu = CAknStylusPopUpMenu::NewL( + iMenuObserver, + aPointerEvent.iParentPosition, + NULL ); + TInt resourceReaderId = 0; + resourceReaderId = R_MYAPP_STYLUS_MENU; + TResourceReader reader; + iCoeEnv->CreateResourceReaderLC( + reader, resourceReaderId ); + iMenu->ConstructFromResourceL( reader ); + CleanupStack::PopAndDestroy(); // reader + } + iMenu->SetPosition( aPointerEvent.iParentPosition ); + iMenu->ShowMenu(); + } + // Forward event to base class too. + CCoeControl::HandlePointerEventL( aPointerEvent ); + } + +RESOURCE STYLUS_POPUP_MENU r_myapp_stylus_menu + { + items = + { + STYLUS_POPUP_MENU_ITEM + { + txt = "Stylus Popup Menu Item 1"; + command = EMyAppMenuItemCmd1; + }, + STYLUS_POPUP_MENU_ITEM + { + txt = "Stylus Popup Menu Item 2"; + command = EMyAppMenuItemCmd2; + }, + STYLUS_POPUP_MENU_ITEM + { + txt = "Stylus Popup Menu Item 3"; + command = EMyAppMenuItemCmd3; + } + }; + } +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D0FEE812-AD80-40D8-B902-05EC16C44C42.dita --- a/Symbian3/SDK/Source/GUID-D0FEE812-AD80-40D8-B902-05EC16C44C42.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D0FEE812-AD80-40D8-B902-05EC16C44C42.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,16 +16,16 @@ IAP ID enables the applications to start a connection to a specific IAP. The application acquires a connection to the requested IAP, regardless of the existing connections.

      - -Connect to socket server . + +Connect to socket server . RSocketServ ss; ss.Connect(); - Open a RConnection object. + Open a RConnection object. RConnection conn; conn.Open( ss ); -Create a connection +Create a connection preference list and extended connection preferences object. TConnPrefList prefList; TExtendedConnPref preferences; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D15068B5-D12E-5515-A772-EA3B304EE01E_d0e354923_href.png Binary file Symbian3/SDK/Source/GUID-D15068B5-D12E-5515-A772-EA3B304EE01E_d0e354923_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D15068B5-D12E-5515-A772-EA3B304EE01E_d0e383916_href.png Binary file Symbian3/SDK/Source/GUID-D15068B5-D12E-5515-A772-EA3B304EE01E_d0e383916_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D173BE00-1DE7-53D0-BBEF-CBF7CACB0193.dita --- a/Symbian3/SDK/Source/GUID-D173BE00-1DE7-53D0-BBEF-CBF7CACB0193.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -ARM/THUMB overrides

      The ARM5 architecture supports a 32-bit instruction set (known simply as ARM) and a 16-bit instruction set called THUMB. Code compiled to one set can interoperate with the other. The Symbian platform builds tools apply the following policy when building projects: kernel-side code is built for ARM, while other code (user-side) is built for THUMB. There are a number of ways to override this policy to build user-side code also for ARM:

      • MMP file: to specify that a project should always be built as ARM, use the following keyword in the mmp file:

        ALWAYS_BUILD_AS_ARM

      • BLD.INF file: you can also specify that a project should always be built as ARM by adding a qualifier, BUILD_AS_ARM, to MMP file statements in a BLD.INF file. For example:

        PRJ_MMPFILES -..\group\commdb.mmp BUILD_AS_ARM -..\group\ced.mmp

        means that commdb is built in ARM and ced in THUMB.

      • makmake: the makmake tool accepts an option -ARM that has the same effect as if ALWAYS_BUILD_AS_ARM were supplied in the MMP file.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D18E56F1-3DB9-472D-B587-30A168E8B8C4_d0e36218_href.png Binary file Symbian3/SDK/Source/GUID-D18E56F1-3DB9-472D-B587-30A168E8B8C4_d0e36218_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D18E56F1-3DB9-472D-B587-30A168E8B8C4_d0e36385_href.png Binary file Symbian3/SDK/Source/GUID-D18E56F1-3DB9-472D-B587-30A168E8B8C4_d0e36385_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D1E80B1B-FBFD-5FBC-981C-E2D04A02EF41_d0e203822_href.png Binary file Symbian3/SDK/Source/GUID-D1E80B1B-FBFD-5FBC-981C-E2D04A02EF41_d0e203822_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D1E80B1B-FBFD-5FBC-981C-E2D04A02EF41_d0e208829_href.png Binary file Symbian3/SDK/Source/GUID-D1E80B1B-FBFD-5FBC-981C-E2D04A02EF41_d0e208829_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D1F29744-EB92-5811-A735-B0BC1B352ED5.dita --- a/Symbian3/SDK/Source/GUID-D1F29744-EB92-5811-A735-B0BC1B352ED5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D1F29744-EB92-5811-A735-B0BC1B352ED5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -36,7 +36,7 @@
      Architecture

      The Video Renderer can be implemented in two different ways, as shown in the following diagram:

      The two Video Renderer architectures - +

      Note: For simplicity, only the Multimedia Framework client/controller thread boundary has been shown; other thread boundaries may exist.

      In both architectures, the Video diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D1F4B2DC-5B18-4454-BFD7-8BB61D80E7CA.dita --- a/Symbian3/SDK/Source/GUID-D1F4B2DC-5B18-4454-BFD7-8BB61D80E7CA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D1F4B2DC-5B18-4454-BFD7-8BB61D80E7CA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -40,7 +40,7 @@ characters is increased by two items so that the table fills the entire display.

      Special character table portrait and landscape mode - +

      Default touch diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D205622E-FB0F-59C4-A039-B418B551CBFA_d0e10560_href.png Binary file Symbian3/SDK/Source/GUID-D205622E-FB0F-59C4-A039-B418B551CBFA_d0e10560_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D205622E-FB0F-59C4-A039-B418B551CBFA_d0e10676_href.png Binary file Symbian3/SDK/Source/GUID-D205622E-FB0F-59C4-A039-B418B551CBFA_d0e10676_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D222EAAA-ACF4-5837-8CDD-5EDB02EAE259_d0e407085_href.png Binary file Symbian3/SDK/Source/GUID-D222EAAA-ACF4-5837-8CDD-5EDB02EAE259_d0e407085_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D222EAAA-ACF4-5837-8CDD-5EDB02EAE259_d0e410885_href.png Binary file Symbian3/SDK/Source/GUID-D222EAAA-ACF4-5837-8CDD-5EDB02EAE259_d0e410885_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2263F64-2582-473A-B939-ACEBF8E974BF_d0e53323_href.png Binary file Symbian3/SDK/Source/GUID-D2263F64-2582-473A-B939-ACEBF8E974BF_d0e53323_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2263F64-2582-473A-B939-ACEBF8E974BF_d0e53466_href.png Binary file Symbian3/SDK/Source/GUID-D2263F64-2582-473A-B939-ACEBF8E974BF_d0e53466_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D24D5F17-462E-5424-99A7-9B16E9FEDC93.dita --- a/Symbian3/SDK/Source/GUID-D24D5F17-462E-5424-99A7-9B16E9FEDC93.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D24D5F17-462E-5424-99A7-9B16E9FEDC93.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,139 +1,132 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> -<!-- This component and the accompanying materials are made available under the terms of the License -"Eclipse Public License v1.0" which accompanies this distribution, -and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> -<!-- Initial Contributors: - Nokia Corporation - initial contribution. -Contributors: ---> -<!DOCTYPE reference - PUBLIC "-//OASIS//DTD DITA Reference//EN" "reference.dtd"> -<reference id="GUID-D24D5F17-462E-5424-99A7-9B16E9FEDC93" xml:lang="en"><title>Rconnection: -connection monitoring and management exampleThis example demonstrates the use of the RConnection API -to do connection monitoring and management. -
      Purpose

      The example demonstrates the following -features of the RConnection API:

        -

      • Opening and closing -a connection using RConnection::Open(RSocketServ& aSocketServer, -TUint aConnectionType = KConnectionTypeDefault) and RConnection::Close().

        • -

      • Starting a connection -that uses the default CommDb connection preferences, and another connection -that overrides them, using (respectively) RConnection::Start() and RConnection::Start(TConnPref& -aPref).

        • -

      • Getting the number of -connections, and retrieving information about one of them, using RConnection::EnumerateConnections(TUint& - aCount) and RConnection::GetConnectionInfo(TUint -aIndex, TDes8& aConnectionInfo).

        • -

      • Attaching a connection -to an existing interface, using RConnection::Attach(const TDesC8& -aConnectionInfo, TConnAttachType aAttachType).

        • -

      • Registering for notifications -when:

          -

        • a certain amount of -data has been sent, using RConnection::DataSentNotificationRequest(TUint -aThreshold, TPckg<TUint>& aUplinkVolume, TRequestStatus& -aStatus).

          • -

        • a certain amout of data -has been received, using RConnection::DataReceivedNotificationRequest(TUint -aThreshold, TPckg<TUint>& aDownlinkVolume, TRequestStatus& - aStatus).

          • -

        • interfaces go up and -down, using RConnection::AllInterfaceNotification(TDes8& aNotification, - TRequestStatus& aStatus).

          • -

        • the connection changes -state, using RConnection::ProgressNotification(TNifProgressBuf& -aProgress, TRequestStatus& aStatus, TUint aSelectedProgress -= KConnProgressDefault).

          • -
        • -

      • Obtaining the amount -of data transferred, using RConnection::DataTransferredRequest().

        • -

      • Obtaining the connection's -current state, using RConnection::Progress(TNifProgress& aProgress).

        • -

      • Stopping the connection, -using RConnection::Stop().

        • -

      • Closing the session -with the socket server using RSocketServ::Close().

        • -
      -
      Download

      Click on the following link to download -the example: Rconnection.zip

      Click: browse to view the example code.

      -
      Class Summary

      The example demonstrates the following -classes:

      RConnection

      RSocket

      RSocketServ

      TCommDbConnPref

      TConnectionInfoBuf

      -
      Design and implementation

      The project implements -a single class called CRConnection, that has three principal -functions:

      CRConnection::DemoApiWithoutDbOverrideL()

      This -shows how to use RConnection to:

        -

      • start a connection and -associate it with an underlying interface, using default CommDb connection -preferences,

        • -

      • get notification when -the underlying interface goes up or down,

        • -

      • get notification about -the state of a connection as it becomes fully established,

        • -

      • transfer data over a -socket,

        • -

      • get the amount of data -transferred,

        • -

      • close the connection.

        • -

      It also shows how to set up a socket to carry out data transfer.

      CRConnection::DemoApiWithDbOverrideL()

      This -is the same as DemoApiWithoutDbOverrideL() except that it:

        -

      • starts a connection -using non-default CommDb connection preferences,

        • -

      • requests notification -when a threshold amount of data has been transferred (instead of getting the -amount of data transferred).

        • -

      CRConnection::AttachToExistingInterfaceL()

      This shows -how to use RConnection to:

        -

      • open 2 connections and -start one of them (the other is not yet associated with an underlying interface),

        • -

      • get connection information -for the 1st connection and use this to attach the 2nd connection to the existing -interface,

        • -

      • get the state of the -attached connection,

        • -

      • close the connections.

        • -
      -
      Building and configuring

      You can build the example -from the IDE or the command line.

      If you use an IDE, import the bld.inf file -into your IDE, and use the build command of the IDE.

      If you use the -command line, open a command prompt, and set the current directory to the -source code directory of the example. You can then build the example using -the SBSv1 build tools with the following commands:

      bldmake -bldfiles

      abld build

      How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

      Emulator:

      Before -running the example, the emulator must be set up to use ethernet, as follows:

        -

      • Install WinPCap -4.0.2

        • -

      • Configure the emulator -using configchange.pl for -instance:

        configchange.pl --config ethernetWithCommDB --kernel -EKA2 --target winscw --variant udeb

        • -

      • Open ethernetced.xml in epoc32\winscw\c\ and -change the last 3 values in the LANBearer operation section -for "EKA2 Emulator Ethernet" in the LANBearerTable to:

        LastSocketActivityTimeout = 10 -LastSessionClosedTimeout = 10 -LastSocketClosedTimeout = 10

        i.e. change the three values from --1 to 10.

        • -

      • Save the file and then -run ced c:\ethernetced.xml from the eshell command prompt -in the emulator.

        • -

      • Download a UDP Echoserver. -An Echoserver is easily available on the internet.

        • -

      • Start the UDP Echoserver -and edit the rconnection.cpp file in the example code so -that the values for KDestAddr and KSockPort match -the values being used by the UDP Echoserver.

        • -

      • Build the application -using the commands described above and then run it.

        • -

      Hardware:

        -

      • To run the example on -an H4 board, connect the H4 to the PC/network by serial cable. Copy ethernetced.xml to -a memory card and execute:

        ced e:\ethernetced.xml

        before -running the example.

        • -
      -
      Running the example

      For the emulator, the example -builds an executable called rconnection.exe in the epoc32\release\winscw\<udeb -or urel>\ folder.

      rconnection.exe is -a console-based application. The example takes input from the user and prints -to the console information about the various stages of the example.

      + + + + + +Rconnection: connection monitoring and management exampleThis example demonstrates the use of the RConnection API to do connection monitoring and management. +
      Purpose

      The example demonstrates the following +features of the RConnection API:

        +

      • Opening and +closing a connection using RConnection::Open(RSocketServ& +aSocketServer, TUint aConnectionType = KConnectionTypeDefault) and RConnection::Close().

        • +

      • Starting a connection +that uses the default CommDb connection preferences, and another connection +that overrides them, using (respectively) RConnection::Start() and RConnection::Start(TConnPref& aPref).

        • +

      • Getting the +number of connections, and retrieving information about one of them, +using RConnection::EnumerateConnections(TUint& + aCount) and RConnection::GetConnectionInfo(TUint +aIndex, TDes8& aConnectionInfo).

        • +

      • Attaching a +connection to an existing interface, using RConnection::Attach(const +TDesC8& aConnectionInfo, TConnAttachType aAttachType).

        • +

      • Registering +for notifications when:

          +

        • a certain amount +of data has been sent, using RConnection::DataSentNotificationRequest(TUint +aThreshold, TPckg<TUint>& aUplinkVolume, +TRequestStatus& aStatus).

          • +

        • a certain amout +of data has been received, using RConnection::DataReceivedNotificationRequest(TUint +aThreshold, TPckg<TUint>& aDownlinkVolume, +TRequestStatus& aStatus).

          • +

        • interfaces go +up and down, using RConnection::AllInterfaceNotification(TDes8& +aNotification, TRequestStatus& aStatus).

          • +

        • the connection +changes state, using RConnection::ProgressNotification(TNifProgressBuf& +aProgress, TRequestStatus& aStatus, TUint +aSelectedProgress = KConnProgressDefault).

          • +
        • +

      • Obtaining the +amount of data transferred, using RConnection::DataTransferredRequest().

        • +

      • Obtaining the +connection's current state, using RConnection::Progress(TNifProgress& +aProgress).

        • +

      • Stopping the +connection, using RConnection::Stop().

        • +

      • Closing the +session with the socket server using RSocketServ::Close().

        • +
      +
      Download

      Click on the following link to +download the example: Rconnection.zip

      Click: browse to view the example code.

      +
      Class Summary

      The example demonstrates the +following classes:

      RConnection

      RSocket

      RSocketServ

      TCommDbConnPref

      TConnectionInfoBuf

      +
      Design and implementation

      The project implements +a single class called CRConnection, that has three +principal functions:

      CRConnection::DemoApiWithoutDbOverrideL()

      This shows how to use RConnection to:

        +

      • start a connection +and associate it with an underlying interface, using default CommDb +connection preferences,

        • +

      • get notification +when the underlying interface goes up or down,

        • +

      • get notification +about the state of a connection as it becomes fully established,

        • +

      • transfer data +over a socket,

        • +

      • get the amount +of data transferred,

        • +

      • close the connection.

        • +

      It also shows how to set up a socket to carry out data transfer.

      CRConnection::DemoApiWithDbOverrideL()

      This is +the same as DemoApiWithoutDbOverrideL() except that +it:

        +

      • starts a connection +using non-default CommDb connection preferences,

        • +

      • requests notification +when a threshold amount of data has been transferred (instead of getting +the amount of data transferred).

        • +

      CRConnection::AttachToExistingInterfaceL()

      This shows how to use RConnection to:

        +

      • open 2 connections +and start one of them (the other is not yet associated with an underlying +interface),

        • +

      • get connection +information for the 1st connection and use this to attach the 2nd +connection to the existing interface,

        • +

      • get the state +of the attached connection,

        • +

      • close the connections.

        • +
      +
      Building and configuring

      You can build +the example from the IDE or the command line.

      If you use an +IDE, import the bld.inf file into your IDE, and +use the build command of the IDE.

      If you use the command line, +open a command prompt, and set the current directory to the source +code directory of the example. You can then build the example using +the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld build

      Emulator:

      Before running +the example, the emulator must be set up to use ethernet, as follows:

        +

      • Install WinPCap 4.0.2

        • +

      • Configure the +emulator using configchange.pl for instance:

        configchange.pl +--config ethernetWithCommDB --kernel EKA2 --target winscw --variant +udeb

        • +

      • Open ethernetced.xml in epoc32\winscw\c\ and change the last 3 values in the LANBearer operation section for "EKA2 Emulator Ethernet" in the LANBearerTable to:

        LastSocketActivityTimeout = 10 +LastSessionClosedTimeout = 10 +LastSocketClosedTimeout = 10

        i.e. change the three +values from -1 to 10.

        • +

      • Save the file +and then run ced c:\ethernetced.xml from the eshell +command prompt in the emulator.

        • +

      • Download a UDP +Echoserver. An Echoserver is easily available on the internet.

        • +

      • Start the UDP +Echoserver and edit the rconnection.cpp file in the +example code so that the values for KDestAddr and KSockPort match the values being used by the UDP Echoserver.

        • +

      • Build the application +using the commands described above and then run it.

        • +

      Hardware:

        +

      • To run the example +on an H4 board, connect the H4 to the PC/network by serial cable. +Copy ethernetced.xml to a memory card and execute:

        ced e:\ethernetced.xml

        before +running the example.

        • +
      +
      Running the example

      For the emulator, the +example builds an executable called rconnection.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

      rconnection.exe is a console-based +application. The example takes input from the user and prints to the +console information about the various stages of the example.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D28FA4E1-6A94-4508-95B3-ACE21BCE6EA7.dita --- a/Symbian3/SDK/Source/GUID-D28FA4E1-6A94-4508-95B3-ACE21BCE6EA7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D28FA4E1-6A94-4508-95B3-ACE21BCE6EA7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,9 +26,9 @@ character string conversions and vice versa. With the help of this library, user will be able to write a hybrid application on Open C, with out knowing much about the descriptors of Symbian platform.

      -
      Download

      Click +

      Download

      Click on the following link to download the example: OpenCStringUtilitiesEx.zip

      Click: browse to view the example code.

      -
      Design and +<section id="GUID-7E7C4564-B10E-41F9-8A9D-D8A6C5E9C51C-GENID-1-10-1-13-1-1-5-1-3-1-11-1-14-1-3-3"><title>Design and Implementation

      The following sections provide information about the implementation of the example.

      Capabilities

      The program capabilities are defined in: stringutils.mmp(DLL - library): CAPABILITY @@ -47,7 +47,7 @@ how to use String-utils library (OpenCStringUtilitiesLibEx.dll) APIs. It has its own icon and can be launched from the UI both in the emulator and in the device.

      APIs demonstrated

      tbuf16towchar

      tbuf16tochar

      tbuf8towchar

      tbufC16towchar

      tbufC8tochar

      tbufC16tochar

      tbufC8towchar

      wchartotbuf16

      chartotbuf16

      wchartotbuf8

      chartotbuf8

      wchartohbufc16

      chartohbufc16

      wchartohbufc8

      chartohbufc8

      hbufC16towchar

      hbufC16tochar

      hbufC8towchar

      hbufC8tochar

      -
      Building and +<section id="GUID-67A72761-1D92-46D1-B1C9-7455978BDE4E-GENID-1-10-1-13-1-1-5-1-3-1-11-1-14-1-3-4"><title>Building and Using To build the example application, go to the OpenCStringUtilitiesEx\group directory and build the application. The definition for the whole application can be found in the bld.inf file in the group subdirectory of the applications diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2AE7E31-CAE7-5F03-8754-24172580BBAF.dita --- a/Symbian3/SDK/Source/GUID-D2AE7E31-CAE7-5F03-8754-24172580BBAF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D2AE7E31-CAE7-5F03-8754-24172580BBAF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Bluetooth Management Collection OverviewThe Bluetooth Management collection contains the Bluetooth Manager and Bluetooth Client components.
      Purpose

      The Bluetooth Management collection contains the Bluetooth Manager and Bluetooth Client components.

      Architecture
      Components

      The Bluetooth Management collection contains the following components:

      • Bluetooth Manager

        The Bluetooth Manager component stores non-volatile details of Bluetooth devices in the BT Registry using DBMS. Stored information can be retrieved, modified and deleted.

      • Bluetooth Client

        The Bluetooth Client component provides support for configuring and managing Bluetooth sockets, accessing the HCI, and configuring Bluetooth AV sessions.

      Using Bluetooth Management

      The Bluetooth Management collection has the following uses:

      • storing, retrieving, modifying and deleting details from the Bluetooth Registry using Bluetooth Manager

      • configuring and managing Bluetooth sockets, accessing the HCI and configuring Bluetooth AV sessions using the Bluetooth Client.

      \ No newline at end of file +Bluetooth Management Collection OverviewThe Bluetooth Management collection contains the Bluetooth Manager and Bluetooth Client components.
      Purpose

      The Bluetooth Management collection contains the Bluetooth Manager and Bluetooth Client components.

      Architecture
      Components

      The Bluetooth Management collection contains the following components:

      • Bluetooth Manager

        The Bluetooth Manager component stores non-volatile details of Bluetooth devices in the BT Registry using DBMS. Stored information can be retrieved, modified and deleted.

      • Bluetooth Client

        The Bluetooth Client component provides support for configuring and managing Bluetooth sockets, accessing the HCI, and configuring Bluetooth AV sessions.

      Using Bluetooth Management

      The Bluetooth Management collection has the following uses:

      • storing, retrieving, modifying and deleting details from the Bluetooth Registry using Bluetooth Manager

      • configuring and managing Bluetooth sockets, accessing the HCI and configuring Bluetooth AV sessions using the Bluetooth Client.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2CF64ED-0D85-5535-9A51-C127B10B07B2_d0e351327_href.png Binary file Symbian3/SDK/Source/GUID-D2CF64ED-0D85-5535-9A51-C127B10B07B2_d0e351327_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2CF64ED-0D85-5535-9A51-C127B10B07B2_d0e380320_href.png Binary file Symbian3/SDK/Source/GUID-D2CF64ED-0D85-5535-9A51-C127B10B07B2_d0e380320_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2DCBC1F-91B8-5F81-AAE8-546AE3EB1E29_d0e324862_href.png Binary file Symbian3/SDK/Source/GUID-D2DCBC1F-91B8-5F81-AAE8-546AE3EB1E29_d0e324862_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D2DCBC1F-91B8-5F81-AAE8-546AE3EB1E29_d0e331332_href.png Binary file Symbian3/SDK/Source/GUID-D2DCBC1F-91B8-5F81-AAE8-546AE3EB1E29_d0e331332_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D37576D8-1BD6-520B-9C69-60F2F89E4452.dita --- a/Symbian3/SDK/Source/GUID-D37576D8-1BD6-520B-9C69-60F2F89E4452.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,51 +0,0 @@ - - - - - -WINSCW-specific errors and warnings

      When you compile code for the WINSCW target, you may get errors and warnings that were not present when building for WINS or ARM targets. This page explains some possible causes of this.

      #pragma for disabling warnings

      Issue: CodeWarrior compiler ignores the #pragma - warning(...) statements that are used to disable specific Microsoft VC++ warnings.

      Resolution: consult the CodeWarrior manuals for equivalent CodeWarrior #pragma controls over specific warnings.

      Expression evaluation order

      The C++ Standard explicitly states that the order of evaluation of expressions is undefined. For example, for the line,

      x = fn1(param1) + fn2(param2);

      some compilers may evaluate fn1(param1) first, while others may evaluate fn2(param2) first. Symbian have in fact found cases where CodeWarrior, and Microsoft VC++ and GCC, differ in this behaviour. You should therefore never assume a particular order of evaluation. Note that this error may be hard to find, as program behaviour can be altered, but no compiler warnings are given.

      friend statements

      Issue: illegal 'friend' declaration compiler errors for statements of the form friend MyClass;.

      Resolution: use the syntax friend class - MyClass;.

      Identifier names not, or, and, etc.

      Issue: compiler errors when using identifiers with the names not, or, and, bitor, xor, compl, bitand, and_eq, xor_eq, or_eq, or not_eq.

      This is because these are C++ keywords (alternative token representations for some operators and punctuators).

      Resolution: modify the identifier name.

      illegal empty declaration warnings

      Issue: warnings caused by unneeded semi-colons, for example,

      class CMyClass - { -public:;

      Resolution: remove unneeded semi-colons.

      Inline assembler hex constants

      Issue: compiler errors for inline assembler hex constants specified with a trailing h, for example, 0001ah.

      Resolution: specify such constants using the C++ 0xnnnn notation.

      Inline assembler labels

      Issue: compiler errors for assembler labels of the form _asm label:.

      Resolution: use C++ labels.

      Member functions that include the class name

      Issue: illegal access/using declaration compiler errors for class member functions whose declarations include the class name, for example:

      class CMyClass - { - void CMyClass::MyFunction(); - };

      Resolution: remove the class name from the function declaration.

      Mismatched char* and unsigned char* in .c files

      Issue: illegal implicit conversion from 'unsigned - char*' to 'const char*' compiler errors when attempting to pass an unsigned char* where a const char* is required.

      CodeWarrior marks this as an error for both .c files and .cpp files; MS Visual C++ only marks it as an error for .cpp files.

      Resolution: change the declaration or call to use matching types. Alternatively, to tell CodeWarrior not to warn on this issue, use the directive:

      #pragma mpwc_relax on
      possible unwanted ';' warnings

      Issue: this warns you that a loop has no body, for example, as in the following:

      for (TInt i=0; i<10; i++); // loop ends here - f(i);

      Resolution: if a loop has no body intentionally, the warning can be removed by adding an empty body, for example,

      while (f) {};
      References to enumerated values declared later

      Issue: undefined identifier compiler errors for usage such as

      class CMyClass - { - void MyFunction(TInt a=EMyVal1); // EMyVal1 not yet defined - enum - { - EMyVal1 - }; - };

      Resolution: move the enumerator's declaration to before its first usage.

      References to pointers to const objects

      Issue: non-const '&' reference initialized to - temporary compiler errors for use of a reference to a pointer to a non-const object, where a reference to a pointer to a const object is required, for example:

      void f(const TInt64*& aNum); - -void f1() - { - TInt64* ptr; - f(ptr); - }

      Resolution: the compiler correctly cannot add const-ness at this level of indirection, as the aNum value could then be modified through the ptr pointer. Modify the code to conform with the const-ness rules.

      Reuse of variables declared in for

      Issue: CodeWarrior follows the C++ standard in limiting the lifetime of a variable declared in a for statement to the loop block. The following code thus gives an undefined identifier error for the use of i in the second for statement.

      for (TInt i=0; i<10; i++) - { - ... - } -for (i=0; i<20; i++) - { - ...

      Resolution: as Microsoft Visual C++ gives an error if, in the above case, i were to be redeclared in the second for statement. To be compatible with both compilers, declare the loop variable outside the for loop.

      sizeof(<non-static class member>) not in the context of an object of that class

      Issue: illegal use of non-static member warning for such code as:

      class CMyClass - { -public: - int iNonStaticMember; - }; - -int main() - { - printf("%d\n", sizeof(CMyClass::iNonStaticMember)); - }

      The error is produced because CMyClass::iNonStaticMember is not the name of a type, nor an expression.

      Resolution: a possible resolution is to provide a dummy object to produce a valid expression: for example,

      sizeof(((CMyClass*)0)->iStaticMember)
      Uninitialised variable warnings

      Issue: extra warnings of the form variable - 'myvariable' is not initialized before being used.

      Resolution: the warnings are correct, and the code should be corrected.

      USER 42 panics when allocating and deleting arrays

      Issue: the program panics with USER 42 when allocating and deleting arrays.

      Resolution: see Cleanup for heap arrays for details of code techniques to prevent such panics.

      Single process and memory protection

      The S in WINS and WINSCW stands for "single process". WINS/WINSCW supports multiple threads, but only a single process. This causes slight differences between WINS/WINSCW and target machines.

      As WINS/WINSCW only has a single process, each process has access to each other’s memory. This means that bad pointers may corrupt another process’s memory, resulting in bugs which would not occur on a multi-process Symbian platform implementation. Also, design bugs such as using pointers across processes do not show until code is first run on a multi-process platform.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D37E0579-0F3B-5EE4-8264-1358E493672B.dita --- a/Symbian3/SDK/Source/GUID-D37E0579-0F3B-5EE4-8264-1358E493672B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D37E0579-0F3B-5EE4-8264-1358E493672B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -27,7 +27,7 @@

      The following diagram illustrates how elements are organised within the array buffer:

      - +

      This kind of array is suitable for a small number of elements or for a moderately large but fixed maximum number of elements. It is not suitable diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D3881E09-4519-5E3F-9978-C9FEFD123B85_d0e366524_href.png Binary file Symbian3/SDK/Source/GUID-D3881E09-4519-5E3F-9978-C9FEFD123B85_d0e366524_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D3881E09-4519-5E3F-9978-C9FEFD123B85_d0e395522_href.png Binary file Symbian3/SDK/Source/GUID-D3881E09-4519-5E3F-9978-C9FEFD123B85_d0e395522_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita --- a/Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D3F52BB9-7230-499C-9BB7-CFAEDBA8F48B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ control inside its own area as illustrated in the figure below.

      Tactile feedback area priorities - +

      In both situations, the compound control wants to give one type of feedback, but there should be a different type of feedback (or no feedback at all) for diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita --- a/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -44,7 +44,7 @@

      The following diagram shows the idea:

      Transaction Commit and Revert - + Dictionary diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D430A6E4-003C-5368-893B-D7FCD5ADCAAD.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-D430A6E4-003C-5368-893B-D7FCD5ADCAAD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +TutorialsThis section describes how to use Secure Sockets. \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D45A4AE9-4169-4466-B02B-629B15C3E9AA.dita --- a/Symbian3/SDK/Source/GUID-D45A4AE9-4169-4466-B02B-629B15C3E9AA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D45A4AE9-4169-4466-B02B-629B15C3E9AA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@ to create a private key-public key pair and generate certificate requests.

      The following diagram illustrates the procedure for creating a private key, self-signed certificate and a certificate request file.

      - +       Creating diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D492CF6C-F889-4299-AC75-951EF343AC9F_d0e5978_href.png Binary file Symbian3/SDK/Source/GUID-D492CF6C-F889-4299-AC75-951EF343AC9F_d0e5978_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D492CF6C-F889-4299-AC75-951EF343AC9F_d0e6099_href.png Binary file Symbian3/SDK/Source/GUID-D492CF6C-F889-4299-AC75-951EF343AC9F_d0e6099_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D4AA635F-DF24-541A-A452-192DDBEE4142.dita --- a/Symbian3/SDK/Source/GUID-D4AA635F-DF24-541A-A452-192DDBEE4142.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D4AA635F-DF24-541A-A452-192DDBEE4142.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Processes and Data Flow

      The following figure shows the processes and data flow in the Messaging subsystem on a secured Symbian platform.

      Processes and dataflow in the Messaging subsystem -       \ No newline at end of file + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D525B9A9-6B32-535B-A282-60C85A48D3FB.dita --- a/Symbian3/SDK/Source/GUID-D525B9A9-6B32-535B-A282-60C85A48D3FB.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,123 +0,0 @@ - - - - - -Floating -point support -

      ARM provide a hardware floating point coprocessor that provides floating -point computation that is fully compliant with IEEE Std 754-1985. This is -an implementation of the ARM Vector Floating Point Architecture (VFPv2). We -refer to the coprocessor as the VFP unit.

      -

      Symbian platform supports the use of VFPv2 on platforms where the required -hardware is present in both RunFast mode and in IEEE-without-exceptions mode. -See ARM's Vector Floating-point Coprocessor Technical reference Manual for -more details on the coprocessor, its architecture, and its execution modes.

      -

      Note that Symbian platform does not support floating point exceptions in -any mode.

      -
        -

      • Using the Vector Floating Point Architecture (VFP) in an application

        • -

      • Run time check for hardware floating point

        • -

      • Execution modes

        • -
      -
      Using the Vector -Floating Point Architecture (VFP) in an application

      An application -can use VFP in two ways:

        -

      • indirectly through the -use of floating point support functions.

        • -

      • directly in its code, -either generated by the compiler, or hand-written in assembler.

        • -

      Indirect use

      By default, all applications are built -to use the floating point support functions.

      On a device without a -VFP unit, floating point support functions are implemented in software and -operate slowly. On a device with a VFP unit, the floating point support functions -are handled by the VFP unit, and operate faster than when implemented in software.

      Note -that applications do not need to make any changes to take advantage of VFP-enabled -floating point support functions, if they are provided in the device's ROM. -Such functions are used automatically at run time.

      Direct use

      To -generate VFP specific code at compile time, you need to add -the armfpu statement -with the vfpv2 keyword into your .mmp file:

      armfpu vfpv2

      On -a device with a VFP unit, this option results in code that runs faster than -the floating point support functions generated by armfpu - softvfp. Note, however, that binaries generated with VFP specific -code do not work on devices without a VFP unit - any call to VFP specific -code results in a KERN-EXEC 3 panic.

      On those devices that have a -VFP unit, the functions supplied in the Math class, that -perform trigonometric and transcendental operations may also be implemented -using VFP specific code. This is transparent to application code.

      -
      Run time check -for hardware floating point

      An application can find out at run -time whether a device supports hardware floating point by calling HAL::Get(), -using the EHardwareFloatingPoint attribute. The following -code fragment shows how you would do this:

      ... -TInt supportedFp; - -TInt HalVfp = HAL::Get(HALData::EHardwareFloatingPoint, supportedFp); -if (HalVfp == KErrNone && (supportedFp & EFpTypeVFPv2)) - { - // HAL says that we have a VFP unit - ... - } -else - { - // HAL says that we do NOT have a VFP unit - ... - } -... -

      Note that, strictly speaking, the return value from HAL::Get() indicates -whether or not the attribute is supported. To deduce whether hardware floating -point is supported by the device, the following logic applies:

        -

      • If the Hardware Abstraction -Layer (HAL) does not support the EHardwareFloatingPoint attribute, -then HAL::Get() returns KErrNotSupported. -This can be interpreted as meaning that the device does not support hardware -floating point.

        • -

      • If the HAL does support -the EHardwareFloatingPoint attribute, then HAL::Get() returns KErrNone. -In this case the TInt variable supportedTypes in -the above example code fragment will contain an enum value of type TFloatingPointType describing -the type of hardware floating point supported. If hardware floating point -is supported, then currently, this can only be ARM Vector Floating Point Architecture -(VFPv2) as indicated by the EFpTypeVFPv2 enum value.

        • -
      -
      Execution modes

      Symbian -platform can support the two execution modes: RunFast and IEEE-without-exceptions.

      - - - -

      RunFast

      -

      In this mode, denormalised numbers, i.e. those outside the range -of normal floating point values, are treated as zero, and a default NaN (Not -a Number) value is used for all NaN situations regardless -of the inputs.

      -       - -

      IEEE-without-exceptions

      -

      In this mode, denormalised numbers are treated as their actual values, -and the IEEE754-mandated values for NaN s are used.

      The -floating point model mandated by the Java specification is identical to this -mode, and means that this mode is sufficient to implement a VFP-accelerated -JVM.

      -       - - -

      An application can set (and check) the execution mode at run time -by calling User::SetFloatingPointMode(), and passing one -of the TFloatingPointMode enum values, which represent -the possible modes.

      The function can still be used even if hardware -floating point is not supported. In this case it returns KErrNotSupported.

      Applications -that do not require NaN values to be as specified by IEEE754 -and are not concerned with accuracy when dealing with very small (denormalised) -quantities, can select RunFast mode for a possible performance -increase. Games or 3D engines are likely to fall into this category. Applications -that require accurate IEEE754 interpretations, such as the JVM, can explicitly -select IEEE-without-exceptions mode, and if this fails as -being unsupported, refuse to run.

    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D52E98C3-F5EE-4CE1-A4F5-2EF41A066B8A.dita --- a/Symbian3/SDK/Source/GUID-D52E98C3-F5EE-4CE1-A4F5-2EF41A066B8A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D52E98C3-F5EE-4CE1-A4F5-2EF41A066B8A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,33 +9,31 @@ --> -Creating -resource header files -

    Typically when you create an application, there are cases where you -need to create an enumerated set of command IDs (which are symbols with integer -values). These defined symbols can then be used in both your code and resource -files. Common examples of these cases, include:

    +Creating resource header files +

    Typically when you create an application, there are cases where +you need to create an enumerated set of command IDs (which are symbols +with integer values). These defined symbols can then be used in both +your code and resource files. Common examples of these cases, include:

      -

    • Custom command IDs used for mapping mobile device user input -based upon Options menu selections to command handling. -These custom command IDs are mapped to the text displayed for the command -in the Options menu in resource files, and then are passed -back to the application by the application framework.

      • -

    • Control IDs in dialogs to allow references to the dialog -controls from C++ code.

      +

    • Custom command IDs used for mapping mobile device +user input based upon Options menu selections +to command handling. These custom command IDs are mapped to the text +displayed for the command in the Options menu +in resource files, and then are passed back to the application by +the application framework.

      • +

    • Control IDs in dialogs to allow references to the +dialog controls from C++ code.

      -

      For more information on control IDs for dialogs, see Using -Dialogs API.

      +

      For more information on control IDs for dialogs, see Using Dialogs API.
      • -

    • Application view IDs. Note that these could also be enumerated -in the header files for the views.

      • -

    • IDs for other resource structures, such as for TABS in -the status pane.

      • +

    • Application view IDs. Note that these could also +be enumerated in the header files for the views.

      • +

    • IDs for other resource structures, such as for TABS in the status pane.

    -

    These enumerated values need to be defined in a resource file, which -by convention has the extension hrh, The syntax is as -follows:

    +

    These enumerated values need to be defined in a resource file, +which by convention has the extension hrh, The +syntax is as follows:

    enum TCommandIds { ECmdAppTest1 = 1, @@ -49,28 +47,27 @@ };

    where

      -

    • enum is the keyword declaration the -set of integer values.

      +

    • enum is the keyword declaration +the set of integer values.

      Use this keyword for each set of enumerated values you defined.
      • -

    • TCommandIds is a label for the list -of enumerated values. This label is not used in the code or resource files.

      -
      • -

    • ECmdAppTest1 is a symbol that can be -used in your code or resource files.

      • -

    • = is the operator used for setting the -value to the symbol.

      • -

    • 1 is the specific value assigned to -the enumerator symbol.

      • +

    • TCommandIds is a label for the +list of enumerated values. This label is not used in the code or resource +files.

      • +

    • ECmdAppTest1 is a symbol that +can be used in your code or resource files.

      • +

    • = is the operator used for setting +the value to the symbol.

      • +

    • 1 is the specific value assigned +to the enumerator symbol.

    -

    Each enumerator is followed by a comma (,) except for -the last value. It is recommended to have a final semi colon (;) -after the enumerated list. If a specific value is not assigned to a symbol -in the enumerated list, then the value is that of the previous enumerator -plus one. Thus, the value for ECmdView1Cmd1 above is -2.

    -

    For more information about the use of the enum statement, -see ENUM statement.

    +

    Each enumerator is followed by a comma (,) +except for the last value. It is recommended to have a final semi +colon (;) after the enumerated list. If a specific +value is not assigned to a symbol in the enumerated list, then the +value is that of the previous enumerator plus one. Thus, the value +for ECmdView1Cmd1 above is 2.

    +

    For more information about the use of the enum statement, see ENUM statement.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D5358527-5E6F-5158-8BCB-F9D74DB9B354.dita --- a/Symbian3/SDK/Source/GUID-D5358527-5E6F-5158-8BCB-F9D74DB9B354.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -wcharentrypoint

    wcharentrypoint

    Use wcharentrypoint statement to specify that the entry point for a standard EXE is wide character (wmain). Otherwise, the default entry point for a standard EXE is narrow character (main).

    This enables the toolchain to include either of the following libraries based on the type of entry point:

    • libcrt0.lib — To support the narrow character entry point, if wcharentrypoint statement is not included in the .mmp file.

    • libwcrt0.lib — To support the wide character entry point, if wcharentrypoint statement is included in the .mmp file.

    The wcharentrypoint statement is supported only on ARM ABI and Symbian emulator compliant platforms, such as, ARMv5, ARMv5_ABIv2, GCCE and WINSCW.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D53A00E4-CF37-5F11-8D15-C5ECCCE64597.dita --- a/Symbian3/SDK/Source/GUID-D53A00E4-CF37-5F11-8D15-C5ECCCE64597.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D53A00E4-CF37-5F11-8D15-C5ECCCE64597.dita Tue Jul 20 12:00:49 2010 +0100 @@ -64,7 +64,7 @@ it must provide a callback pointer of the MHWRMVibraObserver implementing class for the NewL() method.

    Vibra API Interfaces - +
    Tactile vibration feedback

    Tactile vibration is used in many touch screen devices to provide vibration feedback to the user diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D541AD43-0832-57CB-BFB3-2FE386942F9B.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-D541AD43-0832-57CB-BFB3-2FE386942F9B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,12 @@ + + + + + +Handling of Multiple Clients

    Overview

    The Contacts Model uses a Client Server architecture. Many clients can send requests to the server for operations on one or more contacts databases.

    In the case where multiple clients are accessing the same database the server will attempt to process the requests sequentially.

    Requests are usually carried out immediately:

    • The request is valid for the current state and is processed

    • The request is not valid for the current state and is completed by leaving with an appropriate error code

    There are however two scenarios where a request cannot be processed immediately:

    • The request needs to open or modify a contact item currently locked by any session

    • The current state of the server prevents the request from being carried out

    In both of these cases the request is queued with the expectation that the condition preventing its completion will soon cease.

    When a contact item is unlocked, or the state of the server changes, an attempt is made to execute the first request in the queue. If the request still cannot be processed it is once again added to the queue. This activity is repeated for all queued requests.

    A request will only remain in the queue for a defined period known as the operation timeout. At the end of this period the client’s request will be completed by leaving with an error code appropriate for the request. These error codes conform to the values used in the previous version of the Contacts Model.

    Setting the Operation Timeout Value

    The following API is used to set the operation timeout value:

    void CContactDatabase::SetOperationTimeOutL(const TInt aMilSeconds) const

    Parameter

    aMilSeconds

    The operation timeout in milliseconds. This timeout is only applied to requests sent by clients of this database after this time.

    Implementation Considerations

    By default the operation timeout is 1 second. You may wish to change this value based on the way in which the application layer uses the Contacts Model.

    The timeout is set per session – multiple clients using the same database can specify independent values for the operation timeout.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D553D41C-D724-510A-A239-66CC158D6984.dita --- a/Symbian3/SDK/Source/GUID-D553D41C-D724-510A-A239-66CC158D6984.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -nostdcpp

    nostdcpp

    This keyword must be included in the project specification file (.mmp) to build a standard target (STDEXE, STDDLL, and STDLIB) using the Symbian C++ semantics for global new operator. To know how the global new operator is handled in standard C++ and Symbian C++, refer to Standard C++ Library in the Generic Open Libraries (P.I.P.S.).

    By default all standard targets use the standard C++ semantics for global new operator.

    Note: If an .mmp file includes both nostdcpp and stdcpp keywords, the build system will ignore the keywords and use the standard C++ semantics to build the target.

    See also

    stdcpp

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D5A05EE7-5559-55CC-A839-478B4F513CE4_d0e204270_href.png Binary file Symbian3/SDK/Source/GUID-D5A05EE7-5559-55CC-A839-478B4F513CE4_d0e204270_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D5A05EE7-5559-55CC-A839-478B4F513CE4_d0e209277_href.png Binary file Symbian3/SDK/Source/GUID-D5A05EE7-5559-55CC-A839-478B4F513CE4_d0e209277_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D5A6A5C9-A959-5CE7-AF45-43DA7D8B2EFF.dita --- a/Symbian3/SDK/Source/GUID-D5A6A5C9-A959-5CE7-AF45-43DA7D8B2EFF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D5A6A5C9-A959-5CE7-AF45-43DA7D8B2EFF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Introduction to Pictures

    A picture is an object which can be drawn to a graphics context and can be stored and restored. A picture is stored, together with its picture header, in any type of store using a storemap.

    Relationship between picture headers and pictures in a store -

    A picture can thus be any object which draws an image — be it a bitmap or a set of graphic commands.

    Additionally, two common desirable facilities for a picture to have are:

    • the ability to be cropped

    • the ability to be scaled

    Scaling can be done in one of three ways:

    • by specifying percentage scale factors for the width and height

    • by specifying the picture size in pixels

    • by specifying the picture size in twips

    Cropping can be done in two ways:

    • by specifying a set of margins in twips

    • by specifying a further set of margins in pixels, for additional cropping

    The drawing operation positions and draws the scaled and cropped picture on the graphics device.

    +

    A picture can thus be any object which draws an image — be it a bitmap or a set of graphic commands.

    Additionally, two common desirable facilities for a picture to have are:

    • the ability to be cropped

    • the ability to be scaled

    Scaling can be done in one of three ways:

    • by specifying percentage scale factors for the width and height

    • by specifying the picture size in pixels

    • by specifying the picture size in twips

    Cropping can be done in two ways:

    • by specifying a set of margins in twips

    • by specifying a further set of margins in pixels, for additional cropping

    The drawing operation positions and draws the scaled and cropped picture on the graphics device.

    The relationships between the picture classes -     Picture Concepts Picture Tutorials     \ No newline at end of file + Picture Concepts Picture Tutorials \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita --- a/Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,13 +26,13 @@ a mutex and vests ownership of the handle in the thread.

    Thread-relative handle - +

    Compare with the following case where ownership of the mutex handle is vested in the process.

    Process-relative handle - +

    In both cases, the mutex object is added to the appropriate Kernel container which can be considered as the owner of the object.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D62A282E-9DEA-5EF3-A606-20647BC5049D.dita --- a/Symbian3/SDK/Source/GUID-D62A282E-9DEA-5EF3-A606-20647BC5049D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D62A282E-9DEA-5EF3-A606-20647BC5049D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,6 +9,125 @@ --> -Audio Client Overview

    This document provides an overview of the Audio Client.

    Purpose

    The Audio Client provides an interface to:

    • Play back, record, and convert sound clips.

    • Play tone sequences and DTMF (Dual-Tone Multi-Frequency) strings.

    Audio Client Library Details

    The DLL that provides the functionality and the library to which your code must link is identified below.

    DLL LIB Short Description

    mediaclientaudio.dll

    mediaclientaudio.lib

    These files are used for implementing the Audio Client.

    Architectural Relationship

    The methods for recording, converting, and playing audio clips or tones interact with the lower levels of MMF (known as the controller framework). The controller framework is in turn responsible for managing the interface to audio hardware. On some phones, this is implemented as a device driver; on others it may be implemented as a connection to a lower level hardware controller.

    Clients using any of the CMdaAudioRecorderUtility, CMdaAudioConvertUtility, CMdaAudioPlayerUtility or CMdaAudioToneUtility classes must have an active scheduler running in their thread because the implementations use active objects and callbacks.

    How the tone player class interacts with other components of MMF is shown below.

    - Audio tone player overview -
    Description

    Audio Playing, Recording, and Conversion

    All three of the audio classes are plugin based, leaving the list of supported audio formats for input and output open ended. The audio file formats supported as standard by MMF are: AU, WAV and raw audio data. Each file format may support one or more compression algorithms (codecs). The standard file formats and corresponding codecs are shown below:

    Audio file format Codecs supported

    AU

    A-Law, mu-law, signed 16 bit PCM big-endian, signed 8 bit PCM

    WAV

    IMA-ADPCM, A-Law, mu-law, unsigned 8 bit PCM, gsm 6.10, signed 16 bit PCM

    raw data

    Signed big-endian 16 bit PCM, signed 16 bit PCM, unsigned 16 bit PCM

    Input and output audio data can be of any format supported by the installed plugins. When possible MMF uses a plugin resolver to determine the format and codecs to use. It determines this by checking the filename extension and reading any header data that may be present in the audio clip. The plugin resolver cannot determine the format and codecs to use for raw audio, so in such cases you must specify this information yourself. A full list of supported plugins can be retrieved by using CMdaAudioConvertUtility::GetSupportedDestinationDataTypesL().

    Note: All audio clips can be uniquely identified for purposes of plugin assignment by their format (gsm z6.10, AU, WAV and so on) and their codec (for example for AU, valid codecs include A-Law, mu-law, signed 16 bit PCM big-endian, signed 8 bit PCM). Each format and codec has an arbitrary ID assigned to it by MMF and its associated plugin, for use with the "Open" functions of both CMdaAudioConvertUtility and CMdaAudioRecorderUtility.

    Tone Playing

    The Audio Client provide a simple interface for tone generation (synthesized sounds) that enables the playing of tone sequences and DTMF (Dual-Tone Multi-Frequency) strings. The tone player functionality is provided by the CMdaAudioToneUtility class and using this class you can play:

    • Single tones of a specified duration and frequency.

    • DTMF strings.

    • Sequences of tones held in files or descriptors.

    • Predefined (fixed) sequences of tones held in the mobile equipment.

    Key Audio Client Classes

    The functionality provided by the Audio Client is contained within the following classes:

    • CMdaAudioRecorderUtility

    • CMdaAudioConvertUtility

    • CMdaAudioPlayerUtility

    • CMdaAudioToneUtility

    Using the Audio Client

    Clients can use the Audio Client to:

    • Manipulate audio sources and sinks, add, retrieve and modify meta data and record audio data to files or descriptors.

    • Convert audio clips contained in files or descriptors to other formats using the default codecs provided by MMF.

    • Play audio clips contained in files, descriptors or URLs.

    • Play single tones, DTMF strings and tone sequences.

    See Also

    How to use the audio convert utility

    How to use the audio player utility

    How to use audio recorder utility

    How to use the audio tone player utility

    DevSound Overview

    \ No newline at end of file +Audio Client Overview +

    This document provides an overview of the Audio Client.

    +
    Purpose

    The Audio Client provides an interface +to:

      +

    • Play back, record, +and convert sound clips.

      • +

    • Play tone sequences +and DTMF (Dual-Tone Multi-Frequency) strings.

      • +

    Audio Client Library Details

    The DLL that provides +the functionality and the library to which your code must link is +identified below.

    + + + + +DLL +LIB +Short Description + + + + +

    mediaclientaudio.dll

    +

    mediaclientaudio.lib

    +

    These files are used for implementing the Audio Client.

    +     + + +
    +
    Architectural Relationship

    The methods +for recording, converting, and playing audio clips or tones interact +with the lower levels of MMF (known as the controller framework). +The controller framework is in turn responsible for managing the interface +to audio hardware. On some phones, this is implemented as a device +driver; on others it may be implemented as a connection to a lower +level hardware controller.

    Clients using any of the CMdaAudioRecorderUtility, CMdaAudioConvertUtility, CMdaAudioPlayerUtility or CMdaAudioToneUtility classes must have an active scheduler running in their thread because +the implementations use active objects and callbacks.

    How +the tone player class interacts with other components of MMF is shown +below.

    + Audio tone player overview + +
    +
    Description

    Audio Playing, Recording, and Conversion

    All three +of the audio classes are plugin based, leaving the list of supported +audio formats for input and output open ended. The audio file formats +supported as standard by MMF are: AU, WAV and raw audio data. Each +file format may support one or more compression algorithms (codecs). +The standard file formats and corresponding codecs are shown below:

    + + + +Audio file format +Codecs supported + + + + +

    AU

    +

    A-Law, mu-law, signed 16 bit PCM big-endian, signed 8 bit +PCM

    +     + +

    WAV

    +

    IMA-ADPCM, A-Law, mu-law, unsigned 8 bit PCM, gsm 6.10, +signed 16 bit PCM

    +     + +

    raw data

    +

    Signed big-endian 16 bit PCM, signed 16 bit PCM, unsigned +16 bit PCM

    +     + + +

    Input and output audio data can be of any format supported +by the installed plugins. When possible MMF uses a plugin resolver +to determine the format and codecs to use. It determines this by checking +the filename extension and reading any header data that may be present +in the audio clip. The plugin resolver cannot determine the format +and codecs to use for raw audio, so in such cases you must specify +this information yourself. A full list of supported plugins can be +retrieved by using CMdaAudioConvertUtility::GetSupportedDestinationDataTypesL().

    Note: All audio clips can be uniquely identified +for purposes of plugin assignment by their format (gsm z6.10, AU, +WAV and so on) and their codec (for example for AU, valid codecs include +A-Law, mu-law, signed 16 bit PCM big-endian, signed 8 bit PCM). Each +format and codec has an arbitrary ID assigned to it by MMF and its +associated plugin, for use with the "Open" functions of both CMdaAudioConvertUtility and CMdaAudioRecorderUtility.

    Tone Playing

    The Audio Client provide a simple interface for tone generation +(synthesized sounds) that enables the playing of tone sequences and +DTMF (Dual-Tone Multi-Frequency) strings. The tone player functionality +is provided by the CMdaAudioToneUtility class and +using this class you can play:

      +

    • Single tones +of a specified duration and frequency.

      • +

    • DTMF strings.

      • +

    • Sequences of +tones held in files or descriptors.

      • +

    • Predefined (fixed) +sequences of tones held in the mobile equipment.

      • +
    +
    Key Audio Client Classes

    The functionality +provided by the Audio Client is contained within the following classes:

      +

    • CMdaAudioRecorderUtility

      • +

    • CMdaAudioConvertUtility

      • +

    • CMdaAudioPlayerUtility

      • +

    • CMdaAudioToneUtility

      • +
    +
    Using the Audio Client

    Clients can use +the Audio Client to:

      +

    • Manipulate audio +sources and sinks, add, retrieve and modify meta data and record audio +data to files or descriptors.

      • +

    • Convert audio +clips contained in files or descriptors to other formats using the +default codecs provided by MMF.

      • +

    • Play audio clips +contained in files, descriptors or URLs.

      • +

    • Play single +tones, DTMF strings and tone sequences.

      • +
    +
    See Also

    How to use the audio +convert utility

    How to use the audio +tone player utility

    DevSound Overview

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D69DD425-5F93-4238-A7E9-915F24A9C9CA.dita --- a/Symbian3/SDK/Source/GUID-D69DD425-5F93-4238-A7E9-915F24A9C9CA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D69DD425-5F93-4238-A7E9-915F24A9C9CA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,9 +16,9 @@ This example uses the APIs of the message queue library to create/close message queues and send/receive messages and also get information on created message queues.

    -
    Download

    Click +

    Download

    Click on the following link to download the example: opencmessagequeuelibraryex.zip

    Click: browse to view the example code.

    -
    Design and +<section id="GUID-7E7C4564-B10E-41F9-8A9D-D8A6C5E9C51C-GENID-1-10-1-13-1-1-5-1-3-1-11-1-12-1-2-3"><title>Design and Implementation

    The following sections provide information about the implementation of the example.

    Description

    OpenCMessageQueueClientEx is a C Application that uses the Message Queue library. This application @@ -44,7 +44,7 @@ apis, an EXE is provided that creates threads and does send/receive on message queues using those exported apis.

    APIs used

    msgget

    msgctl

    msgrcv

    msgsnd

    semget

    semctl

    semop

    -
    Building and +<section id="GUID-67A72761-1D92-46D1-B1C9-7455978BDE4E-GENID-1-10-1-13-1-1-5-1-3-1-11-1-12-1-2-4"><title>Building and Using To build the Message Queue Library example application, go to the OpenCMessageQueueLibraryEx\group directory and build the application. The Message Queue Library application consists of two modules, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D6B332EB-D9D7-5598-98C7-E73164A2057D_d0e252535_href.jpg Binary file Symbian3/SDK/Source/GUID-D6B332EB-D9D7-5598-98C7-E73164A2057D_d0e252535_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D6B332EB-D9D7-5598-98C7-E73164A2057D_d0e257464_href.jpg Binary file Symbian3/SDK/Source/GUID-D6B332EB-D9D7-5598-98C7-E73164A2057D_d0e257464_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D6BB18FE-289D-546F-97DC-389B57B5B2E3.dita --- a/Symbian3/SDK/Source/GUID-D6BB18FE-289D-546F-97DC-389B57B5B2E3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D6BB18FE-289D-546F-97DC-389B57B5B2E3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -22,7 +22,7 @@ Frameworks collection.

    Multimedia APIs and Frameworks Architectural Overview - +
    Description

    The Multimedia Framework overview details the architecture of the components that constitutes the Multimedia APIs and diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D6BE4647-25A8-5F88-9137-F4882AF22BCF.dita --- a/Symbian3/SDK/Source/GUID-D6BE4647-25A8-5F88-9137-F4882AF22BCF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D6BE4647-25A8-5F88-9137-F4882AF22BCF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Setting the Text Cursor

    A text cursor (TTextCursor) is a rectangular area which can optionally be set to flash. It has a height, width, ascent and origin, illustrated below.

    Text cursor -

    The text cursor is positioned on screen by specifying an offset between its origin and the origin of a window. It can be added to a window group using RWindowGroup::SetTextCursor().

    Two predefined types of text cursors are provided: solid and hollow rectangles. In addition bitmaps can be used as text cursors. Custom text cursors are added to the Window Server using RWsSession::SetCustomTextCursor(). They have a unique identifier, which is used by RWindowGroup::SetTextCursor(). They are clipped if too large and their vertical alignment can be adjusted.

    Sprites and Cursors \ No newline at end of file +

    The text cursor is positioned on screen by specifying an offset between its origin and the origin of a window. It can be added to a window group using RWindowGroup::SetTextCursor().

    Two predefined types of text cursors are provided: solid and hollow rectangles. In addition bitmaps can be used as text cursors. Custom text cursors are added to the Window Server using RWsSession::SetCustomTextCursor(). They have a unique identifier, which is used by RWindowGroup::SetTextCursor(). They are clipped if too large and their vertical alignment can be adjusted.

    Sprites and Cursors \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D729593E-C131-5F67-BF0C-6C9AD847C9F9_d0e322196_href.png Binary file Symbian3/SDK/Source/GUID-D729593E-C131-5F67-BF0C-6C9AD847C9F9_d0e322196_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D729593E-C131-5F67-BF0C-6C9AD847C9F9_d0e328666_href.png Binary file Symbian3/SDK/Source/GUID-D729593E-C131-5F67-BF0C-6C9AD847C9F9_d0e328666_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e58942_href.png Binary file Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e58942_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59085_href.png Binary file Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59085_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59705_href.png Binary file Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59705_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59848_href.png Binary file Symbian3/SDK/Source/GUID-D74C4403-1516-4C8F-B457-98BA0F97718A_d0e59848_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D754C477-DB73-56F7-A135-13E1179CBB2D_d0e398384_href.png Binary file Symbian3/SDK/Source/GUID-D754C477-DB73-56F7-A135-13E1179CBB2D_d0e398384_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D754C477-DB73-56F7-A135-13E1179CBB2D_d0e402179_href.png Binary file Symbian3/SDK/Source/GUID-D754C477-DB73-56F7-A135-13E1179CBB2D_d0e402179_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D76B1999-E118-585B-A6B4-8AE8CCCB6F8B.dita --- a/Symbian3/SDK/Source/GUID-D76B1999-E118-585B-A6B4-8AE8CCCB6F8B.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,19 +0,0 @@ - - - - - -paged -

    paged

    -

    Use the paged statement to specify that the executable -is code-paged. This is the same as specifying the pagedcode keyword -for an executable.

    -

    You can also mark an executable as paged using the OBY file keyword file[[HWVD]]. For more information about the file[[HWVD]] keyword, refer to the ROM Tools Guide in the Application Development -Toolkit available for download at http://developer.symbian.org.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D7DF85A8-1F90-5EC8-9EA1-EB33382849B0.dita --- a/Symbian3/SDK/Source/GUID-D7DF85A8-1F90-5EC8-9EA1-EB33382849B0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D7DF85A8-1F90-5EC8-9EA1-EB33382849B0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,34 +1,31 @@ - - - - - -TAndRClasses: -typical ‘T’ and ‘R’ type classes -
    Description

    TAndRClasses shows -a typical ‘T’ class and a typical ‘R’ class.

    The ‘T’ type is a value -type, owning no external object.

    The ‘R’ type is a resource type; -typically this is proxy for an object owned elsewhere. In practice, the 'R' -type is a handle to a resource owned and managed by the Kernel.

    In -this example, the ‘R’ class derives from the standard Symbian platform handle -class RTimer.

    -
    Download

    Click on the following link to download -the example: TAndRClasses.zip

    Click on the following link -to download additional files: CommonFramework.zip

    Click browse TAndRClasses to view the example code.

    Click CommonFramework to view additional files.

    -
    Class summary

    RTimer TCleanupItem CleanupStack TRequestStatus

    -
    Build

    The example includes the two project files -needed for building: bld.inf and the .mmp file.

    The Symbian platform build -process describes how to build this application, which results in an -executable called:

    \epoc32\release\<target>\<urel -or udeb>\TANDRCLASSES.EXE.

    -
    Usage

    Run the executable TANDRCLASSES.EXE.

    Executables -for the emulator targets wins and winscw can -be run on your PC. Executables for ARM targets must be copied to your target -platform before being run.

    + + + + + +TAndRClasses: typical ‘T’ and ‘R’ type classes +
    Description

    TAndRClasses shows a typical ‘T’ class and a typical ‘R’ class.

    The ‘T’ +type is a value type, owning no external object.

    The ‘R’ type +is a resource type; typically this is proxy for an object owned elsewhere. +In practice, the 'R' type is a handle to a resource owned and managed +by the Kernel.

    In this example, the ‘R’ class derives from +the standard Symbian platform handle class RTimer.

    +
    Download

    Click on the following link to +download the example: TAndRClasses.zip

    Click on the following +link to download additional files: CommonFramework.zip

    Click browse TAndRClasses to view the example code.

    Click CommonFramework to view additional files.

    +
    Class summary

    RTimer TCleanupItem CleanupStack TRequestStatus

    +
    Build

    The example includes the two project +files needed for building: bld.inf and the .mmp file.

    The Symbian platform build process +describes how to build this application, which results in an executable +called:

    \epoc32\release\<target>\<urel +or udeb>\TANDRCLASSES.EXE.

    +
    Usage

    Run the executable TANDRCLASSES.EXE.

    Executables for the emulator targets wins and winscw can be run on your PC. Executables +for ARM targets must be copied to your target platform before being +run.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D7E5FECF-0B29-5908-A163-37036DF165E1_d0e78765_href.png Binary file Symbian3/SDK/Source/GUID-D7E5FECF-0B29-5908-A163-37036DF165E1_d0e78765_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D7E5FECF-0B29-5908-A163-37036DF165E1_d0e78813_href.png Binary file Symbian3/SDK/Source/GUID-D7E5FECF-0B29-5908-A163-37036DF165E1_d0e78813_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D7F000F0-019A-486E-BB0C-C0065D08C5F6_d0e5850_href.png Binary file Symbian3/SDK/Source/GUID-D7F000F0-019A-486E-BB0C-C0065D08C5F6_d0e5850_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D7F000F0-019A-486E-BB0C-C0065D08C5F6_d0e5971_href.png Binary file Symbian3/SDK/Source/GUID-D7F000F0-019A-486E-BB0C-C0065D08C5F6_d0e5971_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D81EAF75-EF8C-4B62-8866-439E29325E8A_d0e12620_href.png Binary file Symbian3/SDK/Source/GUID-D81EAF75-EF8C-4B62-8866-439E29325E8A_d0e12620_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D81EAF75-EF8C-4B62-8866-439E29325E8A_d0e12723_href.png Binary file Symbian3/SDK/Source/GUID-D81EAF75-EF8C-4B62-8866-439E29325E8A_d0e12723_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8302B04-D850-5FA7-A1AD-F5C40CF6A1EF.dita --- a/Symbian3/SDK/Source/GUID-D8302B04-D850-5FA7-A1AD-F5C40CF6A1EF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D8302B04-D850-5FA7-A1AD-F5C40CF6A1EF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ provided by a combination of AIF and caption files, has been split into two categories:

    The diagram below shows the new file structure used to provide application information.

    - +

    • A registration file which 'points' to one of three localizable resource files provided. If the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D84847BB-523D-5057-8F14-F6BCEECA2327_d0e185542_href.jpg Binary file Symbian3/SDK/Source/GUID-D84847BB-523D-5057-8F14-F6BCEECA2327_d0e185542_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D84847BB-523D-5057-8F14-F6BCEECA2327_d0e190538_href.jpg Binary file Symbian3/SDK/Source/GUID-D84847BB-523D-5057-8F14-F6BCEECA2327_d0e190538_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8837969-74D0-5E17-AD42-3F10DD1FD5BF.dita --- a/Symbian3/SDK/Source/GUID-D8837969-74D0-5E17-AD42-3F10DD1FD5BF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D8837969-74D0-5E17-AD42-3F10DD1FD5BF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -121,7 +121,7 @@ to which the EXE is linked. The loader uses the version number in the import table to select the correct version of the DLL. The following flowchart shows how the loader selects the DLL from the set of possible DLLs.

      - +

    • If there are no DLLs that meet the requirements, the load fails.

      • @@ -195,7 +195,7 @@ number in RLibrary::Load(), the loader selects a version of the DLL from the set. The following flowchart shows how the loader selects the DLL from the set of possible DLLs.

      - +

    • If there are no DLLs that meet the requirements, the load fails.

      • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e51851_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e51851_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e51994_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e51994_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e58489_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e58489_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e58632_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e58632_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e69091_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e69091_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e69115_href.png Binary file Symbian3/SDK/Source/GUID-D8D65830-CC9D-4E9F-A206-34BB077E89E6_d0e69115_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita --- a/Symbian3/SDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -49,7 +49,7 @@ following diagram shows the key components in the Symbian Foundation Graphics package and some closely related components in other packages.

      Symbian^3 component architecture - +

      The key ScreenPlay components are introduced below under separate subheadings.

    Graphics Composition

    The @@ -100,14 +100,14 @@ on the S60 middleware layer, in particular on the Hitchcock component (which is in the UI Accelerator package).

    Render stage solution A - +

    Another possible solution (called solution B) is based on the DirectGDI and Graphics Resource components (which are described next), both of which have interface and adaptation layers. This solution is not full featured. Like the previous diagram, this diagram focuses on the more relevant components and does not attempt to show everything.

    Render stage solution B - +

    Both of these render stage solutions mean that existing Window Server applications can take advantage of hardware acceleration if it is available (and therefore run faster) without recompiling the code.

    ScreenPlay diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D96EE819-DEA9-5B1A-AA94-4AC065C73697.dita --- a/Symbian3/SDK/Source/GUID-D96EE819-DEA9-5B1A-AA94-4AC065C73697.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D96EE819-DEA9-5B1A-AA94-4AC065C73697.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@

    The following diagram illustrates how elements are organised within the array buffer:

    - +

    This kind of array is suitable for large arrays with a high turnover of elements.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D99BA4CA-9823-4968-953D-36AA7F266B39_d0e12054_href.png Binary file Symbian3/SDK/Source/GUID-D99BA4CA-9823-4968-953D-36AA7F266B39_d0e12054_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D99BA4CA-9823-4968-953D-36AA7F266B39_d0e12157_href.png Binary file Symbian3/SDK/Source/GUID-D99BA4CA-9823-4968-953D-36AA7F266B39_d0e12157_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9C4D520-821D-5097-A63C-0BF4C7F59827_d0e267518_href.png Binary file Symbian3/SDK/Source/GUID-D9C4D520-821D-5097-A63C-0BF4C7F59827_d0e267518_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9C4D520-821D-5097-A63C-0BF4C7F59827_d0e272373_href.png Binary file Symbian3/SDK/Source/GUID-D9C4D520-821D-5097-A63C-0BF4C7F59827_d0e272373_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e51973_href.png Binary file Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e51973_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e52116_href.png Binary file Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e52116_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e69180_href.png Binary file Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e69180_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e69204_href.png Binary file Symbian3/SDK/Source/GUID-D9F3D83E-50C7-4D15-839C-F225D95865B0_d0e69204_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DA070DA3-CE2E-5B4E-834F-32BED736E01D_d0e79411_href.png Binary file Symbian3/SDK/Source/GUID-DA070DA3-CE2E-5B4E-834F-32BED736E01D_d0e79411_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DA070DA3-CE2E-5B4E-834F-32BED736E01D_d0e79469_href.png Binary file Symbian3/SDK/Source/GUID-DA070DA3-CE2E-5B4E-834F-32BED736E01D_d0e79469_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DA2C605B-6CCF-4039-BD02-DD4BDA003C97_d0e41499_href.png Binary file Symbian3/SDK/Source/GUID-DA2C605B-6CCF-4039-BD02-DD4BDA003C97_d0e41499_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DA2C605B-6CCF-4039-BD02-DD4BDA003C97_d0e41657_href.png Binary file Symbian3/SDK/Source/GUID-DA2C605B-6CCF-4039-BD02-DD4BDA003C97_d0e41657_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DA793067-32DD-5D4D-A0E6-E05DF9047529.dita --- a/Symbian3/SDK/Source/GUID-DA793067-32DD-5D4D-A0E6-E05DF9047529.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -export

    abld export ( ( [-c] | [-w] ) | ( [-k] [-v] ) )

    This command copies all the files to be exported from source to their destinations, as defined in the prj_exports section of the component description file.

    Each destination file is only created if it does not exist or has an earlier datestamp than the corresponding source file.

    The directories which will contain the destination files will be created automatically if they do not exist.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e58905_href.png Binary file Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e58905_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59048_href.png Binary file Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59048_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59307_href.png Binary file Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59307_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59450_href.png Binary file Symbian3/SDK/Source/GUID-DAB7AB0C-8B32-4472-8EDC-AA8A5A01205C_d0e59450_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAC32BB9-C0EB-42FF-A596-C2F1A90A4BD7.dita --- a/Symbian3/SDK/Source/GUID-DAC32BB9-C0EB-42FF-A596-C2F1A90A4BD7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DAC32BB9-C0EB-42FF-A596-C2F1A90A4BD7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -49,7 +49,7 @@ a view is; however, it does provide support for a view being a display page on the screen

    -Controller-view hierarchy in traditional and Symbian architectures +Controller-view hierarchy in traditional and Symbian architectures

    In practice, the view concept varies depending upon your chosen architecture approach:

    Traditional architecture diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAD40CCE-EA59-4DCA-8922-824B18F0387A.dita --- a/Symbian3/SDK/Source/GUID-DAD40CCE-EA59-4DCA-8922-824B18F0387A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DAD40CCE-EA59-4DCA-8922-824B18F0387A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ softkey is <b>Cancel</b>.</p> <fig id="GUID-E2A1FCE9-6EF2-4CED-A74D-F41FE9DE5C46"> <title>Multi-selection list query - +
    Using multi-selection list queries in applications

    For implementation diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAF35D49-9630-4186-A350-E8483693D50D.dita --- a/Symbian3/SDK/Source/GUID-DAF35D49-9630-4186-A350-E8483693D50D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DAF35D49-9630-4186-A350-E8483693D50D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ Hierarchical column list component, where the subtitle "Today" and "Yesterday" are expanded - +

    The hierarchical column list can have three different row types:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DAF86036-CC40-5F26-9F15-2F2093F59C03.dita --- a/Symbian3/SDK/Source/GUID-DAF86036-CC40-5F26-9F15-2F2093F59C03.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DAF86036-CC40-5F26-9F15-2F2093F59C03.dita Tue Jul 20 12:00:49 2010 +0100 @@ -59,7 +59,7 @@ the WriteDeviceData capability.

      Ideally, all older .exe s should be migrated to use the 9.1 version of Define().

      The following diagram shows the "category space".

      - +

      The KUidSecurityThresholdCategoryValue value effectively forms a threshold value. Processes with a SID value below this threshold can define a category that is different from their SID, provided diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB571D42-03F4-50F9-974D-B905707FC5F4_d0e79809_href.png Binary file Symbian3/SDK/Source/GUID-DB571D42-03F4-50F9-974D-B905707FC5F4_d0e79809_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB571D42-03F4-50F9-974D-B905707FC5F4_d0e79867_href.png Binary file Symbian3/SDK/Source/GUID-DB571D42-03F4-50F9-974D-B905707FC5F4_d0e79867_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB6EC285-F5DB-5A7A-AFF3-E423AD4B9F81-master.png Binary file Symbian3/SDK/Source/GUID-DB6EC285-F5DB-5A7A-AFF3-E423AD4B9F81-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB6EC285-F5DB-5A7A-AFF3-E423AD4B9F81_d0e461294_href.png Binary file Symbian3/SDK/Source/GUID-DB6EC285-F5DB-5A7A-AFF3-E423AD4B9F81_d0e461294_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB9F413A-35E2-577E-91C3-1D519835FAB4_d0e79537_href.png Binary file Symbian3/SDK/Source/GUID-DB9F413A-35E2-577E-91C3-1D519835FAB4_d0e79537_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DB9F413A-35E2-577E-91C3-1D519835FAB4_d0e79595_href.png Binary file Symbian3/SDK/Source/GUID-DB9F413A-35E2-577E-91C3-1D519835FAB4_d0e79595_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DBF6760F-D209-4B8F-89D5-A7EFFF7959E2.dita --- a/Symbian3/SDK/Source/GUID-DBF6760F-D209-4B8F-89D5-A7EFFF7959E2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DBF6760F-D209-4B8F-89D5-A7EFFF7959E2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,8 +14,8 @@ can open the data connection.

      To open the data connection with the selected destination network:

      - -Start the connection + +Start the connection through the Internet destination network using the Connection Manager API. Select the best available access point within the Internet destination diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC37C3A9-B03F-5699-9E05-8ADD62C2FF04_d0e8364_href.png Binary file Symbian3/SDK/Source/GUID-DC37C3A9-B03F-5699-9E05-8ADD62C2FF04_d0e8364_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC37C3A9-B03F-5699-9E05-8ADD62C2FF04_d0e8486_href.png Binary file Symbian3/SDK/Source/GUID-DC37C3A9-B03F-5699-9E05-8ADD62C2FF04_d0e8486_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC44DCFC-8549-5CDE-B6DA-F5FD73E2D9FC_d0e125271_href.jpg Binary file Symbian3/SDK/Source/GUID-DC44DCFC-8549-5CDE-B6DA-F5FD73E2D9FC_d0e125271_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC44DCFC-8549-5CDE-B6DA-F5FD73E2D9FC_d0e128891_href.jpg Binary file Symbian3/SDK/Source/GUID-DC44DCFC-8549-5CDE-B6DA-F5FD73E2D9FC_d0e128891_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e51623_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e51623_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e51766_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e51766_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e56400_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e56400_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e56543_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e56543_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e68872_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e68872_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e68896_href.png Binary file Symbian3/SDK/Source/GUID-DC4E42CA-2A65-44D7-8DBE-386F60F998A0_d0e68896_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita --- a/Symbian3/SDK/Source/GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -73,7 +73,7 @@ interface, and all require an implementation that implements that interface (shown in green).

      Key EGL relationships and dependencies - +

      The EGL Interface component provides a consistent interface to EGL on the Symbian platform, enabling cross-device compatibility. The component includes the Khronos-released diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DCA2880E-7DF9-5E60-8F87-241711935389.dita --- a/Symbian3/SDK/Source/GUID-DCA2880E-7DF9-5E60-8F87-241711935389.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DCA2880E-7DF9-5E60-8F87-241711935389.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,68 +1,68 @@ - - - - - -FeatMngrExample: -dynamic feature management exampleThis example demonstrates the use of Feature Manager APIs for dynamic -feature management. It also demonstrates how to receive notification about -changes to a feature. -

      Download

      Click on the following link to download -the example: FeatMngrExample.zip

      Click: browse to view the example code.

      -
      Purpose

      The example shows how to use the Feature Manager API. -UI vendors and device manufacturers can use this API to declare features (such -as DRM agents, codecs, vibra) as available or not. The feature set can be -adjusted dynamically as software services are installed and uninstalled or -as platform capabilities are discovered dynamically.

      This example -shows how Feature Manager APIs allow applications and system software to establish -which features are present on or absent from a Symbian device.

      -
      Design and implementation

      The example consists -of two processes:

        -

      • featmngrexample.exe: -this is the main process which provides the list of available features. It -also provides the option to add new features or delete/update a feature.

        • -

      • featurechecker.exe: -this process receives notification about new features installed or uninstalled -by the main process.

        • -

      FeatMngrExample

      This shows the use of the RFeatureControl API -to manage features.

      It presents menu options to the user to list the -available features, to add or delete a feature, update an existing feature, -and to enable or disable a feature. It also starts another process, called -featurechecker.exe which receives notifications of events happening in this -process. The list of features includes some whose feature flags are non-modifiable. -Any attempt to modify or delete those features will result in a system error --21 (KErrAccessDenied). When adding a new feature, it should -be in the range as described in the console because the featurechecker process -subscribes to this range of features for change notification.

      FeatureChecker

      This -process is started by featmngrexample.exe. It implements -the MFeatureObserver class to handle notification of feature -changes. FeatureChecker also demonstrates the use of the CFeatureNotifier class. -It implements HandleNotifyChange() to handle the changes -made by FeatMngrExample. The type of change is displayed to the user as an -infoprint message (User::InfoPrint()). HandleNotifyChange() is -called to handle changes for those features which are subscribed to for notification -(in the NotifyFeatureL () method).

      -
      Building and configuring

      To build the example:

        -

      • The example builds two -executables called featmngrexample.exe and featurechecker.exe in -the standard locations. The second executable is run by the first.

        • -

      • You can build the example -from your IDE or the command line.

        If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

        If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

        bldmake -bldfiles

        abld build

        How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

        • -
      -
      Running the example

      When running the example, the -user is presented with various menu options that are self-explanatory. Press -any other key to exit.

      -
      See also:

      Feature Management

      + + + + + +FeatMngrExample: dynamic feature management exampleThis example demonstrates the use of Feature Manager APIs +for dynamic feature management. It also demonstrates how to receive +notification about changes to a feature. +
      Download

      Click on the following link to download the example: FeatMngrExample.zip

      Click: browse to view the example code.

      +
      Purpose

      The example shows how to use the Feature Manager API. UI vendors and device manufacturers can use this API to declare +features (such as DRM agents, codecs, vibra) as available or not. +The feature set can be adjusted dynamically as software services are +installed and uninstalled or as platform capabilities are discovered +dynamically.

      This example shows how Feature Manager APIs allow +applications and system software to establish which features are present +on or absent from a Symbian device.

      +
      Design +and implementation

      The example consists of two processes:

        +

      • featmngrexample.exe: this is the main process which provides the list of available features. +It also provides the option to add new features or delete/update a +feature.

        • +

      • featurechecker.exe: this process receives notification about new features installed +or uninstalled by the main process.

        • +

      FeatMngrExample

      This shows the use of the RFeatureControl API to manage features.

      It presents +menu options to the user to list the available features, to add or +delete a feature, update an existing feature, and to enable or disable +a feature. It also starts another process, called featurechecker.exe +which receives notifications of events happening in this process. +The list of features includes some whose feature flags are non-modifiable. +Any attempt to modify or delete those features will result in a system +error -21 (KErrAccessDenied). When adding a new feature, +it should be in the range as described in the console because the +featurechecker process subscribes to this range of features for change +notification.

      FeatureChecker

      This process is +started by featmngrexample.exe. It implements +the MFeatureObserver class to handle notification +of feature changes. FeatureChecker also demonstrates +the use of the CFeatureNotifier class. It implements HandleNotifyChange() to handle the changes made by FeatMngrExample. +The type of change is displayed to the user as an infoprint message +(User::InfoPrint()). HandleNotifyChange() is called to handle changes for those features which are subscribed +to for notification (in the NotifyFeatureL () method).

      +
      Building +and configuring

      To build the example:

        +

      • The example +builds two executables called featmngrexample.exe and featurechecker.exe in the standard locations. +The second executable is run by the first.

        • +

      • You can build +the example from your IDE or the command line.

        If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

        If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld +build

        • +
      +
      Running +the example

      When running the example, the user is presented +with various menu options that are self-explanatory. Press any other +key to exit.

      +
      See +also:

      Feature Management

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DCCA3BD3-582A-5C71-A104-D922FFE3C680_d0e287427_href.png Binary file Symbian3/SDK/Source/GUID-DCCA3BD3-582A-5C71-A104-D922FFE3C680_d0e287427_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DCCA3BD3-582A-5C71-A104-D922FFE3C680_d0e292258_href.png Binary file Symbian3/SDK/Source/GUID-DCCA3BD3-582A-5C71-A104-D922FFE3C680_d0e292258_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DCFF3240-F1CD-41FF-B832-990ADF101674_d0e4725_href.png Binary file Symbian3/SDK/Source/GUID-DCFF3240-F1CD-41FF-B832-990ADF101674_d0e4725_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DCFF3240-F1CD-41FF-B832-990ADF101674_d0e4850_href.png Binary file Symbian3/SDK/Source/GUID-DCFF3240-F1CD-41FF-B832-990ADF101674_d0e4850_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD04585F-3D60-5CB2-8975-AE602B75740B_d0e398653_href.png Binary file Symbian3/SDK/Source/GUID-DD04585F-3D60-5CB2-8975-AE602B75740B_d0e398653_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD04585F-3D60-5CB2-8975-AE602B75740B_d0e402448_href.png Binary file Symbian3/SDK/Source/GUID-DD04585F-3D60-5CB2-8975-AE602B75740B_d0e402448_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574-master.png Binary file Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574_d0e315975_href.png Binary file Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574_d0e315975_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574_d0e322445_href.png Binary file Symbian3/SDK/Source/GUID-DD0F8AFB-F96C-4EAC-96DE-7D5C0597B574_d0e322445_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e184514_href.png Binary file Symbian3/SDK/Source/GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e184514_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e189511_href.png Binary file Symbian3/SDK/Source/GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e189511_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD39680E-C0CB-4D97-A921-25FACC30FBE3_d0e306771_href.jpg Binary file Symbian3/SDK/Source/GUID-DD39680E-C0CB-4D97-A921-25FACC30FBE3_d0e306771_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD39680E-C0CB-4D97-A921-25FACC30FBE3_d0e313235_href.jpg Binary file Symbian3/SDK/Source/GUID-DD39680E-C0CB-4D97-A921-25FACC30FBE3_d0e313235_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD3A519B-26D5-5920-BEF3-16273A661448_d0e49491_href.png Binary file Symbian3/SDK/Source/GUID-DD3A519B-26D5-5920-BEF3-16273A661448_d0e49491_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD3A519B-26D5-5920-BEF3-16273A661448_d0e49649_href.png Binary file Symbian3/SDK/Source/GUID-DD3A519B-26D5-5920-BEF3-16273A661448_d0e49649_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD764F2C-365A-5A5C-9412-4AF2EDB16924_d0e357582_href.png Binary file Symbian3/SDK/Source/GUID-DD764F2C-365A-5A5C-9412-4AF2EDB16924_d0e357582_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD764F2C-365A-5A5C-9412-4AF2EDB16924_d0e386575_href.png Binary file Symbian3/SDK/Source/GUID-DD764F2C-365A-5A5C-9412-4AF2EDB16924_d0e386575_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD77AA04-D0AB-4BEB-900F-B3BE50AC0B7F.dita --- a/Symbian3/SDK/Source/GUID-DD77AA04-D0AB-4BEB-900F-B3BE50AC0B7F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DD77AA04-D0AB-4BEB-900F-B3BE50AC0B7F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,38 +12,38 @@ Opening a Connection based on User SelectionExtended Connection Preferences API can be used by applications to open a connection based on user selection. -

      When an +

      When an application chooses to establish a connection based on user selection, Connection selection dialog needs to be enabled. Only the SNAPs and IAPs matching with bearer set are displayed for selection.

      - -Connect to socket server . + +Connect to socket server . RSocketServ ss; ss.Connect(); - Open a RConnection object. + Open a RConnection object. RConnection conn; conn.Open( ss ); -Create a connection +Create a connection preference list and extended connection preferences object. TConnPrefList prefList; TExtendedConnPref preferences; -Enable the Connection +Enable the Connection selection dialog to accept user queries using TExtendedConnPref::SetConnSelectionDialog(). preferences.SetConnSelectionDialog( ETrue ); -Append extended +Append extended connection preferences into connection preference list. prefList.AppendL( &preferences ); -Start a connection +Start a connection with connection preferences. conn.Start( prefList ); -

      The application +

      The application is connected to the SNAP or IAP selected by the user.

             Additional diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DD7D33BD-0DDB-584C-9362-AEECFA1EA9A7.dita --- a/Symbian3/SDK/Source/GUID-DD7D33BD-0DDB-584C-9362-AEECFA1EA9A7.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -makefile

      abld [ test ] makefile ( ( [-c] | [-w] ) | ( [-k] [-v] ) ) [ platform ] [ program]

      This command creates the makefiles for each project within your component, via makmake.

      To generate the makefiles, makmake is invoked with the -d switch, which causes the makefiles to be created in a subdirectory of epoc32\build\.

      The makefiles are always created with this command, regardless of whether the corresponding .mmp files have been changed or not.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DDA0ECF7-BC92-4AFB-998F-5FDD300655FB.dita --- a/Symbian3/SDK/Source/GUID-DDA0ECF7-BC92-4AFB-998F-5FDD300655FB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DDA0ECF7-BC92-4AFB-998F-5FDD300655FB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,8 +21,8 @@

    • c:\FileMenu.r10 is for ELangAmerican.

    - - + +

    In the application, define a string with the neutral-language resource file name.

    _LIT(KRscFilename, "C:\\FileMenu.rsc");     diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DDE06BD5-2515-59FD-B91F-4C78A768533D.dita --- a/Symbian3/SDK/Source/GUID-DDE06BD5-2515-59FD-B91F-4C78A768533D.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - --savespace

    This option removes intermediate files created during the building of a project if the build is eventually successful. If the build fails, the intermediate files remain so that errors can be corrected and an incremental rebuild of the project version that failed to build can take place.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE0E5230-A422-5859-A8DF-5E51AAA9B23A_d0e203628_href.png Binary file Symbian3/SDK/Source/GUID-DE0E5230-A422-5859-A8DF-5E51AAA9B23A_d0e203628_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE0E5230-A422-5859-A8DF-5E51AAA9B23A_d0e208635_href.png Binary file Symbian3/SDK/Source/GUID-DE0E5230-A422-5859-A8DF-5E51AAA9B23A_d0e208635_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE417474-906D-5EB8-A80D-2CBF099EC81C_d0e322882_href.jpg Binary file Symbian3/SDK/Source/GUID-DE417474-906D-5EB8-A80D-2CBF099EC81C_d0e322882_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE417474-906D-5EB8-A80D-2CBF099EC81C_d0e329352_href.jpg Binary file Symbian3/SDK/Source/GUID-DE417474-906D-5EB8-A80D-2CBF099EC81C_d0e329352_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE5FC074-75C1-5833-83B2-D25396F52732_d0e354645_href.png Binary file Symbian3/SDK/Source/GUID-DE5FC074-75C1-5833-83B2-D25396F52732_d0e354645_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DE5FC074-75C1-5833-83B2-D25396F52732_d0e383638_href.png Binary file Symbian3/SDK/Source/GUID-DE5FC074-75C1-5833-83B2-D25396F52732_d0e383638_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DEB6E162-B2AA-5DF6-B750-E833C7DE4902.dita --- a/Symbian3/SDK/Source/GUID-DEB6E162-B2AA-5DF6-B750-E833C7DE4902.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DEB6E162-B2AA-5DF6-B750-E833C7DE4902.dita Tue Jul 20 12:00:49 2010 +0100 @@ -65,7 +65,7 @@ a peer-to-peer (one on one) connection assumes the PANU role, thus becoming a client member of the piconet.

    PANU to PANU connection - +

    PAN-GN

    A PAN-GN device assumes the role of a forwarding node or host and the attached PANU devices act as clients, networking up to a maximum of seven PANUs. The @@ -85,7 +85,7 @@ role allows only a single PANU client access to the uplink for the external network.

    PAN-NAP, bridging networks - +

    The following image shows a Bluetooth-enabled laptop accessing the Internet through a mobile handset that is acting as a PAN-NAP device. The Bluetooth handset may provide the uplink via GPRS, WIFI, dial-up, or in some diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DEF3B8B3-5BD7-505B-93F9-A20CE00FFAE6.dita --- a/Symbian3/SDK/Source/GUID-DEF3B8B3-5BD7-505B-93F9-A20CE00FFAE6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DEF3B8B3-5BD7-505B-93F9-A20CE00FFAE6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -62,7 +62,7 @@

  • Preventing deadlock.

    • The diagram below shows how plugins fit into the File Server software stack.

    - +

    Note: more than one plugin can be loaded into the file server at the same time. A plugin is not aware of other plugins.

    Threads and execution context

    The Symbian platform File Server has multiple threads. There is a thread for each @@ -94,7 +94,7 @@ the plugins are not re-entrant safe this can lead to deadlock in the file server.

    File server deadlock - +

    The framework introduced in v9.5 prevents deadlock by allowing plugins to issue internal file server requests after intercepting a request by using the newly introduced RFilePlugin, RDirPlugin and RFsPlugin APIs @@ -104,7 +104,7 @@ for a typical plugin intercepting a file read request is illustrated below:

    Read request intercepted by a plugin - +

    The classes RFilePlugin, RDirPlugin and RFsPlugin have been introduced to facilitate plugins with direct access behaviour on file and directory requests. These classes are analogous to the client-side RFile, RDir and RFs classes and have functions with similar or identical signitures.

    In @@ -184,7 +184,7 @@ first plugin to be able to intercept requests.

    Plugin stack showing absolute positions - +

    The absolute position method is more appropriate for mounting plugins that operate regardless of their position in the plugin stack or when all of the plugins for a device are known and installed when manufactured. This diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF1B3C55-2CFC-49C8-88A2-D10925ECAC3E.dita --- a/Symbian3/SDK/Source/GUID-DF1B3C55-2CFC-49C8-88A2-D10925ECAC3E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DF1B3C55-2CFC-49C8-88A2-D10925ECAC3E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@ do not freeze the invalid export entries in the DEF file using the ARM RVCT compiler.

    -
    Use +<section id="GUID-DDE6596E-1A67-4219-8822-45A82C39DF0B-GENID-1-10-1-13-1-1-9-1-6-1-3-2"> <title>Use of Global Destructor

    Symbian does not invoke destructors of global objects upon program termination. For example, in the code below, the destructor ~foo() is not called upon program termination. @@ -49,7 +49,7 @@ }

    -
    Issues +<section id="GUID-DDE6596E-1A67-4219-8822-45A82C39DF0B-GENID-1-10-1-13-1-1-9-1-6-1-3-3"> <title>Issues with <codeph>new</codeph> operator

    Throwing bad_alloc or any object from new on ARMV5 platfrom crashes. RVCT reports an exception when new throws bad_alloc. The problem occurs even if the user throws any object from within an overloaded @@ -73,7 +73,7 @@ is by defining new similar to:

    void* operator new(size_t s,newarg) throw (std::bad_alloc)

    and invoking it as:

    Myclass* my = new(S60) Myclass()
    -
    The <codeph>id</codeph> Member +<section id="GUID-DDE6596E-1A67-4219-8822-45A82C39DF0B-GENID-1-10-1-13-1-1-9-1-6-1-3-4"> <title>The <codeph>id</codeph> Member Issue

    The id member variable of facet classes cannot be accessed directly, it has to be accessed via the GetFacetLocaleId() interface.

    Following code snippet is an example that illustrates how to uselocale::id while diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF37DAC3-8B86-5674-B025-931F743ED888_d0e124732_href.png Binary file Symbian3/SDK/Source/GUID-DF37DAC3-8B86-5674-B025-931F743ED888_d0e124732_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF37DAC3-8B86-5674-B025-931F743ED888_d0e128352_href.png Binary file Symbian3/SDK/Source/GUID-DF37DAC3-8B86-5674-B025-931F743ED888_d0e128352_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e46823_href.png Binary file Symbian3/SDK/Source/GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e46823_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e46981_href.png Binary file Symbian3/SDK/Source/GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e46981_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF3F2FD0-FF68-4CEF-843F-CBC9E84F3A7F.dita --- a/Symbian3/SDK/Source/GUID-DF3F2FD0-FF68-4CEF-843F-CBC9E84F3A7F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DF3F2FD0-FF68-4CEF-843F-CBC9E84F3A7F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,12 +12,12 @@ Signal pane

    The Signal pane displays the cellular signal strength indicator.

    - + Signal pane (left) - +

    The indicator may also contain information about a packet data connection (such as GPRS) status.

    -

    The Signal pane is not accessible -to applications.

    +

    The Signal pane is not +accessible to applications.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF4D7DFF-ECA9-40CF-9F3B-4BBC3F8162E4.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-DF4D7DFF-ECA9-40CF-9F3B-4BBC3F8162E4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,56 @@ + + + + + +Converting +between UTC and local time +
    Time zone ID +

    Each time zone is uniquely identified by its time zone ID which is +a numeric reference or a name. The CTzId class encapsulates +a time zone identifier. A time zone ID is created using the CTzId::NewL() factory +method, for example:

    _LIT8( KAsiaHongKong,"Asia/Hong_Kong" ); //A valid time zone name +CTzId* zoneId = CTzId::NewL( KAsiaHongKong );

    The time zone’s +numeric ID or name can be retrieved using CTzId::TimeZoneNumericID() or CTzId::TimeZoneNameID() respectively. +

    operator==() and operator!=() can +be used to check if the time zone ID matches or differs from another time +zone ID.

    +
    Converting +between UTC and local time

    You can convert between times expressed +in UTC and local time using either the CTzConverter or RTz class. +

    CTzConverter does the conversion on the client +side by caching rules which it gets from the time zone server. This class +should be used for conversion between UTC and local time for the system time +zone, for performance reasons.

    If the conversion involves foreign +time zones, the RTz class can be used instead.

    The +following types of time conversion are possible:

      +

    • UTC +to local time in any time zone

      • +

    • UTC +to local time in the system time zone

      • +

    • Local +time in the system time zone to UTC

      • +

    • Local +time in any time zone to UTC

      • +
    +
    Setting the +local time

    RTz::SetHomeTime() sets the local +time in the system time zone:

    _LIT8( KMyTime, "20050105:103000.00" ); // Local time to set (5th January 2005 10:30 hrs). +TTime myTime( KMyTime ); //Create the time as a TTime object +TInt errCode = myTZoneServer.SetHomeTime( myTime );

    The WriteDeviceData capability +is needed to set the system time.

    +
    Automatic UTC +offset

    Whenever DST begins or ends, the UTC offset needs to be updated +accordingly. This can be done automatically by calling RTz::SetAutoUpdateBehaviorL(). +This function takes a value from the TTzAutoDSTUpdateModes enum. +When set to TTzAutoDSTUpdateModes::ETZAutoDSTUpdateOn(), +the UTC offset is automatically updated for changes to DST.

    +
    See also

    Time zone conversion overview

    timezoneconversion: Using +the time zone server

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF756D6C-1E03-4EC0-B074-09611D122359.dita --- a/Symbian3/SDK/Source/GUID-DF756D6C-1E03-4EC0-B074-09611D122359.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DF756D6C-1E03-4EC0-B074-09611D122359.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,109 +1,99 @@ - - - - - -Storing -location information on a mobile device -

    Location information may -be stored as database entries called landmarks that contain at least -a name and a location.

    -

    Typical use cases include:

    -
      -

    • Sending location information that is stored according to -the World Geodetic System (WGS 84) to another device.

      • -

    • Finding sites within a set distance of a stored point.

      -
      • -
    - -

    The SDK does not include a map API, and therefore you must use a third -party API to display the location information you receive on a map. Does this also apply to S60 5th Edition?

    -     -
    Saving location -information on a mobile device -

    To store location information on your mobile device:

    -
      -

    1. Make use of -the methods of the Landmarks -API when -constructing your application.

      - -

      The CPosLandmarkDatabase class is used for accessing the database with the landmarks -information and the CPosLandmark class -contains the location information.

      -

      For detailed information on how to do this, see:

      -
        -

      • Using landmarks database for a discussion of how to -start accessing the database with the location information, including a structure -diagram.

        • -

      • Managing landmarks for code samples of opening, editing, and adding -location information to a database

        • -

      • Listening to database events for possible events type passed to -your application and code samples for implementing a listener

        - -

        The TPosLmEvent class -is used in listening for events.

        -         -
        • -
      -       -
      2. -

    2. Make sure eposlandmarks.lib is -accessible to your linker when compiling your application by including it -in your .mmp file or by editing the project properties in your IDE, depending -on your build environment.

      3. -

    3. Make sure -you have the correct capabilities information set for your application, depending -on your application you may need LocalServices, NetworkServices, ReadDeviceData, ReadUserData, WriteDeviceData, and WriteUserData.

      -
      4. -
    -
    -
    Additional information -on storing location information -

    For more information see, Question -for the reviewers: Is there anything else that we could add here?

    -
      -

    • API description for a description of the API and its class structure

      -
      • -

    • Using -the Landmarks API for a general overview on how to create applications -using the API

      • -

    • For a reference example on searching and manipulating the -information in the location database, see LocationLandmarksRefAppForS60 in -the SDK (<SDK installation directory>\S60CppExamples\)

      -
      • -

    • For a reference example on how to use common UI components -to work with landmark data, see LocationLandmarksUIRefApp in -the SDK (<SDK installation directory>\S60CppExamples\AutoAdaptedToTouchEx\)

      -
      • -
    -
    -
    Related Symbian -APIs -

    The Symbian platform also offers the following related APIs:

    -
      -

    • Landmarks -API for accessing the database

      • -

    • Landmarks Database Management API for creating and deleting databases

      -
      • -

    • Landmarks -Search API for allowing mobile devices users to search the database

      -
      • -

    • Landmarks -UI Add/Edit API for allowing mobile device users to add and edit -landmarks

      • -

    • Landmarks -UI Selector API for displaying and selecting landmarks

      • -

    • Location Acquisition API for finding the location of a mobile -device

      • -

    • Communication for -sending location information to other devices

      • -
    -
    + + + + + +Storing location information on a mobile device +

    Location +information may be stored as database entries called landmarks that contain at least a name and a location.

    +

    Typical use cases include:

    +
      +

    • Sending location information that is stored according +to the World Geodetic System (WGS 84) to another device.

      +
      • +

    • Finding sites within a set distance of a stored point.

      +
      • +
    + +

    The SDK does not include a map API, and therefore you must use +a third party API to display the location information you receive +on a map. Does this also apply +to S60 5th Edition?

    +     +
    Saving +location information on a mobile device +

    To store location information on your mobile device:

    +
      +

    1. Make +use of the methods of the Landmarks APIwhen constructing your application.

      + +

      The CPosLandmarkDatabase class is used for accessing the database with the landmarks +information and the CPosLandmark class contains the location information.

      +

      For detailed information on how to do this, see:

      +
        +

      • Using landmarks database for a discussion of how to start +accessing the database with the location information, including a +structure diagram.

        • +

      • Managing landmarks for code samples of opening, editing, +and adding location information to a database

        • +

      • Listening to database events for possible events type passed +to your application and code samples for implementing a listener

        + +

        The TPosLmEvent class is +used in listening for events.

        +         +
        • +
      +       +
      2. +

    2. Make +sure eposlandmarks.lib is accessible to your linker +when compiling your application by including it in your .mmp file +or by editing the project properties in your IDE, depending on your +build environment.

      3. +

    3. Make +sure you have the correct capabilities information set for your application, +depending on your application you may need LocalServices, NetworkServices, ReadDeviceData, ReadUserData, WriteDeviceData, and WriteUserData.

      4. +
    +
    +
    Additional +information on storing location information +

    For more information see, Question for the reviewers: Is there anything else that we could +add here?

    +
      +

    • API description for a description of the API and its class +structure

      • +

    • Using the Landmarks API for a general overview on how to +create applications using the API

      • +

    • For a reference example on searching and manipulating +the information in the location database, see LocationLandmarksRefAppForS60 in the SDK (<SDK installation directory>\S60CppExamples\)

      • +

    • For a reference example on how to use common UI components +to work with landmark data, see LocationLandmarksUIRefApp in the SDK (<SDK installation directory>\S60CppExamples\AutoAdaptedToTouchEx\)

      • +
    +
    +
    Related +Symbian APIs +

    The Symbian platform also offers the following related APIs:

    +
      +

    • Landmarks API for accessing the database

      • +

    • Landmarks Database Management API for creating and deleting +databases

      • +

    • Landmarks Search API for allowing mobile devices users +to search the database

      • +

    • Landmarks UI Add/Edit API for allowing mobile device users +to add and edit landmarks

      • +

    • Landmarks UI Selector API for displaying and selecting +landmarks

      • +

    • Location Acquisition API for finding the location +of a mobile device

      • +

    • Communication for sending location information to other devices

      +
      • +
    +
     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF7959E7-15A4-5504-8D22-B8189DB2688E.dita --- a/Symbian3/SDK/Source/GUID-DF7959E7-15A4-5504-8D22-B8189DB2688E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-DF7959E7-15A4-5504-8D22-B8189DB2688E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Introduction to Swizzles and deferred loading

    In complex applications involving a large network of objects, it may be desirable, and even necessary, to defer the loading of objects into memory from the store.

    It should, therefore, be possible to represent such an object in one of two ways:

    • by the stream ID of the stream containing the external representation of that object, if it is not in memory.

    • by a pointer, if it is in memory (or has already been loaded into memory); the pointer points to the in-memory object.

    A Swizzle is a device for handling this dual representation.

    A typical container type object, therefore, does not have a pointer directly to a contained object, but has a Swizzle which can represent that contained object either as a pointer or as a stream ID, as illustrated in the following diagram.

    A Swizzle can be considered as a lean, but efficient, container in its own right.

    The concrete Swizzle classes are templated; the template parameter defines the type of object which the Swizzle represents.

    There are two general concrete Swizzle classes:

    • TSwizzle<class T>

    • TSwizzleC<class T>

    A TSwizzle<class T> represents a <class T> type object. Full access is available to the <class T> type object through the Swizzle.

    A TSwizzleC<class T> represents a <class T> type object. Access to the object is limited; in particular the object cannot be changed.

     \ No newline at end of file +Introduction to Swizzles and deferred loading

    In complex applications involving a large network of objects, it may be desirable, and even necessary, to defer the loading of objects into memory from the store.

    It should, therefore, be possible to represent such an object in one of two ways:

    • by the stream ID of the stream containing the external representation of that object, if it is not in memory.

    • by a pointer, if it is in memory (or has already been loaded into memory); the pointer points to the in-memory object.

    A Swizzle is a device for handling this dual representation.

    A typical container type object, therefore, does not have a pointer directly to a contained object, but has a Swizzle which can represent that contained object either as a pointer or as a stream ID, as illustrated in the following diagram.

    A Swizzle can be considered as a lean, but efficient, container in its own right.

    The concrete Swizzle classes are templated; the template parameter defines the type of object which the Swizzle represents.

    There are two general concrete Swizzle classes:

    • TSwizzle<class T>

    • TSwizzleC<class T>

    A TSwizzle<class T> represents a <class T> type object. Full access is available to the <class T> type object through the Swizzle.

    A TSwizzleC<class T> represents a <class T> type object. Access to the object is limited; in particular the object cannot be changed.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF83E798-408C-5E69-9520-A733DAEAB788_d0e79034_href.png Binary file Symbian3/SDK/Source/GUID-DF83E798-408C-5E69-9520-A733DAEAB788_d0e79034_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DF83E798-408C-5E69-9520-A733DAEAB788_d0e79092_href.png Binary file Symbian3/SDK/Source/GUID-DF83E798-408C-5E69-9520-A733DAEAB788_d0e79092_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e51793_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e51793_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e51936_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e51936_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e58465_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e58465_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e58608_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e58608_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e69038_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e69038_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e69062_href.png Binary file Symbian3/SDK/Source/GUID-DFBBA71F-0042-4303-B66F-0D291106B655_d0e69062_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E0284006-9173-5BC5-A899-E0873CA1AE1F.dita --- a/Symbian3/SDK/Source/GUID-E0284006-9173-5BC5-A899-E0873CA1AE1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Native EXEs and LIBs vs. OE EXEs and LIBs

    The conventional way of defining the entry point for a Symbian platform executable is by including "E32Main " in the application source. Since Symbian OS v9.3, you can define the entry point for an executable by including "main " instead of "E32Main ". With this approach, Symbian developers may easily port their C/C++ code to Symbian platform with less changes to the original source.

    Symbian OS v9.3 and later releases provide an Open Environment (OE) to develop EXEs with the "main " entry point. The OE executables and libraries are identified by their targettype, which can either be STDEXE, STDDLL or STDLIB. An OE EXE may choose to have a wide character entry point using the MMP keyword, wcharentrypoint.

    Here is a list of important differences between native Symbian platform executables and OE executables:

    • Native Symbian platform EXEs use "E32Main " entry point, whereas OE EXEs use "main " entry point.

    • The UIDs used to identify native Symbian platform EXEs and DLLs are different when compared to OE EXEs and DLLs.

    • In a native Symbian platform executable, the functions and data symbols with extern linkage are exported only if IMPORT_C /EXPORT_C declarations are found in the header or source files. In a OE executable, all functions and data symbols with extern linkage are exported by default without IMPORT_C /EXPORT_C declarations in the header or source files.

    • The libraries required by a native Symbian platform executable/library have to be listed explicitly in the MMP file, whereas for an OE executable/library they are included by default.

    • The native Symbian platform EXEs and DLLs does not have symbol lookup, whereas OE EXEs and DLLs support symbol lookup using dlsym.

    • A native Symbian platform EXE, DLL or LIB must include the path to standard APIs in the mmp file. For an OE EXE, DLL or LIB the build system includes ${EPOCROOT}epoc32/include/stdapis as the default path for header files.

    The build system has been modified to support compilation of C++ source files with extensions “.cc ”, “.cxx ” and “.c++ ”. This change is applicable to both OE and native Symbian platform executables and libraries. That is, from Symbian OS v9.3 onwards a native Symbian platform or an OE executable/library can be built using C++ source files with extensions “.cc ”, “.cxx ” and “.c++ ”.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-3-1-1-4-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-3-1-1-4-1-4-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,84 +0,0 @@ - - - - - -Using -the extended notifier framework -
    The framework

    Notifiers -allow components with no direct UI linkage to interact with the user via an -interface such as a dialog box. For example, a low level component might want -to warn the user about a low battery level. Typically, such a component would -not have direct access, or knowledge of, a UI. The solution to this problem -is provided by what are known as notifiers and the extended notifier framework. -The UI element (the dialog box) is provided by the device's UI -through what are known as notifier plug-ins.

    The extended notifier -framework is a system that loads these plug-in DLLs from Z\sys\bin\notifiers.

    These -DLLs are expected to export a single factory function at ordinal #1 that returns -an array of notifiers. A special notifier target type is supported by makmake. -The second Uid for notifiers should be 0x10005522.

    The behaviour of -notifiers is supplied by providing an implementation of the MEikSrvNotifierBase2 interface -. A notifier is associated with a channel and a priority. Priority is used -to determine the order of activation if more than one notifier is activated -at any time. Priority only affects notifiers on the same channel (for example, -a screen or LED). This means that two notifiers can be active at the same -time provided that they are on different channels.

    The channel and -priority used by all the notifiers in the system needs to be considered carefully -to avoid them interfering with each other in unexpected ways. The MEikSrvNotifierBase2 derived -class also needs to be implemented correctly. Notifiers run in the UIKON server -thread and are accessed on the client side via RNotifier. -Note that if a notifier panics it will lead to a device reset.

    -
    The factory -function

    The factory function at ordinal #1 is expected to return -an array of notifiers. The following is a typical implementation:

    EXPORT_C CArrayPtr<MEikSrvNotifierBase2>* NotifierArray() - { - CArrayPtrFlat<MEikSrvNotifierBase2>* notifiers=new CArrayPtrFlat<MEikSrvNotifierBase2>(5); - if (notifiers) - { - TRAPD(err, CreateNotifiersL(notifiers)); - if(err) - { - TInt count = notifiers->Count(); - while(count--) - { - (*notifiers)[count]->Release(); - } - delete notifiers; - notifiers = NULL; - } - } - return(notifiers); - } -

    Ownership of the notifier array or its contents is not -transferred to the framework until this function returns. To avoid memory -leaks, all acquired resources must be freed if anything goes wrong part of -the way through its processing.

    Calling Release() on -a notifier should cause that notifier to free all of its resources, and as -a minimum should call delete this;. See MEikSrvNotifierBase2::Release().

    Returning -a Null value from this function causes the framework to leave -with KErrNoMemory.

    The CreateNotifiersL() function -should be implemented as follows:

    LOCAL_C void CreateNotifiersL(CArrayPtrFlat<MEikSrvNotifierBase2>* aNotifiers) - { - MEikSrvNotifierBase2* notifier; - notifier = CMyNotifierA::NewL(); - CleanupStack::PushL(notifier); - aNotifiers->AppendL(notifier); - CleanupStack::Pop(notifier); - ... - ... - // typically, repeat this procedure for as - // many notifiers as are implemented - // in the plug-in DLL. - }

    Use of the standard Symbian platform technique -of using the cleanup stack to hold pointers to allocated objects for as long -as these objects have no owner; this prevents memory leaks. For this reason, -avoid using a technique such as aNotifiers->AppendL(CMyNotifierA::NewL());, -which, although shorter, will result in a memory leak if the AppendL() operation -fails.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-4-1-1-4-1-4-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-4-1-1-4-1-4-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,84 @@ + + + + + +Using +the extended notifier framework +
    The framework

    Notifiers +allow components with no direct UI linkage to interact with the user via an +interface such as a dialog box. For example, a low level component might want +to warn the user about a low battery level. Typically, such a component would +not have direct access, or knowledge of, a UI. The solution to this problem +is provided by what are known as notifiers and the extended notifier framework. +The UI element (the dialog box) is provided by the device's UI +through what are known as notifier plug-ins.

    The extended notifier +framework is a system that loads these plug-in DLLs from Z\sys\bin\notifiers.

    These +DLLs are expected to export a single factory function at ordinal #1 that returns +an array of notifiers. A special notifier target type is supported by makmake. +The second Uid for notifiers should be 0x10005522.

    The behaviour of +notifiers is supplied by providing an implementation of the MEikSrvNotifierBase2 interface +. A notifier is associated with a channel and a priority. Priority is used +to determine the order of activation if more than one notifier is activated +at any time. Priority only affects notifiers on the same channel (for example, +a screen or LED). This means that two notifiers can be active at the same +time provided that they are on different channels.

    The channel and +priority used by all the notifiers in the system needs to be considered carefully +to avoid them interfering with each other in unexpected ways. The MEikSrvNotifierBase2 derived +class also needs to be implemented correctly. Notifiers run in the UIKON server +thread and are accessed on the client side via RNotifier. +Note that if a notifier panics it will lead to a device reset.

    +
    The factory +function

    The factory function at ordinal #1 is expected to return +an array of notifiers. The following is a typical implementation:

    EXPORT_C CArrayPtr<MEikSrvNotifierBase2>* NotifierArray() + { + CArrayPtrFlat<MEikSrvNotifierBase2>* notifiers=new CArrayPtrFlat<MEikSrvNotifierBase2>(5); + if (notifiers) + { + TRAPD(err, CreateNotifiersL(notifiers)); + if(err) + { + TInt count = notifiers->Count(); + while(count--) + { + (*notifiers)[count]->Release(); + } + delete notifiers; + notifiers = NULL; + } + } + return(notifiers); + } +

    Ownership of the notifier array or its contents is not +transferred to the framework until this function returns. To avoid memory +leaks, all acquired resources must be freed if anything goes wrong part of +the way through its processing.

    Calling Release() on +a notifier should cause that notifier to free all of its resources, and as +a minimum should call delete this;. See MEikSrvNotifierBase2::Release().

    Returning +a Null value from this function causes the framework to leave +with KErrNoMemory.

    The CreateNotifiersL() function +should be implemented as follows:

    LOCAL_C void CreateNotifiersL(CArrayPtrFlat<MEikSrvNotifierBase2>* aNotifiers) + { + MEikSrvNotifierBase2* notifier; + notifier = CMyNotifierA::NewL(); + CleanupStack::PushL(notifier); + aNotifiers->AppendL(notifier); + CleanupStack::Pop(notifier); + ... + ... + // typically, repeat this procedure for as + // many notifiers as are implemented + // in the plug-in DLL. + }

    Use of the standard Symbian platform technique +of using the cleanup stack to hold pointers to allocated objects for as long +as these objects have no owner; this prevents memory leaks. For this reason, +avoid using a technique such as aNotifiers->AppendL(CMyNotifierA::NewL());, +which, although shorter, will result in a memory leak if the AppendL() operation +fails.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-6-1-1-3-1-10-1.dita --- a/Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-6-1-1-3-1-10-1.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,84 +0,0 @@ - - - - - -Using -the extended notifier framework -
    The framework

    Notifiers -allow components with no direct UI linkage to interact with the user via an -interface such as a dialog box. For example, a low level component might want -to warn the user about a low battery level. Typically, such a component would -not have direct access, or knowledge of, a UI. The solution to this problem -is provided by what are known as notifiers and the extended notifier framework. -The UI element (the dialog box) is provided by the device's UI -through what are known as notifier plug-ins.

    The extended notifier -framework is a system that loads these plug-in DLLs from Z\sys\bin\notifiers.

    These -DLLs are expected to export a single factory function at ordinal #1 that returns -an array of notifiers. A special notifier target type is supported by makmake. -The second Uid for notifiers should be 0x10005522.

    The behaviour of -notifiers is supplied by providing an implementation of the MEikSrvNotifierBase2 interface -. A notifier is associated with a channel and a priority. Priority is used -to determine the order of activation if more than one notifier is activated -at any time. Priority only affects notifiers on the same channel (for example, -a screen or LED). This means that two notifiers can be active at the same -time provided that they are on different channels.

    The channel and -priority used by all the notifiers in the system needs to be considered carefully -to avoid them interfering with each other in unexpected ways. The MEikSrvNotifierBase2 derived -class also needs to be implemented correctly. Notifiers run in the UIKON server -thread and are accessed on the client side via RNotifier. -Note that if a notifier panics it will lead to a device reset.

    -
    The factory -function

    The factory function at ordinal #1 is expected to return -an array of notifiers. The following is a typical implementation:

    EXPORT_C CArrayPtr<MEikSrvNotifierBase2>* NotifierArray() - { - CArrayPtrFlat<MEikSrvNotifierBase2>* notifiers=new CArrayPtrFlat<MEikSrvNotifierBase2>(5); - if (notifiers) - { - TRAPD(err, CreateNotifiersL(notifiers)); - if(err) - { - TInt count = notifiers->Count(); - while(count--) - { - (*notifiers)[count]->Release(); - } - delete notifiers; - notifiers = NULL; - } - } - return(notifiers); - } -

    Ownership of the notifier array or its contents is not -transferred to the framework until this function returns. To avoid memory -leaks, all acquired resources must be freed if anything goes wrong part of -the way through its processing.

    Calling Release() on -a notifier should cause that notifier to free all of its resources, and as -a minimum should call delete this;. See MEikSrvNotifierBase2::Release().

    Returning -a Null value from this function causes the framework to leave -with KErrNoMemory.

    The CreateNotifiersL() function -should be implemented as follows:

    LOCAL_C void CreateNotifiersL(CArrayPtrFlat<MEikSrvNotifierBase2>* aNotifiers) - { - MEikSrvNotifierBase2* notifier; - notifier = CMyNotifierA::NewL(); - CleanupStack::PushL(notifier); - aNotifiers->AppendL(notifier); - CleanupStack::Pop(notifier); - ... - ... - // typically, repeat this procedure for as - // many notifiers as are implemented - // in the plug-in DLL. - }

    Use of the standard Symbian platform technique -of using the cleanup stack to hold pointers to allocated objects for as long -as these objects have no owner; this prevents memory leaks. For this reason, -avoid using a technique such as aNotifiers->AppendL(CMyNotifierA::NewL());, -which, although shorter, will result in a memory leak if the AppendL() operation -fails.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-7-1-1-3-1-10-1.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-E049772D-A96F-592F-AF59-C9B69E8D24C1-GENID-1-10-1-7-1-1-3-1-10-1.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,84 @@ + + + + + +Using +the extended notifier framework +
    The framework

    Notifiers +allow components with no direct UI linkage to interact with the user via an +interface such as a dialog box. For example, a low level component might want +to warn the user about a low battery level. Typically, such a component would +not have direct access, or knowledge of, a UI. The solution to this problem +is provided by what are known as notifiers and the extended notifier framework. +The UI element (the dialog box) is provided by the device's UI +through what are known as notifier plug-ins.

    The extended notifier +framework is a system that loads these plug-in DLLs from Z\sys\bin\notifiers.

    These +DLLs are expected to export a single factory function at ordinal #1 that returns +an array of notifiers. A special notifier target type is supported by makmake. +The second Uid for notifiers should be 0x10005522.

    The behaviour of +notifiers is supplied by providing an implementation of the MEikSrvNotifierBase2 interface +. A notifier is associated with a channel and a priority. Priority is used +to determine the order of activation if more than one notifier is activated +at any time. Priority only affects notifiers on the same channel (for example, +a screen or LED). This means that two notifiers can be active at the same +time provided that they are on different channels.

    The channel and +priority used by all the notifiers in the system needs to be considered carefully +to avoid them interfering with each other in unexpected ways. The MEikSrvNotifierBase2 derived +class also needs to be implemented correctly. Notifiers run in the UIKON server +thread and are accessed on the client side via RNotifier. +Note that if a notifier panics it will lead to a device reset.

    +
    The factory +function

    The factory function at ordinal #1 is expected to return +an array of notifiers. The following is a typical implementation:

    EXPORT_C CArrayPtr<MEikSrvNotifierBase2>* NotifierArray() + { + CArrayPtrFlat<MEikSrvNotifierBase2>* notifiers=new CArrayPtrFlat<MEikSrvNotifierBase2>(5); + if (notifiers) + { + TRAPD(err, CreateNotifiersL(notifiers)); + if(err) + { + TInt count = notifiers->Count(); + while(count--) + { + (*notifiers)[count]->Release(); + } + delete notifiers; + notifiers = NULL; + } + } + return(notifiers); + } +

    Ownership of the notifier array or its contents is not +transferred to the framework until this function returns. To avoid memory +leaks, all acquired resources must be freed if anything goes wrong part of +the way through its processing.

    Calling Release() on +a notifier should cause that notifier to free all of its resources, and as +a minimum should call delete this;. See MEikSrvNotifierBase2::Release().

    Returning +a Null value from this function causes the framework to leave +with KErrNoMemory.

    The CreateNotifiersL() function +should be implemented as follows:

    LOCAL_C void CreateNotifiersL(CArrayPtrFlat<MEikSrvNotifierBase2>* aNotifiers) + { + MEikSrvNotifierBase2* notifier; + notifier = CMyNotifierA::NewL(); + CleanupStack::PushL(notifier); + aNotifiers->AppendL(notifier); + CleanupStack::Pop(notifier); + ... + ... + // typically, repeat this procedure for as + // many notifiers as are implemented + // in the plug-in DLL. + }

    Use of the standard Symbian platform technique +of using the cleanup stack to hold pointers to allocated objects for as long +as these objects have no owner; this prevents memory leaks. For this reason, +avoid using a technique such as aNotifiers->AppendL(CMyNotifierA::NewL());, +which, although shorter, will result in a memory leak if the AppendL() operation +fails.

    +     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E04B4397-2926-4F4D-A7FE-F79F3BF37BF8-master.png Binary file Symbian3/SDK/Source/GUID-E04B4397-2926-4F4D-A7FE-F79F3BF37BF8-master.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E04B4397-2926-4F4D-A7FE-F79F3BF37BF8_d0e67575_href.png Binary file Symbian3/SDK/Source/GUID-E04B4397-2926-4F4D-A7FE-F79F3BF37BF8_d0e67575_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E08F6BA9-F1A9-50D5-8CBE-8304BBA24D1F.dita --- a/Symbian3/SDK/Source/GUID-E08F6BA9-F1A9-50D5-8CBE-8304BBA24D1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -The Symbian emulator build targets

    This section describes distinctive aspects of building for the emulator targets.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E09CA978-2599-50F9-AF6D-077AD7D5CA6F_d0e303526_href.jpg Binary file Symbian3/SDK/Source/GUID-E09CA978-2599-50F9-AF6D-077AD7D5CA6F_d0e303526_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E09CA978-2599-50F9-AF6D-077AD7D5CA6F_d0e309998_href.jpg Binary file Symbian3/SDK/Source/GUID-E09CA978-2599-50F9-AF6D-077AD7D5CA6F_d0e309998_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E0A02CCA-486B-592E-9B3B-BA4A378EC5AD.dita --- a/Symbian3/SDK/Source/GUID-E0A02CCA-486B-592E-9B3B-BA4A378EC5AD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E0A02CCA-486B-592E-9B3B-BA4A378EC5AD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Socket connection example

    This example shows the relationship that sockets, connections and subconnections have to each other.

    \ No newline at end of file +Socket connection example

    This example shows the relationship that sockets, connections and subconnections have to each other.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E0C21636-657A-413F-A905-A08608B60768.dita --- a/Symbian3/SDK/Source/GUID-E0C21636-657A-413F-A905-A08608B60768.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E0C21636-657A-413F-A905-A08608B60768.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ clients about long tap events.

    Touch UI utilities API class structure - +

    To receive long tap events in your application, implement the MaknLongTapDetectorCallBack interface. When the user makes long tap on the device screen, the framework sends events diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E0D4EFAC-85E6-4EF6-B65C-1D1602E3A8FD.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-E0D4EFAC-85E6-4EF6-B65C-1D1602E3A8FD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,81 @@ + + + + + +Creating +a User-Defined Time Zone from an Existing Time Zone +

    This tutorial +describes how a client uses CTzUserData to manage user data. CTzLocalizer enables +a client to get existing localized time zone names.

    The steps for +a client to create a user-defined TZ from an existing TZ are described in +the Procedure section.

    + +Include the header +files that contain the CTzLocalizer and CTzUserData classes. + +Include a numeric time zone ID. This is supplied by the UI layer. + +Get the localized TZ names for the existing time zone (specified +by the TZID) using CTzLocalizer::GetLocalizedTimeZoneL(TInt). + +Create a user-defined TZ names object using CTzUserNames::NewL(). + +Connect to the TZ Server using RTz::Connect(). + +Get all the TZ rules for the existing time zone using RTz::GetTimeZoneRulesL(). + +Create the user-defined TZ using CTzUserData::CreateL(). + + +

    This is illustrated in the code example that follows.

    #include <tzlocalizer.h> // For CTzLocalizer etc. +#include <tz.h> // For CTzUserData etc. +#include <…> + +… + +// This numeric TZID would typically be supplied by the UI layer. +TInt existingTzId = 1234; + +// Get localized TZ names for existing TZ. +CTzLocalizer* tzLocalizer = CTzLocalizer::NewL(); +CTzLocalizedTimeZone* localizedTz = tzLocalizer-> GetLocalizedTimeZoneL( existingTzId ); +CTzLocalizedCity* localizedCity = tzLocalizer-> GetDefaultCityL( localizedTz ); +CTzLocalizedCityGroup* localizedGroup = tzLocalizer-> GetCityGroupL( localizedCity->GroupId() ); + +// Create user-defined TZ names object. +CTzUserNames* tzNames = CTzUserNames::NewL( localizedTz->StandardName(), + localizedTz->ShortStandardName(), + localizedTz->DaylightName(), + localizedTz->ShortDaylightName(), + localizedCity->Name(), + localizedGroup ->Name() ); + +// Connect to TZ Server. +RTz tzServer; +User::LeaveIfError( tzServer.Connect() ); + +// Get the TZ rules for the existing TZ. +CTzId* tzId = CTzId::NewL( existingTzId ); +TTime startTime( TDateTime( 0,EJanuary,0,0,0,0,0 ) ); // Get all the +TTime endTime( TDateTime( 9999,EDecember,30,23,59,59,0 ) ); // TZ rules. +CTzRules* tzRules = tzServer.GetTimeZoneRulesL( *tzId, + startTime, + endTime, + ETzUtcTimeReference ); + +// Create user-defined TZ. +CTzUserData* tzUserData = CTzUserData::NewL( tzServer ); +CTzId* userTzId = tzUserData->CreateL( *tzRules, *tzNames ); + +…     + +Subscribe +and Respond to TZ Data Changes + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E1410365-7254-5326-B3F7-D7100D31E59F.dita --- a/Symbian3/SDK/Source/GUID-E1410365-7254-5326-B3F7-D7100D31E59F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E1410365-7254-5326-B3F7-D7100D31E59F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Array of variable length elements, segmented buffer

    This is a CArrayVarSeg<class T> object whose elements can have different lengths. Although each element is a class T object, the length of that object can vary.

    In this type of array, each element occupies its own individual cell allocated from the heap. The array buffer contains fixed length data structures, one for each element, which are logically contiguous within the buffer but are physically contiguous only within a segment. Each fixed length data structure contains the length of an element (a TInt value) and a pointer to it. The structure itself is part of the implementation but occupies no more than eight bytes on 32-bit machines.

    A segmented buffer is implemented as a doubly linked list of equally sized cells allocated from the heap and is always extended by allocating a new segment and inserting it into the appropriate place in the list. A segmented array buffer is implemented using a CBufSeg object.

    The following diagram illustrates how elements are organised within the array buffer:

    This kind of array is suitable for large arrays with a high turnover of elements.

    This class is immediately derived from the abstract templated base class CArrayVar<class T> which is itself derived from the abstract non-templated base class CArrayVarBase.

    See also

    Dynamic Buffers Guide.

     \ No newline at end of file +Array of variable length elements, segmented buffer

    This is a CArrayVarSeg<class T> object whose elements can have different lengths. Although each element is a class T object, the length of that object can vary.

    In this type of array, each element occupies its own individual cell allocated from the heap. The array buffer contains fixed length data structures, one for each element, which are logically contiguous within the buffer but are physically contiguous only within a segment. Each fixed length data structure contains the length of an element (a TInt value) and a pointer to it. The structure itself is part of the implementation but occupies no more than eight bytes on 32-bit machines.

    A segmented buffer is implemented as a doubly linked list of equally sized cells allocated from the heap and is always extended by allocating a new segment and inserting it into the appropriate place in the list. A segmented array buffer is implemented using a CBufSeg object.

    The following diagram illustrates how elements are organised within the array buffer:

    This kind of array is suitable for large arrays with a high turnover of elements.

    This class is immediately derived from the abstract templated base class CArrayVar<class T> which is itself derived from the abstract non-templated base class CArrayVarBase.

    See also

    Dynamic Buffers Guide.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E161AB84-1B24-53AF-B313-D68CF9F8EE60.dita --- a/Symbian3/SDK/Source/GUID-E161AB84-1B24-53AF-B313-D68CF9F8EE60.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E161AB84-1B24-53AF-B313-D68CF9F8EE60.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ pointer to the first byte following the end of the buffer, while Back() always returns a pointer to the beginning of the buffer.

    End() and Back() in fixed flat arrays - +
    Segmented array

    For a segmented array, the situation is different (as illustrated below). Looking at the segment containing elements n and n+1, End() returns a pointer to the first byte following the end of that segment. In @@ -47,7 +47,7 @@ element in the array, Back() returns a pointer with a NULL value.

    End() and Back() in fixed segmented arrays - +
    See also

    Dynamic Buffers Guide.

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E16E286C-FB6A-5D3E-95D6-044C39DBA2B4.dita --- a/Symbian3/SDK/Source/GUID-E16E286C-FB6A-5D3E-95D6-044C39DBA2B4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E16E286C-FB6A-5D3E-95D6-044C39DBA2B4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -The object container

    All reference counting objects must be held in an object container. An object container acts as a home for a set of related reference counting objects.

    An object container is an instance of a CObjectCon class.

    After construction, a reference counting object must be added to an object container. Only one instance of a reference counting object can be held by an object container, i.e. each object within an object container must be distinct.

    The main characteristics of an object container can be summarised as follows:

    • they allow a logical collections of reference counting objects to be gathered together.

    • explicitly destroying a reference counting object causes that object to be removed from its object container.

    • removing a reference counting object from its object container causes that object to be destroyed.

    • each object container is assigned a unique ID on construction. This is an integer that forms part of the identity of all of its contained reference counting objects. All reference counting objects within an object container are associated with the same unique ID. The value of the unique ID can range from 1 to 16,383 (0x3fff).

    Object containers are constructed by an object container index, a CObjectConIx type. The maximum number of object containers which may be constructed and held in an object container index is 6,383 (0x3fff).

    An object container is implemented as a simple array, where each element of the array is a pointer to a contained reference counting object. Adding a reference counting object to the object container is simply a matter of adding the reference counting object's pointer into the array. The following diagram shows a simple situation where two object containers hold a number of reference counting objects.

    The CObjectCon::AddL() function adds a reference counting object to the object container.

    The CObjectCon::Remove() function removes a reference counting object from its object container and also destroys that reference counting object. Conversely, if the reference counting object is destroyed (typically, as a result of successive calls to CObject::Close()), it is removed from its object container.

    See also:

    • CObjectCon

    • CObject

    \ No newline at end of file +The object container

    All reference counting objects must be held in an object container. An object container acts as a home for a set of related reference counting objects.

    An object container is an instance of a CObjectCon class.

    After construction, a reference counting object must be added to an object container. Only one instance of a reference counting object can be held by an object container, i.e. each object within an object container must be distinct.

    The main characteristics of an object container can be summarised as follows:

    • they allow a logical collections of reference counting objects to be gathered together.

    • explicitly destroying a reference counting object causes that object to be removed from its object container.

    • removing a reference counting object from its object container causes that object to be destroyed.

    • each object container is assigned a unique ID on construction. This is an integer that forms part of the identity of all of its contained reference counting objects. All reference counting objects within an object container are associated with the same unique ID. The value of the unique ID can range from 1 to 16,383 (0x3fff).

    Object containers are constructed by an object container index, a CObjectConIx type. The maximum number of object containers which may be constructed and held in an object container index is 6,383 (0x3fff).

    An object container is implemented as a simple array, where each element of the array is a pointer to a contained reference counting object. Adding a reference counting object to the object container is simply a matter of adding the reference counting object's pointer into the array. The following diagram shows a simple situation where two object containers hold a number of reference counting objects.

    The CObjectCon::AddL() function adds a reference counting object to the object container.

    The CObjectCon::Remove() function removes a reference counting object from its object container and also destroys that reference counting object. Conversely, if the reference counting object is destroyed (typically, as a result of successive calls to CObject::Close()), it is removed from its object container.

    See also:

    • CObjectCon

    • CObject

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E189B0C0-AAB5-5472-996B-91043DE0B6D4.dita --- a/Symbian3/SDK/Source/GUID-E189B0C0-AAB5-5472-996B-91043DE0B6D4.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E189B0C0-AAB5-5472-996B-91043DE0B6D4.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,41 +1,42 @@ - - - - - -Package -Buffers OverviewAllows any value type (a T class) to be encapsulated as a descriptor, -for the purpose of inter-thread data transfer. -
    Architectural relationships

    The Client/Server API -expects data that is to be passed between threads to be encapsulated in a -descriptor. Package buffers provide a generic way for the thread providing -the data to do this. The thread receiving the data extracts the original data -from the package.

    APIs with client/server architectures, such as telephony -and Messaging, define specialised package buffer types that encapsulate the -particular data types that they require to pass between threads.

    -
    Description

    The API has two key concepts: package -buffer descriptor, and package pointer descriptor.

    -
    Package buffer descriptor

    The package buffer descriptor -creates a new instance of the type to encapsulate and stores it within the -descriptor. The interface allows a reference to the encapsulated object to -be obtained, so that it can be accessed and modified.

    The package buffer -descriptor interface is provided by TPckgBuf.

    -
    Package pointer descriptor

    The package pointer -descriptor refers to an already existing object. It is otherwise used in a -similar way to the package buffer descriptor.

    The package pointer descriptor -interface is provided by TPckgC for const objects, and TPckg for -non-const objects.

    -     - -Client/Server -Overview - -Using Descriptors - + + + + + +Package Buffers OverviewAllows any value type (a T class) to be encapsulated as +a descriptor, for the purpose of inter-thread data transfer. +
    Architectural +relationships

    The Client/Server API expects data that is +to be passed between threads to be encapsulated in a descriptor. Package +buffers provide a generic way for the thread providing the data to +do this. The thread receiving the data extracts the original data +from the package.

    APIs with client/server architectures, such +as telephony and Messaging, define specialised package buffer types +that encapsulate the particular data types that they require to pass +between threads.

    +
    Description

    The API has two key concepts: package buffer descriptor, and +package pointer descriptor.

    +
    Package +buffer descriptor

    The package buffer descriptor creates +a new instance of the type to encapsulate and stores it within the +descriptor. The interface allows a reference to the encapsulated object +to be obtained, so that it can be accessed and modified.

    The +package buffer descriptor interface is provided by TPckgBuf.

    +
    Package +pointer descriptor

    The package pointer descriptor refers +to an already existing object. It is otherwise used in a similar way +to the package buffer descriptor.

    The package pointer descriptor +interface is provided by TPckgC for const objects, +and TPckg for non-const objects.

    +     +Using +Descriptors +Client/Server +Overview     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E244744F-4837-5B46-8E37-4666A28BF0B7.dita --- a/Symbian3/SDK/Source/GUID-E244744F-4837-5B46-8E37-4666A28BF0B7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E244744F-4837-5B46-8E37-4666A28BF0B7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> The run-time control hierarchy

    At run-time all controls in an application are related to each other in a tree hierarchy. The top-level window-owning controls are owned by the AppUi. This is similar to the hierarchy of windows that exists in the Window Server which has a group window for each application at the root. It is important to understand the relationships between window-owning and non-window owning controls. The diagram below attempts to illustrate these.

    The run-time control hierarchy -

    A non-window-owning control is confined to the extent of its parent if the parent is window-owning, and must be confined to the extent of its parent if the parent is non-window-owning.

    A window-owning component is confined to the nearest window-owning control above it in the hierarchy.

    Screen drawing may be initiated by either the application (because it's running and it has changed its display) or by the Window Server (because something else has updated the screen and the application is visible).

    • Application-initiated redrawing follows the control framework run-time hierarchy: controls are drawn by their parents regardless of whether they are window-owning or not.

    • Window-Server-initiated redrawing, on the other hand, follows the Window Server hierarchy: parents do not draw their window-owning children.

    A control's container or parent control may not be changed after it has been set.

    The run time hierarchy of controls has been enhanced for version 9.1 of the Symbian OS. The distinction between the 'parent-child' relationship from the Window Server and the 'container-component' relationship from the control framework may be simplified with the addition of a parent pointer to CCoeControl.

    In UIQ v3 the parent pointer is enabled. In S60 and MOAP the parent pointer currently is not enabled.

    The addition of the parent pointer allows the framework to navigate the control hierarchy upwards as well as downwards. When enabled, the parent pointer is set automatically (see how to write a control).

    The run-time hierarchy is particularly significant when laying out and when refreshing the screen. Here are a few examples of how the framework uses the run-time hierarchy.

    • When a control is drawn it must have the correct Look and Feel: its colours, fonts, font style, size and shape must be correct. Controls use their parent's graphics contexts and text drawers.

    • If a control (lodger or a parent) changes size, the controls around or within it might have to move or resize. From 9.1 the framework provides a layout manager interface (MCoeLayoutManager). Controls use the run-time hierarchy to find the appropriate layout manager.

    • From 9.1 parent controls take responsibility for drawing behind their children. This allows flexibility with backgrounds, transparent controls and controls which appear non-rectangular. To enable this process to work with window-owning controls (necessary because the Window Server will not allow parent windows to draw behind child windows) a new interface, MCoeControlBackground, has been introduced. When a window owning control draws itself it first looks for an MCoeControlBackground in its chain of parents and calls MCoeControlBackground::Draw() before drawing itself.

    \ No newline at end of file +

    A non-window-owning control is confined to the extent of its parent if the parent is window-owning, and must be confined to the extent of its parent if the parent is non-window-owning.

    A window-owning component is confined to the nearest window-owning control above it in the hierarchy.

    Screen drawing may be initiated by either the application (because it's running and it has changed its display) or by the Window Server (because something else has updated the screen and the application is visible).

    • Application-initiated redrawing follows the control framework run-time hierarchy: controls are drawn by their parents regardless of whether they are window-owning or not.

    • Window-Server-initiated redrawing, on the other hand, follows the Window Server hierarchy: parents do not draw their window-owning children.

    A control's container or parent control may not be changed after it has been set.

    The run time hierarchy of controls has been enhanced for version 9.1 of the Symbian OS. The distinction between the 'parent-child' relationship from the Window Server and the 'container-component' relationship from the control framework may be simplified with the addition of a parent pointer to CCoeControl.

    In UIQ v3 the parent pointer is enabled. In S60 and MOAP the parent pointer currently is not enabled.

    The addition of the parent pointer allows the framework to navigate the control hierarchy upwards as well as downwards. When enabled, the parent pointer is set automatically (see how to write a control).

    The run-time hierarchy is particularly significant when laying out and when refreshing the screen. Here are a few examples of how the framework uses the run-time hierarchy.

    • When a control is drawn it must have the correct Look and Feel: its colours, fonts, font style, size and shape must be correct. Controls use their parent's graphics contexts and text drawers.

    • If a control (lodger or a parent) changes size, the controls around or within it might have to move or resize. From 9.1 the framework provides a layout manager interface (MCoeLayoutManager). Controls use the run-time hierarchy to find the appropriate layout manager.

    • From 9.1 parent controls take responsibility for drawing behind their children. This allows flexibility with backgrounds, transparent controls and controls which appear non-rectangular. To enable this process to work with window-owning controls (necessary because the Window Server will not allow parent windows to draw behind child windows) a new interface, MCoeControlBackground, has been introduced. When a window owning control draws itself it first looks for an MCoeControlBackground in its chain of parents and calls MCoeControlBackground::Draw() before drawing itself.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2455472-49FA-5492-B7CB-2C33BD830591_d0e169127_href.jpg Binary file Symbian3/SDK/Source/GUID-E2455472-49FA-5492-B7CB-2C33BD830591_d0e169127_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2455472-49FA-5492-B7CB-2C33BD830591_d0e174141_href.jpg Binary file Symbian3/SDK/Source/GUID-E2455472-49FA-5492-B7CB-2C33BD830591_d0e174141_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E24F15B4-D767-5B79-B0EB-88294B9BC16A_d0e202076_href.png Binary file Symbian3/SDK/Source/GUID-E24F15B4-D767-5B79-B0EB-88294B9BC16A_d0e202076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E24F15B4-D767-5B79-B0EB-88294B9BC16A_d0e207083_href.png Binary file Symbian3/SDK/Source/GUID-E24F15B4-D767-5B79-B0EB-88294B9BC16A_d0e207083_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E26E46AE-914E-5F21-AB44-10F926BAA8AC.dita --- a/Symbian3/SDK/Source/GUID-E26E46AE-914E-5F21-AB44-10F926BAA8AC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E26E46AE-914E-5F21-AB44-10F926BAA8AC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,81 +1,68 @@ - - - - - -EUserHlExample: -EUser High Level exampleThis example demonstrates how to use the EUser High Level library -and includes the ceratian features supported by the library. It also demonstrates -the usage of specific APIs associated with the EUser High Level Library. -
    Purpose

    This -example demonstrates the following features of EUserHL:

      -

    • String handling

      • -

    • Object creation and -automatic resource management

      • -

    • Memory usage by EUserHL -classes

      • -
    -
    Download

    Click -on the following link to download the example: EUserHlExample.zip

    Click: browse to view the example code.

    -
    Design and -implementation

    The example implements three main functions:

      -

    • WalkthroughStringsL() demonstrates -string handling.

      • -

    • WalkthroughManagedL() demonstrates -object creation and resource management.

      • -

    • WalkthroughUsageL() demonstrates -memory usage by EUserHL library classes.

      • -

    String handling

    LString is designed -to be a self-managing, resizable alternative to some of the existing descriptor -types.

    WalkthroughStringsL() demonstrates how LString can -be used in similar ways to the existing TDesC and TDes descriptor -classes, as well as showing some additional functions, including:

      -

    • LString::SetMaxlengthL()

      • -

    • LString::ReserveFreeCapacityL()

      • -

    • LString::Compress()

      • -

    • LString::Reset()

      • -

    CStringUserTwoPhase is used to demonstrate the -use of LString s in the two-phase construction pattern. LCleanedupPtr is -used in place of the CleanupStack in the NewL() function.

    CStringUserSinglePhase is -used to demonstrate the use of LString s in the single -phase construction pattern. A macro CONSTRUCTORS_MAY_LEAVE is -declared to ensure cleanup is correctly handled if the constructor leaves.

    Object -creation and automatic resource management

    The LCleanedUpXxx classes LCleanedupPtr, LCleanedupHandle, LCleanedupArray, LCleanedupGuard and LCleanedupRef classes -provide automatic resource management that avoids the need for the programmer -to use the cleanup stack.

    WalkthroughManagedL() shows -how the various LCleanedUpXxx classes are used. It shows -how objects declared locally to a function (a pointer, a resource handle, -an array, and an object cleaned up using a TCleanupItem) -are deleted automatically when they go out of scope.

    CManagedUserTwoPhase demonstrates -the use of the management classes in the two-phase construction pattern. LCleanedupPtr is -used in the NewL() function in place of the CleanupStack. LManagedXxx classes -(for example LManagedPtr and LManagedHandle) -are used to handle cleanup of member data.

    Related APIs

    CleanupStack

    LCleanedupArray

    LCleanedupGuard

    LCleanedupHandle

    LCleanedupPtr

    LCleanedupRef

    LManagedHandle

    LManagedPtr

    TCleanupItem

    Memory -usage

    WalkthroughUsageL() API demonstrates the -memory overhead of using EUserHL.

    -
    Building and -configuring

    To build the example:

      -

    • You can build the example -from your IDE or the command line.

      If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

      If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

      bldmake -bldfiles

      abld build

      How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

      • -

    • For the emulator, the -example builds an executable called euserhlexample.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

      • -
    -
    Running the -example

    This is a console application. The user presses any key -to step through it and the emulator closes down on exit.

    -
    See also:

    EUser -High Level Library

    + + + + + +EUserHlExample: EUser High Level exampleThis example demonstrates how to use the EUser High Level +library and includes the ceratian features supported by the library. +It also demonstrates the usage of specific APIs associated with the +EUser High Level Library. +
    Purpose

    This example demonstrates the following features of EUserHL:

      +

    • String handling

      • +

    • Object creation +and automatic resource management

      • +

    • Memory usage +by EUserHL classes

      • +
    +
    Download

    Click on the following link to download the example: EUserHlExample.zip

    Click: browse to view the example code.

    +
    Design +and implementation

    The example implements three main functions:

      +

    • WalkthroughStringsL() demonstrates string handling.

      • +

    • WalkthroughManagedL() demonstrates object creation and resource management.

      • +

    • WalkthroughUsageL() demonstrates memory usage by EUserHL library classes.

      • +

    String handling

    LString is designed to be a self-managing, resizable alternative to some +of the existing descriptor types.

    WalkthroughStringsL() demonstrates how LString can be used in similar +ways to the existing TDesC and TDes descriptor classes, as well as showing some additional functions, +including:

      +

    • LString::SetMaxlengthL()

      • +

    • LString::ReserveFreeCapacityL()

      • +

    • LString::Compress()

      • +

    • LString::Reset()

      • +

    CStringUserTwoPhase is used to demonstrate +the use of LString s in the two-phase construction +pattern. LCleanedupPtr is used in place of the CleanupStack in the NewL() function.

    CStringUserSinglePhase is used to demonstrate +the use of LString s in the single phase construction +pattern. A macro CONSTRUCTORS_MAY_LEAVE is declared +to ensure cleanup is correctly handled if the constructor leaves.

    Object creation and automatic resource management

    The LCleanedUpXxx classes LCleanedupPtr, LCleanedupHandle, LCleanedupArray, LCleanedupGuard and LCleanedupRef classes provide automatic resource management that avoids the need +for the programmer to use the cleanup stack.

    WalkthroughManagedL() shows how the various LCleanedUpXxx classes are +used. It shows how objects declared locally to a function (a pointer, +a resource handle, an array, and an object cleaned up using a TCleanupItem) are deleted automatically when they go out +of scope.

    CManagedUserTwoPhase demonstrates +the use of the management classes in the two-phase construction pattern. LCleanedupPtr is used in the NewL() function +in place of the CleanupStack. LManagedXxx classes (for example LManagedPtr and LManagedHandle) are used to handle cleanup of member data.

    Related APIs

    CleanupStack

    LCleanedupArray

    LCleanedupGuard

    LCleanedupHandle

    LCleanedupPtr

    LCleanedupRef

    LManagedHandle

    LManagedPtr

    TCleanupItem

    Memory usage

    WalkthroughUsageL() API demonstrates the memory overhead of using EUserHL.

    +
    Building +and configuring

    To build the example:

      +

    • You can build +the example from your IDE or the command line.

      If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

      If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

      bldmake bldfiles

      abld +build

      • +

    • For the emulator, +the example builds an executable called euserhlexample.exe in the epoc32\release\winscw\<udeb or + urel>\ folder.

      • +
    +
    Running +the example

    This is a console application. The user presses +any key to step through it and the emulator closes down on exit.

    +
    See also:

    EUser High Level +Library

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2AB4BDF-8AFD-5776-A614-50DC3ACF3AD4_d0e135205_href.png Binary file Symbian3/SDK/Source/GUID-E2AB4BDF-8AFD-5776-A614-50DC3ACF3AD4_d0e135205_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2AB4BDF-8AFD-5776-A614-50DC3ACF3AD4_d0e138810_href.png Binary file Symbian3/SDK/Source/GUID-E2AB4BDF-8AFD-5776-A614-50DC3ACF3AD4_d0e138810_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2CB0826-FC44-5AC9-BBB1-B449073484F3.dita --- a/Symbian3/SDK/Source/GUID-E2CB0826-FC44-5AC9-BBB1-B449073484F3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E2CB0826-FC44-5AC9-BBB1-B449073484F3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ buffer to be re-allocated so that its capacity increases from four to eight elements.

    - +

    For a segmented array buffer, the granularity defines the capacity of a single segment. A segmented array buffer is always expanded by allocating diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2E2FACF-5D4F-43E8-8B53-B268252CF572.dita --- a/Symbian3/SDK/Source/GUID-E2E2FACF-5D4F-43E8-8B53-B268252CF572.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E2E2FACF-5D4F-43E8-8B53-B268252CF572.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,8 +18,8 @@ under the Options menu when the destination network is highlighted.

    To define the connection management items:

    - -Request the connection + +Request the connection settings dialog for supported items using the Connection Settings UI API. Show the items that your application supports in the UI using the diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2F6A71A-4A18-5E0B-AE77-C059C59448E4_d0e352645_href.png Binary file Symbian3/SDK/Source/GUID-E2F6A71A-4A18-5E0B-AE77-C059C59448E4_d0e352645_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E2F6A71A-4A18-5E0B-AE77-C059C59448E4_d0e368521_href.png Binary file Symbian3/SDK/Source/GUID-E2F6A71A-4A18-5E0B-AE77-C059C59448E4_d0e368521_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E331B72B-84AF-558A-9B8F-73E5E50B58C7.dita --- a/Symbian3/SDK/Source/GUID-E331B72B-84AF-558A-9B8F-73E5E50B58C7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E331B72B-84AF-558A-9B8F-73E5E50B58C7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,90 +1,87 @@ - - - - - -Building -a Standard C++ Application or Library -

    This topic describes the required header files and libraries to compile -and link against to build a Standard C++ application or library on a Symbian -platform build environment.

    -

    You can build a C++ application or library using one of the following target -types:

    -
      -

    • STD target types

      • -

    • Other Symbian target types

      • -
    -

    Notes:

    -
      -

    • The required standard -C++ header files are available in the ${EPOCROOT}/epoc32/include/stdapis/stlportv5 directory.

      • -

    • The standard C++ library -name is libstdcppv5.lib.

      • -

    • You must specify the -system-include path and library name in the .mmp file -associated with the C++ application or library.

      • -
    -
    STD target -types

    You can develop a C++ application or library using the following -STD target types:

      -

    • STDEXE

      • -

    • STDDLL

      • -

    • STDLIB

      • -

    These target types enable symbol lookup by name thereby adding the -symbol information into the executable.

    Note: For more information -about STD target types (STDEXE /STDDLL /STDLIB), -see the Target Types section.

    Example

    The -following code snippet illustrates the use of the STD target type stdexe:

    //writing an stdexe, the mmp file may look like follows -//Start of test_stdexe.mmp -Target test_stdexe.exe -Targettype stdexe -Source test1.cpp -Systeminclude /epoc32/include/stdapis/stlportv5 -Library libstdcppv5.lib -Capability all -tcb -//End of test_stdexe.mmp
    -
    Other Symbian -target types

    You can avoid symbol information overhead while developing -C++ applications or libraries, by performing the following configurations:

      -

    1. Use the other Symbian -target types such as, dll, lib, exe and -so on. For more information about other Symbian target types, see the targettype section.

      2. -

    2. In addition, use the -MMP keyword STDCPP.

      3. -

    You may also have to include ${EPOCROOT}/epoc32/include/stdapis explicitly -as the standard C headers are required by the standard C++ header. If you -are referring to Standard C APIs directly or indirectly, you must specify libc.lib and libpthread.lib in -the .mmp file.

    Example

    The following -code snippet illustrates the use of STDCPP MMP keyword and -the use of the exe target type:

    //test_exe.mmp -Target test_exe.exe -Targettype exe -//The STDCPP keyword specifies Standard C++ -STDCPP -Source test2.cpp -Systeminclude /epoc32/include/stdapis/stlportv5 -Systeminclude /epoc32/include/stdapis -Library libstdcppv5.lib libc.lib -Staticlibrary libcrt0.lib -Capability all -tcb -//End of test_exe.mmp
    -     -Copyright -Acknowledgments for Standard C++ (STLport) -Standard -C++ Library Overview -Standard -C++ Support on the Symbian Platform -Developing -Applications or Libraries Using Standard C++ -Troubleshooting - -Known Issues - + + + + + +Building a Standard C++ Application or Library +

    This topic describes the required header files and libraries to +compile and link against to build a Standard C++ application or library +on a Symbian platform build environment.

    +

    You can build a C++ application or library using one of the following +target types:

    +
      +

    • STD target types

      • +

    • Other Symbian target types

      • +
    +

    Notes:

    +
      +

    • The required +standard C++ header files are available in the ${EPOCROOT}/epoc32/include/stdapis/stlportv5 directory.

      • +

    • The standard +C++ library name is libstdcppv5.lib.

      • +

    • You must specify +the system-include path and library name in the .mmp file associated with the C++ application or library.

      • +
    +
    STD +target types

    You can develop a C++ application or library +using the following STD target types:

      +

    • STDEXE

      • +

    • STDDLL

      • +

    • STDLIB

      • +

    These target types enable symbol lookup by name thereby adding +the symbol information into the executable.

    Note: For +more information about STD target types (STDEXE /STDDLL /STDLIB), see the Target Types section.

    Example

    The following code snippet +illustrates the use of the STD target type stdexe:

    //writing an stdexe, the mmp file may look like follows +//Start of test_stdexe.mmp +Target test_stdexe.exe +Targettype stdexe +Source test1.cpp +Systeminclude /epoc32/include/stdapis/stlportv5 +Library libstdcppv5.lib +Capability all -tcb +//End of test_stdexe.mmp
    +
    Other +Symbian target types

    You can avoid symbol information overhead +while developing C++ applications or libraries, by performing the +following configurations:

      +

    1. Use the other +Symbian target types such as, dll, lib, exe and so on. For more information about other +Symbian target types, see Symbian Tools Guide > Building + > Symbian Build System (SBSv1) > Build tools reference > MMP file +syntax > targettype.

      2. +

    2. In addition, +use the MMP keyword STDCPP.

      3. +

    You may also have to include ${EPOCROOT}/epoc32/include/stdapis explicitly as the standard C headers are required by the standard +C++ header. If you are referring to Standard C APIs directly or indirectly, +you must specify libc.lib and libpthread.lib in the .mmp file.

    Example

    The following code snippet illustrates the use of STDCPP MMP keyword and the use of the exe target type:

    //test_exe.mmp +Target test_exe.exe +Targettype exe +//The STDCPP keyword specifies Standard C++ +STDCPP +Source test2.cpp +Systeminclude /epoc32/include/stdapis/stlportv5 +Systeminclude /epoc32/include/stdapis +Library libstdcppv5.lib libc.lib +Staticlibrary libcrt0.lib +Capability all -tcb +//End of test_exe.mmp
    +     +Copyright +Acknowledgments for Standard C++ (STLport) +Standard +C++ Library Overview +Standard +C++ Support on the Symbian Platform +Developing +Applications or Libraries Using Standard C++ +Troubleshooting + +Known +Issues     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E402616A-7ED8-45AC-B836-99C3A3760B33.dita --- a/Symbian3/SDK/Source/GUID-E402616A-7ED8-45AC-B836-99C3A3760B33.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E402616A-7ED8-45AC-B836-99C3A3760B33.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,7 +10,7 @@ Key events -Key presses generate key events +Key presses generate key events

    Key events are generated when a device user presses one or more device key buttons. The application framework delivers the event to the application that has focus. The TKeyEvent structure is used to contain diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E449F309-F230-46F9-B777-EF64D0E3191D.dita --- a/Symbian3/SDK/Source/GUID-E449F309-F230-46F9-B777-EF64D0E3191D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E449F309-F230-46F9-B777-EF64D0E3191D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,7 +17,7 @@ note. Errors that are not too serious should cause an information note.

    Information note - +
    Using information notes in applications

    You can create either a basic diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4543D60-A9D0-5121-9540-993BB15D3275_d0e332473_href.png Binary file Symbian3/SDK/Source/GUID-E4543D60-A9D0-5121-9540-993BB15D3275_d0e332473_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4543D60-A9D0-5121-9540-993BB15D3275_d0e338939_href.png Binary file Symbian3/SDK/Source/GUID-E4543D60-A9D0-5121-9540-993BB15D3275_d0e338939_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E455ABFF-3EFF-5396-A52A-A33CDB2EB41A.dita --- a/Symbian3/SDK/Source/GUID-E455ABFF-3EFF-5396-A52A-A33CDB2EB41A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E455ABFF-3EFF-5396-A52A-A33CDB2EB41A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -38,6 +38,6 @@ an example. See the diagram below.

    Effect of CleanupClosePushL and subsequent pop and destroy - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E489F575-DD07-4949-AB98-8F6A11BF708A_d0e66511_href.png Binary file Symbian3/SDK/Source/GUID-E489F575-DD07-4949-AB98-8F6A11BF708A_d0e66511_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E489F575-DD07-4949-AB98-8F6A11BF708A_d0e66654_href.png Binary file Symbian3/SDK/Source/GUID-E489F575-DD07-4949-AB98-8F6A11BF708A_d0e66654_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E48B708E-8B0B-5CF7-80D5-B55966387021.dita --- a/Symbian3/SDK/Source/GUID-E48B708E-8B0B-5CF7-80D5-B55966387021.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,119 +0,0 @@ - - - - - -GCCE build -targets -

    Introduction

    -

    The GCCE build target builds ARM code using a version -of the freely available GNU Compiler Collection (GCC) tools. The GCC compiler -is intended only for building applications, and cannot be used to compile -the complete Symbian platform.

    -

    The GCC binaries conform to ABIv2 for the ARM architecture. Details about -the ABI standard are published at http://www.arm.com/products/DevTools/ABI.html.

    -

    The following table lists the GCC build targets available for various ARM -architectures that use Thumb or Thumb2 instruction sets:

    - - - - -Build target -ARM architecture -Instruction set - - - - -

    GCCE

    -

    V5

    -

    Thumb

    -     - -

    GCCEV6

    -

    V6

    -

    Thumb

    -     - -

    GCCEV6t2

    -

    V6

    -

    Thumb-2

    -     - -

    GCCEV7

    -

    V7

    -

    Thumb-2

    -     - - -
    -

    Note: Code built for the targets listed in the earlier table can -interoperate with code built by other compilers for ARM targets.

    -

    Prerequisite

    -

    To build for the GCC targets, you must install the GCC CSL ARM toolchain. -The installer, arm-none-symbianelf-2005-q1c.exe, is supplied -in kits, and is located at epoc32\tools\distrib\. Run -this program to start the installation wizard. By default, the compiler is -installed to C:\Program Files\CSL Arm Toolchain\.

    -

    The installation wizard does not modify the Windows PATH environment -variable. You must manually add the bin sub-directory -of the installed tools to the PATH variable. For example, -if the compiler is installed to C:\gcce, then C:\gcce\bin must -be added to the PATH environment variable.

    -

    Building for GCC targets

    -

    GCC targets are not the default build targets. To build a program for any -GCC target, you must explicitly specify the targets as supported platforms -in the component's BLD.INF file, using prj_platforms statement.

    -

    For example:

    -PRJ_PLATFORMS -WINSCW GCCE GCCEV6 GCCEV6t2 GCCEV7 -

    allows the component to be built for WINSCW, GCCE, GCCEV6, GCCEV6t2, -and GCCEV7.

    -

    You can build component for the GCC targets using the following bldmake and abld commands:

    -

    bldmake bldfiles

    -

    abld build gcce | gccev6 | gccev6t2 | gccev7 [udeb | urel]

    -

    Note: To build for GCCEV6t2 and GCCEV7, -you need GCCE v4.2 that supports building ARM code for Thumb-2.

    -

    Binaries are generated in the udeb and urel sub-directories -of the epoc32\release\<GCC platform>\ directory.

    -

    Import library (.dso) files are generated in the epoc32\release\ARMV5\lib\ directory. -This directory is used, as the library file format has not changed since ARMV5.

    -

    Note: These are the same directories that are used for import libraries -generated by RVCT for different build targets, such as ARMV5, ARMV6, -and so on. This allows other applications to link to any library, regardless -of the build target for which they are generated.

    -

    ROM building

    -

    The compiler setting allows the Symbian base components to include the -correct compiler-specific run-time libraries in the ROM image.

    -

    The default compiler used to build is ARM RVCT. This compiler is indicated -to buildrom using the argument -DRVCT.

    -

    The toolchain from Symbian OS v9.1 also supports binaries built with the GCCE compiler. -Binaries built with this compiler can be combined in ROM with binaries built -with RVCT to the ABIv2. To do this, use -the -D_GCCE macro:

    -

    buildrom -D_EABI=ARMV5 -D_GCCE -otechview.img h2 techview

    -

    By default, if the binaries are not available in GCCE, they are taken from -the ARMV5_ABIV2 directory, and if not in there also, they -are be taken from the ARMV5 directory. (ARMV5 is -necessary as some of the runtime DLLs will be present only in that directory.) -

    -

    The order in which buildrom searches directories to get binaries to put -into ROM can also be specified explicitly using a BINARY_SELECTION_ORDER command -in an oby file. For example:

    -

    BINARY_SELECTION_ORDER = GCCE, ARMV5_ABIv2, ARMV5

    -

    The preceding command specifies explicitly that binaries should taken from GCCE, -then ARMV5_ABIv2, and then ARMV5.

    -

    Source issues

    -

    The GCCE build target uses the same DEF file format as -the ARMV5 target. By default, the GCC toolchian looks for -the DEF files in the project's EABI directory.

    -

    Note: The GCC compiler is very strict in checking that the source -code conforms to the ANSI C++ standard. Therefore, source code that previously -compiled with less strict compilers, such as RVCT 2.1, may no longer compile.

    -     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4A23972-CC2F-5773-B1A4-6123333D1F5E.dita --- a/Symbian3/SDK/Source/GUID-E4A23972-CC2F-5773-B1A4-6123333D1F5E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,13 +0,0 @@ - - - - - -start <platform> ... end

    start platform

    platform-specific-statement-list

    [COPY_FOR_STATIC_LINKAGE]

    end

    A platform-specific section is enclosed in a start and end block.

    The platform-specific statements allowed depend on the platform. Unlike #if defined blocks, which allow statements to specify different files dependent upon the platform for which the makefile is being created, start ... end platform blocks are used to delimit statements understood only by the build tools when creating a makefile for a particular platform.

    Specify the platform as MARM if the section is defined for ARM platforms, or WINS for non-ARM platforms. Specify the platform as WINC for WINC and VC6WINC only sections.

    The COPY_FOR_STATIC_LINKAGE statement is useful for DLLs that are both dynamically loaded and statically linked. If it is used in a START WINS block, then the target DLL is built both into the specified target directory (for dynamic loading), and into the epoc32\release\ wins or - winscw \ udeb or urel (for static linking).

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4B5C7CE-7820-5D80-8CD1-DCD692C11F23_d0e130564_href.png Binary file Symbian3/SDK/Source/GUID-E4B5C7CE-7820-5D80-8CD1-DCD692C11F23_d0e130564_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4B5C7CE-7820-5D80-8CD1-DCD692C11F23_d0e134184_href.png Binary file Symbian3/SDK/Source/GUID-E4B5C7CE-7820-5D80-8CD1-DCD692C11F23_d0e134184_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E4BF80BE-17E9-5622-9E10-43C96EAC9754.dita --- a/Symbian3/SDK/Source/GUID-E4BF80BE-17E9-5622-9E10-43C96EAC9754.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -pagedcode

    pagedcode

    Use the pagedcode statement to specify that the executable is code paged.

    If an executable is marked as code paged, the pages are loaded into RAM page by page on demand. This can reduce application startup time and memory usage.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e201740_href.png Binary file Symbian3/SDK/Source/GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e201740_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e206747_href.png Binary file Symbian3/SDK/Source/GUID-E51546A8-D000-540C-A757-56B323EA9DA7_d0e206747_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E5291BCB-D5D0-5175-B0A1-FE03CD14E1BD.dita --- a/Symbian3/SDK/Source/GUID-E5291BCB-D5D0-5175-B0A1-FE03CD14E1BD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E5291BCB-D5D0-5175-B0A1-FE03CD14E1BD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Configuring and clearing files

    You can configure the following settings for audio or video files, and the session log file:

    • Configuring audio files

    • Configuring video files

    • Configuring file metadata

    • Setting the video output screen

    • Enabling auto pause and resume for video

    • Clearing the log file

    Note: You can configure media files only when they are open, and when they are neither being recorded nor played.

    Configuring audio files

    To configure the settings of an audio file:

    1. In the File menu, click Open for Play, and select the audio file you want to configure.

    2. In the Settings menu, click Audio. The Audio Settings dialog box is displayed.

    3. In the Repeats box, enter the number of times to repeat the audio clip.

    4. In the Delay box, enter the interval between repeats in seconds.

    5. Select the Autoplay check box to play the file automatically when you open it for play.

    6. Select the Priority and Priority Preference.

    7. Select the Auto Pause&Resume check box to enable this functionality.

    8. Click OK to save the audio settings.

    Configuring video files

    Note: The ability to configure the video settings is not yet supported.

    To configure the settings of a video file:

    1. In the File menu, click Open for Play, and select the video file you want to configure.

    2. In the Settings menu, click Video. The Video Setting dialog box is displayed.

    3. Select the degree of Rotation.

    4. Enter percentages for the Scale Width and Scale Height.

    5. Select the Anti Alias Filtering check box to enable anti-alias filtering.

    6. Enter the coordinates in the top, bottom, left and right boxes to define the boundaries of the crop region.

    7. Select the Viewfinder check box to enable it.

    8. Enter values for the Camera Index and Camera Priority.

    9. Click OK to save the video settings.

    Configuring file metadata

    You can enter the metadata for any media file that is open for record. You can view but cannot modify the metadata of a file that is open for play.

    To enter or modify file metadata:

    1. In the File menu, select Open for Record.

    2. In the Settings menu, select Meta Data. The MetaData dialog box is displayed.

    3. Enter information into the Title, Author, Copyright, Revision, Category and Comments boxes.

    4. Click OK to save the metadata details entered.

    Setting the video output screen

    You can set the video output rendering to any specific screen number.

    To set the output screen:

    1. In the Settings menu, select Multiple Screen. The Set Output Screen dialog box is displayed.

    2. Enter the Screen Number in the Enter the Screen Number box.

    3. Click OK to save the output screen setting.

      Note: If the Screen Number is not supported, the MVS displays a KErrNotSupported message.

    Enabling auto pause and resume for video

    You can enable auto pause and resume for video by registering for resource notification. Registering for resource notification means that the audio playback for a video can be paused and resumed efficiently if access to the resource is lost and subsequently regained.

    To enable auto pause and resume:

    1. In the Settings menu, select Register For Notification. The Register For Resource Notification dialog box is displayed.

    2. Select the Enable Auto Pause & Resume check box to enable this functionality.

    3. Click OK to save the auto pause and resume setting.

      If you currently have a media file open for record, an information message is displayed to inform you that the setting has been applied. Otherwise, the setting is saved and applied when you next open a media file for record.

    To disable auto pause and resume, repeat the above steps but clear the Enable Auto Pause & Resume check box.

    Clearing the log file

    All events during a session are recorded in a log file.

    To clear the log for the current session, in the Settings menu, click ClearLog.

    Note: This feature is currently not available.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Recording media files

    Playing media files

    Editing media files

    \ No newline at end of file +Configuring and clearing files

    You can configure the following settings for audio or video files, and the session log file:

    • Configuring audio files

    • Configuring video files

    • Configuring file metadata

    • Setting the video output screen

    • Enabling auto pause and resume for video

    • Clearing the log file

    Note: You can configure media files only when they are open, and when they are neither being recorded nor played.

    Configuring audio files

    To configure the settings of an audio file:

    1. In the File menu, click Open for Play, and select the audio file you want to configure.

    2. In the Settings menu, click Audio. The Audio Settings dialog box is displayed.

    3. In the Repeats box, enter the number of times to repeat the audio clip.

    4. In the Delay box, enter the interval between repeats in seconds.

    5. Select the Autoplay check box to play the file automatically when you open it for play.

    6. Select the Priority and Priority Preference.

    7. Select the Auto Pause&Resume check box to enable this functionality.

    8. Click OK to save the audio settings.

    Configuring video files

    Note: The ability to configure the video settings is not yet supported.

    To configure the settings of a video file:

    1. In the File menu, click Open for Play, and select the video file you want to configure.

    2. In the Settings menu, click Video. The Video Setting dialog box is displayed.

    3. Select the degree of Rotation.

    4. Enter percentages for the Scale Width and Scale Height.

    5. Select the Anti Alias Filtering check box to enable anti-alias filtering.

    6. Enter the coordinates in the top, bottom, left and right boxes to define the boundaries of the crop region.

    7. Select the Viewfinder check box to enable it.

    8. Enter values for the Camera Index and Camera Priority.

    9. Click OK to save the video settings.

    Configuring file metadata

    You can enter the metadata for any media file that is open for record. You can view but cannot modify the metadata of a file that is open for play.

    To enter or modify file metadata:

    1. In the File menu, select Open for Record.

    2. In the Settings menu, select Meta Data. The MetaData dialog box is displayed.

    3. Enter information into the Title, Author, Copyright, Revision, Category and Comments boxes.

    4. Click OK to save the metadata details entered.

    Setting the video output screen

    You can set the video output rendering to any specific screen number.

    To set the output screen:

    1. In the Settings menu, select Multiple Screen. The Set Output Screen dialog box is displayed.

    2. Enter the Screen Number in the Enter the Screen Number box.

    3. Click OK to save the output screen setting.

      Note: If the Screen Number is not supported, the MVS displays a KErrNotSupported message.

    Enabling auto pause and resume for video

    You can enable auto pause and resume for video by registering for resource notification. Registering for resource notification means that the audio playback for a video can be paused and resumed efficiently if access to the resource is lost and subsequently regained.

    To enable auto pause and resume:

    1. In the Settings menu, select Register For Notification. The Register For Resource Notification dialog box is displayed.

    2. Select the Enable Auto Pause & Resume check box to enable this functionality.

    3. Click OK to save the auto pause and resume setting.

      If you currently have a media file open for record, an information message is displayed to inform you that the setting has been applied. Otherwise, the setting is saved and applied when you next open a media file for record.

    To disable auto pause and resume, repeat the above steps but clear the Enable Auto Pause & Resume check box.

    Clearing the log file

    All events during a session are recorded in a log file.

    To clear the log for the current session, in the Settings menu, click ClearLog.

    Note: This feature is currently not available.

    See Also

    Introduction to the MVS

    MVS GUI layout

    Recording media files

    Playing media files

    Editing media files

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E52D52C8-AC58-5550-8932-59B314A47313_d0e322816_href.jpg Binary file Symbian3/SDK/Source/GUID-E52D52C8-AC58-5550-8932-59B314A47313_d0e322816_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E52D52C8-AC58-5550-8932-59B314A47313_d0e329286_href.jpg Binary file Symbian3/SDK/Source/GUID-E52D52C8-AC58-5550-8932-59B314A47313_d0e329286_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E544A944-5A65-40BD-A3B4-EF14E6132130_d0e4524_href.png Binary file Symbian3/SDK/Source/GUID-E544A944-5A65-40BD-A3B4-EF14E6132130_d0e4524_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E544A944-5A65-40BD-A3B4-EF14E6132130_d0e4651_href.png Binary file Symbian3/SDK/Source/GUID-E544A944-5A65-40BD-A3B4-EF14E6132130_d0e4651_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E56D30B2-9EF7-555C-8119-9F5E0F959AB4_d0e203595_href.png Binary file Symbian3/SDK/Source/GUID-E56D30B2-9EF7-555C-8119-9F5E0F959AB4_d0e203595_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E56D30B2-9EF7-555C-8119-9F5E0F959AB4_d0e208602_href.png Binary file Symbian3/SDK/Source/GUID-E56D30B2-9EF7-555C-8119-9F5E0F959AB4_d0e208602_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E56EB25C-9B94-5486-9492-5151FDF79B6C.dita --- a/Symbian3/SDK/Source/GUID-E56EB25C-9B94-5486-9492-5151FDF79B6C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E56EB25C-9B94-5486-9492-5151FDF79B6C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ and unregisters surfaces:

    Surface registration - +

    The Video Renderer uses the global constant KAllScreens (provided by the Surface Update component) to ensure all displays are updated with new @@ -39,7 +39,7 @@ Data flow between client, Video Renderer and Surface Update client-side API - + Video Renderer diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E58FA02A-D721-42FC-941F-1D8E5BCD96BC_d0e67722_href.png Binary file Symbian3/SDK/Source/GUID-E58FA02A-D721-42FC-941F-1D8E5BCD96BC_d0e67722_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E5962E2D-C2D1-40EC-96FB-79CA6D10417F_d0e4765_href.png Binary file Symbian3/SDK/Source/GUID-E5962E2D-C2D1-40EC-96FB-79CA6D10417F_d0e4765_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E5962E2D-C2D1-40EC-96FB-79CA6D10417F_d0e4890_href.png Binary file Symbian3/SDK/Source/GUID-E5962E2D-C2D1-40EC-96FB-79CA6D10417F_d0e4890_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E5FB2D04-D57E-4EEA-850F-40F813C75D8C_d0e5506_href.png Binary file Symbian3/SDK/Source/GUID-E5FB2D04-D57E-4EEA-850F-40F813C75D8C_d0e5506_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E5FB2D04-D57E-4EEA-850F-40F813C75D8C_d0e5627_href.png Binary file Symbian3/SDK/Source/GUID-E5FB2D04-D57E-4EEA-850F-40F813C75D8C_d0e5627_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E60F9268-35D5-4D3F-B219-22AECF13953B_d0e74377_href.png Binary file Symbian3/SDK/Source/GUID-E60F9268-35D5-4D3F-B219-22AECF13953B_d0e74377_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E60F9268-35D5-4D3F-B219-22AECF13953B_d0e74415_href.png Binary file Symbian3/SDK/Source/GUID-E60F9268-35D5-4D3F-B219-22AECF13953B_d0e74415_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E61A931D-6E66-5E17-AE61-ABFB74CB8EF2.dita --- a/Symbian3/SDK/Source/GUID-E61A931D-6E66-5E17-AE61-ABFB74CB8EF2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E61A931D-6E66-5E17-AE61-ABFB74CB8EF2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -14,7 +14,7 @@

    The diagram illustrates the life-cycle of an active object.

    Flow diagram showing the life cycle of an active object - +

    Procedural flow follows the black arrows; control is transferred along the blue links, as follows:

    diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e77303_href.png Binary file Symbian3/SDK/Source/GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e77303_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e77341_href.png Binary file Symbian3/SDK/Source/GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e77341_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E63AAE78-335F-5BD3-BECA-1709C3C7FB3F.dita --- a/Symbian3/SDK/Source/GUID-E63AAE78-335F-5BD3-BECA-1709C3C7FB3F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -baseaddress

    baseaddress hex-constant

    Use the baseaddress statement to specify the address to which a DLL will be built and, if possible, loaded. It only applies to WINSCW/WINS builds.

    Use it to give each DLL a different base address, so that the Windows loader does not have to do any relocation while loading Symbian platform and its DLLs. This considerably speeds up the initialisation of Symbian platform under WINSCW/WINS.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E63D0A01-EF87-566F-9BFA-9E75AD6F3205.dita --- a/Symbian3/SDK/Source/GUID-E63D0A01-EF87-566F-9BFA-9E75AD6F3205.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E63D0A01-EF87-566F-9BFA-9E75AD6F3205.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Window HierarchyIn a running application, all window instances are arranged in a hierarchy, in which each window has a parent. The Window Server has a window not owned by the client, called the "root" window which is the parent of all the group windows.

    Variant: Both (ScreenPlay and non-ScreenPlay). Target audience: Application developers.

    Parent windows

    The following diagram shows the relationship between parent and child windows and window groups at run-time. Arrows indicate "is a parent of".

    Window hierarchy -

    The relationships between parent and child windows have the following properties:

    • A window's parent is specified when the window is created.

    • The Window Server imposes no limit to the number of children a window can have. The number of children is limited only by the resources of the system.

    • When a parent window is destroyed, all its children are removed from the screen. However, the objects associated with them are not destroyed until the window or the client that owns them is destroyed.

    • A window's parent defines the region in which the window can be displayed. A child cannot be displayed outside its parent, and is clipped to the parent’s visible region. If a child window is moved so that part of it extends beyond its parent, that part of the child window will not be visible.

    • Note that if a window's parent is a window group, the window can be displayed anywhere on the screen, because window groups do not have a size.

    Sibling windows

    If a window has multiple children, these are known as siblings. Sibling windows are maintained in a list, and the parent window owns a link to the first window in the sibling list. The order of the windows in the sibling list represents the windows’ ordinal position. This determines which windows are displayed on top of which, if they overlap.

    Window Types     \ No newline at end of file +

    The relationships between parent and child windows have the following properties:

    • A window's parent is specified when the window is created.

    • The Window Server imposes no limit to the number of children a window can have. The number of children is limited only by the resources of the system.

    • When a parent window is destroyed, all its children are removed from the screen. However, the objects associated with them are not destroyed until the window or the client that owns them is destroyed.

    • A window's parent defines the region in which the window can be displayed. A child cannot be displayed outside its parent, and is clipped to the parent’s visible region. If a child window is moved so that part of it extends beyond its parent, that part of the child window will not be visible.

    • Note that if a window's parent is a window group, the window can be displayed anywhere on the screen, because window groups do not have a size.

    Sibling windows

    If a window has multiple children, these are known as siblings. Sibling windows are maintained in a list, and the parent window owns a link to the first window in the sibling list. The order of the windows in the sibling list represents the windows’ ordinal position. This determines which windows are displayed on top of which, if they overlap.

    Window Types     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E64A8D76-28AD-4F75-9E92-3290488F85D9_d0e67410_href.png Binary file Symbian3/SDK/Source/GUID-E64A8D76-28AD-4F75-9E92-3290488F85D9_d0e67410_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E64A8D76-28AD-4F75-9E92-3290488F85D9_d0e67551_href.png Binary file Symbian3/SDK/Source/GUID-E64A8D76-28AD-4F75-9E92-3290488F85D9_d0e67551_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita --- a/Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -48,7 +48,7 @@ are three parameters, one of which is an integer, and the other two being pointers to descriptors.

    - +

    Inter-thread data transfer
    See also

    Descriptor diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E65D89C5-0472-573A-BD1C-B298848CD4CF.dita --- a/Symbian3/SDK/Source/GUID-E65D89C5-0472-573A-BD1C-B298848CD4CF.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E65D89C5-0472-573A-BD1C-B298848CD4CF.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -Bluetooth Collection OverviewThe Bluetooth collection contains the SDP, GAVDP and notifier support components.

    Purpose

    The Bluetooth Collection contains the SDP, GAVDP and notifier support components.

    Architecture
    Components

    The Bluetooth collection contains the following components:

    • SDP

      Bluetooth Service Discovery Protocol (SDP) enables a device to find out what services are available on another device. For example, when connecting a mobile phone to a bluetooth headset, SDP can find out which Bluetooth profiles the headset supports. The SDP component enables devices to register services to the SDP database and to query the database for available services. The SDP Agent and the SDP Database provide functionality for the SDP component.

    • GAVDP

      Generic Audio Video Distribution Profile (GAVDP) enables audio or video streaming.

    • Bluetooth Notifiers Support

      The Bluetooth Notifiers Support component enables you to create dialogs for interacting with device users about Bluetooth interactions. You can offer Bluetooth dialogs for several purposes, but the main purpose is to provide security for Bluetooth interactions.

    Using the Bluetooth collection

    The Bluetooth collection has the following uses:

    • using SDP to find out what services are available on another device

    • Using GAVDP to enable audio or video streaming

    • using the Bluetooth Notifiers Support to create dialogs for interacting with device users about Bluetooth interactions.

    \ No newline at end of file +Bluetooth Collection OverviewThe Bluetooth collection contains the SDP, GAVDP and notifier support components.
    Purpose

    The Bluetooth Collection contains the SDP, GAVDP and notifier support components.

    Architecture
    Components

    The Bluetooth collection contains the following components:

    • SDP

      Bluetooth Service Discovery Protocol (SDP) enables a device to find out what services are available on another device. For example, when connecting a mobile phone to a bluetooth headset, SDP can find out which Bluetooth profiles the headset supports. The SDP component enables devices to register services to the SDP database and to query the database for available services. The SDP Agent and the SDP Database provide functionality for the SDP component.

    • GAVDP

      Generic Audio Video Distribution Profile (GAVDP) enables audio or video streaming.

    • Bluetooth Notifiers Support

      The Bluetooth Notifiers Support component enables you to create dialogs for interacting with device users about Bluetooth interactions. You can offer Bluetooth dialogs for several purposes, but the main purpose is to provide security for Bluetooth interactions.

    Using the Bluetooth collection

    The Bluetooth collection has the following uses:

    • using SDP to find out what services are available on another device

    • Using GAVDP to enable audio or video streaming

    • using the Bluetooth Notifiers Support to create dialogs for interacting with device users about Bluetooth interactions.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E6803961-14A0-44BD-A94E-5D8A38EA907F.dita --- a/Symbian3/SDK/Source/GUID-E6803961-14A0-44BD-A94E-5D8A38EA907F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E6803961-14A0-44BD-A94E-5D8A38EA907F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -21,7 +21,7 @@ keypad solutions should take this into account.

    Lists and grids - +
    Using lists and grids in applications

    The APIs to use for lists and grids diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E6CB4891-AFC8-50BB-A2C8-057DB1269DA9.dita --- a/Symbian3/SDK/Source/GUID-E6CB4891-AFC8-50BB-A2C8-057DB1269DA9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,40 +0,0 @@ - - - - - -Meta -files -

    A meta file is a simple text file associated with each template extension -makefile, it contains additional information about the extension such as makefile -type, platform and so on.

    -

    Following is the syntax for meta file:

    -

    makefile gnumake | nmake

    -

    [platform value]

    -

    [option option-name_1 option-value_1]

    -

    ...

    -

    [option option-name_n option-value_n]

    -

    The makefile gnumake | nmake is compulsory -for all the meta files. It specifies whether the makefile is of type gnumake or nmake.

    -

    The optional platform value specifies -the platforms for which the associated template extension makefile can be -applied. If not specified, the makefile is invoked for all the platforms. -For example, the platform could be winscw and/or ARMv5.

    -

    The optional option option-name option-value sets -a default value for an option, which can be changed within START EXTENSION...END block -in the bld.inf file. For more information, refer to prj_extensions.

    -

    This example will set values to platform and makefile variables.

    #copy_default.meta -# - -makefile gnumake -platform win32     - -How to write -a meta file - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E71D8907-236E-5948-9594-E14E34A31DC8.dita --- a/Symbian3/SDK/Source/GUID-E71D8907-236E-5948-9594-E14E34A31DC8.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -document

    document document-file-list

    Use the document statement to specify document files.

    Each document statement may specify an arbitrary number of document files.

    There may be an arbitrary number of document statements in the project description file relative to each sourcepath.

    This keyword is only used in the creation of IDE makefiles, where it can be useful for specifying files so that they are available for editing within the IDE but do not play a part in building the executable.

    The .mmp file is incorporated in IDE workspaces by default.

     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E71DEB5F-A13A-5675-B2DE-9BCFDB38A3EC.dita --- a/Symbian3/SDK/Source/GUID-E71DEB5F-A13A-5675-B2DE-9BCFDB38A3EC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E71DEB5F-A13A-5675-B2DE-9BCFDB38A3EC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -What is the mechanism for reading, writing and searching for dataThis topic describes the mechanism for reading data from the Comms Database and writing data to the Comms Database.

    All elements that you can read and write have the class MMetaDatabase as a base class. This base class contains the functions that get and store that element.

    Tables, records, links and fields are all elements. The classes that represent tables, records, links and fields have MMetaDatabase in their class hierarchy. You use the functions in MMetaDatabase to load and store tables, records, links and fields.

    The MMetaDatabase class gives you:

    • the functions to get data from the Comms Database: LoadL(), FindL(), RefreshL()

    • the functions to put data into the Comms Database: StoreL(), ModifyL(), DeleteL()

    Getting data directly from the Comms Database

    If you know the record Id part of the element Id of a table, record, field or link, you can load the table, record, field or link from the Comms Database. Call SetRecordId() on the CMDBElement base class to set the record Id. Call LoadL() on the MMetaDatabase base class to load the table, record, field or link.

    The CommsDat API gets the data that the tool or application is allowed to see from the Comms database. The data that the tool or application can see depends on platform security capabilities and the access attributes for the session.

    A request to load a single element fails if the tool or application does not have the platform security capabilities.

    A request to load a table does not fail if some records in the table are not available. The tool or application can see only those records that are available.

    A request to load a record does not fail if some fields in the record are not available. The tool or application can see only those fields that are available.

    LoadL() writes over the content of the table, record, field or link object in memory.

    LoadL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Finding data in the Comms Database

    You can search for records in the Comms Database. There are two patterns:

    Finding a single record that has specified field values

    You create a CMDBRecordBase object in memory. You select the fields for the search and set the field values. Call FindL() on the CMDBRecordBase object. FindL() is member of the MMetaDatabase base class. If the search is successful, the CommsDat API fills the CMDBRecordBase object with the values from the first record in the Comms Database that matches. The values include the element Id. If the search is not successful, the CMDBRecordBase object is not changed.

    FindL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Note that you do not need to set the record Id part of the element Id of the table, the record, the field or the link object.

    Finding all records in a table that match a specified record

    You create a CMDBRecordSet object and append a single record to the array of records. You select the fields for the search and set the field values. This record is the 'search record'. Call FindL() on the CMDBRecordSet object. If the search is successful, the function returns a number of complete records. The first record found writes over the 'search record'. If the search is not successful, the CMDBRecordSet object is not changed

    FindL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Note that you do not need to set the record Id part of the element Id of the table, the record, the field or the link object.

    Refreshing data in memory

    You can update your copy of the data in memory. You call RefreshL() to update the data. The method is similar to LoadL() but the method does not write over fields that the tool or application has changed. All other fields are refreshed from the Comms Database.

    RefreshL() is a member of the MMetaDatabase base class.

    RefreshL() is useful if a tool or application maintains a cache of Comms information.

    RefreshL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Adding new data to the Comms Database

    If need to add or change the data in the Comms Database you must add or change the data in the table, the record, the link or the field object in memory.

    Call StoreL() to create new records, tables and fields. The CommsDat API only stores the fields that the tool or application has changed.

    A table, record, field or link object that exists must have a valid element Id before the call to StoreL().

    To add a new user defined table to the Comms Database set the record Id part of the element Id of the table to KCDNewTableRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id.

    To add a new record to a table set the record Id part of the element Id of the table to KCDNewRecordRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id. The table must exist before you add the new record.

    To add a new column to a user defined table set the record Id part of the element Id of the table to KCDNewColumnRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id. The effect of a new column is to add a new field in the user defined records.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    StoreL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    Changing data in the Comms Database

    If you need to change data in the Comms Database you must change the data in the table, the record, the link or the field object in memory. The table, the record, the link and the field must already exist in the database.

    Call ModifyL() to change existing data. The function cannot create new records or tables, but can store new fields in a record.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    ModifyL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    Deleting data from the Comms Database

    Call DeleteL() to delete a table, a record, a field or a link from the Comms Database.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    DeleteL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    \ No newline at end of file +What is the mechanism for reading, writing and searching for dataThis topic describes the mechanism for reading data from the Comms Database and writing data to the Comms Database.

    All elements that you can read and write have the class MMetaDatabase as a base class. This base class contains the functions that get and store that element.

    Tables, records, links and fields are all elements. The classes that represent tables, records, links and fields have MMetaDatabase in their class hierarchy. You use the functions in MMetaDatabase to load and store tables, records, links and fields.

    The MMetaDatabase class gives you:

    • the functions to get data from the Comms Database: LoadL(), FindL(), RefreshL()

    • the functions to put data into the Comms Database: StoreL(), ModifyL(), DeleteL()

    Getting data directly from the Comms Database

    If you know the record Id part of the element Id of a table, record, field or link, you can load the table, record, field or link from the Comms Database. Call SetRecordId() on the CMDBElement base class to set the record Id. Call LoadL() on the MMetaDatabase base class to load the table, record, field or link.

    The CommsDat API gets the data that the tool or application is allowed to see from the Comms database. The data that the tool or application can see depends on platform security capabilities and the access attributes for the session.

    A request to load a single element fails if the tool or application does not have the platform security capabilities.

    A request to load a table does not fail if some records in the table are not available. The tool or application can see only those records that are available.

    A request to load a record does not fail if some fields in the record are not available. The tool or application can see only those fields that are available.

    LoadL() writes over the content of the table, record, field or link object in memory.

    LoadL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Finding data in the Comms Database

    You can search for records in the Comms Database. There are two patterns:

    Finding a single record that has specified field values

    You create a CMDBRecordBase object in memory. You select the fields for the search and set the field values. Call FindL() on the CMDBRecordBase object. FindL() is member of the MMetaDatabase base class. If the search is successful, the CommsDat API fills the CMDBRecordBase object with the values from the first record in the Comms Database that matches. The values include the element Id. If the search is not successful, the CMDBRecordBase object is not changed.

    FindL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Note that you do not need to set the record Id part of the element Id of the table, the record, the field or the link object.

    Finding all records in a table that match a specified record

    You create a CMDBRecordSet object and append a single record to the array of records. You select the fields for the search and set the field values. This record is the 'search record'. Call FindL() on the CMDBRecordSet object. If the search is successful, the function returns a number of complete records. The first record found writes over the 'search record'. If the search is not successful, the CMDBRecordSet object is not changed

    FindL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Note that you do not need to set the record Id part of the element Id of the table, the record, the field or the link object.

    Refreshing data in memory

    You can update your copy of the data in memory. You call RefreshL() to update the data. The method is similar to LoadL() but the method does not write over fields that the tool or application has changed. All other fields are refreshed from the Comms Database.

    RefreshL() is a member of the MMetaDatabase base class.

    RefreshL() is useful if a tool or application maintains a cache of Comms information.

    RefreshL() opens a read-only transaction with the Comms Database if the tool or application has not already started a transaction.

    Adding new data to the Comms Database

    If need to add or change the data in the Comms Database you must add or change the data in the table, the record, the link or the field object in memory.

    Call StoreL() to create new records, tables and fields. The CommsDat API only stores the fields that the tool or application has changed.

    A table, record, field or link object that exists must have a valid element Id before the call to StoreL().

    To add a new user defined table to the Comms Database set the record Id part of the element Id of the table to KCDNewTableRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id.

    To add a new record to a table set the record Id part of the element Id of the table to KCDNewRecordRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id. The table must exist before you add the new record.

    To add a new column to a user defined table set the record Id part of the element Id of the table to KCDNewColumnRequest before the call to StoreL(). Call SetRecordId() on the CMDBElement base class to set the record Id. The effect of a new column is to add a new field in the user defined records.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    StoreL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    Changing data in the Comms Database

    If you need to change data in the Comms Database you must change the data in the table, the record, the link or the field object in memory. The table, the record, the link and the field must already exist in the database.

    Call ModifyL() to change existing data. The function cannot create new records or tables, but can store new fields in a record.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    ModifyL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    Deleting data from the Comms Database

    Call DeleteL() to delete a table, a record, a field or a link from the Comms Database.

    The tool or application must have the platform security capabilities to write to the Comms Database.

    DeleteL() opens a read/write transaction with the Comms Database if the tool or application has not already started a transaction.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E726406A-2DAF-5A5F-91AF-7919C671F18F_d0e334814_href.png Binary file Symbian3/SDK/Source/GUID-E726406A-2DAF-5A5F-91AF-7919C671F18F_d0e334814_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E726406A-2DAF-5A5F-91AF-7919C671F18F_d0e341280_href.png Binary file Symbian3/SDK/Source/GUID-E726406A-2DAF-5A5F-91AF-7919C671F18F_d0e341280_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E77E2E2A-2F2D-549E-ABD6-175E68A406CB_d0e337536_href.png Binary file Symbian3/SDK/Source/GUID-E77E2E2A-2F2D-549E-ABD6-175E68A406CB_d0e337536_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E77E2E2A-2F2D-549E-ABD6-175E68A406CB_d0e344002_href.png Binary file Symbian3/SDK/Source/GUID-E77E2E2A-2F2D-549E-ABD6-175E68A406CB_d0e344002_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E7EFAD50-3323-49A6-A5D9-95B95F0FBF0E.dita --- a/Symbian3/SDK/Source/GUID-E7EFAD50-3323-49A6-A5D9-95B95F0FBF0E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E7EFAD50-3323-49A6-A5D9-95B95F0FBF0E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ data about an item that has focus in the main pane.

    Preview pop-up - +

    The preview is displayed with a 0.6 second delay after the focus is moved (for example, scrolling down a list with the Arrow keys) to avoid too rapid diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E808AB2B-3A2D-5C91-9047-A74AAA770CE6_d0e117401_href.png Binary file Symbian3/SDK/Source/GUID-E808AB2B-3A2D-5C91-9047-A74AAA770CE6_d0e117401_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E808AB2B-3A2D-5C91-9047-A74AAA770CE6_d0e117641_href.png Binary file Symbian3/SDK/Source/GUID-E808AB2B-3A2D-5C91-9047-A74AAA770CE6_d0e117641_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E80AA33B-E5E0-5F4B-9A7F-65B357F7161C.dita --- a/Symbian3/SDK/Source/GUID-E80AA33B-E5E0-5F4B-9A7F-65B357F7161C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,34 +0,0 @@ - - - - - -Overview -

    This section details the source text resource file format, and is a useful -reference for developers in C++ and OPL.

    -

    Topics covered include: the lexical conventions obeyed, the C++ pre-processor -statements supported, and a description of the native resource compiler statements.

    -

    Changes since v5

    -

    Note the following changes since v5:

    -
      -

    • UTF8 encoding can be -used in source files to represent Unicode values.

      • -

    • TEXT resources -have been deprecated: you should use LTEXT instead.

      • -

    • Binary compatible is -broken with Unicode resource files prepared with v5. The handling of Unicode -string resources (TEXT16 and LTEXT16) has -changed to ensure that the Unicode characters are aligned to a multiple of -2 bytes when the resource is used.

      • -

    • The < number > syntax -for using special character codes expects a Unicode character value if a Unicode -resource is being created. The < number > syntax cannot be used to specify -individual 8-bit values in Unicode resource files.

      • -
    - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E81D72B2-BA77-5F4E-8742-3812A60A4DAC.dita --- a/Symbian3/SDK/Source/GUID-E81D72B2-BA77-5F4E-8742-3812A60A4DAC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E81D72B2-BA77-5F4E-8742-3812A60A4DAC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,106 +1,101 @@ - - - - - -How to -use modifiable buffer descriptor — TBuf<TInt>Modifiable buffer descriptors are useful for holding strings or -data and providing safe ways to access and modify that data. -
      -

    • For text data, it is -usual to construct a TBuf<TInt> type and allow the appropriate -variant, either a TBuf8<TInt> or a TBuf16<TInt> to -be selected at build time.

      • -

    • For binary data, an -explicit TBuf8<TInt> is used.

      • -

    • It is rare to use an -explicit TBuf16<TInt>.

      • -
    -

    Although, the following notes refer to the build independent types; they -are equally valid for the explicit 8 bit and 16 bit types.

    -
    Constructing -a TBuf<TInt>

    A modifiable buffer descriptor can be constructed -in a number of ways:

      -

    • as an empty buffer descriptor.

      • -

    • as an empty buffer descriptor -but giving it a length.

      • -

    • by copying data from -any other type of descriptor.

      • -

    • by copying data from -another modifiable buffer descriptor of the same size.

      • -

    The following code fragment constructs a TBuf<16> object. -The buffer descriptor is uninitialised, i.e. it contains no data. The assignment -operator or the Copy() function can be used to put data into -the buffer descriptor after construction:

    _LIT(KText,"Hello World!"); -... -TBuf<16> buf1; // length of buf1 is 0 -... -buf1 = KText; // data assigned

    The source descriptor is a -literal which is converted to descriptor type.

    The following code fragment -constructs a TBuf<16> object and sets it length to 12. -No data is assigned into the descriptor.

    ... -TBuf<16> buf1(12); // length of buf1 is 12 -...

    The following code fragment constructs a TBuf<16> object, -initialised with the 12 characters making up the English language phrase "Hello -World!".

    _LIT(KText,"Hello World!"); -... -TBuf<16> buf1(KText);

    The following code fragment constructs -a TBuf<16> object from another TBuf<16> object. -This is, in effect, copy construction.

    _LIT(KText,"Hello World!"); -... -TBuf<16> buf1(KText); -TBuf<16> buf2(buf1); // buf2 constructed from the data in buf1

    In -both of these cases, the resulting length of the descriptor is 12.

    A -non-modifiable buffer descriptor can also be constructed from 'C' style zero -terminated string. However, this is rarely necessary but may make it easier -to port legacy 'C' code.

    -
    Replacing data

    Data -within a modifiable buffer descriptor can be completely replaced through the -assignment operator or by using the Copy() function.

    _LIT(KText,"Hello World!"); -_LIT(KNewText,"New text"); -_LIT(KReplaced,"Replaced"); -... -TBuf<16> buf1(KText); -TBuf<16> buf2; -... -buf2 = buf1; // buf2 now contains "Hello World!" -... -buf2 = KNewText; // buf2 now contains "New text". - // the literal is converted to a descriptor - // type. -buf2.Copy(KReplaced); // buf2 content replaced using Copy()
    -
    Accessing and -changing data

    Once a modifiable buffer descriptor has been constructed, -the functions in the base classes, TDesC and TDes, -are available to be access and change the data.

    _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); -... -buf1.Length();

    and

    _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); // length is 12 -... -buf1.Delete(6,6); // length is now 6, leaving "Hello" in - // the buffer
    -
    Illegal access -causing an exception

    The following code fragment raises a panic -because of an attempt to assign too much data. The maximum length of the buffer -descriptor is 16 but the length of the data to be copied is 31:

    _LIT(KText,"Hello World! The sun is shining"); -... -TBufC<16> buf1(KText);

    The following code fragment raises -a panic because of an attempt to delete data outside the boundary defined -by the descriptor:

    _LIT(KText,"Hello World!"); -... -TBufC<16> buf1(KText); -buf1.Delete(99,1);
    -     - -Literal Descriptors - + + + + + +How to use modifiable buffer descriptor — TBuf<TInt>Modifiable buffer descriptors are useful for holding strings +or data and providing safe ways to access and modify that data. +
      +

    • For text data, +it is usual to construct a TBuf<TInt> type and +allow the appropriate variant, either a TBuf8<TInt> or a TBuf16<TInt> to be selected at build time.

      • +

    • For binary data, +an explicit TBuf8<TInt> is used.

      • +

    • It is rare to +use an explicit TBuf16<TInt>.

      • +
    +

    Although, the following notes refer to the build independent types; +they are equally valid for the explicit 8 bit and 16 bit types.

    +
    Constructing +a TBuf<TInt>

    A modifiable buffer descriptor can be constructed +in a number of ways:

      +

    • as an empty +buffer descriptor.

      • +

    • as an empty +buffer descriptor but giving it a length.

      • +

    • by copying data +from any other type of descriptor.

      • +

    • by copying data +from another modifiable buffer descriptor of the same size.

      • +

    The following code fragment constructs a TBuf<16> object. The buffer descriptor is uninitialised, i.e. it contains +no data. The assignment operator or the Copy() function +can be used to put data into the buffer descriptor after construction:

    _LIT(KText,"Hello World!"); +... +TBuf<16> buf1; // length of buf1 is 0 +... +buf1 = KText; // data assigned

    The source descriptor +is a literal which is converted to descriptor type.

    The following +code fragment constructs a TBuf<16> object and +sets it length to 12. No data is assigned into the descriptor.

    ... +TBuf<16> buf1(12); // length of buf1 is 12 +...

    The following code fragment constructs a TBuf<16> object, initialised with the 12 characters making +up the English language phrase "Hello World!".

    _LIT(KText,"Hello World!"); +... +TBuf<16> buf1(KText);

    The following code fragment +constructs a TBuf<16> object from another TBuf<16> object. This is, in effect, copy construction.

    _LIT(KText,"Hello World!"); +... +TBuf<16> buf1(KText); +TBuf<16> buf2(buf1); // buf2 constructed from the data in buf1

    In both of these cases, the resulting length of the descriptor +is 12.

    A non-modifiable buffer descriptor can also be constructed +from 'C' style zero terminated string. However, this is rarely necessary +but may make it easier to port legacy 'C' code.

    +
    Replacing +data

    Data within a modifiable buffer descriptor can be +completely replaced through the assignment operator or by using the Copy() function.

    _LIT(KText,"Hello World!"); +_LIT(KNewText,"New text"); +_LIT(KReplaced,"Replaced"); +... +TBuf<16> buf1(KText); +TBuf<16> buf2; +... +buf2 = buf1; // buf2 now contains "Hello World!" +... +buf2 = KNewText; // buf2 now contains "New text". + // the literal is converted to a descriptor + // type. +buf2.Copy(KReplaced); // buf2 content replaced using Copy()
    +
    Accessing +and changing data

    Once a modifiable buffer descriptor has +been constructed, the functions in the base classes, TDesC and TDes, are available to be access and change +the data.

    _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); +... +buf1.Length();

    and

    _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); // length is 12 +... +buf1.Delete(6,6); // length is now 6, leaving "Hello" in + // the buffer
    +
    Illegal +access causing an exception

    The following code fragment +raises a panic because of an attempt to assign too much data. The +maximum length of the buffer descriptor is 16 but the length of the +data to be copied is 31:

    _LIT(KText,"Hello World! The sun is shining"); +... +TBufC<16> buf1(KText);

    The following code fragment +raises a panic because of an attempt to delete data outside the boundary +defined by the descriptor:

    _LIT(KText,"Hello World!"); +... +TBufC<16> buf1(KText); +buf1.Delete(99,1);
    +     + +Literal Descriptors     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E8266924-FA52-5171-BD73-423A46227A74.dita --- a/Symbian3/SDK/Source/GUID-E8266924-FA52-5171-BD73-423A46227A74.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E8266924-FA52-5171-BD73-423A46227A74.dita Tue Jul 20 12:00:49 2010 +0100 @@ -64,7 +64,7 @@ this. The diagram is also true for TPtrC8 and TPtrC16.

    Array of non-modifiable pointer descriptor elements - +

    NOTE: delete() and reset() removes the non-modifiable pointer descriptors from the array but does not delete the data or descriptors that they point to.

    @@ -75,7 +75,7 @@ is added as an array element. The following diagram illustrates this. The diagram is also true for HBufC8 and HBufC16.

    Array of pointer elements - +

    There are two implementations of the array, one using a flat buffer and the other using a segmented buffer.

    The flat buffer implementation is supplied in two variants:

      @@ -120,10 +120,10 @@ concrete classes and the base classes which support them.

      The class relationships for CDesCArrayFlat & CDesCArraySeg - +

      The class relationships for CPtrCArray - +
    Copying Descriptor Arrays

    An array of non-modifiable pointer descriptors, a CPtrCArray type, @@ -137,7 +137,7 @@ the effect of the copy operation based on the concrete type of the source array.

    Copying descriptor arrays - +
    8-Bit Variant, 16-Bit Variant and Build Independence

    Descriptor arrays are supplied diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E86347E8-8D3C-5FCB-BD9F-EA0DF8F0D9FD_d0e266235_href.png Binary file Symbian3/SDK/Source/GUID-E86347E8-8D3C-5FCB-BD9F-EA0DF8F0D9FD_d0e266235_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E86347E8-8D3C-5FCB-BD9F-EA0DF8F0D9FD_d0e271090_href.png Binary file Symbian3/SDK/Source/GUID-E86347E8-8D3C-5FCB-BD9F-EA0DF8F0D9FD_d0e271090_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E87018CD-01B4-5886-87FC-CD25EE90587D.dita --- a/Symbian3/SDK/Source/GUID-E87018CD-01B4-5886-87FC-CD25EE90587D.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E87018CD-01B4-5886-87FC-CD25EE90587D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,8 +11,8 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Central Repository Transactions

    This topic describes the concepts of Central Repository transactions.

    Overview of transactions

    In a typical use case, a repository is accessed by several different applications for different purposes such as reading, updating, caching and backing up. These applications are regarded as having a client-server relationship with the repository. When multiple applications can access a repository there is a danger of concurrent write operations corrupting the data. To prevent this, applications access repositories within sessions and perform operations on a repository within subdivisions of a session called transactions. The concept of a transaction is borrowed from database programming and is designed to ensure that only one application can modify a repository at any one time. Operations performed within a transaction are virtual, operating on a copy of the repository, until the transaction is successfully committed and the actual repository is modified. Transactions conform to a model which prevents them from being committed concurrently, so maintaining data integity.

    Only the following operations are permitted within a transaction:

    • Find()

    • Get()

    • Set()

    • Create()

    • Delete()

    • Move()

    Transactions are either synchronous or asynchronous. As the programmer you are responsible for avoiding errors such as beginning a transaction within a transaction which will cause a leave. You do this by conforming to a transaction model.

    The recommended transaction model is the optimistic non-serialised transaction model. It works on the principle that any number of clients may start a transaction at the same time, but as soon as one transaction is committed, any other transactions fail and must be started again.

    A session is in various states:

    • Not in transaction

    • Active

    • Failed

    An asynchronous transaction involves two other states:

    • Pending start

    • Pending commit

    Synchronous transactions

    A synchronous transaction has the following structure.

    • A session is initially in the state Not in transaction.

    • Call the synchronous form of StartTransaction() with the single parameter EConcurrentReadWriteTransaction.

    • The session changes state to Active.

    • Manipulate the repository with the functions Get() Set() Find() etc covered above.

    • The session continues in the Active state. The changes to the repository are cached but not actually applied during the Active state. You then either revoke or persist the changes.

    • To revoke the changes, call CancelTransaction()

    • The session returns to Not in transaction.

    • To persist the changes, call the synchronous form of CommitTransaction() with the parameter aKeyInfo of type TUint32 This function returns success or an error message and its parameter holds information about the transaction. On success, the parameter holds the number of settings which were changed. On failure, the parameter holds the settings which caused failure in the form of a key or partial key.

    • On success the session returns to Not in transaction. On failure it enters the Failed state. When a transaction fails, the operations already performed are discarded and no subsequent operations can reverse the failure.

    • If the reason for failure was the success of another transaction, the error message is KErrLocked and the session is Not in transaction. You try the same sequence of function calls until you get a successful commit.

      If there was some other reason for failure you must close the transaction yourself. To do this, either call CancelTransaction() or else call CommitTransaction() a second time.

      There is sometimes reason to fail the transaction deliberately by calling FailTransaction() For instance you might want to generate failure after an unsuccessful Get() operation and then cancel the transaction.

    Synchronous transaction state diagram -
    Asynchronous transactions

    Synchronous transactions have the disadvantage that a busy server may block the client thread before any action takes place. To avoid this problem you can use the slightly more complicated asynchronous transactions. An asynchronous transaction has the same structure as a synchronous one except that there are two new states Pending Start and Pending Commit where a transaction waits until the server is ready to communicate with it. The transition from Not in transaction to Active now proceeds like this.

    • A session is initially in the state Not in transaction.

    • Call the asynchronous form of StartTransaction() with the parameters EConcurrentReadWriteTransaction and aStatus of type TRequestStatus This function returns void: success or the reasons for failure are determined from the state of aStatus after execution.

    • The session changes state to Pending Start. Activity on the server will eventually promote the session to Active.

    • Manipulate the repository with the functions Get(), Set(), Find() etc covered above.

    • The session continues in the Active state. The changes to the repository are cached but not actually applied during the Active state. You then either revoke or persist the changes.

    • To revoke the changes, call CancelTransaction() This call has different effects depending on whether it was called in the Pending Start state or the Active state. If it was called in the Pending Start state it sets aStatus to KErrCancel

    • The session returns to Not in transaction.

    • To persist the changes, call the asynchronous form of CommitTransaction() with the parameters aKeyInfo of type TUint32 and aStatus of type TRequestStatus This function returns void. Its first parameter holds information about the transaction.

    • On success, the aStatus parameter holds the number of settings which were changed. On failure, the parameter holds the settings which caused failure in the form of a key or partial key. The aStatus parameter is set to success or failure.

    • If the reason for failure was the success of another transaction, aStatus is set to KErrLocked and the session is Not in transaction. You try the same sequence of function calls until you get a successful commit.

      If there was some other reason for failure you must close the transaction yourself. To do this, either call CancelTransaction() or else call CommitTransaction() a second time.

      There is sometimes reason to fail the transaction deliberately by calling FailTransaction() For instance you might want to generate failure after an unsuccessful Get() operation and then cancel the transaction.

    +
    Asynchronous transactions

    Synchronous transactions have the disadvantage that a busy server may block the client thread before any action takes place. To avoid this problem you can use the slightly more complicated asynchronous transactions. An asynchronous transaction has the same structure as a synchronous one except that there are two new states Pending Start and Pending Commit where a transaction waits until the server is ready to communicate with it. The transition from Not in transaction to Active now proceeds like this.

    • A session is initially in the state Not in transaction.

    • Call the asynchronous form of StartTransaction() with the parameters EConcurrentReadWriteTransaction and aStatus of type TRequestStatus This function returns void: success or the reasons for failure are determined from the state of aStatus after execution.

    • The session changes state to Pending Start. Activity on the server will eventually promote the session to Active.

    • Manipulate the repository with the functions Get(), Set(), Find() etc covered above.

    • The session continues in the Active state. The changes to the repository are cached but not actually applied during the Active state. You then either revoke or persist the changes.

    • To revoke the changes, call CancelTransaction() This call has different effects depending on whether it was called in the Pending Start state or the Active state. If it was called in the Pending Start state it sets aStatus to KErrCancel

    • The session returns to Not in transaction.

    • To persist the changes, call the asynchronous form of CommitTransaction() with the parameters aKeyInfo of type TUint32 and aStatus of type TRequestStatus This function returns void. Its first parameter holds information about the transaction.

    • On success, the aStatus parameter holds the number of settings which were changed. On failure, the parameter holds the settings which caused failure in the form of a key or partial key. The aStatus parameter is set to success or failure.

    • If the reason for failure was the success of another transaction, aStatus is set to KErrLocked and the session is Not in transaction. You try the same sequence of function calls until you get a successful commit.

      If there was some other reason for failure you must close the transaction yourself. To do this, either call CancelTransaction() or else call CommitTransaction() a second time.

      There is sometimes reason to fail the transaction deliberately by calling FailTransaction() For instance you might want to generate failure after an unsuccessful Get() operation and then cancel the transaction.

    Asynchronous Transaction State Diagram -
    Cleanup

    There is a danger that a transaction might remain open for ever if it is opened by code which subsequently leaves. To avoid this possibility, the CCentralRepository class has two functions which cause the cleanup stack to end the transaction in the event of a leave. CleanupCancelTransactionPushL(), also named CleanupRollbackTransactionPushL(), causes a leave to be followed by a call to CancelTransaction(). CleanupFailTransactionPushL() causes a leave to be followed by a call to FailTransaction().

    Central Repository Guide Optimising Repository +
    Cleanup

    There is a danger that a transaction might remain open for ever if it is opened by code which subsequently leaves. To avoid this possibility, the CCentralRepository class has two functions which cause the cleanup stack to end the transaction in the event of a leave. CleanupCancelTransactionPushL(), also named CleanupRollbackTransactionPushL(), causes a leave to be followed by a call to CancelTransaction(). CleanupFailTransactionPushL() causes a leave to be followed by a call to FailTransaction().

    Central Repository Guide Optimising Repository Access Modifications to Keyspaces     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E88E64C6-5A80-59EE-8227-455EC033E6E9.dita --- a/Symbian3/SDK/Source/GUID-E88E64C6-5A80-59EE-8227-455EC033E6E9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E88E64C6-5A80-59EE-8227-455EC033E6E9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -What are sessions with the Comms DatabaseThis topic describes the use of sessions to access the Comms Database.

    Tools and applications create and use a session to access the Comms Database. A session is an instance of the class CMDBSession. An instance of CMDBSession acts as a handle to the database. The functions provided by MMetaDatabase to access the Comms Database require an instance of CMDBSession.

    You must create a session before you get data from the Comms Database and before you update the Comms Database. To create a session, you create an instance of the CMDBSession class.

    You delete the session after you finish your use of the Comms Database. To delete a session, you delete the instance of the CMDBSession class.

    \ No newline at end of file +What are sessions with the Comms DatabaseThis topic describes the use of sessions to access the Comms Database.

    Tools and applications create and use a session to access the Comms Database. A session is an instance of the class CMDBSession. An instance of CMDBSession acts as a handle to the database. The functions provided by MMetaDatabase to access the Comms Database require an instance of CMDBSession.

    You must create a session before you get data from the Comms Database and before you update the Comms Database. To create a session, you create an instance of the CMDBSession class.

    You delete the session after you finish your use of the Comms Database. To delete a session, you delete the instance of the CMDBSession class.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E8EF06D7-FB4E-598D-9D9D-4395AB6F51C8.dita --- a/Symbian3/SDK/Source/GUID-E8EF06D7-FB4E-598D-9D9D-4395AB6F51C8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E8EF06D7-FB4E-598D-9D9D-4395AB6F51C8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> -Creating a Charconv Plug-in DLL

    This section describes how to create a Charconv plug-in DLL.

    Introduction

    The flowchart below shows the steps to create a Charconv plug-in DLL.

    Procedure

    An example is used to explain the procedure for creating a Charconv plug-in DLL. This plug-in converts between the cp850 character set and Unicode.

    1. Create a cnvtool source file using a text editor and save it as, for example d:\charconvfiles\data\cp850.txt. This file contains pairs of hexadecimal numbers. The first number in each pair is the encoding of a character in cp850and the second is the Unicode encoding of the same character.

      ... +Creating a Charconv Plug-in DLL

      This section describes how to create a Charconv plug-in DLL.

      Introduction

      The flowchart below shows the steps to create a Charconv plug-in DLL.

      Procedure

      An example is used to explain the procedure for creating a Charconv plug-in DLL. This plug-in converts between the cp850 character set and Unicode.

      1. Create a cnvtool source file using a text editor and save it as, for example d:\charconvfiles\data\cp850.txt. This file contains pairs of hexadecimal numbers. The first number in each pair is the encoding of a character in cp850and the second is the Unicode encoding of the same character.

        ... 0x00 0x0000 #NULL 0x01 0x0001 #START OF HEADING 0x02 0x0002 #START OF TEXT diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9191C31-4D09-4C95-85E4-4282ADEE1D82.dita --- a/Symbian3/SDK/Source/GUID-E9191C31-4D09-4C95-85E4-4282ADEE1D82.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E9191C31-4D09-4C95-85E4-4282ADEE1D82.dita Tue Jul 20 12:00:49 2010 +0100 @@ -33,7 +33,7 @@ with a red frame are new features.

        <parmname>CCoeControl::HandlePointerEventL()</parmname> usage - +

        To handle pointer events in your custom control:

          @@ -121,8 +121,7 @@ more information on this and other touch event options, see Enabling additional touch events for your application.

        1. Optional MTouchFeedback observer for sending a vibration when a mobile device user touches a control with the feedback interface.

          For -more information on tactile feedback, see Tactile -feedback.

          2. +more information on tactile feedback, see Tactile feedback.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E91931D8-E433-58FB-B064-70903FA4C4A5_d0e110878_href.png Binary file Symbian3/SDK/Source/GUID-E91931D8-E433-58FB-B064-70903FA4C4A5_d0e110878_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E91931D8-E433-58FB-B064-70903FA4C4A5_d0e111110_href.png Binary file Symbian3/SDK/Source/GUID-E91931D8-E433-58FB-B064-70903FA4C4A5_d0e111110_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E932B20C-5155-530F-9669-6F5BB1F1AD41.dita --- a/Symbian3/SDK/Source/GUID-E932B20C-5155-530F-9669-6F5BB1F1AD41.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,69 +0,0 @@ - - - - - -STRUCT -statement -<struct-statement> -struct-statement ::= -STRUCT <struct-name> [ BYTE | WORD ] { <struct-member-list> } -

          A STRUCT statement defines the format of a struct; all -resources are defined in terms of structs. The struct has a name designated -by struct-name, and some items designated by struct-member-list.

          -
          Struct names

          The following rules must -be observed for struct-names:

            -

          • they must be given in -upper case

            • -

          • they must begin with -an alphabetic character, although subsequent characters may be numeric

            • -

          • they may not begin with -any of the 12 struct type-names (see STRUCT -members), or the keywords: GLOBAL, STRUCT, LEN or RESOURCE. -This restriction applies only to the struct-name, not the member-name of -any individual struct members.

            So the following struct definition will -generate an error

            STRUCT BUFTHING - { - BUF buffer; - }

            whereas this struct definition will compile correctly

            STRUCT ABUFTHING - { - BUF buffer; - }
            • -
          -
          Struct member list

          The struct-member-list is -a sequence of struct-member s where each member is terminated -by a semi-colon. The complete list is enclosed within a pair of braces.

          See STRUCT members for -more details.

          -
          BYTE/WORD keywords

          STRUCT definitions -allow resource instances to be of variable length, as the struct can allow -default variables for its members. A resource’s entire length can be deduced -from the position of the next resource; this information is available in a -resource file’s index. If the resource is used as a member within an instance -of another resource, however, its length must be identified another -way.

            -

          • Use BYTE to -prefix the struct with a single byte indicating its length (zero to 255 characters).

            • -

          • Use WORD to -prefix the struct with a word indicating its length (zero to 65,535 characters).

            • -
          -

          The following are valid STRUCT statements:

          STRUCT STRING - { - LTEXT str; - }

          This defines a struct called STRING which -contains a single LTEXT item.

          STRUCT TEST BYTE - { - WORD status; - STRUCT text; - }

          This defines a struct called TEST which -contains a WORD and an embedded struct. The total length -of TEST is unknown, but should not exceed 255 characters: -the BYTE directive in the definition indicates that, when -this struct is embedded within another, it should be preceded with a byte -indicating its length (zero to 255 characters).

           -           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E93EE459-8CF4-42A1-B06C-E78E56FD25A0.dita --- a/Symbian3/SDK/Source/GUID-E93EE459-8CF4-42A1-B06C-E78E56FD25A0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E93EE459-8CF4-42A1-B06C-E78E56FD25A0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -17,8 +17,8 @@

          The client applications can use the property listener to monitor the property changes made by other clients.

           - -Create a property + +Create a property listener implementation for the MSensrvPropertyListener interface. class PropertyListener:public MSensrvPropertyListener { diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9C620EF-4C77-56C3-8023-A6F13989246A_d0e413261_href.png Binary file Symbian3/SDK/Source/GUID-E9C620EF-4C77-56C3-8023-A6F13989246A_d0e413261_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9C620EF-4C77-56C3-8023-A6F13989246A_d0e417061_href.png Binary file Symbian3/SDK/Source/GUID-E9C620EF-4C77-56C3-8023-A6F13989246A_d0e417061_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9E21C82-13F6-50D4-A271-F9E5F1BD982F.dita --- a/Symbian3/SDK/Source/GUID-E9E21C82-13F6-50D4-A271-F9E5F1BD982F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E9E21C82-13F6-50D4-A271-F9E5F1BD982F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,7 +12,7 @@ Background Processing for EcamThis topic describes how to capture an image using standalone background processing in Ecam. -

          Before you start +

          Before you start you should understand the Onboard Camera Overview topic.

          The Ecam API has diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9F08BCA-39F6-55D3-8974-BD0FFB90DE11_d0e283704_href.png Binary file Symbian3/SDK/Source/GUID-E9F08BCA-39F6-55D3-8974-BD0FFB90DE11_d0e283704_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9F08BCA-39F6-55D3-8974-BD0FFB90DE11_d0e288543_href.png Binary file Symbian3/SDK/Source/GUID-E9F08BCA-39F6-55D3-8974-BD0FFB90DE11_d0e288543_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-E9F203A6-D9E3-41B7-9FC4-24EDE20C4753.dita --- a/Symbian3/SDK/Source/GUID-E9F203A6-D9E3-41B7-9FC4-24EDE20C4753.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-E9F203A6-D9E3-41B7-9FC4-24EDE20C4753.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ user has tried to do something that may cause a considerable problem.

          Error note - +
          Guidelines for using error notes

          Use an error note when the user does diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA107811-240C-5F95-922B-7C042FA00A87.dita --- a/Symbian3/SDK/Source/GUID-EA107811-240C-5F95-922B-7C042FA00A87.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EA107811-240C-5F95-922B-7C042FA00A87.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,15 +9,13 @@ --> -Reading -a String Resource

          The simplest use of a resource file involves reading string resources -and interpreting the source data.

          -

          Resources are defined in terms of structs which are accessed and -read by the RResourceFile class, and interpreted by the TResourceReader. -An application may also use resources from multiple files simultaneously. -See Resource File examples for -more information.

          Consider a sample resource file where a struct of -STRING is defined having a single member of type LTEXT:

          // define structures +Reading a String Resource

          The simplest use of a resource file involves reading +string resources and interpreting the source data.

          +

          Resources are defined in terms of structs which are accessed +and read by the RResourceFile class, and interpreted +by the TResourceReader. An application may also +use resources from multiple files simultaneously. See Resource File examples for more information.

          Consider a sample resource file where +a struct of STRING is defined having a single member of type LTEXT:

          // define structures STRUCT STRING { LTEXT text; @@ -30,52 +28,48 @@           -Compile the resource file using the -resource compiler (rcomp) to generate an .rsc file -and an .rsg file. +Compile the resource file using the resource compiler (rcomp) +to generate an .rsc file and an .rsg file. +

          For information on resource compiler, see Symbian^3 Tools +Guide > Building.

          - .rsc file contains the resource data; this is -the resource file that must be referred to at run-time by the RResourceFile class -in the C++ code. + .rsc file contains the resource data; +this is the resource file that must be referred to at run-time by +the RResourceFile class in the C++ code. - .rsg file is a generated - header file that contains #define statements -for each resource defined in the source file. In the resource file generated -here, the only resource is called hello and the generated -header file contains: + .rsg file is a generated + header file that contains #define statements for each resource defined in the source file. In the +resource file generated here, the only resource is called hello and the generated header file contains: #define HELLO 1 -Note that the name in the generated header file is converted to upper -case. +Note that the name in the generated header file is converted +to upper case.           - #include the .rsg file in the -file containing the C++ code, to access the resource IDs generated by the -resource compiler. For example, for a project refered as ReadText, -this might be: + #include the .rsg file +in the file containing the C++ code, to access the resource IDs generated +by the resource compiler. For example, for a project refered as ReadText, this might be: #include ReadText.rsg -Initialize the RResourceFile object in the C++ program, -specifying the name of the resource file: +Initialize the RResourceFile object in the +C++ program, specifying the name of the resource file: RResourceFile resourceFile; resourceFile.OpenL( fsSession,_L( Z:\\system\\data\\ReadText.rsc ) ); -Note: To access the resource file contents, a session with the file -server must be started using an instance of RFs class. +Note: To access the resource file contents, a session with the +file server must be started using an instance of RFs class. -Use one of the three functions (RResourceFile::AllocReadLC(), RResourceFile::AllocReadL() or RResourceFile::ReadL() to read a resource as shown in the following -code fragment: +Use one of the three functions (RResourceFile::AllocReadLC(), RResourceFile::AllocReadL() or RResourceFile::ReadL() to read a resource as shown in the following code fragment: HBufC8* dataBuffer = resourceFile.AllocReadLC( HELLO ); -Interpret the resource data using a TResourceReader object. -This provides access to the text string through a pointer descriptor as shown -in the following code fragment: +Interpret the resource data using a TResourceReader object. This provides access to the text string through a pointer +descriptor as shown in the following code fragment: TResourceReader theReader; ... @@ -83,11 +77,10 @@ TPtrC textdata = reader.ReadTPtrC();           -

          In this example, once the resource data is no longer needed, the -heap descriptor, dataBuffer, can be removed from the cleanup stack and destroyed -as shown in the code fragment:

          CleanupStack::PopAndDestroy();

          When -all operations on the resource file are complete, the resource file can be -closed using the RResourceFile::close() function as:

          resourceFile.Close();           +

          In this example, once the resource data is no longer needed, +the heap descriptor, dataBuffer, can be removed from the cleanup stack +and destroyed as shown in the code fragment:

          CleanupStack::PopAndDestroy();

          When all operations on the resource file are complete, the resource +file can be closed using the RResourceFile::close() function as:

          resourceFile.Close();           Example

          Consider a resource constructed from the following definition.

          RESOURCE ARRAY anarray { @@ -99,9 +92,9 @@ LBUF { txt="Del"; }, LBUF { txt="Space"; } }; -}

          A TPtrC representing the second item can -be constructed using the ReadTPtrC() function. The example -simply takes the length of the text Enter:

          // open the resource file +}

          A TPtrC representing the second +item can be constructed using the ReadTPtrC() function. +The example simply takes the length of the text Enter:

          // open the resource file ... HBufC8* res = resourceFile.AllocReadLC( ANARRAY ); TResourceReader theReader; @@ -112,8 +105,4 @@           Resource files -Resource -file format -Resource -compilation           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA20E614-C911-4EE9-92B5-C8F9B657D59E.dita --- a/Symbian3/SDK/Source/GUID-EA20E614-C911-4EE9-92B5-C8F9B657D59E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EA20E614-C911-4EE9-92B5-C8F9B657D59E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,37 +9,31 @@ --> -Platform -security architecture -

          The purpose of the Symbian platform security architecture is to enable -users to use their mobile devices in an easy and trusted manner.

          -

          This section introduces some central platform security concepts. These -include the following:

          +Platform security architecture +

          The purpose of the Symbian platform security architecture is +to enable users to use their mobile devices in an easy and trusted +manner.

          +

          This section introduces some central platform security concepts. +These include the following:

            -

          • Capabilities

            -
            • -

          • Application -signing

            • -

          • Data -caging

            • +

          • Capabilities

            • +

          • Application signing

            • +

          • Data caging

          -

          For more details on the above concepts, see the Symbian -Signed website.

          -
          Additional information -on security +

          For more details on the above concepts, see the Symbian Signed website.

          +
          Additional +information on security
            -

          • For more information on how to test and certify your applications -and how to access capabilities, -see The -Complete Guide to Symbian Signed.

            • -

          • For more information about security in Symbian C++ application -development, see the Security -Articles in the Forum Nokia Developer Community Wiki.

            • -

          • For more advanced information and practical examples on how -to use various security options provided by the platform, see the following -Forum Nokia resources:All these examples -are listed as compatible with the 3rd Edition on Forum Nokia, and therefore -it is unclear whether they apply to 5th Edition.

            +

          • For more information on how to test and certify your +applications and how to access capabilities, see The Complete Guide to Symbian Signed.

            • +

          • For more information about security in Symbian C++ +application development, see the Security Articles in the Forum Nokia Developer Community +Wiki.

            • +

          • For more advanced information and practical examples +on how to use various security options provided by the platform, see +the following Forum Nokia resources:All these examples are listed as compatible +with the 3rd Edition on Forum Nokia, and therefore it is unclear whether +they apply to 5th Edition.

            • System Information Example

            • ECom Plug-in Architecture and ECom Plug-In Examples

              • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA2AAE86-0BD3-52C9-BD13-75E9F04DE77F_d0e229007_href.png Binary file Symbian3/SDK/Source/GUID-EA2AAE86-0BD3-52C9-BD13-75E9F04DE77F_d0e229007_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA2AAE86-0BD3-52C9-BD13-75E9F04DE77F_d0e233992_href.png Binary file Symbian3/SDK/Source/GUID-EA2AAE86-0BD3-52C9-BD13-75E9F04DE77F_d0e233992_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA3419BD-D757-5AC3-AE6F-DF21F794AE47.dita --- a/Symbian3/SDK/Source/GUID-EA3419BD-D757-5AC3-AE6F-DF21F794AE47.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EA3419BD-D757-5AC3-AE6F-DF21F794AE47.dita Tue Jul 20 12:00:49 2010 +0100 @@ -51,19 +51,19 @@
            Buffer descriptor - + Heap descriptor - + Pointer descriptor - + Resizable buffer descriptor - +

            Although the four types seem to be different, the underlying class structure makes such differences transparent allowing them to be treated in the same diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e371060_href.png Binary file Symbian3/SDK/Source/GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e371060_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e390209_href.png Binary file Symbian3/SDK/Source/GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e390209_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EA8038F6-8727-5ABE-805C-9FF095293EB7.dita --- a/Symbian3/SDK/Source/GUID-EA8038F6-8727-5ABE-805C-9FF095293EB7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EA8038F6-8727-5ABE-805C-9FF095293EB7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -29,7 +29,7 @@ standards define terminology specific to individual profiles. Please refer to the latest Bluetooth standard at www.bluetooth.com for all official definitions.

          Architecture - +
          Description

          There are two kinds of profiles provided for by Symbian platform: implemented and @@ -40,7 +40,7 @@

          Figure 1 above shows the dependencies of profiles. The shaded profiles, discussed in the next section, are implemented by the Symbian platform Bluetooth subsystem.

          - +

          Implemented Bluetooth profiles

          The following profiles are implemented by Symbian platform Bluetooth:

            diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EADC4EA6-4492-5A00-A29E-6F7747FCAAC9_d0e184763_href.png Binary file Symbian3/SDK/Source/GUID-EADC4EA6-4492-5A00-A29E-6F7747FCAAC9_d0e184763_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EADC4EA6-4492-5A00-A29E-6F7747FCAAC9_d0e189760_href.png Binary file Symbian3/SDK/Source/GUID-EADC4EA6-4492-5A00-A29E-6F7747FCAAC9_d0e189760_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EAFD71DD-0EB2-402A-9511-D0F3362BDCE3_d0e67688_href.png Binary file Symbian3/SDK/Source/GUID-EAFD71DD-0EB2-402A-9511-D0F3362BDCE3_d0e67688_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EAFD71DD-0EB2-402A-9511-D0F3362BDCE3_d0e67752_href.png Binary file Symbian3/SDK/Source/GUID-EAFD71DD-0EB2-402A-9511-D0F3362BDCE3_d0e67752_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EB212C35-5416-4CA7-8091-61B45D78E220.dita --- a/Symbian3/SDK/Source/GUID-EB212C35-5416-4CA7-8091-61B45D78E220.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EB212C35-5416-4CA7-8091-61B45D78E220.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ buttons that have touch functionality. Toolbar - +

            A tooltip is an information pop-up containing information regarding each button must be shown.

            @@ -107,7 +107,7 @@ session.

            Toolbar button states: example of ON/OFF type of button - +
            Floating toolbar

            Floating toolbar is a component for showing the key functions on top of the Main pane @@ -167,7 +167,7 @@ it is always visible. Toolbar can be hidden in case other controls are also hidden (in full screen views).

            Toolbar in touch UI fixed in the layout - +
            Toolbar extension in touch UI

            As in non-touch UI, toolbars can have extensions also diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EB58901D-66BD-56BF-B0CD-5FC4F73F06F3.dita --- a/Symbian3/SDK/Source/GUID-EB58901D-66BD-56BF-B0CD-5FC4F73F06F3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EB58901D-66BD-56BF-B0CD-5FC4F73F06F3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> DevVideo Library Overview

            This document provides an overview of the DevVideo library.

            Purpose

            DevVideo provides the interface between the Symbian platform and the video processing hardware for all video functionality.

            DevVideo Library Details

            The DLL that provides the functionality and the library to which your code must link is identified below.

            DLL LIB Short Description

            devvideo.dll

            devvideo.lib

            These files are used for implementing DevVideo.

            Architectural Relationship

            DevVideo provides middleware components, such as MMF controller plug-ins, access to video codecs, pre-processors and post-processors. DevVideo interacts with:

            • MMF Controller Framework

              The controller framework helps to manage the interface to DevVideo and provides controller plug-ins for playing and recording video data.

            • Controller plug-ins

              Video play and video record controller plug-ins implement play and record functionality respectively.

            • Video Hardware Device interface

              CMMFVideoHwDevice is the base class for all video hardware devices. Video playback hardware devices are video decoders and video post-processors. Video recording hardware devices are video pre-processors and encoders.

              Note that, although the interface is called "Hardware Device" interface, it is possible that the codecs, and pre-processors and post-processors, are not running on a separate hardware device. They could be running on the same processor as all the other software.

            Shown below is a representation of how DevVideo interacts with the Multimedia Framework and Media Device Framework components:

            DevVideo and related components -
            Description

            DevVideo is a hardware abstraction layer that provides access to video functionality. DevVideo functionality includes video decoding, encoding, pre-processing and post-processing.

            Key DevVideo Classes

            The video play and record functionality provided by DevVideo is contained within the following key classes:

            • MMMFDevVideoPlayProxy - the interface to CMMFDevVideoPlay. Hardware devices use this interface to deliver data back to the client.

            • CMMFDevVideoPlay - DevVideoPlay interface and implementation.

            • MMMFDevVideoPlayObserver - set of callback functions that any client using CMMFDevVideoPlay must implement.

            • MMMFDevVideoRecordProxy - the interface to CMMFDevVideoRecord. Hardware devices use this interface to deliver data back to the client.

            • CMMFDevVideoRecord - DevVideoRecord interface and implementation.

            • MMMFDevVideoRecordObserver - set of callback functions that any client using CMMFDevVideoRecord must implement.

            Using DevVideo

            Clients can use DevVideo to:

            • Select the video decoder to use.

            • Configure the video decoder.

            • Select the video post-processor to use.

            • Configure the video post-processor.

            • Set clock source for timing video playback.

            • Set video output destination.

            • Start video playback.

            • Pause video playback.

            • Stop video playback.

            • Select the video encoder to use.

            • Configure the video encoder.

            • Select the video pre-processor to use.

            • Configure the video pre-processor.

            • Set clock source for timing of video recording.

            • Start video recording.

            • Pause video recording.

            • Stop video recording.

            • Pass video buffers to and from the client.

            • Pass pictures to and from the client.

            See Also

            Video Client Overview

            \ No newline at end of file +
            Description

            DevVideo is a hardware abstraction layer that provides access to video functionality. DevVideo functionality includes video decoding, encoding, pre-processing and post-processing.

            Key DevVideo Classes

            The video play and record functionality provided by DevVideo is contained within the following key classes:

            • MMMFDevVideoPlayProxy - the interface to CMMFDevVideoPlay. Hardware devices use this interface to deliver data back to the client.

            • CMMFDevVideoPlay - DevVideoPlay interface and implementation.

            • MMMFDevVideoPlayObserver - set of callback functions that any client using CMMFDevVideoPlay must implement.

            • MMMFDevVideoRecordProxy - the interface to CMMFDevVideoRecord. Hardware devices use this interface to deliver data back to the client.

            • CMMFDevVideoRecord - DevVideoRecord interface and implementation.

            • MMMFDevVideoRecordObserver - set of callback functions that any client using CMMFDevVideoRecord must implement.

            Using DevVideo

            Clients can use DevVideo to:

            • Select the video decoder to use.

            • Configure the video decoder.

            • Select the video post-processor to use.

            • Configure the video post-processor.

            • Set clock source for timing video playback.

            • Set video output destination.

            • Start video playback.

            • Pause video playback.

            • Stop video playback.

            • Select the video encoder to use.

            • Configure the video encoder.

            • Select the video pre-processor to use.

            • Configure the video pre-processor.

            • Set clock source for timing of video recording.

            • Start video recording.

            • Pause video recording.

            • Stop video recording.

            • Pass video buffers to and from the client.

            • Pass pictures to and from the client.

            See Also

            Video Client Overview

            \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EBD1242B-6BD9-5ABB-B471-24ABC78A918C.dita --- a/Symbian3/SDK/Source/GUID-EBD1242B-6BD9-5ABB-B471-24ABC78A918C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EBD1242B-6BD9-5ABB-B471-24ABC78A918C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,4 +11,4 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> MIME Recognition Framework Overview

            The MIME (Multipurpose Internet Mail Extension) recognition framework enables data type identification.

            The MIME recognition framework implements data type recognition using MIME (data) recognizers. The MIME recognizers are ECOM plug-ins. A MIME recognizer reads a small piece of the data. A data type can be recognized by more than one MIME recognizer. The framework uses the concepts of priority and confidence level to determine the data type.

            The Application Architecture (AppArc) launches the appropriate application using the MIME framework to handle the data.

            It is not guaranteed that an application will be available to handle a data type, even if it was successfully recognized.

            Purpose

            MIME type recognition enables devices to identify data type in streams or files and start appropriate application automatically.

            Key concepts and terms
            MIME

            MIME (Multipurpose Internet Mail Extension) is an internet standard system for identifying the type of data in a file or stream. Types can include graphics, photos, audio, video files and formatted text.

            Priority

            The plug-in developer assigns a priority (EHigh, ENormal or ELow) to the data recognizers. A data type can be handled by more than one application and may therefore be recognized by more than one recognizer.

            The priority determines the position at which the recognizer is inserted into the recognizer list. The higher priority recognizers are placed at the start of the list. If more than one recognizer recognizes a data type with the same confidence, the recognizer with the higher priority takes precedence. The sequence in which recognizers are invoked by the framework is determined by their priority. High priority recognizers are invoked first.

            For more details refer to CApaDataRecognizerType::TRecognizerPriority.

            Recognizer list

            The MIME recognition framework maintains a list of MIME recognizers. The recognizer list is constructed based on the data types the MIME recognizers claim to support and is ordered by priority.

            Confidence level

            A MIME recognizer reads a small piece of data from the start of a file or stream. It attempts to match the data with one of its known types. If the match is complete it returns the associated data type with full confidence (ECertain) and if there is no match it returns no data type with no confidence (ENotRecognized). If there is a partial match it can return a data type with an intermediate confidence level (EPossible, EUnlikely, ENotRecognized).

            The confidence of MIME recognizers can be expressed in 5 different levels:

            • ECertain

            • EProbable

            • EPossible

            • EUnlikely

            • ENotRecognized

            By default, the confidence level of the MIME Recognizer is ECertain.

            For more details refer CApaDataRecognizerType::TRecognitionConfidence.

            Architecture

            MIME recognizers are ECOM plugins, located under \sys\bin\.

            MIME framework architecture -

            • AppArc is the main client of the MIME recognition framework.

            • Applications that need data type recognition use the MIME recognition framework via AppArc APIs.

            • The MIME recognition framework delegates the data type identification task to an appropriate MIME recognizer.

            • The MIME recognizer identifies the data type.

            • AppArc launches the application for the identified data type.

            APIs API Description

            CApaDataRecognizerType

            Is the abstract base class for a recognizer. Recognizers need to define and implement a derived class and provide an implementation of the functions.This class contains the MIME APIs related to MIME recognition framework.

            RApaLsSession

            A session with the application architecture server. The server provides access to a cached list of the applications on the device. This class contains the AppArc APIs related to MIME recognition framework.

            Typical uses

            The MIME recognition framework allows the plug-in writers to:

            • Write Data(MIME) Recogzisers

            \ No newline at end of file +

            • AppArc is the main client of the MIME recognition framework.

            • Applications that need data type recognition use the MIME recognition framework via AppArc APIs.

            • The MIME recognition framework delegates the data type identification task to an appropriate MIME recognizer.

            • The MIME recognizer identifies the data type.

            • AppArc launches the application for the identified data type.

          APIs API Description

          CApaDataRecognizerType

          Is the abstract base class for a recognizer. Recognizers need to define and implement a derived class and provide an implementation of the functions.This class contains the MIME APIs related to MIME recognition framework.

          RApaLsSession

          A session with the application architecture server. The server provides access to a cached list of the applications on the device. This class contains the AppArc APIs related to MIME recognition framework.

          Typical uses

          The MIME recognition framework allows the plug-in writers to:

          • Write Data(MIME) Recogzisers

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC49B54F-7724-433B-BD7F-201DE3B7DAA6.dita --- a/Symbian3/SDK/Source/GUID-EC49B54F-7724-433B-BD7F-201DE3B7DAA6.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EC49B54F-7724-433B-BD7F-201DE3B7DAA6.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,126 +1,118 @@ - - - - - -Resource -file structure -

          Resource files -may consist of comments, C++ pre-processor statements, and structure statements -indicated by predefined keywords.

          -

          For more information on the format of resource files, see Resource file source format.

          -

          For a commented example of a resource file, see Resource -management example: HelloWorldBasic.

          -

          A resource file has the following structure:

          -
          Comments -

          You can use either C (/* */) or C++ (//) -style comments.

          -

          For more information on the lexical conventions of resource files, see - Lexical conventions.

          -
          -
          NAME statements -

          The first non-comment statement in a resource must be the NAME statement. -The syntax is as follows:

          -NAME name -

          where name is a 4 letter ID that is unique in the -application. This ID is used to differentiate and access resource files when -an application uses multiple resource files.

          -

          For more information on the NAME statement, see NAME statement.

          -
          -
          C++ pre-processor -statements -

          The resource compiler supports a set of pre-processor statements, including:

          -
            -

          • #define

            • -

          • #include

            • -

          • #ifdef

            • -

          • #ifndef

            • -

          • #if

            • -

          • #else

            • -

          • #endif

            • -
          -

          For more information on the supported pre-processor statements, see - C++ pre-processor statements.

          -

          Typically, resource files contain #includes statements -for the following files:

          -
            -

          • appinfo.rh

            • -

          • avkon.rh

            • -

          • avkon.rsg

            • -

          • eikon.rh

            • -
          -

          These files are located under the /Epoc32/include folder. -They contain the structure declarations for commonly used data structures -in the Symbian platform.

          - -
          -
          RESOURCE statements -syntax -

          The RESOURCE keyword is used to declare a resource in a resource file. -The syntax is as follows:

          -RESOURCE <STRUCT_NAME> | <resource_name> | -{ -<resource-initialiser-list> -} -

          where:

          -
            -

          • <STRUCT_NAME> is the name of a declared -data structure in an included resource header file.

            <STRUCT_NAME> must -be in upper case.

            • -

          • resource_name identifies the resource -.

            resource_name must be in lower case.

            -
            • -

          • resource-initialiser-list contains the -values the members of the structure should be initialized with when the default -values should not be used.

            • -
          -

          RESOURCE statements may include resources defined -within other resource statements in the resource file. For example:

          -RESOURCE EIK_APP_INFO - { - menubar = r_name; - } -

          uses a resource declared in a later statement to define its menu bar. -For more information, seeEIK_APP_INFO.

          -

          Resource statements may also included nested resource structures. For -example:

          -RESOURCE MENU_PANE r_name2 - { - items = - { - MENU_TITLE - { - menu_pane = r_name3; - } - }; - } -

          For more information on the MENU_PANE resource -see , Menu bar resource -statements.

          -

          For more information on structures, see:

          -
            -

          • STRUCT -statement

            • -

          • STRUCT member types

            • -

          • Arrays -within structs

            • -
          -

          For more on resource statements, see:

          -
            -

          • Required -resource file statements

            -
            • -

          • Optional -resource file statements

            -
            • -

          • RESOURCE -statement.

            • -
          -
          + + + + + +Resource file structure +

          Resource files may consist of comments, C++ pre-processor statements, and +structure statements indicated by predefined keywords.

          +

          For more information on the format of resource files, see Resource file source format.

          +

          For a commented example of a resource file, see Resource +management example: HelloWorldBasic.

          +

          A resource file has the following structure:

          +
          Comments +

          You can use either C (/* */) or C++ (//) style comments.

          +

          For more information on the lexical conventions of resource +files, see Lexical conventions.

          +
          +
          NAME +statements +

          The first non-comment statement in a resource must be the NAME statement. The syntax is as follows:

          +NAME name +

          where name is a 4 letter ID that is unique +in the application. This ID is used to differentiate and access resource +files when an application uses multiple resource files.

          +

          For more information on the NAME statement, +see NAME statement.

          +
          +
          C++ pre-processor +statements +

          The resource compiler supports a set of pre-processor statements, +including:

          +
            +

          • #define

            • +

          • #include

            • +

          • #ifdef

            • +

          • #ifndef

            • +

          • #if

            • +

          • #else

            • +

          • #endif

            • +
          +

          For more information on the supported pre-processor statements, +see C++ pre-processor statements.

          +

          Typically, resource files contain #includes statements for the following files:

          +
            +

          • appinfo.rh

            • +

          • avkon.rh

            • +

          • avkon.rsg

            • +

          • eikon.rh

            • +
          +

          These files are located under the /Epoc32/include folder. They contain the structure declarations for commonly used +data structures in the Symbian platform.

          + +
          +
          RESOURCE +statements syntax +

          The RESOURCE keyword is used to declare a resource in a resource +file. The syntax is as follows:

          +RESOURCE <STRUCT_NAME> | <resource_name> | +{ +<resource-initialiser-list> +} +

          where:

          +
            +

          • <STRUCT_NAME> is the name +of a declared data structure in an included resource header file.

            +

            <STRUCT_NAME> must be in upper case.

            +
            • +

          • resource_name identifies the +resource .

            resource_name must be +in lower case.

            • +

          • resource-initialiser-list contains +the values the members of the structure should be initialized with +when the default values should not be used.

            • +
          +

          RESOURCE statements may include resources +defined within other resource statements in the resource file. For +example:

          +RESOURCE EIK_APP_INFO + { + menubar = r_name; + } +

          uses a resource declared in a later statement to define its +menu bar. For more information, seeEIK_APP_INFO.

          +

          Resource statements may also included nested resource structures. +For example:

          +RESOURCE MENU_PANE r_name2 + { + items = + { + MENU_TITLE + { + menu_pane = r_name3; + } + }; + } +

          For more information on the MENU_PANE resource +see , Menu +bar resource statements.

          +

          For more information on structures, see:

          +
            +

          • STRUCT statement

            • +

          • STRUCT member types

            • +

          • Arrays within structs

            • +
          +

          For more on resource statements, see:

          +
            +

          • Required resource file statements

            • +

          • Optional resource file statements

            • +

          • RESOURCE statement.

            • +
          +
           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e51873_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e51873_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e52016_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e52016_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e58382_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e58382_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e58525_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e58525_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e69109_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e69109_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e69133_href.png Binary file Symbian3/SDK/Source/GUID-EC7E0C0E-EEB0-45B5-BE4A-11CAF78EC366_d0e69133_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC824DA2-CA19-567C-8218-7C6E1C5ED461_d0e280024_href.png Binary file Symbian3/SDK/Source/GUID-EC824DA2-CA19-567C-8218-7C6E1C5ED461_d0e280024_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC824DA2-CA19-567C-8218-7C6E1C5ED461_d0e284863_href.png Binary file Symbian3/SDK/Source/GUID-EC824DA2-CA19-567C-8218-7C6E1C5ED461_d0e284863_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EC98E7E0-872D-467D-BDC8-6471F6165705.dita --- a/Symbian3/SDK/Source/GUID-EC98E7E0-872D-467D-BDC8-6471F6165705.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EC98E7E0-872D-467D-BDC8-6471F6165705.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ the indicator.

          Universal indicator pop-up - +

          Default touch diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ECACB935-AD19-5BE6-AC27-A63465244087_d0e177456_href.png Binary file Symbian3/SDK/Source/GUID-ECACB935-AD19-5BE6-AC27-A63465244087_d0e177456_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ECACB935-AD19-5BE6-AC27-A63465244087_d0e182481_href.png Binary file Symbian3/SDK/Source/GUID-ECACB935-AD19-5BE6-AC27-A63465244087_d0e182481_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ECBA6331-2187-52C9-A5DF-20CD1EEFE781.dita --- a/Symbian3/SDK/Source/GUID-ECBA6331-2187-52C9-A5DF-20CD1EEFE781.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ECBA6331-2187-52C9-A5DF-20CD1EEFE781.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,7 +9,7 @@ --> <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> -<concept xml:lang="en" id="GUID-ECBA6331-2187-52C9-A5DF-20CD1EEFE781"><title>Audio Output Streaming Tutorial

          This tutorial describes how to use Audio Output Streaming.

          Purpose

          The purpose of this tutorial is to show you how to open, play and then close an audio output stream.

          Required Background

          The user needs to maintain the data packets in a queue before starting to send it to the server. There is no need for the entire sound clip to arrive to be able to pass on to the low level audio controller. They can be forwarded as they arrive. If the server tends to receive data more than it can read or process, then a separate queue is maintained in the client side whose elements are references to the buffers passed to it. Once the server is free to receive more data the client sends the data in the queue and receives a notification from the server by means of a callback. As a result of this, the client deletes the data fragments from the queue.

          Upon receiving the data packets the audio controller maintains them in the received buffers. A read function is instantiated to read the data into the destination descriptors.

          Introduction

          The Audio streaming API is the interface providing the functionalities for playing, stopping, and recording the audio stream to and from the audio buffers. The audio output stream interface class, CMdaAudioOutputStream, enables client applications to:

          • Stream raw audio data from specified buffers to audio devices.

          • Specify the priority of the audio stream relative to other clients trying to use the same hardware.

          • Set the sample rate and the number of audio channels before playback.

          • Adjust the volume and channel balance during playback.

          Using Audio Output Streaming

          Typically, using an audio output stream involves the following steps as shown in the sequence diagram below:

          The following tasks will be covered in this tutorial:

          • Constructing an audio output stream

          • Opening an audio output stream

          • Getting and setting the stream properties

          • Playing an audio output stream

          • Stopping an audio output stream

          Basic Procedure for Constructing an Audio Output Stream

          The high level step to construct an audio output stream is shown here:

          • The client application creates an audio output stream object using the static function CMdaAudioOutputStream::NewL(). Optionally, it also sets the audio priorities to be able to access the audio hardware in relation to the other clients trying to access the same device.

            static IMPORT_C CMdaAudioOutputStream *NewL(MMdaAudioOutputStreamCallback &aCallBack, +Audio Output Streaming Tutorial

            This tutorial describes how to use Audio Output Streaming.

            Purpose

            The purpose of this tutorial is to show you how to open, play and then close an audio output stream.

            Required Background

            The user needs to maintain the data packets in a queue before starting to send it to the server. There is no need for the entire sound clip to arrive to be able to pass on to the low level audio controller. They can be forwarded as they arrive. If the server tends to receive data more than it can read or process, then a separate queue is maintained in the client side whose elements are references to the buffers passed to it. Once the server is free to receive more data the client sends the data in the queue and receives a notification from the server by means of a callback. As a result of this, the client deletes the data fragments from the queue.

            Upon receiving the data packets the audio controller maintains them in the received buffers. A read function is instantiated to read the data into the destination descriptors.

            Introduction

            The Audio streaming API is the interface providing the functionalities for playing, stopping, and recording the audio stream to and from the audio buffers. The audio output stream interface class, CMdaAudioOutputStream, enables client applications to:

            • Stream raw audio data from specified buffers to audio devices.

            • Specify the priority of the audio stream relative to other clients trying to use the same hardware.

            • Set the sample rate and the number of audio channels before playback.

            • Adjust the volume and channel balance during playback.

            Using Audio Output Streaming

            Typically, using an audio output stream involves the following steps as shown in the sequence diagram below:

            The following tasks will be covered in this tutorial:

            • Constructing an audio output stream

            • Opening an audio output stream

            • Getting and setting the stream properties

            • Playing an audio output stream

            • Stopping an audio output stream

            Basic Procedure for Constructing an Audio Output Stream

            The high level step to construct an audio output stream is shown here:

            • The client application creates an audio output stream object using the static function CMdaAudioOutputStream::NewL(). Optionally, it also sets the audio priorities to be able to access the audio hardware in relation to the other clients trying to access the same device.

              static IMPORT_C CMdaAudioOutputStream *NewL(MMdaAudioOutputStreamCallback &aCallBack, TInt aPriority, TMdaPriorityPreference aPref=EMdaPriorityPreferenceTimeAndQuality);

            Basic Procedure for Opening an Audio Output Stream

            The high level steps to open an audio output stream are shown here:

            1. To open the output stream, use the Open() member function. For example:

              virtual void Open(TMdaPackage* aSettings);

            2. Once the stream is open MMdaAudioOutputStreamCallback::MaoscOpenComplete() is invoked to indicate that the stream is ready to use.

              void CIOStreamAudio::MaoscOpenComplete(TInt aError) { ASSERT(iState==EStateOpeningOutput); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ED784025-4E65-4BE9-ADA8-A13427B6EA30.dita --- a/Symbian3/SDK/Source/GUID-ED784025-4E65-4BE9-ADA8-A13427B6EA30.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-ED784025-4E65-4BE9-ADA8-A13427B6EA30.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@

              Marked items are indicated graphically.

              Markable list. Marked items are indicated graphically in the list. - +

              The Mark and Unmark functions are available in the Options menu of the markable list. Alternatively, or as a shortcut, the user can keep diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ED823C5E-A59B-476A-BF88-0FCBA5D35FED_d0e72175_href.png Binary file Symbian3/SDK/Source/GUID-ED823C5E-A59B-476A-BF88-0FCBA5D35FED_d0e72175_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-ED823C5E-A59B-476A-BF88-0FCBA5D35FED_d0e72202_href.png Binary file Symbian3/SDK/Source/GUID-ED823C5E-A59B-476A-BF88-0FCBA5D35FED_d0e72202_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e51678_href.png Binary file Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e51678_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e51821_href.png Binary file Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e51821_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e67259_href.png Binary file Symbian3/SDK/Source/GUID-EDBCCC26-BA4D-4318-9F0D-62272FA97BBF_d0e67259_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDC16636-B24E-598B-9084-EAE782A4A213.dita --- a/Symbian3/SDK/Source/GUID-EDC16636-B24E-598B-9084-EAE782A4A213.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EDC16636-B24E-598B-9084-EAE782A4A213.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ network and creates a bearer to access the Wi-Fi network. The device then moves all the existing connections across to the Wi-Fi bearer. In the final step the device disconnects from the GPRS network.

              - +

              Bearer Mobility operates in response to changes in the environment of the device. A bearer is known as available when the device is in range diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e190360_href.png Binary file Symbian3/SDK/Source/GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e190360_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e195331_href.png Binary file Symbian3/SDK/Source/GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e195331_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDCBBB5E-FAAD-50A5-9EE4-B4F399B77CE9.dita --- a/Symbian3/SDK/Source/GUID-EDCBBB5E-FAAD-50A5-9EE4-B4F399B77CE9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,53 +0,0 @@ - - - - - -bld.inf -file syntax overview -

              Component definition files, which are always called bld.inf, -are used by bldmake to define the abld.bat and -makefiles to be created.

              -

              bld.inf files are made up of a number of sections, -with headers prj_platforms, prj_exports, prj_testexports, -and prj_mmpfiles.

              -

              Note that:

              -
                -

              • Each section header -can appear any number of times in the file (including none).

                • -

              • The section headers -and their data are case-insensitive.

                • -

              • A trailing backslash -is used to indicate a line continuation.

                • -

              • Use the C++ style comment -syntax for comments.

                • -

              • Preprocessor directives -such as #include and #ifdef can -be used.

                • -
              - -// Files to be exported -prj_exports -myheader1.h -myheader2.h - -// Project files -prj_mmpfiles -myprj1.mmp -myprj2.mmp - -// Files to be exported for test purposes -prj_testexports -mytestheader1.h - -// Project files for test programs -prj_testmmpfiles -mytest1.mmp -mytest2.mmp - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDDEA6A0-D45D-5241-B594-94ADDD803646.dita --- a/Symbian3/SDK/Source/GUID-EDDEA6A0-D45D-5241-B594-94ADDD803646.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EDDEA6A0-D45D-5241-B594-94ADDD803646.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,36 +9,35 @@ --> -Rendezvous -Thread rendezvous example codeThis example demonstrates the use of Rendezvous() API. -
              Purpose

              The code is a simple example that shows -the principle of synchronization using the thread rendezvous technique.

              -
              Class summary
                +Rendezvous Thread rendezvous example codeThis example demonstrates the use of Rendezvous() API. +
                Purpose

                The code is a simple example that shows the principle of synchronization +using the thread rendezvous technique.

                +
                Class +summary

                • RThread - A handle to a thread.

                -
                Download

                Download the example: Rendezvous.zip.

                Download some additional files -required by the example: CommonFramework.zip.

                View the source code: browse. View the additional files: browse

                -
                Building and -configuring
                  -

                • You can build the example -from your IDE or the command line.

                  If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

                  If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

                  bldmake -bldfiles

                  abld build

                  How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

                  • -

                • For the emulator, the -example builds an executable called threadrendezvous.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

                  • +
                  Download

                  Download the example: Rendezvous.zip.

                  Download some additional +files required by the example: CommonFramework.zip.

                  View the source +code: browse. View the additional files: browse

                  +
                  Building +and configuring
                    +

                  • You can build +the example from your IDE or the command line.

                    If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

                    If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

                    bldmake bldfiles

                    abld +build

                    • +

                  • For the emulator, +the example builds an executable called threadrendezvous.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

                  -
                  Running the example

                  When running the example, the -user is presented with various menu options that are self explanatory. The -code is a simple example that shows the principle of synchronization using -the thread rendezvous technique.

                  +
                  Running +the example

                  When running the example, the user is presented +with various menu options that are self explanatory. The code is a +simple example that shows the principle of synchronization using the +thread rendezvous technique.

                  - -Synchronisation -techniques - +Synchronization +techniques \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EDE54D27-D902-5C67-BF8E-5E7E0A33A98E.dita --- a/Symbian3/SDK/Source/GUID-EDE54D27-D902-5C67-BF8E-5E7E0A33A98E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EDE54D27-D902-5C67-BF8E-5E7E0A33A98E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,4 +9,4 @@ --> -ASN-PKCS OverviewThe ASN-PKCS component provides interfaces for:

                  • Performing ASN.1 -DER (Abstract Syntax Notation One - Distinguished Encoding Rules) encoding and decoding of PKCS (Public-Key Cryptography Standards) private keys in raw text as well as PBE (Password-Based Encryption) encrypted forms.

                  • Performing ASN.1 encoding and decoding of PBE parameters associated with the private keys.

                  Key concepts and terms
                  Key

                  A cryptography key is a constant value applied using a cryptographic algorithm to encrypt text or to decrypt encrypted text.

                  Keys are classified as symmetric and asymmetric based on the type of algorithm applied. If the same key is used for both encryption and decryption, it is symmetric. If different keys are used for encryption and decryption, they are asymmetric. Asymmetric keys exist in the form of a public and private key pair, where the public key is used for encryption and the private key is used for decryption.

                  Key Store

                  A key store is a repository of keys that can be retrieved and used to accomplish a variety of tasks.

                  The key store provides the following functionality:

                  • Generation, import and export of RSA, DSA, and DH key pairs

                  • Listing of stored keys

                  • Authentication of users

                  • Private key operations for authenticated users

                  Architecture

                  The following block diagram describes the interaction of the ASN-PKCS component with the certificate and key stores:

                  The client application accesses the various certificates and keys of the device stored in the respective stores. Depending on the requests received from the store management and implementation components, ASN-PKCS acts on the keys during certain key and certificate manipulation operations. For details of the operations during which the ASN-PKCS APIs are invoked, see Typical uses.

                  APIs
          API Description

          CDecPKCS8Data

          Provides the means to decode PKCS#8 encoded private keys.

          Typical uses

          ASN-PKCS APIs are used for encoding and decoding purposes during the following key and certificate manipulation operations:

          • Encoding and decoding of PKCS private keys (in raw text and PBE-encrypted forms) during import and export of keys. When PBE-encrypted PKCS keys are imported or exported, the ASN-PKCS APIs also help in encoding or decoding of the PBE parameters.

          • Encoding of the private keys accompanying public key certificates (according to PKCS#12 standards) while creating certificate requests.

          • Creation of PKCS#7 messages for creating the certificate requests.

          Notes:

          • Device creators can use the ASN-PKCS component along with their own implementation of the certificate and key stores.

          • For details of the key and certificate operations, see Unified Keystore Tutorials and Unified Certificate Store Tutorial respectively.

          Unified Stores           \ No newline at end of file +ASN-PKCS OverviewThe ASN-PKCS component provides interfaces for:

          • Performing ASN.1 -DER (Abstract Syntax Notation One - Distinguished Encoding Rules) encoding and decoding of PKCS (Public-Key Cryptography Standards) private keys in raw text as well as PBE (Password-Based Encryption) encrypted forms.

          • Performing ASN.1 encoding and decoding of PBE parameters associated with the private keys.

          Key concepts and terms
          Key

          A cryptography key is a constant value applied using a cryptographic algorithm to encrypt text or to decrypt encrypted text.

          Keys are classified as symmetric and asymmetric based on the type of algorithm applied. If the same key is used for both encryption and decryption, it is symmetric. If different keys are used for encryption and decryption, they are asymmetric. Asymmetric keys exist in the form of a public and private key pair, where the public key is used for encryption and the private key is used for decryption.

          Key Store

          A key store is a repository of keys that can be retrieved and used to accomplish a variety of tasks.

          The key store provides the following functionality:

          • Generation, import and export of RSA, DSA, and DH key pairs

          • Listing of stored keys

          • Authentication of users

          • Private key operations for authenticated users

          Architecture

          The following block diagram describes the interaction of the ASN-PKCS component with the certificate and key stores:

          The client application accesses the various certificates and keys of the device stored in the respective stores. Depending on the requests received from the store management and implementation components, ASN-PKCS acts on the keys during certain key and certificate manipulation operations. For details of the operations during which the ASN-PKCS APIs are invoked, see Typical uses.

          APIs API Description

          CDecPKCS8Data

          Provides the means to decode PKCS#8 encoded private keys.

          Typical uses

          ASN-PKCS APIs are used for encoding and decoding purposes during the following key and certificate manipulation operations:

          • Encoding and decoding of PKCS private keys (in raw text and PBE-encrypted forms) during import and export of keys. When PBE-encrypted PKCS keys are imported or exported, the ASN-PKCS APIs also help in encoding or decoding of the PBE parameters.

          • Encoding of the private keys accompanying public key certificates (according to PKCS#12 standards) while creating certificate requests.

          • Creation of PKCS#7 messages for creating the certificate requests.

          Notes:

          • Device creators can use the ASN-PKCS component along with their own implementation of the certificate and key stores.

          • For details of the key and certificate operations, see Unified Keystore Tutorials and Unified Certificate Store Tutorial respectively.

          Unified Stores           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EE556214-BFB8-582E-ACD9-5287D7C64EFA_d0e334772_href.jpg Binary file Symbian3/SDK/Source/GUID-EE556214-BFB8-582E-ACD9-5287D7C64EFA_d0e334772_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EE556214-BFB8-582E-ACD9-5287D7C64EFA_d0e341238_href.jpg Binary file Symbian3/SDK/Source/GUID-EE556214-BFB8-582E-ACD9-5287D7C64EFA_d0e341238_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EE5937B6-9103-4711-B13B-06A62D56AF79_d0e69754_href.png Binary file Symbian3/SDK/Source/GUID-EE5937B6-9103-4711-B13B-06A62D56AF79_d0e69754_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EE5937B6-9103-4711-B13B-06A62D56AF79_d0e69777_href.png Binary file Symbian3/SDK/Source/GUID-EE5937B6-9103-4711-B13B-06A62D56AF79_d0e69777_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EEC50FC0-46D5-4ED7-AD95-67430D5EC651.dita --- a/Symbian3/SDK/Source/GUID-EEC50FC0-46D5-4ED7-AD95-67430D5EC651.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EEC50FC0-46D5-4ED7-AD95-67430D5EC651.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,24 +1,25 @@ - - - - - -Application -security -

          Native C++ applications have broad access to the mobile device functionality. -They can access, for example, network and mobile device interfaces, storage -memory and messaging framework. This provides many features for application -developers to use, but can be exploited in the wrong hands.

          -

          The Symbian platform -security architecture allows an application server to determine whether -installed software using the server can be trusted. This section covers the -most critical components in the security system, the components that first -encounter problems and form the front line of defense when a system is attacked.

          -

          The following aspects of application security are covered in this section:

          + + + + + +Application security +

          Native C++ applications have broad access to the mobile device +functionality. They can access, for example, network and mobile device +interfaces, storage memory and messaging framework. This provides +many features for application developers to use, but can be exploited +in the wrong hands.

          +

          The Symbian platform security architecture allows an application server +to determine whether installed software using the server can be trusted. +This section covers the most critical components in the security system, +the components that first encounter problems and form the front line +of defense when a system is attacked.

          +

          The following aspects of application security are covered in +this section:

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EF3DB813-B0B9-5099-9E57-561A32111BF0.dita --- a/Symbian3/SDK/Source/GUID-EF3DB813-B0B9-5099-9E57-561A32111BF0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EF3DB813-B0B9-5099-9E57-561A32111BF0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,5 +11,5 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Feature Manager Server GuideThis document describes the feature management server.
          Purpose

          The feature management server maintains the table which contains and maintains the list of features available on the device.

          Required background

          The feature management system uses the standard client server architecture that is the feature manager server that does the work associated with the feature management functionality. Communication between the application and the server is undertaken by two dlls.

          Architecture

          The relationship between the parts of the feature management system is :

          Architecture of the feature management system -
          APIs

          Communication to and from the feature management server is only provided by the methods available in the Feature Manager Client API and the Feature Manager Discovery API.

          Typical uses

          These are the same as for feature management (since it does all the work). They include adding, disabling, enabling and removing features.

          For the description of the APIs used in feature management look at the component overview for featmgr.dll and featdiscovery.dll.

          Feature Manager Overview Feature Manager Client +
          APIs

          Communication to and from the feature management server is only provided by the methods available in the Feature Manager Client API and the Feature Manager Discovery API.

          Typical uses

          These are the same as for feature management (since it does all the work). They include adding, disabling, enabling and removing features.

          For the description of the APIs used in feature management look at the component overview for featmgr.dll and featdiscovery.dll.

          Feature Manager Overview Feature Manager Client Overview Feature Discovery Overview \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EF7F79E4-21B1-59E3-A063-ABD2C6426E7C_d0e134536_href.png Binary file Symbian3/SDK/Source/GUID-EF7F79E4-21B1-59E3-A063-ABD2C6426E7C_d0e134536_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EF7F79E4-21B1-59E3-A063-ABD2C6426E7C_d0e138140_href.png Binary file Symbian3/SDK/Source/GUID-EF7F79E4-21B1-59E3-A063-ABD2C6426E7C_d0e138140_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EFAEDFA5-3807-56EB-8D47-3A6960C4056C.dita --- a/Symbian3/SDK/Source/GUID-EFAEDFA5-3807-56EB-8D47-3A6960C4056C.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EFAEDFA5-3807-56EB-8D47-3A6960C4056C.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,7 +28,7 @@ the SDP description, delete the CSdpDocument object and close the string pool.

          The following illustration shows how to create an SDP description.

          - +

          Note: In the following illustration only required SDP fields are included.

      Error handling

      All diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EFE378EA-C668-5CD5-A630-B8041027791A_d0e76852_href.png Binary file Symbian3/SDK/Source/GUID-EFE378EA-C668-5CD5-A630-B8041027791A_d0e76852_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EFE378EA-C668-5CD5-A630-B8041027791A_d0e76890_href.png Binary file Symbian3/SDK/Source/GUID-EFE378EA-C668-5CD5-A630-B8041027791A_d0e76890_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EFF3BD37-BC29-52F5-B8AA-6362F0C3E20F.dita --- a/Symbian3/SDK/Source/GUID-EFF3BD37-BC29-52F5-B8AA-6362F0C3E20F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,87 +0,0 @@ - - - - - -ARMV5 -build targets -

      The ARMV5 build target builds to the ARMV5 architecture. -It is built to conform to a binary standard developed by ARM (the ABI for -the ARM architecture). Details of the standard are published at http://www.arm.com/products/DevTools/ABI.html.

      -

      The situation is complicated by there existing two versions of the ARM -ABI, referred to as v1 and v2 respectively, both of which are supported by -the toolchain. This page explains the build target to use in each case. For -more information on the differences in the toolchain used for each version -of the ABI, see ABIv1 -to ABIv2 toolchain changes.

      -

      This page includes the following sections, which describe RVCT compiler -versions for the ARM platform and ABI versions of ARM:

      -
        -

      • ARM RVCT compiler versions

        • -

      • ARMV5 (ABI v1 mode)

        • -

      • ARMV5 (ABI v2 mode)

        • -
      -
      ARM RVCT compiler -versions

      The ARMV5 build targets are built using -ARM's own RealView Compiler Tools (RVCT) (http://www.arm.com/products/DevTools/RealViewDevSuite.html).

      Note -that RVCT 2.2 build 435 used with Symbian OS v9.2 is not supported from v9.3 -onwards. Symbian OS v9.3 uses RVCT 2.2 build 559 and from OS v9.4 onwards -RVCT 2.2 build 616 is used.

      The following section discusses issues -concerned with having RVCT 2.2 builds 435, 559 and 616 installed on a single -PC, so as to enable development on both v9.2, v9.3 and v9.4.

      Compiler -set-up for v9.2, v9.3 and v9.4 builds

      If you need to develop for -Symbian OS v9.2, v9.3 and v9.4 on the same PC, you need to have the RVCT 2.2 -builds 435, 559 and 616 installed. The build tools will use the version that -appears first in the environment path variable. You will -need to modify this setting yourself when moving between development kits.

      Assuming -the tools are installed to C:\apps\:

        -

      • When working with v9.2, -include build 435 version of the tools first in the path.

        For example:

        set -PATH=C:\apps\ARM\RVCT\Programs\2.2\435\win_32-pentium;%path%

        • -

      • When working with v9.3, -include build 559 version of the tools first in the path.

        For example:

        set -PATH=C:\apps\ARM\RVCT\Programs\2.2\559\win_32-pentium;%path%

        • -

      • When working with v9.4, -include build 616 version of the tools first in the path.

        For example:

        set -PATH=C:\apps\ARM\RVCT\Programs\2.2\616\win_32-pentium;%path%

        • -

      To know which version is currently installed on your PC, use the -following command:

      armcc --vsn

      This -reports the compiler version and build number.

      -
      ARMV5 (ABI -v1 mode)

      Use this target to create binaries conforming to the ABI -v1.

      To build for ARMV5 (ABI v1) with abld on -Symbian OS v9.3 and earlier versions, use:

      abld build ARMV5 -[udeb | urel]

      To build for ARMV5 (ABI -v1) with abld on Symbian OS v9.4 and later versions, -use:

      abld build ARMV5_ABIv1 [udeb | urel]

      Binaries -are generated in the udeb and/or urel sub-directories -of the epoc32\release\ARMV5\ directory. From Symbian -OS v9.4 onwards, the binaries are generated in epoc32\release\ARMV5_ABIv1\.

      Library -export (.lib) files are generated in the epoc32\release\ARMV5\lib\ directory.

      -
      ARMV5 (ABI -v2 mode)

      Use this target to create binaries conforming to the ABI -v2.

      To build for ARMV5 (ABI v2) with abld on -Symbian OS v9.3 and earlier versions, use:

      abld build ARMV5_ABIv2 -[udeb | urel]

      To build for ARMV5 (ABI -v2) with abld on Symbian OS v9.4 and later versions, -use:

      abld build ARMV5 [udeb | urel]

      Binaries -are generated in the udeb and/or urel sub-directories -of the epoc32\release\ARMV5_ABIv2\ directory. From Symbian -OS v9.4 onwards, the binaries are generated in epoc32\release\ARMV5\.

      Library -export (.dso) files are generated in the epoc32\release\ARMV5\lib\ directory. -The ABI v2 toolchain need to support multiple ABI v2 compatible compilers -to have a common directory for the import library files.

      From Symbian -OS v9.4 and later, ABI v2 is the default platform. So, a simple abld -build command will create a binary conforming to ABI v2. To create -a binary conforming to ABI v1, use abld build ARMV5_ABIv1.

      You -can switch back to the old approach, where the targets ARMV5 and ARMV5_ABIv2 will -build binaries conforming to ABI v1 and ABI v2 respectively. For more details -on this, refer to Switching -between ABI modes.

      - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-EFF8D1A1-00D5-5F96-8285-414DC0044AB8.dita --- a/Symbian3/SDK/Source/GUID-EFF8D1A1-00D5-5F96-8285-414DC0044AB8.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-EFF8D1A1-00D5-5F96-8285-414DC0044AB8.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,14 +16,14 @@ the calling process. The calling process should have a WriteUserData capability.

      The following steps explain the process of setting a use policy for a key:

       - -Create a file system + +Create a file system session using an RFs object. - + Create an object of type CUnifiedKeyStore using CUnifiedKeyStore::NewL() or CUnifiedKeyStore::NewLC(). - + Initialise the member functions and keystore using the asynchronous function CUnifiedKeyStore::Initialize(). @@ -31,13 +31,13 @@ List all keys in the keystore using the CUnifiedKeyStore::List() function. Retrieve the handle of the key for which the use policy needs to be set. - + Set the use policy for the key using the CUnifiedKeyStore::SetUsePolicy() function.

      Use policy is set for the selected key.

      -Example

      The -following code snippet shows how to set use policy for a key.

      // Create a file system session object +Example

      The +following code snippet shows how to set use policy for a key.

      // Create a file system session object RFs iFs; CleanupClosePushL(&iFs); diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F03A323A-2FCC-5247-909F-4AB2701B1C45.dita --- a/Symbian3/SDK/Source/GUID-F03A323A-2FCC-5247-909F-4AB2701B1C45.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,17 +0,0 @@ - - - - - -smpsafe -

      smpsafe

      Sets a flag on the target. -This indicates the OS that the program when run on muti-core processors can -make use of full symmetric multiprocessing (SMP) capabilities. SMP safe programs -can achieve high performance.

      -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F057FFF8-EA6A-5719-BE6B-B37950A07A7B_d0e219908_href.png Binary file Symbian3/SDK/Source/GUID-F057FFF8-EA6A-5719-BE6B-B37950A07A7B_d0e219908_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F057FFF8-EA6A-5719-BE6B-B37950A07A7B_d0e224902_href.png Binary file Symbian3/SDK/Source/GUID-F057FFF8-EA6A-5719-BE6B-B37950A07A7B_d0e224902_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F0923110-D5D9-56D7-8CBC-82CAE062BC1A.dita --- a/Symbian3/SDK/Source/GUID-F0923110-D5D9-56D7-8CBC-82CAE062BC1A.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - --check

      This option is for checking that the required files have been created during a particular build step.

      The option creates a list of files that should have been created and then checks that each one exists in turn. If a file is missing the full name of the file is piped to STDERR.

      Note that if this option is specified with abld - build, makefiles will not be included in the list of files to be checked.

      If the option is specified with abld - reallyclean, however, the makefiles will be included in the list.

       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F0C71D6E-CAF1-49CC-A697-FC1A810DF1D5.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F0C71D6E-CAF1-49CC-A697-FC1A810DF1D5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,17 @@ + + + + + +Time +Zone Services Tutorials +

      The tutorials are aimed at device creators. The client applications that +result, such as Clock, access and manage system TZ data and user-defined TZ +data.

      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F0DCFAB5-DE92-5336-B4E2-1ED40BE05DEC_d0e431942_href.png Binary file Symbian3/SDK/Source/GUID-F0DCFAB5-DE92-5336-B4E2-1ED40BE05DEC_d0e431942_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F0DCFAB5-DE92-5336-B4E2-1ED40BE05DEC_d0e435742_href.png Binary file Symbian3/SDK/Source/GUID-F0DCFAB5-DE92-5336-B4E2-1ED40BE05DEC_d0e435742_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F13D4492-4E0C-5D7A-A30D-9E79F092CF72.dita --- a/Symbian3/SDK/Source/GUID-F13D4492-4E0C-5D7A-A30D-9E79F092CF72.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,26 +0,0 @@ - - - - - -listing -

      abld [ test ] listing [-k] -[-v] [ platform ] [ build ] -[ program ] [ source_basename ]

      -

      This command creates an assembler listing file for a particular source -file.

      -

      The listing file name has the format extension source_basename .lis. ABI-name.

      -

      The listing file is created in the build directory and then copied to the -directory containing the source file.

      -

      Assuming myproject is a project, -and cappui.cpp is the file to get the listing for, the -following command would produce an ARMI release assembly listing for that -file:

      abld listing armi urel myproject cappui

      This -would produce an output file cappui.lis.armi.

       -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F149726A-CC79-42A1-8A25-E15AC14ABE9A.dita --- a/Symbian3/SDK/Source/GUID-F149726A-CC79-42A1-8A25-E15AC14ABE9A.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F149726A-CC79-42A1-8A25-E15AC14ABE9A.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ items that the user can adjust. Setting lists are displayed in the main pane.

      Setting list - +

      A setting item can be adjusted by selecting it in the same way as selection list items are selected in general; that is, by pressing the Selection key, @@ -67,19 +67,19 @@ Pop-up setting - + Multi-selection setting - + Text setting - + Slider setting - +

      By default, in a setting editor, the keypad functions are as follows:

      Default key events diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F14A2252-7D7B-5631-9796-3C9AC54014E7.dita --- a/Symbian3/SDK/Source/GUID-F14A2252-7D7B-5631-9796-3C9AC54014E7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F14A2252-7D7B-5631-9796-3C9AC54014E7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -33,7 +33,7 @@ your client application. </p> <codeblock id="GUID-EED135A5-C141-5525-9C0C-DCF318040C46" xml:space="preserve">IMPORT_C void RequestL (CMsvSearchSortQuery* aQuery, TBool aMarkQuery, TRequestStatus& aQueryStatus, TInt aIterator=0)</codeblock> <p><b>Unmarking</b> </p> <p>To unmark a query ID, use the CMsvSearchSortOperation::UnmarkQuery() function in your client application. </p> <codeblock id="GUID-1C27E207-33F0-5F64-81FC-C50BF257BCB7" xml:space="preserve">IMPORT_C TInt UnmarkQuery (const TInt aQueryId )</codeblock> <fig id="GUID-7D09EFAE-67B3-5142-A6EF-F9D86E39414F"> <title> Repetitive search request process - +
      Procedure

      1. To get a query ID, complete diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F15B9BDF-EDF8-5684-A0FC-C0A08F9C1F22.dita --- a/Symbian3/SDK/Source/GUID-F15B9BDF-EDF8-5684-A0FC-C0A08F9C1F22.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F15B9BDF-EDF8-5684-A0FC-C0A08F9C1F22.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,116 +9,91 @@ --> -linkedlist: -Using the Linked List classes -

        The following examples -show the use of the linked list classes:

          +linkedlist: Using the Linked List classes +

          The following +examples show the use of the linked list classes:

          • Singly linked list example

          • Doubly linked list example

          • Delta queue example

          -
          Singly linked -list example

          This example application demonstrates the use of singly -linked lists. The templated TSglQue class is used to create -a singly linked list.

          Download

          Click on the following -link to download the example: sgllist.zip

          Click: browse to view the example.

          Description

          The -example creates a singly linked list of objects of the TDigit class. -This list represents a long number. An object of class CLongNumber owns -the list. The user can edit this list using the functions defined in the CLongNumber class. -The following edit operations are possible:

            -

          • Insert an object of -the TDigit class at the start of the singly linked list

            • -

          • Insert an object of -the TDigit class at the end of the singly linked list

            • -

          • Remove an object of -the TDigit class from the end of the singly linked list

            • -

          The user can perform any of these operations by pressing keys specified -in the menu. CLongNumber is an active object class and handles -the key press events in the CLongNumber::RunL() function.The CLongNumber::ReadFunc() function -displays a menu and waits for an asynchronous key press event.

          An -object of the templated TSglQueIter class is used to traverse -this linked list. The sum of all digits of the number represented by the linked -list is displayed to the user.

          An object of the CAdder class -is used to traverse the CLongNumber::iNumber list and print -the sum of all digits of the number represented by this list. The CAdder::Add() function -gets this sum.

          Related APIs

            +
            Singly +linked list example

            This example application demonstrates +the use of singly linked lists. The templated TSglQue class is used to create a singly linked list.

            Download

            Click on the following link to download the example: sgllist.zip

            Click: browse to view the example.

            Description

            The example creates a singly linked list of objects of the TDigit class. This list represents a long number. An object +of class CLongNumber owns the list. The user can +edit this list using the functions defined in the CLongNumber class. The following edit operations are possible:

              +

            • Insert an object +of the TDigit class at the start of the singly linked +list

              • +

            • Insert an object +of the TDigit class at the end of the singly linked +list

              • +

            • Remove an object +of the TDigit class from the end of the singly linked +list

              • +

            The user can perform any of these operations by pressing +keys specified in the menu. CLongNumber is an active +object class and handles the key press events in the CLongNumber::RunL() function.The CLongNumber::ReadFunc() function displays +a menu and waits for an asynchronous key press event.

            An object +of the templated TSglQueIter class is used to traverse +this linked list. The sum of all digits of the number represented +by the linked list is displayed to the user.

            An object of +the CAdder class is used to traverse the CLongNumber::iNumber list and print the sum of all digits +of the number represented by this list. The CAdder::Add() function gets this sum.

            Related APIs

            • CAdder

            • CLongNumber

            • TDigit

            • TSglQueIter

              • -

            Design and implementation

            Figure 1 shows the classes -in the example.

            - Figure 1. Classes in the singly linked list example - - +

          Design and implementation

          Figure 1 shows the +classes in the example.

          + Figure 1. Classes in the singly linked list example + +

          Class summary

          • TSglQue

          • TSglQueIter

            • -

          Build

          The -Symbian build process describes how to build this example.

          For -the emulator, the example builds an executable called sgllist.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

          See -also:

          Using -Singly Linked Lists

          -
          Doubly linked -list example

          This example application demonstrates the use of doubly -linked lists. The templated TDblQue class is used create -a doubly linked list.

          Download

          Click on the following -link to download the example: dbllist.zip

          Click: browse to view the example code

          Description

          The -example creates a doubly linked list of objects of the TLetter class. -This list represents a character string. An object of class CMyStringReverse owns -this string. The user can edit this string using the functions defined in -the CMyStringReverse class. The following edit operations -are possible:

            -

          • Insert a character at -the start of the list

            • -

          • Insert a character at -the end of the list

            • -

          The user can perform either of these operations by pressing keys -specified in the menu. CMyStringReverse is an active object -class and handles key press events in the CMyStringReverse::RunL() function. -The CMyStringReverse::ReadFunc() function displays a menu -and waits for an asynchronous key press event.

          The CMyStringReverse class -has a doubly linked list iterator, iIteratorString. The iIteratorString object -iterates through the list iString from start to end to print -the string reversed.

          Design and implementation

          Figure -2 shows the classes in the example.

          +

        Build

        For the emulator, the +example builds an executable called sgllist.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

        See also:

        Using Singly Linked +Lists

        +
        Doubly +linked list example

        This example application demonstrates +the use of doubly linked lists. The templated TDblQue class is used create a doubly linked list.

        Download

        Click on the following link to download the example: dbllist.zip

        Click: browse to view the example code

        Description

        The example creates a doubly linked list of objects of the TLetter class. This list represents a character string. +An object of class CMyStringReverse owns this string. +The user can edit this string using the functions defined in the CMyStringReverse class. The following edit operations are +possible:

          +

        • Insert a character +at the start of the list

          • +

        • Insert a character +at the end of the list

          • +

        The user can perform either of these operations by pressing +keys specified in the menu. CMyStringReverse is an +active object class and handles key press events in the CMyStringReverse::RunL() function. The CMyStringReverse::ReadFunc() function +displays a menu and waits for an asynchronous key press event.

        The CMyStringReverse class has a doubly linked +list iterator, iIteratorString. The iIteratorString object iterates through the list iString from start +to end to print the string reversed.

        Design and implementation

        Figure 2 shows the classes in the example.

        Figure 2. Classes in the doubly linked list example - +

        Class summary

          -

        • TDblQue - A templated class that provides the behaviour -for managing a doubly linked list.

          • -

        Build

        The -Symbian build process describes how to build this example.

        For -the emulator, the example builds an executable called dbllist.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

        See -also

        Using -Doubly Linked Lists

        Example code

        -
        Delta queue -example

        This example application demonstrates the use of the delta -queue. The templated TDeltaQue class is used create a delta -queue.

        Download

        Click on the following link to download -the example: deltaque.zip

        Click: browse to view the example code.

        Description

        The -example creates an object of the CTimerEntry class. This -is a CTimer derived class. An object of this class generates -timer events by using the CTimer::After() function. The -data member of this class, iQueue is a delta list. The offset -value of each node in this list is the tick count after each timer event. -The CTimerEntry::Arbitrator() function decides the action -to be performed for each event generated by the timer. It either adds tick -counts to the list or removes elements from the list based on the state of -the queue.

        Related APIs

          +

        • TDblQue - A templated class that provides +the behaviour for managing a doubly linked list.

          • +

        Build

        For the emulator, the example builds +an executable called dbllist.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

        See also

        Using Doubly Linked +Lists

        Example code

        +
        Delta +queue example

        This example application demonstrates the +use of the delta queue. The templated TDeltaQue class is used create a delta queue.

        Download

        Click on the following link to download the example: deltaque.zip

        Click: browse to view the example code.

        Description

        The example creates an object of the CTimerEntry class. This is a CTimer derived class. An object +of this class generates timer events by using the CTimer::After() function. The data member of this class, iQueue is a delta list. The offset value of each node in this list is the +tick count after each timer event. The CTimerEntry::Arbitrator() function decides the action to be performed for each event generated +by the timer. It either adds tick counts to the list or removes elements +from the list based on the state of the queue.

        Related APIs

        • CTimer - Base class for a timer active object.

        • CTimer::After()

          • -

        Design and implementation

        Figure 3 shows the classes -of the example.

        +

        Design and implementation

        Figure 3 shows the +classes of the example.

        Figure 3. Classes of the delta queue example - +

        Class summary

        • TDeltaQue

        • CTimer - Base class for a timer active object.

          • -

        Build

        The -Symbian build process describes how to build this example.

        For -the emulator, the example builds an executable called deltaque.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

        +

        Build

        For the emulator, the example builds +an executable called deltaque.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

      \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e51832_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e51832_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e51975_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e51975_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e58481_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e58481_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e58624_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e58624_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e64048_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e64048_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e64191_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e64191_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e69073_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e69073_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e69097_href.png Binary file Symbian3/SDK/Source/GUID-F161C184-2016-4331-A57C-78C753453EFE_d0e69097_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F18A6C91-136D-450E-90F0-7C2B9263777C_d0e5989_href.png Binary file Symbian3/SDK/Source/GUID-F18A6C91-136D-450E-90F0-7C2B9263777C_d0e5989_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F18A6C91-136D-450E-90F0-7C2B9263777C_d0e6110_href.png Binary file Symbian3/SDK/Source/GUID-F18A6C91-136D-450E-90F0-7C2B9263777C_d0e6110_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F18AA5AC-80C6-51B2-8D15-61C59D877520_d0e369722_href.jpg Binary file Symbian3/SDK/Source/GUID-F18AA5AC-80C6-51B2-8D15-61C59D877520_d0e369722_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F18AA5AC-80C6-51B2-8D15-61C59D877520_d0e388871_href.jpg Binary file Symbian3/SDK/Source/GUID-F18AA5AC-80C6-51B2-8D15-61C59D877520_d0e388871_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F1CC06C0-0D3A-4BBC-97E1-E52D2856D7A7.dita --- a/Symbian3/SDK/Source/GUID-F1CC06C0-0D3A-4BBC-97E1-E52D2856D7A7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F1CC06C0-0D3A-4BBC-97E1-E52D2856D7A7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ Find pane is situated in the bottom part of the main pane.

      Find pane within a selection list of names in Phonebook - +

      The standard functionality of the Find pane is as follows:

        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F1EFB7C3-BC06-4822-BA37-06B02BECE80A_d0e74267_href.png Binary file Symbian3/SDK/Source/GUID-F1EFB7C3-BC06-4822-BA37-06B02BECE80A_d0e74267_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F1EFB7C3-BC06-4822-BA37-06B02BECE80A_d0e74305_href.png Binary file Symbian3/SDK/Source/GUID-F1EFB7C3-BC06-4822-BA37-06B02BECE80A_d0e74305_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita --- a/Symbian3/SDK/Source/GUID-F21A1ABE-4844-54E2-83E0-4AD25E867A72.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ - - - - - -ABIv1 -to ABIv2 toolchain changes -

        The principal task of Symbian platform build tools such as abld/makmake is -to read the specified project (.mmp) files and then call the appropriate compiler -and linker with the necessary inputs and option settings. The binaries output -from commercial compiler and linkers, such as ARM's RVCT and GNU GCC, cannot -however be directly used by Symbian platform. Symbian platform requires binaries -to be in Symbian-specific format, known as the E32Image format.

        -

        In order to create binaries in this format, the toolchain must perform -additional steps on the compiler/linker output. How these steps are performed -is considerably different between builds for the ABIv1 and ABIv2 targets. -Essentially, a number of small tools used for ABIv1 targets, are replaced -for ABIv2 targets by a single tool called the post-linker (file name elf2e32.exe). -This redesign is intended to simplify the work needed to introduce support -for a new ABIv2 compatible compiler into the toolchain.

        -

        The following diagram shows the steps (somewhat simplified) performed by -the toolchain for the creation of a DLL for ABIv1 and v2 respectively:

        - - ABIv1 and v2 toolchains compared - - -

        The elf2e32 tool replaces the ABIv1 toolchain tools def2dll.bat, elf2inf.pl, makedef.pl and elftran.exe.

        -
        .dso files

        In the ABIv2 toolchain, .lib files -are replaced by .dso files. These files are used in similar -situations to .lib files. However, the format of these -two files is completely different. A .lib file is an -archive file created from stubs generated for each of the exported symbols. -A .dso file is an ELF object similar to other objects -created with the compiler. It has all the associated sections required for -an ELF object, such as the symbol table, string table, etc. The .dso file -also has the information required for the linker to link to the correct ordinals -to the DLL. .lib files cannot be used by the ABIv2 toolchain, -and .dso files cannot be used by the ABIv1 toolchain.

        -
        Linked objects

        The compiler toolchain that supports -ABIv2 produces linked objects that are different to those produced by the -ABIv1 toolchain. The linked objects produced are both ELF format, but they -have extra information that can be used by a postlinker to create platform -specific binaries. As the ELF produced by ABIv2 has more information, it is -not necessary to perform the sort of manipulations performed by the many small -tools in the ABIv1 toolchain. As the linked objects differ significantly in -their content, it is not possible to mix ABIv1 and ABIv2 toolchain objects -in the same build tree.

        -
        E32Image format

        The final E32image produced by -the ABIv2 toolchain is in the same format as that of the ABIv1 toolchain. -However, a byte by byte comparison of the same E32image file in ABIv1 and -ABIv2 is not possible. The layout of the code produced by the linker is different, -although the code is still binary compatible.

        -         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F220E2B7-DE9B-5230-A396-15853369C176_d0e184149_href.png Binary file Symbian3/SDK/Source/GUID-F220E2B7-DE9B-5230-A396-15853369C176_d0e184149_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F220E2B7-DE9B-5230-A396-15853369C176_d0e189139_href.png Binary file Symbian3/SDK/Source/GUID-F220E2B7-DE9B-5230-A396-15853369C176_d0e189139_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F22B8035-CD08-4181-B03A-759E92CA967B.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F22B8035-CD08-4181-B03A-759E92CA967B.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,16 @@ + + + + + +Organizer Guide +

        The Organizer package is a collection of various components related +to Personal Information Management (PIM). Organizer package includes +Calendar, Clock, Alarm, Notepad and Search applications.

        +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F23BB1F1-CF90-597F-8410-34AB8B567501.dita --- a/Symbian3/SDK/Source/GUID-F23BB1F1-CF90-597F-8410-34AB8B567501.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F23BB1F1-CF90-597F-8410-34AB8B567501.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ such as Telephony, SyncML and Messaging.

        PIM Subsystem components are part of the Application Services and Generic Middleware layers - +
        Application Engines

        Application Engines provide data storage and manipulation diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2487AEE-966E-472E-9162-E0400C9A8234.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F2487AEE-966E-472E-9162-E0400C9A8234.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,21 @@ + + + + + +Converting +from UTC to local time in the system time zone + +To convert from +UTC to the local time of the system time zone, use CTzConverter::ConvertToLocalTime(), +without specifying a time zone ID to convert to: +

        TInt errCode = myConverter->ConvertToLocalTime( myTime );

        + + + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F25C17AC-BA88-4965-BAE8-AEF0E2EA66EC.dita --- a/Symbian3/SDK/Source/GUID-F25C17AC-BA88-4965-BAE8-AEF0E2EA66EC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F25C17AC-BA88-4965-BAE8-AEF0E2EA66EC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,43 +1,41 @@ - - - - -Zooming actions -Mobile device users must be able to zoom in and out consistently within applications on a mobile device. However -the zooming actions may differ from one device model to another. - - - - -

        The product features and form factor of a mobile device determine -which zooming actions application developers should make available -on it:

        -
          -

        • If the device has an ITU-T keypad, the asterisk (*) key zooms -in and the hash mark (#) key zooms out. This functionality is not -available in editors or other states where the keys play another role. -In these cases, the zoom functions, if applicable, must be available -in the Options menu.

          • -

        • If the device has a QWERTY or half-QWERTY keyboard, use the -two topmost keys at the top left of the keyboard for zooming in and -out. For example, on a Latin keyboard, use the Q key to zoom in and -the A key to zoom out. Some products might have zooming symbols printed -on the keyboard to help users find the zooming features. Again, the -functions are not available in editors.

          • -

        • On touch devices, users can use touch stripes to zoom. Finger -movement along the stripe controls zooming. Applications may support -different number of zoom levels. It should be possible to zoom across -the full range with one swipe.

          • -

        • On touch devices with multiple touch support, users can use -pinch zoom. See Multiple touch section for more details on pinch in and pinch out.

          • -

        • On touch devices, some applications may support double-tapping -zoom. A double tap can toggle between zoomed and normal view, but -this depends on the application.

          • -
        -         -         - + + + + + +Zooming actionsMobile device users must be able to zoom in and out consistently +within applications on a mobile device. However the zooming actions +may differ from one device model to another. +

        The product features and form factor of a mobile device determine +which zooming actions application developers should make available +on it:

        +
          +

        • If the device has an ITU-T keypad, the asterisk (*) key zooms +in and the hash mark (#) key zooms out. This functionality is not +available in editors or other states where the keys play another role. +In these cases, the zoom functions, if applicable, must be available +in the Options menu.

          • +

        • If the device has a QWERTY or half-QWERTY keyboard, use the +two topmost keys at the top left of the keyboard for zooming in and +out. For example, on a Latin keyboard, use the Q key to zoom in and +the A key to zoom out. Some products might have zooming symbols printed +on the keyboard to help users find the zooming features. Again, the +functions are not available in editors.

          • +

        • On touch devices, users can use touch stripes to zoom. Finger +movement along the stripe controls zooming. Applications may support +different number of zoom levels. It should be possible to zoom across +the full range with one swipe.

          • +

        • On touch devices with multiple touch support, users can use +pinch zoom. See Multiple touch section for more details on pinch in and pinch +out.

          • +

        • On touch devices, some applications may support double-tapping +zoom. A double tap can toggle between zoomed and normal view, but +this depends on the application.

          • +
        +         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F263A3D1-EA96-5D4B-B8C9-4B8471082DBA.dita --- a/Symbian3/SDK/Source/GUID-F263A3D1-EA96-5D4B-B8C9-4B8471082DBA.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F263A3D1-EA96-5D4B-B8C9-4B8471082DBA.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,6 +9,6 @@ --> -MVS GUI layout

        The MVS GUI is shown below.

        This example shows the GUI while an audio file is playing, and includes the tool bar (at the top), the information pane (in the middle), and the status bar (at the bottom).

        Tool bar

        The tool bar buttons let you control the currently loaded media file.

        From left to right, the buttons let you:

        • play, pause, stop and record a file. These buttons have the standard symbols for AV devices.

        • set the number of repeats for the file (curved arrow)

        • set the playback sound volume (megaphone)

        • set the stereo balance (arrows pointing left and right)

        • fast reverse the file (standard symbol)

        • fast forward the file (standard symbol).

        Information pane

        The information pane displays details of the current media file:

        • The state of the file: AUDIO or VIDEO, PLAYING, RECORDING, PAUSED or STOPPED

        • The sound volume as a percentage of the maximum

        • The sound balance: Left, Right or Centre

        • The number of times the file contents are played

        • The audio priority

        • The length of the clip in milliseconds

        • The bit rate (per second).

        When the a video file is loaded, the pane also contains:

        • The frame size

        • The frame rate.

        Status bar

        The status bar displays the current state of the GUI.

        +<concept xml:lang="en" id="GUID-F263A3D1-EA96-5D4B-B8C9-4B8471082DBA"><title>MVS GUI layout

        The MVS GUI is shown below.

        This example shows the GUI while an audio file is playing, and includes the tool bar (at the top), the information pane (in the middle), and the status bar (at the bottom).

        Tool bar

        The tool bar buttons let you control the currently loaded media file.

        From left to right, the buttons let you:

        • play, pause, stop and record a file. These buttons have the standard symbols for AV devices.

        • set the number of repeats for the file (curved arrow)

        • set the playback sound volume (megaphone)

        • set the stereo balance (arrows pointing left and right)

        • fast reverse the file (standard symbol)

        • fast forward the file (standard symbol).

        Information pane

        The information pane displays details of the current media file:

        • The state of the file: AUDIO or VIDEO, PLAYING, RECORDING, PAUSED or STOPPED

        • The sound volume as a percentage of the maximum

        • The sound balance: Left, Right or Centre

        • The number of times the file contents are played

        • The audio priority

        • The length of the clip in milliseconds

        • The bit rate (per second).

        When the a video file is loaded, the pane also contains:

        • The frame size

        • The frame rate.

        Status bar

        The status bar displays the current state of the GUI.

        Status bar -

        From left to right, the boxes show:

        • The path and name of the file (if any) being recorded or played.

        • What the GUI is doing; for example: Recording, Opened, Playing or Idle.

        • The elapsed time of clip being recorded or played, in hours, minutes, seconds and hundredths of a second (centiseconds): hh:mm:ss:cs.

        See Also

        Introduction to the MVS

        Recording media files

        Playing media files

        Editing media files

        Configuring and clearing files

        \ No newline at end of file +

        From left to right, the boxes show:

        • The path and name of the file (if any) being recorded or played.

        • What the GUI is doing; for example: Recording, Opened, Playing or Idle.

        • The elapsed time of clip being recorded or played, in hours, minutes, seconds and hundredths of a second (centiseconds): hh:mm:ss:cs.

        See Also

        Introduction to the MVS

        Recording media files

        Playing media files

        Editing media files

        Configuring and clearing files

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2877A25-1FBC-5C7C-9542-9EDED2748AD3_d0e335623_href.png Binary file Symbian3/SDK/Source/GUID-F2877A25-1FBC-5C7C-9542-9EDED2748AD3_d0e335623_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2877A25-1FBC-5C7C-9542-9EDED2748AD3_d0e342089_href.png Binary file Symbian3/SDK/Source/GUID-F2877A25-1FBC-5C7C-9542-9EDED2748AD3_d0e342089_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2D86E40-279A-5B48-B91F-922803FEF5DE.dita --- a/Symbian3/SDK/Source/GUID-F2D86E40-279A-5B48-B91F-922803FEF5DE.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F2D86E40-279A-5B48-B91F-922803FEF5DE.dita Tue Jul 20 12:00:49 2010 +0100 @@ -59,7 +59,7 @@ support for 7, 8, and 16-bit text messages, and message concatenation.

        The following figure shows the SMS architecture:

        SMS MTM architecture - +

        SMS Client MTM

        The SMS Client MTM implements the standard set of Client MTM APIs described in Client @@ -162,7 +162,7 @@ as type of operation, and number of messages processed. Progress information is provided by TSmsProgress.

        APIs - +

        The following are the important classes for SMS Client MTM:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2D96A30-7264-5CAF-9CC7-8AF05EF978E1_d0e117433_href.png Binary file Symbian3/SDK/Source/GUID-F2D96A30-7264-5CAF-9CC7-8AF05EF978E1_d0e117433_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2D96A30-7264-5CAF-9CC7-8AF05EF978E1_d0e117673_href.png Binary file Symbian3/SDK/Source/GUID-F2D96A30-7264-5CAF-9CC7-8AF05EF978E1_d0e117673_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2E8CB4B-C1BB-577D-B018-7FF231B70D8C_d0e189694_href.png Binary file Symbian3/SDK/Source/GUID-F2E8CB4B-C1BB-577D-B018-7FF231B70D8C_d0e189694_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2E8CB4B-C1BB-577D-B018-7FF231B70D8C_d0e194665_href.png Binary file Symbian3/SDK/Source/GUID-F2E8CB4B-C1BB-577D-B018-7FF231B70D8C_d0e194665_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2F19F40-E87B-4FF2-ABE8-4E14AE728364_d0e66931_href.png Binary file Symbian3/SDK/Source/GUID-F2F19F40-E87B-4FF2-ABE8-4E14AE728364_d0e66931_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F2F19F40-E87B-4FF2-ABE8-4E14AE728364_d0e67074_href.png Binary file Symbian3/SDK/Source/GUID-F2F19F40-E87B-4FF2-ABE8-4E14AE728364_d0e67074_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F31EC49A-FE01-58B2-9CB5-4A3BBCCB7DA7_d0e184746_href.png Binary file Symbian3/SDK/Source/GUID-F31EC49A-FE01-58B2-9CB5-4A3BBCCB7DA7_d0e184746_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F31EC49A-FE01-58B2-9CB5-4A3BBCCB7DA7_d0e189743_href.png Binary file Symbian3/SDK/Source/GUID-F31EC49A-FE01-58B2-9CB5-4A3BBCCB7DA7_d0e189743_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F32E2F00-B68F-59B2-AABA-181E16354C86.dita --- a/Symbian3/SDK/Source/GUID-F32E2F00-B68F-59B2-AABA-181E16354C86.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F32E2F00-B68F-59B2-AABA-181E16354C86.dita Tue Jul 20 12:00:49 2010 +0100 @@ -35,7 +35,7 @@ on to the next control in the hierarchy.

      The sequence diagram below illustrates the Object Provider process for supplying an interface pointer from the run-time hierarchy.

      - +

      Object1 wishes to call a function on MInterface. It calls MopGetObject() on the nearest control in the run-time hierarchy. The Object Provider Framework identifies the Uid for Minterface and diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F342B002-0667-5D51-AE2D-3CF534D70B62_d0e213719_href.png Binary file Symbian3/SDK/Source/GUID-F342B002-0667-5D51-AE2D-3CF534D70B62_d0e213719_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F342B002-0667-5D51-AE2D-3CF534D70B62_d0e218717_href.png Binary file Symbian3/SDK/Source/GUID-F342B002-0667-5D51-AE2D-3CF534D70B62_d0e218717_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F35C5336-907C-5B2A-92C6-F8883D49996E.dita --- a/Symbian3/SDK/Source/GUID-F35C5336-907C-5B2A-92C6-F8883D49996E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,107 +0,0 @@ - - - - - -How -to localise resources -

      Overview

      Symbian developers can localise a C++ -application by simply changing the resource file text associated with each -menu item, task bar or other control. Since changes to the text do not change -the symbol information in the generated header file, it is not necessary to -recompile the application to use the new file. Consequently, a resource file -may be generated for each language supported, and the actual resource used -is determined by the end-user at installation time.

      The examples quoted -in this page are taken from the code example Examples\ToolsAndUtilities\Localise, -which provides the Hello World application, localised for English and German.

      -
      Localisable strings

      Localisable strings should -not be defined within a resource file, but in separate files with the extension .rls. -An .rls file defines symbolic identifiers for strings, -to which the resource file refers when it needs the associated string.

      An -example from an .rls file is shown below:

      // Strings localised for UK -rls_string STRING_r_example_first_menu_name "Hello" -rls_string STRING_r_example_item0 "Item 0"

      The keyword rls_string appears -before each string definition, followed by a symbolic identifier, and then -the string itself in quotes. To localise the file for German, the same identifiers -would be used, but the strings would be translated, i.e.

      // Strings localised for German -rls_string STRING_r_example_first_menu_name "Hallo" -rls_string STRING_r_example_item0 "Eintrag 0"

      The resource -file itself would be the same, whatever the locale, as it would only refer -to strings through their symbolic names, e.g.

      MENU_TITLE - { - menu_pane=r_example_first_menu; - txt=STRING_r_example_first_menu_name; - }

      defines a menu title resource, with a title string defined -by STRING_r_example_first_menu_name (i.e. "Hello" in UK, -"Hallo" in German).

      -
      Building localised resource files

      You can define -in a project definition (.mmp) file the locales that -the project supports. Given appropriate resource source and .rls files, -the build process then builds a separate compiled resource file for each supported -locale.

      The process in detail can be broken into three steps:

        -

      • determine on a symbolic -identifier for every supported locale

        • -

      • specify in the project -definition file the supported locales

        • -

      • #include the .rls files -for the supported locales in the resource source file

        • -

      These are discussed further below.

      Locale identifiers

      You -should decide on a symbolic identifier for every supported language. The symbol -should be of the form:

      LANGUAGE_ language-code

      where language-code should -be two characters long, but otherwise can be anything you like, as long as -each language in the resource file has a unique symbol.

      You are recommended -to use a standard two-digit number as defined by Symbian in an enumeration TLanguage in e32std.h, -which gives numeric values to the languages. For example, the value ELangGerman (German) -in TLanguage has the value 3, so you could use LANGUAGE_03 as -the symbol for German.

      Alternatively, you can use logical letters -for each language: e.g. US English might have the symbol LANGUAGE_US, -while French might have the symbol LANGUAGE_FR.

      Project -definition files

      For projects with localised resources, you must -use the lang statement in the .mmp file -to set the languages codes used. So, for the above example, in which the language -codes used are for German (03) and UK English (01), the lang statement -should read:

      lang 01 03

      When -the project is built, each resource file specified in the project file will -be compiled multiple times, once for each language-code specified. The language -codes are used to complete the extension of the built resource files: for -our example, two files would be built: project-name .r01 and project-name .r03.

      Resource source files

      The symbols can then used, -with conditional compilation statements, to specify which string definitions -should be compiled for each language. In the example code fragment below, -the file 01-strings.rls is assumed to have the strings -localised for UK English, and the file 03-strings.rls the -strings localised for German.

      // Conditional compile, depending on locale -#ifdef LANGUAGE_01 // if language code is for UK - #include "01-strings.rls" -#elif defined LANGUAGE_03 // if language code is for German - #include "03-strings.rls" -#endif -// end conditional compile -
        -

      • when built with the -code 01, the UK English strings in 01-strings.rls are -compiled into the resource file

        • -

      • when built with the -code 03, the German strings in 03-strings.rls are compiled -into the resource file

        • -
      -
      How programs load resource files

      The Uikon application -framework attempts to load the project's resource file when the application -starts up. If the resource file has the extension .rsc, -then this is loaded. Alternatively, the framework attempts to load the correct -resource file by comparing the system locale setting with the available resource -files: for example, in a German locale, the resource file with extension .r03 would -be loaded. Resource files that are explicitly loaded by programs, rather than -by the framework, can use the same stategy, by calling BalfUtils::NearestLanguageFile() to -find a resource file with the correct language extension.

      More typically -than installing all the resource files for all the available locales, you -would only want to select a single resource file for installation, based on -the system locale or user preference. The Symbian platform Installation System -enables this, as described in PKG -file format to support multilingual application installation.

      - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F389671B-FC30-561B-BF48-E597D0CB2D47.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F389671B-FC30-561B-BF48-E597D0CB2D47.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,55 @@ + + + + + +Using +Secure Sockets : TutorialThis topic describes how to use secure sockets. + +Open a socket using +RSocket::Open() function and connect it with RSocket::Connect() function. + + +Create a secure socket by calling CSecureSocket::NewL() function with +the parameters as socket and secure protocol name. + + +To start the application acting as a client, use the CSecureSocket::StartClientHandshake() +function to initiate a handshake with the remote server. To start the application +acting as a server, use the CSecureSocket::StartServerHandshake() function. +The call completes with an error code, if the handshake fails. + + +Secure Sockets example

      In the following example +iSocket is a reference to the already opened and connected socket and KSSLProtocol +is the descriptor containing the name of a protocol, in this case TLS1.0. +The function should return a pointer to the CSecureSocket.

      +// Connect the socket server + User::LeaveIfError(iSocketServ.Connect()); +// Open the socket + User::LeaveIfError(iSocket.Open(iSocketServ, KAfInet, KSockStream, KProtocolInetTcp)); +//Connect the socket + connectInetAddr.SetAddress(KTestAddress); + connectInetAddr.SetPort(KSSLPort); //TLS port + + iSocket.Connect(connectInetAddr, iStatus); + + ... + + +// Construct the Tls socket + iTlsSocket = CSecureSocket::NewL(iSocket, KSSLProtocol()); + +// start the handshake + iTlsSocket->StartClientHandshake(iStatus); + +       +

      Use CSecureSocket::Send() to send data over the socket. Use CSecureSocket::Recv() +and CSecureSocket::RecvOneOrMore() to receive data from the socket.

      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F3913401-83F6-5A12-BCA8-ABA232C2BF3D.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F3913401-83F6-5A12-BCA8-ABA232C2BF3D.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,20 @@ + + + + + +End-to-End +Sockets API Example +
      Description

      This +updated example is a Sockets reference implementation of an enterprise system +that includes mobile clients, a server-based database, and Web portals (PHP +and JSP implementations).

      +
      Download

      Click +on the following link to download the example: Symbian_OS_End-to-End_Sockets_API_Example.zip

      Click browse to view the example code.

      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F392355C-C499-555A-85B7-1DF40492E9B2_d0e220085_href.png Binary file Symbian3/SDK/Source/GUID-F392355C-C499-555A-85B7-1DF40492E9B2_d0e220085_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F392355C-C499-555A-85B7-1DF40492E9B2_d0e225079_href.png Binary file Symbian3/SDK/Source/GUID-F392355C-C499-555A-85B7-1DF40492E9B2_d0e225079_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F3EE1000-71A6-4D48-A30B-3D2357BF20FB.dita --- a/Symbian3/SDK/Source/GUID-F3EE1000-71A6-4D48-A30B-3D2357BF20FB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F3EE1000-71A6-4D48-A30B-3D2357BF20FB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ interface.

      Generic button used in a toolbar - +

      The Generic button API is used for creating buttons that are displayed as parts of container components, such as a toolbar. It is not used for creating diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F41C1661-9704-500F-9324-B13748642332.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F41C1661-9704-500F-9324-B13748642332.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,49 @@ + + + + + +Configuring +the Server Name Indication : TutorialThis topic describes how to configure the server name indication. +

      Servers that support a virtual name-based hosting must know the +virtual names of the client that tries to establish a connection. The virtual +name-based hosts controls the decision of the server. The decision of server +is to return the server certificate or PSK if you use a PSK +ciphersuite.

      To address this issue, Symbian implements the server +name indication extension which is specified in RFC4366.

      Note: To maintain maximum compatibility +with the existing servers, a server name indication extension is not sent +to the server unless the server explicitly requests it. For example the implementer +Secure User Plane Location (SUPL) has to use this feature explicitly.

      The +steps required to establish a connection are shown below:

      + +Create an array +class. + +Wrap the array class. + +Call Setopt() on +CSecureSocket to pass the array of names. + + + Example

      The following example code shows how to +find the server names that the client is attempting to establish a connection:

      + +//Create an array class + CDesC8ArrayFlat *serverNames = new(ELeave) CDesC8ArrayFlat(1); + CleanupStack::PushL(serverNames); +//Wrap the array class + serverNames->AppendL(serverName); +//Call Setopt() on CSecureSocket to pass the array of names in + TPckgC<CDesC8Array *> serverNameIndicationPkg(serverNames); + User::LeaveIfError(secureSocket->SetOpt(KSoServerNameIndication, KSolInetSSL, serverNameIndicationPkg)); +//SecureSocket now owns the serverNames object + CleanupStack::Pop(serverNames); + +       + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F4203C60-EB2A-4644-8B2D-291087724BA9_d0e143081_href.png Binary file Symbian3/SDK/Source/GUID-F4203C60-EB2A-4644-8B2D-291087724BA9_d0e143081_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F4203C60-EB2A-4644-8B2D-291087724BA9_d0e148171_href.png Binary file Symbian3/SDK/Source/GUID-F4203C60-EB2A-4644-8B2D-291087724BA9_d0e148171_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita --- a/Symbian3/SDK/Source/GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita Tue Jul 20 12:00:49 2010 +0100 @@ -28,13 +28,13 @@ indicate the division of Planes.

      Planes in the Communications Framework - +

      The following diagram overlays the Planes with an example series of Layers

      Planes and Layers in the Communications Framework - +

      • Data Plane

        • @@ -63,7 +63,7 @@ Data Plane corresponds to the Sockets Server API: RSocket.

        The following diagram shows the thread divide.

        Data Plane in the Communications Framework - +

        Features

        The Data Plane:

        • exchanges data with remote peers and uses data transfer protocols

          • diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F46D5A5B-EC44-53B0-9A11-886735B28610.dita --- a/Symbian3/SDK/Source/GUID-F46D5A5B-EC44-53B0-9A11-886735B28610.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F46D5A5B-EC44-53B0-9A11-886735B28610.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,87 +1,81 @@ - - - - - -How to -use the modifiable pointer descriptor — TPtrModifiable pointer descriptors are useful for referencing strings -or data which can be accessed and changed. -
            -

          • For text data, it is -usual to construct a TPtr type and allow the appropriate -variant, either a TPtr or a TPtrC to be -selected at build time.

            • -

          • For binary data, an -explicit TPtr8 is used.

            • -

          • It is rare to use an -explicit TPtr16.

            • -
          -
          Constructing a TPtr

          A modifiable pointer descriptor -can be constructed in a number of ways:

            -

          • another modifiable pointer -descriptor.

            • -

          • from a non-modifiable -buffer descriptor using the Des() function

            • -

          • from an explicit pointer -into memory and specifying a maximum length.

            • -

          • from an explicit pointer -into memory and specifying the length of the data and a maximum length.

            • -

          The following code fragment constructs a TPtr to -represent the data already represented by another TPtr:

          TPtr ptr1; -... -TPtr ptr2(ptr1); -...

          The following code fragment constructs a TPtr for -a non-modifiable buffer descriptor, a TBufC<TInt>, using -the Des() function. Data that would normally be unmodifiable -through the TBufC<TInt> can be changed through the TPtr.

          The -source are literals which are converted to descriptor type.

          _LIT(KText,"Hello World!"); -_LIT(KExtraText," & Hi"); -... -TBufC<16> buf1(KText); -... -TPtr ptr = buf1.Des(); -... -ptr.Delete((ptr.Length()-1),1); -ptr.Append(KExtraText);

          Define a TText area -initialised to contain the string "Have a nice day":

          The following -code fragments show the construction of a TPtr using a pointer -and specifying a length and a maximum length. This technique is not commonly -used. Literals are a much better way of defining string constants.

          TText str[16] = {'H', 'a', 'v', 'e', ' ', 'a', - ' ', 'n', 'i', 'c', 'e', - ' ', 'd', 'a', 'y', '\0'}; TPtr ptr(&str[0],15,16);

          The -descriptor ptr represents the data in str and -is constructed to have a current length of 15 (the length of the text, excluding -the zero terminator) and a maximum length of 16 (the actual length of str). -Once the descriptor has been constructed, it has no further use for the zero -terminator.

          TPtr ptr(&str[0],15,16);
          -
          Replacing data through the TPtr

          Data can be completely -replaced using the assignment operator or the Copy() function.:

          _LIT(KText,"Hi there"); -... -ptr = KText; -... -ptr.Copy(KText);

          Note the use of the _LIT macro -to define the source string. A literal is converted into a descriptor type.

          The -length of ptr is now 8 but the maximum length remains unchanged. -The size depends on the build variant. In a non-Unicode build, this is 8 but -in a Unicode build, this becomes 16 (two bytes for every character).

          -
          Changing the length of data

          The length of the data -represented can be changed.

          _LIT(KText,"Hi there"); -... -ptr = KText; -ptr.SetLength(2); -ptr.Zero(); -

          For example, after ptr.SetLength(2), the -descriptor represents the string "Hi". The length can even be set to zero -so that after ptr.Zero(), the descriptor represents no data. -Nevertheless, the maximum length remains unchanged.

          -           - -Literal Descriptors - + + + + + +How to use the modifiable pointer descriptor — TPtrModifiable pointer descriptors are useful for referencing +strings or data which can be accessed and changed. +
            +

          • For text data, +it is usual to construct a TPtr type and allow the +appropriate variant, either a TPtr or a TPtrC to be selected at build time.

            • +

          • For binary data, +an explicit TPtr8 is used.

            • +

          • It is rare to +use an explicit TPtr16.

            • +
          +
          Constructing +a TPtr

          A modifiable pointer descriptor can be constructed +in a number of ways:

            +

          • another modifiable +pointer descriptor.

            • +

          • from a non-modifiable +buffer descriptor using the Des() function

            • +

          • from an explicit +pointer into memory and specifying a maximum length.

            • +

          • from an explicit +pointer into memory and specifying the length of the data and a maximum +length.

            • +

          The following code fragment constructs a TPtr to represent the data already represented by another TPtr:

          TPtr ptr1; +... +TPtr ptr2(ptr1); +...

          The following code fragment constructs a TPtr for a non-modifiable buffer descriptor, a TBufC<TInt>, using the Des() function. Data that would normally +be unmodifiable through the TBufC<TInt> can be +changed through the TPtr.

          The source are literals +which are converted to descriptor type.

          _LIT(KText,"Hello World!"); +_LIT(KExtraText," & Hi"); +... +TBufC<16> buf1(KText); +... +TPtr ptr = buf1.Des(); +... +ptr.Delete((ptr.Length()-1),1); +ptr.Append(KExtraText);

          Define a TText area initialised to contain the string "Have a nice day":

          The following code fragments show the construction of a TPtr using a pointer and specifying a length and a maximum length. This +technique is not commonly used. Literals are a much better way of +defining string constants.

          TText str[16] = {'H', 'a', 'v', 'e', ' ', 'a', + ' ', 'n', 'i', 'c', 'e', + ' ', 'd', 'a', 'y', '\0'}; TPtr ptr(&str[0],15,16);

          The descriptor ptr represents the data in str and is constructed to have a current length of 15 (the +length of the text, excluding the zero terminator) and a maximum length +of 16 (the actual length of str). Once the descriptor +has been constructed, it has no further use for the zero terminator.

          TPtr ptr(&str[0],15,16);
          +
          Replacing +data through the TPtr

          Data can be completely replaced using +the assignment operator or the Copy() function.:

          _LIT(KText,"Hi there"); +... +ptr = KText; +... +ptr.Copy(KText);

          Note the use of the _LIT macro to define the source string. A literal is converted into a +descriptor type.

          The length of ptr is now +8 but the maximum length remains unchanged. The size depends on the +build variant. In a non-Unicode build, this is 8 but in a Unicode +build, this becomes 16 (two bytes for every character).

          +
          Changing +the length of data

          The length of the data represented can +be changed.

          _LIT(KText,"Hi there"); +... +ptr = KText; +ptr.SetLength(2); +ptr.Zero(); +

          For example, after ptr.SetLength(2), the descriptor represents the string "Hi". The length can even +be set to zero so that after ptr.Zero(), the descriptor +represents no data. Nevertheless, the maximum length remains unchanged.

          +           +Literal +Descriptors           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F46E4F89-B9ED-5A4A-B812-B605B925D0C0.dita --- a/Symbian3/SDK/Source/GUID-F46E4F89-B9ED-5A4A-B812-B605B925D0C0.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F46E4F89-B9ED-5A4A-B812-B605B925D0C0.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,47 +1,202 @@ - - - - - -How to use the audio convert utility
          Overview

          Audio convert utility is used to convert audio clips contained in files or descriptors to other formats using the default codecs provided by MMF. This functionality is implemented by the CMdaAudioConvertUtility class.

          Description

          Using a audio converter utility involves the following tasks:

          • Construct and open converter utility object

          • Configure conversion parameters

          • Convert audio clip

          • Change conversion position and crop audio data

          • Custom commands

          Construct and open converter utility object

          The MMF provides a utility class called CMdaAudioConverterUtility. Using this class, you can convert audio clips from one format to another. The CMdaAudioConverterUtility::NewL() function need to be used to construct an object of this utility class, with the following arguments:

          • An object of the class, which inherits the MMdaObjectStateChangeObserver class to receive state change notifications from the converter object.

          • Client's relative priority, which can be EMdaPriorityMin, EMdaPriorityNormal or EMdaPriorityMax.

          • An object of TMdaPriorityPreference specifying the behaviour, if a higher priority client takes over the device.

          The following code shows how the client application CClientApp inherits the MMdaObjectStateChangeObserver and creates the audio converter utility object:

          class CClientApp : public CBase, MMdaObjectStateChangeObserver - { -public: - void CClientApp(); -protected: - - // from MMdaObjectStateChangeObserver - virtual void MoscoStateChangeEvent(CBase *aObject, TInt aPreviousState, TInt aCurrentState, TInt aErrorCode); - -protected: - CMdaAudioConverterUtility* iConverter; - }; - -void CClientApp() -{ - iConverter = CMdaAudioConverterUtility::NewL(*this, EMdaPriorityNormal, - EMdaPriorityPreferenceTimeAndQuality); -} -

          Once the audio converter utility object is constructed, you can open an audio clip for conversion using the function CMdaAudioConverterUtility::OpenL(). You can use the following versions of this function:

          • To open an existing audio file and append the converted audio data to another file, use the following version:

            OpenL(const TDesC& aPrimaryFile, const TdesC& aSecondaryFile);

            Where, aPrimaryFile and aSecondaryFile are used to specify the source and destination audio file names.

          • To open existing audio file and store the converted audio data to either a file or a descriptor, use the following version:

            OpenL(const TdesC& aPrimaryFile - TMdaClipLocation* aLocation, - TMdaClipFormat* aFormat, - TMdaPackage* aArg1 = NULL, - TMdaPackage* aArg2 = NULL); -

            Where, aPrimaryFile specifies the source audio file names. The aLocation, aFormat, aArg1 and aArg2 are used to specify the target location for the converted audio data, target audio format, codec for the target audio and target audio settings.

          • To open audio data either from a file or a descriptor source and store the resulting data to either a file or descriptor, use the following version:

            OpenL(TmdaClipLocation* aPriLocation - TMdaClipLocation* aSecLocation, - TMdaClipFormat* aPriFormat, - TMdaClipFormat* aSecFormat, - TMdaPackage* aPriArg1 = NULL, - TMdaPackage* aPriArg2 = NULL, - TMdaPackage* aSecArg1 = NULL, - TMdaPackage* aSecArg2 = NULL); -

            Where, aPriLocation and aPriLocation specifies the source and destination audio data locations. The aPriFormat and aSecFormat specifies the audio format of the source and target audio data. The aPriArg1 and aPriArg2 specifies codec and settings for the source audio data. Whereas, the aSecArg1 and aSecArg2 specifies the codec and settings for the target audio data.

          Note: It is recommended to use the first version of OpenL to specify source and destination audio file location. The arguments for the other versions are deprecated.

          The following code uses the first version of OpenL to specify source and destination audio location:

          TFileName fromFilename = _L("C:\\rectest2.wav"); -TFileName toFilename = _L("C:\\rectest2.wav"); - -iConverter-&gt;OpenL(&fromFilename, &toFilename); -

          Once the converter calls the CMdaAudioConverterUtility::OpenL() function, the callback function MMdaObjectStateChangeObserver::MoscoStateChangeEvent() will notify the client application about the change in state of the object.

          Configure conversion parameters

          The configuration parameters can be broadly classified into four categories as shown below:

          Set recorded file length

          You can control the size settings of a recorded file. This is handled by the SetMaxWriteLength() function that sets the maximum number of bytes that can be written to a recorded audio clip. The SetMaxWriteLength() function is provided so that converters can limit the amount of file storage or memory that should be allocated. If the maximum limit is reached, MMF stops recording and notifies the client application.

          The following code sets the maximum number of bytes to 800:

          iConverter->SetMaxWriteLength(800);

          Formats and Codecs

          You can report and set formats and codecs for audio data that is already open. The four methods related to DataTypes (codecs) enable you to retrieve a list of supported codecs for the current data format, set a new codec to use or determine which codec is currently in use. A further three methods are provided to query and set the audio format to use.

          Codec related actions:

          • To get the data type of the destination audio clip, use the DestinationDataTypeL() function.

          • To set the data type of the destination audio clip, use the SetDestinationDataTypeL() function.

          • To get a list of supported data types for the conversion destination, use the GetSupportedDestinationDataTypesL() function.

          • To get the data type of the source audio clip, use the SourceDataTypeL() function.

          Data format related actions:

          • To get the format of the destination audio clip, use the DestinationFormatL() function.

          • To set the format of the destination audio clip, use the SetDestinationFormatL() function.

          • To get the format of the source audio clip, use the SourceFormatL() function.

          Note: It is only possible to report the format and codec used by the source audio and cannot be changed.

          Bit and sample rates

          You can report and set bit and sample rates as required by specific codecs.

          Methods to control the bit rate of audio data:

          • To get a list of supported bit rates to the conversion destination, use the GetSupportedConversionBitRatesL() function.

          • To get the bit rate of the destination audio clip, use the DestinationBitRateL() function.

          • To set the bit rate of the destination audio clip, use the SetDestinationBitRateL() function. The bit rate must be one of the supported bit rates of the audio target. Use the GetSupportedConversionBitRatesL() function to retrieve a list of supported bit rates.

          • To get the bit rate of the source audio clip, use the SourceBitRateL() function.

          Note: None of the default codecs provided in the MMF support the use of bit rates. These methods are provided to enable the creation of additional codecs that might require bit rate information, such as the audio format MP3.

          Methods for controlling the sampling rate of audio data:

          • To get a list of supported conversion sample rates, use the GetSupportedConversionSampleRatesL() function. The list of sample rates is used by the conversion destination.

          • To get the sample rate of the conversion destination, use the DestinationSampleRateL() function.

          • To set the sample rate for the conversion destination, use the SetDestinationSampleRateL() function. The sample rate must be one of the supported sample rates of the audio target. Use the GetSupportedConversionSampleRatesL() function to retrieve a list of supported sample rates.

          • To get the sample rate of the source audio clip, use the SourceSampleRateL() function.

          Note: It is only possible to report the bit rate or sample rate used by the source audio and cannot be changed.

          Balance

          You can report and set the audio mode (mono or stereo).

          • To get a list of the supported number of channels for conversion, use the GetSupportedConversionNumberOfChannelsL() function.

          • To get the number of channels the destination audio clip contains, use the DestinationNumberOfChannelsL() function.

          • To set the number of channels the destination audio clip contains, use the SetDestinationNumberOfChannelsL() function. The number of channels must be one of the values returned by GetSupportedConversionNumberOfChannelsL().

          • To get the number of channels used by the conversion source, use the SourceNumberOfChannelsL() function.

          Note: It is only possible to report the number of supported channels for the source audio and cannot be changed.

          Convert audio clip

          Several methods are provided in CMdaAudioConvertUtility to enable the conversion of audio data. The specific functions to convert and perform related tasks are as follows:

          • To start converting audio data from the current position within the audio source and writing the converted data to a play window within the destination file, use the ConvertL() function.

          • To stop audio conversion, use the Stop() function. The positions within the audio source and destination are maintained to handle subsequent ConvertL() statements.

          • To stop audio conversion and close all related controllers, use the Close() function.

          Change conversion position and crop audio data

          It is possible to crop the audio clip from the current position to the end of the clip or from the begging to the current position as illustrated below:

          • To crop the current clip from the current position, use the CropL() function. The remainder of the clip is discarded. The effects of the function cannot be undone. The function is synchronous and can leave if there is a problem. The leave code depends on the configuration settings.

          • To crop the audio clip from the start of the file to the current position, use the CropFromBeginningL() function. The audio data prior to the current position is discarded. The effects of the function cannot be undone. The function is synchronous and can leave if there is a problem. The leave code depends on the configuration settings.

          To retrieve the current position of the audio clip or move the position to the desired location use the following functions:

          • To get the current position in the audio clip, use the Position() function. The position is defined in terms of a time interval measured from the beginning of the audio sample data.

          • To set the current position in the audio clip, use the SetPosition() function. A subsequent call to the ConvertL() function starts conversion from this new position.

          Custom commands

          • To send a raw custom command synchronously to the controller or to allow data to be returned from the controller, use the CustomCommandSync() function.

          • To send a raw custom command asynchronously to the controller or to allows data to be returned from the controller, use the CustomCommandAsync() function.

          See Also

          How to use the audio player utility

          How to use audio recorder utility

          How to use the audio tone player utility

          \ No newline at end of file + + + + + +How to use the audio convert utility +
          Overview

          Audio convert utility is used to convert audio clips contained +in files or descriptors to other formats using the default codecs +provided by MMF. This functionality is implemented by the CMdaAudioConvertUtility class.

          +
          Description

          Using a audio converter utility +involves the following tasks:

            +

          • Construct and open converter utility object

            • +

          • Configure conversion parameters

            • +

          • Convert audio clip

            • +

          • Change conversion position and crop audio data

            • +

          • Custom commands

            • +

          Construct and open +converter utility object

          The MMF provides a utility class +called CMdaAudioConverterUtility. Using this class, +you can convert audio clips from one format to another. The CMdaAudioConverterUtility::NewL() function need to be used +to construct an object of this utility class, with the following arguments:

            +

          • An object of +the class, which inherits the MMdaObjectStateChangeObserver class to receive state change notifications from the converter object.

            • +

          • Client's relative +priority, which can be EMdaPriorityMin, EMdaPriorityNormal or EMdaPriorityMax.

            • +

          • An object of TMdaPriorityPreference specifying the behaviour, if a higher +priority client takes over the device.

            • +

          The following code shows how the client application CClientApp inherits the MMdaObjectStateChangeObserver and creates the audio converter utility object:

          class CClientApp : public CBase, MMdaObjectStateChangeObserver + { +public: + void CClientApp(); +protected: + + // from MMdaObjectStateChangeObserver + virtual void MoscoStateChangeEvent(CBase *aObject, TInt aPreviousState, TInt aCurrentState, TInt aErrorCode); + +protected: + CMdaAudioConverterUtility* iConverter; + }; + +void CClientApp() +{ + iConverter = CMdaAudioConverterUtility::NewL(*this, EMdaPriorityNormal, + EMdaPriorityPreferenceTimeAndQuality); +} +

          Once the audio converter utility object is constructed, +you can open an audio clip for conversion using the function CMdaAudioConverterUtility::OpenL(). You can use the following +versions of this function:

            +

          • To open an existing +audio file and append the converted audio data to another file, use +the following version:

            OpenL(const TDesC& aPrimaryFile, const TdesC& aSecondaryFile);

            Where, aPrimaryFile and aSecondaryFile are used to specify the source and destination audio file names.

            • +

          • To open existing +audio file and store the converted audio data to either a file or +a descriptor, use the following version:

            OpenL(const TdesC& aPrimaryFile + TMdaClipLocation* aLocation, + TMdaClipFormat* aFormat, + TMdaPackage* aArg1 = NULL, + TMdaPackage* aArg2 = NULL); +

            Where, aPrimaryFile specifies the +source audio file names. The aLocation, aFormat, aArg1 and aArg2 are used to specify +the target location for the converted audio data, target audio format, +codec for the target audio and target audio settings.

            • +

          • To open audio +data either from a file or a descriptor source and store the resulting +data to either a file or descriptor, use the following version:

            OpenL(TmdaClipLocation* aPriLocation + TMdaClipLocation* aSecLocation, + TMdaClipFormat* aPriFormat, + TMdaClipFormat* aSecFormat, + TMdaPackage* aPriArg1 = NULL, + TMdaPackage* aPriArg2 = NULL, + TMdaPackage* aSecArg1 = NULL, + TMdaPackage* aSecArg2 = NULL); +

            Where, aPriLocation and aPriLocation specifies the source and destination audio data locations. The aPriFormat and aSecFormat specifies the +audio format of the source and target audio data. The aPriArg1 and aPriArg2 specifies codec and settings for the +source audio data. Whereas, the aSecArg1 and aSecArg2 specifies the codec and settings for the target +audio data.

            • +

          Note: It is recommended to use the first version +of OpenL to specify source and destination audio +file location. The arguments for the other versions are deprecated.

          The following code uses the first version of OpenL to specify +source and destination audio location:

          TFileName fromFilename = _L("C:\\rectest2.wav"); +TFileName toFilename = _L("C:\\rectest2.wav"); + +iConverter-&gt;OpenL(&fromFilename, &toFilename); +

          Once the converter calls the CMdaAudioConverterUtility::OpenL() function, the callback function MMdaObjectStateChangeObserver::MoscoStateChangeEvent() will notify the client application about the change in state of +the object.

          Configure conversion +parameters

          The configuration parameters can be broadly +classified into four categories as shown below:

          Set recorded file length

          You can control the size +settings of a recorded file. This is handled by the SetMaxWriteLength() function that sets the maximum number of bytes that can be written +to a recorded audio clip. The SetMaxWriteLength() function is provided so that converters can limit the amount of +file storage or memory that should be allocated. If the maximum limit +is reached, MMF stops recording and notifies the client application.

          The following code sets the maximum number of bytes to 800:

          iConverter->SetMaxWriteLength(800);

          Formats and Codecs

          You can report and set formats +and codecs for audio data that is already open. The four methods related +to DataTypes (codecs) enable you to retrieve a list of supported codecs +for the current data format, set a new codec to use or determine which +codec is currently in use. A further three methods are provided to +query and set the audio format to use.

          Codec related actions:

            +

          • To get the data +type of the destination audio clip, use the DestinationDataTypeL() function.

            • +

          • To set the data +type of the destination audio clip, use the SetDestinationDataTypeL() function.

            • +

          • To get a list +of supported data types for the conversion destination, use the GetSupportedDestinationDataTypesL() function.

            • +

          • To get the data +type of the source audio clip, use the SourceDataTypeL() function.

            • +

          Data format related actions:

            +

          • To get the format +of the destination audio clip, use the DestinationFormatL() function.

            • +

          • To set the format +of the destination audio clip, use the SetDestinationFormatL() function.

            • +

          • To get the format +of the source audio clip, use the SourceFormatL() function.

            • +

          Note: It is only possible to report the format and +codec used by the source audio and cannot be changed.

          Bit and sample rates

          You can report and set bit and +sample rates as required by specific codecs.

          Methods to control +the bit rate of audio data:

            +

          • To get a list +of supported bit rates to the conversion destination, use the GetSupportedConversionBitRatesL() function.

            • +

          • To get the bit +rate of the destination audio clip, use the DestinationBitRateL() function.

            • +

          • To set the bit +rate of the destination audio clip, use the SetDestinationBitRateL() function. The bit rate must be one of the supported bit rates of +the audio target. Use the GetSupportedConversionBitRatesL() function to retrieve a list of supported bit rates.

            • +

          • To get the bit +rate of the source audio clip, use the SourceBitRateL() function.

            • +

          Note: None of the default codecs provided in the +MMF support the use of bit rates. These methods are provided to enable +the creation of additional codecs that might require bit rate information, +such as the audio format MP3.

          Methods for controlling the +sampling rate of audio data:

            +

          • To get a list +of supported conversion sample rates, use the GetSupportedConversionSampleRatesL() function. The list of sample rates is used by the conversion destination.

            • +

          • To get the sample +rate of the conversion destination, use the DestinationSampleRateL() function.

            • +

          • To set the sample +rate for the conversion destination, use the SetDestinationSampleRateL() function. The sample rate must be one of the supported sample rates +of the audio target. Use the GetSupportedConversionSampleRatesL() function to retrieve a list of supported sample rates.

            • +

          • To get the sample +rate of the source audio clip, use the SourceSampleRateL() function.

            • +

          Note: It is only possible to report the bit rate +or sample rate used by the source audio and cannot be changed.

          Balance

          You can report and set the audio mode (mono +or stereo).

            +

          • To get a list +of the supported number of channels for conversion, use the GetSupportedConversionNumberOfChannelsL() function.

            • +

          • To get the number +of channels the destination audio clip contains, use the DestinationNumberOfChannelsL() function.

            • +

          • To set the number +of channels the destination audio clip contains, use the SetDestinationNumberOfChannelsL() function. The number +of channels must be one of the values returned by GetSupportedConversionNumberOfChannelsL().

            • +

          • To get the number +of channels used by the conversion source, use the SourceNumberOfChannelsL() function.

            • +

          Note: It is only possible to report the number of +supported channels for the source audio and cannot be changed.

          Convert audio clip

          Several methods are provided in CMdaAudioConvertUtility to enable the conversion of audio data. The specific functions to +convert and perform related tasks are as follows:

            +

          • To start converting +audio data from the current position within the audio source and writing +the converted data to a play window within the destination file, use +the ConvertL() function.

            • +

          • To stop audio +conversion, use the Stop() function. The positions +within the audio source and destination are maintained to handle subsequent ConvertL() statements.

            • +

          • To stop audio +conversion and close all related controllers, use the Close() function.

            • +

          Change conversion +position and crop audio data

          It is possible to crop the +audio clip from the current position to the end of the clip or from +the begging to the current position as illustrated below:

            +

          • To crop the +current clip from the current position, use the CropL() function. The remainder of the clip is discarded. The effects of +the function cannot be undone. The function is synchronous and can +leave if there is a problem. The leave code depends on the configuration +settings.

            • +

          • To crop the +audio clip from the start of the file to the current position, use +the CropFromBeginningL() function. The audio data +prior to the current position is discarded. The effects of the function +cannot be undone. The function is synchronous and can leave if there +is a problem. The leave code depends on the configuration settings.

            • +

          To retrieve the current position of the audio clip or move +the position to the desired location use the following functions:

            +

          • To get the current +position in the audio clip, use the Position() function. +The position is defined in terms of a time interval measured from +the beginning of the audio sample data.

            • +

          • To set the current +position in the audio clip, use the SetPosition() function. A subsequent call to the ConvertL() function starts conversion from this new position.

            • +

          Custom commands

            +

          • To send a raw +custom command synchronously to the controller or to allow data to +be returned from the controller, use the CustomCommandSync() function.

            • +

          • To send a raw +custom command asynchronously to the controller or to allows data +to be returned from the controller, use the CustomCommandAsync() function.

            • +
          +
          See Also

          How to use the audio +tone player utility

          +           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F4C3DDE1-F7D3-5256-BABD-34759DCA57BF.dita --- a/Symbian3/SDK/Source/GUID-F4C3DDE1-F7D3-5256-BABD-34759DCA57BF.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - - tidy

          abld [ test ] tidy [-k] [-v] [ platform ] [ build [ program ] ]

          This command removes releasables defined by .mmp files which are listed with the tidy attribute in your component’s description file.

          The command can be run following a build to remove any releasables which are no longer required now that the build has completed.

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F4E64499-57CB-5E4A-AAD7-439191BF5E0F.dita --- a/Symbian3/SDK/Source/GUID-F4E64499-57CB-5E4A-AAD7-439191BF5E0F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F4E64499-57CB-5E4A-AAD7-439191BF5E0F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Launching Zsh

          This topic describes how to launch Zsh using a Telnet session on a PC. You can use the following methods:

          • Emulator as a Telnet server

          • Device (phone) as a Telnet server

          Emulator as a Telnet server

          To launch Zsh (using a Telnet session) on a PC using an emulator as a Telnet server, perform the following steps:

          1. Start the emulator by selecting Extras > Eshell.

          2. Run the following command:

            TelnetD

            Note: Before running the Telnetd command, ensure that Zsh.exe and the external command executables such as find.exe, grep.exe, ps.exe, unzip.exe and zip.exe are present in a sys/bin folder. You can copy these files from the /epoc32/release/winscw/<udeb/urel > directory.

          3. The IP address of the Telnet server running on the emulator is displayed, as shown in the following image:

            IP configuration -

          4. In a scenario where multiple IP addresses are listed, use the ping command from the PC console to identify the IP address that is accessible from the PC, as shown in the following image.

            +

          5. In a scenario where multiple IP addresses are listed, use the ping command from the PC console to identify the IP address that is accessible from the PC, as shown in the following image.

            Using the ping command -

          6. Open command prompt on a Windows PC.

          7. Run the following command by typing the IP address (associated with the emulator) that is accessible from the PC:

            telnet <ip-address of the emulator>

            The emulator and the Telnet client console prompts for an alphanumeric key to authenticate the session.

          8. Type the same alphanumeric key (which is upto eight characters) both on the emulator console window and also on the Telnet client console.

            Zsh is successfully launched on the PC.

          Device (phone) as a Telnet server

          After establishing a connection between a device and the PC using one of the methods described in the Device Setup section, you can launch Zsh. To launch Zsh (using a Telnet session) on a PC using a device as a Telnet server, perform the following steps:

          Note: Before starting a Telnet session, ensure that TelnetD and Zsh are installed on the device.

          1. Start TelnetD on the device by clicking the Zsh icon. The IP address of the Telnet server running on the device is displayed.

          2. In a scenario where multiple IP addresses are listed, use the ping command from the PC console to identify the IP address of the device that is accessible from the PC.

          3. Open command prompt on a Windows PC.

          4. Run the following command, by typing the IP address (associated with the device) that is accessible from the PC:

            Telnet <ip-address of the device>

            The device and the Telnet client console prompts for an alphanumeric key to authenticate the session.

          5. Type the same alphanumeric key (which is upto eight characters) both on the device console window and also on the Telnet client console.

            Zsh is successfully launched on the PC. The following image shows the result of this command on a Linux PC:

          Emulator Setup Device Setup Using TelnetD and Zsh           \ No newline at end of file +

        • Open command prompt on a Windows PC.

        • Run the following command by typing the IP address (associated with the emulator) that is accessible from the PC:

          telnet <ip-address of the emulator>

          The emulator and the Telnet client console prompts for an alphanumeric key to authenticate the session.

        • Type the same alphanumeric key (which is upto eight characters) both on the emulator console window and also on the Telnet client console.

          Zsh is successfully launched on the PC.

          • Device (phone) as a Telnet server

          After establishing a connection between a device and the PC using one of the methods described in the Device Setup section, you can launch Zsh. To launch Zsh (using a Telnet session) on a PC using a device as a Telnet server, perform the following steps:

          Note: Before starting a Telnet session, ensure that TelnetD and Zsh are installed on the device.

          1. Start TelnetD on the device by clicking the Zsh icon. The IP address of the Telnet server running on the device is displayed.

          2. In a scenario where multiple IP addresses are listed, use the ping command from the PC console to identify the IP address of the device that is accessible from the PC.

          3. Open command prompt on a Windows PC.

          4. Run the following command, by typing the IP address (associated with the device) that is accessible from the PC:

            Telnet <ip-address of the device>

            The device and the Telnet client console prompts for an alphanumeric key to authenticate the session.

          5. Type the same alphanumeric key (which is upto eight characters) both on the device console window and also on the Telnet client console.

            Zsh is successfully launched on the PC. The following image shows the result of this command on a Linux PC:

          Emulator Setup Device Setup Using TelnetD and Zsh           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F4F3A37A-AB0C-47B8-A538-C05F1CA73BF3.dita --- a/Symbian3/SDK/Source/GUID-F4F3A37A-AB0C-47B8-A538-C05F1CA73BF3.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F4F3A37A-AB0C-47B8-A538-C05F1CA73BF3.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ configurations depending on the functionality requirements, languages, and so on. Also, indirect strokes and gestures provide flexibility reducing the need for physical buttons.

          - +

        • Intuitive - Manipulating objects directly by touching them is natural and intuitive. Touch interface allows better real-time experience diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F59B0B89-94C3-4E0B-BF87-2AE5B3811F59.dita --- a/Symbian3/SDK/Source/GUID-F59B0B89-94C3-4E0B-BF87-2AE5B3811F59.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F59B0B89-94C3-4E0B-BF87-2AE5B3811F59.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,6 +24,6 @@

        Smiley picker in portrait and landscape modes - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F5A82F61-B93A-5652-93A4-B9CE877B4D4A_d0e332635_href.png Binary file Symbian3/SDK/Source/GUID-F5A82F61-B93A-5652-93A4-B9CE877B4D4A_d0e332635_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F5A82F61-B93A-5652-93A4-B9CE877B4D4A_d0e339101_href.png Binary file Symbian3/SDK/Source/GUID-F5A82F61-B93A-5652-93A4-B9CE877B4D4A_d0e339101_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F5B58B20-B85C-5BCD-B1EB-69CCE42DE6BB_d0e176051_href.png Binary file Symbian3/SDK/Source/GUID-F5B58B20-B85C-5BCD-B1EB-69CCE42DE6BB_d0e176051_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F5B58B20-B85C-5BCD-B1EB-69CCE42DE6BB_d0e181076_href.png Binary file Symbian3/SDK/Source/GUID-F5B58B20-B85C-5BCD-B1EB-69CCE42DE6BB_d0e181076_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F5D49215-B34A-5FCC-A7E1-0AF3275694B3.dita --- a/Symbian3/SDK/Source/GUID-F5D49215-B34A-5FCC-A7E1-0AF3275694B3.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,141 +0,0 @@ - - - - - -GCCXML -build target -

        The GCCXML build target generates an XML description of the project and -the program. This XML is intended to be parsed by other development and program -analysis tools. The XML is generated using the GCC-XML (http://www.gccxml.org) tool, which is distributed -on kits in the epoc32\tools\ directory.

        -

        To execute a GCCXML build, use the abld command as -follows:

        -

        abld build gccxml [udeb/urel]

        -

        GCCXML is available as a target for all projects that can be built for -an ARM target (this is assumed by the build tools unless the bld.inf file -specifies otherwise with a prj_platforms statement.)

        -

        The build of a Symbian platform component for the GCCXML platform results -in three actions:

        -
          -

        1. The GCC-XML tool is -called on each source file used in the build of a component's binary. An XML -file is output as a result.

          The GCC-XML output format is not yet extensively -documented: see http://www.gccxml.org/HTML/FAQ.html for -the latest information.

          2. -

        2. The tool chain also -generates an XML file describing some elements of the component's .mmp file.

          The -XML format is described below.

          3. -

        3. The tool chain packages -the output from steps 1 and 2 into a zip file named <project-name>.gxp. -The file is stored in epoc32\release\gccxml\[udeb|urel]\.

          4. -
        -
        Format of <project>.mmp.xml

        A GCCXML build creates -an XML representation of the project's mmp file named <project>.mmp.xml. -Not all the mmp file statements are represented in the XML.

        The following -XML elements and attributes are used:

      - - - -

      Element

      -

      Attribute

      -

      Description

      -       - -

      mmpInfo

      -

       -

      Top-level wrapper element

      -       - -

      mmp

      -

      path

      -

      Full path of the .mmp file

      -       - -

      target

      -

      name

      -

      TARGET statement value

      -       - -

       -

      type

      -

      TARGETTYPE statement value

      -       - - -

      path

      -

      TARGETPATH statement value

      -       - -

      abi

      -

      type

      -

      Deduced ABI e.g. ARM4

      -       - -

      linkas

      -

      name

      -

      LINKAS statement value

      -       - -

      uids

      -

      u0

      -

      1st UID of the executable

      -       - -

       -

      u1

      -

      2nd UID of the executable (from the UID statement)

      -       - -

       -

      u2

      -

      3rd UID of the executable (from the UID statement)

      -       - -

      defFile

      -

      path

      -

      Full path of the .def file

      -       - -

      libs

      -

       -

      Wrapper for lib elements that describe the libraries the project -links to

      -       - -

      lib

      -

      name

      -

      Name of the library

      -       - -

       -

      type

      -

      For standard libraries specified by the LIBRARY keyword -this is not used.

      For a stub library inserted by the build processor, -this is "First".

      For libraries specified by the ASSPLIBRARY statement, -this is "ASSP".

      Note: "ASSP" is applicable only for Symbian -platform versions prior to v9.1. Since v9.1, it is not a valid library type.

      For -libraries specified by the STATICLIBRARY statement, this -is "Static".

      -       - -

      sourceFile

      -

      name

      -

      Source file name

      -       - - -

      path

      -

      Path to the source file

      -       - - -

      The population of some of attributes is dependent on the type and -format of the component being built.

      -       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F64B88E0-49DA-5563-896E-29BAB8A244C9.dita --- a/Symbian3/SDK/Source/GUID-F64B88E0-49DA-5563-896E-29BAB8A244C9.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F64B88E0-49DA-5563-896E-29BAB8A244C9.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,65 +1,59 @@ - - - - - -HelloWorld: -A simple GUI application with a single viewThis example demonstrates a simple application using a GUI with -a single view. -
      Download

      Click on the following link to download -the example: HelloWorldGUI.zip

      Click: browse to view the example code.

      -
      Class Summary

      CEikApplication

      CEikDocument

      CEikAppUi

      CCoeControl

      -
      Design and implementation

      This application consists -of 4 classes:

        -

      • Application class derived -from CEikApplication.

        • -

      • Document class derived -from CEikDocument.

        • -

      • AppUi class derived -from CEikAppUi.

        • -

      • AppView class derived -from CCoeControl.

        • -

      E32Main() marks the entry point to the example. -It calls EikStart::RunApplication() to create a new application -instance. The UI framework then calls CExampleApplication::AppDllUid() to -obtain the application's UID. The UID returned must match the second value -defined in the project definition file.

      Once the application is created, -the UI framework calls CExampleApplication::CreateDocumentL() to -create an instance of the document class. CreateDocumentL() internally -calls the constructor of the document class and passes the supplied reference -to the constructor initialisation list. The document has no real work to do -in this simple GUI application.

      As soon as the document has been created -the UI framework creates an instance of the application UI (appUI). The appUI -class is an instance of a CEikAppUi -derived class and -this class takes care of user interaction.

      AppUI creation uses two -phase construction where first CExampleDocument::CreateAppUiL() is -called and then the framework calls the second phase constructor of the appUI -class. CExampleAppUi::ConstructL() creates and owns the view. -User commands are handled by the CExampleAppUi::HandleCommandL() method.

      The -app view class is used to draw the view. The view in this example consists -of a simple outline rectangle with text drawn in the middle.

      The example -contains a resource file HelloWorld.rss which defines -resource information. This includes a menubar with four menu items, an icon -and caption.

      HelloWorld.hrh defines the menu -command IDs and HelloWorld.pkg file is the source file -used for installation file (SIS file) generation.

      -
      Building and configuring

      Steps to build the example:

        -

      • You can build the example -from your IDE or the command line.

        If you use an IDE, import the bld.inf file -of the example into your IDE, and use the build command of the IDE.

        If -you use the command line, open a command prompt, and set the current directory -to the source code directory of the example. You can then build the example -with the SBSv1 build tools with the following commands:

        bldmake -bldfiles

        abld build

        How to use bldmake and How to use abld describe -how to use the SBSv1 build tools.

        • -

      • For the emulator, the -example builds an executable called helloworld.exe in -the epoc32\release\winscw\<udeb or urel>\ folder.

        • -
      + + + + + +HelloWorld: A simple GUI application with a single viewThis example demonstrates a simple application using a +GUI with a single view. +
      Download

      Click on the following link to +download the example: HelloWorldGUI.zip

      Click: browse to view the example code.

      +
      Class Summary

      CEikApplication

      CEikDocument

      CEikAppUi

      CCoeControl

      +
      Design and implementation

      This application +consists of 4 classes:

        +

      • Application +class derived from CEikApplication.

        • +

      • Document class +derived from CEikDocument.

        • +

      • AppUi class +derived from CEikAppUi.

        • +

      • AppView class +derived from CCoeControl.

        • +

      E32Main() marks the entry point to the +example. It calls EikStart::RunApplication() to create +a new application instance. The UI framework then calls CExampleApplication::AppDllUid() to obtain the application's UID. The UID returned must match the +second value defined in the project definition file.

      Once +the application is created, the UI framework calls CExampleApplication::CreateDocumentL() to create an instance of the document class. CreateDocumentL() internally calls the constructor of the document class and passes +the supplied reference to the constructor initialisation list. The +document has no real work to do in this simple GUI application.

      As soon as the document has been created the UI framework creates +an instance of the application UI (appUI). The appUI class is an instance +of a CEikAppUi -derived class and this class takes +care of user interaction.

      AppUI creation uses two phase construction +where first CExampleDocument::CreateAppUiL() is called +and then the framework calls the second phase constructor of the appUI +class. CExampleAppUi::ConstructL() creates and owns +the view. User commands are handled by the CExampleAppUi::HandleCommandL() method.

      The app view class is used to draw the view. The +view in this example consists of a simple outline rectangle with text +drawn in the middle.

      The example contains a resource file HelloWorld.rss which defines resource information. This +includes a menubar with four menu items, an icon and caption.

      HelloWorld.hrh defines the menu command +IDs and HelloWorld.pkg file is the source file +used for installation file (SIS file) generation.

      +
      Building and configuring

      Steps to build +the example:

        +

      • You can build +the example from your IDE or the command line.

        If you use +an IDE, import the bld.inf file of the example +into your IDE, and use the build command of the IDE.

        If you +use the command line, open a command prompt, and set the current directory +to the source code directory of the example. You can then build the +example with the SBSv1 build tools with the following commands:

        bldmake bldfiles

        abld +build

        • +

      • For the emulator, +the example builds an executable called helloworld.exe in the epoc32\release\winscw\<udeb or urel>\ folder.

        • +
       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita --- a/Symbian3/SDK/Source/GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@ in other packages.

      The Symbian Foundation non-ScreenPlay graphics architecture - +

      The software model is as follows:

        @@ -48,7 +48,7 @@

        The following diagram shows the rendering stack in the non-ScreenPlay variant.

        The rendering stack in the non-ScreenPlay variant - +

        Although DSA provides a solution for applications that require high frame @@ -59,7 +59,7 @@ in this type of use case.

        Example non-uniform memory, non-ScreenPlay hardware model - + The ScreenPlay diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F6780E5A-26DA-5453-B9BE-11039CFA4FFB.dita --- a/Symbian3/SDK/Source/GUID-F6780E5A-26DA-5453-B9BE-11039CFA4FFB.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -Resource file compiled format

        This section describes the binary format of compiled resource files.

        The resource reading API's in can read resources in the legacy Unicode format, as well as the two new formats introduced from v7.0.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F681C857-086F-527A-9946-A91560601658_d0e403679_href.jpg Binary file Symbian3/SDK/Source/GUID-F681C857-086F-527A-9946-A91560601658_d0e403679_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F681C857-086F-527A-9946-A91560601658_d0e407479_href.jpg Binary file Symbian3/SDK/Source/GUID-F681C857-086F-527A-9946-A91560601658_d0e407479_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F68FF4C2-F9DB-5935-9027-9BEC006D031F_d0e324544_href.png Binary file Symbian3/SDK/Source/GUID-F68FF4C2-F9DB-5935-9027-9BEC006D031F_d0e324544_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F68FF4C2-F9DB-5935-9027-9BEC006D031F_d0e331014_href.png Binary file Symbian3/SDK/Source/GUID-F68FF4C2-F9DB-5935-9027-9BEC006D031F_d0e331014_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F6903E31-DF4A-572F-BF2C-65CE618F016E.dita --- a/Symbian3/SDK/Source/GUID-F6903E31-DF4A-572F-BF2C-65CE618F016E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F6903E31-DF4A-572F-BF2C-65CE618F016E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@ containers, one container for each type; i.e. one for threads, one for processes, one for mutexes etc. as shown below.

        - +

        See also:

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F6B5F777-D12F-5913-AECE-047DF8C72F1F.dita --- a/Symbian3/SDK/Source/GUID-F6B5F777-D12F-5913-AECE-047DF8C72F1F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F6B5F777-D12F-5913-AECE-047DF8C72F1F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> How to Get Location InformationThis document demonstrates how a client application uses the Location Acquisition API to get a position.
          Purpose

          This tutorial explains how to get location information using the Location Acquisition API.

          Required background

          Location Acquisition API Overview describes the main client/server classes of the API.

          Position Data and Info Classes describes the classes that hold location information.

          Getting location information

          This section describes how to get location information using the Location Acquisition API.

          Introduction

          Client applications use the RPositionServer and RPositioner classes to get position updates. RPositionServer is used by client applications to manage a session with the Location Server and to get Positioning Module information. RPositioner is used by client applications to manage a subsession with the Location Server and to get position updates.

          GPS positioning modes

          The Global Positioning System (GPS) is a technology that is often included in devices that support LBS.

          For each location request from a client, the LBS subsystem can operate in one of several different GPS positioning modes. The Location Acquisition API hides the details of which GPS positioning mode is in use from client applications. A client makes the same sequence of calls to the API to get a position update whichever positioning mode is used. Note that only some of these positioning modes may be available to a client application at runtime.

          Each GPS positioning mode is a different way of getting a position fix:

          • Autonomous

            LBS uses a GPS Positioning Module to calculate position fixes without assistance data from the network. This mode typically takes the longest time to obtain a location fix compared to the other modes.

          • Terminal Based Mode

            LBS uses an A-GPS Positioning Module to calculate position fixes using assistance data from the network. Assistance data specifies the GPS satellites that are above the horizon as seen from the mobile device's current location. Assistance data is used by an A-GPS Positioning Module to reduce the time necessary to obtain a position fix.

            The network can also supply a reference position to the LBS subsystem as part of the sequence of events. This position is calculated in the network using cell-based techniques and may be less accurate than that obtained from GPS. If a reference position is available, it may be returned to the client before a GPS position.

            See Location Acquisition API Runtime Behaviour for more information about the position updates that can be returned by LBS.

          • Terminal Assisted Mode

            LBS uses an A-GPS Positioning Module to obtain GPS measurements (using assistance data from the network). GPS measurements are the raw data used to calculate a GPS fix. Measurements are sent to the network and a position fix is calculated by a remote server. The remotely calculated position fix is returned to the mobile device and is known as the final network position. The LBS subsystem returns this position to the client.

          • Simultaneous Terminal Based Mode and Terminal Assisted Mode.

            LBS passes GPS measurements to the network (as in Terminal Assisted Mode), but also attempts to use those measurements to calculate a GPS position fix (as in Terminal Based Mode). The position returned to the client may be either a GPS position (calculated in the mobile device) or a final network position (calculated using the measurements by a remote server in the network). The position that is calculated first (the GPS position or the final network position) is generally returned to the client. The final network position may also be returned to the client after the return of the GPS position.

          Some devices also support a Cell-based Mode in which LBS obtains a position fix from the network without using GPS. This position fix is sometimes less accurate than that obtained using GPS.

          A client application cannot directly choose the GPS positioning mode that is used for its location request. A handset manufacturer may provide an LBS settings application where the GPS mode can be selected by an end user. However for modes that involve the network (Terminal Based Mode, Terminal Assisted Mode and Cell-based Mode) it is possible for a network operator to override the GPS mode as part of the location request. If a client wants to know precisely how a position fix was calculated, this information is available in the returned position info object (as described in more detail later in this document).

          Example sequence

          Figure 1 shows a simplified sequence for a client requesting a position update from LBS. The sequence shows simplified behaviour for Terminal Based Mode. The A-GPS Module is a Positioning Module that uses Assisted GPS to calculate a position. The Network Protocol Module is a Positioning Module that obtains GPS assistance data and reference positions (often approximate positions) from the network. Note that Terminal Based Mode may not be available on all mobile devices. This depends on the Positioning Modules that have been installed by the mobile device creator.

          Figure 1. Simplified Terminal Based Mode Sequence -

          Example code and description

          The following code shows a simple example of how a client application can get a single position update. The numbers in the code comments refer to sections that follow the code example.

          #include <lbs.h> +

          Example code and description

          The following code shows a simple example of how a client application can get a single position update. The numbers in the code comments refer to sections that follow the code example.

          #include <lbs.h> #include <lbserrors.h> ... @@ -201,4 +201,4 @@ TPositionModuleInfo::ETechnologyAssisted, but it is possible for LBS to return TPositionModuleInfo::ETechnologyTerminal | TPositionModuleInfo::ETechnologyAssisted if it is configured to do so. See Location Acquisition API runtime behaviour for more information.

        Note that NotifyPositionUpdate() may complete early if a GPS positioning module signals to LBS that it will be unable to return a location fix with the required quality criteria. In this case the Location Server returns the best location fix it can obtain to the client. The value of the TRequestStatus parameter of the client is set to either KPositionQualityLoss or KErrNone depending on the configuration of Location Acquisition API runtime behaviour.

        Tracking

        A position update time line for tracking is shown in figure 2. Note that the exact behaviour of tracking on systems may differ from that shown in Figure 2.

        A client application has previously called TPositionUpdateOptions::SetUpdateInterval(T) and RPositioner::SetUpdateOptions() (not shown in figure 2). Partial updates are not set. LBS is also configured to return reference positions and accurate positions only (see Location Acquisition API runtime behaviour for more information about this behaviour). The important points are:

        • A client application makes its first call to RPositioner::NotifyPositionUpdate() (First NPUD in figure 2).

        • After a time t, the client's RunL() method is called and it receives its first position update (the reference position update Ref Pos in figure 2). This first position update is delivered to the client by LBS as soon as possible (t is as short as possible and is not equal to T). The client then makes its next call to NotifyPositionUpdate() (the next NPUD in figure 2). When tracking, a client application should make its next call to RPositioner::NotifyPositionUpdate() as soon as possible in its RunL() method. The time between the client's RunL() and the client's next NPUD is exaggerated for clarity in Figure 2.

        • At a time t + T (where T is the update interval) the client's RunL() method is called and it receives the next position update (GPS Pos in figure 2). The client makes its next call to NotifyPositionUpdate().

        • The next position update is expected at time t + 2T, but in the case shown in figure 2 this is not possible (the mobile device may have moved into an area where the GPS signal is weak). In general if it is not possible to obtain an accurate GPS fix by time t + nT, but the fix is obtained a short time later, the next position update is delivered as soon as possible after time t + nT (after t + 2T in figure 2).

        • The client makes its next call to NotifyPositionUpdate() and at time t + (n+1)T the next position update is delivered (at t + 3T in figure 2).

          The important point to note is that LBS attempts to deliver position updates at regular times t + nT but the time interval between position updates may temporarily be greater than or less than T.

        • Note that if partial updates were enabled, an incomplete position would be delivered at time t + 2T if it were available. Also note that an inaccurate position would be delivered if one was available at that time and LBS was configured to return it.

        Figure 2. Position updates when tracking -

        Error codes

        The value of a client's TRequestStatus can be set to an LBS error code (defined in lbserrors.h) or an error code defined in a licensee's Positioning Module. An error causes NotifyPositionUpdate() to complete. An application should always check the value of TRequestStatus when its RunL() method is called.

        7. Cancel or complete a location information request

        To cancel a location request a client application calls RPositionerSubSessionBase::CancelRequest(), passing a EPositionerNotifyPositionUpdate parameter. The client's TRequestStatus is set to KErrCancel if the request was successfully cancelled and no position update is returned.

        To complete a location request early, a client application calls RPositionerSubSessionBase::CompleteRequest() passing a EPositionerNotifyPositionUpdate parameter. Calling this method does not cancel the position update, but asks the Location Server to return any available position data. The returned position update may be different from that which would have been returned if the request had been allowed to complete normally. If the request is completed early, the client's TRequestStatus is set to KPositionEarlyComplete.

        8. Close the subsession and session

        RPositioner::Close() closes the subsession. RPositionServer::Close() closes the server session. In the code example the cleanup stack function is used. Any privacy requester objects created by a client must also be cleaned up.

    \ No newline at end of file +

    Error codes

    The value of a client's TRequestStatus can be set to an LBS error code (defined in lbserrors.h) or an error code defined in a licensee's Positioning Module. An error causes NotifyPositionUpdate() to complete. An application should always check the value of TRequestStatus when its RunL() method is called.

    7. Cancel or complete a location information request

    To cancel a location request a client application calls RPositionerSubSessionBase::CancelRequest(), passing a EPositionerNotifyPositionUpdate parameter. The client's TRequestStatus is set to KErrCancel if the request was successfully cancelled and no position update is returned.

    To complete a location request early, a client application calls RPositionerSubSessionBase::CompleteRequest() passing a EPositionerNotifyPositionUpdate parameter. Calling this method does not cancel the position update, but asks the Location Server to return any available position data. The returned position update may be different from that which would have been returned if the request had been allowed to complete normally. If the request is completed early, the client's TRequestStatus is set to KPositionEarlyComplete.

    8. Close the subsession and session

    RPositioner::Close() closes the subsession. RPositionServer::Close() closes the server session. In the code example the cleanup stack function is used. Any privacy requester objects created by a client must also be cleaned up.

    \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F6B9860A-E7F2-5B03-878D-9BCA0AF029C2.dita --- a/Symbian3/SDK/Source/GUID-F6B9860A-E7F2-5B03-878D-9BCA0AF029C2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F6B9860A-E7F2-5B03-878D-9BCA0AF029C2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -81,7 +81,7 @@ and components associated with each collection:

    Collections and components of Generic OS Services - +
    Technologies

    Generic OS services enables, implements or uses the following technologies:

      diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F6BC696F-0279-5902-B945-AEF7257D3EEB.dita --- a/Symbian3/SDK/Source/GUID-F6BC696F-0279-5902-B945-AEF7257D3EEB.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F6BC696F-0279-5902-B945-AEF7257D3EEB.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,15 +1,16 @@ - - - - - -PIM -ExamplesExample code for Application Engines and Services. - + + + + + +PIM +Examples +

      Example code for Application Engines and Services.

      +       \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F740BA72-B00E-5D98-BD0F-5937F60460BC_d0e169201_href.jpg Binary file Symbian3/SDK/Source/GUID-F740BA72-B00E-5D98-BD0F-5937F60460BC_d0e169201_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F740BA72-B00E-5D98-BD0F-5937F60460BC_d0e174215_href.jpg Binary file Symbian3/SDK/Source/GUID-F740BA72-B00E-5D98-BD0F-5937F60460BC_d0e174215_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F765C7EB-A8C6-50C0-B350-85BE04C8984F.dita --- a/Symbian3/SDK/Source/GUID-F765C7EB-A8C6-50C0-B350-85BE04C8984F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F765C7EB-A8C6-50C0-B350-85BE04C8984F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -18,7 +18,7 @@

      Anchor points are always referred to as headers.

      A doubly linked list is useful for maintaining a circular queue of items.

      - +

      Doubly linked lists involve the creation and use of the classes:

        diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F77CC49A-904D-486B-8D16-972525EC34D5.dita --- a/Symbian3/SDK/Source/GUID-F77CC49A-904D-486B-8D16-972525EC34D5.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F77CC49A-904D-486B-8D16-972525EC34D5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -23,7 +23,7 @@

        The Clear key is used for deleting characters and for that purpose only.

        Data query. - +
        Using data queries in applications

        For implementation information, diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e173024_href.png Binary file Symbian3/SDK/Source/GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e173024_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e178049_href.png Binary file Symbian3/SDK/Source/GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e178049_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F79A3DD7-DB91-545F-8165-F1F2DD6D0AD2.dita --- a/Symbian3/SDK/Source/GUID-F79A3DD7-DB91-545F-8165-F1F2DD6D0AD2.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F79A3DD7-DB91-545F-8165-F1F2DD6D0AD2.dita Tue Jul 20 12:00:49 2010 +0100 @@ -12,4 +12,4 @@ Creating an Implicitly Bound SocketThis topic describes how create an implicitly bound socket.

        • An application opens a socket using the default interface connection and binds to a port and IP address of the connection. The application receives inbound traffic only from the interface the socket is bound to.

          For example, an application opens an implicit UDP socket and listens on port 8000. The UDP socket binds to interface IP address 10.253.4.134. The UDP socket must receive data packets from this interface only.

        • If an application opens a socket and does not bind to a port or IP address of the default interface connection, then the application receives inbound traffic from multiple interfaces.

          For example, if an application opens an implicit UDP socket and does not bind the port 8000 to the IP address of the default interface connection, then the application receives inbound traffic from all the interfaces.

        Implicit binding example

        Client B creates a socket with implicit binding without specifying the interface connection.

        server = RSocketServ.Connect(); socket1 = RSocket.Open(server); -

        ESock creates the socket within the default connection and subconnection.

        Socket Binding \ No newline at end of file +

        ESock creates the socket within the default connection and subconnection.

        Socket Binding \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F79E4F18-19E2-577E-8409-8B82BD48AC66.dita --- a/Symbian3/SDK/Source/GUID-F79E4F18-19E2-577E-8409-8B82BD48AC66.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F79E4F18-19E2-577E-8409-8B82BD48AC66.dita Tue Jul 20 12:00:49 2010 +0100 @@ -52,7 +52,7 @@
        Architecture

        The following diagram illustrates the XML framework, consisting of client and a parser:

        Block diagram of XML framework - +

        The XML framework consists of classes which model the main constituents of the architecture - the framework as a whole, the parser plug-ins and extensions to XML, the content processor chain and the content handler mechanism.

        The diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F79EE68F-FFC3-541E-AE3A-D7203034DA43.dita --- a/Symbian3/SDK/Source/GUID-F79EE68F-FFC3-541E-AE3A-D7203034DA43.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,99 +0,0 @@ - - - - - -mmp -project specification -

        This page describes the MMP for a typical GUI application.

        -

        TARGETTYPE

        -

        From v9.0, a GUI application is an exe. This is specified with the targettype statement:

        -TARGETTYPE exe -

        The target filename's extension can be either .app or .exe. This is specified -using a target statement:

        -TARGET <appname>.exe -

        UID

        -

        Specify the UID for the application in a uid statement:

        -UID 0x100039CE <UID3> -

        The UID2 value 0x100039CE should be used for all applications. -The UID3 value is the unique identifier for the particular application.

        -

        Stack size

        -

        By default, processes have a stack size of 8K. This can be insufficient -for some applications. To increase the size, use an epocstacksize statement:

        -// set stack to 20K -epocstacksize 0x5000 -

        UI resource

        -

        Specify the application's UI resource file using a start -resource statement:

        -START RESOURCE <appname>.RSS -HEADER -TARGETPATH \Resource\Apps -END -

        The resource should be built into the \Resource\Apps directory. -This is specified using the TARGETPATH part of the statement.

        -

        The header line tells the resource compiler to produce -a file \epoc32\include\<appname>.rsg, which defines -macro constants through which C++ programs can refer to resource structures.

        -

        Caption/icon resource

        -

        An application can specify localisable captions and icons to display on -the shell using a LOCALISABLE_APP_INFO resource, either -in the UI resource file or in a separate resource file.

        -

        Registration file

        -

        Specify the application's registration file using another start -resource statement:

        -START RESOURCE <appname>_reg.rss -TARGETPATH \private\10003a3f\apps -END -

        The registration file must be built to the private system directory \private\10003a3f\apps directory.

        -

        Note that for security reasons a registration file cannot be installed -directly to this location on a target device. When creating a PKG file (software -install package file) for an application, the registration file must be installed -to the \private\10003a3f\import\apps\ directory.

        -

        For more information, see Application -registration information.

        -

        Icons

        -

        A bitmap file containing icons for an application can be specified using -a start bitmap statement:

        -START BITMAP <appname>.mbm -TARGETPATH \Resource\Apps -SOURCE <color-depth> <source-bitmap-list> -END -

        Icon files, like the UI resource file, should be built into the \Resource\Apps directory.

        -

        An example of a real GUI application project file -is given below:

        TARGET HelloWorld.exe -TARGETTYPE exe -UID 0x100039CE 0x10004299 -VENDORID 0x70000001 -epocstacksize 0x5000 - -SOURCEPATH . -SOURCE HelloWorld_Main.cpp -SOURCE HelloWorld_Application.cpp -SOURCE HelloWorld_Document.cpp -SOURCE HelloWorld_AppUi.cpp -SOURCE HelloWorld_AppView.cpp -USERINCLUDE . -SYSTEMINCLUDE \epoc32\include - -START RESOURCE HelloWorld.RSS -HEADER -TARGETPATH \Resource\Apps -end - -START RESOURCE HelloWorld_reg.rss -TARGETPATH \private\10003a3f\apps -END - -START BITMAP HelloWorld.mbm -TARGETPATH \Resource\Apps -SOURCE c8,1 icon24.bmp icon2m.bmp icon32.bmp icon3m.bmp icon48.bmp icon4m.bmp -END - -LIBRARY euser.lib apparc.lib cone.lib eikcore.lib         - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7A17E65-CB2D-41D3-9404-1A7D7F55FABC_d0e70843_href.png Binary file Symbian3/SDK/Source/GUID-F7A17E65-CB2D-41D3-9404-1A7D7F55FABC_d0e70843_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7A17E65-CB2D-41D3-9404-1A7D7F55FABC_d0e70868_href.png Binary file Symbian3/SDK/Source/GUID-F7A17E65-CB2D-41D3-9404-1A7D7F55FABC_d0e70868_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7BFE6E3-0EEE-536C-8411-65D8F5FEBF2E_d0e79068_href.png Binary file Symbian3/SDK/Source/GUID-F7BFE6E3-0EEE-536C-8411-65D8F5FEBF2E_d0e79068_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7BFE6E3-0EEE-536C-8411-65D8F5FEBF2E_d0e79126_href.png Binary file Symbian3/SDK/Source/GUID-F7BFE6E3-0EEE-536C-8411-65D8F5FEBF2E_d0e79126_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7C9730D-7A41-4EE3-881C-393BB52B99C8_d0e36154_href.png Binary file Symbian3/SDK/Source/GUID-F7C9730D-7A41-4EE3-881C-393BB52B99C8_d0e36154_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7C9730D-7A41-4EE3-881C-393BB52B99C8_d0e36321_href.png Binary file Symbian3/SDK/Source/GUID-F7C9730D-7A41-4EE3-881C-393BB52B99C8_d0e36321_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F7FEB759-E64D-5B6D-9017-C5E982E4FC16.dita --- a/Symbian3/SDK/Source/GUID-F7FEB759-E64D-5B6D-9017-C5E982E4FC16.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F7FEB759-E64D-5B6D-9017-C5E982E4FC16.dita Tue Jul 20 12:00:49 2010 +0100 @@ -24,7 +24,7 @@ illustrates how Standard C++ interacts with the Symbian platform and P.I.P.S. libraries:

        Standard C++ on the Symbian platform - +
        Copyright diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F8069628-BD32-535C-963A-A1CF8172E275.dita --- a/Symbian3/SDK/Source/GUID-F8069628-BD32-535C-963A-A1CF8172E275.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F8069628-BD32-535C-963A-A1CF8172E275.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,6 +11,6 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> What are CF Protocols, Binders, and FlowsThis topic describes the concepts of Communications Framework (CF) Protocols,Binders and Flows in the Communications Framework.

        In the Communications Architecture each Layer requires the participation of several communications components; namely the Tier Manager, MCPR, CPR, SCPR and the components. The name given to the Data Flow components is a Communications Framework Protocol (CF Protocol).

        Figure 1 - A CF Protocol in the Layered Comms Stack -

        A CF Protocol is a collection of components on the Data Plane, most importantly the Flow and the Binder(s). The Flow is a Node and communicates with the SCPR that caused it to be started, using the asynchronous Message Transport mechanism. Each Flow has one or more Binders which connect the Flow to the layer above.

        CF Protocol components +

        A CF Protocol is a collection of components on the Data Plane, most importantly the Flow and the Binder(s). The Flow is a Node and communicates with the SCPR that caused it to be started, using the asynchronous Message Transport mechanism. Each Flow has one or more Binders which connect the Flow to the layer above.

        CF Protocol components Components of a CF Protocol -

        A CF Protocol is constructed of two main components:

        • Flow - a single conversation with a remote peer. There can be multiple Flows in a CF Protocol to handle multiple concurrent conversations through the same instance of the CF Protocol.

        • Binder - A Binder handles the interface between the current Flow and the Layer above. A Binder connects two CF Protocols together so that they can communicate data and sometimes commands. A Flow can have more than one Binder if it needs to connect to more than one Flow in the Layer above.

          A Protocol Binder is the binding point for de-multiplexed incoming data but provides no flow control, data will be lost if the layer above is not ready to process it.

          A Session Binder handles flow control by contacting the Layer above to say data is available, and waits for the CF Protocol of the Layer above to request the data.

        Flow

        A Flow is an instance of a class which represents a single conversation with a remote peer.

        There may be many active Flows in a CF Protocol to represent many concurrent conversations through the same instance of the CF Protocol.

        A Flow is a Stack Node created and controlled by one SCPR.

        Configuration data for the Flow is provisioned directly by the SCPR and usually originates from the MCPR.

        Since a Flow handles message exchange with the corresponding SCPR asynchronously, a Flow is always a state machine. State transitions are mostly triggered by exchange of different message types with the remote peer. State transitions may also be triggered by other mechanisms, such as timeouts, that require active objects within the Flow. A Flow is created by a Factory.

        The Flow can de-multiplex the inbound, though it is up to the specific Flow to have appropriate code to do the de-multiplexing. De-multiplexing could be performed based on address information, port information, protocol specific session, source identifier or other data. De-multiplexing passes data to specific Flows, via individual Protocol Binders, to higher level CF Protocols which can also de-multiplex the data further. If there is no de-multiplexing then the layer above does not have to bind a protocol interface as a data receiver. An example would be an IP Flow, which may contain IPv4 and IPv6 packets and would have separate Protocl Binders for each version.

        Each Flow must serve the following messages:

        • TBindTo - tells the Flow which lower Flow to bind to

        • TProvisionConfig - carries a configuration object

        • TStartFlow - starts the Flow

        • TStopFlow - stops the Flow

        • TDestroy - instructs the Flow to delete itself

        • TStateChange - the Flow should send this whenever it wants to inform the control side of its state change

        Binder

        The Binder is split into two parts:

        • Binder Control - used by the upper layer to set up the binding with the lower layer.

        • Binder - the actual binding between two Layers so that data can be sent and received. Again there are two types of Binder, Protocol Binder and Session Binder. It is common for a particular CF Protocol to only support one kind of Binder, Session or Protocol.

        There will be CF Protocols where it will be a good design to have a Protocol Binder for data, and to use a Session Binder for control messages. These will usually be separate Flows.

        Protocol Binder

        A Protocol Binder is used by the Flow as the link to the next higher CF Protocol for inbound data.

        A Protocol Binder only communicates with the Flow and should never communicate with an SCPR. Any design that would require the Protocol Binder to communicate with the SCPR should be redesigned.

        Protocol Binders are most commonly used for lower-level protocols (nearer the hardware) rather than the higher-level Link layer protocols.

        Session Binder

        A Session Binder offers much richer functionality than a Protocol Binder as it is mostly used by higher level protocols (closer to application space) that are more complex than the lower level ones (closer to hardware). A Session Binder operates independently of the protocol of the next Layer above with which it connects, as opposed to the Protocol Binder which is specific for a particular protocol in the Layer above. A Session Binder may offer functionality that is supported by only some of the protocols using that binder. For example a Session Binder may provide flow control on the data, while a Protocol Binder will pass the data upwards immediately and if the Layer above is not able to accept the data it will be discarded.

        Layers Planes Nodes \ No newline at end of file +

        A CF Protocol is constructed of two main components:

        • Flow - a single conversation with a remote peer. There can be multiple Flows in a CF Protocol to handle multiple concurrent conversations through the same instance of the CF Protocol.

        • Binder - A Binder handles the interface between the current Flow and the Layer above. A Binder connects two CF Protocols together so that they can communicate data and sometimes commands. A Flow can have more than one Binder if it needs to connect to more than one Flow in the Layer above.

          A Protocol Binder is the binding point for de-multiplexed incoming data but provides no flow control, data will be lost if the layer above is not ready to process it.

          A Session Binder handles flow control by contacting the Layer above to say data is available, and waits for the CF Protocol of the Layer above to request the data.

        Flow

        A Flow is an instance of a class which represents a single conversation with a remote peer.

        There may be many active Flows in a CF Protocol to represent many concurrent conversations through the same instance of the CF Protocol.

        A Flow is a Stack Node created and controlled by one SCPR.

        Configuration data for the Flow is provisioned directly by the SCPR and usually originates from the MCPR.

        Since a Flow handles message exchange with the corresponding SCPR asynchronously, a Flow is always a state machine. State transitions are mostly triggered by exchange of different message types with the remote peer. State transitions may also be triggered by other mechanisms, such as timeouts, that require active objects within the Flow. A Flow is created by a Factory.

        The Flow can de-multiplex the inbound, though it is up to the specific Flow to have appropriate code to do the de-multiplexing. De-multiplexing could be performed based on address information, port information, protocol specific session, source identifier or other data. De-multiplexing passes data to specific Flows, via individual Protocol Binders, to higher level CF Protocols which can also de-multiplex the data further. If there is no de-multiplexing then the layer above does not have to bind a protocol interface as a data receiver. An example would be an IP Flow, which may contain IPv4 and IPv6 packets and would have separate Protocl Binders for each version.

        Each Flow must serve the following messages:

        • TBindTo - tells the Flow which lower Flow to bind to

        • TProvisionConfig - carries a configuration object

        • TStartFlow - starts the Flow

        • TStopFlow - stops the Flow

        • TDestroy - instructs the Flow to delete itself

        • TStateChange - the Flow should send this whenever it wants to inform the control side of its state change

        Binder

        The Binder is split into two parts:

        • Binder Control - used by the upper layer to set up the binding with the lower layer.

        • Binder - the actual binding between two Layers so that data can be sent and received. Again there are two types of Binder, Protocol Binder and Session Binder. It is common for a particular CF Protocol to only support one kind of Binder, Session or Protocol.

        There will be CF Protocols where it will be a good design to have a Protocol Binder for data, and to use a Session Binder for control messages. These will usually be separate Flows.

        Protocol Binder

        A Protocol Binder is used by the Flow as the link to the next higher CF Protocol for inbound data.

        A Protocol Binder only communicates with the Flow and should never communicate with an SCPR. Any design that would require the Protocol Binder to communicate with the SCPR should be redesigned.

        Protocol Binders are most commonly used for lower-level protocols (nearer the hardware) rather than the higher-level Link layer protocols.

        Session Binder

        A Session Binder offers much richer functionality than a Protocol Binder as it is mostly used by higher level protocols (closer to application space) that are more complex than the lower level ones (closer to hardware). A Session Binder operates independently of the protocol of the next Layer above with which it connects, as opposed to the Protocol Binder which is specific for a particular protocol in the Layer above. A Session Binder may offer functionality that is supported by only some of the protocols using that binder. For example a Session Binder may provide flow control on the data, while a Protocol Binder will pass the data upwards immediately and if the Layer above is not able to accept the data it will be discarded.

        Layers Planes Nodes         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F82675C4-C2FD-50E2-BEDA-EB454FF1C57E_d0e202130_href.png Binary file Symbian3/SDK/Source/GUID-F82675C4-C2FD-50E2-BEDA-EB454FF1C57E_d0e202130_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F82675C4-C2FD-50E2-BEDA-EB454FF1C57E_d0e207137_href.png Binary file Symbian3/SDK/Source/GUID-F82675C4-C2FD-50E2-BEDA-EB454FF1C57E_d0e207137_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F8A26275-883A-5299-9C37-9DDCC2F62108.dita --- a/Symbian3/SDK/Source/GUID-F8A26275-883A-5299-9C37-9DDCC2F62108.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F8A26275-883A-5299-9C37-9DDCC2F62108.dita Tue Jul 20 12:00:49 2010 +0100 @@ -15,7 +15,7 @@ of the existing file and the new version must be the same.

        For example, the file, a.exe located on z:\...\, can be eclipsed by placing a latest version of a.exe on C:\...\.

        -
        Eclipsing rules

        The +

        Eclipsing rules

        The eclipsing of binary and data files in the ROM is strictly controlled. That is, device creators can eclipse only the files that are listed in the Stub SIS file. The eclipsing fails if there is no associated Stub SIS file present diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F8E4D4AC-878A-52C5-A04D-9E116A0087D5.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-F8E4D4AC-878A-52C5-A04D-9E116A0087D5.dita Tue Jul 20 12:00:49 2010 +0100 @@ -0,0 +1,21 @@ + + + + + +CalInterimAPI: +Using the Calendar API +

        Description

        This +C++ application demonstrates how to add and modify anniversary entries using +the Calendar Interim API (also known as CalInterim API). The Calendar Interim +API replaced the Agenda Model API.

        +
        Download

        Click +on the following link to download the example: CalenderExample.zip

        Click: browse to view the example code.

        +
        See also

        Calendar overview

        + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F9455FE8-5247-58D5-ACEF-52753B88444F.dita --- a/Symbian3/SDK/Source/GUID-F9455FE8-5247-58D5-ACEF-52753B88444F.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to control binary compatibility
        Overview

        It is important for users that the software they buy and use should continue to run on new releases of Symbian platform, and that it should be transferable to new devices containing the latest releases of the operating system.

        Ensuring that a current software release does not break existing software is known as maintaining binary compatibility (BC). There is a related compatibility issue for data — ensuring that new software versions remain data compatible with previous versions. Data incompatibilities can be just as galling for software users, making existing documents obsolete, but don't intrinsically affect the software itself.

        BC is most obviously a concern for the systems developers responsible for the evolution of the operating system. However, it is relevant for any Symbian developer whose software provides services to client software. Symbian developers whose software uses such services should understand a problem that potentially they may encounter.

        A related concern is where a program is first developed using a version of some system component or a third part service. Symbian developers may need to know whether their programs will also work with older versions of that system component or third part service. This form of compatibility is an added bonus but, generally, backward compatibility is the overriding requirement.

        The interface as contract

        When a software component is changed, the changes impact all dependent software components — including the ones which have not yet been written. This means that rather than relying on testing, the safety of changes must somehow be guaranteed.

        A component which defines an interface through which it may be used should be regarded as making a contract with the rest of the world. Its interface is its contact. Other components which build against its interface must be guaranteed that when they later run against its interface, nothing will have changed. The BC requirement is that guarantee.

        Although in principle there are many different mechanisms through which software can offer an interface to clients, in the Symbian software platform, BC is a DLL related problem.

        Source compatibility, link compatibility, binary compatibility

        BC is stronger than both link and source compatibility. Maintaining BC also implies that both link and source compatibility are maintained.

        Source compatibility describes the situation where an interface we are using has changed between building against it and running against it, in such a way that we can only recover by rebuilding against the changed interface. Our source need not change, but we must rebuild.

        Because source level interfaces are defined in the published header #include files, it is easy to see whether changes are compatible — examine the changes to the header file.

        Link compatibility describes the situation where to recover from an interface change we must relink our component against a component we originally built against. Our source need not be rebuilt, but we must relink.

        Link level interfaces are defined by the published import library. Again it is not too hard to see whether a change is compatible — ensure that all exported functions are unchanged.

        Binary compatibility guarantees a constant interface between our building and running against another component.

        The BC level interface is not so easy to define and may include quite general behaviour of the changed component. Because it is hard to define it is hard to check for changes which potentially break it. Potential BC breaking changes include:

        • Virtual member functions are for life — you can't add or remove virtual member functions

        • or change the virtuality of a function

        • or change their declaration order

        • or override an existing function that was previously inherited

        • You cannot add a UID if was originally omitted from the DLL

        Safe changes which preserve backward binary compatibility include:

        • Any name can be changed but — this requires clear documentation because dependent components must change source code, and usually also requires editing the frozen .def files

        • Adding services — classes, global functions, static and non-virtual member functions can all be added to a shared library

        • Changing access specification — any member can be made more widely accessible. The reverse is not allowed. Similarly, friendship can be bestowed but not withdrawn

        • You can do what you like with private data and non-virtual function members except — when it would change the class size, or when effectively public data would move in the class

        • Parameters and return values — valid inputs must retain their interpretation and existing output values must retain their meaning

        • Inputs can be widened: e.g. less derived pointer, extended enum, adding a const qualifier or outputs can be narrowed: e.g. more derived pointer, fewer error code values, removing a const qualifier

        • Pointer and reference types can be exchanged

        To help maintain BC only release what you need to release — you don't have to support what you don't release

        Controlling binary compatibility with build time tools

        Some potentially BC breaking changes are introduced not by Symbian developers but by the build system. Symbian platform provides tools which help to control BC by blocking accidental build-time changes.

        When a DLL is loaded it supplies a table of addresses, one for each exported symbol and one for the entry point of each exported function. This is the DLL's public interface. To preserve BC the index of each export must remain constant from one release to another.

        Symbian platform uses export definitions (.def) files to manage this requirement. Each exported symbol is listed in the exports section of the file with its ordinal, which is calculated as index + ordinal base. Symbian platform uses an ordinal base of 1. By the definition of source compatibility implied by BC, every export defined in an earlier release will be defined in the new release. Exports introduced in a new release must come after those defined in earlier releases.

        For DLL builds, the build tools automatically create the .def file within the build tree for the specified target. Once these have been generated for a build, they can be archived with the project source and used in future builds to freeze the exports against change.

        This is done by copying the .def files into a default location and including the directive

        DEFFILE projectname.def

        in the project .mmp file.

        In any subsequent command-line build of the project the exports will be guaranteed compatible with the current version. If new exports are added, the new def files should once again be copied from the build directory and archived with the new release. Only command-line builds should be released.

        The creation and translation of .def files is managed by the Symbian platform build process, see The Symbian build process.

        \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F95A7D74-FD5C-40D2-BF4F-2F75443CAE51.dita --- a/Symbian3/SDK/Source/GUID-F95A7D74-FD5C-40D2-BF4F-2F75443CAE51.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F95A7D74-FD5C-40D2-BF4F-2F75443CAE51.dita Tue Jul 20 12:00:49 2010 +0100 @@ -26,7 +26,7 @@ b) Column A contains an icon, columns B&C combined for text. c) Columns A&B combined for a large icon, column C contains text. d) Column A: an icon; column B: a label; column C: text. - + Standard elements within list item associated with columns diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F9605837-2209-500D-AB62-48A433489C5E.dita --- a/Symbian3/SDK/Source/GUID-F9605837-2209-500D-AB62-48A433489C5E.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,61 +0,0 @@ - - - - - -Resource -file definition -

        A source file consists of any number of statements:

        -<source-file> -source-file ::= - <statement-list> <statement> -statement ::= - <uid2-statement> | <uid3-statement> | <character_set-statement> | <enum-statement> | <name-statement> | <resource-statement> | <struct-statement> -

        A summary of the keywords that are used for these statement types respectively -is given below:

        -
        - - - -

        CHARACTER_SET

        -

        Defines the character set to be used

         -         - -

        ENUM

        -

        Defines a set of integer values

         -         - -

        NAME

        -

        By default, the resource IDs in the generated header file are allocated -from 1 in ascending sequence. The sequence can be made to begin from another -value using this statement.

         -         - -

        RESOURCE

        -

        Defines an actual resource instance of the type defined in -a struct, gives it a resource id, and causes it to be generated in the resource -file.

        -         - -

        STRUCT

        -

        Defines a type of resource.

         -         - -

        UID2

        -

        Defines the second UID for the resource file

         -         - -

        UID3

        -

        Defines the third UID for the resource file

         -         - - -
        -

        The most usual statements are STRUCT and RESOURCE.

        - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e62709_href.png Binary file Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e62709_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e62852_href.png Binary file Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e62852_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e69206_href.png Binary file Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e69206_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e69230_href.png Binary file Symbian3/SDK/Source/GUID-F96623BF-B646-46B4-942E-69EB065BE491_d0e69230_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96D14A5-58BB-4F1A-A6FB-5D13DCB84B33_d0e61999_href.png Binary file Symbian3/SDK/Source/GUID-F96D14A5-58BB-4F1A-A6FB-5D13DCB84B33_d0e61999_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F96D14A5-58BB-4F1A-A6FB-5D13DCB84B33_d0e62142_href.png Binary file Symbian3/SDK/Source/GUID-F96D14A5-58BB-4F1A-A6FB-5D13DCB84B33_d0e62142_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F97EA91E-35E3-5E69-A4C4-7415AB91C1BC_d0e77072_href.png Binary file Symbian3/SDK/Source/GUID-F97EA91E-35E3-5E69-A4C4-7415AB91C1BC_d0e77072_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F97EA91E-35E3-5E69-A4C4-7415AB91C1BC_d0e77110_href.png Binary file Symbian3/SDK/Source/GUID-F97EA91E-35E3-5E69-A4C4-7415AB91C1BC_d0e77110_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F9896E96-1076-552D-AE54-8F9DABED867F.dita --- a/Symbian3/SDK/Source/GUID-F9896E96-1076-552D-AE54-8F9DABED867F.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-F9896E96-1076-552D-AE54-8F9DABED867F.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Configuring the Video Player

        This tutorial describes how to configure the video player.

        Purpose

        The purpose of this tutorial is to show you how to make configuration adjustments to the video player.

        Required Background

        The Video Client Overview introduces the video client utilities.

        Introduction

        The video player utility is used to open, play, and obtain information from sampled video data. This functionality is implemented by the CVideoPlayerUtility class. The video data can be supplied either in a file, a descriptor or a URL.

        Using Video Player

        The following tasks will be covered in this tutorial:

        • Set the Display Window

        • Query and Set the Volume

        • Query and Set the Balance

        • Query and Set the Priority

        • Query and Set the Bit and Frame Rate

        • Query and Set the Current Playback Position

        • Query and Set the MIME and Codec Type

        Setting the Display Window

        The high level steps to set the display window are shown here:

        • CVideoPlayerUtility::SetDisplayWindowL: This is used to provide the video controller with an area of display to render the current video frame. It can be represented pictorially as shown below:

          Video display regions -

          The screeenRect specifies the area within the window provided for displaying the video image. This rectangle is in screen coordinates. The video frame will be fitted to this rectangle as best possible, while maintaining the original aspect ratio.

          The ClipRect specifies the region to draw. The drawn region will be the intersection between the ClipRect and the ScreenRect.

          A crop region is defined as a region in the source video frame. The cropped region is displayed in the center of the ScreenRect with the same scaling as if it was displayed as part of the whole image. This could be used to zoom in on a region by setting the crop region, and setting the scale factor to fill the WindowRect.

          void CPlayVideo::SetDisplayWindowL(RWsSession &aWs, CWsScreenDevice &aScreenDevice, RWindowBase &aWindow, const TRect &aWindowRect, const TRect &aClipRect) +

          The screeenRect specifies the area within the window provided for displaying the video image. This rectangle is in screen coordinates. The video frame will be fitted to this rectangle as best possible, while maintaining the original aspect ratio.

          The ClipRect specifies the region to draw. The drawn region will be the intersection between the ClipRect and the ScreenRect.

          A crop region is defined as a region in the source video frame. The cropped region is displayed in the center of the ScreenRect with the same scaling as if it was displayed as part of the whole image. This could be used to zoom in on a region by setting the crop region, and setting the scale factor to fill the WindowRect.

          void CPlayVideo::SetDisplayWindowL(RWsSession &aWs, CWsScreenDevice &aScreenDevice, RWindowBase &aWindow, const TRect &aWindowRect, const TRect &aClipRect) { iVideoUtility->SetDisplayWindowL(aWs, aScreenDevice, aWindow, aWindowRect, aClipRect); } diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F99938E9-9E06-53C0-B762-2CE51BC5F1E2_d0e427411_href.png Binary file Symbian3/SDK/Source/GUID-F99938E9-9E06-53C0-B762-2CE51BC5F1E2_d0e427411_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F99938E9-9E06-53C0-B762-2CE51BC5F1E2_d0e431211_href.png Binary file Symbian3/SDK/Source/GUID-F99938E9-9E06-53C0-B762-2CE51BC5F1E2_d0e431211_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-F9E10A82-88E9-57AA-AFEE-3C1A21BF05BC.dita --- a/Symbian3/SDK/Source/GUID-F9E10A82-88E9-57AA-AFEE-3C1A21BF05BC.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -target

          abld [ test ] target ( ( [-c] | [-w] ) | ( [-s] [-k] [-v] ) ) [ platform ] [ build [ program ] ]

          This command builds the executables for your component.

          Since, in the makefiles generated by makmake, the main target is dependent upon the RESOURCE and LIBRARY targets, resources and import libraries will also be created when the main target is built.

          Executables will not be regenerated where they have later datestamps than the source files they depend upon.

           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FA12B3F7-4E84-5BBD-8598-9A974FFA7FCC.dita --- a/Symbian3/SDK/Source/GUID-FA12B3F7-4E84-5BBD-8598-9A974FFA7FCC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FA12B3F7-4E84-5BBD-8598-9A974FFA7FCC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -41,7 +41,7 @@ Figure 1 - How Root Server and Root Server relate, and the steps involved during startup - +

          Root Server Configurator is configured by two types of files: CMI files, and the c32start.ini file.

          diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FA18838A-F0C6-5241-8913-BFB46571D908.dita --- a/Symbian3/SDK/Source/GUID-FA18838A-F0C6-5241-8913-BFB46571D908.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,14 +0,0 @@ - - - - - -Device-level code

          Drivers for native ARM-based targets access real hardware, while under WINSCW, you use Win32 facilities to access or emulate hardware. This means that WINSCW device-level code must be substantially different from that used by native targets.

          First, you will need substantial conditional compilation. Device drivers will need full testing under both WINSCW and ARM targets. In general, a WINSCW device driver is best considered as a separate project from a corresponding native target device driver.

          Usually, in order to implement this kind of code, you will also need to access Win32 libraries. Specify them using .mmp specifications such as:

          start wins -win32_library kernel32.lib gdi.lib -end           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FAC309FE-B7DA-572B-9165-BC9BEF944D83_d0e334695_href.png Binary file Symbian3/SDK/Source/GUID-FAC309FE-B7DA-572B-9165-BC9BEF944D83_d0e334695_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FAC309FE-B7DA-572B-9165-BC9BEF944D83_d0e341161_href.png Binary file Symbian3/SDK/Source/GUID-FAC309FE-B7DA-572B-9165-BC9BEF944D83_d0e341161_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FAFDBFC2-BFFF-536C-A96D-8404C389DD0C.dita --- a/Symbian3/SDK/Source/GUID-FAFDBFC2-BFFF-536C-A96D-8404C389DD0C.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -unpagedcode

          unpagedcode

          Use the unpagedcode statement to specify that the executable is not code paged.

          \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB12481D-B3F6-5901-A0DC-DF92BCED3B18_d0e169039_href.jpg Binary file Symbian3/SDK/Source/GUID-FB12481D-B3F6-5901-A0DC-DF92BCED3B18_d0e169039_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB12481D-B3F6-5901-A0DC-DF92BCED3B18_d0e174053_href.jpg Binary file Symbian3/SDK/Source/GUID-FB12481D-B3F6-5901-A0DC-DF92BCED3B18_d0e174053_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB45BC8B-FE99-5616-9270-132C4174DAE7_d0e364601_href.png Binary file Symbian3/SDK/Source/GUID-FB45BC8B-FE99-5616-9270-132C4174DAE7_d0e364601_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB45BC8B-FE99-5616-9270-132C4174DAE7_d0e383750_href.png Binary file Symbian3/SDK/Source/GUID-FB45BC8B-FE99-5616-9270-132C4174DAE7_d0e383750_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB479891-8788-5548-B875-A5C637EC2DE6_d0e177098_href.png Binary file Symbian3/SDK/Source/GUID-FB479891-8788-5548-B875-A5C637EC2DE6_d0e177098_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB479891-8788-5548-B875-A5C637EC2DE6_d0e182123_href.png Binary file Symbian3/SDK/Source/GUID-FB479891-8788-5548-B875-A5C637EC2DE6_d0e182123_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB654184-C256-546F-AF6C-E0FADA78D5D0_d0e214615_href.png Binary file Symbian3/SDK/Source/GUID-FB654184-C256-546F-AF6C-E0FADA78D5D0_d0e214615_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FB654184-C256-546F-AF6C-E0FADA78D5D0_d0e219613_href.png Binary file Symbian3/SDK/Source/GUID-FB654184-C256-546F-AF6C-E0FADA78D5D0_d0e219613_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FBB9ED48-3C0F-4B2D-90FC-52127698F253.dita --- a/Symbian3/SDK/Source/GUID-FBB9ED48-3C0F-4B2D-90FC-52127698F253.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FBB9ED48-3C0F-4B2D-90FC-52127698F253.dita Tue Jul 20 12:00:49 2010 +0100 @@ -20,7 +20,7 @@

          IPv4/IPv6 dual-stack enables applications to choose the protocol to use or automatically select it according to address type. This feature is supported from Symbian OS v7.0s onwards.

          -IPv4/IPv6 dual-protocol stack +IPv4/IPv6 dual-protocol stack

          It is possible to establish a secure connection from application to application and also from router to router. Security features implemented in low-level protocols (like IPv6) are automatically available to higher-level diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e76098_href.png Binary file Symbian3/SDK/Source/GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e76098_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e76136_href.png Binary file Symbian3/SDK/Source/GUID-FBBC7F0D-FD4B-58B7-BEAC-B68EEBD19ACF_d0e76136_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FBC9FA67-847F-599B-B244-3E9B72D40505_d0e323758_href.jpg Binary file Symbian3/SDK/Source/GUID-FBC9FA67-847F-599B-B244-3E9B72D40505_d0e323758_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FBC9FA67-847F-599B-B244-3E9B72D40505_d0e330228_href.jpg Binary file Symbian3/SDK/Source/GUID-FBC9FA67-847F-599B-B244-3E9B72D40505_d0e330228_href.jpg has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FC230C68-18FC-5DB9-A5B2-942B48DC5590_d0e334707_href.png Binary file Symbian3/SDK/Source/GUID-FC230C68-18FC-5DB9-A5B2-942B48DC5590_d0e334707_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FC230C68-18FC-5DB9-A5B2-942B48DC5590_d0e341173_href.png Binary file Symbian3/SDK/Source/GUID-FC230C68-18FC-5DB9-A5B2-942B48DC5590_d0e341173_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FC929B37-20E1-5DA7-91A7-CBBED2E69A6E.dita --- a/Symbian3/SDK/Source/GUID-FC929B37-20E1-5DA7-91A7-CBBED2E69A6E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FC929B37-20E1-5DA7-91A7-CBBED2E69A6E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,60 +1,50 @@ - - - - - -Getting -Equivalent and Nearest Equivalent Languages This section describes how to call functions of BaflUtils to -get an equivalent language list and a nearest equivalent language. -

          This tutorial assumes that you have an understanding of the following -topics:

            -

          • Equivalent -Language Reference explains the equivalent language table, including -the equivalent language list and its priority.

            • -

          • About -Application Resources describes the purpose of resource files.

            • -

          • How -to Localize Resources describes language-neutral and language-dependent -resource files.

            • -
          -

          BaflUtils provides the following two static -functions to get the equivalent language list and a nearest equivalent language:

            -
          • GetEquivalentLanguageList(TLanguage aLang, TLanguagePath& aEquivalents)

            For a given language (TLanguage), it returns an array -(TLanguagePath) which contains the equivalent languages. -If no equivalent language is found, ELangNone is returned.

            • -
          • NearestLanguageFileV2(const RFs& aFs,TFileName& aName, TLanguage& aLanguage)

            A TLanguage value is used at the end of a resource -file name to identify a resource file for a language. For example, filename.r01 and filename.r02 are -the English and French versions of the filename.rsc resource -file.

            An application calls BaflUtils::NearestLanguageFileV2() to -determine which localized resource file is the closest to the current system -language. The function searches the following drives in the given sequence -for the available resource files, which have the same file name (without extension) -as aName. Once the resource files are searched on a drive, -the function stops searching on the next drive.

              -

            • The custom resource -drive if it is set using the HAL::ECustomResourceDrive attribute -or the legacy HAL::ESystemDrive attribute.

              • -

            • The optional drive if -it is specified in the aName parameter.

              • -

            • Z: drive -if the optional drive is not set in the aName parameter.

              • -

            The current system language is then taken as a given language. All -the available resource file names are prioritized according to the equivalent -language list. The resource file name with the highest priority is -returned.

            • -
           - -Getting -an Equivalent Language List - -Getting -a Nearest Equivalent Language - - + + + + + +Getting Equivalent and Nearest Equivalent Languages This section describes how to call functions of BaflUtils to get an equivalent language list and a nearest +equivalent language. +

          This tutorial +assumes that you have an understanding of Equivalent Language +Reference which explains the equivalent language table, including +the equivalent language list and its priority.

           +

          BaflUtils provides the following two static functions to +get the equivalent language list and a nearest equivalent language:

            +
          • GetEquivalentLanguageList(TLanguage aLang, TLanguagePath& aEquivalents)

            For a given language (TLanguage), it returns +an array (TLanguagePath) which contains the equivalent +languages. If no equivalent language is found, ELangNone is returned.

            • +
          • NearestLanguageFileV2(const RFs& aFs,TFileName& aName, TLanguage& aLanguage)

            A TLanguage value is used at the end of a +resource file name to identify a resource file for a language. For +example, filename.r01 and filename.r02 are the English and French versions of the filename.rsc resource file.

            An application calls BaflUtils::NearestLanguageFileV2() to determine which localized resource file is the closest to the +current system language. The function searches the following drives +in the given sequence for the available resource files, which have +the same file name (without extension) as aName. +Once the resource files are searched on a drive, the function stops +searching on the next drive.

              +

            • The custom resource +drive if it is set using the HAL::ECustomResourceDrive attribute or the legacy HAL::ESystemDrive attribute.

              • +

            • The optional +drive if it is specified in the aName parameter.

              • +

            • Z: drive if the optional drive is not set in the aName parameter.

              • +

            The current system language is then taken as a given language. +All the available resource file names are prioritized according to +the equivalent +language list. The resource file name with the highest priority +is returned.

            • +
           + +Getting an Equivalent +Language List + +Getting a Nearest +Equivalent Language + +           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCC51FFE-DC34-5168-9564-8F30273DE1BD_d0e306369_href.png Binary file Symbian3/SDK/Source/GUID-FCC51FFE-DC34-5168-9564-8F30273DE1BD_d0e306369_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCC51FFE-DC34-5168-9564-8F30273DE1BD_d0e312843_href.png Binary file Symbian3/SDK/Source/GUID-FCC51FFE-DC34-5168-9564-8F30273DE1BD_d0e312843_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCE138BF-A471-5864-AE4C-8D89EF5F2BB9.dita --- a/Symbian3/SDK/Source/GUID-FCE138BF-A471-5864-AE4C-8D89EF5F2BB9.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,49 +0,0 @@ - - - - - -Symbian -Emulator target using Metrowerks CodeWarrior -

          This page describes how to build for the Symbian emulator using the Metrowerks -CodeWarrior compiler. The Symbian emulator is also known as the WINSCW build -target.

          -
          Building from the command line

          To build for WINSCW, -with abld use:

          bldmake bldfiles

          abld -build winscw [udeb | urel]

          Binaries are generated in the udeb and/or urel sub-directories -of the epoc32\release\winscw\ directory.

          -
          Building from the CodeWarrior IDE

          You can build -applications for a WINSCW Symbian emulator using the CodeWarrior compiler -from the CodeWarrior IDE. You can also build for ARM targets from the IDE: -this invokes the native toolchain, rather than CodeWarrior's own compiler.

          The -simplest way to use CodeWarrior, is, after defining a bld.inf file -and a .mmp file, choose the File - | Import project from .mmp file command. CodeWarrior then -reads the .mmp file that you select, and generates and -opens a CodeWarrior project. You can then use the normal CodeWarrior commands -to run, build, and debug the project.

          If later you change the .mmp file, -you can use the same commands to regenerate the IDE workspace. Changes you -make to the project made through the IDE, such as adding a source file, are -not automatically written to the .mmp file, but it is -good practice to manually keep the .mmp file up to date -with any changes made.

          The IDE project files have special build steps -which invoke the resource compiler, so for projects that use resources, this -does not need to be run separately.

          Alternative method

          A -slightly longer method is available that creates a CodeWarrior IDE project -from the command line. To do this, run bldmake bldfiles as -described, and then, to generate a CodeWarrior IDE project, use:

          abld -makefile CW_IDE

          This creates an importable project file project-name .xml in -the directory <path>\epoc32\build\ absolute_path_to_mmp_file \ mmp_basename \winscw\.

          You can now tell CodeWarrior to read -this file and from it generate a project file of its own native type (an .mcp file). -Start CodeWarrior, choose the File | Import Project... command, -select the HelloWorld.xml file, and choose a name for -the CodeWarrior project (such as HelloWorld again). CodeWarrior -will now generate and load the project, which you can build, run, debug, etc. -using the normal IDE commands.

          -           \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCEDC338-61CA-5D10-A8DB-E44A3EBBDE5E.dita --- a/Symbian3/SDK/Source/GUID-FCEDC338-61CA-5D10-A8DB-E44A3EBBDE5E.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FCEDC338-61CA-5D10-A8DB-E44A3EBBDE5E.dita Tue Jul 20 12:00:49 2010 +0100 @@ -36,7 +36,7 @@ A FEP places its control on the stack with a high priority such that it has first access to key events.

          FEP Base - +

          The Window Server provides support for windows that float above other windows in the application. This allows a FEP to have a visible presence.

          Each running application has its own instance of the current FEP. Support is provided diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCFF0750-0AE9-5F51-B4F7-B1655E1AD244_d0e215760_href.png Binary file Symbian3/SDK/Source/GUID-FCFF0750-0AE9-5F51-B4F7-B1655E1AD244_d0e215760_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FCFF0750-0AE9-5F51-B4F7-B1655E1AD244_d0e220758_href.png Binary file Symbian3/SDK/Source/GUID-FCFF0750-0AE9-5F51-B4F7-B1655E1AD244_d0e220758_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD0593E7-A36C-4656-A85A-9D62DFBCC42F_d0e194260_href.png Binary file Symbian3/SDK/Source/GUID-FD0593E7-A36C-4656-A85A-9D62DFBCC42F_d0e194260_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD0593E7-A36C-4656-A85A-9D62DFBCC42F_d0e199266_href.png Binary file Symbian3/SDK/Source/GUID-FD0593E7-A36C-4656-A85A-9D62DFBCC42F_d0e199266_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD1BB5C6-A042-56C9-8F1F-B51BF9DF5389_d0e364394_href.png Binary file Symbian3/SDK/Source/GUID-FD1BB5C6-A042-56C9-8F1F-B51BF9DF5389_d0e364394_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD1BB5C6-A042-56C9-8F1F-B51BF9DF5389_d0e383543_href.png Binary file Symbian3/SDK/Source/GUID-FD1BB5C6-A042-56C9-8F1F-B51BF9DF5389_d0e383543_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD21D8B1-EB37-409A-9158-19DBBF1A67B7_d0e72846_href.png Binary file Symbian3/SDK/Source/GUID-FD21D8B1-EB37-409A-9158-19DBBF1A67B7_d0e72846_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD21D8B1-EB37-409A-9158-19DBBF1A67B7_d0e72873_href.png Binary file Symbian3/SDK/Source/GUID-FD21D8B1-EB37-409A-9158-19DBBF1A67B7_d0e72873_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD503B6E-889C-521F-B61A-0EBDCA8CD9AC_d0e355285_href.png Binary file Symbian3/SDK/Source/GUID-FD503B6E-889C-521F-B61A-0EBDCA8CD9AC_d0e355285_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD503B6E-889C-521F-B61A-0EBDCA8CD9AC_d0e384278_href.png Binary file Symbian3/SDK/Source/GUID-FD503B6E-889C-521F-B61A-0EBDCA8CD9AC_d0e384278_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD52DFC5-03CD-4C7A-B118-0D5C90D99F1A_d0e71700_href.png Binary file Symbian3/SDK/Source/GUID-FD52DFC5-03CD-4C7A-B118-0D5C90D99F1A_d0e71700_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FD52DFC5-03CD-4C7A-B118-0D5C90D99F1A_d0e71727_href.png Binary file Symbian3/SDK/Source/GUID-FD52DFC5-03CD-4C7A-B118-0D5C90D99F1A_d0e71727_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE3825C5-BDEE-5F18-9FFD-2E794E618FEC.dita --- a/Symbian3/SDK/Source/GUID-FE3825C5-BDEE-5F18-9FFD-2E794E618FEC.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FE3825C5-BDEE-5F18-9FFD-2E794E618FEC.dita Tue Jul 20 12:00:49 2010 +0100 @@ -11,7 +11,7 @@ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> Data Access ExampleThis example describes typical processing of the data in an RMBufChain.

          Downwards flow Example : flow going downwards -

          The following function is a simplified example of how a component in the middle of the stack could process data sent to the driver. As shown in the above diagram, the upper layer provides the data in the RMBufChain parameter.

          +

          The following function is a simplified example of how a component in the middle of the stack could process data sent to the driver. As shown in the above diagram, the upper layer provides the data in the RMBufChain parameter.

          void Send (RMBufChain &aChain) { TBuf8<KHeaderLength> aHeader; @@ -29,7 +29,7 @@ }

          Note that depending on the available space remaining in front of the data in the MBuf, the RMBufChain::Prepend() method may request the pond to add a new MBuf to the front of the chain. For more information, see Buffer layout.

          Upwards flow Example : flow going upwards -

          The following function is a simplified example of how a component in the middle of the stack could process data received by the driver. As shown in the above diagram, the underlying layer provides the data in the RMBufChain parameter.

          +

          The following function is a simplified example of how a component in the middle of the stack could process data received by the driver. As shown in the above diagram, the underlying layer provides the data in the RMBufChain parameter.

          void Process (RMBufChain &aChain) { TBuf8<KHeaderLength> aHeader; diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE3C8D39-CE17-5AC7-AB6A-4D6664D52196_d0e184843_href.png Binary file Symbian3/SDK/Source/GUID-FE3C8D39-CE17-5AC7-AB6A-4D6664D52196_d0e184843_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE3C8D39-CE17-5AC7-AB6A-4D6664D52196_d0e189840_href.png Binary file Symbian3/SDK/Source/GUID-FE3C8D39-CE17-5AC7-AB6A-4D6664D52196_d0e189840_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE4BBEB4-4E5A-5BF2-A72F-AF53BAD83518_d0e187538_href.png Binary file Symbian3/SDK/Source/GUID-FE4BBEB4-4E5A-5BF2-A72F-AF53BAD83518_d0e187538_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE4BBEB4-4E5A-5BF2-A72F-AF53BAD83518_d0e192526_href.png Binary file Symbian3/SDK/Source/GUID-FE4BBEB4-4E5A-5BF2-A72F-AF53BAD83518_d0e192526_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE9017F4-4197-472F-A3E7-267169A51ABD.dita --- a/Symbian3/SDK/Source/GUID-FE9017F4-4197-472F-A3E7-267169A51ABD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FE9017F4-4197-472F-A3E7-267169A51ABD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,53 +1,49 @@ - - - - - -Registration -

          You need to register your applications in order to make them visible -to the application menu and to provide other information to the underlying -operating system. To register, you need to provide a registration resource -file, typically named <application_name>_reg.rss that -contains the non-localized information for your application. Examples of non-localized -information include:

          -
            -

          • UID of the application

            • -

          • name of the application executable, without an extension

            -
            • -

          • application properties, such as embeddability or whether -it is hidden

            • -
          -

          For more information on how to create a registration file for the non-localized -information for your application, see Creating -registration resource files.

          -

          You also need to provide localized information for your applications, -such as captions and icons. This is done by either including a name and path -of a localizable icon and caption resource file or the symbolic ID of a LOCALISABLE_APP_INFO data -structure in your application UI resource file. For a discussion of the available -options for where you can place this resource statement, see Localisable -icon/caption definition files.

          -

          You may define the following localized information:

          -
            -

          • application caption, which is typically displayed next to -the icon in the application menu

            • -

          • short caption used by some mobile devices when screen space -is limited

            • -

          • name of the icon file

            • -
          -

          For more information on using the LOCALISABLE_APP_INFO data -structure, see Defining -localizable registration information

          - -

          You must compile both the non-localized information registration resource -file and the localized information resource file and include the results in -your package file in order for your application to be registered in a mobile -device.

          - -           + + + + + +Registration +

          You need to register your applications in order to make them +visible to the application menu and to provide other information to +the underlying operating system. To register, you need to provide +a registration resource file, typically named <application_name>_reg.rss that contains the non-localized information for your application. +Examples of non-localized information include:

          +
            +

          • UID of the application

            • +

          • name of the application executable, without an extension

            +
            • +

          • application properties, such as embeddability or +whether it is hidden

            • +
          +

          For more information on how to create a registration file for +the non-localized information for your application, see Creating registration resource files.

          +

          You also need to provide localized information for your applications, +such as captions and icons. This is done by either including a name +and path of a localizable icon and caption resource file or the symbolic +ID of a LOCALISABLE_APP_INFO data structure in +your application UI resource file. For information about localisable +icons, see Symbian^3 Tools Guide > Building.

          +

          You may define the following localized information:

          +
            +

          • application caption, which is typically displayed +next to the icon in the application menu

            • +

          • short caption used by some mobile devices when screen +space is limited

            • +

          • name of the icon file

            • +
          +

          For more information on using the LOCALISABLE_APP_INFO data structure, see Defining localizable registration information

          + +

          You must compile both the non-localized information registration +resource file and the localized information resource file and include +the results in your package file in order for your application to +be registered in a mobile device.

          + +                     \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE922294-380D-447D-AC46-A46EFAD79168.dita --- a/Symbian3/SDK/Source/GUID-FE922294-380D-447D-AC46-A46EFAD79168.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FE922294-380D-447D-AC46-A46EFAD79168.dita Tue Jul 20 12:00:49 2010 +0100 @@ -30,7 +30,7 @@ right, then top-to-bottom. In right-to-left languages, the order is flipped horizontally.

        -Default grid-filling +<table id="GUID-B2580444-D5A5-4E29-A33E-F4C8B0EA9B69-GENID-1-10-1-7-1-1-5-1-8-1-1-6-1-2-4"><title>Default grid-filling order: Left-to-right UI languages @@ -54,7 +54,7 @@ -
        Default +</table><table id="GUID-B2580444-D5A5-4E29-A33E-F4C8B0EA9B69-GENID-1-10-1-7-1-1-5-1-8-1-1-6-1-2-5"><title>Default grid-filling order: Right-to-left UI languages @@ -120,6 +120,6 @@ only scroll down commands used. b) Left-to-right UI language; only scroll right commands used. c) Right-to-left UI language; only scroll down used. d) Right-to-left UI language; only scroll right used. - + \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FE94596E-B5BB-51FE-BE38-069840323915.dita --- a/Symbian3/SDK/Source/GUID-FE94596E-B5BB-51FE-BE38-069840323915.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FE94596E-B5BB-51FE-BE38-069840323915.dita Tue Jul 20 12:00:49 2010 +0100 @@ -16,7 +16,7 @@ GSM encoding supports the GSM 7-bit default alphabet and GSM 7-bit default alphabet extension table through an escape mechanism.

        Figure 1

        Escape mechanism - +

        The GSM 7-bit default alphabet consists of 128 characters. Each character is represented by 7 bits. 10 extra characters are defined in the GSM 7-bit default extension table. These characters are represented by an @@ -43,7 +43,7 @@ be decoded back to the same Unicode letter A instead of Á.

        Figure 2

        Lossy conversion - +
        16-bit Unicode encoding

        Unicode is an international standard character set. It @@ -74,7 +74,7 @@ as locking-single.

        Figure 3

        National language encoding - +

        The single shift mechanism is useful when a message contains only a few characters outside the default GSM table. It is however inefficient when a message contains many unsupported characters, because each escaped diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FEFF353E-DE8A-5FBA-B696-CD01D06BE813_d0e187563_href.png Binary file Symbian3/SDK/Source/GUID-FEFF353E-DE8A-5FBA-B696-CD01D06BE813_d0e187563_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FEFF353E-DE8A-5FBA-B696-CD01D06BE813_d0e192551_href.png Binary file Symbian3/SDK/Source/GUID-FEFF353E-DE8A-5FBA-B696-CD01D06BE813_d0e192551_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FF08B8F5-9881-5BA3-ACD1-C09E40A09438.dita --- a/Symbian3/SDK/Source/GUID-FF08B8F5-9881-5BA3-ACD1-C09E40A09438.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FF08B8F5-9881-5BA3-ACD1-C09E40A09438.dita Tue Jul 20 12:00:49 2010 +0100 @@ -19,7 +19,7 @@ collection. The following diagram shows the architecture of the Multimedia Plug-ins collection:

        Multimedia Plug-ins architecture - +
        Description

        The Multimedia Plug-ins collection provides a generic plug-in architecture for the Camera Framework, Imaging diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FF312AAD-E40B-5238-A31C-B34AFD892D5A.dita --- a/Symbian3/SDK/Source/GUID-FF312AAD-E40B-5238-A31C-B34AFD892D5A.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,48 +0,0 @@ - - - - - -Static -interface DLLs -

        A static interface DLL represents an interface which is defined to its -clients by one or more headers for use at compile time, and an import library -for use at link time.

        -

        When a executable that is a client of the DLL is loaded at run-time, the -loader notes that it requires the static interface DLL to be available. The -loader then either loads the DLL or, if it is loaded already, attaches the -new client to it.

        -

        In Symbian platform, all static interface DLLs must have a uid2 of 0x1000008d. -The particular static interface DLL is then identified by name and by uid3.

        -

        For example, if a DLL called helloview.dll is built -with a uid3 of 0x10000252, then the name used in the import -library for ARM builds of Symbian platform is helloview[10000252]. -When the loader loads the helloview.dll, it checks that -its UID is 0x10000252. If the uid3 in the -DLL does not match, then the load fails.

        -
        mmp project specification

        A static interface DLL -project file must specify the correct target type and UID:

          -

        • Specify the TARGETTYPE line -as:

          TARGETTYPE dll

          This -implicitly specifies UID1 correctly.

          • -

        • Specify the UID for -the DLL in a UID line:

          UID 0x1000008d -<UID3>

          • -
        -

        An example of the mmp project file for a -static DLL is given below:

        TARGET CreateStaticDLL.dll -TARGETTYPE dll -UID 0x1000008d 0x10004268 -SOURCEPATH . -SOURCE CreateStaticDLL.cpp -USERINCLUDE . -SYSTEMINCLUDE \Epoc32\include -LIBRARY euser.lib -EXPORTUNFROZEN         - \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FF81C5C5-09B7-5194-928E-0BA87417B2CD.dita --- a/Symbian3/SDK/Source/GUID-FF81C5C5-09B7-5194-928E-0BA87417B2CD.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-FF81C5C5-09B7-5194-928E-0BA87417B2CD.dita Tue Jul 20 12:00:49 2010 +0100 @@ -10,6 +10,6 @@ What are Access Point Priorities?This topic explains access point priorities and how the values are inherited.

        Contention management issues are resolved using the priorities associated with the Access Points. Priorities are assigned to Access Point Layers. If an incoming GPRS connection has a higher priority than an existing GRPS connection, the existing connection is stopped and the new connection is started. If the incoming GPRS connection has a lower priority than all existing GPRS connections the incoming GPRS connection is discarded.

        The Access Point priority is stored in the CommsDat AccessPointTable. You can specify a priority for access point using the CommsData config file in “cfg” format. The priority range is 1-KMaxTUint where 1 is high priority and KMaxTUint is low priority. If a priority is not assigned to an access point the default value is KMaxTUint is given. A zero priority value is not allowed.

        Access Point Priority Inheritance Example

        Access Point Priorities can be inherited between Access Point Layers. The current Access Point Layer priority is compared to the inherited Access Point priority, the highest priority is assigned to the Point Layer. This means that the priority of an Access point layer can be overridden by an inherited priority.

        CurrentPriority = max_priority{AccessPointPriority, - inherited_priority}

        The following diagram contains three Access Point Layers. Each Access Point Layer has an associated priority.

        As a result of inheritance the following priorities are applied.

        For IP_MCPR1 the resultant priority is {3, KmaxTUint} = 3

        For IPPROTO_MCPR1 the resultant priority is {3, 5} = 3

        For PDP_MCPR1 the resultant priority is {4, 3} = 3

        Changes in Access Point Priorities at Runtime

        The following diagram outlines how priorities can change at runtime.

        In this example:

        • Two stack configurations (SNAP1 and SNAP2) are defined in the CommsDat. The configurations have different settings for the IP layer but the same IPProto and PDP layers.

        • An application is started on SNAP1. IP_CPR1 and IP_MCPR1 are created.

        • A second application is started on SNAP2. IP_CPR2 and IP_MCPR2 are created.

        • Current priorities for IPProto and PDP layer will be recalculated. On this example they do not change because priority 6 is the lowest priority in this stack.

        • If first application stops its connection and second application continue to work, IP_CPR1 is destroyed. IPPROTO_CPR1 and PDP_CPR1 priorities will be recalculated.

          IPPROTO_CPR1 priority = max_priority{5, 6} = 5

          PDP_CPR1 priority = max_priority{4, 5} = 4

        What is Contention? What is Contention + inherited_priority}

        The following diagram contains three Access Point Layers. Each Access Point Layer has an associated priority.

        As a result of inheritance the following priorities are applied.

        For IP_MCPR1 the resultant priority is {3, KmaxTUint} = 3

        For IPPROTO_MCPR1 the resultant priority is {3, 5} = 3

        For PDP_MCPR1 the resultant priority is {4, 3} = 3

        Changes in Access Point Priorities at Runtime

        The following diagram outlines how priorities can change at runtime.

        In this example:

        • Two stack configurations (SNAP1 and SNAP2) are defined in the CommsDat. The configurations have different settings for the IP layer but the same IPProto and PDP layers.

        • An application is started on SNAP1. IP_CPR1 and IP_MCPR1 are created.

        • A second application is started on SNAP2. IP_CPR2 and IP_MCPR2 are created.

        • Current priorities for IPProto and PDP layer will be recalculated. On this example they do not change because priority 6 is the lowest priority in this stack.

        • If first application stops its connection and second application continue to work, IP_CPR1 is destroyed. IPPROTO_CPR1 and PDP_CPR1 priorities will be recalculated.

          IPPROTO_CPR1 priority = max_priority{5, 6} = 5

          PDP_CPR1 priority = max_priority{4, 5} = 4

        What is Contention? What is Contention Management? Starting a Network Connection Tutorial         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFBB390B-0A5D-5ABC-A111-95B3C84818DE_d0e79925_href.png Binary file Symbian3/SDK/Source/GUID-FFBB390B-0A5D-5ABC-A111-95B3C84818DE_d0e79925_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFBB390B-0A5D-5ABC-A111-95B3C84818DE_d0e79983_href.png Binary file Symbian3/SDK/Source/GUID-FFBB390B-0A5D-5ABC-A111-95B3C84818DE_d0e79983_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFC6F01E-15AB-43E6-90E8-0E42DA297AE9_d0e5124_href.png Binary file Symbian3/SDK/Source/GUID-FFC6F01E-15AB-43E6-90E8-0E42DA297AE9_d0e5124_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFC6F01E-15AB-43E6-90E8-0E42DA297AE9_d0e5245_href.png Binary file Symbian3/SDK/Source/GUID-FFC6F01E-15AB-43E6-90E8-0E42DA297AE9_d0e5245_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFD56DA3-9301-5679-9209-A70CE63A34A2.dita --- a/Symbian3/SDK/Source/GUID-FFD56DA3-9301-5679-9209-A70CE63A34A2.dita Fri Jul 16 17:23:46 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12 +0,0 @@ - - - - - -How to initialise LINK and LLINK RESOURCE members

        A LINK or LLINK member must be initialised with a resource-identifier. This resource identifier may be in the form of a resource name or a number.

        • To specify a resource in the same file, use the resource name in lower case.

          It is not necessary for the resource to be defined at the time the statement is processed, but an error will result if the resource is not defined in the entire file. When declared in lower case any NAME specified in the file will be added onto the resource id.

        • To specify a resource in a different file, use the resource name in upper case.

          To reference it you must #include the relevant header file containing the resource. All resource names are turned into upper case when their #define s are generated in the header file — this is how the resource compiler recognises that it must look for the resource in another file. If this resource does not exist in any #include d file then an error is generated.

        • The resource identifier may also be specified as a number: in this case it is the resource id (including NAME).

          If no such resource id exists either in the file or any #include d header files, no error is generated by the compiler. The programmer must therefore ensure that the id is a valid reference.

        See Resource file definition for information on how resource ids are generated. See also NAME statement and related statements.

         \ No newline at end of file diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFE6BAF8-C093-53FC-8672-365BAF38E048_d0e338240_href.png Binary file Symbian3/SDK/Source/GUID-FFE6BAF8-C093-53FC-8672-365BAF38E048_d0e338240_href.png has changed diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-FFE6BAF8-C093-53FC-8672-365BAF38E048_d0e344706_href.png Binary file Symbian3/SDK/Source/GUID-FFE6BAF8-C093-53FC-8672-365BAF38E048_d0e344706_href.png has changed