# To subscribers of the xforms list from Serge B Bromow <serge@omensys.com> :
(Sorry for the length of this post)
Well here is an interesting problem or bug or WHAT?
My main app uses a touch screen interface. It was brought to my
attention, that holding your finger on the touch screen for more that
30-40 seconds would causes the app to fail. This is unusual behavior for
an experienced finger but new staff tend to press on the screen until
they have located
their desired choice.
After a few weeks of going through my code I could not find any problems
and could not replicate the problem in the shop using my own touch
device(s). Once again, I thought my client was loosing his grip. I was
convinced since a number of clients use the same app without problems.
I did however, see the app fail and exit ungracefully at the client site
while performing some routine maintenance. (having a beer) I setup and
identical server and using the same touch device I was finally able to
replicate the failure.
The problem seems to be xforms related. Here is a snippet
of the offending code.
main()
{
fl_init();
fd = open("/dev/touch");
fl_add_io_callback(fd, cb_touch, 0l);
fl_do_forms();
}
cb_touch(fd, data)
{
FL_OBJECT *box;
fl_remove_io_calback();
while(TRUE) {
act = read_touch(&x, &y);
if( act == LIFT_OFF ) {
raise_button(box);
fl_add_io_calaback(fd, cb_touch,0l);
fl_trigger_object( box );
return;
}
press_button(x, y, box);
}
press_button(x, y, *box)
{
fl_set_mouse(x, y);
fl_check_forms(); /* < HERE IS THE ISSUE. (I THINK) */
box = fl_get_object_under_mouse( active_form );
/* test box, raise old, depress new and so on */
}
The particular controller that is used is an old "Micro Touch", running
at 9600bps and emits, as it turn out, about a 190 packets a second.
After 30-40 seconds over a 10000 packets and 10000 "fl_check_forms" have
been executed. Other controllers (Elo, ISI, Hampshire) running at the
same speed emit far fewer packets/second and do not cause this failure
to appear.
This may check_forms seems to causes the xforms lib to cause a
segmentation fault and the app fails. I added a trap for SIGSEGV and
returned the program to a safe place to continue executing. This
actually works! The program carries on as though nothing happened.
Not an X sort of guy so the following is pure speculation.
It would seem that this rather large number of "fl_check_forms" in such
a short period of times causes an overflow condition in the library.
Possibly pending request or something. After the Seg fault is trapped
and returned to a safe section in the code these request seem to catch
up and all is well again.
I can do a few things to minimize the effect of rapid execution of
"fl_check_forms" but I cannot resolve the xforms lib issue.
I can slow the touch controller down, however this is the native speed
for most controllers and is impractical to update each site with a new
controller configuration.
I can check to see if the cursor has moved X pixels from the last entry
and skip the check_forms if the delta is small. This however is not very
safe since the pointer may have moved to another button in that small
change.
Some one could show me a substitute for "check_forms". The only reason I
use it is to move the cursor to reflect to touch pointer location. If I
do not, the the test to see if an object is under the cursor fails to
return the proper button.
FINALLY!
Is a fix to the forms library possible to prevent the SG Fault or is
the an un reasonable expectation to update the form so many times / sec?
Is there another way to update the cursor position in the library so
that the fl_get_object_under_mouse( active_form ) works properly without
the use of fl_check_forms?
Any help appreciated,
Serge
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
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 30 2002 - 00:53:15 EDT