VFP variables or fields on forms - Detecting changes

[Colin Burton]

Hi all

is there a way to determine if the value of a variable or form field has changed

the reason i ask is because at some point in my code t is being changed. but i know not where or when

i can get at the values at the start of a process and can see that by the end they have changed

short of using a lot of messageboxes or wait winodows i am at a loss as to deertmine where my variable gets a new (WErong) value
and seeing as somewhere along this code rooute it opens up other forms it is making life tricky

TIA

Colin

 

[Tore Bleken]

Start the debugger, and ask it to stop when the value changes.

For a tutorial, read

http://www.tomorrowssolutionsllc.com/Articles/Learn to Use the Debugger.PDF

 

[ggreen61]

Create a custom class for the textbox, editbox, etc. Then add two new properties, ValueChanged and OrigValue. For the ValueChanged property use the Access method to do the following:

RETURN !(this.Value == this.OrigValue)

When you initialize the control, set both the Value property and the OrigValue property to the initial value. Now you can query the control ValueChanged property to see if it has been changed by the end user.

Greg

 

[Mike Lewis]

This is exactly why breakpoints were invented.

Go to Tools / Breakpoints within the Debugger. Choose "Break when an expression has changed". Put the name of the variable in the "Expression" field. Next, click the Add button. Then run the program.

Be aware that the breakpoint will probably fire more often than you would like, for example every time the variable goes into or out of scope. But it should give you something to work on.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

In the case of form properties, you can use BINDEVENT to find out where they are changed even at runtime, where breakpoints and the debugger are not available. But I second Tore, too. Within development that's the easiest way to find out.

Mike is also right it can get tedious if there are many changes and you need to find the one changing t to an illegal value, not all other changes.
In that case, a bind event monitoring will be able to log the changes without needing your interaction at every change.

Also, in the specific case of control.Value changes you have the control.ProgrammaticChange() event that's there for reacting to programmatic changes. And you can deny wrong values there or use PROGRAM(PROGRAM(-1)-1) to get the prg or class/method that caused the change and even the line number with ASTACKINFO(), provided you add debug info in your EXE.

Well, and last but not least the best method to react to changes is having defined a property_assign() method that will run whenever anything changes the property, passing in the new value. Again PROGRAM() or ASTACKINFO help you to find out where that came from.

Chriss

 

[JackTheC]

Do you mean the variable T changes unexpectedly?
I had that 25 years ago already. T seems to be used/changed by the VFP system.
Since then I use TT instead of T and never use single letter variables anymore.

 

[Mike Lewis]

Jack,

The reason that we avoid single-letter variable names is that the letters A to J are built-in table aliases, and M is used to distinguish variables from fields. But there is no problem in using K, L or N to Z. So I doubt if that is the cause of Colin's issue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

The issue is likely forgetting to make t local in one place. But as Colin didn't just talk about variables but also a "form field", the question is a bit vague. There is no such thing as a form field. He could come from a Visual Studio background and call properties fields or he could mean controls like textboxes, I don't know. Anyway, breakpoint expressions can watch over anything.

Chriss