Properties for a custom class (not a collection)

[downwitch]

Hi,

I know this has been covered here and in the .public groups, but it
seems like it's been a while, especially around here, so I just thought
I'd ask again to see if anyone has figured out a new angle.

If I have a class MyClass--not a collection container but a
single-level class--that has a bunch of properties of different types,
I'd like to be able to reference them via the standard VBA syntax of

MyClass.Propert ies("MyProperty ")

or

MyClass.Item("M yProperty")

so that I could use variables instead of having to say

MyClass.MyPrope rty

to get and let.

Of course, I could create a whole collection myself to loop using the
Item/IEnumerator trick, but seems to me that kind of squashes the
usefulness of properties in the first place.

Thanks in advance.

[polite person]

On 21 Jul 2005 06:27:08 -0700, "downwitch" <do*******@gmai l.com> wrote:

Hi,

I know this has been covered here and in the .public groups, but it
seems like it's been a while, especially around here, so I just thought
I'd ask again to see if anyone has figured out a new angle.

If I have a class MyClass--not a collection container but a
single-level class--that has a bunch of properties of different types,
I'd like to be able to reference them via the standard VBA syntax of

MyClass.Proper ties("MyPropert y")

or

MyClass.Item(" MyProperty")

so that I could use variables instead of having to say

MyClass.MyProp erty

to get and let.

Of course, I could create a whole collection myself to loop using the
Item/IEnumerator trick, but seems to me that kind of squashes the
usefulness of properties in the first place.

Thanks in advance.

Hi
Is this problem special to custom classes?
I don't know how to do this for the Application object, for example.

If you were in VB you could examine the input file for the linker and see what code
is actually produced. You can also generate a map file if you paste
SetEnv "LINK", "/MAP"
into the immediate window.See
http://www.constantthought.com/yabbs...y;threadid=240
Debugging tip: Getting the name of the current and calling function at runtime

[lylefair]

I guess the thread shows this is a difficult problem.
Would you consider using an Access form (as a class) with textbox
controls for your "properties "
You could open the form with
Dim f as Form_FormName
Set f as New Form_FormName
The form's open and close event procedures would give you the
equivalent of the class's Initialize and Terminate Procedures.
You might have to set the form's visible property to false in it's open
event procedure.
You form visible, I think it does not matter.
You could access your Properties as
f.Controls("Nam e").Value
I THINK ... haven't got time to test this. I played with the notion
several years ago, as a Class with a visual show of what's going on ...
like a meter.
Of course, one would have to close the form or set the instance to
nothing when its work was done.

A post about this (1998) was

The form is tiny and has no recordsource and no controls, images or
whatever.
It does have a module. The module has four properties, viz. Application
(private), Copies, Document, and Status (which prints the document and
returns the status).
The first reference to the form is in code, something like
form_frmPrint.C opies = 5
whereupon the form open event creates an instance of Word.
Now the form slumbers, invisible.
I can let and get its public properties at will from anywhere. (The
properties are private actually, and I access them through Property Let
and
Set procedures.)
As far as I know, as long as I don't close the form, the word instance
remains on the alert ready to do the printing.
When the application closes, the form closes, running the close event
procedure that quits and releases the Word app.

Question: Is performance taking any significant hit by keeping this
form
open (but invisible), over and above what it might take keeping a
non-form
class instance open?

And for the Why? sayers ... the form is always in scope ... and the
closing
of it and therefore the quitting and release of Word are implicit in
the
closing of the database. In pertinent error routines, I'll close it as
well.

[rkc]

downwitch wrote:

Hi,

I know this has been covered here and in the .public groups, but it
seems like it's been a while, especially around here, so I just thought
I'd ask again to see if anyone has figured out a new angle.

If I have a class MyClass--not a collection container but a
single-level class--that has a bunch of properties of different types,
I'd like to be able to reference them via the standard VBA syntax of

MyClass.Propert ies("MyProperty ")

or

MyClass.Item("M yProperty")

so that I could use variables instead of having to say

MyClass.MyPrope rty

to get and let.

