[AccessD] Re: [Private] Framework Discussion - Dependent Objects

Ken,

>Yes, you will get early binding and Intellisense, if you use interfaces.
No, you won't get all of the class properties of the underlying object VIA
THE
INTERFACE.

I was afraid of that.  I assume that "all of the advantages of early
binding" means speed.  Intellisense only deals with parent properties and
(in my specific case) my individual "sub classes" if you will have MANY more
methods that I can't Intellisense.

I have a specific set of Framework Class Interface variables and methods and
yes, it would be nice to have that predefined and just "inherited" (or
implemented) but in the end that is like implementing 1/4th of my head when
I need my whole body.

Again, I can see other places where it might very well be a major portion of
the whole and very useful.

Would you work with me offline to define this framework interface class and
show me how to Implement that in all of my framework classes?  When it comes
to defining interfaces I will take all the help I can get.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ken Ismert
Sent: Tuesday, March 16, 2004 1:06 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Re: [Private] Framework Discussion - Dependent
Objects



My miscellaneous observations:

(Colby, Fri 3/12/2004)
>I am open to interfaces, assuming that you can present a case for a
>significant advantage ... Am I getting early binding out of this so
>that Intellisense works?  If so can I "get at" all of the class
>properties, i.e. not just those implemented?

Yes, you will get early binding and Intellisense, if you use interfaces. No,
you won't get all of the class properties of the underlying object VIA THE
INTERFACE. But you can still get at them. Drawing on Drew's example:

    Dim rFWC As FrameWorkControl
    Dim rCbo As Access.ComboBox

    Set rFWC = New FWComboBox
    Set rFWC.LinkedObject = cboMyCombo
    ' do FrameWorkControl things ...
    If rFWC.ObjectType = "ComboBox" Then
        Set rCbo = rFWC.LinkedObject
        ' do Combo things ...
        Set rCbo = Nothing
    End If

The point is you can use the generic methods of the interface and the
specific combobox methods, and still preserve early binding.

(Brock, Tue 3/16/2004)
> ... Also, and seriously, I find my forms so diverse and often highly
>specialized as I can't see a framework fit in and certainly not worth
>spending the time to build it ...

This is one of the big challenges of frameworks: no matter how suited it is
for you, it often won't fit the unique requirements of others. You can never
build a framework that is big enough for everybody.

However, frameworks can have a payoff in standardization and consistency,
provided that the cost to build and implement them are kept to a reasonable
level.

Which brings us back to the case for interfaces. They are the best way (in
VB6) to provide:

 * Standardization - An interface allows you to define a common set of
behaviors for a group of objects.
 * Extensibility - Interfaces allow you to extend your framework in a
consistent, controlled way. This has two benefits: First, helps keep your
initial investment lower. Define your interface, build only what you need,
and move on. Second, it allows others to more easily extend the framework to
fit their own unique requirements.

When Microsoft wanted to allow VB programmers a standard way to extend
Office, they provided the Office Add-In framework, which implemented the
IDTExtensibility2 interface. This is the COM way of allowing extensibility.

-Ken

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com