Last time I was curious about this topic. What happens in the BeforeUpdate event to two separate controls that are bound to the same column?
So rather than wonder what would happen… how about we test for the behavior we would want in this situation… which begs the question, what kind of behavior do we want?
- I might want to just know which control was updated, from what to what.
- I might just care about the bound field and what is getting updated.
And why might someone actually want to bind 2 different controls to the same underlying database field?
I think since this is a form auditing class, it should ideally be able to differentiate which form field made the change. So now I’ll write a test assuming that and see what happens.
I have created a new field called TestTextAlso which is bound to TestText, the first field I created.
Let’s see if this wreaks havoc on our existing tests:
Nope, no problem whatsoever. I guess that probably means that the BeforeUpdate routine is actually only specifying which form fields are being modified. I’ll write a test to verify that behavior.
'@TestMethod("Verify Changes")
Private Sub WhenTwoFieldsAreBoundToSameData_BeforeAndAfterValuesAreReturnedOnlyForTheChangedField()
Dim dctInputs As New Scripting.Dictionary, colResults As VBA.Collection, FieldInputsMatched As Boolean, OtherFieldInputsDontMatch As Boolean
Set dctInputs = CreateAndAddToInputDict(FieldToChange:="TestText", InitialValue:="BeforeValue", ChangeTo:="AfterValue")
Set colResults = SetFields_ChangeThem_ReturnNewListOfChanges(dctInputs)
FieldInputsMatched = FieldInputsMatchResults(dctInputs, colResults(1).FieldChanges)
Set dctInputs = CreateAndAddToInputDict(FieldToChange:="TestTextAlso", InitialValue:="BeforeValue", ChangeTo:="AfterValue")
OtherFieldInputsDontMatch = Not FieldInputsMatchResults(dctInputs, colResults(1).FieldChanges)
Assert.IsTrue FieldInputsMatched And OtherFieldInputsDontMatch
End Sub
And there it is and it Failed!
Ok, more exploring on this tomorrow. What are those fields really returning?