Hi XFormers,
I've found strange behavior of file selector goodie. When one registers
callback for it (fl_set_fselector_callback), it works only for one
show-up of the file selector. After dismissing the goodie, the next
fl_show_file_selector() invocation gives the FS form with Cancel button
(which is not shown when the callback is registered) and with Dismiss
return button which seems to be a leftover from the "callback mode"
(normally it is Ready return button). And the callback is not called
by double-clicking the file.
I do not know if this is the right behavior - at least it is not
documented properly. BTW, manual says the callback function for FS
should be: void callback(cont char*, void *). In forms.h, however,
it is declared as "int" function. Is the return value meaningful?
The manual says also: "without the callback, the file selector is
always modal" - what does this actually mean?
This is a good point to propose a change (or addendum) for FS.
I think it would be very useful to be able to make FS fully
non-blocking. I a normal mode (w/o callback registered),
fl_show_file_selector() blocks interaction (although, e.g. idle handler
gets called, which is very good. Probably signals and I/O get serviced,
too - I did not check). In many situations it would be desirable to
have FS not block the interaction - fl_show_file_selector() would work
rather like fl_show_form. When I first found fl_set_fselector_callback
routine, I thought it was just what I was looking for - non-blocking FS
with the callback invoked when the user selects a file. Unfortunately,
it is only partly so: callback gets invoked on double click, but not on
"normal selection". There is also only Dismiss button instead of
Cancel and Ready. I'd vote to keep normal setup of FS buttons,
invoke callback on double click, Cancel and Ready and make
fl_show_file_selector() return immediately if the callback is registered.
The callback itself could either be unregistered every time (thus
requiring to re-register) or kept until it is unregistered by the user.
Of course, to keep people using the current API happy, it could probably
be easily implemented as a additional feature, e.g. by something like
fl_set_fselector_blocking(int yes)
The same trick could be also applied to informational goodies
(fl_show_message etc.). XForms 0.88 introduced a mechanism to dismiss
them programatically by use of timeouts and fl_hide_XXXXX, but I think
there are many situations in which the message has purely informational
value and the program could (and, in fact, should) continue leaving the
info for a user on the screen until he/she dismisses it by pressing OK
button (or through a timeout).
with best regards,
Michal.
****************************************************************************
Michal Szymanski Internet: msz@sirius.astrouw.edu.pl
Warsaw University Observatory Bitnet: msz@plwauw61.bitnet
Al. Ujazdowskie 4 Voice: 48-22-6294011 ext 23
00-478 Warszawa, POLAND FAX: 48-22-6294967
****************************************************************************
_________________________________________________
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/