Of course, I could create a whole collection myself to loop using the
Item/IEnumerator trick, but seems to me that kind of squashes the
usefulness of properties in the first place.

I think the following is a basic approach to what you are after.

<clsPropertie s>
Option Compare Database
Option Explicit

Private m_properties As VBA.Collection

Public Property Get properties(key As String) As String
properties = m_properties.it em(key)
End Property

Public Property Let properties(key As String, value As String)
m_properties.Ad d value, key
End Property

Private Sub Class_Initializ e()
Set m_properties = New VBA.Collection
End Sub

Private Sub Class_Terminate ()
Set m_properties = Nothing
End Sub

</clsProperties>

<test>
Sub testPropertyCol lection()
Dim pc As clsPropetyColle ction
Set pc = New clsPropetyColle ction
pc.properties(" Horse") = "Mustang"
MsgBox pc.properties(" Horse")
Set pc = Nothing
End Sub
</test>

[downwitch]

rkc wrote:

I think the following is a basic approach to what you are after.

<clsPropertie s>

<snip>

Yes, this is the idea, but it's still more wheel reinvention than I'm
after (of course ;)). The trick to a catch-all properties collection
is that what DFW is talking about still poses a problem. Normally when
you set variables and hold properties in a class, you've got a cogent
"object" that organizes your code. The hierarchy can be quite rigid,
which I've always found very useful--I use a full class hierarchy that
emulates some table data when the structure is very complex, because it
makes code manipulations easy to make, and virtually self-documenting.

Using collection-type classes and flat "single-object" classes as in

classFoot parent of classToes parent of classToe

makes things very nice and pretty, and while I suppose you could set a
generic objParent in your clsProperties collection, and then add that
"collection " to any other single-object class, but at that point you
have to *always* use

classToe.Proper ties("NailPolis hColor") = "hot pink"

and you lose the self-documenting thing of storing strNailPolishCo lor
as a visible "member" of the class. Property Let/Set and Get are
strict, and that's very useful, I think, one of the things that makes
classes so powerful.

It'a shame that MS didn't take the (obvious, to me anyway) extra step
of exposing the set of properties one invents as a public collection,
since after all they *behave* like other similar exposed collections.
An instance of the above example that calls

MyFoot.Toes("Bi gToe")

is so easy to read and hard to miscode it's almost magical, and it's
not such a leap from there to see

MyFoot.Toes("Bi gToe")(strPrope rtyIWantRightNo w)

_with the same class setup_ as a logical step. I would think it has to
be the same logical engine, but I'm only speculating.

Using a hidden form could work, I suppose, but I suspect at that point
the whole thing would run much faster using temporary tables, at which
point you're out of VBA and fake OOP anyway, so it's more like
abandoning custom classes than making them work.

I'm still up for any ideas. Worth pointing out that the
default-item-of-collection method of exporting a collection, pasting
some standard text into it, and reimporting it--which I first learned
from the developer's handbook a few years back--is totally undocumented
and works like a charm. Might there be other workarounds out there for
those of you who know pure VB classes better than I?

[David W. Fenton]

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:q0******** ***********@twi ster.nyroc.rr.c om:

downwitch wrote:

Hi,

I know this has been covered here and in the .public groups, but
it seems like it's been a while, especially around here, so I
just thought I'd ask again to see if anyone has figured out a new
angle.

If I have a class MyClass--not a collection container but a
single-level class--that has a bunch of properties of different
types, I'd like to be able to reference them via the standard VBA
syntax of

MyClass.Propert ies("MyProperty ")

or

MyClass.Item("M yProperty")

so that I could use variables instead of having to say

MyClass.MyPrope rty

to get and let.

Of course, I could create a whole collection myself to loop using
the Item/IEnumerator trick, but seems to me that kind of squashes
the usefulness of properties in the first place.

I think the following is a basic approach to what you are after.

<clsProperties >
Option Compare Database
Option Explicit

Private m_properties As VBA.Collection

Public Property Get properties(key As String) As String
properties = m_properties.it em(key)
End Property

Public Property Let properties(key As String, value As String)
m_properties.Ad d value, key
End Property

