I have a class where I would like to store
UDTs in collections, but since the class
is private I can't do that. This is a class
to organize data and make it easily searchable.
What I've come up with as the simplest
approach to what I need is a collection that holds
collections. The main collection might hold up to
100 sub-collections. Each sub-collection might
have as many as 30 items, with each item being a
boolean value. I could do this as arrays. It's
just a bit more tedious to code.

   Any thoughts on that in terms of efficiency?
I worry about bogging down with too many
collections. And while I'm on it, I wonder
exactly what a collection is. According to
O'Reilly's VB book a collection is fairly slow.
I'm not really worried about that, but I do wonder
about memory usage. Would a collection be an
object pointer to an array of double 4-byte
values, with each pair being a string pointer
key with long value or pointer item? If that's
the case then a Collection would seem to be
fairly efficient and lean.

On 20/11/2009 02:32, mayayana wrote:
>    I have a class where I would like to store
> UDTs in collections, but since the class
> is private I can't do that. This is a class
> to organize data and make it easily searchable.
> What I've come up with as the simplest
> approach to what I need is a collection that holds
> collections. The main collection might hold up to
> 100 sub-collections. Each sub-collection might
> have as many as 30 items, with each item being a
> boolean value. I could do this as arrays. It's
> just a bit more tedious to code.

Errrr, why??
Why not use a class instead?
This is the closest to a type that is supported by collections and is 
much more useable (and type safe)

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

"mayayana" <mayaXXyana@rcXXn.com> wrote in message
news:%235$fEmYaKHA.196@TK2MSFTNGP05.phx.gbl...
>   I have a class where I would like to store
> UDTs in collections, but since the class
> is private I can't do that. This is a class
> to organize data and make it easily searchable.
> What I've come up with as the simplest
> approach to what I need is a collection that holds
> collections. The main collection might hold up to
> 100 sub-collections. Each sub-collection might
> have as many as 30 items, with each item being a
> boolean value. I could do this as arrays. It's
> just a bit more tedious to code.
>
>    Any thoughts on that in terms of efficiency?
> I worry about bogging down with too many
> collections. And while I'm on it, I wonder
> exactly what a collection is. According to
> O'Reilly's VB book a collection is fairly slow.
> I'm not really worried about that, but I do wonder
> about memory usage. Would a collection be an
> object pointer to an array of double 4-byte
> values, with each pair being a string pointer
> key with long value or pointer item? If that's
> the case then a Collection would seem to be
> fairly efficient and lean.
>

