Allan Rae <[EMAIL PROTECTED]> writes:
| > FD_form, declared in class FormBase is:
| > struct FD_form
| > {
| > FL_FORM *form;
| > void *vdata;
| > char *cdata;
| > long ldata;
| > };
| >
| > What are vdata, cdata and ldata? They aren't used in the
| > code. Are they just historical baggage?
|
| They are xforms baggage. XForms wants them. It just happens to expose
| some of its internals in the generated code.
XForms baggage but inserted by fdesign.
|
| > Furthermore, to quote forms/README:
| > "Name all buttons and other form components that
| > are likely to cause a callback. The names should
| > be of the form: button_ok, radio_group_item and so on"
| > Why?
| > They all get connected as a linked list (or something) by xfoms anyway
| > (fl_add_text) and xforms deals with their destruction. They are
| > mentioned only in build(). Nothing else needs to know about them.
| > Obviously, you know a LOT more than me, but is this not true for all
| > the pop-ups: all that matters to the rest of the code is the callback
| > which is tied to a particular button etc in build(). It's the callback
| > that is important, not the button itself.
|
| IIRC there were a couple of cases where we needed to identify the button
| in the callback. I can't remember why we didn't just use the callback
| value. Anyway, it is also a lot easier to read the code when we can see a
| button name. I remember now. If you want to disable a button -- such as
| when the document is read-only -- you have to name that button in order to
| be able to disable it. Likewise for inputs.
If in the callback fro a xforms object want to do something with the
class/object that the button really/cncepually belongs to you need to
pass a pointer to the class/object in the u_vdata variable of the
xforms object, and then to a cast (static:cast) in the callback... you
can see this done in a lot of callbacks.
Lgb
