TC sez:
> ... another FL_DRAW for that object will be issued that
> can potentially screw up the window/clipping setting of the first
> FL_DRAW. In your case, I don't quite understand why it is
> MotionEvent that causes trouble. I will look into it.
It may be because I am also bracketing my draws with fl_freeze_form()
and fl_unfreeze_form(), which I don't recall if I mentioned or not. I
suspect that XForms's internal bookkeeping gets hosed somehow.
I can also potentially issue a couple of fl_activate_object() or
fl_deactivate_object() calls while down in my Free object handler.
If there's a more Kosher way of handling the need for a Free object
handler to alter another object's configuration, then I'd be happy to
hear about it. Nothing that I could think of was anything better than
a gross hack, which I'd like to avoid.
This, by the way, isn't a particularly high priority item with me. It
was more of a "what if" type experiment -- I wanted to see how my
Free object handler's Pixmap manipulation routines would work in
double buffer mode and bumped into this problem while doing the
experiment.
I also have strange problems with inexplicable core dumps in the
dynamic loader if I attempt to run the code on a 24 bit TrueColor
device and force XForms into PseudoColor mode. In this case, I'm not
sure whether I'm doing something bogus or XForms is being strange
since I haven't been able to trap the error -- it takes place
somewhere in the dynamic loader (ld.so) and covers its tracks to such
an extent that there's no traceback. I expect that this may be
because the dynamic loader may switch to a private stack while running
(or perhaps something even more bizarre).
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/