"Collections" are nothing more than a group of data arranged so you can use
the same model or operations to work with all the elements. This includes
everything from a simple array to a relational database. (Yep, all SQL
Server is is a super 'collection'.
Back in the day of "real" programming these groups and methods for handling
them were called "Data Structures" and programmers spent most of their time
learning and cataloging them.

Take a look at:
http://en.wikibooks.org/wiki/Data_Structures

There are only something this side of a zillion options - take your pick.
But first you might want to narrow down your selection. So forget "How" (ie,
UDTs, classes, arrays, VB Colection, ...) for a bit, take a yellow pad and
start drawing "What" it is you want to do. Until you define how you intend
to add, modify, search, iterate, ... blah, blah, your data - no one can
provide a valid answer.

The result will eventually be expressed using various methods (Hows) but do
go there yet.

In the meantime consider the following:
The VB Collection Object is slooooww compared to other options. The VB
Collection was supplied as a convenience, it is not highly optimized built
as it is as a general purpose tool. (It also serves as two very different
Data Structures but that is another story. If memory or performance becomes
a concern you will likely be looking for a custom solution.

For the amount of data you are talking about - a simple ready to run out of
the box database product would seem the best route. You could also use a
custom written one.

-ralph

"mayayana" <mayaXXyana@rcXXn.com> wrote
> The main collection might hold up to
> 100 sub-collections. Each sub-collection might
> have as many as 30 items, with each item being a
> boolean value. I could do this as arrays. It's
> just a bit more tedious to code.
>
>    Any thoughts on that in terms of efficiency?

The UDT is helpful to store data efficiently, while
the collection is a glorified array of Variants.  If you
move to collections, you would see efficiency go out
the window....

I noticed that your data is all in the form of boolean
variables.  If that is the case you could use 1 bit to
denote True or False, in a value large enough to store
up to 30 items. (30 bits).  One array of Longs would
be able to hold all your data (while also being easy
to read and write to disk).

Similar to what Ralph said, I advise people to store
their data in a form that makes it easy for the program
to use.  What good is efficiency if you have to triple
the code needed, every time you want to access it?

So like Ralph said, decide what you need to do with
the data, and then look for storage methods that will
make those things easy to do....

For an example of using 1 bit to store booleans, consider
the code below.  Class1 contains all the code necessary
(less error handling) to manage the array of data.  I'd say
it isn't tedious at all.

To get at the data you simply supply an Index and
the named value you want (the names being those you
used in the UDT, I used A1, A2, B1, B2, etc...)

Plus Intellisense helps you out along the way....

HTH
LFS


' Form code - - - - - - - - -
Private Sub Form_Load()
  Dim D As Class1
  Set D = New Class1

  D.Item(1, A1) = True
  Debug.Print D.Item(0, A2)
  Debug.Print D.Item(1, A1)
End Sub


' Class1 code  - - - - - - - -
Public Enum Flag
  A1 = 1
  A2 = 2
  B1 = 4
  B2 = 8
  C1 = 16
  C2 = 32
  ' ... etc
End Enum

Private Data(0 To 100) As Long

Public Property Get Item(ByVal Index As Long, ByVal Name As Flag) As Boolean
  Item = CBool(Data(Index) And Name)
End Property

Public Property Let Item(ByVal Index As Long, ByVal Name As Flag, ByVal Value As Boolean)
  If Value Then
    Data(Index) = Data(Index) Or Name
  Else
    Data(Index) = Data(Index) And (Not Name)
  End If
End Property

  Thanks all. I am actually trying a class now.
That seemed bulky, but it is convenient. And
I once read that a class adds 90 bytes. (Or is
it 96?). That seems fairly inconsequential if
the number of classes is < 1000 or so.

  I basically need to store groups of strings,
with each having an associated boolean value.
Like so:

Fruit:  apple - true
          orange - false

Grain: bread - false
          rice - true
          corn - false
etc.

  I want to easily return a group list (bread, rice, corn),
check the boolean value for a given string value
(rice = true), etc. If I put that into a class I only
need two simple arrays in the class for storage. I
can then add the classes to a collection in an
over-class, which allows me to call the over-class
with clear methods like GetBool("Grain", "rice").


  There seems to be wide agreement that VB
Collections are not so hot. I didn't realize that
they were actually storing variants. Usually I
use arrays wherever possible because I figure that
they're the most efficient. And inside a class they
can be hidden. But it can get convoluted when there
are arrays in arrays, etc., even if the resulting class
interface is intuitive and usable. So I was interested
in others' ideas.

"mayayana" <mayaXXyana@rcXXn.com> schrieb im Newsbeitrag
news:uYEpnXfaKHA.1596@TK2MSFTNGP06.phx.gbl...
>   Thanks all. I am actually trying a class now.
> That seemed bulky, but it is convenient. And
> I once read that a class adds 90 bytes. (Or is
> it 96?). That seems fairly inconsequential if
> the number of classes is < 1000 or so.
>
>   I basically need to store groups of strings,
> with each having an associated boolean value.
> Like so:
>
> Fruit:  apple - true
>           orange - false
>
> Grain: bread - false
>           rice - true
>           corn - false
> etc.

What is it, what you really want to achieve?
If for example in "one given fruit-group-instance" there's
only one "value = true" and all the others are false (to
identify a fruit) ... did you already thought about
using Enums instead? If you use Powers of 2 for
your Enum-Values, then you could even combine
different "bool-properties" - effectively simulating
Larrys suggestion of a Bitset, stored in a Long-Value
(Enums are 32Bit-types).

But given your other requirements...

> ... which allows me to call the over-class
> with clear methods like GetBool("Grain", "rice").

....especially when you possibly plan, to persist the
data somewhere, then a DB comes to mind, using
SQL for all kind of queries (in a very flexible and
comfortable way).

The question (as always) is, what tradeoff you are
willing to accept - a DB-solution would require
some Dlls in your deployment (about 1MB or so)
and it would raise the MemConsumption of your
App in a range of 2MB to 3MB (due to the loaded
DB-engine), + additional Memory, depending on how
many Recordsets you want to keep open, or how
large your "total Data-Set" is (or will grow), in case
you want to hold your Data in an InMemory-DB.
But the benefits are less lines of code in your App
(mostly due to the already powerful data-container-
classes - the Recordsets - which you will not have
to implement yourself) ... + the better and easier
extensibility of the "Data-Model" and the larger
flexibility regarding the queries (just change some
text in a given SQL-string, to adapt to further
query- and filter- or sorting-requirements).

Larrys suggestions regarding BitFields for the boolean
values + using Types and Arrays etc. is good advise,
if your total data-set is huge (then BitFields would
worth the effort, with regards to mem-consumption) -
and/or if performance matters (typed Arrays instead
of Classes stored in Collections). But as I read it
from your description, neither one is the case - your
total Data-Set is more or less a smaller one - and also
performance seems not to be critical - so in that case
you should (or could) use an approach that is flexible
and easier to develop/enhance (with less LOC).
A VB-Classic-App (a small Exe) has some Base-Mem-
Overhead of typically 3-4MB - given that, you should
not waste "hours of coding", just to safe some 100kByte (or
let's make that 1MB), if the alternative solution is more
"generic", more dynamically adjustable to further requirements
and "just finished earlier".



Olaf

"mayayana" <mayaXXyana@rcXXn.com> wrote in message 
news:uYEpnXfaKHA.1596@TK2MSFTNGP06.phx.gbl...
>  I basically need to store groups of strings,
> with each having an associated boolean value.
> Like so:
>
> Fruit:  apple - true
>          orange - false
>
> Grain: bread - false
>          rice - true
>          corn - false
> etc.

I would use Enum for the entries unless they are user-modifiable. 
Collections are slow when you add items to them, but they are fast when you 
retrieve items by Key. That's because the Collection object uses a hash 
table of the keys you enter(the keys themselves are not stored, but "item" 
parameter is), and then uses a fast search algorithm to search the hash and 
return the "item".

http://en.wikipedia.org/wiki/Hash_table

To see how much memory they use, add one million entries, then see your app 
memory usage, and divide by the number of entries.

Also, when adding items, you could use just use one collection and use the 
format "Category:Item" when specifying the key. Example:

col.Add CByte(1), "Fruit:apple"
col.Add CByte(0), "Fruit:orange"
col.Add CByte(0), "Grain:bread"
col.Add CByte(1), "Grain:rice"
col.Add CByte(0), "Grain:corn"

You could make that into an AddItem routine to simplify things:

Public Sub AddItem(ByVal bItem As Boolean, ByRef sKey As String)
    col.Add CByte(bItem), sKey
End Sub

How to get True/False value:

bResult = CBoolean(col("Grain:corn"))

"mayayana" <mayaXXyana@rcXXn.com> wrote
>
>   I basically need to store groups of strings,
> with each having an associated boolean value.
> Like so:
>
> Fruit:  apple - true
>           orange - false
>
> Grain: bread - false
>           rice - true
>           corn - false
> etc.
>
>   I want to easily return a group list (bread, rice, corn),
> check the boolean value for a given string value
> (rice = true), etc. If I put that into a class I only
> need two simple arrays in the class for storage.

Do you really need two arrays?  Keeping associated
data in different structures has to be managed carefully
to keep them 'in sync'.  Consider:

APPLE orange
bread RICE corn

There you have two lists, including a means to differentiate
between the items:

' return a list
Value = LCase$(list)

' return a value
Value = (item = UCase$(item))

Just some 'food for thought'...   ;-)

LFS

> Do you really need two arrays?  Keeping associated
> data in different structures has to be managed carefully
> to keep them 'in sync'.

  Yes, but I figured on adding to both at the same
time. And I can't use the case ID because the names
need to keep their case. I also wanted to avoid
string operations. (Nobody had suggested an interesting
way to add all data to a single collection item by
concatenating two strings, but that means a lot of
string building behind the scenes.)


   But now I have another idea. I originally
wanted to use an array of UDTs. That would make
it easy, orderly, and clear to pass data around.
The problem with that, of course, is that I can't
use a UDT as a parameter if it's declared in a
private class or a .bas module. But there's something
I hadn't thought of:
  It works to declare the UDT in a public-not-creatable
class. (This is a DLL so that's an option.)  It seems
bizarre that I can't use a globally declared UDT in a
private class, but can if it's declared in a public class
that never gets instantiated. But it works. Ideally I'd
like to mark that class hidden for typelib readers,
but VB doesn't seem to provide that option. I guess
the best I can do is to just name it something
"unpleasant", like "C__" and provide no method to
access an instance.

"mayayana" <mayaXXyana@rcXXn.com> wrote in message 
news:eb0F2uiaKHA.4312@TK2MSFTNGP04.phx.gbl...
> The problem with that, of course, is that I can't
> use a UDT as a parameter if it's declared in a
> private class

Yes you can. Use "Friend" instead of "Public". See this post for details:

http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/13476df93b1d077a

"mayayana" <mayaXXyana@rcXXn.com> wrote
>    But now I have another idea. I originally
> wanted to use an array of UDTs. That would make
> it easy, orderly, and clear to pass data around.

I am curious as to how the data you posted will fit
into a array of UDTs.

eg:
Fruit:  apple - true
          orange - false

Grain: bread - false
          rice - true
          corn - false
etc.


???
LFS

   I know about Friend but it doesn't seem to
apply to UDTs. If I declare Friend Type
I get an error "only valid for functions, subs or
properties". I can declare it public, but it won't
work in a private class. The class has to be
public. Using a type2 class works fine, but it
would be nice to make it hidden, and I doubt
that I can locate the flag... in the typelib... in
the compiled DLL... to perform such an edit.


> > The problem with that, of course, is that I can't
> > use a UDT as a parameter if it's declared in a
> > private class
>
> Yes you can. Use "Friend" instead of "Public". See this post for details:
>
>
http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/13
476df93b1d077a
>
>
>

"mayayana" <mayaXXyana@rcXXn.com> wrote in message
news:eb0F2uiaKHA.4312@TK2MSFTNGP04.phx.gbl...
> > Do you really need two arrays?  Keeping associated
> > data in different structures has to be managed carefully
> > to keep them 'in sync'.
>
>   Yes, but I figured on adding to both at the same
> time. And I can't use the case ID because the names
> need to keep their case. I also wanted to avoid
> string operations. (Nobody had suggested an interesting
> way to add all data to a single collection item by
> concatenating two strings, but that means a lot of
> string building behind the scenes.)
>
>
>    But now I have another idea. I originally
> wanted to use an array of UDTs. That would make
> it easy, orderly, and clear to pass data around.
> The problem with that, of course, is that I can't
> use a UDT as a parameter if it's declared in a
> private class or a .bas module. But there's something
> I hadn't thought of:
>   It works to declare the UDT in a public-not-creatable
> class. (This is a DLL so that's an option.)  It seems
> bizarre that I can't use a globally declared UDT in a
> private class, but can if it's declared in a public class
> that never gets instantiated. But it works. Ideally I'd
> like to mark that class hidden for typelib readers,
> but VB doesn't seem to provide that option. I guess
> the best I can do is to just name it something
> "unpleasant", like "C__" and provide no method to
> access an instance.
>

Declare the UDT as a Struct in a TypeLibrary

-ralph

mayayana escribi�:
>    I know about Friend but it doesn't seem to
> apply to UDTs. If I declare Friend Type
> I get an error "only valid for functions, subs or
> properties". I can declare it public, but it won't
> work in a private class. The class has to be
> public. Using a type2 class works fine, but it
> would be nice to make it hidden, and I doubt
> that I can locate the flag... in the typelib... in
> the compiled DLL... to perform such an edit.
> 
> 
>>> The problem with that, of course, is that I can't
>>> use a UDT as a parameter if it's declared in a
>>> private class
>> Yes you can. Use "Friend" instead of "Public". See this post for details:
>>
>>
> http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/13
> 476df93b1d077a

You could copy the UDT with CopyMemory, then you need to pass just a 
Long value that you get with VarPtr:

http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/2e3d1905aa6eafd0

>
> I am curious as to how the data you posted will fit
> into a array of UDTs.
>

  It doesn't quite fit like that.

   I just wanted UDTs for the string-boolean pair.
(And as it turns out a third member will be handy
in that UDT.)

   What I've got at this point is a class with 4 arrays:

ArrayofGroupNames
ArrayOfGroupItemUDTArrays
ArrayToHoldNumberofItemsPerGroup

A 4th array holds ubound of the item arrays

I keep track of the number of groups, and the
Group index in the group name array is also the
corresponding index into the array of UDT arrays
to hold item data.

   Each time I add a group I check for the need
to redim. Then instead of GroupExists I'm using
GroupIndex. GroupExists loops through the group
names array and returns the index or -1.  -1 means
it doesn't exist. To add an item I check the GroupIndex
property, then add the item (UDT) to the corresponding
index position of the UDT array storage array.

  By adjusting counters whenever a group or item
is added, I always know the number of groups and
the number of items in each group.

  It's ugly and abstruse inside the class. That's why
I was looking into other ways to approach it. But I
think it must be quite efficient since it's just arrays,
and it can be intuitively designed in terms of the
interface methods.



> eg:
> Fruit:  apple - true
>           orange - false
>
> Grain: bread - false
>           rice - true
>           corn - false
> etc.
>
>
> ???
> LFS
>
>

> Declare the UDT as a Struct in a TypeLibrary
>

  That's something I hadn't thought of. The method
of adding it to a class works OK, but I guess a typelib
would be the only option if I wanted to do the same
thing in a standard EXE. I can't create a public class
there.

"mayayana" <mayaXXyana@rcXXn.com> wrote in message
news:OGsEpYlaKHA.4688@TK2MSFTNGP06.phx.gbl...
>
> > Declare the UDT as a Struct in a TypeLibrary
> >
>
>   That's something I hadn't thought of. The method
> of adding it to a class works OK, but I guess a typelib
> would be the only option if I wanted to do the same
> thing in a standard EXE. I can't create a public class
> there.
>

Actually all you are doing by creating a public class is creating a Type
published in a Type Library so it is "universally" available in a VB
project.

This method was used in the early days as a quick VB ODL "generator". The
technique was to create a VB public class of something you wanted to put in
an ODL within an DLL project. Compile it, then open OLE View (or other tool)
and select the resulting Type Library, then copy and paste it into your ODL.

This is still an interesting technique to use while writing a IDL as it
provides a quick visual comparison. But really isn't necessary once you get
used to writing IDL.

-ralph

> This is still an interesting technique to use while writing a IDL as it
> provides a quick visual comparison. But really isn't necessary once you
get
> used to writing IDL.

 Thanks for that tip. I started looking into
that and ended up rediscovering Matthew
Curland's TLB editor, which is a simple
front-end for writing and editing typelibs.

  I defined my UDT, created a TLB, and added
the reference. That worked fine. But
then I couldn't create an array of UDT arrays
because I can't cast them as Variants and
there's no way to declare something like:

   Private Array1 as NewUDT()

So I declared another UDT in the typelib
with one member, which is an array of my
UDTs. Thus:

  Type UDTArray
    UDTa() as UDT
  End Type

Private Array1 as UDTArray

  So now I can fill a UDT, add it to a UDTArray,
and add that to my array of UDTArrays:

  Array1(i).UDTa = UDTArray1

 This opens up a whole new, bizarre zoo
of possibilities. :)

"mayayana" <mayaXXyana@rcXXn.com> wrote in message
news:%23$vUOW7aKHA.5156@TK2MSFTNGP05.phx.gbl...
>
> > This is still an interesting technique to use while writing a IDL as it
> > provides a quick visual comparison. But really isn't necessary once you
> get
> > used to writing IDL.
>
>  Thanks for that tip. I started looking into
> that and ended up rediscovering Matthew
> Curland's TLB editor, which is a simple
> front-end for writing and editing typelibs.
>

I don't remember which version of ODL/IDL or make typelib utility Curland is
using. Loaned my book out. But I think it uses the slightly older ODL
version. Before you go much farther you need to have a version of the MIDL
compiler 5.x or greater.
[Do you have VS 6 (with VC++ 6)? Or have you downloaded a Platform SDK
greater than '99?
Then maybe Curland's is up todate. ????]

The reason is because you want to write type libraries using IDL (Interface
Definition Language), not ODL (Object Definition Language). Although ODL
will work for most VB automation types, ODL was MS's first entry into
providing type libraries for automation for VB. They later migrated to using
a single language - IDL (Interface Definition Language) as for the rest of
COM. Hate to bore you with details, but there are many syntax changes
changes between the two languages, and most online and book references show
IDL not ODL.  It is can get confusing enough without having to translate IDL
to ODL. So learn IDL and skip ODL.

>   I defined my UDT, created a TLB, and added
> the reference. That worked fine. But
> then I couldn't create an array of UDT arrays
> because I can't cast them as Variants and
> there's no way to declare something like:
>
>    Private Array1 as NewUDT()
>

That looks odd as it is VB code, not ODL/IDL, so I'm guessing you were using
the Curland utility. Must be some kind limitation of the tool because you
can declare an array of UDTs in a type library like this.
Assuming you already declared myUDT

         SAFEARRAY( myUDT ) Array1;

Also you can declare Variants as well. Must be some kind of limitation of
the tool you are using that you couldn't declare/define arrays of variants.

> So I declared another UDT in the typelib
> with one member, which is an array of my
> UDTs. Thus:
>
>   Type UDTArray
>     UDTa() as UDT
>   End Type
>
> Private Array1 as UDTArray
>

The above would be: (Assuming you already declared myUDT.)
[Air Code!]
     typedef
     [   uuid{ ...guid_string.... },
         version(1.0),
         helpstring("An struct holding an array of my UDTs")
     ]
     struct UDTArray {
            [helpstring("and array of UDTs")]
            SAFEARRAY(myUDT) Array1;
     } UDTArray;

And so on.

But if you are happy with what you are doing, that's fine. No reason to
change. Creating a Dll to provide a type library, while awkward compared to
providing a type library, doesn't have much impact on the final product.

-ralph

> So learn IDL and skip ODL.

   I'll keep that in mind. I wasn't aware of the
difference. But Curland's tool is a GUI editor.
I can just define a "record", define the members,
and save it as a .tlb file. No muss, no fuss. :)

  I had started by copying from OLE View, as you
had explained. But I knew I'd then have to figure
out the compiling, and when I tried Curland's
editor I realized there was no need to get into
writing it from scratch. (I've avoided learning IDL
up to now because it's such an awkward mess of
of semi-colons, parentheses, curly braces, brackets,
etc.)

> >    Private Array1 as NewUDT()
> >
>
> That looks odd as it is VB code, not ODL/IDL, so I'm
> guessing you were using
> the Curland utility.

  I was just using sample VB code to demonstrate
what I meant.

> Must be some kind limitation of the tool because you
> can declare an array of UDTs in a type library like this.
> Assuming you already declared myUDT
>
>          SAFEARRAY( myUDT ) Array1;


  I did declare that. I don't see any way to
do it outside of a UDT/record without creating
a class. Am I correct in that? In other words,
it doesn't seem to be possible to just define
a basic variable type because it's not a "typekind".
You seem to be doing the same with your code,
defining an array of type myUDT by declaring
it as a record member:

> struct UDTArray {
>             [helpstring("and array of UDTs")]
>             SAFEARRAY(myUDT) Array1;
>      } UDTArray;

--------------------------------------
My version is like so:
--------------------------------------

    typedef struct tagTCol {

long LPosition;

VARIANT_BOOL IfNumeric;

BSTR sName;
    } TCol;

    typedef struct tagTColArray {

SAFEARRAY(TCol) TColA;
    } TColArray;
};

"mayayana" <mayaXXyana@rcXXn.com> wrote in message
news:u7Uv$m%23aKHA.1652@TK2MSFTNGP05.phx.gbl...
>
>
>   I did declare that. I don't see any way to
> do it outside of a UDT/record without creating
> a class. Am I correct in that? In other words,
> it doesn't seem to be possible to just define
> a basic variable type because it's not a "typekind".
> You seem to be doing the same with your code,
> defining an array of type myUDT by declaring
> it as a record member:
>

They look identical because I was just mimicking the structure of what you
had already presented.

Like I said before, if what you are doing provides the results and the
sematics you want then there is no reason to venture into alternatives.

Most OLE automation data types are identical to VB data types because both
VB and OLE grew-up with each other, and is one of the reasons so much of the
ugly-side of COM is transparent to the VB user.

-ralph