Mike,

>>Is this the right direction to pursue? Any thoughts are appreciated.<<

Yes, I think using an Interface is the right way to handle this.

~~Bonnie




>I have a Windows Forms app that's extensible in that it looks for .dlls in a "Plug-In" folder, loads each assembly, iterates through the types, and if a type implements my interface, does stuff. Stuff it does includes grabbing a MenuItem to add to the app's "Plug-In" MenuItem.
>
>This works fine, but it's pretty much a one-way street. That is, the plug-in can't get information from the host. Just for kicks I added a set property to the interface so now the plug-in has a reference to the app's main form - you could do cute things like iterate through the app's MDI children and manipulate which form is activated, or any other public member.
>
>What I really want is to let a plug-in have access to objects in the app. Objects in this case would be data (Mere Mortals business objects) associated with an MDI form.
>
>What I've just started is another interface. I'm thinking my MDI child forms should implement the interface, then when the plug-in has a reference to a child form, could cast it to the new interface, and call, for example, .GetDataSet() or .GetBusinessOjbect().
>
>Is this the right direction to pursue? Any thoughts are appreciated.
>
>Mike