Re: XForms: file selector - callback problem

T.C. Zhao (zhao@bloch.phys.uwm.edu)
Fri, 19 Dec 1997 22:49:55 -0600

To subscribers of the xforms list from "T.C. Zhao" <zhao@bloch.phys.uwm.edu> :

On Nov 26, 8:55pm, Michal Szymanski wrote:
> 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.
>
This is a bug, at least the behavior is not what I thought it was.

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?
I will correct the document. Also the return value of the callback
function is currently unused.

> The manual says also: "without the callback, the file selector is
> always modal" - what does this actually mean?
modal means (pseudo)blocking.

>
> 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).
>
Good proposal. I think no-blocking kind of goodies have their
places in the library and I will try to add some. Thanks.

_________________________________________________
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://bloch.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/