tlbinf32.dll

[Colin McGuigan]

I've got a question about the tlbinf32.dll. I've got a piece of code that
takes in an object, and outputs all members of an enum used by a specific
method of that object.

This code works fine if the object is in a compiled DLL, so I'm relatively
sure the code is good.

However, if I put the code into the DLL itself, and try to run it in VB's
IDE, it doesn't work. Specifically, when I try to call
TLI.TLIApplication.ClassInfoFromObject() on an object that's defined within
the same DLL, it pops back an ActiveX error 430: "Class does not support
Automation or does not support expected interface".

Compiled, again, it works fine.

I'd rather not have to give up the ability to debug the DLL in VB's IDE.
So...does anyone know why it's doing this, and how I can get it to work in
debug mode (or, alternatively, another way to read the names of the enum
members)?

--
Colin McGuigan

[Matthew Curland]

You can't assume that you runtime type information for all objects in your
project. In fact, you only have full typeinfo support for Public objects,
not for private objects or items in the VB runtime (forms, intrinsic
controls, etc). This is discussed in the tlbinf32.chm help file where
ClassInfoFromObject and InterfaceInfoFromObject are described. Of course,
this data is actually static for internal objects (its hard to change them
at runtime), so you might want to consider an alternate approach where you
dump the data at DT and use it later at RT. The guids won't be the same, but
the names, memberids, enum values, etc will stay consistent. Just add a
conditionally compile 'DumpTypes' procedure in a module and call it from the
debug window. It should be that hard to do. The nicest thing here would be
to actually gen a typelib for this DT data, but that is a fair amount of
work. -Matt

"Colin McGuigan" <cmcguigan@imany.com> wrote in message
news:3b670f63$1@news.devx.com...
> I've got a question about the tlbinf32.dll. I've got a piece of code that
> takes in an object, and outputs all members of an enum used by a specific
> method of that object.
>
> This code works fine if the object is in a compiled DLL, so I'm relatively
> sure the code is good.
>
> However, if I put the code into the DLL itself, and try to run it in VB's
> IDE, it doesn't work. Specifically, when I try to call
> TLI.TLIApplication.ClassInfoFromObject() on an object that's defined
within
> the same DLL, it pops back an ActiveX error 430: "Class does not support
> Automation or does not support expected interface".
>
> Compiled, again, it works fine.
>
> I'd rather not have to give up the ability to debug the DLL in VB's IDE.
> So...does anyone know why it's doing this, and how I can get it to work in
> debug mode (or, alternatively, another way to read the names of the enum
> members)?
>
> --
> Colin McGuigan
>
>

[Matthew Curland]

You can't assume that you runtime type information for all objects in your
project. In fact, you only have full typeinfo support for Public objects,
not for private objects or items in the VB runtime (forms, intrinsic
controls, etc). This is discussed in the tlbinf32.chm help file where
ClassInfoFromObject and InterfaceInfoFromObject are described. Of course,
this data is actually static for internal objects (its hard to change them
at runtime), so you might want to consider an alternate approach where you
dump the data at DT and use it later at RT. The guids won't be the same, but
the names, memberids, enum values, etc will stay consistent. Just add a
conditionally compile 'DumpTypes' procedure in a module and call it from the
debug window. It should be that hard to do. The nicest thing here would be
to actually gen a typelib for this DT data, but that is a fair amount of
work. -Matt

"Colin McGuigan" <cmcguigan@imany.com> wrote in message
news:3b670f63$1@news.devx.com...
> I've got a question about the tlbinf32.dll. I've got a piece of code that
> takes in an object, and outputs all members of an enum used by a specific
> method of that object.
>
> This code works fine if the object is in a compiled DLL, so I'm relatively
> sure the code is good.
>
> However, if I put the code into the DLL itself, and try to run it in VB's
> IDE, it doesn't work. Specifically, when I try to call
> TLI.TLIApplication.ClassInfoFromObject() on an object that's defined
within
> the same DLL, it pops back an ActiveX error 430: "Class does not support
> Automation or does not support expected interface".
>
> Compiled, again, it works fine.
>
> I'd rather not have to give up the ability to debug the DLL in VB's IDE.
> So...does anyone know why it's doing this, and how I can get it to work in
> debug mode (or, alternatively, another way to read the names of the enum
> members)?
>
> --
> Colin McGuigan
>
>

[Colin McGuigan]

"Matthew Curland" <mattcur@microsoft.com> wrote in message
news:3b672821$1@news.devx.com...
> You can't assume that you runtime type information for all objects in your
> project. In fact, you only have full typeinfo support for Public objects,
> not for private objects or items in the VB runtime (forms, intrinsic
> controls, etc). This is discussed in the tlbinf32.chm help file where
> ClassInfoFromObject and InterfaceInfoFromObject are described.

