tlbinf32.dll


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: tlbinf32.dll

  1. #1
    Colin McGuigan Guest

    tlbinf32.dll

    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



  2. #2
    Matthew Curland Guest

    Re: tlbinf32.dll

    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
    >
    >




  3. #3
    Matthew Curland Guest

    Re: tlbinf32.dll

    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
    >
    >




  4. #4
    Colin McGuigan Guest

    Re: tlbinf32.dll


    "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



  5. #5
    Colin McGuigan Guest

    Re: tlbinf32.dll


    "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



  6. #6
    Matthew Curland Guest

    Re: tlbinf32.dll

    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
    >
    >




  7. #7
    Matthew Curland Guest

    Re: tlbinf32.dll

    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
    >
    >




  8. #8
    Colin McGuigan Guest

    Re: tlbinf32.dll


    "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



  9. #9
    Colin McGuigan Guest

    Re: tlbinf32.dll


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center