[XForms] New pre-release: xforms-1.0.92pre3

JOEL.MOOTS at L-3com.com JOEL.MOOTS at L-3com.com
Wed May 20 15:03:14 CEST 2009

To subscribers of the xforms list

> -----Original Message-----
> From: Jens Thoms Toerring [mailto:jt at toerring.de]
> Sent: Tuesday, May 19, 2009 3:07 PM
> To: Moots, Joel A. @ EOS; xforms at bob.usuhs.mil
> Subject: Re: [XForms] New pre-release: xforms-1.0.92pre3
> > Anyway, as that is the case, wouldn't it make sense to have all
> the
> > prototypes use 'long' since the FL_OBJECT argument member that
> > fl_set_object_callback sets is 'long' anyway? It shouldn't break
> any
> > existing code, and we'd be consistent at least. Any conversions
> from 'void
> > *' to 'long' and back would continue to behave the same, and we
> could always
> > switch any such unsafe code to use the extra u_ members, right?
> But then you would get a lot of warnings (and perhaps even com-
> pile time errors with C++) for existing programs that use correct
> arguments for e.g. form callbacks which expect a void pointer in-
> stead of a long. I guess I would be pretty annoyed if my cleanly
> compiling code suddenly would throw lots of warnings or worse...

It suddenly occurs to me that I've been arguing the wrong thing. From
glancing around, it seems to me that callbacks on FL_OBJECTs (e.g., that
can be set from fdesign) take 'long' for user data and all remaining
callbacks (that have a user data arg) use 'void *'. Is that wrong?

To unsubscribe, send any message to
xforms-leave at bob.usuhs.mil or see: 
List Archive: http://bob.usuhs.mil/pipermail/xforms and
XForms Home: http://savannah.nongnu.org/projects/xforms

More information about the Xforms mailing list