Many Event procedures pointing to same code

**Steve Jorgensen** · Nov 12 '05, 02:16 PM

Re: Many Event procedures pointing to same code

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, wolfesimon@comc ast.net (Dee) wrote:
[color=blue]
>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[/color]

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn't have the time.

**Steve Jorgensen** · Nov 12 '05, 02:16 PM

Re: Many Event procedures pointing to same code

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 "txtControl X".

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(Cance l As Integer)
Dim ctl As Access.Control
For Each ctl In Me.Controls
If ctl.Name Like "txtControl X*" Then
ctl.AfterUpdate = "=AfterUpdateCo ntrolX(""" & ctl.Name & """)"
End If
Next
End Sub

Public Function AfterUpdateCont rolX(strControl Name As String) As Long
Debug.Print strControlName
End Function

On 10 Sep 2003 23:08:52 -0700, wolfesimon@comc ast.net (Dee) wrote:
[color=blue]
>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[/color]

- Steve Jorgensen

----
I would have written you a shorter program,
but I didn't have the time.

**Allen Browne** · Nov 12 '05, 02:16 PM

Re: Many Event procedures pointing to same code

Call MyOtherControl_ AfterUpdate

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

"Dee" <wolfesimon@com cast.net> wrote in message
news:35171ab2.0 309102208.25133 b80@posting.goo gle.com...[color=blue]
> 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[/color]

**Steve Jorgensen** · Nov 12 '05, 02:16 PM

Re: Many Event procedures pointing to same code

On Thu, 11 Sep 2003 07:49:27 GMT, "Allen Browne"
<abrowne1_SpamT rap@bigpond.net .au> wrote:
[color=blue]
>Call MyOtherControl_ AfterUpdate[/color]

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.

**Terry Kreft** · Nov 12 '05, 02:16 PM

Re: Many Event procedures pointing to same code

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 CalculateResult s()
' Put your code in here
End Sub

Then in each of your event handlers you put
Call CalculateResult s

Terry

"Dee" <wolfesimon@com cast.net> wrote in message
news:35171ab2.0 309102208.25133 b80@posting.goo gle.com...[color=blue]
> 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[/color]

**David W. Fenton** · Nov 12 '05, 02:19 PM

Re: Many Event procedures pointing to same code

nospam@nospam.n ospam (Steve Jorgensen) wrote in
<pf50mv4jeeo2kn v22rlkm1chc5plu 0je1j@4ax.com>:
[color=blue]
>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.[/color]

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.ActiveCo ntrol 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

**Steve Jorgensen** · Nov 12 '05, 02:20 PM

Re: Many Event procedures pointing to same code

On Thu, 11 Sep 2003 18:29:03 GMT, dXXXfenton@bway .net (David W. Fenton)
wrote:
[color=blue]
>nospam@nospam. nospam (Steve Jorgensen) wrote in
><pf50mv4jeeo2k nv22rlkm1chc5pl u0je1j@4ax.com> :
>[color=green]
>>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.[/color]
>
>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.ActiveCo ntrol because I don't trust
>its reliability across Access versions, so I pass the control to[/color]

I second that!

Many Event procedures pointing to same code

Many Event procedures pointing to same code

Comment

Comment

Comment

Comment

Comment

Comment

Comment