code with old value (1 Viewer)

rainbows

Registered User.
Local time
Today, 09:52
Joined
Apr 21, 2017
Messages
425
hi this is some code someone helped me with a long time ago, and i am trying to go thro all the codes i have been given help with to try and understand how they work for future

this code works great but i am total confused how it gets the oldvalue as i have no feild anywhere calling it up

steve





Code:
Private Sub StockQty_AfterUpdate()

Dim OldValue As String
Dim NewValue As String
Dim MaterialID As Double
MaterialID = Me.MaterialID

OldValue = Me.StockQTY.OldValue
NewValue = Me.StockQTY

DoCmd.RunSQL "INSERT INTO TblDataChanges ( MaterialID, ChangeDate, ControlName, OldValue, NewValue ) VALUES ('" & MaterialID & "',Now(),'stockqty' ,'" & OldValue & "', '" & NewValue & "');"
Exit Sub

End Sub
 

ebs17

Well-known member
Local time
Today, 18:52
Joined
Feb 7, 2020
Messages
1,949
To understand this, you could visit the object catalog, which can be accessed using the F2 key in the VBA editor, for example.

Objects have properties, text boxes as controls of a form are objects of this form, and they have a number of properties, including Value and OldValue.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 11:52
Joined
Feb 28, 2001
Messages
27,191
@rainbows - Since you want to understand where .OldValue comes from, I'll explain a bit. This is a rough overview and I might have left out some things.

On a bound form, you can expect to have bound controls. If you make a change to a control on the form, one of the possible things you can do is a DoCmd.UnDo to reset the form to its original values. Another thing is to save the updated form. But how does that work?

Each bound control has three property-style values of note that describe its value. The first and most obvious property is .Value which is the visible value shown on the form (if the control is visible at the time). For bound controls, the second property is .OldValue, which holds the value that the control had as a result of the Form_Current event. That is because the underlying .Recordsource table/query supplied values to each bound control during _Current, and the values went TWO places... in .Value and in .OldValue, and this happens because of what happens with .Save vs. .UnDo methods.

When you do a .Save, the form updates the current record from the bound controls' .Value properties to the .ControlSource for that control, and then writes the updated record back to the .RecordSource, whatever it is. Then a _Current event starts that whole cycle over again.

When you do an .UnDo, the form updates each control by copying the .OldValue to overlay the .Value property, thus restoring the form's data to the values that were based on the most recent _Current event. An update of the .RecordSource is not necessary because after the .UnDo, the form's controls and the .RecordSource match again. Therefore, no .Save occurs.

The third property is ONLY for whatever control is currently in focus and is called .Text - the text of what is being manually entered into the control at the moment. The .Value property doesn't actually change right there. You can use backspace or other text editing shortcuts. When you tab out of that control, though, .Value becomes the "official" value and you can no longer reference that control's .Text property. This may be somewhat of an oversimplification of the .Text property, but it comes close.

For an unbound form or unbound control, there IS no .RecordSource or .ControlSource to supply an original value. In that case, no .OldValue property exists that you can reference, and an .UnDo has no effect. However, the .Text property IS available even for unbound controls when they are in focus.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:52
Joined
Feb 19, 2002
Messages
43,296
@The_Doc_Man 's explanation is better since it puts the .OldValue property in context and references the other two properties that hold the actual control's data at a different point in time. This is a real example of the weakness of doing a search in isolation. In ancient history before everyone learned the instant gratification of google, we used to have product manuals. They were far better for something like this because once you found OldValue in the index, it would take you to a section of the manual where in close proximity, if you opened your eyes, you would also see the definitions for .Value and .Text and how the three interact. I learned almost as much by reading the table of contents as I did by reading the entry the index or TOC pointed me to. In fact, using the TOC allowed you to drill down to a detail topic without actually knowing the proper search term. I really miss the original Access Manuals. I think MS stopped shipping them after A95 but they lived on in help until around 2003. They are now only a fond memory and help in Access sucks big time. When I search Access help, I want syntax FIRST. Instead I get bad forum references where people asked a question and never got a valid answer.

Also, the help entry uses the Forms!formname!controlname syntax and never explains why. When you are writing code within a form or report's class module, the preferred syntax is Me.ControlName, Why?
1. It gives you intellisense
2. It is more efficient since VBA knows in which class module the control is defined and it doesn't have to go through all the loaded class modules to find the dim for the variable.
 

Users who are viewing this thread

Top Bottom