Now I am facing one more problem . I have multiple excel file runnig on one system , but I am getting only one excel file using GetActiveObject. when I close this then I am getting second one using get object . so why I am not getting all the excel files ??
Checking the first 4 bytes of the location pointed to by the interface pointer returned by CoCreateInstance() function might give you the address of vtable (I have not tried it). But why do you want to do this?
I need to call all the functions of COM Interface exposed methods at runtime.
For this I need to access vtable of COM coclass where all addresses of exposed methods of its interfaces are stored.
Math is COM object
and its exposed interface is "Operations"
and "Sum" is the method of this interface.
I need the address of "Sum", so that I can call it on run time. Just like you use loadlibrary for DLL and adter passing functional address, using GetProcAddress we can call function at runtime.
Here in COM same I need to do. But here no LoadLibrary , and no GetProcAddress. Just we need to iterate vtable and one by one we'll get the addresses of methods and we'll call these methods on run time.
Even if you get the function pointers this way, how to get the function signature (arguments and types)? You may have to use type library to get more details about the interface functions and supported interfaces.
a coclass will always have pointers to virtual tables (of all interfaces it implements) as its instance data. In CreateObject() function, coclass is instantiated, type casted to the interface ptr which we demands through CoCreaInstance and returned. so the returned ptr will be pointing to the virtual table of that interface. This virtual table ptr is used later in function calls to locate the correct implemented functions. Pls correct me if iam wrong..
size of the returned interface ptr will be size of a pointer (4 bytes as any pointer). so in order to call the functions using that ptr, u need to have their declarations. Also for all com interfaces, first few entries in vtable will point to the implementation of functions from the base interfaces, such as QueryInterface, AddRef ... of IUnknown. So think whether ur plan is going to work our or not..
You're going about things the wrong way. Getting the v-table's address is no problem. Doing something useful with it will be. All it is an array of function pointers. The pointers have no type information associated with them. It sounds like you should look into type libraries (see the ITypeLib[^] interface) or automation[^].
I have got the addresses of functions from vtable but in little wiered manner.
like typedef void (*FN)(void)
int* dwPtr= (int*)pSomeInterface;
pFn=(FN)*((int*)*(&dwPtr[Count])+1);//will give the address of QueryInterface
pFn=(FN)*((int*)*(&dwPtr[Count])+2);//will give the address of AddRef
pFn=(FN)*((int*)*(&dwPtr[Count])+6);//and finally my method Sum
but this is all hardcoded stuff and little wiered.
I in a search of some generic usefull method to lookup their addresses and then I NEED their NAME as well so that which ever at runtime I give the name as function my app should traverse and call only that method
using FN, how are you going to call those methods like QueryInterface, AddRef.. as they take various number of arguments? u may be able to call without errors, bt result will be unexpected. without having specific info about the functions in interface, u won't be able to proceed..
but _asm patch helped me out in this regard.
call proc ;function address
Here suppose i have given all info (parameters or arguments) at run time for NOW(Which I have passed it on runtime console).
For future(might be later) I will load every thing from TLB's. e.g (How to know that QueryInterface taking 3 params of different type? This is ITypeLibe which provides information from TLB of that Component which I can query from registry to load specific TLB and give me specific function signature and types).
Hence I got all params and function names as well(Which I can decipher from signature working with RE's(regular expression)).
But 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 ?
Can we use reflections to invoke the exposed methods of certain interfaces of COM Object?
Here we will be able to show all exposed methods of COM DLL or COM exe and and on run time, we can execute all of those methods, by passing parameters.
This is already done for Win32DLL here but any idea about COM?
Can we call COM exposed interface METHODS at runtime one by one. This can be achieved in case of WIN32 DLL's using reflections. But SAME job need to be done with COM Dll or COM EXE. We'll be able to view all exposed methods of that COM DLL or COM EXE on client(say on MFC GUI) and ony by one we need to call all of those methods by just clicking "invoke or Execute".(Remember I need to call unmanaged code, purely written in VC++ unmanaged code) . That would not be .NET assembly.
I had COM DLL
it has mehods namely int Sum(int,x,int y);
Client should show in its combo the methods signature i.e Sum(int x,int y)
and when I click at invoke it should give me result say (2 OR any thing that would be sum of those x & y params).
this is done here but this is strictly for Win32 DLL's not for COM DLL or COM EXE's
I don't think you can do this in COM or in WIN32 DLL as neither of them support reflection in the .NET sense. I know it is possible to figure out some aspects of functions from decorated function names, but if the names are undecorated (i.e. C style) then such information is not available.
txtspeak is the realm of 9 year old children, not developers. Christian Graus