# To subscribers of the xforms list from Clive A Stubbings <firstname.lastname@example.org> :
> 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
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
Of course... the alternative is still... <big> ;-) </big>
int my_fl_input_changed(FL_OBJECT *obj)
if (obj && (obj->objclass == FL_INPUT))
> 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
email@example.com or see
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Tue Jul 11 2000 - 19:19:12 EDT