Troubleshooting in WorkShop Visual

23

• WorkShop Visual Interface

• Resource Panels

• Layout Editor

• Links

• Code Generation

Labels Don't Display Correctly

Cause and Solution: These labels are only available when the correct resource file is read. If the labels are not available, X substitutes variable names. Reconfigure your system so WorkShop Visual reads the WorkShop Visual resource file. There are several ways to do this in X. Consult your system administrator.

Only a Few Labels Are Wrong

Cause and Solution: Your configuration may be reading an obsolete version of the WorkShop Visual resource file. Check the software version and make sure WorkShop Visual is reading the resource file that came with that version.

Blank Help Screens

Cause and Solution: Either your X environment is not finding the correct resource file, or the resource file is not accessing the correct search path. Make sure the "helpDir" resource contains the search path for your WorkShop Visual help database.

For advice on setting resources for specific widgets and combinations of widgets, lookup the widget in Chapter 22, "Widget Reference" and your Motif documentation. Note that many apparent problems with resource settings can be solved by resetting the widget involved or the Shell.

When you set values in WorkShop Visual's resource panels, WorkShop Visual actually resets resources of widget instances in the dynamic display. Sometimes the results are not what you expect:

Resource Settings Are Rejected

• The value you typed into a field of the resource panel is not accepted

• The value in the resource panel reverts to the former value

• The value in the resource panel changes to some other value

• The dynamic display reflects the value on the resource panel, but the value is not what you typed

For example, if a RadioBox contains a group of ToggleButtons, the width of the individual ToggleButtons is determined by their text and margin resources; the width of the RadioBox is calculated from the width of its widest child; and all the ToggleButtons are forced to be the same width as the widest one. A width setting on the Core resource panel is overridden by the calculated value. If the RadioBox is in turn the child of a Form, attachments set in the Layout Editor can override the RadioBox rules.

Solution: Check your design for constraints that may be overriding the setting. Use the constraints imposed by other widgets to achieve the desired effect.

Solutions: Reset the widget. If that doesn't work, reset the Shell. If resetting the Shell doesn't work, consult the Widget Reference chapter. You may need to set two or more resources to achieve a single effect. For example, to display a pixmap on a label or button, you must set the "Pixmap" resource to specify the pixmap you want, and set the "Type" resource to "Pixmap."

A few resources are never reflected in the dynamic display, as discussed below.

Geometry Resources Are Overridden

Cause and Solution: The width and height Core resources of any widget can be overridden, either by resources specific to that widget class or by geometry rules of the widget's parent. Consult Chapter 22, "Widget Reference", starting on page 653, or Motif documentation for information about resources of the widget and its parent that may be controlling its size.

Cause and Solution: The width and height Core resources of a Shell can be overridden by the corresponding resources of the Shell's child. One way to control the size of a dialog is to set the width and height resources of the Shell's child. Another way is to set the minimum width and height resources of the Shell, which are not overridden by the child.

Cause and Solution: The x,y position resources of a Shell can be overridden by the position resources of the Shell's child if the Shell's child is a BulletinBoard, or a derivative of the BulletinBoard such as a Form, DialogTemplate, or MessageBox. To use the Shell's x,y position resources to control the dialog's position, set the BulletinBoard's "Default position" resource to "No."

Resources Are Not Reflected After Resetting

Cause: Certain resources can only be set when a widget is first created. These resources cannot be changed once the widget is added to the dynamic display. They include various resources related to scrollbars such as "Scrolling policy." WorkShop Visual still lets you change the value on the resource panel, and even though the value is not reflected in the dynamic display, the new setting takes effect at run time of the generated application. For details about individual resources, consult the Motif Programmer's Manual.

Cause: The "Dialog Style" resource of BulletinBoards and widget classes that derive from the BulletinBoard can be set to "Modeless," "System Modal," or "Application Modal." Modal dialogs disable all other dialogs until they receive an answer from the user, so if a setting of "System Modal" or "Application Modal" were effective in the dynamic display, you would not be able to do anything else until the dynamic display was closed. You can still select one of these settings; WorkShop Visual disables the setting while you are building the hierarchy and generates it correctly in the code.

