Unanswered: Trapping programmatically fired Events using WithEvents
I've got a Form with a TextBox on it. A Class Module has this TextBox set as a private module level WithEvents object, and defines an AfterUpdate event handler for it. A second class module calls the sets the value of the TextBox on the Form, but that doesn't fire the AfterUpdate Event. The AfterUpdate method of the TextBox on the form is called manually, but although that calls the TextBox's AfterUpdate method defined in the Form module, it doesn't call the AfterUpdate method in the Class Module.
Any ideas where I'm going wrong?
Private mclsMod1 AS clsModule1
Private Sub Form_Open()
Set mclsMod1 = New clsModule1
.TextBox = txtBox1
Public Sub txtBox1_AfterUpdate()
Class Module 1 (clsModule1)
Private WithEvents mtxtBox AS TextBox
Public Property Set TextBox(txtBox As TextBox)
Set mtxtBox = txtBox
mtxtBox.AfterUpdate = "[Event Procedure]"
Public Sub mtxtBox_AfterUpdate()
Public Sub UpdateTextBox(strFormName As String, strTextBoxName As String)
strUpdateCommand = "Forms('" & strFormName & "')." & strTextBoxName & "_AfterUpdate"
To call AfterUpdate method, your Textbox must be linked to a field, and your form linked to a table, then, instead of callind txt_textbox1_AfterUpdate directly, use the refresh method of the form, that should send the event AfterUpdate properly to control
I think your stuck on a dead-end. You can call yourself "hard-coded way" the event each time, but it might not be suitable for you since you use a Class module to not put code everywhere. If you were using Visual Basic, it would be very easy to do by using a SendMessage, but in Access, you are limited...
I've hit on a solution I think, although it's a bit of a nasty hack
I've added a generic handler to each Form which uses the class module, and this handler is called instead of the AfterUpdate method, with the name of the control as the argument. This is passed to the instance of the class module contained in the Form for proceessing...
I'd like to get away from using the extra method in the form though, if only to make the class module properly modular.
Just a typo - The actual code I've been using has a lot of other things happening so I just made up an example of the problem I was having.
The reason for all this is a replacement for a combo box based on remote data (in this case on SQL Server) - I have a hidden TextBox, a Label and an Image grouped as a "LookupField" Class Module. When the user clicks the image it pops up a Form (passing the name of the form and the name of the TextBox) which they can select the value in - when they double-click on their selection if closes this popup form and sets the TextBox to the returned value.
What I was trying to do is automaticaly detect when the TextBox value is updated, so that the Label can be updated with the relevant data (i.e. TextBox is "id" field, Label might be "name"). The user should never see the value of the id field as it is purely internal data. There may be several of these LookupFields on one Form, so it's important to make it as modular as possible.
The reason for going to all this trouble over using a combo box is the size of some of this remote data - there's several thousand rows in the SQL Server tables and it would be extremely inefficient to load them each time. The data is also extremely volatile, so can't be cached Client side without causing concurrency problems.
I think I've got it now though, but I'm going to do a bit more tweaking...