Subdocument?

Ok, I kinda layout a scenario and look for suggestions:
I have a application that allows you to draw what is basically a networking topology (PC based network). The application is a test designer for a application we make. Outside of just representing a machine in the network, you can represent certain applications and services it exposes.
I want to be able to draw a “flow-chart” to attach to the machine, its applications and services. In the flow chart, I want to draw out things like, “Start Service” and point it to the “Service” (like IIS). Then, “Copy File”. Then “Stop Service” and point it to IIS again.
I would like this “Flow Chart” to be somewhat independent, but also interact with the “main” content of the network diagram.
So, in a perfect world, I would like to right click the machine and choose “Draw system test flow chart…” and have a new GoView comeup that has the same repesentation of the machine and its applications and services. In this new view, I would like to be able to interact with the machine and services, but not move or modify the machine stuff in any way. I would like them to point to the same document, so everything stays in sync.
My current thinking:
Have the flow chart in a hidden layer (in the main view), bring up a new GoView with the same document and disable editing of the machine layer view and put the flow chart in the previously hidden layer and enable that layer.
Does this make sense? Is there an easier way to do this?

I hadn’t thought of your implementation technique, but that might work. It depends on the details of what you want to show and do. You can probably implement this fairly easily, but will implicitly limit your flexibility in some matters.
Alternatively:
It’s fairly common to have the GoDocument be a “view” onto the real data, whether data structures in memory or records in a database. As the real data changes, you add/modify/remove objects in the GoDocument. As the user modifies the GoDocument, you make corresponding changes to the real data.
So you could have different documents, where the objects in one document represent both the main objects and some details, and the other document represents just the main objects.
Also, it is possible to have a single GoUndoManager keep track of multiple documents, rather than the normal one-per-document.

It’s fairly common to have the GoDocument be a “view” onto the real data, whether data structures in memory or records in a database. As the real data changes, you add/modify/remove objects in the GoDocument. As the user modifies the GoDocument, you make corresponding changes to the real data.<<
I’m using the GoDocument to generate the “real data”, so I don’t see this as a option.
When I tried my technique, making other layers invisible using AllowView = False, they disappear from the original view. I feared this.
So you could have different documents, where the objects in one document represent both the main objects and some details, and the other document represents just the main objects.<<
How would I keep the common object (main objects) in sync. Can a single GoObject be in two documents?

maybe i barking up the wrong tree here… is a GoSubGraph a “view” within a “view”?

Sorry, perhaps I should have been more explicit. What you’ll need to do is remove the layers you don’t want to see from the view’s collection of layers. The ObjectBrowser sample app demonstrates this, and also gives you a picture of the internal data structures involved.
You’ll note these lines where ObjectBrowser.Form1 initializes the document and two views:
// two views share a document
goView2.Document = doc;
// but second view doesn’t show any links
goView2.Layers.Remove(doc.LinksLayer);

To answer your other questions: no a single GoObject cannot belong to more than one GoGroup or more than one GoLayer (and thus not more than one GoDocument). And a GoSubGraph is not really a view within a view, because you cannot scroll or scale the child objects independently from the rest of the view. Besides, a GoSubGraph is a GoObject, so it’s normally part of a GoDocument, not a GoView.