Nancy,

>Okay, here's one. Two roads that go to the same town. Bet you thought I'd come up with a computer use case, huh? Actually, I mean that seriously. A client wanted the table maintenance form on two menus. One on the "adminstrator-only" menu, and one on a normal user submenu. The reason was that administrators would sometimes do maintance and they flat didn't want to have to look anywhere but their own menu.
>Sometimes it is a data context change without any difference in the result.


So that's a couple of places instead of lots so the data context "feels" more like there should be just a single instance for your use case. Being activated from a menu would also mean that a form manager would be used to manage the single instance. The fragment of code I posted would not work for this.

"Lots" to me would mean 4, 5 or even a dozen places and then it would seem that the data context of where the spawned form is launched from would be more independent and therefore not single instance. Let me give a more concrete example:

I worked on a manufacturing app where a project had three components. The user could open as many project forms as they wanted. From the project form they could open a seperate form for each component so they could have 4 windows open max per project. But once a component form was open for a project they couldn't open another, this was easily handled by deactivating the form launching control.

Since multiple projects could be open the user could have one of each component forms open for each project, so overall it was a multiple-(single instance) form system *s*

Another example of multiple-(single instance). There is an arbitrary tree of nodes. Each node has a set of possible attributes.

A treeview based form can be used to drill down to the desired node, and then a single node attribute editing form can be launched. The user typically needs to be able to work with several nodes at a time. So we allow several node edit forms to be open, but only one form can exist for a given node.