TLBINF32 not working when program is compiled...

Posted on 2005-04-07
Last Modified: 2012-06-27


I've a strange problem I can't really solve...

I'm using the the TLBINF32 to browse for available properties of an object. Simplified the codes looks like this :

            Dim t As New TLI.TLIApplication
            Dim interfacei As TLI.InterfaceInfo
            Dim xTypeInfo As TLI.TypeInfo
            Dim memberX As TLI.MemberInfo

          Set interfacei = t.InterfaceInfoFromObject(App)

             MsgBox ("Write registry :" + CStr(interfacei.Name))
             MsgBox ("Continue " + CStr(interfacei.MajorVersion))
                 For Each memberX In interfacei.Members
                              MsgBox ("Member " + CStr(memberX.Name))

 This code is working fine when running the program in the IDE of VB6. But once the program is compiled, I can only retrieve the name of the object. Retrieving the members will throw me an error 445 - Object doesn't support this action.

In the example provided i use the App-object but it could be any class defined in the same program. Such as " Dim xObject as New MyObject" where MyObject is defined as a class in the SAME project.

I further notice that when retrieving the name I get "_App" as name when the program is runned in th IDE, where I receive "App" when the program is compiled.
I already tried to put all the functionality of the TLBINF32 library in a seperate ActiveX DLL  with a wrapper class, but the result stays the same.

Can anybody explain me why this is ? Is there a work around ?  Most examples I find on the net starts from the "TypeLibInfoFromFile" to retrieve the information which is not useable for me as I need to "scan" running objects in the same program.

I'm working with the TLBINF32.DLL versiion (6.00.9782)
I'm using VB6 with SP5, My machine is an XP Pro with SP2.
Question by:DextroSoft
    LVL 8

    Accepted Solution

    Is this code in Standard EXE or an ActiveX Exe?

    What you will find is that in the IDE VB doesn't really care much which type of Exe you want to build and will for it's own purpose build a full type library for the classes etc in your project.   However on build it will remove all unnecessary items from the output of a Standard EXE.

    So if it is a Standard EXE compile it as an ActiveX Exe instead.

    LVL 15

    Expert Comment

    From Matthew Curland in some newsgroups post:
    "Note that TLI will only work in the compiled EXE/DLL/OCX if the class is
    public. There is no runtime type information available for private objects.
    Of course, private objects don't tend to change much between when you
    compile and run them, so it is easy enough to compile in a static set of
    data. -Matt"

    Author Comment

    Changing the EXE in an ActiveX EXE seems to be 1 solution that works....
    But it seems not to work for default vb classes such as App, Printer, Err,...

    I will attribute the points to anthonyjones66 as it saved me a lot of monkey -coding work :-)

    anyone a solution which will work on App, Err, printer, etc... ?

    LVL 8

    Expert Comment

    These are VB components that are external to the project.  Their defnitions are found in C:\Program Files\Microsoft Visual Studio\VB98\VB6.OLB.  You could try using the TypeLibInfoFromFile method  of the TLIApplication object to open and explore it.


    Author Comment

    These objects are enumerated in the file you indicate. The only problem is that except of the description I only receive to members: e.g. App gets _App en AppEvents as members. Anyway, I will accept the answer as I figured out I only have 4 of these objects and I can easely "hardcode" them... The most work was with these app. 70 other objects I had and enumerating these is working like a charm..

    So: In Order to tlbinf32 to work with running objects ( InterfaceInfoFromObject) an object must have a type-library. This is the case when the program is running in the IDE, in order to have the type-library info still available when the program is compiled, the class must be set as "public" . The only way to do this, is to create ActiveX EXE's instead of "regular" once.

    Thanks for the help

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How to run any project with ease

    Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
    - Combine task lists, docs, spreadsheets, and chat in one
    - View and edit from mobile/offline
    - Cut down on emails

    Suggested Solutions

    Introduction While answering a recent question ( in the VB classic zone, I wrote some VB code in the (Office) VBA environment, rather than fire up my older PC.  I didn't post completely correct code o…
    Have you ever wanted to restrict the users input in a textbox to numbers, and while doing that make sure that they can't 'cheat' by pasting in non-numeric text? Of course you can do that with code you write yourself but it's tedious and error-prone …
    Get people started with the process of using Access VBA to control Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
    Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…

    760 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    9 Experts available now in Live!

    Get 1:1 Help Now