Functions | |
void | Show_Special_Event (char *type, char *param) |
Returns the type and parameters of the "special" event, which happens to be the current event. More... | |
Detailed Description
Function Documentation
◆ Show_Special_Event()
void Show_Special_Event | ( | char * | type, |
char * | param | ||
) |
Returns the type and parameters of the "special" event, which happens to be the current event.
- Parameters
-
type - The "type" of the special event. Usually this consists of an indication of the source of the event (e.g., "macdriver"), a colon, and an indication of what kind of event it was (e.g., "macdriver: pulldown selection"). Passed by reference always. Returned to user. param - The parameters, whatever they may be, converted into a long string, that go along with the given type of special event. If there were no parameters specified, a blank or null string is returned. Passed by reference always. Returned to user.
DETAILS
Occasionally, there is a piece of input information that needs to be communicated to your program, which does not fit into any of the regular kinds of events (mouse, keyboard, button, or wakeup). Queue_Special_Event() , Await_Event() , and Show_Special_Event() provide a mechanism for mixing an arbitrary kind of event into the incoming event queue.
The most common source of special events is a HOOPS display driver that is busy interacting with an external window system. To see if your display driver has any special event types available, check the driver's release notes. To tell a driver that it should generate special events for your program, use the "special events" Driver Option. Your program would call Await_Event() to wait for an event (special or otherwise) to occur. When a special event has occurred, your program would call Show_Special_Event() to find out about it.
You can also use special events purely internally within your program, as one method of allowing a deeply nested, or distant, utility routine to communicate gracefully (we hope) with the rest of the program. For example, a deeply nested subroutine might queue a special event of type "switch to page 2", and return. Each calling routine might then see the "switch to page 2" event in its normal event-processing loop, say "I don't know how to do that", finish up what it was doing, requeue the event, and return another level up the stack. Eventually, someone would know (we hope) how to "switch to page 2", and would take care of the matter.