Private Sub Class_Initializ e()
Set m_properties = New VBA.Collection
End Sub

Private Sub Class_Terminate ()
Set m_properties = Nothing
End Sub

</clsProperties>

<test>
Sub testPropertyCol lection()
Dim pc As clsPropetyColle ction
Set pc = New clsPropetyColle ction
pc.properties(" Horse") = "Mustang"
MsgBox pc.properties(" Horse")
Set pc = Nothing
End Sub
</test>

That still doesn't get you a collection that you can walk through to
pull out all the properties (or a specific subset of them).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:q0******** ***********@twi ster.nyroc.rr.c om:

downwitch wrote:

Hi,

I know this has been covered here and in the .public groups, but
it seems like it's been a while, especially around here, so I
just thought I'd ask again to see if anyone has figured out a new
angle.

If I have a class MyClass--not a collection container but a
single-level class--that has a bunch of properties of different
types, I'd like to be able to reference them via the standard VBA
syntax of

MyClass.Prop erties("MyPrope rty")

or

MyClass.Item ("MyProperty ")

so that I could use variables instead of having to say

MyClass.MyPr operty

to get and let.

Of course, I could create a whole collection myself to loop using
the Item/IEnumerator trick, but seems to me that kind of squashes
the usefulness of properties in the first place.

I think the following is a basic approach to what you are after.

<clsPropertie s>
Option Compare Database
Option Explicit

Private m_properties As VBA.Collection

Public Property Get properties(key As String) As String
properties = m_properties.it em(key)
End Property

Public Property Let properties(key As String, value As String)
m_properties.Ad d value, key
End Property

Private Sub Class_Initializ e()
Set m_properties = New VBA.Collection
End Sub

Private Sub Class_Terminate ()
Set m_properties = Nothing
End Sub

</clsProperties>

<test>
Sub testPropertyCol lection()
Dim pc As clsPropetyColle ction
Set pc = New clsPropetyColle ction
pc.properties(" Horse") = "Mustang"
MsgBox pc.properties(" Horse")
Set pc = Nothing
End Sub
</test>

That still doesn't get you a collection that you can walk through to
pull out all the properties (or a specific subset of them).

The collection is there. A method to add or retrieve a single property
from the collection is there. If you want to iterate the collection
of course there is more to it. You write an iterator class or provide
methods in each class (which would would be redundant) to iterate the
collection.

How do you get a specific subset of properties from a dao.field object?

[David W. Fenton]

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:HZ******** ***********@twi ster.nyroc.rr.c om:

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:q0******** ***********@twi ster.nyroc.rr.c om:

The collection is there. A method to add or retrieve a single
property from the collection is there. If you want to iterate the
collection of course there is more to it. You write an iterator
class or provide methods in each class (which would would be
redundant) to iterate the collection.

How do you get a specific subset of properties from a dao.field
object?

Well, you can filter by name.

The custom class module allows you to create different
collections/arrays for different purposes. In the query-by-form
criteria class that I have there's an array for the individual
criteria that is used in the private method that writes WHERE
clause, which is called by the public property that returns the SQL
string.

There are other properties that are *not* part of that array.

Had there been a pre-existing Properties collection for my class, I
would have had to use naming conventions to get a walkable structure
for assembling the WHERE clause, as with the DAO collections.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

downwitch wrote:

Yes, this is the idea, but it's still more wheel reinvention than I'm
after (of course ;)). The trick to a catch-all properties collection
is that what DFW is talking about still poses a problem. Normally when
you set variables and hold properties in a class, you've got a cogent
"object" that organizes your code. The hierarchy can be quite rigid,
which I've always found very useful--I use a full class hierarchy that
emulates some table data when the structure is very complex, because it
makes code manipulations easy to make, and virtually self-documenting.

Using collection-type classes and flat "single-object" classes as in

classFoot parent of classToes parent of classToe

makes things very nice and pretty, and while I suppose you could set a
generic objParent in your clsProperties collection, and then add that
"collection " to any other single-object class, but at that point you
have to *always* use

