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:
OK.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.
I can see that.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 trouble;-)
I see your dilemma.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.
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) {
lockin_amplifier_sensitivity(input_VALUE(SENS_FIELD));
} ELSE IF input_changed(PHASE_FIELD) {
lockin_amplifier_phase(input_value(PHASE_FIELD));
}
}
hide_toolbox();
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.I understand your problem in this case.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
This is the crux of our discussion.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.
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.
Yes input objects are an curious beast.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.
Or should not get back the focus if the program moves on to other tasks.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.
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 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.
I don't see the relevance.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.
Still don't understand what the look or feel or delay or perception have to do with object interaction.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).
Yes can't.Now to the example you describe. You wroteI 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 canIs the this actually meant to be "can't"?
Yes you are correct. That was a poor example.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.
Here is a code view of what I mean;
while(1) {
ob = fl_do_forms();
if( ob == exitob ) {
exit(0);
}
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 ) {
continue;
}
exit(0);
}
if( ob == inputob ) {
perform_test();
}
}
The inputob object being called in advance of the exitob has no useful purpose.
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.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.
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
--
Signature
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.
--
Signature
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.