forms and controls design question

[Bob]

I want to have all forms out of my controls' DLL and in their own, only some
controls have to create these forms under certain conditions. For instance,
a base data-viewing control needs to bring up a configuration form when the
user control+right-clicks. It is acceptable practice to have these controls
raise shared events (i.e. "form1 popup request") and then attach delegates
to them on app startup (or do it all through a single common shared event)?
I don't particularly like the idea but it's the only way I can think of
doing it. Would it be better just to keep the forms where they are? I don't
like that, either, it doesn't sit right with me to have forms part of a
controls DLL.

Bob

[Bob]

I suppose I should clarify a bit more - I want the forms DLL's separated
according to function, they shouldn't be referencing each other. So the
controls that bring up the configuration forms should only do so if the DLL
containing them is referenced in the top-level assembly...

Oh never mind. Maybe I'm just making it too complicated.

Bob

"Bob" <no****@nowhere.com> wrote in message
news:u0****************@tk2msftngp13.phx.gbl...

I want to have all forms out of my controls' DLL and in their own, only some controls have to create these forms under certain conditions. For instance, a base data-viewing control needs to bring up a configuration form when the user control+right-clicks. It is acceptable practice to have these controls raise shared events (i.e. "form1 popup request") and then attach delegates
to them on app startup (or do it all through a single common shared event)? I don't particularly like the idea but it's the only way I can think of
doing it. Would it be better just to keep the forms where they are? I don't like that, either, it doesn't sit right with me to have forms part of a
controls DLL.

Bob