Im using the ajbcalendar button to populate a text box for dates. I have an afterupdate event that makes a control visible when the value is not null. It works fine if you type in the data manually, but not when I use the calendar button. What gives?
The problem lies in that the after update event does not fire if a control is updated via code. You would need to run that after update event (by changing it to Public) in the code that sets the value in the ajbcalendar control.
The version in the thread shown is quite old and I am in the process of updating it, however I have not finished my update to my satisfaction.
The main problem is it that the version I am directing you to will not work with an MDE database. I have solve this problem in my latest version but like I said I’m not quite ready to release it.
The other thing I didn’t like about it was you need an extra reference, (not a problem) the instructions for setting this up are in the thread.
Not if done correctly. And sometimes it is the only way around a problem. In this case it is kind of the problem because you can't have the afterupdate code do its job if it doesn't fire and the event won't fire if the value is updated through code. So, in general it is good to not fire events for controls from outside sources. But in practice, sometimes it is unavoidable.
However, if the code in the after update event were moved to a public function in a standard module then both could call it whenever needed.
So that is another way, and probably the best way, to do it.
Control values set by code do not fire the after update event because nothing actually fires it due to the way it is. That is just the way it goes and you have to account for it. However, what is the code on the After Update event? Perhaps we can convert it to a function in a standard module that both the control's after update event AND the calendar control can fire off.
Exactly, in other words there’s never any need to call a controls events directly.
I don’t have a clue as to why, except I understand it’s not good practice and there can be unforeseen consequences, what they are, what the logic and reasoning is behind this advice I do not know. I would like to know, if anyone knows.
I don’t have a clue as to why, except I understand it’s not good practice and there can be unforeseen consequences, what they are, what the logic and reasoning is behind this advice I do not know. I would like to know, if anyone knows.
Calling an event from another place can instantiate a hidden instance of that form or report if it is not already open. Then you can get errors when you go to open that form or report.
Calling an event from another place can instantiate a hidden instance of that form or report if it is not already open. Then you can get errors when you go to open that form or report.
You have two controls.
One a data control which can (could) accept a value entered directly.
Another control as a means of assigning a value to that data control.
The AfterUpdate event will fire only upon User Interface editing of that control.
Code assignments, as you've discovered, do not raise the event.
That's by design. It might not agree with your personal view of how this should have been implemented but being this way allows us to coerce the code to be called if we want, but also to silently alter values when we choose without worrying about the event firing.
There is no inherent problem in calling the Event Procedure to duplicate the code as if you had entered the value manually.
i.e. in your ajbcalendar event
Code:
Private Sub ajbcalendar_Click()
'Do whatever
Set EndDate = fGetDate
'Force that update code
Call EndDate_AfterUpdate
End Sub
That will cause no problem. Raise no phantom instance.
It's calling another subprocedure, which is surely even in the same module. (That's all Event Procedures are). You're not raising the event. You're calling a procedure.
Now there are those (and I would generally count myself among them) who prefer not to implement this in quite that way, it just feels a little less tidy for maintenance, having to remember if some other event procedure is also calling this one when you're making edits.
Whereas maintaining a separate procedure called from both event procedures maintains consistency and even allows for the two procedures to do more than just this other action.
For example
Code:
Private Sub ajbcalendar_Click()
'Do whatever
Set EndDate = fGetDate
'Force that update code
ShowControl
End Sub
Private Sub EndDate_AfterUpdate()
ShowControl
End Sub
Private Sub ShowControl()
If Not [COLOR=black]IsNull(Me.EndDate)[/COLOR] Then
Me.cboReason.Visible = False
Else
Me.cboReason.Visible = True
End If
End Sub
I'm not saying that's the implementation verbatim (not sure exactly what you're doing), but it's the idea.
