As you are probably aware, not all classes can be registered using regsvr32.exe i.e you get that dreaded dll entry point not found error, so, using the tblinf32.dll, you can suss out just which type of COM application you have, and based upon the results register the dll appropriately.
Be interesting if you could share a small sample or even psuedo code.
I'll look and see if I have anything I can post .. I am sure you appreciate since it was for a client, I must be very careful about posting code.
Depending upon the way the class is invoked it may run out of process ... I have seen some really crazy stuff done ... anyway, by knowing exactly the type of class I am dealing with, I can use appropriate calling methods for each, thus ensuring the class runs in-process.
I must have the most horse blinder experience, because in all my years instanciating classes hosted in activex dlls I have never had one attempt to run out of process. Mind you, I never polled the system either to determine if an object was attempting to run out of process, so maybe I'm simply oblivious. Reflecting for a nano second ... yeah, the latter.
Have you ever created an ActiveX EXE that uses classes that are only available to the executable i.e. MyClass.exe is the only program that can register the application class .. since ActiveX EXE programs are generally self registering, (at least the ones I have dealt with), and unregistering in some cases, it means that if you wish to register the class, you have to be able to execute the program ... if you execute the program, your options are limited as to how you can do that, such as calling the program using ShellExecute. To my knowledge, ShellExecute runs the new program in its own memory space, thus marshalling takes its toll on data gathering between the programs ... also sometimes you find an ActiveX exe that has been renamed to something else such as MyApp.dll or MyApp.dat. In those instances, the user must know what kind of program he is dealing with as regsvr32 does not work with ActiveX exes.
Ideally, everyone would follow the same methodology and we would be able to handle all classes the same, but until then, I'll have to utilize gathering the type library information from the file i.e. is it an application or dll? what are the exposed classes? shoot ... are there any exposed classes?
Is that a little bit clearer? Perhaps I am doing something unnecessary ... but it has always been my understanding that if you run an app using ShellExecute, then it runs in its own memory space ... maybe I am wrong ..
