Hi folks,

There are actually two odd issues here, but the second one, for which

this subject is named, seems even stranger than the first:

First Issue

I have a textbox, in whose Init() I have this:

THIS.AddProperty("OldValue",{})

THIS.Value = {}

(Let's leave aside, for now, that I could set the default value in

the property sheet instead of doing this, and I could use the Format

property to enforce good Date types. I don't do that, and haven't in

nearly 10 years of use.)

There are some programmatic methods that can set this textbox's value

to a Date coming from a Date field in one specific table without any

"translation", or to an empty date, as I do above. The table does not

accept NULLs.

The InteractiveChange() method of this control (fires when the user

is typing in the control) will compare THIS.Value to THIS.OldValue

and if they are not the same, THIS.Value will be copied to

THIS.OldValue, like so:

IF THIS.Value <> THIS.OldValue

THIS.OldValue = THIS.Value

ENDIF

There is identical code in the control's ProgrammaticChange() method,

so that the two properties are kept in synch when some other piece of

code changes the control's Value.

I have verified that no code ever can change the control's Value or

OldValue properties to anything that is not a Date. I have also

confirmed that there is no somehow corrupted value in the relevant

table's date column that is not a valid Date data type. Further, if

the user tries to type anything other than a digit or a slash into

the control, nothing happens, including that the InteractiveChange()

code does not run. The cursor just sits there, waiting for the user

to type a valid character. (Not directly relevant but just in case

you ask, I also can confirm that the standard un-trappable "Bad date"

error will occur if the user's entry consists only of dights and

slashes that do not correspond to a valid date.)

This is ancient code and it has not been changed in many, many years.

But today, for the first time (at least since my program started

emailing me when it crashes about a year ago) the line:

IF THIS.Value <> THIS.OldValue

triggered Error 107 ("Operator/operand type mismatch") in the

InteractiveChange() method.

That is the first odd issue. I cannot figure out for the life of me

how that could happen.

Second Issue

The code in the InteractiveChange() and ProgrammaticChange() methods

of this textbox was originally identical.

In order to add an error handler that displays a message, resets the

values to empty dates, and does not crash the program, I added:

IF TYPE("THIS.Value") <> "D" OR TYPE("THIS.OldValue") <> "D"

*Issue some message

THIS.Value = {}

THIS.OldValue = {}

ENDIF

to the InteractiveChange() method before it gets to the property

value-comparison line.

Then I inserted

THIS.Value = "Foobar"

Above that block to test my change and ran the program.

I began typing into the textbox. I immediately got Error 107 from the

**ProgrammaticChange()** method.

Yes, I had only made the change in the InteractiveChange() method.

But I expected that method to generate the error message. Instead,

somehow, when I started typing, InteractiveChange() ran to the point

where I set the control's Value to a string, executed that line, and

then, instead of generating the error message, execution somehow

jumped to the ProgrammaticChange() method, where Error 107 occurred on:

IF THIS.Value <> THIS.OldValue

????

I don't believe that InteractiveChange() is supposed to call

ProgrammaticChange() or vice-versa. That's why there are two separate methods.

I have often said that the VFP order of events does not always

proceed as advertised, and I guess here is proof.

Any thoughts?

Thanks and I hope you are amused.

Ken Dibble

www.stic-cil.org

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/25.D9.09875.E6961675@cdptpa-oedge01

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

At 07:45 2016-06-15, Ken Dibble <krdibble@stny.rr.com wrote:

[snip]

>Second Issue

>

>The code in the InteractiveChange() and ProgrammaticChange() methods

>of this textbox was originally identical.

>

>In order to add an error handler that displays a message, resets the

>values to empty dates, and does not crash the program, I added:

>

>IF TYPE("THIS.Value") <> "D" OR TYPE("THIS.OldValue") <> "D"

> *Issue some message

> THIS.Value = {}

> THIS.OldValue = {}

>ENDIF

>

>to the InteractiveChange() method before it gets to the property

>value-comparison line.

>

>Then I inserted

>

>THIS.Value = "Foobar"

>

>Above that block to test my change and ran the program.

>

>I began typing into the textbox. I immediately got Error 107 from

>the **ProgrammaticChange()** method.

>

>Yes, I had only made the change in the InteractiveChange() method.

>But I expected that method to generate the error message. Instead,

>somehow, when I started typing, InteractiveChange() ran to the point

>where I set the control's Value to a string, executed that line, and

>then, instead of generating the error message, execution somehow jumped to the

^^^^^^^

The ProgrammaticChange event "[O]ccurs when the value of a

control is changed in code." You just changed the value of the

control, so the event fired.

>ProgrammaticChange() method, where Error 107 occurred on:

>

>IF THIS.Value <> THIS.OldValue

>

>????

>

>I don't believe that InteractiveChange() is supposed to call

