The widget edit dialog is used to describe a particular widget class. The fields are:-
Include file:
The file which you would include in a program which uses the widget class, for instance
Defined name function:
X-Designer has to convert internal resource names back to symbolic names which are usually defined in the header file with #define. For instance, it has to convert the internal name "foreground" to the symbol "XtNforeground".
By default, it does this by adding the prefix "XtN" to the internal name, but this does not always work. For instance, the Athena clock widget has a resource "hands" whose symbolic name is "XtNhand". The defined name function allows you to override X-Designer's default name conversion where needed.
This need not normally be specified. If you need it, and have not specified it, compiling code generated by X-Designer will fail, complaining that "XtN
Can add child function:
Each widget icon in the X-Designer widget palette is enabled only if the widget is a permissible child of the currently selected widget in the widget hierarchy. For the Motif widgets, knowledge of the children which can be accepted by various parents is built into X-Designer. X-Designer can provide some of this functionality for user-defined widgets (for instance, it will not allow you to add a child to a primitive widget), but there are some restrictions which X-Designer cannot determine (for instance, a menu bar will only accept cascade button children). The can add child function is used to provide this information for user-defined widgets. This need not be specified. However, it may be needed to prevent creation of invalid widget hierarchies which may cause failures in X-Designer or in the code generated by X-Designer. See the xdconfig User Manual for an example.
Appropriate parent function:
The appropriate parent function is the converse of the can add child function. It is used to disable the icon in the widget palette if the currently selected widget in the widget hierarchy is not a suitable parent for this user-defined widget. This need not be specified. However, it may be needed to prevent creation of invalid widget hierarchies which may cause failures in X-Designer or in the code generated by X-Designer. See the xdconfig User Manual for an example.
Realize function:
When you click on an icon in the widget palette, X-Designer creates and realizes a widget of the appropriate type. X-Designer does not normally set any resource values when it creates the widget, but accepts the toolkit defaults. Sometimes this can cause problems. For instance, some container widgets are, by default, created with zero width and height, which will cause X to complain. The realize function allows you to specify a function which is called before the widget is realized, typically to do initialization. This function is only called when a widget is created within X-Designer. If the same initialization is required in the generated code, it should be added as a code prelude. This is often not necessary. Problems with containers occur because X-Designer realizes them before they have any children. In the generated code, the children will be added before realization, forcing the width and height to a non-zero value and eliminating the complaints from X. The realize function is not normally required. See the xdconfig User Manual for an example.
Abstract Child function:
By default, X-Designer will display all built-in children of a third party widget recursively, so that the user can customise the parts of a composite object. There may be parts of a widget which you do not want an application programmer to have access to in this way. By specifying an abstract child routine, you can control which children the user can see inside X-Designer, and of those which remain visible, which ones can be edited.
Icons:
The icons are bitmaps used by X-Designer to represent the widget in the widget palette and the widget hierarchy. The small icon (20by20 pixels) is used on VGA resolution screens (that is, when xdesigner.smallscreen is true) and the large icon (32 by 32 pixels) on workstation-type screens. If no small icon is specified, the large one will always be used. If no icons are specified, X-Designer will use a button with the widget class name on it in the palette, and a box with a cross in the hierarchy. For each of the two icons, you should specify the include file where it is defined (eg X11/bitmaps/woman) and the name used in that file. The first line of a bitmap definition is usually
#define
In our example, the bitmap in the file /usr/openwin/include/bitmaps/woman is 'sorceress'. You should normally specify at least the large icon. You can create an icon using the X utility 'bitmap' (and others).
Generate class initialization:
By default, X-Designer will generate a call to XtInitializeWidgetClass(3X) for each third party component found in the design. This is so that any converters registered in the ClassInitialize method of the widget are installed before an instance of the widget is created in the generated code. This may not be necessary - you can disable the XtInitializeWidgetClass() code generation by turning the toggle off.
Disable Find widget:
X-Designer allows the user to type
Disable foreground swapping:
When a widget is selected in the hierarchy, X-Designer normally swaps the foreground and background colors, so that the widget highlights in the design window. X-Designer only does this if the widget has a foreground resource. Some widgets with foreground resources (notably the OLIT widgets) cannot handle a change of the resource value after the widget has been managed. When you select such a widget in the hierarchy, X-Designer will fail when it attempts to swap the foreground and background. Setting this toggle will disable the swapping of foregrounds and background, and so prevent the failure. It should not normally be set.
Can create the widget:
If this toggle is set (the default) there will be an icon for the user-defined widget in the X-Designer icon palette, and it will be possible for the user to create instances of this widget class in X-Designer. If the toggle is reset, there will be no icon in the palette and the user will not be able to instantiate this widget class. However, a resource panel for the class will still be generated, and any user-defined widgets which are subclasses of this widget class will use that resource panel to set inherited resources. This is normally only used when a hierarchy of user-defined widget classes is being added, and you want the resources of an abstract class in the hierarchy to be treated in a way similar to X-Designer's treatment of Core resources.
Can manage the widget:
Certain Xt components may not be directly managed by the programmer. Components derived from the Object class fall into this category: indeed, managing an XtObject corrupts the address space. X-Designer has an internal algorithm which prevents it from managing known component classes of this type, either inside the product or in generated code. However there may be a third party component which the internal algorithms fail to catch. Turning the toggle off explicitly prevents X-Designer from managing the component in any way.
Can edit as abstract child:
If this component occurs as a built-in child of another widget class, you may not want the user to be able to alter its settings, which presumably have been carefully prepared for the situation in which the widget resides. Turning the toggle off prevents the user from being able to edit any of the resources associated with this component, whenever it appears as a built-in child of another class.
See also: