Is There A Function That Tells If A Record Has Been Changed? 2

[drosenkranz]

Hello There,

Is there a way (like a dirty flag) that tells me if a user changed any of the values in the text boxes while they were on the form? I'm using optimistic row buffering.

Thanks.

The 2nd mouse gets the cheese.

 

[rgbean]

Yup, see GETFLDSTATE( ), OLDVAL(), and CURVAL().

Rick

 

[ramani]

Idea 1:
You can have a form level variable .. mChanged with intial value .f.

In the valid event of all the TextBoxes, you can put the code to set the value to .t.

When the editing starts, set that value to .f.
======================================================
Idea 2 :
When you start editing, do a SCATTER MEMVAR
When you complete, check the values with the memory values.
======================================================
Idea 3 :
Read the topic on OLDVAL() and CURVAL()
======================================================
It depends on how big is your form content and your application.

Also Read on GETFLDSTATE()

Hope this helps you.



ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[ramani]

wow.. Rick.. same time posting.. LOL.. ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[drosenkranz]

My thanks once again for the advice!
The 2nd mouse gets the cheese.

 

[ChrisRChamberlain]

ramani

Idea 1

With respect, using the .Valid event is not the correct place to put THISFORM.mChanged = .T.

There may not have been a change in the value of the control, but your method will always indicate there has been a change, irrespective of whether or not it's true.

The .InterActiveChange event only occurs in the event of a change to the value of the control, and so that is where THISFORM.mChanged = .T. should go.

Chris

 

[ramani]

Hi Chris,

Appreciate your reviewing.. In fact Valid event fires only when there is a change in the field content. But neverthless, idea 2 is better since the values can be comapred.

In idea 1, irrespective of the event used, the user just pressing some keys and putting back the same values, does fire the instances and record may not have be changed. So the wrong signal is obtained.

So for an accurate usage, I cannot recommed idea 1, though drosenkranz would get some view of trapping the changes.

Also, I have noticed that when the Forms Clasable (x) is enabled, and when the records are changed but without clicking SAVE, if the user quits by closing, the form quits without commiting the record. So it is safer to DISABLE the Forms Closable property whenever an editing starts. I bring this point because... instead of doing the disabling when start editing, actual value change when trapped (say using idea 2)..(routines to trap the value changes in each text or whatever box) the forms closable can be disabled. So this brings about the 'no need' for using a form level variable. At the saving place, if this is disabled then Save or else Leave as it is.. can be initiated... All these for broader reading... and many more can ba added..
Hope drosenkranz sorted his problems.. without my bla bla blassssssss.. hihihi

ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[ChrisRChamberlain]

ramani

In fact Valid event fires only when there is a change in the field content.

This statement is incorrect - the .Valid() event occurs irrespective of any change to the value of a control on exiting the control, hence my original comments concerning the placement of THISFORM.mChanged = .T.

Chris

 

[ramani]

Hi Chris... easy .. easy .. on me...
You are right as to the VALID EVENT firing everytime... at least the concept is that.... But I do not recollect when & where I had a situation to that not firing.. (which was staying in my mind). Anyway your writing is enlightening my conception.
In a Browse for example, VALID dosent fire unless a change takes place. This is recorded by microsoft in their help file.. May be this had stayed in my mind.

As for text box and normal controls, it fires every time.
Thank Chris for correcting me. I have a tendency to always use the LostFocus event for almost all validations. I am comfortable with it. ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[ChrisRChamberlain]

ramani

An alternative and more accurate way of using a form property to determine a change in value of a single control, is to assign the value of the control to the property.

In the .When() event put:-

THISFORM.OldValue = THIS.Value

In the .LostFocus() or .Valid() event put:-

IF ALLT(THISFORM.OldValue) # ALLT(THIS.Value)
[tab]* Changes made
ENDI

This method ensures that if the user has made a change to the value of the control, and subsequently reversed the change, then no change has in fact taken place.

You can also allow changes to the case of the value to be go unrecognised with:-

IF UPPE(ALLT(THISFORM.OldValue)) = UPPE(ALLT(THIS.Value))
[tab]* Changes to case may or not have been made
ENDI

You can then note that the record, as opposed to the control value, has changed by using a second form property such as THISFORM.lRecordChanged which becomes .T., in the event of a change.

Chris

 

[csr]

Since you guys are grinding out every little detail of these options ... here is another glitch on this code ...

In the following code, suggested above, if the user changes the value, leaves the field, and then goes back and changes it back ... the flag will indicate that changes were made.

And would be incorrect !

==========================================================
THISFORM.OldValue = THIS.Value

In the .LostFocus() or .Valid() event put:-

IF ALLT(THISFORM.OldValue) # ALLT(THIS.Value)
* Changes made
ENDI

===========================================================

I have used the concept of the OLDVALUE also, but I put it in the control itself. Then in the refresh method of the control I assign OLDVALUE to the present value of that control.

Then test the control's VALUE again OLDVALUE prior to saving. Now that may not be perfect in every scenario either. I guess that is why they came up with OLDVAL() and CURVAL() but my recollection is that those things are not perfect either ... in some situations. Don't ask me when, I don't use them because I don't try to determine if anything changed anymore. Keep things simple, that is my motto.

Don
dond@csrinc.com

 

[ChrisRChamberlain]

Hi Don

The statement you refer to is correct within the context of editing the value of a control.

What I was trying to explain is that you could reverse changes within the control without flagging a change, and indeed change the case of the value also without flagging a change, if it was relevant to do so.

Ramani's option didn't compare values so it would incorrectly flag changes regardless of whether or not changes had been made simply on the basis that the control had been "visited".

Your comments are accurate in that you could revert to the original value of the control in a subsequent "visit" and thus flag a change where no change had been made.

I too do not trust OLDVAL(), CURVAL() and GETFLDSTATE(), prefering SCATTER MEMO MEMVAR NAME object in the THISFORM.Activate() or appropriate event and then comparing values in the THISFORM.Deactivate() or appropriate event.

In the event of any change, you can individually qualify each change if required and offer the option of reverting to the original value, or simply update the entire record.

Chris

 

[weedz]

Hi guys, just an observation, but if you do not trust the regular VFP functions, how would you go about, testing this when you are using business objects that handle your table/view changes iso acting upon events that happen on the form or its controls (let's say in an automation server).

I know CURVAL() and OLDVAL() do strange things sometimes (I believe you have to specifically give the name of the datanase in some occasions). But the functions in itself work good enough for me.

Thanks for your attention,

Weedz (Wietze Veld)

http://www.crowncap.demon.nl

They cling emotionally to code and fix development rather than choosing practices based on analytical assesments of what works best. - Steve McConnell

 

[CDavis]

This has been an interesting discussion that prompts me to ask if .null. values are accounted for in the methods listed. In other words if a particular field originally contains a null value and is subsequently changed to some other value and then deleted prior to committing changes would the field still end up with a null value and is there any situation in which that might be important?

 

[drosenkranz]

Lots of options and good insights. All of you at Tek-Tips have made coming back to FoxPro (after more than just a few years away) a lot more pleasant. Your time and expertise is always appreciated my friends. Great stuff!
The 2nd mouse gets the cheese.