I have a question for you regarding the SubGraphApp sample program that ships with the new V3.0 of GoDiagrams.
If you set up the SubGraphApp with an empty, collapsed subgraph on the right-hand side of the screen and a single node on the left-hand side of the screen as follows:
And then drag/drop the single node into the empty, collapsed subgraph, you’ll see the following results:
I was thinking that the SubGraph should have remained in its starting position with it’s starting size (before the drag/drop operation). Is this expected behavior?
Oops, that’s a bug we introduced in the example SubGraphApp.SubGraphDraggingTool. This worked correctly in earlier versions of the sample.
If you look in the DoDragging method override, we called the base DoDragging method after doing the Collapse (if it had been expanded because it had been collapsed originally). It ought to do it before.
base.DoDragging(evttype);
if (expandfirst)
sg.Collapse();
One more issue involving collapsed SubGraphs, this time in my program. First, I should point out that my DoDragging method was lifted from the SubGraphApp project. My version differs slightly in that it puts a helpful reminder (message) on the status bar indicating that the user should press and hold the key (as opposed to some other key) to drop objects into a subgraph. Again, its just a helpful reminder. I believe this code all works fine.
My question has to do with what happens to the collapsed subgraph after the user has dropped an object into it. In my case, the collapsed subgraph jumps, or warps, to a new screen position, probably 50 pixels, about a half an inch, above and to the left of it’s previous position. I am wondering what is causing this jumping or warping behavior.
I do have a margin of approximately 50 pixels between the handle/label and the topmost child in the subgraph. Could this margin be the reason the collapsed subgraph jumps up whenever an object is dropped into it? This behavior does not happen when the subgraph is expanded.
That could be. Unfortunately, such customization of GoSubGraph can be tricky to implement. Usually, working overrides are pretty straight-forward, but the trick is in doing it just the right way. Alas, I can’t help you because there is way too much variation and I don’t really know what you are doing or what you want in every situation.
Does the handle move at all when the adding to a collapsed subgraph? Maybe you need to position the dropped objects a little differently before making the call to Collapse() again, at that place where the code was mis-ordered in that sample dragging tool.
Interestingly, the handle/label stay fixed in their expected positions. It’s the entire subgraph (i.e., handle, label, and decorated rectangle around the contents) that jumps.
I think one way to test would be to reduce the margin between the handle/label and the topmost child object to see if the collapsed subgraph jumps less. I’m thinking that if this change does affect the jump then perhaps one solution might be to suspend the ComputeInsideMargins call if the subgraph is collapsed? Or does ComputeInsideMargin already account for whether the subgraph is collapsed or not?
If you save the sg.Location before the Expand in DoDragging, and restore it after the Collapse, the collapsed node won’t jump on you. (If you shift-drag a node into a expanded subgraph, it can change the bounds, and collapsing it will then put it in a different spot than if you hadn’t dropped that node into it. Looks to me that’s what’s happening here. Having a margin might make this more noticeable.)
Success! Restoring the location of the subgraph after collapsing (sg.Collapse()) in the DoDragging method did the trick. Now the collapsed subgraph stays put whenever a node is dragged/dropped into it.