> The major common point of all suggestions was to use *global*
> pointers. I thought I could avoid this. Internally (in XForms) there
> are pointers to the first and the last object of a form. ...
> [...]
> So I could find any object in any form and identify it. The own
> thing missing was/is a possibility to distinguish:
>
> "is this the customer form's name field"
>
> or
>
> "is this the customer form's street field"
You can avoid using global pointers by using the u_vdata fields in the
object's FL_OBJECT structure. The u_vdata field (declared as pointer
to void) can be used by your application to point back to whatever you
wish. You can use it to point to specialized data for the object or
some context information that you wish to share between objects.
In addition, each object has a pointer back to the form in which it
resides (the form field). The FL_FORM object also has a u_vdata field
which may be used by the application.
What I generally do is to use the form's u_vdata to point to a context
structure which contains, among other things, the pointer to the FD_*
structure generated by the fdesign create routine. Given that and the
FD_* structure definition, I can find any object on the form. If my
context structure also contains the FD_* pointers to any sibling forms
I can manipulate them as well as long as I have their structure
definition.
For instance:
typedef struct {
FD_this_form *this_form_ptr;
FD_that_form *that_form_ptr;
[...]
} Context, *ContextP;
Then, I can do something like
FD_this_form *this_form;
FD_that_form *that_form;
ContextP context_ptr;
[...]
this_form = create_form_this_form();
this_form->this_form_form->u_vdata = context_ptr;
context_ptr->this_form = this_form;
that_form = create_form_that_form();
that_form->that_form_form->u_vdata = context_ptr;
context_ptr->that_form = that_form;
Now you shall have context wherever you go.
So, in your callback:
void some_callback( FL_OBJECT *obj, long data )
{
ContextP context_ptr = ( ContextP ) obj->form->u_vdata;
FD_this_form *this_form = context_ptr->this_form;
[...]
fl_do_something( this_form->other_object, argument );
[...]
}
Note that the FD_* structures *also* have vdata (not u_vdata) and
ldata fields within them upon which you can hang your favorite
pointer.
So there is very little need within XForms to use global variables.
In most of my code globals are extremely rare. In fact about the only
place where I use them are as flags for signal handlers where I have
no other alternative.
> Maybe it's useful to add an 'object ID' to the FL_OBJECT structure?
You can do this yourself by using the u_ldata field of the FL_OBJECT
structure, though using a scheme such as I show above, it's not really
necessary.
> Have a nice weekend, everybody on the list :-)
Ditto. (Ugh! I used a Rush Limbaughism.)
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/xforms-archive/