By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,220 Members | 1,516 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,220 IT Pros & Developers. It's quick & easy.

Many Event procedures pointing to same code

P: n/a
Dee
I have 11 numeric fields on a form which are all inter related.

When any field changes after update, all need recalculation.

Each field has an after update event procedure. Each of which runs the
same code in different Private Subs.

Is there a way to point each private sub to just one subroutine, or do
I need all of this duplicate code?

Thanks Dee
Nov 12 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
The easy way is to make a public function in the form, then put
=<functionname>() in the After Update property of each control. Yes, it
has to be a "Function" even though it will not be used to return a value.
The down side of this approach is that the code calling the function is now
hidden in a form property where it's easy to forget about and fail to
maintain if, for instance, you add a 12th control to the list.

A while back, we had a thread on how to set up some additional event
handling classes to handle this situation in a more type safe manner, but
what we came up with was a bit too cumbersome to be worth implementing.
You're pretty much left choosing to either implement 11 event handlers, or
put the function call in the even property. I usually opt for the 11
handlers, but if it gets up past about 15, then I go with the calls. Note
that you can document the calls by making a note in a comment at the top of
the form module and/or by adding an invisible label somewhere on the form.

On 10 Sep 2003 23:08:52 -0700, wo********@comcast.net (Dee) wrote:
I have 11 numeric fields on a form which are all inter related.

When any field changes after update, all need recalculation.

Each field has an after update event procedure. Each of which runs the
same code in different Private Subs.

Is there a way to point each private sub to just one subroutine, or do
I need all of this duplicate code?

Thanks Dee

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn't have the time.
Nov 12 '05 #2

P: n/a
Actually, I just thought of a cool trick for this. It keeps everything in
the code at design time, and it only depends on a naming convention to
figure out which controls to apply to.

In the following example, we assume that the controls that will invoke the
event handler are all named beginning with "txtControlX".

Note that this technique or just manually setting the event properties to
function calls has an additional limitation I didn't mention before. These
functions can't receive event parameters such as the x, y position of a
mouse click, etc., but that doesn't matter in this case.

---------
Option Compare Database
Option Explicit

Private Sub Form_Open(Cancel As Integer)
Dim ctl As Access.Control
For Each ctl In Me.Controls
If ctl.Name Like "txtControlX*" Then
ctl.AfterUpdate = "=AfterUpdateControlX(""" & ctl.Name & """)"
End If
Next
End Sub

Public Function AfterUpdateControlX(strControlName As String) As Long
Debug.Print strControlName
End Function
On 10 Sep 2003 23:08:52 -0700, wo********@comcast.net (Dee) wrote:
I have 11 numeric fields on a form which are all inter related.

When any field changes after update, all need recalculation.

Each field has an after update event procedure. Each of which runs the
same code in different Private Subs.

Is there a way to point each private sub to just one subroutine, or do
I need all of this duplicate code?

Thanks Dee

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn't have the time.
Nov 12 '05 #3

P: n/a
Call MyOtherControl_AfterUpdate

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html

"Dee" <wo********@comcast.net> wrote in message
news:35**************************@posting.google.c om...
I have 11 numeric fields on a form which are all inter related.

When any field changes after update, all need recalculation.

Each field has an after update event procedure. Each of which runs the
same code in different Private Subs.

Is there a way to point each private sub to just one subroutine, or do
I need all of this duplicate code?

Thanks Dee

Nov 12 '05 #4

P: n/a
On Thu, 11 Sep 2003 07:49:27 GMT, "Allen Browne"
<ab***************@bigpond.net.au> wrote:
Call MyOtherControl_AfterUpdate


Sorry, I forgot that wasn't obvious. You may still end up with 11
handlers, but as Allen says, they should all, in turn, call one function if
they all do the same thing.

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn't have the time.
Nov 12 '05 #5

P: n/a

In the form module create a sub, put the code for your calculation there and
then call it from your event handlers.

e.g.

Private Sub CalculateResults()
' Put your code in here
End Sub

Then in each of your event handlers you put
Call CalculateResults

Terry
"Dee" <wo********@comcast.net> wrote in message
news:35**************************@posting.google.c om...
I have 11 numeric fields on a form which are all inter related.

When any field changes after update, all need recalculation.

Each field has an after update event procedure. Each of which runs the
same code in different Private Subs.

Is there a way to point each private sub to just one subroutine, or do
I need all of this duplicate code?

Thanks Dee

Nov 12 '05 #6

P: n/a
no****@nospam.nospam (Steve Jorgensen) wrote in
<pf********************************@4ax.com>:
A while back, we had a thread on how to set up some additional
event handling classes to handle this situation in a more type
safe manner, but what we came up with was a bit too cumbersome to
be worth implementing. You're pretty much left choosing to either
implement 11 event handlers, or put the function call in the even
property. I usually opt for the 11 handlers, but if it gets up
past about 15, then I go with the calls. Note that you can
document the calls by making a note in a comment at the top of the
form module and/or by adding an invisible label somewhere on the
form.


I actually make the determination based on how specific the
function call is to the controls. That is, if there is special
handling in any cases I'll be more likely to use an Event Handler
than a function property.

I'm also opposed to use Screen.ActiveControl because I don't trust
its reliability across Access versions, so I pass the control to
the function. This means more work, as each function property is
specific to its own control (having a unique argument), but I just
feel more secure knowing that I'm operating on the control I intend
to operate on.

Of course, if you are operating on a group of controls and don't
care which one initiates it, that's not an issue.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #7

P: n/a
On Thu, 11 Sep 2003 18:29:03 GMT, dX********@bway.net (David W. Fenton)
wrote:
no****@nospam.nospam (Steve Jorgensen) wrote in
<pf********************************@4ax.com>:
A while back, we had a thread on how to set up some additional
event handling classes to handle this situation in a more type
safe manner, but what we came up with was a bit too cumbersome to
be worth implementing. You're pretty much left choosing to either
implement 11 event handlers, or put the function call in the even
property. I usually opt for the 11 handlers, but if it gets up
past about 15, then I go with the calls. Note that you can
document the calls by making a note in a comment at the top of the
form module and/or by adding an invisible label somewhere on the
form.


I actually make the determination based on how specific the
function call is to the controls. That is, if there is special
handling in any cases I'll be more likely to use an Event Handler
than a function property.

I'm also opposed to use Screen.ActiveControl because I don't trust
its reliability across Access versions, so I pass the control to


I second that!

Nov 12 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.