How to get function Name against function address of vtable?

[glitteringsound]

Hello,

I need to call the co-class function by reading its address from vtable of COM exposed interface methods. I need some generic way to read addresses.

Now I need to call the function, which would have specific address(NOT KNOWN) arguments(parameters) which I have collected from TLB, and name as well. How that address corresponds to that function name to which I am going to call.

For this I need to traverse vtable which is holding functional addresses, LASTLY need to correspond function address with NAME of that function. This is I dont know. How? More over one function with the same name may appear in vtable(Overloading case). In that case we need to distinguish function names w.r.t their addresses. How to tackle ?
Regards
Usman

[ProgramArtist]

The implemantation details of the VTABLE are compiler dependent. So if you are implementing what you've described in your post you cannot be sure

1. that this code will work on another platform
2. this code will work on another compiler version (next one in a few years)

I would rather suggest that you explain to us what exactly do you want to achieve. Maybe (I'm almost sure) that there is a better, correct c++ way to solve this.

With regards
Programartist

[ProgramArtist]

Additionally:

The function name exists only in the symbol table of the compiler. You can access the pointer of the function given by name (and params) only in your source code, during compiling time and through debugging information.

If your app is running there are no function names in it. The linker is the last one who knows the function names. You can see that if you "debug" a non-debug-build of your exe: No function names are given. Only adresses (in the code segment or in the VTABLE of instances of classes).

If you want to implement a function like:

BOOL CallAnyFunc(LPCSTR szName, const int iParamCount, ParameterStructArray* pParams);

you need to make a connection between your functions and their names. This is possible by creating lists/maps of functions/functionnames.

With regards
Programartist

[glitteringsound]

Thnx for answer.

Respectfully Sir.!!

I am designing a Unit Testing framework for which I need to pull out all function signatures of certain COM Exe or COM DLL to show in the grid or whatever interface to user, so that later by selecting certain function signature from that list, He/She can execute that function after providing the arguments(data as parameters) to that function. All this would be done dynamically at runtime, on runtime function will be called whatever user wants.

This can be achieved from various ways.

By providing TLB(Type libraries) we can pull every function signature and can show every signature to Grid control or on Tree control. Second step is to call these functions at runtime by providing data. Calling require data and address of functions(or Names). I would have some GUI panel or control which will take the data from user and that data would then become as arguments.

Now real problem comes for which I posted earlier. Call to functions/methods of that interface exposed by COM component implemented by co-class. This requires to trail down vtable of interface exposed by component , finding the address of that function and then need to know IS IT REALLY THAT ADDRESS TO WHICH I AM GOING TO CALL AS FUNCTION? So this requires to translate that address to function name and then comparison some string comparison would decide that whether it was really that function name which USER CLICKED from Tree Control showing signatures.

Suggestions or reccommendations?

[ProgramArtist]

Ok,

sorry for overlooking the COM keyword in your OP.

But I still do not know why you need the pointers to the VTABLE?
If you get the information from the TLB you can get the IDISPATCH Interface and you can invoke the functions by calling invoke().

public static Variant invoke(Object pDispatch, _Guid iid,         String dispName, int dispID, int lcid, int wFlags, Object         oArg[], int uArgErr[]);

See the MSDN for examples and reference.

The idea behind the COM programming is that you can invoke these published methods of certain interfaces. There is absolutely no need to get the pointer values of the VTABLE entries (e.g. there is no need to know the implementation details).

With regards
Programartist

[glitteringsound]

this one I never try. but will try now
But this one has limitations. We at last need to traverse the vtable. As my component can implement the interfaces those are of third party. e.g (OPC has its own interfaces which always be implemented for the use of their exposed interface methods). In that case these methods won't go inside IDispatch. Later on they also not appearing in that component's TLB as well.

[glitteringsound]

More over can invoke(..,..) of IDispatch be able to call these function at run time(As GetProcAddress in case of DLL enables us).?

[ProgramArtist]

More over can invoke(..,..) of IDispatch be able to call these function at run time(As GetProcAddress in case of DLL enables us).?

Of course it can. That's the idea behind the COM (IMHO). You write a piece of code (control, app, dll, ...) and you publish an well defined interface (that's what you've read in the TLB). Then - not knowing the implementation details - you can invoke every compiled code that implements exactly that interface.

With regards Programartist

[glitteringsound]

What about those THIRD PARTY EXPOSED INTERFACES methods which never goes inside IDispatch interface. Those interfaces always implemted by COM component but their descriptions & documentations never goes inside TLB of that component(e.g OPC interfaces)