The RequestManager user class provides facilities to manage frames. It handles the standard frame-handling requests and facilitates other developer-specified requests, which are redirected to local procedures in the calling frame.

This class has a particular role in managing frames based on the active_display frame template (see "The active_display Template" in the Workbench User Guide) and containing fields generated using Display from User Class (see "Create a Display from a User Class" in the Workbench User Guide). This is mediated by the RespondToRequest method.

The way users interact with OpenROAD business applications operates on a request-response paradigm. For example:

In each of these cases the application responds appropriately, then rests until the next request.

RequestManager follows this paradigm, fielding each request and providing the appropriate response, whether it is supplied by the developer or built into the default handling.

In way of illustration: if the frame were an automobile, the RequestManager user class would be the engine, the gears, the transmission, the brakes, and the steering. It would have nothing to do with the appearance of the car.

The active_display template contains code which includes a declaration of a variable of type RequestManager called RM. The attributes belonging to the RequestManager class should be considered as readonly when they belong to the RM variable in frames that are derived from the active_display template, containing displays generated using Insert, Display From User Class in Workbench. Do not change their values, because the effects of such changes are not supported.

However, in other circumstances they can be convenient to use. For example, if you are using a QueryObject to populate a choicelist in a frame, you always must specify the frame's scope and the names of any variables populated by the query: if your frame already has a RequestManager variable declared, rather than declaring a new ChoiceField, ChoiceList, or array of ChoiceDetail variable and naming it, you can use this attribute.

All requests from the active_display built-in code come through the RespondToRequest method. The defined interface is callingframe, itemvarname (the active object, passed as a name, valid in the callingframe's scope), and info (ancillary information). If these parameters are omitted (the typical situation), they are derived from in-scope objects during the subsequent call to RespondToRequest.

Using parameters is necessary only when:

Any ad hoc call added to the code, and unrelated to the event trigger, must pass the request with the necessary information explicitly provided in the parameters. Typically such calls are direct calls to RespondToRequest from a procedure that is part of a more complex function. For example, when a window is resized, it also may require a tablefield to be resized, or vice versa. RequestManager can handle both of these situations, but only the first one can be performed using derived parameters; the second request must be made ad hoc, using explicit parameters.

RespondToRequest then determines the appropriate category of response (the type of handler to call), the triggering field, and the action that field triggers (as a keyword, identifying a case statement within the response handler). The handler may be within RequestManager as a generic local procedure, or may be in the calling frame as a developer-defined or custom facility, implemented as a local procedure.

The handler is passed the action, info, and trigger, and then executes the case block identified by the action. Typically the case block contains wrapper code around a call to an action-specific function. The outcome of any request is returned as success, failure, or not found. Not found can be returned only from a case in the frame, and indicates that the corresponding built-in function in RequestManager, if any, is to be executed.

The active_display frame template contains examples of the use of RequestManager in practice.