# Code Generation

WorkShop Visual generates source code in C, C++ and UIL, with the resource settings either hard wired into the code, or generated in a matching X Resource file. To write an application using WorkShop Visual, it is necessary to understand the way that code is generated and how to link your application code to it.

In Microsoft Windows mode, you may also generate a Microsoft Windows resource file. If you have created any pixmaps, these will be automatically converted at this point into Microsoft Windows Bitmaps or Icons (depending on whether the selected widget is a Button or Label respectively). Each one is written into a separate file using the name of the pixmap object as the filename.

Each design for which code is generated produces one output file, or module. Each module consists of a number of sections.

Analysis of the Primary Module

From top to bottom, your primary code module contains the following sections:

- Headers (optional)
- Global variable declarations
- Declarations of link functions, or the functions themselves (optional)
- Structures needed for your fonts and pixmaps and code setting up font and pixmap objects
- Widget creation code for your design hierarchy
- A main() procedure (optional)

The optional portions of the file can be included or excluded by setting toggles on the control panel.

The Header Section

The primary module has the following header material, in this order:

- The module heading (if any)
- WorkShop Visual's heading
- The #include statements (optional)
- The module prelude (if any)

Your file does not have a module heading or module prelude. You can specify code to be inserted in these places from within WorkShop Visual.

After some standard WorkShop Visual comments, there is a list of #include statements needed for the Motif code in your module. The #include statements are optional and are controlled by the toggles in the Code Options dialog.

Link Functions or Link Declarations

Next, the module contains code for the link functions. The following code fragment shows a typical link function:

    void XDunmanage_link (w, client_data, call_data)
    Widget w; /* widget id */
    XtPointer client_data;	/* data from application */
    XtPointer call_data;	/* data from widget class */
    void XDunmanage_link ( Widget w, XtPointer client_data, XtPointer call_data )
    {
    	if ( client_data && *(Widget *)client_data )
    	XtUnmanageChild ( *(Widget *)client_data );
    }

Generation of this code is optional and is controlled by the Generate Options dialog.

Variable Declarations

In this section, all globally defined widgets in the design are declared. The following lines are typical:

    Widget exit_button = (Widget) NULL;
    Widget help_cascade = (Widget) NULL;

Only global widgets are declared here. By default, widgets are local in scope. Local widgets are defined in the function which creates their parent Shell and cannot be referenced elsewhere in your application. To make a widget global, you can:

- Specify it as global on the Core resource panel
- Give it an explicit variable name

Note that the variable names of Application Shells and Top level Shells are always global in WorkShop Visual and therefore should not be made local. In addition, any widget which is the target of a link must also be global.

Variable Names

Variable names must be unique. If you "Read" or "Paste" widgets into your design whose variable names duplicate names of existing widgets, WorkShop Visual silently removes the duplicate names and assigns new, local, names of the form widget_type, e.g. shell4, form5, etc.

By convention, variable names of widgets should begin with a lower-case letter. This helps avoid conflict with Motif declarations.

Creation Procedures

By default, WorkShop Visual generates a creation procedure for each Shell widget in your design. The creation procedures are the heart of the generated code. Each creation procedure does the following:

- Creates the Shell widget itself
- Creates and manages all the children of the Shell and their children
- Sets all hard-wired resources for any child of the Shell
- Adds callbacks and (optionally) links to any child of the Shell which has them

The creation procedures do not display the Shell. Usually, windows are displayed by a function call in the main() procedure or in a callback routine.

Callback Procedures

The primary module does not include callback functions themselves. However, it does add any callbacks you have specified to each widget's callback list.

Description of the Main Program

A minimal main() procedure is either generated into a separate file or at the end of your primary module.

WorkShop Visual's main() procedure does the following things:

- Opens a connection to the X server
- Initializes the X toolkit
- Calls the creation procedure for the first Application Shell
- Calls the creation procedures for all other Shells in the design
- Calls XtRealizeWidget() to display the first Application Shell
- Calls XtAppMainLoop() (which never returns)
- Calls exit() (This call is for neatness only, since this line of code is never executed)

See also:

- Generate dialog
- Stubs File Generation
- Callbacks
- Methods
- Links
- Code Preludes
- Module Preludes
- Help documents and markers
- Widget and Variable Names
- Microsoft Foundation Classes
- Microsoft Windows Mode
- About WorkShop Visual