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.