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

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 seemingly 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 discussion. 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 subtracting 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