Best way to make a custom control "reusable?"

[Max Moor]

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?

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

 

[Baz]

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.

 

[Klatuu]

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.

 

[Baz]

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

 

[Klatuu]

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

 

[Keith Wilby]

Microsoft do it all the time,

Microsoft do many things wrong.

Keith.

 

[Klatuu]

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.

 

[Baz]

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]

String was also a datatype when I last looked. QED.

And don't be so damned patronising.

 

[Klatuu]

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!

--
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
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

 

[Max Moor]

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]

Not your fault. Good luck.

Thanks, Baz. This is just what I was hoping for. (Sorry about the ensuing
battle.)

- Max

 

[Keith Wilby]

Microsoft do many things wrong.

Keith.

Whoops, could I just qualify that with a ;-) ?