Object Instanciation - Parameters? Redefines? Protos? Watchers?

[Snaux]

Multi-part Question, all short and related to VBA OOP and particularly
Object Instanciation.

1) In most OOP languages, when you instanciate an object you can pass
parameters to it: fido = New Dog(#Brown, #Cute). From what I've seen,
VBA doesn't seem to allow this (it throws an end of line error), so you
have to create a new object, then explicitly change whatever settings
were preset by your object_initialize proc. So, am I missing some
alternate command or trick to do this? I really prefer the concept of
single-line object instanciation, as it tends to limit errors by
third-party programmers, who I'm writing for.

2) In some languages, you can add a new property to an existing object
at runtime, even though the object itself doesn't necessarily know what
that property is for: fido.addProp(#BadBreath, True). Is there a way to
do this? as a workaround, I've been simply adding an "AdditionalData"
collection to all my objects, but it's a little lame to add the
overhead unless I really need it.

3) Similarly, a few OOP langs (C, Java, Flash come to mind) allow you
to redefine the native objects/methods/functions through prototyping or
direct tweaking of the object's code. VB/VBA Possible?

4) Finally, is there a way to put an external watcher on an object
property, something that executes code when the property of an object
changes, without the object itself knowing about it? This would be like
the debugger's watch function, except that instead of breaking the code
when the condition is met, it executes code. I've made some half-ass
progress using a system timer which checks for value changes
periodically, but it's cumbersome and very after-the-fact: Set
needsbath= watchdog(fido, hasfleas=true, milliseconds:=100). I'd
prefer: fido.addwatch(#fleas, #needsbath), which would simply run the
code "Needsbath" whenever the status of fido's fleas property changes
(or better yet, is ABOUT to change). Fido doesn't need to know he needs
a bath, fido's owner does.

5) CurrentDB? Got it. CurrentForm? No prob. CurrentProc? Anyone? I'd
love to be able to get the name of the currently-executing procedure,
and it's caller, into a string or addressof.

BONUS POINTS: Any good books on VB/VBA OOP?

 

[Bob Hairgrove]

Multi-part Question, all short and related to VBA OOP and particularly
Object Instanciation.

1) In most OOP languages, when you instanciate an object you can pass
parameters to it: fido = New Dog(#Brown, #Cute). From what I've seen,
VBA doesn't seem to allow this (it throws an end of line error), so you
have to create a new object, then explicitly change whatever settings
were preset by your object_initialize proc. So, am I missing some
alternate command or trick to do this? I really prefer the concept of
single-line object instanciation, as it tends to limit errors by
third-party programmers, who I'm writing for.

VBA is neither C++ nor Java. You will need to wrap your object
instantiation code in functions to which you can pass initialization
parameters. The other way to do this is to use other classes as
containers for initialization parameters, initialize those first as
global variables, and then create the objects which can access the
parameter object variables in the class "Initialize" procedure.

You could also do this using tables, but that gets a little
complicated when multiple users are involved.

2) In some languages, you can add a new property to an existing object
at runtime, even though the object itself doesn't necessarily know what
that property is for: fido.addProp(#BadBreath, True). Is there a way to
do this? as a workaround, I've been simply adding an "AdditionalData"
collection to all my objects, but it's a little lame to add the
overhead unless I really need it.

There is the "Properties" collection for the Database object...maybe
you could take advantage of that?

Actually, one of the aims of having objects in OOP is so that you can
encapsulate the data owned by the object and hide the details of how
that data is used from the clients. Clients of the objects shouldn't
be allowed to mess with its properties, IMHO. It sounds like you are
trying to invent a workaround for the absence of inheritance and
polymorphism in VBA...?

3) Similarly, a few OOP langs (C, Java, Flash come to mind) allow you
to redefine the native objects/methods/functions through prototyping or
direct tweaking of the object's code. VB/VBA Possible?

C is not an OOP ... C++ is (they aren't the same). I don't do Flash,
and I don't do Java either. I do C++. But some people say that C++
isn't an OOP either...

VBA implements encapsulation by implementation, not by inheritance.
IOW, you can mimic base classes by making them members of your class.
However, VBA makes little or no use of the concept of an interface.

There is no way to inherit an interface except by duplicating some
public functions or properties throughout the different classes which
make up the class hierarchy you are trying to build. It is a lot of
trouble to maintain afterwards because you will be duplicating a lot
of code. The question is, whether or not it is worth it?

4) Finally, is there a way to put an external watcher on an object
property, something that executes code when the property of an object
changes, without the object itself knowing about it?
No.

This would be like
the debugger's watch function, except that instead of breaking the code
when the condition is met, it executes code. I've made some half-ass
progress using a system timer which checks for value changes
periodically, but it's cumbersome and very after-the-fact: Set
needsbath= watchdog(fido, hasfleas=true, milliseconds:=100). I'd
prefer: fido.addwatch(#fleas, #needsbath), which would simply run the
code "Needsbath" whenever the status of fido's fleas property changes
(or better yet, is ABOUT to change). Fido doesn't need to know he needs
a bath, fido's owner does.

In a true OOP language, you can implement ownership ... but not in
VBA.

5) CurrentDB? Got it. CurrentForm? No prob. CurrentProc? Anyone? I'd
love to be able to get the name of the currently-executing procedure,
and it's caller, into a string or addressof.

Nothing built-in. (

But if you use a good editor, such as UltraEdit or UltraEdit-Studio,
to write your VBA code (or at least stubs for the code ... the Access
built-in editor does a better job at IntelliSense), you can create
macros which set up string variables containing the procedure or
function name which can be passed to error-handling routines, for
example.

BONUS POINTS: Any good books on VB/VBA OOP?

VB/VBA and OOP are mutually exclusive, IMHO. Any attempt at mimicking
it will give you much more trouble than it is worth. Better to write a
lot of stand-alone functions and invest the time and energy into
documenting their appropriate use.

If you really need OOP for your application, do it in Java or C++ and
use MS-Access as a back-end (or as a prototype for a real database
such as Oracle which has built-in Java). You can always use ODBC or
JDBC for accessing the data.

 

[Douglas J. Steele]

But if you use a good editor, such as UltraEdit or UltraEdit-Studio,
to write your VBA code (or at least stubs for the code ... the Access
built-in editor does a better job at IntelliSense), you can create
macros which set up string variables containing the procedure or
function name which can be passed to error-handling routines, for
example.

Take a look at MZTools http://www.mztools.com/index.htm

 

[Snaux]

It sounds like you are
trying to invent a workaround for the absence of inheritance and
polymorphism in VBA...?

OMG, I feel naked!

Yes, that's exactly what I'm trying to do, among other things. I'm
working on what I *thought* was a relatively simple ProgressBar class
that would be smart enough to spawn off children automatically during
lengthy tasks (hence the questions relating to watchers and identifying
the currently-executing code).

It's easy enough to do in C++ or Flash ActionScript, but I've found the
best way to learn a language is to give yourself a difficult task and
then figure out a way to do it.

From your response, it sounds like this is *kinda* possible, but

probably not worth the hoop-jumping to pull it off. At least I have a
clearer picture of VBA's limitations... thanks for taking the time to
provide solid answers!