> I suggest you should declare "theFduiPtr" as a global variable
> in your source file which has "main()" in it:
>
> FD_whatever *theFduiPtr;
>
> Just this short declaration, NOT
> "FD_whatever *theFduiPtr = (FD_whatever *)ob->form->fdui ;".
Why?
Although I suppose this is a matter of programming style whether you
rely upon global variables or not, the fdui field in the FL_FORM data
structure was designed to do precisely what it does, which is to
provide a link back to the fdesign generated user interface structure.
I know this since it was more or less at my instigation, as far as I'm
aware, that this mechanism was implemented.
BTW, the construction I actually use is to declare the following in a
header file included in all sources which have the need of
manipulating the FD structures:
typedef struct {
FL_FORM *form;
void *vdata;
long ldata;
} FD_generic;
#define GENERIC(obj) ( ( FD_generic *)obj->form->fdui )
#define DUI(cast,obj) ( ( cast *) GENERIC( obj ) )
This can then be used as
void some_callback( FL_OBJECT *obj, long data )
{
FD_whatever *whatver = DUI( FD_whatever, obj );
[...]
}
Obvious extensions are
#define DUI_VDATA( obj ) ( GENERIC( obj )->vdata )
#define DUI_LDATA( obj ) ( GENERIC( obj )->ldata )
Bear in mind that if you have multiple instantiations of the
FD_whatever form, you'd have to keep multiple global FD_whatever
pointers and keep track of which one is which in some manner.
Of course, again, this is largely a matter of style and can be
something of a religious issue. I tend to avoid global variables
almost at all costs and find the mechanisms described above helpful in
managing data and context in complicated XForms applications where I
have multiple instantiations of forms.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/