[Fwd: Re: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS); ]]

[Serge Bromow]

Hi Jens,

I will address each item and to further clarify I prepared a video to better explain my comments. You can view the video here;

http://www.dineamix.ca/tutorials/input_return.mpeg

You know what they say "A Video is Worth a Thousand Words". English, French, German or otherwise.

Jens Thoms Toerring wrote:

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. 

  

You are quite right. Not sure what I was thinking.

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).
  

Here is where we differ. I believe that hitting another object (other than an input object) should superceed the input return.

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).

  

I don't believe this is so. See the video for a proper working 1.0.90 FL_RETURN_ALWAYS.

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.
  

Sorry I wasn't there for the discussion.

What you say maybe true but it is impractical to enforce.

Example:
I have input field that returns to the callback and the data is invalid it return focus to the field.
Now all I want to do is dismiss the form with invalid data in the field. I can because the callback always returns me to the field where the button is ignored. We are trapped. (this is where I found the problem amongst other areas)

In the video you can see when I place focus on the browser the input field continues to return. I believe that another object should override the return status as in previous versions.

I further believe that it is inconsistent to return 2 objects with 1 event.

If it is necessary to test the field then this should be done in the program, not the library.

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).

  

You can catch the field call internally and update your data but not return the object. If the program needs the data it can be tested on the next event not forced by the library. You have to leave us programmers with something to do!!!

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?
  

Again I dont see the bug in my version but I am pretty sure the new approach at END for FL_RETURN_END and ALWAYS is not correct in practical terms.

Best Regards,

Serge

                           Best regards, Jens
  

--

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. 

--

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.