Solution: If you have resources of this kind in your design, you can only see the final results after the design is finished and you generate the code. You can see the results at intermediate stages by generating code and running a prototype using the following steps:

1. Generate a primary code module. Include all types of resources and a main() program.

2. Generate a stubs file (only necessary if your design has callbacks). Leave the function braces empty.

3. Compile and link the generated files.

4. Run the resulting program.

Cause: When a widget does not have an explicit font setting, Motif searches back through the design hierarchy to find the widget's nearest BulletinBoard, BulletinBoard derivative, or Shell ancestor, and uses the font setting of that ancestor for the current widget. Therefore, if several buttons all have default font settings but are children of different BulletinBoards, some may show different fonts from others.

Solution: Setting a font on the BulletinBoard or Shell instead of on individual widgets is a convenient way of setting all the fonts at once. To get uniformity you must use the same font on all parent widgets with explicit font settings. A font object is a convenient way to do this.

Font Change on Parent Doesn't Affect Children

Cause and Solution: The new font setting on a parent widget does not affect the children until you reset the parent widget. Reset the parent widget.

Cause and Solution: Font settings on parent widgets do not affect their children if the children have explicit font settings of their own. Make sure the children have default font settings.

CascadeButtons in DialogTemplate Don't Display

Cause: This is a bug in some versions of Motif. The DialogTemplate resizes properly to accommodate the button box and work area, but if the MenuBar exceeds the width of the button box and work area, it is cut off.

Solution: Add the button box and work area children to the DialogTemplate before you add the CascadeButtons to the MenuBar. In many cases the width of your work area or button box will create enough width to accommodate the MenuBar.

Solution: If your MenuBar is still too wide to display, use a Form as the work area, or put the work area inside a Form, then use the Layout Editor to add extra space around the work area.

Solution: You can force the DialogTemplate to be wider by setting its "Width" resource on the Core resource panel.

Widget Becomes Very Small or Very Large

Cause and Solution: In some versions of Motif there is a bug in the Form that appears when the Form is a child of a DialogTemplate. When you reset the Form, any container widgets inside the Form become very small. If you have this problem, resetting the DialogTemplate instead of the Form corrects it. To do this, you must go from the Layout Editor screen to the main WorkShop Visual screen, select the DialogTemplate in the construction area, and give the "Reset" command. To resume working in the Layout Editor, first select the Form again in the construction area.

Cause and Solution: Attachments can change the size of a widget. For example, attaching the edges of a widget to the corresponding edges of the Form forces the widget to span the full width or height of the Form. Reset the Form. If resetting the Form doesn't work, remove some of the attachments from the widget and reset again.

Methods of breaking attachments are listed below. For a more complete discussion, see Chapter 4, "The Layout Editor", starting on page 103.

• Use "Undo" to remove the most recent attachment

• Move the widget

• In the "Attach" mode, click just inside the edge of the widget or drag from just inside the edge of the widget toward the widget's center

• Replace the old attachment with a new attachment

• Select the widget in the design hierarchy, bring up its Constraints panel, and reset the attachment "Type" for that edge to "None".

Cause and Solutions: If you add an attachment that results in a circularity involving two or more widgets, Motif detects the circularity and returns the error message. Click on "Undo." If you still get the error message, carefully inspect your layout for an attachment loop and remove one of the attachments.

"Bailed Out..." Error Message

Cause and Solutions: This Motif message indicates that your layout contains attachments that contradict one another without being circular. It usually occurs with "Self" or "Position" attachments. Use "Undo" or move the widgets to remove the contradictory attachments, then reset the Form.

Widgets Overlap the Boundary of the Form

Causes: Widgets whose edges coincide with the sides of the Form can overlap the line drawn around the Form, causing undesirable breaks in the line. This only occurs if the Form is the immediate child of a Shell. Three conditions in the Form can cause the overlap:

• A widget is attached to the edge of the Form with an offset of 0 or 1 pixel

