[Top][All Lists]

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

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

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

 Hi Jens,

Sorry for the delay. I have been busy the past few days and yesterday I lost both Internet connections.

So lets begin..

Jens Thoms Toerring wrote:
Hi Serge,

   thank you very much for your patience and for sending
me the program you did the tests with!

First of all, my clained "observation" that the behaviour
was totally broken in 1.0.90 etc. was wrong - I guess I
must have made some mistakes when compiling and linking
my short test programs with the different library ver-
sions. Now using your test program and with a bit more
of attention to details I find that the change you obser-
ved happend on the transition from 1.0.90 to 1.0.91.
And conerning your video, I think your observations
are all correct.
Let me start with my reasons for making the change and
why I think the handing of input objects was not correct
in 1.0.90 and before by describing a real-world example

The program I use XForms with most is for controlling
devices used in experiments in physics and chemistry labs.
The user may want to set up a device and for that a form
gets opened. The form has several input fields where (s)he
enters values to be sent to the device. Each input field
has a callback, to be invoked when editing the input field
is finished and something has changed, so it's set to be
reported on the FL_END_CHANGED condition. In the callback
the new input fields content is validated and, if appro-
priate, the new setting is sent to the device. And then
there's, of course, a close button to be pressed when the
user is done.

With the 1.0.90 version and before there was this problem:
when the user edited a field and then pressed close the
callback for the last field edited was not invoked since
there was no notification that editing the field had ended.
Thus the form got hidden without the last changes the user
made being executed. Obviously, that led to some amount of
I can see that.
The only way around that problem was to make the code
for the close button, which in principle should just do
what's written on it, i.e. close the form, much more 
complicated by having to add code to check each and every
input field and compare it's value with how the device
is set and, if there was a deviation, set the device up
according to the corresonding input fields content. In-
stead of a simple, single line callback function for a
button that just does the obvious thing you now needed
a function that had to check a dozend of input fields,
talk to the device at least that many times and repro-
duced a lot of the code already in the callback func-
tions for the individual input fields.
I see your dilemma.
But it gets even worse: my program interprets scripts des-
cribing experiments. So the user can set up a new experiment
on his own without having me get involved. And in these scripts
such forms can be generated on the fly, i.e. the user can
define a simple form with a few commands, e.g.

  SENS_FIELD   = input_create("FLOAT_INPUT", "Sensitivity", 1 mV);
  PHASE_FIELD  = input_create("INT_INPUT", "Phase", 270);
  CLOSE_BUTTON = button_create("NORMAL_BUTTON", "Close");
  show_toolbox( );

That would make my program create a new form with an input
field for a float number (with a label "Sensitivity"), an
input field for an integer ("Phase") and a "Close" button.

Now to deal with the form from within the script you typical-
ly would have a loop similar to this

  WHILE toolbox_wait() != CLOSE_BUTTON {
      IF input_changed(SENS_FIELD) {
      } ELSE IF input_changed(PHASE_FIELD) {

toolbox_wait() sleeps until the state of one of the objects in
the form changes and returns that object. Looks simple, doesn't
it? And it is supposed to be simple since the users aren't ne-
cessarily experienced programmers.
What a great Idea. An app designer for Xforms.
But now comes the "strange" behaviour with 1.0.90. The user
enters some value in one of the fields and presses "Close".
But the new value is never set since my program doesn't get
notified that editing stopped and thus can't make toolbox_wait()
return to the script for that input field. The user, of course,
reports this as a bug - (s)he set a new value but it never made
it to the device. Now, I now can start to expain to him or her,
that, when the "Close" button is pressed, the changes made to
the last input field aren't reported back and, in order to get
around that, there are only two "fixes":

 a) Before (s)he presses "Close" (s)he has to move the cursor
    into another input field (or press <TAB>, at least if there
    is only a single input field) and has to tell his/her col-
    legues who also may use the script.

 b) Alternatively, when the "Close" button has been pressed
    (s)he must add lines for sending each of the values again
    to the device
or c) You check any changes to input field on close and perform the update for them.
In both cases the user will probably think I'm out of my mind
and unable to write reliable programs;-) But since I have no idea
what the user is going to put into the script I can't forsee what
needs to be done when the "Close" button (which I know nothing
about in advance nor what it is supposed to do) is going to be
pressed and supply the stuff the user didn't put in there...

All hinges on reliably getting notfied when editing an input field
 has ended. That's why I don't follow your argument of
I understand your problem in this case.
Here is where we differ. I believe that hitting another object (other
than an input object) should superceed the input return.

I see it exactly the other way round: each object should do its
stuff, regardless of any other objects that may exist. When an
input object notices that editing has ended and it's set up to
send a notification under this condition then it should do that,
whatever the reasons editing ended are. If you make the reaction
of one object dependent on what other objects exist or do I feel
that we might end up with an extremely compicated set of rules
that nobody will be able to understand fully anymore. And there-
fore I personally consider the behaviour in 1.0.90 and before to
be broken.
This is the crux of our discussion.

1st - We differ in what we consider END. I see it as TAB or ENTER or MOUSE FOCUS  to another input object. You added ANY OTHER  interaction to this list. The change of interaction to another input object is valid but I disagree when focus moves to a NON input field. I do not consider this END of input interaction. Rather I see this as new interaction.
2nd - Input object are unique in they allow for keyboard interaction and should be treated as unique. No simple object interaction rule here. That is to say they may not follow the sames rules as simple mouse events.
3rd - I believe that user interaction should always supersede previous xfroms directives. (like callbacks) The Human is the driving force for interactive request and should be.
4th - I believe we violate a basic principal by having fl_do/check_forms() return more than 1 object per interaction. This is a big one for me.

