Why is it not possible to add a GoObject to more than oner layer? We have a requirement to be able to add collections of objects to layers which represent particular domain models and sometimes an object might overlay more than one model. Customers like to view layers independently which currently may contain holes. I don’t want to try and second guess your implementation, but simplisticly it seems that a layer is just a collection holding references to objects which should present no problem.
It would be useful too to use the document's layers as indexes (like the LinksLayer) and the view's layers for presentation which also requires references to the objects in more than one collection.
I'd be happy if you told me I was missing something obvious!
When conceptually an object can belong to multiple “containers” you have to specify the policies covering changes to the “container”. For example, if a node were to “belong” to two different layers, what should happen when one of the layers is deleted? Should the node remain in the other layer, or should it be deleted too?
Similar kinds of issues arise when dealing with copying or moving or making invisible. If you have experimented with layers in Visio and have had objects in multiple layers, you’ll have seen such inconsistencies.
When using GoDiagram, it’s better to design and implement exactly what you want. Examples include the TreeApp and SharedStates samples.
TreeApp doesn’t actually put nodes in different layers, but they could be. Yet moving/copying/deleting a node can do the same to all of the tree children of the node, due to how GoToolDragging.ComputeEffectiveSelection has been extended.
SharedStates demonstrates a different strategy, showing how to associate multiple objects with multiple containers, without using GoSubGraph.
Thank you. I hadn’t understood the level of node managment undertaken by Layers - deleting a layer also deletes its contents. I’d imagined the contents dropping through to the default layer (or if in more than one layer remaining in the other layer) and that the default layer was non-deletable. Too much imagining and not enough research!
I absolutely agree that design should be deliberate with a clearly understood intention.
I've tried something silly:
GoDocument d = new GoDocument();
d.Add(new GoLabeledLink()); // Added to the default layer: the one with identifier 0
d.Layers.Remove(d.Layers.Find(0)); // try deleting the default layer
The default layer remains so it is protected but the link has been deleted. I'm not sure I was expecting that.