Question to the Gurus
-
Hi, I am developing an application with several components in it. The main application will have a GUI and there are several components like BHO, MS Office Addins, Clipboard trackers etc. I have a problem here. These components should communicate with the main application by some means. It has to pass some events or some values to the main application. I will be creating both the components and the main application and I would like to know, the best method to connect the components to the main application. I have pretty good exposure to COM and Windows programming. Also Is it possible to create a Singleton Automation server ? Thanks and Regards Jugs "A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
-
Hi, I am developing an application with several components in it. The main application will have a GUI and there are several components like BHO, MS Office Addins, Clipboard trackers etc. I have a problem here. These components should communicate with the main application by some means. It has to pass some events or some values to the main application. I will be creating both the components and the main application and I would like to know, the best method to connect the components to the main application. I have pretty good exposure to COM and Windows programming. Also Is it possible to create a Singleton Automation server ? Thanks and Regards Jugs "A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
Jagadeesh VN wrote: communicate with the main application Define "communicate" and the needs of the "communication process". Are we talking about COM components? Will access methods do (get/set)? Jagadeesh VN wrote: connect the components to the main application Define "connect". Is this "connect" in the sense ::CoCreateInstance or is it referring to the "communication process" above? Jagadeesh VN wrote: Singleton Automation server This feels like you want some kind of COM server that will act as a switchboard for the "communication process". Right or wrong? The best way, IMO, is to register the server in the ROT and use monikers to be sure that there is only one switchboard alive. But perhaps this is overkill. How about callback interfaces or connection points if we are talking about COM components? -- Roger
-
Jagadeesh VN wrote: communicate with the main application Define "communicate" and the needs of the "communication process". Are we talking about COM components? Will access methods do (get/set)? Jagadeesh VN wrote: connect the components to the main application Define "connect". Is this "connect" in the sense ::CoCreateInstance or is it referring to the "communication process" above? Jagadeesh VN wrote: Singleton Automation server This feels like you want some kind of COM server that will act as a switchboard for the "communication process". Right or wrong? The best way, IMO, is to register the server in the ROT and use monikers to be sure that there is only one switchboard alive. But perhaps this is overkill. How about callback interfaces or connection points if we are talking about COM components? -- Roger
Hi Roger, Thanks for the reply. "Define "communicate" and the needs of the "communication process". Are we talking about COM components? Will access methods do (get/set)?" I have a BHO and some MS office addins, which will be continously monitoring some of the events like BeforeNavigate (BHO), OnOpenNewDocument(Addin), ONCloseDocument(Addin), etc. I have a GUI application, where all these events should be reported consistently. I was thinking of implementing the GUI application as a Singleton Automation Server using DECLARE_CLASSFACTORY_SINGLETON macro. Then the monitoring components will create an instance of this automation server and since it is implemented using singleton pattern, the monitors will be able to connect and bind to the same instance of the GUI. Then they can use EventSinks or some other interface methods to communicate with the GUI. Also Since I am using DECLARE_CLASSFACTORY_SINGLETON, I belive the Service Control Manager will check the Running Object Table and will return the currently active instance to all the clients. Can you please confirm this. Once again Thanks for posting a reply. Regards Jugs "A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
-
Hi Roger, Thanks for the reply. "Define "communicate" and the needs of the "communication process". Are we talking about COM components? Will access methods do (get/set)?" I have a BHO and some MS office addins, which will be continously monitoring some of the events like BeforeNavigate (BHO), OnOpenNewDocument(Addin), ONCloseDocument(Addin), etc. I have a GUI application, where all these events should be reported consistently. I was thinking of implementing the GUI application as a Singleton Automation Server using DECLARE_CLASSFACTORY_SINGLETON macro. Then the monitoring components will create an instance of this automation server and since it is implemented using singleton pattern, the monitors will be able to connect and bind to the same instance of the GUI. Then they can use EventSinks or some other interface methods to communicate with the GUI. Also Since I am using DECLARE_CLASSFACTORY_SINGLETON, I belive the Service Control Manager will check the Running Object Table and will return the currently active instance to all the clients. Can you please confirm this. Once again Thanks for posting a reply. Regards Jugs "A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
Hi Jugs, OK, so you have some COM servers (BHOs, MsOffice AddIns etc) and some clients (IE, MsOffice apps) that creates these servers. And... you are talking about a new COM server (the GUI app) where the earlier mentioned servers are clients, right? Let me know if I'm way off And... you need EventSinks in your BHOs and AddIns... Why? Don't we have a design problem here? Who is the client/consumer and who is the server/provider? Do you actually intend to control your clients from the GUI app server? If not; what is the purpose of the event sinks? I don't know what you want to do with your GUI app, which means that your design may be relevant even if I find it suspicious. Isn't the GUI app some kind of a logging application? If so; how about using a UDP port in your GUI app (localhost) and send logging packets to that port from each server? Each server may try to start the GUI app, but the GUI app makes sure that it is the only instance running. Or you could write a service that write logging packets to a file readable from a GUI app. Or some other kind of inter-process communication (WM_COPYDATA?), take your pick. Hope you find some relevans in the above -- Roger -- modified at 10:34 Wednesday 5th October, 2005