I'm experimenting with a plugin architecture for my company's internal business system. I have managed to read all .DLLs in a Plugin folder which implement a specific interface. What I am trying to figure out is the best method of communication between the "host" MDI parent application and forms that will be in the .DLLs which I intend to make MDI children.
Currently, I am returning just ToolStripMenuItem objects from the .DLLs to add to the MDI Parent. I've also tested that events wired in the .DLLs to the ToolStripMenuItems do propagate to the code in the .DLLs. I've also managed to return a Form object via the interface and open that form, as the Plugin folder is being "scanned".
However, I am not clear how I would make these forms MDI children. Also, any other forms living in the .DLLs will also have to be MDI children. I created a VS 2008 Addin project just to see what's going on, and it seems that the Addin accepts an Application object on which it adds to the ToolStripMenuItems and does other operations. The code to build the menu inside the .DLL. This is opposite of what I have done so far, where the MDI requests a ToolStripMenuItem from each .DLL and adds the returned object to its own menu.
Would designing my plugin architecture to accept an application object in the same manner the only way I could get forms to open as an MDI child? Am I asking for other, currently unknown to me, headaches by NOT passing in the application object to the .DLL?