Next: Extending XF Up: The Implementation of XF Previous: The Implementation of XF

# The generated code

The source that is created by XF has a general layout, and contains a certain set of functionality. The produced code can be saved into one file, or be splitted into several modules. In both cases the general layout and functionality is the same.

Apart from the procedures that are written by the user, XF

saves a number of procedures that are used to create the widget structures, initialize the program or support the special XF bindings. The creation of most of this code can be turned off and on explicitly (Options | Source options).

1. Module inclusion code.
   If the source has been split into modules, the main file of the application begins with code that initializes the module load path and parses the commandline options.

2. Toplevel creation code.
   The procedures ``ShowWindow...'', `` DestroyWindow...'' etc. are created automatically by XF , to display and hide the various toplevel windows of the application. There can also be procedures named `` StartupSrc...'', ``MiddleSrc...'' and `` EndSrc...''. They are called by the corresponding window creation procedure, and can be used to initialize the widgets that are inside the displayed toplevel window.

3. User defined procedures.
   If the source is structured into modules, the procedures that have been written by the developer are all stored in this section. The order can be changed, and the procedures can be distributed to different modules.

4. Internal procedures.
   This section contains procedures that XF creates to produce a running application. The creation of most of these procedures can be turned off and on explicitly (Options | Source options). The remaining XF

   internal procedures are all assigned to the level 7 (see chapter ). If the saving of level 7 is disabled, these procedures are not saved. If the source is not structured into modules, the user defined and the internal procedures are mixed, as XF stores all procedures in alphabetical order.

   1. XFLocalIncludeModule
      This procedure is called with the name of the module to be loaded. The procedure scans through the directories specified with the environment variable XF_LOAD_PATH, and tries to load this module. In addition to that archives are searched for the modules. The user can use the environment variable XF_VERSION_SHOW to specify the retrieve command (see the description of version control).

   2. XFLocalParseAppDefs, XFLocalLoadAppDefs, XFLocalSetAppDefs
      These procedures provide full support for the X Resource mechanism. The procedure ``XFLocalLoadAppDefs'' gets an application class name, and loads the resource stored under this name. The procedure ``XFLocalSetAppDefs'' applies the resources to the specified widget path.

   3. SymbolicName, SN
      These two procedures implement the symbolic name handling. The developer can assign a name to a widget path name. This makes the access to this widget easier. Calling these procedures with the symbolic name, returns the concrete widget path name.

   4. Alias, Unalias
      These two procedures implement the alias handling. Aliases can be used to access procedures and widgets under a different name. The difference from symbolic names is that each aliased procedure creates an additional procedure, making this approach a little space consuming. The alias procedure gets two parameters, first the new alias name, and second the procedure that is aliased. Unalias gets one parameter, specifying the alias name to be removed.

   5. GetSelection
      This procedure is used to implement a safe X selection retrieval for the text and entry widget. If the bindings do not contain this procedure, it may be deleted.

   6. MenuPopupAdd, MenuPopupPost, MenuPopupMotion, MenuPopupRelease
      The procedure ``MenuPopupAdd'' sets the appropriate bindings to pop up a menu. The popup menu is attached to the widget specified with the first parameter. The second parameter specifies the mouse button that activates the popup menu (1, 2 or 3). The next parameter specifies the widget name of the menu that is to be popped up. The following parameter is optional, and can contain a valid event modifier. The last parameter can contain a canvas tag or id. The menu is attached to this tag or id. The other procedures are only used internally.

   7. NoFunction
      This procedure does nothing. It can be called with any number of parameters.

5. StartupSrc, EndSrc.
   These two procedures contain source that is evaluated during the startup of the application program. ``StartupSrc'' is executed as first code in the application, and `` EndSrc'' is executed after all toplevel windows have been displayed. The user must add initialization code to one of these procedures.

6. Invocation of StartupSrc.
   The startup code is evaluated.

7. Initialization of variables.
   The global variables are initialized with the procedure ``InitGlobals'', or directly inside the code. The developer should initialize important variables directly in his initialization code for his application. The values assigned in the ``InitGlobals'' procedure represent the values when the application was saved.

8. Setting of class bindings.
   If this is specified in the source options, the currently defined class bindings are saved into the application code. These bindings are initialized at this point.

9. Showing the toplevel windows.
   The toplevel windows that should be displayed are created by invoking the appropriate ``ShowWindow...'' procedure.

10. Loading of bindings.
    The user can specify a Tcl/Tk file containing bindings for his application. This file can be specified with the environment variable XF_BIND_FILE, or the commandline option ``-xfbindfile'' when the source contains the commandline parsing code.

11. Application default handling.
    The application default file is loaded, and the settings are applied to the displayed widgets.
12. Invocation of EndSrc.
    The end code is evaluated.

Next: Extending XF Up: The Implementation of XF Previous: The Implementation of XF