This section discusses some basic ideas and concepts that are central to the process of writing IDL widget applications.
IDL widgets are uniquely identified via their widget IDs. The widget ID is a long integer assigned to the widget when it is first created; this integer is returned as the value of the widget creation function. For example, you might create a base widget with the following IDL command:
base = WIDGET_BASE()
Here, the IDL variable base receives the widget ID of the newly-created top-level base widget.
Routines within your widget application that need to retrieve data from widgets or change their appearance need access to the widgets' IDs. Techniques for passing widget IDs between independent routines in your widget application are discussed in Working With Widget IDs.
With one exception (described below), when you create a new widget using one of the WIDGET_* functions, you specify the widget ID of the new widget's parent widget. This parent-child relationship defines a widget hierarchy.
For example, suppose you have created a base widget whose widget ID is contained in the IDL variable base. The following IDL command creates a button widget that is a child of the base widget whose widget ID is stored in the variable base:
button1 = WIDGET_BUTTON(base, VALUE='Test button')
In addition to being below base in the widget hierarchy, button1 appears inside base1 when the base widget is realized on the screen.
The exception to this parent-child rule is a special instance of a base widget called a top-level base. A top-level base is different from an "ordinary" base widget in the following ways:
In practice, a widget application always begins with a top-level base. The fact that the widget ID of the top-level base widget is always available in the event structure of widget events is very useful for managing the state of a widget application. This topic is discussed in depth in Managing Application State.
IDL widgets provide a platform-independent abstraction layer on top of the graphical interface toolkits of the different operating systems supported by IDL. This abstraction layer allows you to create a graphical user interface once, and let IDL do the work of translating and displaying the interface on different platforms.
When you use one of the widget creation routines, IDL creates a widget record that represents one or more native widgets in the current platform's user interface toolkit. The widget record is used to contain all of the information needed by IDL to manage the widget's state. The platform-specific native widget that underlies the IDL widget is not created (or instantiated) until you call the WIDGET_CONTROL procedure with the REALIZE keyword (see Manipulating Widgets for details on using WIDGET_CONTROL). Between the time when the widget is created as an IDL widget record and when it is realized as a platform-specific interface element, you have control over many, but not all, aspects of the widget's state. Some details of the final realized widget's state (such as its exact screen geometry) may remain undetermined until the widget is instantiated.
It is important to note that unrealized widgets in a widget hierarchy can be manipulated programmatically. Examples of attributes you can manipulate before realization are the overall geometry of the user interface, widget values, and user values. You can even retrieve widget values before the widgets are realized. Unrealized widgets do not, however, generate widget events, since the actual platform-specific user interface has yet to be created.
Once a widget has been realized, its corresponding platform-specific user interface toolkit element is instantiated. The native toolkit determines the widget's exact screen geometry. If the widget is then mapped, it becomes visible on the computer screen, can be manipulated by a user, and generates widget events.
| Note |
Note also that widgets that are visible on screen can be made unavailable to the user by setting the SENSITIVE keyword to WIDGET_CONTROL. See Sensitizing Widgets for details.