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.