Re: XForms: pushed on FL_RADIO_BUTTON objects

From: Jan Menzel (
Date: Sun Dec 10 2000 - 06:57:33 EST

  • Next message: T.C. Zhao: "Re: XForms: pushed on FL_RADIO_BUTTON objects"

    # To subscribers of the xforms list from Jan Menzel <> :

    On Sat, 9 Dec 2000, Steve Lamont wrote:

    > # To subscribers of the xforms list from Steve Lamont <> :
    > > according to the manual "[...]pushed indicates whether the mouse
    > > is pushed within the bounding box of the object[...]" (page 267). For
    > > FL_RADIO_BUTTON pushed is only set once. ...
    > A FL_RADIO_BUTTON by itself acts strangely. If you had two of them in
    > a Group, they'd act as you might expect.
    Thanks, grouping them explicit works.

    > > ... For me this is a problem: in my
    > > application the buttons are update asynchronously using
    > > fl_idle_callback(). So I have a establish a prehandler for grepping the
    > > FL_PUSH and FL_RELEASE events for preventing changing the button state
    > > while the user pushes it.
    > I don't understand what you're trying to tell us here or what you're
    > trying to do.
    My application consists of two parts: one does periodic processing in
    background, the other displays the results in the controlling form. The
    background stuff is done using timer and SIGALRM. I found, the processing
    the signals synchronously with XForms using fl_set_signal_callback() is
    not fast enough. Therefor I did the dividing: the background process is
    now asynchronously and the form is updated with fl_idle_callback(). The
    problem is now, that the idle callback changes the form even if the user
    is just doing interactions. Eg. typing text into inputs: the changed value
    is by default updated at the end (pressing <return> or <tab>) but all the
    time the idle callback sets the current value into the input field. For
    coping with that I had to implement some kind of system telling the idle
    callback, that interaction is just taking place and that not updates
    should be done. For buttons if found it sufficient to evaluate the
    <pushed>-field. If pushed is set, the idle callback does not touch it at
    all. For browsers that does not work, because pushed is not updated. For
    inputs pushed is senseless: some kind of timeout for keyboard and mouse
    events is needed (-> problem "<automatic>-field and inputs").

    > > I reported a similar problem with browsers: either pushed is not
    > > set (that how it looks to me) or releases way before calling the browsers
    > > callback. (at least one fl_idle_callback() does happen before the callback
    > > is called and pushed is not set).
    > I think that the nub of the problem here is that the state information
    > within the FL_OBJECT structure is intended for use within object
    > handlers and not really for the use of applications directly. The
    > XForms main loop, as the manual says, diddles these as it so desires.
    > Since it's not entirely clear to me what exactly you're trying to
    > accomplish, I can't help much more than that.
    Thanks for helping.

            Regards Jan

     Dipl. Phys. | mailto:
     Jan Menzel |

    To unsubscribe, send the message "unsubscribe" to or see
    XForms Home Page:
    List Archive:

    This archive was generated by hypermail 2b29 : Sun Dec 10 2000 - 07:04:05 EST