|void||Disable_Selection_Events (const char *locater, const char *picture)|
|Disables selection events for a mouse or other pointer device. More...|
|void||Enable_Selection_Events (const char *locater, const char *display)|
|Tells the system to let the user start pointing at geometries. More...|
|void Disable_Selection_Events||(||const char *||locater,|
|const char *||picture|
Disables selection events for a mouse or other pointer device.
locater - Commonly "?locater". In general, a segment with an attached device driver that knows about a physical locater device, such as a mouse, tablet, or trackball. picture -
No additional details. See Enable_Selection_Events()
|void Enable_Selection_Events||(||const char *||locater,|
|const char *||display|
Tells the system to let the user start pointing at geometries.
locater - Commonly "?locater". In general, a segment with an attached device driver that knows about a physical locater device, such as a mouse, tablet, or trackball. display - Commonly "?Picture". In general, a segment with an attached device driver that knows how to test for selections.
In order for selection input to occur, you have to name the device you're interested in monitoring and the scene you want it tested against. Then wait for the type of event that you're interested in to occur. Then take a look at it.
The easiest way to do this is to let the high-level Get_Selection() routine do it for you. The problem with the Get routines is that unexpected events are thrown away, so you can't gracefully allow for input from a keyboard and a locater simultaneously. Also you have no control over which locater device and picture tree is picked.
If you want to do better call Enable_Selection_Events() directly to establish interest in a device and start it running. Then call Await_Event() to acquire new events. Finally call Show_Selection() (or a related routine) to take a look at the events. When your program (or subsection of your program) is done with the device, it can call Disable_Selection_Events() to restore operations to their previous state.
Different levels of your program can simultaneously have the same type of event-enable in effect. The system keeps a count of how many "enables" do not have a matching "disable" yet, and turns off the input only when this "enable count" reaches zero.
When a source of input is finally turned off, any pending events originating from it are discarded from the event queue.
The particular user actions that cause a selection search to occur or not to occur are determined by the Selectability attribute.
The system does not guarantee that an "up" selection will always intervene and be available between "down" events, although this is generally the case. The exception occurs if the event queue overflows or if the user slides out of the selected window and into another window without the button status changing.
Location events and Selection events can be enabled on the same locater simultaneously. Both events will be queued, which will be queued first is up to the system.
The "as-included-by" segment name syntax is ignored when passed to HOOPS as a segment name. This makes it hard to accurately requeue an arbitrary Selection Event.
Flagging enabled events causes confusion when a window with events enabled becomes invisible. The work around is to disable events before setting the visibility to off.
On the extended DOS platform, exiting a window with a mouse button depressed generates an event. This limitation can lead to multiple selections with a single click.