I'm aware. But they're all public, creatable objects (if they weren't, it
wouldn't work when compiled, etc).

> Of course,
> this data is actually static for internal objects (its hard to change them
> at runtime), so you might want to consider an alternate approach where you
> dump the data at DT and use it later at RT. The guids won't be the same,
but
> the names, memberids, enum values, etc will stay consistent. Just add a
> conditionally compile 'DumpTypes' procedure in a module and call it from
the
> debug window. It should be that hard to do. The nicest thing here would be
> to actually gen a typelib for this DT data, but that is a fair amount of
> work.

My problem is that it works _fine_ at run-time. If I compile the code,
works great. It doesn't work at design time: ClassInfoFromObject barfs when
I feed it an object from a DLL that VB has open in it's IDE (but, again, it
works fine if I compile it and run it normally).

I found another twist: the various name lookups don't seem to work, either,
eg:

Debug.Print clsTypeLib.GetTypeInfo("COrder").Name

You would expect this to print out 'COrder' (a valid object that does exist
in the typelib's TypeInfos collection), but it doesn't; it prints out a
totally unrelated object (CAmountMatrix, in this case). Similar problem
with GetTypeInfoNumber, TypeInfos.NamedItem, etc. If I loop through the
items manually and do my own string comparison, that works, and, as before,
if I compile the code and run it outside the IDE, then it works...but when
working on objects that are open in the IDE, tlbinf32 is having all sorts of
problems.

I've found a way around it: instead of using ClassInfoFromObject, which
errors, I can use InterfaceInfoFromObject, get the Parent of the interface
to get a TypeLib reference, then iterate through the CoClasses collection of
the TypeLib manually until I find the one I want. It's annoying, but it
does work in debug mode.

--Colin McGuigan

[Colin McGuigan]

"Matthew Curland" <mattcur@microsoft.com> wrote in message
news:3b672821$1@news.devx.com...
> You can't assume that you runtime type information for all objects in your
> project. In fact, you only have full typeinfo support for Public objects,
> not for private objects or items in the VB runtime (forms, intrinsic
> controls, etc). This is discussed in the tlbinf32.chm help file where
> ClassInfoFromObject and InterfaceInfoFromObject are described.

I'm aware. But they're all public, creatable objects (if they weren't, it
wouldn't work when compiled, etc).

> Of course,
> this data is actually static for internal objects (its hard to change them
> at runtime), so you might want to consider an alternate approach where you
> dump the data at DT and use it later at RT. The guids won't be the same,
but
> the names, memberids, enum values, etc will stay consistent. Just add a
> conditionally compile 'DumpTypes' procedure in a module and call it from
the
> debug window. It should be that hard to do. The nicest thing here would be
> to actually gen a typelib for this DT data, but that is a fair amount of
> work.

My problem is that it works _fine_ at run-time. If I compile the code,
works great. It doesn't work at design time: ClassInfoFromObject barfs when
I feed it an object from a DLL that VB has open in it's IDE (but, again, it
works fine if I compile it and run it normally).

I found another twist: the various name lookups don't seem to work, either,
eg:

Debug.Print clsTypeLib.GetTypeInfo("COrder").Name

You would expect this to print out 'COrder' (a valid object that does exist
in the typelib's TypeInfos collection), but it doesn't; it prints out a
totally unrelated object (CAmountMatrix, in this case). Similar problem
with GetTypeInfoNumber, TypeInfos.NamedItem, etc. If I loop through the
items manually and do my own string comparison, that works, and, as before,
if I compile the code and run it outside the IDE, then it works...but when
working on objects that are open in the IDE, tlbinf32 is having all sorts of
problems.

I've found a way around it: instead of using ClassInfoFromObject, which
errors, I can use InterfaceInfoFromObject, get the Parent of the interface
to get a TypeLib reference, then iterate through the CoClasses collection of
the TypeLib manually until I find the one I want. It's annoying, but it
does work in debug mode.

--Colin McGuigan

[Matthew Curland]

Gotcha, I'm reading more carefully this time Sorry to make you reclarify.

I tried some of this and, yes, it is pretty messed up. When running in the
IDE, VB uses ITypeInfo and ITypeLib implementations that are in-memory, not
based on a standard on-disk typelib (the temp file only provides a moniker
so that LoadTypeLib works). These are no where near as robust as the
compiled versions, as you're seeing. There were some early problems in VB4
(such as GetTypeInfo(0).TypeInfoNumber returning 1, not 0) that are still
hacked around in TLI, but there are obviously more involved problems here.
As you said, simply iterating TypeInfos until you find the name you want
seems to give you a reasonable object, as does a lookup by TypeInfoNumber
(using TypeInfos.IndexedItem), but the name lookup is clearly toast.

You may have noticed that some IntelliSense bits also fail to work against
in memory typelibs. For example, you don't get a list after the library name
or an enum member in a referenced project in the same project group. These
limitations also have to do with different levels of typelib API support by
the in-memory varieties. Essentially, they did just enough to make the
compiler work, but not much more. -Matt

>
> > You can't assume that you runtime type information for all objects in
your
> > project. In fact, you only have full typeinfo support for Public
objects,
> > not for private objects or items in the VB runtime (forms, intrinsic
> > controls, etc). This is discussed in the tlbinf32.chm help file where
> > ClassInfoFromObject and InterfaceInfoFromObject are described.
>
> I'm aware. But they're all public, creatable objects (if they weren't, it
> wouldn't work when compiled, etc).
>
> My problem is that it works _fine_ at run-time. If I compile the code,
> works great. It doesn't work at design time: ClassInfoFromObject barfs
when
> I feed it an object from a DLL that VB has open in it's IDE (but, again,
it
> works fine if I compile it and run it normally).
>
> I found another twist: the various name lookups don't seem to work,
either,
> eg:
>
> Debug.Print clsTypeLib.GetTypeInfo("COrder").Name
>
> You would expect this to print out 'COrder' (a valid object that does
exist
> in the typelib's TypeInfos collection), but it doesn't; it prints out a
> totally unrelated object (CAmountMatrix, in this case). Similar problem
> with GetTypeInfoNumber, TypeInfos.NamedItem, etc. If I loop through the
> items manually and do my own string comparison, that works, and, as
before,
> if I compile the code and run it outside the IDE, then it works...but when
> working on objects that are open in the IDE, tlbinf32 is having all sorts
of
> problems.
>
> I've found a way around it: instead of using ClassInfoFromObject, which
> errors, I can use InterfaceInfoFromObject, get the Parent of the interface
> to get a TypeLib reference, then iterate through the CoClasses collection
of
> the TypeLib manually until I find the one I want. It's annoying, but it
> does work in debug mode.
>
> --Colin McGuigan
>
>

[Matthew Curland]

Gotcha, I'm reading more carefully this time Sorry to make you reclarify.

I tried some of this and, yes, it is pretty messed up. When running in the
IDE, VB uses ITypeInfo and ITypeLib implementations that are in-memory, not
based on a standard on-disk typelib (the temp file only provides a moniker
so that LoadTypeLib works). These are no where near as robust as the
compiled versions, as you're seeing. There were some early problems in VB4
(such as GetTypeInfo(0).TypeInfoNumber returning 1, not 0) that are still
hacked around in TLI, but there are obviously more involved problems here.
As you said, simply iterating TypeInfos until you find the name you want
seems to give you a reasonable object, as does a lookup by TypeInfoNumber
(using TypeInfos.IndexedItem), but the name lookup is clearly toast.

You may have noticed that some IntelliSense bits also fail to work against
in memory typelibs. For example, you don't get a list after the library name
or an enum member in a referenced project in the same project group. These
limitations also have to do with different levels of typelib API support by
the in-memory varieties. Essentially, they did just enough to make the
compiler work, but not much more. -Matt

>
> > You can't assume that you runtime type information for all objects in
your
> > project. In fact, you only have full typeinfo support for Public
objects,
> > not for private objects or items in the VB runtime (forms, intrinsic
> > controls, etc). This is discussed in the tlbinf32.chm help file where
> > ClassInfoFromObject and InterfaceInfoFromObject are described.
>
> I'm aware. But they're all public, creatable objects (if they weren't, it
> wouldn't work when compiled, etc).
>
> My problem is that it works _fine_ at run-time. If I compile the code,
> works great. It doesn't work at design time: ClassInfoFromObject barfs
when
> I feed it an object from a DLL that VB has open in it's IDE (but, again,
it
> works fine if I compile it and run it normally).
>
> I found another twist: the various name lookups don't seem to work,
either,
> eg:
>
> Debug.Print clsTypeLib.GetTypeInfo("COrder").Name
>
> You would expect this to print out 'COrder' (a valid object that does
exist
> in the typelib's TypeInfos collection), but it doesn't; it prints out a
> totally unrelated object (CAmountMatrix, in this case). Similar problem
> with GetTypeInfoNumber, TypeInfos.NamedItem, etc. If I loop through the
> items manually and do my own string comparison, that works, and, as
before,
> if I compile the code and run it outside the IDE, then it works...but when
> working on objects that are open in the IDE, tlbinf32 is having all sorts
of
> problems.
>
> I've found a way around it: instead of using ClassInfoFromObject, which
> errors, I can use InterfaceInfoFromObject, get the Parent of the interface
> to get a TypeLib reference, then iterate through the CoClasses collection
of
> the TypeLib manually until I find the one I want. It's annoying, but it
> does work in debug mode.
>
> --Colin McGuigan
>
>

[Colin McGuigan]

"Matthew Curland" <mattcur@microsoft.com> wrote in message
news:3b6737d7$1@news.devx.com...
> Gotcha, I'm reading more carefully this time Sorry to make you
reclarify.
>
> I tried some of this and, yes, it is pretty messed up.
<snip>

Thanks for the information (as always), Matt. Glad to know that it's not
just me, and I'm not (that) crazy. =P

--
Colin McGuigan

[Colin McGuigan]

"Matthew Curland" <mattcur@microsoft.com> wrote in message
news:3b6737d7$1@news.devx.com...
> Gotcha, I'm reading more carefully this time Sorry to make you
reclarify.
>
> I tried some of this and, yes, it is pretty messed up.
<snip>

Thanks for the information (as always), Matt. Glad to know that it's not
just me, and I'm not (that) crazy. =P

--
Colin McGuigan