classToe.Proper ties("NailPolis hColor") = "hot pink"

and you lose the self-documenting thing of storing strNailPolishCo lor
as a visible "member" of the class. Property Let/Set and Get are
strict, and that's very useful, I think, one of the things that makes
classes so powerful.

This is probably more than you're interested in since you want
magic as opposed to effort. But then taking care of that mule
team is probably time consuming.

<clsProperty>
Option Compare Database
Option Explicit

Private m_Name As String
Private m_Value As String
Private m_parent As Object

Public Property Let Name(ByVal nm As String)
m_Name = nm
End Property

Public Property Get Name() As String
Name = m_Name
End Property

Public Property Get Value() As Variant
Value = m_Value
End Property

Public Property Let Value(ByVal vlu As Variant)
'uses VB6 CallByName function to call the property's
'parent's Property Let method
m_Value = vlu
CallByName m_parent, Me.Name, VbLet, Me.Value
End Property

Public Property Set parent(prnt As Object)
Set m_parent = prnt
End Property

Private Sub Class_Terminate ()
Set m_parent = Nothing
End Sub

</clsProperty>

<clsToe>
Option Compare Database
Option Explicit

Private m_nailPolishCol or As String
Private m_hasFungus As Boolean
Private m_properties As VBA.Collection

Public Property Get properties(key As String) As String
Dim prop As clsProperty

Set prop = m_properties.It em(key)
properties = prop.Value
Set prop = Nothing
End Property

Public Property Let properties(key As String, Value As String)
Dim prop As clsProperty
Set prop = New clsProperty
Set prop.parent = Me
prop.Name = key
prop.Value = Value
m_properties.Ad d prop, key
Set prop = Nothing
End Property

Public Property Let NailPolishColor (clr As String)
m_nailPolishCol or = clr
End Property

Public Property Get NailPolishColor () As String
NailPolishColor = m_nailPolishCol or
End Property

Public Property Get HasFungus() As Boolean
HasFungus = m_hasFungus
End Property

Public Property Let HasFungus(ByVal bln As Boolean)
m_hasFungus = bln
End Property

Private Sub Class_Initializ e()
Set m_properties = New VBA.Collection
End Sub

Private Sub Class_Terminate ()
Set m_properties = Nothing
End Sub
</clsToe>

<sub test>
Sub Test()
Dim toe As clsToe
Set toe = New clsToe
toe.properties( "NailPolishColo r") = "Orange"
toe.properties( "HasFungus" ) = True

'get property by name
MsgBox toe.properties( "NailpolishColo r")

'get property by method
MsgBox toe.NailPolishC olor & _
vbCrLf & _
"has fungus: " & toe.HasFungus

Set toe = Nothing

End Sub

</sub test>

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester. yabba.dabba.do. rr.bomb> wrote in
news:HZ******** ***********@twi ster.nyroc.rr.c om:

How do you get a specific subset of properties from a dao.field
object?

Well, you can filter by name.

The custom class module allows you to create different
collections/arrays for different purposes. In the query-by-form
criteria class that I have there's an array for the individual
criteria that is used in the private method that writes WHERE
clause, which is called by the public property that returns the SQL
string.

How are you doing on the demo of your query-by-form implementation?
You've been threatening to publish it. I'd like to see it.

[downwitch]

rkc wrote:

This is probably more than you're interested in since you want
magic as opposed to effort. But then taking care of that mule
team is probably time consuming.

<snip>

No, on the contrary, I find this pretty unspeakably awesome.

I'd venture to guess that this is the first time anywhere in the world
Access has tracked the lower phalanges, and I thank you for it.

So one last question--and I was really with you on this before you went
to all the trouble--how do you validate data? I think your clsProperty
needs a data type property... And so on. I see your point, but you
wind up reproducing, well, VBA in VBA. It's not the effort that's the
problem, it's the having-to-write-the-language-for-the-language that
gets me down.

I wish the MS Access development team was subjected to developing with
Access. They could probably work this through in an afternoon, and
then justify jacking up the price of MS Office Pro another fifty bucks
(and a team of mules).