Technical information

RMS NetLinx Scheduling Client API
165
RMS Enterprise - NetLinx Programmer’s Guide
RMS NetLinx Scheduling Client API
Overview
NetLinx programmers can make use of RMS scheduling information in the following ways:
1. Query RMS for a variety of information about scheduling events. Programmers are provided with both send commands and
functions for their queries.
2. Execute commands to perform such tasks as creating or ending events. As with queries, both send commands or function calls
are provided.
3. Monitor RMS scheduling change events such as changes to monthly summary.
The response to a query or request for the execution of a task will be in the form of either a data event or the execution of a callback
function. In some cases a single command may result in more than one event type or more than one call to the same event as in the
case of reporting all the booking events for the day.
Date and Time Format Information
Unless otherwise stated, dates consist of two components, a date in the form of 'mm/dd/yyyy' and a time in the form of 'hh:mm:ss'.
The time is in 24 hour format (hours are in the range 0 through 23).
Use the RmsSetGuiDatePattern and RmsSetGuiDatePattern functions to format the Client time and date format. See Setting The
Client Time and Date Format on page 176 for details.
Location Information
Locations or location ID's in the scheduling API's are numeric values greater than zero. When using send commands, many allow
the input of a location ID in numeric format as the last argument. In most cases the location is optional and if not specified, the
default location for the client will be assumed.
In the notes for the syntax for SEND_COMMANDs, an optional location argument is indicated by parentheses.
Many commands return as part of their response an indication as to whether or not the information relates to the default location.
The response will always be the CHAR constant for 'TRUE' or 'FALSE'.
Callbacks
The RMS SDK provides a wide range of functions generally known as callbacks which are executed as part of an event
communication process. The scheduling API's follow this same approach and thus requires the programmer to determine the
callbacks of interest by including #DEFINE statements in their code. In addition, a programmer must create an implementation of
the callback function.
For specifics on the callbacks and their related #DEFINE statements, check the "RmsSchedulingApi.axi" and
"RmsSchedulingEventListener.axi" NetLinx include files.
For each of the callbacks documented below, the #DEFINE which will enable it is listed with it.
#DEFINE Compiler Directive
This directive defines a symbol to be used only by #IF_DEFINED and #IF_NOT_DEFINED compiler directives.
#DEFINE <symbol>
The name of the symbol must be unique among all other identifiers in the program. The symbol can be defined anywhere in the
program file but cannot be used in any statement that appears before it is defined.
Example:
// Specify the INCLUDE_TOGGLE_VIDEO_PROJECTOR_POWER_FUNCTION compiler
// directive if there is a video projected connected to the controller
#DEFINE INCLUDE_TOGGLE_VIDEO_PROJECTOR_POWER_FUNCTION
#IF_DEFINED INCLUDE_TOGGLE_VIDEO_PROJECTOR_POWER_FUNCTION
DEFINE_FUNCTION toggleVideoProjectorPower()
{
// code to toggle video projector power goes here
}
#END_IF