Volume 6A: Motif Programming Manual

descendents of the specified widget, which is why only a single call is needed to create the entire widget hierarchy.

If all goes well, the routine puts the ID of the newly created widget in widget_return and returns a status of

MrmSUCCESS. The other return parameter, class_return, holds the internal UIL class code of the widget. Note

that the class_return value is not a pointer to the widget's class record. As of Motif 1.2, the class_return

value is useless because the possible return values are not publicly defined in the Mrm header files. If you need to

determine the type of the returned widget, you can use the appropriate XtIs*() or XmIs*() macro. For example,

to verify that --hello_main is really a Form, you would use XmIsForm -(-hello_main). If

MrmFetchWidget() fails, it returns the following: MrmBAD_HIERARCHY, if the hierarchy argument is

invalid; MrmNOT_FOUND, if the widget description cannot be found in the UID files; or Mrm_FAILURE for any

other type of failure. To avoid crashing your application, you should always check the return status against

MrmSUCCESS after fetching a widget hierarchy, as illustrated in the source code Although our example simply exits

when an error occurs, a more robust application should attempt to recover from the problem.

The MrmFetchWidget() routine takes the place of all the widget calls needed in an application that doesn't use

UIL and Mrm. As it creates widgets, Mrm automatically sets the resources and callbacks that are specified in the UIL

module. ...