[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 11. Saving and Loading Forms

To save the set of forms created select the item "Save" or "Save As" from the "File" menu. You will be prompted for a file name using the file selector if the latter is selected. Choose a name that ends with `.fd`, e.g., ``ttt.fd`'.

The program will now generate three files: ``ttt.c`', ``ttt.h`' and ``ttt.fd`'. If these files already exist, backup copies of them are made (by appending `.bak` to the already existing file names). ``ttt.c`' contains a piece of C-code that builds up the forms and ``ttt.h`' contains all the object and form names as indicated by the user. It also contains declaration of the defined callback routines.

Depending on the options selected from the "Options" menu, two more files may be emitted, namely the main program and callback function templates. They are named ``ttt_main.c`' and ``ttt_cb.c`' respectively.

There are two different kind of formats for the C-code generated. The default format allows more than one instance of the form created and uses no global variables. The other format, activated by the `altformat` option given on the command line or switched on via the "Options" menu by selecting "Alt Format", uses global variables and does not allow more than one instantiation of the designed forms. However, this format has a global routine that creates all the forms defined, which by default is named `create_the_forms()` but that can be changed (see below).

Depending on which format is output, the application program typically only needs to include the header file and call the form creation routine.

To illustrate the differences between the two output formats and the typical way an application program is setup, we look at the following hypothetical situation: We have two forms, `foo` and `bar`, each of which contains several objects, say `fnobj1`, `fnobj2` etc. where `n = 1, 2`. The default output format will generate the following header file (``foobar.h`'):

    #ifndef FD_foobar_h_
    #define FD_foobar_h_

    /* call back routines if any */

    extern void callback(FL_OBJECT *, long);

    typedef struct {
        FL_FORM *   foo;
        void *      vdata;
        char *      cdata;
        long        ldata;
        FL_OBJECT * f1obj1;
        FL_OBJECT * f1obj2;
    } FD_foo;

    typedef struct {
        FL_FORM *   bar;
        void *      vdata;
        char *      cdata;
        long        ldata;
        FL_OBJECT * f2obj1;
        FL_OBJECT * f2obj2;
    } FD_bar;

    extern FD_foo *create_form_foo(void);
    extern FD_bar *create_form_bar(void);

    #endif /* FD_foobar_h */

and the corresponding C file:

    #include <forms.h>
    #include "foobar.h"

    FD_foo *create_form_foo(void) {
        FD_foo *fdui = fl_calloc(1, sizeof *fdui);

        fdui->foo = fl_bgn_form(....);
        fdui->f1obj1 = fl_add_aaaa(....);
        fdui->f1obj1 = fl_add_bbbb(....);
        fl_end_form();

        fdui->foo->fdui = fdui;
        return fdui;
    }

    FD_bar *create_form_foo(void) {
        FD_bar *fdui = fl_calloc(1, sizeof *fdui);

        fdui->bar = fl_bgn_form(....);
        fdui->f2obj1 = fl_add_cccc(....);
        fdui->f2obj2 = fl_add_dddd(....);
        fl_end_form();

        fdui->bar->fdui = fdui;
        return fdui;
    }

The application program would look something like the following:

    #include <forms.h>
    #include "foobar.h"

    /* add call back routines here */

    int main(int argc, char *argv[]) {
        FD_foo *fd_foo;
        FD_bar *fd_bar;

        fl_initialize(...);
        fd_foo = create_form_foo();
        init_fd_foo(fd_foo);  /* application UI init routine */

        fd_bar = create_form_bar();
        init_fd_bar(fd_bar)   /* application UI init routine */

        fl_show_form(fd_foo->foo, ...);

        /* rest of the program */
    }

As you see, `fdesign` generates a structure that groups together all objects on a particular form and the form itself into a structure for easy maintenance and access. The other benefit of doing this is that the application program can create more than one instance of the form if needed.

It is difficult to avoid globals in an event-driven callback scheme with most difficulties occurring inside the callback function where another object on the same form may need to be accessed. The current setup makes it possible and relatively painless to achieve this.

There are a couple of ways to do this. The easiest and most robust way is to use the member `form->fdui`, which fdesign sets up to point to the `FD_` structure of which the form (pointer) is a member. To illustrate how this is done, let's take the above two forms and try to access a different object from within a callback function.

    fd_foo = create_form_foo();
    ...

and in the callback function of `ob` on form `foo`, you can access other objects as follows:

    void callback(FL_OBJECT *obj, long data) {
        FD_foo *fd_foo = obj->form->fdui;
        fl_set_object_dddd(fd_foo->f1obj2, ....);
    }

Of course this setup still leaves the problems accessing objects on other forms unsolved although you can manually set the `form->u_vdata` to the other `FD_` structure:

    fd_foo->form->u_vdata = fd_bar;

or use the `vdata` field in the `FD_` structure itself:

    fd_foo->vdata = fd_bar;

The other method, not as easy as using `form->fdui` (because you get no help from fdesign), but just as workable, is simply using the `u_vdata` field in the `FD_` structure to hold the address of the object that needs to be accessed. In case of need to access multiple objects, there is a field `u_vdata` in both the `FL_FORM` and `FL_OBJECT` structures you can use. You simply use the field to hold the `FD_` structure:

    fd_foo = create_form_foo();
    fd_foo->foo->u_vdata = fd_foo;
    ...

and in the callback function you can access other objects as follows:

    void callback(FL_OBJECT *obj, long data) {
        FD_foo *fd_foo = obj->form->u_vdata;
        fl_set_object_dddd(fd_foo->f1obj2, ....);
    }

Not pretty, but adequate for practical purposes. Note that the `FD_` structure always has a pointer to the form as the first member, followed by `vdata`, `cdata` and `ldata`. There's also a `typedef` for a structure of type `FD_Any` in `forms.h`:

    typedef struct {
        FL_FORM * form;
         void *   vdata;
         char *   cdata;
         long     ldata;
    } FD_Any;

you can use a cast to a specific `FD_` structure to get at `vdata` etc. Another alternative is to use the `FD_` structure as the user data in the callback(11)

    fl_set_object_callback(obj, callback, (long) fdui);

and use the callback as follows

    void callback(FL_OBJECT *obj, long arg) {
        FD_foo *fd_foo = (FD_foo *) arg;
        fl_set_object_lcolor(fd + foo->f1obj1, FL_RED);
        ...
    }

Avoiding globals is, in general, a good idea, but as everything else, also an excess of a good things can be bad. Sometimes simply making the `FD_` structure global makes a program clearer and more maintainable.

There still is another difficulty that might arise with the current setup. For example, in `f1obj1`'s callback we change the state of some other object, say, `f1obj2` via `fl_set_button()` or `fl_set_input()`. Now the state of `f1obj2` is changed and it needs to be handled. You probably don't want to put much code for handling `f1obj2` in `f1obj1`'s callback. In this situation, the following function is handy

    void fl_call_object_callback(FL_OBJECT *obj);

`fl_call_object_callback(fdfoo->f1obj2)` will invoke the callback for `f1obj2` callback in exactly the same way the main loop would do and as far as `f1obj2` is concerned, it just handles the state change as if the user changed it.

The alternative format outputs something like the following:

    /* callback routines */
    extern void callback(FL_OBJECT *, long);

    extern FL_FORM *foo,
                   *bar;
     extern FL_OBJECT *f1obj1,
                      *f1obj2,
                      ...;
    extern FL_OBJECT *f2obj1,
                     *f2obj2,
                     ...;

    extern void create_form_foo(void);
    extern create_form_bar(void);
    extern void create_the_forms(void);

The C-routines:

    FL_FORM *foo,
            *bar;

    FL_OBJECT *f1obj1,
              *f1obj2,
              ...;
    FL_OBJECT *f2obj1,
              *f2obj2,
              ...;

    void create_form_foo(void) {
        if (foo)
            return;
        foo = fl_bgn_form(....);
        ...
    }

    void create_form_bar(void) {
        if (bar)
            return;
        bar = fl_bgn_form(....);
        ...
    }

    void create_the_forms(void) {
        create_form_foo();
        create_form_bar();
    }

Normally the application program would look something like this:

    #include <forms.h>
    #include "foobar.h"

    /* Here go the callback routines */
    ....

    int main(int argc, char *argv[]) {
        fl_initialize(....);
        create_the_forms();
        /* rest of the program follows*/
        ...
    }

Note that although the C-routine file in both cases is easily readable, editing it is strongly discouraged. If you were to do so, you will have to redo the changes whenever you call fdesign again to modify the layout.

The third file created, ``ttt.fd`', is in a format that can be read in by the Form Designer. It is easy readable ASCII but you had better not change it because not much error checking is done when reading it in. To load such a file select the "Open" item from the "File" menu. You will be prompted for a file name using the file selector. Press your mouse on the file you want to load and press the button labeled "Ready". The current set of forms will be discarded, and replaced by the new set. You can also merge the forms in a file with the current set. To this end select "Merge" from the "File" menu.

### Footnotes

### (11)

Unfortunately, this scheme isn't legal C as a pointer may be longer than a long, but in practice, it should work out ok on virtually all platforms.

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated on January 5, 2026 using texi2html 1.82.