xforms-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALW


From: Serge Bromow
Subject: [Fwd: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS); ]]
Date: Sat, 15 May 2010 12:46:34 -0400
User-agent: Thunderbird 2.0.0.24 (X11/20100228)

Hi Serge,
   I sent the following reply to your mail to the XForms
mailing list last night, but the list seems to be ex-
tremely slow at the moment - while it's in the archive
it doesn't seem to have been sent out to the subscribers.
Thus I forward it directly to you so you don't have to
wait for an answer any longer.

                         Best regards, Jens

----- Forwarded message from Jens Thoms Toerring <address@hidden> -----

Date: Sat, 8 May 2010 21:28:49 +0200
From: Jens Thoms Toerring <address@hidden>
To: Development with and of XForms <address@hidden>
Subject: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS);
User-Agent: Mutt/1.5.20 (2009-06-14)

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

----- End forwarded message -----


--
Serge Bromow
DineAmix Inc.
<address@hidden>
(613) 260-8629
888 411-6636
Ottawa, Canada.



IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify DineAmix Inc. immediately by email at address@hidden.

Thank you. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]