diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-37CB6D0C-41F0-5C52-A925-978FAC30D311.dita --- a/Symbian3/PDK/Source/GUID-37CB6D0C-41F0-5C52-A925-978FAC30D311.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-37CB6D0C-41F0-5C52-A925-978FAC30D311.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,48 +1,48 @@ - - - - - -Implementing -the Client Side -

The animation framework requires implementers to write server side and -client side code. On the client side, provided by the Window Server Client-Side -API, RAnimDll should be derived from -for DLL level functionality, and for each animation an RAnim class -should be derived. The client side classes can be thought of as thin layers -of code that are used to pass information through to the matching server side -classes, where the detailed logic is implemented.

-

Clients must request an animation DLL to be loaded before the animations -provided by it can be used. This is done using the RAnimDll.

-

RAnim provides functions for implementing client side -behavior. Generally, the client side code is concerned with setting up and -initializing the server side classes which implement the actual animation -graphics. The mechanisms that allow information to be packaged on the client -side, passed through the Window Server, and recovered on the server side, -are described in Passing -Arguments from Client to Server.

-

Two kinds of command function are provided, RAnim::Command() and RAnim::CommandReply(). The choice of which one -to use depends on whether a return value is required and whether the command -takes effect immediately or can be cached to the Window Server queue. If leaves -are possible in code within or called from a command function, a return code -should be tested and errors handled appropriately.

-

The CommandReply() function forces immediate action. In -general by the time these functions return, Window Server requests have been -carried out. The background to this behavior is Window Server buffering of -the requests it receives. In effect the behavior of these commands is to put -a request to the Window Server queue and then flush the queue to ensure immediate -action. The Command() function is buffered by the Window -Server. Although these functions return immediately, there is no guarantee -when the Window Server request will actually be carried out.

- -Client-Side -Buffer -Animations - + + + + + +Implementing +the Client Side +

The animation framework requires implementers to write server side and +client side code. On the client side, provided by the Window Server Client-Side +API, RAnimDll should be derived from +for DLL level functionality, and for each animation an RAnim class +should be derived. The client side classes can be thought of as thin layers +of code that are used to pass information through to the matching server side +classes, where the detailed logic is implemented.

+

Clients must request an animation DLL to be loaded before the animations +provided by it can be used. This is done using the RAnimDll.

+

RAnim provides functions for implementing client side +behavior. Generally, the client side code is concerned with setting up and +initializing the server side classes which implement the actual animation +graphics. The mechanisms that allow information to be packaged on the client +side, passed through the Window Server, and recovered on the server side, +are described in Passing +Arguments from Client to Server.

+

Two kinds of command function are provided, RAnim::Command() and RAnim::CommandReply(). The choice of which one +to use depends on whether a return value is required and whether the command +takes effect immediately or can be cached to the Window Server queue. If leaves +are possible in code within or called from a command function, a return code +should be tested and errors handled appropriately.

+

The CommandReply() function forces immediate action. In +general by the time these functions return, Window Server requests have been +carried out. The background to this behavior is Window Server buffering of +the requests it receives. In effect the behavior of these commands is to put +a request to the Window Server queue and then flush the queue to ensure immediate +action. The Command() function is buffered by the Window +Server. Although these functions return immediately, there is no guarantee +when the Window Server request will actually be carried out.

+ +Client-Side +Buffer +Animations + \ No newline at end of file