Control bound to an expression - telling when it has changed

[avibandel]

Hi
I'd like to act upon an text control's content change.
the text control is bound to an expression.

The thing I want to implement is a text control which is bound to a normal field in a table, but also is filled automatically by summing some other fields on the form.

I've tried almost all events for the text control, but they all seem to be raised upon manual updating of the text, and not a calculated expression being changed.

[Stewart Ross]

Hi. There are no in-built control events that will recognise value changes in calculated controls.

You will need to reconsider what underlies the value change you mention; after all, the change in value results from an event somewhere else. Where does the change to the next value occur? How do you recognise it? What fields are affected, in what tables?

It seems to me that the change to the input values feeding the calculated control is what you need to trap - not the consequences on the dependent calculated control itself.

-Stewart

[missinglinq]

Stewart is right, of course, you need to trap what triggers the change in your control/field, not the change to the control/field itself. Here's a very simplified example.

You have three textboxes, txtFieldA, txtFieldB and txtFieldC. Basically

txtFieldC = txtFieldA * txtFieldB

so with txtFieldC being bound to a field in your underlying query or table, in the AfterUpdate events of txtFieldA and txtFieldB:

Private Sub txtFieldA_AfterUpdate()
 If Not IsNull(Me.txtFieldB) Then
   Me.txtFieldC = Me.txtFieldA * Me.txtFieldB
 End If
End Sub

Private Sub txtFieldB_AfterUpdate()
If Not IsNull(Me.txtFieldA) Then
   Me.txtFieldC = Me.txtFieldA * Me.txtFieldB
 End If
End Sub

Now if there are values in txtFieldA and txtFieldB, txtFieldC will automatically be updated and stored when the record is saved.

Welcome to Bytes!

Linq ;0)>

[avibandel]

Hi. There are no in-built control events that will recognise value changes in calculated controls.

You will need to reconsider what underlies the value change you mention; after all, the change in value results from an event somewhere else. Where does the change to the next value occur? How do you recognise it? What fields are affected, in what tables?

It seems to me that the change to the input values feeding the calculated control is what you need to trap - not the consequences on the dependent calculated control itself.

-Stewart

well, the text control i'm talking about holds a summary of a column in a subform.
What I want to do is to save this total into a different field, on some other subform.