# To subscribers of the xforms list from Jeff Pierce <wd4nmq@comcast.net> :
If you want to hide a form with an input object, why does hiding it's
parent form cause the object's callback to be called even when another
object's callback hid the form?
Lets say you have a form that is used as a dialog box. It has 2 objects,
an input and a buttom. The main app creates the dialog, you click the
button WITHOUT typing in the input. Everything is cool, the buttons
callback is called, it reports no input exists and hides the form.
Now, the dialog is created and you enter data in the input string. If
you simply hit <return> everything works the way it should. The input
string callback is called which reads the input and then hides the form.
However, If you either click the button or the forms 'X' in the window
manager after entering data in the input the app craters with the following.
In searchFindButton(), data = 2
Input = test string
In getSearchstring(), data = 1
Input =
In fl_hide_form [forms.c 865] recursive call ?
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 10 (X_UnmapWindow)
Resource id in failed request: 0x0
Serial number of failed request: 1391
Current serial number in output stream: 1393
From my debug,messages, this seems to be the sequence if you hit the
button object and you have put text ion the input object.
The button call back is called and I read the text in the input object.
The button callback then executes the fl_hide_form.
Then, for some reason as fl_hide_form is being executed, it calls the
input object callback. Which also read the input text, which there
is none because the button callback read it, This callback then ALSO
excutes fl_hideform and the app craters.
The behavior is the same for the window 'X' box.
Removing the input's callback fixes teh problem. But, then you cannot
use the <return> key to start the search.
It seems that the fl_hide_form is trying to ASSUME what I want to do and
is forcing what that on my code.
Shouldn't this be considered a bug?
-- Jeff, wd4nmq wd4nmq@comcast.net http://mywebpages.comcast.net/wd4nmq_________________________________________________ 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/ Development: http://savannah.nongnu.org/files/?group=xforms
This archive was generated by hypermail 2b29 : Sun Apr 13 2003 - 13:26:19 EDT