After Update doesnt work with Calendar control?

Zorkmid

Registered User.
Local time
Yesterday, 19:28
Joined
Mar 3, 2009
Messages
188
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?

-Z
 
here's my code:

Code:
Private Sub EndDate_AfterUpdate()
   If Not Null Then
          Me.cboReason.Visible = False
    Else
          Me.cboReason.Visible = True
    End If
End Sub

Hmmmm the control doesnt seem to go back to invisible if the field is blanked either. Im stumped...
 
First of all - this is incorrect

If Not Null Then


It should be:
Code:
   If Not [B][COLOR="Red"]IsNull(Me.EndDate)[/COLOR][/B] Then
          Me.cboReason.Visible = False
    Else
          Me.cboReason.Visible = True
    End If

And you can shorten that up to be simply a single line of code:

Me.cboReason.Visible = (Not IsNull(Me.EndDate))
 
It now works when I manually type in the date, and clears when I clear the control, but I still get nothing when I use the ajbcalendar control

-z
 
It now works when I manually type in the date, and clears when I clear the control, but I still get nothing when I use the ajbcalendar control

-z

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.
 
I have had this problem and I don’t believe there is a simple cure, I may be wrong!


I did come up with a solution which you can find here:

Powerful and easy to use Calendar Form

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.
 
It’s not considered good practice to run a controls events from outside of the control. You can sometimes get unforeseen consequences.
 
Why the heck should it matter by what method the data was entered?

Shouldn't it read the field after its updated? Like the event says?

Can I use another event? On dirty or something?

-Z

I guess I'll just label it so that users dont fill it out.....stupid ms access
 
It’s not considered good practice to run a controls events from outside of the control. You can sometimes get unforeseen consequences.
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.
 
Why the heck should it matter by what method the data was entered?

Shouldn't it read the field after its updated? Like the event says?

Can I use another event? On dirty or something?

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.
 
The code was

Private Sub EndDate_AfterUpdate()
Me.cboReason.Visible = (Not IsNull(Me.EndDate))
End Sub


But I've just set cboReason to stay visible all the time and ask users to leave it blank unless they are clsoing a case.

If you want to see the actual DB I'll be attaching it in my next thread around dbl clicking list boxes.

-Z
 
the code in the after update event were moved to a public function

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.

Thanks Bob!
 
The code was

Private Sub EndDate_AfterUpdate()
Me.cboReason.Visible = (Not IsNull(Me.EndDate))
End Sub


But I've just set cboReason to stay visible all the time and ask users to leave it blank unless they are clsoing a case.

If you want to see the actual DB I'll be attaching it in my next thread around dbl clicking list boxes.

-Z

Did you try Bob's other solution?

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.
 
I actually haven't yet, but I really dont understand what bob means when he says that, so I doubt I could figure it out :)

-Z
 
I'm afraid I'm really not seeing the problem.

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.

Cheers.
 

Users who are viewing this thread

Back
Top Bottom