• A widget is attached to the edge of the Form with a default offset and a vertical or horizontal spacing value of 0

• There are no attachments between the bottom or right edge of the Form and the widgets closest to those edges

Solution: Put the Form inside another manager widget, such as another Form or a DialogTemplate. This is the simplest and most flexible solution.

"Add" Is Disabled

Cause and Solution: The Link facility requires the target widget to have an explicit variable name. If the target widget is a Shell, its immediate child must also have an explicit name. WorkShop Visual grays out the "Add" option if it does not find explicit names. Name the appropriate widgets.

A Link Stops Working

Cause and Solution: If you change the name of a widget, WorkShop Visual does not automatically update links that refer to that widget and they cease to be functional. Remove the obsolete links and replace them with new ones.

Links Don't Update When You Select Another Button

Cause: WorkShop Visual interprets the selection of any new widget as a target widget for a potential new link on the previously selected button.

Solution: Pull down the Widget Menu and select "Edit links" again to display and edit links on the second button. You do not have to close the Links panel first.

"No Application Shell" Warning

Cause and Solution: Your design does not contain the required Application Shell. Bring up the resource panel for the Shell of the main window in your design, click on the "Application Shell" toggle, then click on "Apply."

Links are Undefined

Cause and Solution: If you generate Links with your primary module, you must generate the actual code for the links - the Link functions - into one of your code files, either the primary module or a stubs file. Be sure to generate the link functions into an appropriate file.

Global Widgets Are Undefined

Cause and Solution: Declarations of global widgets and objects are generated into the primary module, but not into the stubs file. To generate a header file that declares them, use the "Externs..." option and #include the resulting header file with your callbacks. This is preferable to writing your own extern declarations or copying the ones generated in the primary module, because it is less error-prone and more complete. The Externs file can be regenerated when necessary to reflect changes in the design.

Application Does Not Use Resources from X Resource File

Cause and Solution: You did not regenerate the X resource file when you regenerated code. If you have added or removed widgets from your design, default widget names may change and no longer correspond to those in the generated X resource file. Regenerate the X resource file.

Cause and Solution: X cannot find the X resource file when you run your application. You may need to rename the X resource file, usually with the same name as the application class and without a suffix. For more information, see your X documentation.

Cause and Solution: X cannot recognize the widget names in the file because a different application class name was used for the generated code file and the X resource file. Regenerate the application and the X resource file, being sure to use the same application class name for both. Be sure to use a unique application name to avoid confusion with other resource files your system may be accessing.

Default Resources Change At Run Time

Cause: Some resources shown in the dynamic display are inherited from WorkShop Visual. If not explicitly set on the resource panels, these resources may inherit values from other sources at run time, depending on the platform where the program is run.

Solution: To ensure the correct colors and fonts, set explicit values for them on the resource panels. Foreground and background colors can be set on each Shell in the design and are then inherited by all children of the Shell. Fonts can be set on BulletinBoards, derivatives of the BulletinBoard, or Shells, and apply to all their children.

Unexpected Results Occur When Widgets Share a Widget Name

• Sharing of resources occurs only at run time. Resource values are not shared among widgets in the dynamic display

• Hard-wired resources are not shared

• Object bindings are not shared

Cause: These are expected results when widgets share a widget name. The dynamic display and hard-wired resource settings disregard common widget names. Resources generated into the X resource file, however, affect all widgets with a common widget name.

Symptom: A color or font is not shared among widgets with a common widget name, even if that resource was generated to the X resource file.

Cause and Solution: The color or font used an object binding instead of a color or font setting. Use a simple color or font setting, or set the resource on a common parent of the widgets that you want to share the value.

Symptom: An explicitly set resource value is overridden at run time.

Cause: If widgets share a widget name and resources are generated to the X resource file, only one value is used even if more than one was set.

Solution: Generally it is better to avoid common widget names unless widgets are to share all resource values. However, you can force any resource value to be restricted to a single widget by hard-wiring it. Use the masking toggles on the resource panels to do this.