Hi Serge,
thanks a lot for testing!
On Sat, May 08, 2010 at 02:00:37PM -0400, Serge Bromow wrote:
> While testing I note that;
>
> When an input object is set to "FL_RETURN_ALWAYS" the input object
> returns even when other buttons are pressed. I have included a
> program you can use to test this behaviour. The form has 2 buttons
> and 1 input object. With the FL_RETURN_ALWAYS set, the program
> return the input object first and then the button that was pressed.
> In previous version the input only returned when key events were
> received. If you comment out the FL_RETURN_ALWAYS the program
> returns to normal behaviour.
>
> FL_RETURN_NONE = ok
> FL_RETURN_CHANGED = ok for buttons (only buttons return) but always
> returns for key events. Should only return at end if input changed.
I beg to disagree - what you describe as the expected behavior
is what you get for FL_RETURN_END_CHANGED, i.e. only return on
end and if the input fields content has changed. FL_RETURN_CHANGED
is (and always has been documented so) to be used for the case
when one wants each single change getting reported.
> FL_RETURN_END = always returns.
Yes, always the end of editing (i.e. when the input field loses
focus.
> FL_RETURN_ALWAYS = always returns.
FL_RETURN_ALWAYS IMHO makes only sense when its meant to be
the combinatation of FL_RETURN_CHANGED and FL_RETURN_END (i.e.
reports the object when either a change (keystroke) happened
or the inut field lost focus), so pressing the button should
actually enforce the object to be returned since pressing the
button makes the input object lose the focus (in your example
the loss of the focus isn't very obvious since there's only one
input field, which gets the focus back immediately after the
button has been pressed).
In earlier versions the behaviour with FL_RETURN_ALWAYS simply
was broken. I just tried your program with earlier versions:
In 1.0 and 1.0.90 FL_RETURN_ALWAYS didn't do anything at all,
i.e. you got the same behaviour as with FL_RETURN_NONE. That's
looks wrong and doesn't fit the documentation.
In 1.0.91 it did behave the same as with FL_RETURN_END_CHANGED.
Also not good, since already the old documentation said that
the object had to be reported on each keystroke (it didn't
mention the end of edit but, but without that it would be
just the same as FL_RETURN_CHANGED).
In 1.0.92sp2 it works the same as it does now, i.e. the object
gets reported on each change and on end of edit (loss of focus).
And that's what I feel it's supposed to do. Without this beha-
viour there wouldn't be any way to continuously monitor inputs
made by the user to validate and, if necessary, reject new
characters and also get informed when the user is done with
editing the field. I even seem to remember that there was
some discussion a long time ago just about this case.
Getting the button press reported after the input is also
necessary since you may have to get the input fields' con-
tent and e.g. store it in some variable before dealing with
the button event (or in the button event handler all fields
that have importance for what the button does would have to
be checked, which could become rather messy).
So going back to the old, buggy behaviour of 1.0.91 or even
1.0 doesn't seem to me to make much sense. I think that this
is one of the cases where the worthy goal of backward-compa-
tibility is topped by fixing a bug that made certain use
cases impossible. What do you think?
Best regards, Jens
--
\ Jens Thoms Toerring ________ address@hidden
\_______________________________ http://toerring.de
|