Re: XForms: Input object change detection

From: Clive A Stubbings (
Date: Tue Jul 11 2000 - 18:59:10 EDT

  • Next message: Peter Firmstone: "XForms: assistance and support for sparc glibc 2.1"

    # To subscribers of the xforms list from Clive A Stubbings <> :


    > I suppose that's okay if it's okay with TC but I'm not sure why you
    > can't use a filter function to detect and record this information.


    1. Assuming u_ldata is not used (which is probably true for input objs
       at the moment)
    2. The data is there already in the structure.. I can see it but can't
       legally access it.. and thats real frustration ;-)
    3. In an object/GUI system, it seems strange not to be able to ask
       the object whether it has changed
    4. It needs doing to every input object in the app (over 80 at present),
       and it makes using filters for real input validation harder (though
       not impossible).
    5. The reset of u_ldata would also need to be done where I set the value of
       each object since FL_RETURN_END is no use because it returns
       if the object hasn't changed - and in this case it matters..
    6. The objects all have callbacks, which makes for a lot of places
       to find where I have to set u_ldata to 0.

    That said, if you really have a major problem with it...

    I can probably do something with a sed script to overload the fl_add_input()
    calls generated by fdesign (actually this has given me some other ideas.. heh heh..)

    Then overload all the fl_set_input calls and then the hard bit is find all
    the input object call backs to reset the "changed" bit.

    I'll have to look to see if the filter gets called on a multi-line input
    object when a tab is input? Is there anyway to move the input focus to the
    "next" object?

    Of course... the alternative is still... <big> ;-) </big>

            int my_fl_input_changed(FL_OBJECT *obj)
                     if (obj && (obj->objclass == FL_INPUT))
                            return(((int *)obj->spec)[7]);
                            return 0;

    > While it clearly is more application programmer code, I'm not sure
    > that adding additional functions to an already large API is the right
    > way to go.

    Well.. I guess in this case, it would be 2-300 lines, but I may be able to
    cut it down to a 100 or so with some 'sed scripting'..
    And I'm one of those old fashioned people who remember when a 15M disc
    was so big we partitioned it into 3 bits!

    > My opinion, of course.

    Can't argue with that.. ;-)

    To unsubscribe, send the message "unsubscribe" to or see
    XForms Home Page:
    List Archive:

    This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 19:19:12 EDT