Location:
W32STD.H
Link against: ws32.lib
class RAnim;
Client-side handle to a server-side animation class.
This class should be sub-classed to provide a client side interface to the server side animation DLL. The server side animation
DLL is derived from CAnim
.
Defined in RAnim
:
AsyncCommandReply()
, Close()
, Command()
, Command()
, CommandReply()
, CommandReply()
, CommandReply()
, Construct()
, Construct()
, Construct()
, Construct()
, Destroy()
, RAnim()
, RAnim()
, ~RAnim()
protected: IMPORT_C RAnim();
Default constructor. Developers should use the other constructor overload.
protected: IMPORT_C RAnim(RAnimDll &aDll);
Protected C++ constructor.
This constructor should be used to construct an animation object from a given animation DLL. The DLL must be loaded first,
see the discussion of RAnimDll
.
|
virtual IMPORT_C void Close();
Sends the close command.
This frees resources belonging to an animation object. It would be called to release resources when the RAnim is owned in-line by another object (so that destruction is automatic).
This function always causes a flush of the window server buffer.
IMPORT_C void Destroy();
Closes and deletes the server-side animation object.
This should be called on heap allocated objects.
This function always causes a flush of the window server buffer.
protected: IMPORT_C TInt Construct(const RWindowBase &aDevice, TInt aType, const TDesC8 &aParams);
Completes construction of the object based on a window device, and creates the server-side animation system.
Construction information is passed to the server side via aType and aParams. The server then passes the information to the function CreateInstanceL() inside the Anim DLL.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt Construct(const RWindowBase &aDevice, TInt aType, const TDesC8 &aParams, const TIpcArgs &aIpcArgs);
Completes construction of the object based on a window device, and creates the server-side animation system.
Construction information is passed to the server side via aType and aParams. The server then passes the information to the function CreateInstanceL() inside the Anim DLL.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt Construct(const RWsSprite &aDevice, TInt aType, const TDesC8 &aParams);
Completes construction of the Anim DLL based on a sprite.
Construction information is passed to the server side via aType and aParams. The server then passes the information to the function CreateInstanceL() inside the Anim DLL.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt Construct(const RWsSprite &aDevice, TInt aType, const TDesC8 &aParams, const TIpcArgs &aIpcArgs);
Completes construction of the Anim DLL based on a sprite.
Construction information is passed to the server side via aType and aParams. The server then passes the information to the function CreateInstanceL() inside the Anim DLL.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt CommandReply(TInt aOpcode);
Sends a command to the server-side CAnim
instance, and waits for a response.
This function executes synchronously and returns the code returned by the server-side method CAnim::CommandReplyL()
. The request is not buffered.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt CommandReply(TInt aOpcode, const TPtrC8 &aArgs);
Sends a command and its arguments to the server-side CAnim
instance, and waits for a response.
The packaged command arguments are passed to the matching server side function, where the behaviour should be implemented.
The request is not buffered. The function executes synchronously and returns the code returned by the server-side method CAnim::CommandReplyL()
.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C TInt CommandReply(TInt aOpcode, const TDesC8 &aArgs, const TIpcArgs &aIpcArgs);
Sends a command and its arguments to the server-side CAnim
instance, and waits for a response.
The IPC (inter-process communication) arguments are passed to the matching server side function, where the behaviour should
be implemented. The request is not buffered. The function executes synchronously and returns the code returned by the server-side
method CAnim::CommandReplyL()
. The first slot of the TIpcArgs
parameter is reserved for internal use.
This function always causes a flush of the window server buffer.
|
|
protected: IMPORT_C void Command(TInt aOpcode, const TPtrC8 &aArgs);
Sends a command and its arguments to the server-side CAnim
instance, and returns immediately.
Commands issued by this function may be buffered before being passed to the server.
Server-side errors cannot be detected, so Command()
should not be used for operations which could fail or which may leave. Use CommandReply()
for those. Although the window server will not fail due to errors not being returned to the client side, client side behaviour
will almost certainly not be correct if errors have been generated but not received.
Use of this function results in a server-side call to the equivalent CAnim::Command()
.
|
protected: IMPORT_C void Command(TInt aOpcode);
Sends a command to the server-side CAnim
instance, and returns immediately.
Commands issued by this function may be buffered before being passed to the server.
Server-side errors cannot be detected, so Command()
should not be used for operations which could fail or which may leave. Use CommandReply()
for those. Although the window server will not fail due to errors not being returned to the client side, client side behaviour
will almost certainly not be correct if errors have been generated but not received.
Use of this function results in a server-side call to the equivalent CAnim::Command()
.
|
protected: IMPORT_C void AsyncCommandReply(TRequestStatus &aRequestStatus, TInt aOpcode, const TIpcArgs &aIpcArgs);
Sends a command and its arguments to the server-side CAnim
instance asynchronously.
The IPC (inter-process communication) arguments are passed to the CAnim-derived class' CommandReplyL function, where the behaviour
should be implemented. The request is not buffered - rather the function executes asynchronously. The first and second slots
of the TIpcArgs
parameter are reserved for internal use.
If the code calling this function is itself an API that is asynchronous (i.e. if the TRequestStatus
passed into this function is simply a parameter to a higher-level API), then that higher-level API should typically provide
a corresponding "Cancel" function that its own clients can use to cancel their asynchronous request - this would typically
be implemented by the higher-level API by using RAnim::CommandReply
.
|