>ProgrammaticChange() or vice-versa. That's why there are two separate methods.

No, there are two separate *events*, because they fire for

different reasons. The docs for ProgrammaticChange Event start with

"Occurs when the value of a control is changed in code."

>I have often said that the VFP order of events does not always

>proceed as advertised, and I guess here is proof.

Not in this case.

>Any thoughts?

>

>Thanks and I hope you are amused.

Almost always.

Sincerely,

Gene Wirchenko

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

>>Yes, I had only made the change in the InteractiveChange() method.

>>But I expected that method to generate the error message. Instead,

>>somehow, when I started typing, InteractiveChange() ran to the

>>point where I set the control's Value to a string, executed that

>>line, and then, instead of generating the error message, execution

>>somehow jumped to the

> ^^^^^^^

> The ProgrammaticChange event "[O]ccurs when the value of a

> control is changed in code." You just changed the value of the

> control, so the event fired.

Ah.... Of course. Brain flatulence.

Having changed the code in both methods, my error handler works, so

I'm satisfied.

Issue One remains--but may never be solved.

Thanks.

Ken Dibble

www.stic-cil.org

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/FD.62.26258.66491675@cdptpa-oedge02

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

At 07:45 2016-06-15, Ken Dibble <krdibble@stny.rr.com> wrote:

>Hi folks,

>

>There are actually two odd issues here, but the second one, for

>which this subject is named, seems even stranger than the first:

Having a whack at this one now:

>First Issue

>

>I have a textbox, in whose Init() I have this:

>

>THIS.AddProperty("OldValue",{})

>

>THIS.Value = {}

>

>(Let's leave aside, for now, that I could set the default value in

>the property sheet instead of doing this, and I could use the Format

>property to enforce good Date types. I don't do that, and haven't in

>nearly 10 years of use.)

>

>There are some programmatic methods that can set this textbox's

>value to a Date coming from a Date field in one specific table

>without any "translation", or to an empty date, as I do above. The

>table does not accept NULLs.

>

>The InteractiveChange() method of this control (fires when the user

>is typing in the control) will compare THIS.Value to THIS.OldValue

>and if they are not the same, THIS.Value will be copied to

>THIS.OldValue, like so:

>

>IF THIS.Value <> THIS.OldValue

> THIS.OldValue = THIS.Value

>ENDIF

>

>There is identical code in the control's ProgrammaticChange()

>method, so that the two properties are kept in synch when some other

>piece of code changes the control's Value.

>

>I have verified that no code ever can change the control's Value or

>OldValue properties to anything that is not a Date. I have also

>confirmed that there is no somehow corrupted value in the relevant

>table's date column that is not a valid Date data type. Further, if

>the user tries to type anything other than a digit or a slash into

>the control, nothing happens, including that the InteractiveChange()

>code does not run. The cursor just sits there, waiting for the user

>to type a valid character. (Not directly relevant but just in case

>you ask, I also can confirm that the standard un-trappable "Bad

>date" error will occur if the user's entry consists only of dights

>and slashes that do not correspond to a valid date.)

>

>This is ancient code and it has not been changed in many, many years.

>

>But today, for the first time (at least since my program started

>emailing me when it crashes about a year ago) the line:

>

>IF THIS.Value <> THIS.OldValue

>

>triggered Error 107 ("Operator/operand type mismatch") in the

>InteractiveChange() method.

>

>That is the first odd issue. I cannot figure out for the life of me

>how that could happen.

A VFP bug is possible. I had a case with aliases where VFP

lost track somehow. This was in a loop where the loop could have

executed thousands of times on the table. It was also in code that

had run fine for quite a while.

What are the types and values of this.value and

this.oldvalue? Dump out that in your error handler. You might have

a VFP bug, but you might have something you overlooked.

[snip]

Sincerely,

Gene Wirchenko

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

>>IF THIS.Value <> THIS.OldValue

>>

>>triggered Error 107 ("Operator/operand type mismatch") in the

>>InteractiveChange() method.

>>

>>That is the first odd issue. I cannot figure out for the life of me

>>how that could happen.

>

> A VFP bug is possible. I had a case with aliases where VFP

> lost track somehow. This was in a loop where the loop could have

> executed thousands of times on the table. It was also in code that

> had run fine for quite a while.

>

> What are the types and values of this.value and

> this.oldvalue? Dump out that in your error handler. You might

> have a VFP bug, but you might have something you overlooked.

Have done, and if I'm still alive and not retired the next time it

happens, I'll let you know what I find.

Thanks.

Ken Dibble

www.stic-cil.org

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/EE.01.07436.DDB91675@cdptpa-oedge01

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

On 15/06/2016 15:45, Ken Dibble wrote:

> <snip>

> The InteractiveChange() method of this control (fires when the user is

> typing in the control) will compare THIS.Value to THIS.OldValue and if

