Event Control

An IDL object which processes widget events as an alternative to using xmanager


IDL has several user interface (UI) components:

  2. IDL widgets
  3. Graphics atoms (The view tree)
A conventional application builds a UI with combination of IDL widgets and Graphics atoms. The graphics atoms are rendered on a widget_draw() canvas. A single event loop is registered using the XMANAGER procedure, and the event handler updates the widgets and atoms.
Event handler
  • Widget_Base
  • Widget_Draw
    Graphics Atoms

nmtkcontrol is an alternative to using coventional UI components.

nmtkcontrol is better than xmanager because it has better support for multiple controls within the same UI.Each control is responsible for:

  1. Managing and rendering top level graphics atoms
    It is possible to add the same top level graphics atom to many different controls. This allows for specialised aspects of rendering and managment of a graphics tree to be performed by different controls. For example, one control might handle an image, whilst the other might control a plot on the same window.
  2. Registering and handling events
    It is also possible to register the same WIDGET_DRAW to many different controls. This allows for specialised event processing to be performed by different controls. For example one control might handle mouse motion events, whilst the other might handle WIDGET_BUTTON events.
  3. Interacting with the data model
    Controls may need to notify other subsystems of changes to the UI. The exact architecture of these systems are not a core concern at present. I have included a method for notifying a change to a specified nmtkactivity, however, I am yet to decide upon an officially supported data model.

The difference between xmanager is nmtkcontrol can be shown schematically (below). Each UI component is disentangled because there can be a many to many relationship between components.

Graphics Atoms

Managing and rendering top level graphics atoms

It is possible to add top level graphics atoms to be managed by nmtkcontrol. In each case, a realized WIDGET_DRAW must be specified as the target window.

Initialise the control object
oControl = obj_new("nmtkcontrol")
Add a top level view to be managed by this control
oControl -> AddView, widget_draw_id, oView
Add a view which belongs to a top level scene to be managed by this control
oControl -> AddScene, widget_draw_id, oScene, oView
Once the views or scenes have been added, it is possible to render them by calling
oControl -> Redraw

Registering and handling events

It is possible to register widgets for event processing. The events are handled by the nmtkcontrol::event procedure.

Initialise the control object and enable event processing
oControl = obj_new("nmtkcontrol",ENABLED=1)
Register a widget for event processing (without blocking)
oControl -> Register, widget_id, /JUST_REG
Specify a cursor to be set upon next redraw of a WIDGET_DRAW
oControl -> SetProperty, CURSOR_NAME="CROSSHAIR"

Writing an event handler for a control is achieved by overriding nmtkcontrol::event. If the event occured within a graphics atom, then it is possible to find the location of the event with respect to the units of the specified atom.

pro mycontrol::event, ev
 location = self -> conv_coord(ev,oAtom)
 print, "X:",location[0], "Y:",location[1]

Interacting with the data model

nmtkcontrol is generic and not designed for any particular data model. However, nmtkcontrol does include a signalling mechanism which is compatible withIDLitIMessage. This mechanism useful for synchronising controls. It is possible to send signals to multiple Observers after each event is processed.