Using "Event Sinks" might be what you want. Here's an example:
Create a class module as follows, and save it as clsTest (note that it MUST
be a class module, not an ordinary module):
'Code begins for clsTest
Option Compare Database
Option Explicit
Private WithEvents mfrm As Form
Private WithEvents mcmd1 As CommandButton
Private WithEvents mcmd2 As CommandButton
Property Set Form(ByRef Form As Form)
Set mfrm = Form
Set mcmd1 = mfrm!cmd1
Set mcmd2 = mfrm!cmd2
End Property
Private Sub mcmd1_Click()
MsgBox "Command 1 clicked in Form " & mfrm.Name
End Sub
Private Sub mcmd2_Click()
MsgBox "Command 2 clicked in Form " & mfrm.Name
End Sub
'Code ends for clsTest
Then create a form named "Form1", give it two command buttons "cmd1" and
"cmd2" and the following code:
'Code begins for Form1
Option Compare Database
Option Explicit
Dim mobjTest1 As clsTest
Private Sub Form_Open(Cancel As Integer)
Set mobjTest1 = New clsTest
Set mobjTest1.Form = Me
End Sub
'Code ends for Form1
Copy Form1 and name the copy Form2. Launch each form, click the command
buttons, and see what happens. You should be able to see that you now have
generic code for the two forms and their command buttons which can be
applied to any form with just three lines of code.
> Hi All,
> I want to use Stephen Lebans' custom scroll bar control to scroll a
> FlexGrid control. Within my application, I'll have a few different forms
> using his control this way.
>
> Desiring to reduce repeated code, I know I can create a module with
all
> the functional code in it, then call those functions from the events
> generated in each form on which the control is used.
>
> Is there a better way to encapsulate the code for the custom scroll
bar
> (really a set of four command buttons), then include it more cleanly into the
> forms where the custom control is used?
[quoted text clipped - 6 lines]
> Thanks,
> Max
Klatuu - 30 May 2007 15:43 GMT
Baz,
I tested your code and it works well, once you complete it.
On first testing, the problem was that there was no response to the Click
event of either button.
I found it was necessary to create an empty Click event for each button on
the form.

Signature
Dave Hargis, Microsoft Access MVP
> Using "Event Sinks" might be what you want. Here's an example:
>
[quoted text clipped - 72 lines]
> > Thanks,
> > Max
Baz - 30 May 2007 16:48 GMT
Thanks, but I know it works. I've got a library of generic class modules
which sink events and give me all kinds of standard form and control
behaviours throughout my applications.
You don't need any empty procedures. All you need is the On Click property
set to "[Event Procedure]". If you don't want to do that in the property
sheet, you can do it in the code thus:
Property Set Form(ByRef Form As Form)
Set mfrm = Form
Set mcmd1 = mfrm!cmd1
Set mcmd2 = mfrm!cmd2
mcmd1.OnClick = "[Event Procedure]"
mcmd2.OnClick = "[Event Procedure]"
End Property
> Baz,
>
[quoted text clipped - 81 lines]
> > > Thanks,
> > > Max
Klatuu - 30 May 2007 16:57 GMT
No need to arrogant.
We are saying the same thing. That is exactly what I did.
I am not trying to beat up on you, I just want the OP to have all the
information. You did not include that in your original response and we can't
be sure the OP could figure that out on his own.
Think about it. An [Event Procedure] with no code in it would be what?
AN EMPTY PROCEDURE!

Signature
Dave Hargis, Microsoft Access MVP
> Thanks, but I know it works. I've got a library of generic class modules
> which sink events and give me all kinds of standard form and control
[quoted text clipped - 108 lines]
> > > > Thanks,
> > > > Max
Baz - 30 May 2007 17:11 GMT
You call ME arrogant, after the condescending way you've replied to me
elsewhere on this thread? You've got a nerve.
An empty procedure is a Sub statement followed by an End Sub statement with
no statements in between. Setting the "On Click" property to "[Event
Procedure]" doesn't create or demand any procedure at all.
> No need to arrogant.
> We are saying the same thing. That is exactly what I did.
[quoted text clipped - 117 lines]
> > > > > Thanks,
> > > > > Max
Max Moor - 30 May 2007 19:07 GMT
"Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in news:465d3ee9$0$19258
$da0feed9@news.zen.co.uk:
> Using "Event Sinks" might be what you want. Here's an example:
Thanks, Baz. This is just what I was hoping for. (Sorry about the ensuing
battle.)
- Max
Baz - 31 May 2007 06:16 GMT
Not your fault. Good luck.
> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in news:465d3ee9$0$19258
> $da0feed9@news.zen.co.uk:
[quoted text clipped - 5 lines]
>
> - Max
Baz's example is vert good --- with one exception.
It is a poor practice to use Access reserved words as names. It can confuse
Access and create unpredictable results.
Change the name Form to something else.

Signature
Dave Hargis, Microsoft Access MVP
> Hi All,
> I want to use Stephen Lebans' custom scroll bar control to scroll a
[quoted text clipped - 16 lines]
> Thanks,
> Max
Baz - 30 May 2007 14:02 GMT
In the very limited situation of property procedure names or argument names
for general functions there is no chance of "confusing" Access, and it makes
it crystal clear to would-be callers what the property or argument is for.
Microsoft do it all the time, there are lots of function arguments with
reserved words for names e.g. "String".
> Baz's example is vert good --- with one exception.
> It is a poor practice to use Access reserved words as names. It can confuse
[quoted text clipped - 8 lines]
> >
> > Desiring to reduce repeated code, I know I can create a module with
all
> > the functional code in it, then call those functions from the events
> > generated in each form on which the control is used.
> >
> > Is there a better way to encapsulate the code for the custom scroll
bar
> > (really a set of four command buttons), then include it more cleanly into the
> > forms where the custom control is used?
> >
> > Ultimately, out of my desire to be a better Access programmer, I
want
> > to know if there is a "best practice" I should be using here, that would
> > minimize code redundancy and make the interface to the custome control most
> > efficient.
> >
> > Thanks,
> > Max
Klatuu - 30 May 2007 14:39 GMT
String is a function.
You are absolutely incorrect about no chance of confusing Access by using
reserved names. I have seen it happen.
Microsoft uses some of the worst naming there is. That doesn't make it right.
Using good naming conventions ensures there will be no issues with reserved
words and it makes it clear to the reader exactly what the name represents.
I suggest you do some studying on naming conventions. Here is a link to
some that may be useful to you.
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccess/html
/msdn_20naming.asp

Signature
Dave Hargis, Microsoft Access MVP
> In the very limited situation of property procedure names or argument names
> for general functions there is no chance of "confusing" Access, and it makes
[quoted text clipped - 35 lines]
> > > Thanks,
> > > Max
Baz - 30 May 2007 16:54 GMT
String was also a datatype when I last looked. QED.
And don't be so damned patronising.
> String is a function.
> You are absolutely incorrect about no chance of confusing Access by using
[quoted text clipped - 4 lines]
> I suggest you do some studying on naming conventions. Here is a link to
> some that may be useful to you.
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccess/html
/msdn_20naming.asp
> > In the very limited situation of property procedure names or argument names
> > for general functions there is no chance of "confusing" Access, and it makes
[quoted text clipped - 35 lines]
> > > > Thanks,
> > > > Max
Keith Wilby - 30 May 2007 14:56 GMT
> Microsoft do it all the time,
Microsoft do many things wrong.
Keith.
Keith Wilby - 31 May 2007 16:16 GMT
>> Microsoft do it all the time,
>
> Microsoft do many things wrong.
>
> Keith.
Whoops, could I just qualify that with a ;-) ?