> they are not the same, THIS.Value will be copied to THIS.OldValue,

> like so:

>

> IF THIS.Value <> THIS.OldValue

> THIS.OldValue = THIS.Value

> ENDIF

I don't get why you are checking using the interactivechange method.

This fires for every character you type in the control. If you want to

check a date I would use the Valid() or lostfocus() methods so you can

check the whole date not a half entered date. I only use the

interactivechange method when doing searches where you want to display

partial matches.

Peter

This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.

www.whisperingsmith.com

Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR.

Tel:0161 831 3700

Fax:0161 831 3715

London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/ef97da11-6707-6ec9-0a80-a075b8fa6648@whisperingsmith.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

On Thu, 16 Jun 2016, at 09:22 AM, Peter Cushing wrote:

> I don't get why you are checking using the interactivechange method.

> This fires for every character you type in the control.

+1

--

Alan Bourke

alanpbourke (at) fastmail (dot) fm

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/1466065899.4109184.639359977.68F49F1E@webmail.messagingengine.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

>>The InteractiveChange() method of this control (fires when the user

>>is typing in the control) will compare THIS.Value to THIS.OldValue

>>and if they are not the same, THIS.Value will be copied to

>>THIS.OldValue, like so:

>>

>>IF THIS.Value <> THIS.OldValue

>> THIS.OldValue = THIS.Value

>>ENDIF

>I don't get why you are checking using the interactivechange method.

>This fires for every character you type in the control. If you want

>to check a date I would use the Valid() or lostfocus() methods so

>you can check the whole date not a half entered date. I only use

>the interactivechange method when doing searches where you want to

>display partial matches.

LostFocus() does not fire unless and until something else gets focus.

There are actions the user can take that result in nothing having

focus, so LostFocus() is not a reliable place to validate

user-entered contents of controls.

My memory is more dim regarding Valid(), but I believe I experimented

with it and could not get it to work the way I wanted. Perhaps I was

trying to display a MessageBox concerning the user's entry and it

would only display a WAIT WINDOW or something. I don't know, but that

decision was made long ago.

Although my decision may seem idiosyncratic, it has worked in

practice, and in theory there is no reason why my use of

InteractiveChange() should cause the error I've seen.

Thanks.

Ken Dibble

www.stic-cil.org

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/E7.67.09039.2DCA2675@cdptpa-oedge02

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

>>I don't get why you are checking using the interactivechange method.

>>This fires for every character you type in the control. If you

>>want to check a date I would use the Valid() or lostfocus() methods

>>so you can check the whole date not a half entered date. I only

>>use the interactivechange method when doing searches where you want

>>to display partial matches.

>

>LostFocus() does not fire unless and until something else gets

>focus. There are actions the user can take that result in nothing

>having focus, so LostFocus() is not a reliable place to validate

>user-entered contents of controls.

>

>My memory is more dim regarding Valid(), but I believe I

>experimented with it and could not get it to work the way I wanted.

>Perhaps I was trying to display a MessageBox concerning the user's

>entry and it would only display a WAIT WINDOW or something. I don't

>know, but that decision was made long ago.

Okay, that was imprecise.

My code isn't validating user data, it's ensuring that the contents

of two properties of the control will always be exactly the same. So

intuitively, the place to do that is InteractiveChange().

My reason for not using LostFocus() is actually because the code must

fire in 100% of cases of user interaction with the GUI, including

cases when nothing gets focus.

In addition to the fact that long ago I couldn't get Valid() to work

the way I expected and therefore simply stopped trying to use it,

since I'm not validating user data in this case, intuitively, Valid()

is not the place for that code. More practically, I don't need a

return value from the code, nor do I want to condition ability to

move to another control on the results of that code.

Ken Dibble

www.stic-cil.org

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/6C.85.09039.404B2675@cdptpa-oedge02

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

At 11:20 2016-06-15, Ken Dibble <krdibble@stny.rr.com> wrote:

>[Gene Wirchenko wrote:]

>> A VFP bug is possible. I had a case with aliases where VFP

>> lost track somehow. This was in a loop where the loop could have

>> executed thousands of times on the table. It was also in code

>> that had run fine for quite a while.

>>

>> What are the types and values of this.value and

>> this.oldvalue? Dump out that in your error handler. You might

>> have a VFP bug, but you might have something you overlooked.

>

>Have done, and if I'm still alive and not retired the next time it

>happens, I'll let you know what I find.

Next up: the mixed feelings should you find the cause. The

satisfaction of having nailed it. The dissatisfaction that you had to.

The best I can suggest is to start suspecting

everything. Start close to the problem and spread out as

needed. That is what I did with my alias problem noted above. My

code should have worked and usually did, but since it did not, I had

to kludge it.

Best of luck.

Sincerely,

Gene Wirchenko

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.