The LA Fox Developer Newsletter

December 1998

Value Assign (Con’t from page 1)

What I learned is that an assign method on the Value property

breaks something else very important. One of the standard

methods of determining if a record has changed is to use the

GetFldState() function. Unfortunately, the use of a value assign

breaks this technique.

What happens is this. When a value assign is created, the

standard code that VFP automatically places into it is as

follows:

Procedure Value_Assign

Iparameter vNewVal

this.value = m.vNewVal

return

When you assign a value to the Value property, the above code

merely does the actual assignment. You could add some code

that says “if the value I’m being assigned is outside a certain

range, don’t change the value.” You can see how this might be

valuable in certain situations. The resulting code might look like

this:

Procedure Value_Assign

Iparameter vNewVal

this.value = iif(m.vNewVal >= O,m.vNewVal,this.value)

return

This is a very simple example, but you get the idea. You can

control from a central location whether or not the. is

changed as well as call any related methods.

What I found in relation to GetFldState() was that when the user

moves to another record, the refresh event causes the value

assign method to fire. For example, the record pointer is sitting

on a customer record (CustlD = 1). The user clicks the Next

button and the record pointer is moved to the CustID =2 record.

The form is then refreshed so that the values in the controls will

reflect the values in the new record. This causes the value

assign method to fire and update the CustiD field from a value of

1 to a value of 2. Everything is fine so far. Unfortunately, what

you will find the next time the record pointer is moved is that

VFP thinks the current record has changed in every case, even

when nothing at alt has changed. This is due to the fact that the

object was changed by the value assign method. As far as VFP

is concerned, the record has changed even if nothing at all has

changed. Obviously this is not good and you don’t want to be

asking your users “do you want to save your changes”

everytime they move to another record regardless of the whether

they actually made changes or not.

The interesting thing is that a regular refresh (one without an

associated value assign method) does not cause this problem,

but adding a value assign method breaks GetFldStateØ. My first

thought to get around this was change the code to this:

Procedure Value_Assign

Iparameter vNewVal

if

.c>this.value

this.value = m.vNewVal

endif

return

This change was also quickly suggested in the FoxPro

newsgroups on the Internet, but it does not help. The point here

is that the record pointer is moving to another record and so the

values will be different. Therefore this IF statement will always

evaluate to true and the assignment will take place just as if the

IF statement weren’t there at all.

So what’s the solution to this? At this point I don’t know. My

current solution is not to use a value assign method. In the back

of my mind I hear a little voice that says “there’s probably a

work-around”, but I haven’t spent much time on it. Another voice

says “Yeah, but it will probably be kludgey” and so for the

moment I’ve decided that value assign methods, though seem-

ingly useful, are actually worthless.

Watch out for this problem in your own development and please

let me know if you find an elegant work-around. As I mentioned,

I haven’t spent a lot of time on this one. The article is mainly

designed to be a warning and to throw this issue out for discus-

sion. Maybe someone who feels they could put the value

assign method to extensive use will tinker with this problem a

bit. You can contact me at russcampbell©interthink.com.

Happy coding.

fEd. -Noie: Russell is the president vitild Atlanta FoxPro Useis

Group and is a frequent contributor to this newsletter.]

Computer Dictionary (Con? from page 2)

INTERIM RELEASE. A programmer’s feeble attempt at

repentance.

SCHEDULED RELEASE DATE. A carefully calculated date

determined by estimating the actual shipping date and sub-

tracting six months from it.

USER-FRIENDLY. Of or pertaining to any feature, device or

concept that makes perfect sense to a programmer.

USERS. Collective term for those who stare vacantly at a

monitor. Users are divided into three types: novice, intermediate

and expert.

Novice Users. People who are afraid that simply

pressing a key might break their computer.

Intermediate Users. People who don’t know how to fix

their computer after they’ve just pressed a key that

broke it.

Expert Users. People who break other people’s

computers.

Page 4