Next: Levels for procedures and Up: Advanced features Previous: Toplevel windows

## Source modules

An XF generated program can be packed into one file, containing the complete code. This is usually done for code that will be distributed. It makes the calling easier, and reduces the number of files to be installed. To create such a file, the menu item (File | Save as...) is activated.

During the development, it is usually better to have small modules that can be handled independently. For example it is a good idea to put the external (XF created) code into a separate module. The code for the widget creation should be put into a separate module, preferrably one module for each toplevel. Finally the procedures loaded from templates should also be stored into modules named after the templates. This makes it easier to locate and modify different pieces of code when working with an editor.

Another aspect of modularization is the working in groups. If a program is built by a group of developers, each developer can put his code into one or more separate modules. These modules are stored locally by each developer, giving him full control over the modules. Modules handled by the other developers can be retrieved by XF at loading time. To access the distributed modules, it is necessary to set the environment variable XF_LOAD_PATH. This variable contains a list of directory names separated by ``:''. Here, XF tries to find modules that are part of the application. XF looks for plain files, and for archives using the ShapeTools.

By specifying which modules should be saved (with the module structure dialog), only the modules that are accessed by the developer are updated. Each developer can publish a module when it is ready, by moving it to a public directory, or by making a check-in into the global archive using ShapeTools. The global program structure should be maintained by one specific administrator, who has control over the main module.

To distribute the toplevel windows and the procedures into different modules, there exists a special dialog box. This dialog allows the user to split the contents of his application (toplevels and procedures) into readable pieces (see figure ).

New modules are added by typing the new module name, and pressing the button (Insert module). To add an element to a module, the user clicks on the appropriate item in the left list. To remove elements from a module, the user double clicks on the item in the right list. There is always one module that has the name of the application. It contains all toplevels and procedures that were not placed in another module.

A module can be made an auto load module with the checkbutton labelled (Auto load), right beside the module name. This means the needed code is generated that loads the module when a procedure from that module is called.

To support the development in groups, it is possible to specify which modules should actually be saved. This is done with the checkbutton labelled (Save module), right beside the module name. This information can be saved to a user specific file.

By selecting the button (Handle Templates) this dialog is switched to the template mode. Here the user can select exactly one widget path and an unlimited number of procedures to be saved to a template. To save this template the (Save) button is pressed. This save button can also be used to save the complete program (when the template mode is not activated).

Next: Levels for procedures and Up: Advanced features Previous: Toplevel windows