Accessing Objects at Run Time

To manipulate an object at run time, you must have access to it. How you choose to access the object depends on the language in which you plan to generate code.

In C++, ViewKit, and Java, objects are declared by default as protected class members and are easy to access from within a class. To access an object from outside the class, you must define a public method, though you most likely want your method to perform any manipulation, rather than passing a widget ID out. Follow good object oriented programming practices.

In C, you can use one of the following methods:

· Set the storage location

· Set createCallback

· Use the class record

· Call Xt functions

If you are generating UIL, you can specify the widget ID with the widget name using MrmFetchWidget.

Setting the storage location

How you access widget IDs when using C depends on whether the widget storage location is already declared or if you want Builder Xcessory to declare the storage location for you. If you set the storage location to Other on the Storage Location dialog (Resource Editor:Component), you are responsible for declaring and allocating the variable in your code, such as in a User Code Block, or in another file.

When you use Other storage, it is good practice to create a structure in which to store the desired widget IDs (and any other useful data). You can then pass a pointer to this structure through to the creation routine and assign the widget ID storage to the appropriate structure members. You can also pass this structure member as client_data to your callback functions, which gives you an easy way to access various widget IDs from those callback functions.

Declaring storage location in Builder Xcessory

If you want Builder Xcessory to declare global storage, follow these steps:

1. Select Storage Location from the Resource Editor Code menu.

2. Select Global from the Storage Location option menu.

Selecting Global tells Builder Xcessory to set up the widget storage location, as well as assign the widget ID's value. This also causes the constants file to be generated.

Note: All globally-defined widget IDs are stored in the constants header file.

Declaring storage location in code

If you have declared the storage location in the code, follow these steps:

1. Select Storage Location from the Resource Editor Component menu to display the Storage Location dialog:


Storage Location Dialog

2. Select Other from the Scope text field on the Storage Location dialog

3. Enter the variable to which Builder Xcessory should assign the ID.

Note: This variable is not generated by Builder Xcessory in the source code. It is assumed to be accessible within the scope of where it is referenced. In C, this is the creation routine, in UIL, the main routine. ViewKit, C++, and Java do not allow you to set a storage location for an internal class member.

Setting createCallback

You can also save the widget ID by using a createCallback. A createCallback is similar to an actual Xt widget callback, but is called from the main file after the widget is created. The parameters passed to a createCallback are the same as those passed to an Xt callback, and allow you to access the widget ID.

You may want to use this method of accessing a widget ID if you want to perform an action immediately after a widget is created. If this is not important, declaring a Local Storage Location is a simpler method.


A creation callback might look like the following:

void createCallback(Widget w,
XtPointer client_data,
XtPointer call_data)
Widget *assign=(Widget*)client_data;


client_data is a variable or structure in which the widget ID is stored.

w is the widget that has just been created.

assign passes the address in which the widget's ID is stored.

Note: Using createCallback in this way is similar to selecting Other from the Storage Location option menu (when you have already declared the storage location). These two methods accomplish the same task.

Using the Class Record

You can access widget IDs by using the structure that Builder Xcessory generates for each class when you are working in C.

Hint: Accessing class member widgets from a function or method that is not part of the class is possible, but not recommended as it breaks the object oriented model.

Calls to Xt Functions

You can also use the Xt function, XtNameToWidget, to obtain the widget ID. Although inefficient, this method is an effective way of obtaining the widget ID of a compound widget child.


If you are generating UIL, you can obtain the widget ID by calling MrmFetchWidget on the widget name.