TLBINF32 not working when program is compiled...


Hi,

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

 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 1.1.97.82 (6.00.9782)
I'm using VB6 with SP5, My machine is an XP Pro with SP2.
DextroSoftAsked:
Who is Participating?
 
anthonywjones66Connect With a Mentor Commented:
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.

Anthony.
0
 
amebaCommented:
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"
0
 
DextroSoftAuthor Commented:
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... ?

0
 
anthonywjones66Commented:
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.

Anthony.
0
 
DextroSoftAuthor Commented:
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
0
All Courses

From novice to tech pro — start learning today.