changeValue code misbehaving
Andy Fox
Hi
I have a form with a combo box field with code attached to the changeValue
method to get the user to confirm that the new value is really intended.
This works OK when changeValue is triggered by clicking on another field on
the form, but if the "OK" button on the form is clicked the form doesn't
close and the button stays depressed until the mouse moves. The "OK" button
only has a formReturn attached to it.
It appears the msgQuestion box called by the changeValue stops the "OK"
button's code from executing.
Am I missing something obvious, please?
Thanks
Andy
Ken Loomis
Andy: try this: Put in the NewValue event:
If eventinfo.reason()=EditValue then
self.action(EditCommitField)
Endif
This will cause changeValue to fire when the field is changed and
without your needing to move off the combo box.
Ken
Andy Fox
Thanks Ken, the problem with committing the change automatically is that if
the user answers "No" to the msgQuestion box I want to disable the change.
I'm still interested to know why the "OK" button's code doesn't execute.
"Ken Loomis" <kloomis@it-re--.com> wrote in message
news:geork0hh3agldoogu...@4ax.com...
Ken Loomis
On Sun, 19 Sep 2004 22:33:11 +0100, "Andy Fox"
<nos...@cnews1.corel.dmz> wrote:
>
>Thanks Ken, the problem with committing the change automatically is that if
>the user answers "No" to the msgQuestion box I want to disable the change.
>
Did you try it, I believe you can still use changeValue, but I haven't
looked at it in a while.
Ken
>I'm still interested to know why the "OK" button's code doesn't execute.
because it's waiting on the changeValue?
Bertil Isberg
Andy
Does the OK button has TabStop checked or unchecked?
--
Bertil Isberg
CTECH
FAQ newsgroup: corel.wpoffice.paradox-faq
Paradox Buglist: http://w1.826.comhem.se/~u82608896/
remove spamfilter (reversed) to reply
Egbert Babst
Andy,
I guess, Bertil met the point.
If TabStop isn't activated, clicking the button would not move the focus off
the field and so it could not trigger the changeValue.
Egbert
"Andy Fox" <nos...@cnews1.corel.dmz> schrieb im Newsbeitrag
news:414df534$1_1@cnews...
Andy Fox
Ken - yes I did try it, thanks. It does what you say it should but that
isn't quite what I want.
Bertil - the tab stop on the button was set to on. Set it to off and
everything now works perfectly! Thanks for solving the problem, I'd like to
know why the tab stop makes a difference though.
Andy
"Andy Fox" <nos...@cnews1.corel.dmz> wrote in message
news:414dba74$1_1@cnews...
Egbert Babst
Andy,
:-O I would have thought the opposite?
Egbert
Egbert Babst
Hmm, can't see my post, so I'll try it another time. Perhaps this will be
doubled...:
This made me curios, so I tested.
What happened was:
If TapStop *isn't* activated, the button fires as desired. But: As I said
the focus isn't moved off the field, so the changeValue is not triggered and
no confirmation will be asked within changeValue. Try it.
If TapStop *is* activated, changeValue is triggered if the value isn't yet
committed, but then the pushButton doesn't fire.
If you push the button another time it fires because the value is already
committed und doesn't need to fire another changeValue.
Bertil, how does changeValue (P9 SP3) hinder the execution of pushButton?
Strange.
Egbert
"Egbert Babst" <Egber...@BabstSoft.com> schrieb im Newsbeitrag
news:414e9734$1_1@cnews...
Bertil Isberg
Egbert
<<
Bertil, how does changeValue (P9 SP3) hinder the execution of pushButton?
>>
It depends on the code in the changeValue() event.
setErrorCode() will prevent the newly entered value to be committed and
will also prevent departure.
When focus is to be moved off the field, changeValue is triggered and
then what happens depends on the code.
If the button does not have TabStop, clicking the button won't trigger
changevalue unless there is code that issues a EditCommitField for the
field object.
Bertil Isberg
Andy
<<
I'd like to
know why the tab stop makes a difference though.
>>
Show the code in the changeValue event and newValue event for the field
as well as code in the button.
Egbert Babst
Bertil,
> It depends on the code in the changeValue() event.
Below I show my testcode, that does nothing else then show a view(). So I
can't (till now) understand, why pushButton then does not work.
I've proved that the focus went to the pushButton. So changeValue is
triggered and shows the view(). But then the button does not do it's default
behavior.
> setErrorCode() will prevent the newly entered value to be committed and
> will also prevent departure.
That's clear.
> When focus is to be moved off the field, changeValue is triggered and
> then what happens depends on the code.
That's what I meant and tested.
> If the button does not have TabStop, clicking the button won't trigger
> changevalue unless there is code that issues a EditCommitField for the
> field object.
Exactly! And that means, Andy is missing the confirmation of
changeValue-code, if he deactivate TabStop of the button and doesn't set
explicitly something like myDropDownField.PostRecord() from within the
pushButton-method.
Test:
----
I've a form with an unbound Drop-Down-list-field "TestDropDown" containing 3
values "AAA", "BBB", "CCC".
The changeValue of this field is:
<<<
method changeValue(var eventInfo ValueEvent)
view("Change Value occurred")
endMethod
>>>
Then there is a pushButton with the following simple code:
<<<
method pushButton(var eventInfo Event)
view("Hi")
endMethod
<<<
If the button's TabStop is activated and I choose a value from the
drop-down-list and then clicking the button gives me:
message: "Change Value occurred"
That means, changeValue was triggered.
But I don't get the "Hi" what means, the pushButton() didn't occur.
Now a click at the drop-down-field without selecting a value (only to set
the focus there) and a second click to the button and I get
only message: "Hi" what means, now no changeValue took place (of course not,
the value was committed and no new one was chosen) and *now* the pushButton
fired.
Same procedure now with TabStop de-activated:
I get each time only the "Hi" message and no changeValue message (also
clear, because the focus didn't move).
So again the question:
How could showing a view-window resp. triggering changeValue prevent
pushButton from working. There is no eventInfo.setErrorCode(userError) or
anything else that would do this explicitly.
Do you have an explanation or is this possibly a bug?
What ever it is, it's good to know this behavior and I'm glad, Andy
mentioned his observation.
Egbert 17:35 in Germany
Bertil Isberg
Egbert
view() and msgInfo() can cause the pushButton event to act funny.
If button has TabStop checked, changeValue will occur on mouseDown() for the
button. But pushButton() event is triggered when mouseDown() and mouseUp()
are sent to the same object. When changeValue() executes a view() on
mouseDown(), and you close the view() box with the mouse, the mouseUp()
won't reach the pushbutton object.
Close the view() box with enter key, and you'll see the difference.
Or replace the view() statements with a assignment to a text object instead,
and you'll also see a correct event chain.
Never use view() and msgInfo() when analyzing mouse events unless you close
the dialogs with the keyboard.
--
Bertil Isberg - CTECH
Paradox buglist:
online: http://w1.826.comhem.se/~u82608896/
FAQ newsgroup: corel.wpoffice.paradox-faq
Egbert Babst
Bertil,
thanks, this makes perfectly sense for me. Quite clear analysis, it's just
Bertil :-)
No question left!
Thanks again.
Egbert 00:20 in Germany
"Bertil Isberg" <bertil.isberg@NOcomhemSPAMdotse> schrieb im Newsbeitrag
news:414f415b_3@cnews...
Andy Fox
Egbert,
I've tried your test code and this does illustrate my problem.
Have you noticed when you close the form the "Change Value occurred" message
appears. Presumably the changevalue is triggered as the closing of the form
commits the change anyway.
I didn't think it was a problem in my application. The field in question is
an unbound field which is read by the calling form. If focus moves to
another field on the called form my confirmation code triggers as normal. If
the user goes straight to the OK button the confirmation code is triggered
when the form closes. I now find that if the user decides to cancel the
change after moving to another field it is fine. However, if the user makes
a selection from the dropdown list, then goes straight to the "OK" button,
because the option to cancel the change is triggered by the form closing it
is too late to prevent the change and the calling form has already read the
wrong value.
BTW I should have said I'm using P9 SP3 also.
"Egbert Babst" <Egber...@BabstSoft.com> wrote in message
news:414ef2ca_3@cnews...
Egbert Babst
Andy,
my observation is pretty well explained by Bertil and I'm glad to see, that
all follows a strict logic and is not a bug but a consequence of Paradox's
event-model.
<<<
However, if the user makes
a selection from the dropdown list, then goes straight to the "OK" button,
because the option to cancel the change is triggered by the form closing it
is too late to prevent the change and the calling form has already read the
wrong value.
>>>
If you like to give the user control also when going strait forward to the
OK-Button, you simply can de-activate the button's TabStop (what you already
have done, indeed) and avoid this way the changeValue at this point. Then
within the pushButton-method you can put another value-check similar to this
you do within the changeValue of the combofield. This is possible, because
the chosen value isn't yet committed. If it fails you can branch to stay
with the form, otherwise you may close it and let the caller-form read the
correct value.
Here the modification of the simple test-code to visualize what I meant:
<<<
method changeValue(var eventInfo ValueEvent)
;|| Assuming this is the validity check of the drop-down-field
if eventInfo.newValue()="BBB" then
view("Please check this value!")
eventInfo.setErrorCode(userError)
endIf
endMethod
>>>
Here the code for the button (TabStop not checked):
<<<
method pushButton(var eventInfo Event)
if TestDropDown'value="BBB" then
;|| Because of unchecked TabStop the focus
;|| remains at the field and the user can choose another value.
view("Please check this value!")
else
;|| Here you may place the 'FormReturn'
view("Alles OK")
endIf
endMethod
>>>
Egbert 01:44 AM in Germany
Bertil Isberg
Egbert
For a combo field, I would rather look at possibilities when forcing
changeValue() to occur when a new value is selected.
newValue event
if eventInfo.reason()=EditValue then
self.action(EditCommitField)
endif
changeValue event
whatever code to test the value
Egbert Babst
Bertil,
yes you're right. I tried to adapt what I read from Andy.
But personally I do always what you recommended. It's really simple because
the newValue(...) in these cases is triggered just after you chose a value
of the list and you need not to leave the field.
And I see this as a hint to you Andy to check your code in the way Bertil
told.
As I told, I've learned something to keep in mind about pushButtons,
mouseclicks and standard dialog windows. I knew well what was triggering
pushButton (mousedown and mouseup at the same object) but I didn't think
about the rest (mouseup did not happen to the same object).
A comment: OPAL really is simple compared with other full OOP-languages but
to use it reasonably it is a *must* to think within the logic of the
event-model - and this isn't that easy for a beginner. Example: I had a lot
of trouble at the beginning because I used very often objects directly in
forms like ui.Home(), ui.Action(...) and got a lot of hard to control
avalanches of primary and secondary eventstreams. Nowadays I do as much as
possible with tcursors.
Bertil, it's such a pity that you can not visit the Convention!
Egbert, 9:54 in Germany
"Bertil Isberg" <bertil...@retlifmapsSCB.se> schrieb im Newsbeitrag
news:414fcee5$1_3@cnews...
Andy Fox
Thanks to everyone for the help. I now understand what is happening,
although it took me a little while and some experimenting!
"Egbert Babst" <Egber...@BabstSoft.com> wrote in message
news:414fd959$1_2@cnews...