-
Hello,
I am developing a multi-tiered app that will use COM objects and possibly MTS.
The objects are data translators. I.e., they take an input stream of data in some format, transform them into the required format, and return the resultant data.
Not all of these components will be finished at once. As they are finished, they will be made available for use.
So, the client app (there will be a VB client app and a IIS/ASP client web app), needs to be able to detect at startup which COM components are available for use.
The COM objects might not be registered on the client machine. They might be registered on a server somewhere.
Is there a way to query either the localhost or some other machine, and retrieve a list of available objects?
For instance, if I know that all components will follow the same standard naming convention, for instance the first few letters will be the same:
WXYZ_DataFormatA_Converter
WXYZ_DataFormatB_Converter
WXYZ_DataFormatC_Converter
Can I just retrieve a list of available objects, then query it based on 'WXYZ'....
Or is there a much easier way to do this that I am overlooking?
When coding the VB app, I can't just go to the Project menu and set references to the components, because some do not exist yet. So the app needs to start up, search for available data translation components, and present these to the user. After one is selected, the app needs to add a reference to the component, then off it goes...
The data translators will all be based off of a template object and support the same methods, properties, and events. So the rest of the code does not have to change.
Is there a way to do this with VB? Any resources on the 'net or in the MSDN library that you could point me towards?
The only way I've thought of to do this is to have a .INI file of some sort that gets updated when one of the components is installed. Basically maintain the list externally.
Thanks,
Joe
-
If your using MTS (certainly in com and not com+) you do not want to reference the objects via project references. You want to use late binding and use createobject. If the object exists your VB will create the object and use it. If the object doesn't exist, then you will get a standard VB error and you can act accordingly (i.e. put a message out saying that component isn't available). Also dont forget if the component is on a different machine then you need to use DCOM.
-
Alternatively, you could use an interface component that all the DLL's implement. This gives you two major advantages - IDisp Binding instead of Late binding, which is faster (and you get the intellisense stuff when you code), and it means that you can use the TLI library to determine whether or not the component supports certain functions.
- gaffa