More on this later.
I admit that input objects are standing out a bit in the whole
scheme for two reasons: they have a long interaction time and
the focus seems to be in one of them all of the time, even during
interaction with other, non-input objects.
Yes input objects are an curious beast.
 But the latter is an
illusion, they lose the focus for the (short) interaction time
with the other object, but normally get it back immediately once
that interaction has ended.

Or should not get back the focus if the program moves on to other tasks.
The thing with 2 objects getting returned at once is a bit
of a red herring. Of course, there are now two events repor-
ted, but, at least with another input object it was the same
before when you think about it carefully: when going from
one input object you get also two events reported, the first
one for the end of editing of the first input object (which
forces the focus away from it) and then an event from the
second on interactions with it.
No not true. You only get the exiting object. The second event only occurs if you perform interaction with the second object. In this case the keyboard.
 The only difference between
going from one input object to another and going to e.g. a
button is that, under normal conditions, you just click on
the button and this ends the interaction with the button
nearly instantaneously (at least it feels like that) while
when going to a new input field it takes a bit more time
to hit a new key, thus a more noticable delay. 
I don't see the relevance.
But, actually,
when in your program you press the button down and keep it
pressed down, the end of edit condition is reported immedi-
ately, but the button only returns when you release it again
(which you can delay for as long as you're prepared to keep
the button pressed down).
Still don't understand what the look or feel or delay or perception have to do with object interaction.
Now to the example you describe. You wrote

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 

Is the this actually meant to be "can't"? 
Yes can't.

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)

I have  bit of a problem understanding your description. Do you
want to close the form despite one of the input fields containing
invalid data? If that's the case why doesn't you simply close the
form when the button is pressed, regardless of what's in the input
field? You get the report from the button and all that happens now
is that you also get an additional call of the input fields call-
back, just before the button press is reported.

The only way I can come up with at the moment how to "get trapped"
is when you have e.g. an "invalid input field content" flag that gets
set in the input fields callback and is evaluated in the callback for
the button and, when set, makes to button do nothing instead of
dismissing the form. In that case you would have trapped yourself,
at least until there's some reasonable content in the input field
(and that kind of "self trapping" is often useful when one can only
continue with all the information in a form being correct).

But when you are prepared to close the form even when it does
contain invalid content in one or more of the input fields, then
a single input fields callback hasn't enough information (or at
least shouldn't require that kind of information) to make deci-
sions about what the button can do. IMHO that should be left to
the descretion of the callback for the button that has to have a
wider field of view.
Yes you are correct. That was a poor example.

Here  is a code view of what I mean;
while(1) {
     ob = fl_do_forms();

    if( ob == exitob ) {

    if( ob == inputob ) {
       if( perform_test() == FAIL ) {
             "warn user"

If perform_test() is valid or not I cannot stop the program from doing exit(0). I can, but more kludge code is required.

Here is the same code with proper checking;
while(1) {
     ob = fl_do_forms();

    if( ob == exitob ) {
        if( perform_test() == FAIL ) {

    if( ob == inputob ) {
The inputob object being called in advance of the exitob has no useful purpose.

Sorry but, as you probably see, I haven't understood the point
you're making here. I went to your website and tried to down-
load the sources in the hope to find some place in your code
you were writing about but unfortunately, the download link seems
 to be broken - I get a "550 /pub/sources: No such file or direc-
tory" error message - so I wasn't able to perhaps have a direct
look at a place where this might be happening. 
Thanks for that. The FTP server now resides on a separate PC and the source was never made available there. I will make the changes.
Since I'm rather
sure that you have some valid points but I simply seem to be too
dense to "get it" I have to beg you to write something with some
extra details that might help me understand what's going on...
Perhaps it's just a difference in the way we think about how to
solve a problem at hand and I simply doesn't yet grok yours.

                          Best regards, Jens
Yes indeed there are valid points. On both sides. We both could go on finding solutions to the fl_input problem and fl_do_forms() return rules but there are more important issues at stake than coding techniques or semantics.

1st - By making changes like this the library risks breaking a lot of code.  In my case alone I find over 250 instance where I implicitly set the  input behaviour to RETURN_END and RETURN_ALWAYS. None expect to see 2 object returns.
2nd - Before making changes there should be some discussion. A search of the current archive yields no results for FL_RETURN. There may have been something before. Right now you and I are having this discussion. It is not being posted to the list for other peoples input. Maybe we should post the last few e-mail to the group to gain other perspective.

I understand that in your particular case the changes to fl_input code change made sense and it may for other instances but since there are programing approaches to your problem they should be used before altering the library to suite a particular condition.

Now all of that said we need a solution.

Here is my self serving possible solution.

We return RETURN_END and RETURN_ALWAYS to there previous behaviour. That is to say they do not return when other interaction takes place except moving to another input field.

Side Bar:
I see you have added more RETURN values than were available in 1.0.90. I just tried FL_RETURN_END_CHANGED which I tough would give me what I need thus leaving your changes alone. Return on input, return on end and do not return on other interaction. But it only return on END not on CHANGE.

Since you have new classes of returns then maybe you could add RETURN_ABSOLUTE or RETURN_PEDANTIC. Always return regardless of other interaction.

This would return expected behaviour for previous build applications and provide the type of return you require. Who knows I may benefit from such a RETURN in the future.

Just some thoughs,


Serge Bromow
DineAmix Inc.
(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.
(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]