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.