Trying to figure out what Event fires for a textbox

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

MS Access 2k, Windows XP
====================
Hi all,

I have a form with an unbound textbox control (txtStartDate) to enter a date
(mm/dd/yyyy). The form has a calendar button to select the date from a pop-up
calendar (Lebans) and put it into the textbox.

I also construct a SQL statement using the value in txtStartDate and some
other controls on the form.

The problem I'm having is that the SQL statement I put in the AfterUpdate
event of txtStartDate is not firing, when I use the pop-up calendar to enter
the date. I also tried to put the code in OnChange event of the control, with
the same result. The SQL code is correct as it is working with other controls.

I think that since the control is being assigned a value using the pop-up
calendar, somehow, the OnChange and the AfterUpdate events are not firing.

Is there a way to correct this?

I'd rather not put the code in the pop-up calendar/button event.
I can also use a button ("Search") to construct the code, but it'll be best
if I can figure something out with one of the txtStartDate events.

Thanks for any help regarding this.

-Amit
 
The events only fire when the control's value is changed by user input, not
when it is changed programmatically. This behaviour is by design and can not
be changed.
 
Brendan Reynolds said:
The events only fire when the control's value is changed by user
input, not when it is changed programmatically. This behaviour is by
design and can not be changed.
Click to expand...

Presumably, if you're changing it programmatically, you know when you
are doing it and can explicitly execute whatever additional code may be
required. That could include calling the control's AfterUpdate event
procedure.
 
If I wanted code to run both when the value was changed programmatically and
when it was changed interactively, I would put the common code into a
separate procedure and call that procedure from both the AfterUpdate event
procedure and from the code that changed the value programmatically, rather
than calling the AfterUpdate procedure from the other code. But from my
reading of the original post, I think the original poster has already
identified the alternatives.
 
Brendan Reynolds said:
If I wanted code to run both when the value was changed
programmatically and when it was changed interactively, I would put
the common code into a separate procedure and call that procedure
from both the AfterUpdate event procedure and from the code that
changed the value programmatically, rather than calling the
AfterUpdate procedure from the other code.
Click to expand...

Out of curiosity, why? Why create a separate procedure? Just so you
can distinguish code that must be executed no matter how the value is
changed from code that must only be executed when the control is changed
via the UI? I've never had occasion to make that distinction.
 
In my view, a procedure named 'SomeTextBox_AfterUpdate' should run when the
AfterUpdate event of SomeTextBox is fired. It should not run when the
AfterUpdate event of SomeTextBox has *not* been fired. Imagine a developer
looking at that code years after it was written. When he/she sees a
procedure named 'SomeTextBox_AfterUpdate' how obvious is it going to be that
that procedure runs when the Click event of SomeButton is fired?
 
Hi Brendan, Dirk:

Thanks for your responses- I'm constantly learning new things about Access.

The reason I wanted to put the SQL code in txtStartDate event was to avoid
duplication (since the value can also be input/changed w/o using the pop-up
calendar), and my lack of knowledge that the AfterUpdate event does not fire
if the value is changed programmatically.

But, it seems like either I'll have to place a procedure (that sets the SQL
code) at 2 places (after the value is assigned using pop-up calendar, and
AfterUpdate of txtStartDate) or call the AfterUpdate event after setting the
value of text control.

However, I'm not sure of the correct syntax to call the AfterUpdate event of
the control from pop-up calendar/button. I tried placing
"txtStartDate_AfterUpdate()" in the line next to the where the value is
being assigned, but I'm getting a compile error....

Thanks.

-Amit
 
:

However, I'm not sure of the correct syntax to call the AfterUpdate event of
the control from pop-up calendar/button. I tried placing
"txtStartDate_AfterUpdate()" in the line next to the where the value is
being assigned, but I'm getting a compile error....
Click to expand...

Holy Spaces. I must be in a daze. Please ignore this. Figured it out.

-amit
 
Brendan Reynolds said:
In my view, a procedure named 'SomeTextBox_AfterUpdate' should run when the
AfterUpdate event of SomeTextBox is fired. It should not run when the
AfterUpdate event of SomeTextBox has *not* been fired. Imagine a developer
looking at that code years after it was written. When he/she sees a
procedure named 'SomeTextBox_AfterUpdate' how obvious is it going to be that
that procedure runs when the Click event of SomeButton is fired?
Click to expand...

<snip>

But, in a way, the value of the control is being updated, even if through
code. Though, maybe the AfterUpdate event should strictly be called when the
value is being updated by user input.

Right now, the only code in the AfterUpdate event is assigning the SQL
statement. But, it is possible that there may be more code added (or a
different scenario) where that part of the AfterUpdate code needs to be
executed in the stricter sense. Then, calling AfterUpdate from the pop-up
calendar would cause problems.

-amit
 
Brendan Reynolds said:
In my view, a procedure named 'SomeTextBox_AfterUpdate' should run
when the AfterUpdate event of SomeTextBox is fired. It should not run
when the AfterUpdate event of SomeTextBox has *not* been fired.
Imagine a developer looking at that code years after it was written.
When he/she sees a procedure named 'SomeTextBox_AfterUpdate' how
obvious is it going to be that that procedure runs when the Click
event of SomeButton is fired?
Click to expand...

I guess it depends on your point of view. In my view, a procedure named
'SomeTextBox_AfterUpdate' is intended to specify what happens when the
value of the text box is updated, regardless of whether that update is
made via the user interface or by code.
 
That would work from code behind the same form as the text box. From outside
of the form, you'll need to change the declaration of
txtStartDate_AfterUpdate from Private to Public and call it like so ...

Forms("YourFormName").txtStartDate_AfterUpdate

.... which, now that you mention it, is another good reason for using a
public procedure in a standard module and calling it from both places! :-)
 
Back
Top