Change Node.Location from code behind

I tried adding Nodes and Links of the subgraph before adding the group, I tried adding the group before adding Nodes and Links of the subgraph. I always get the same result. And because I do all this programmatically, I make sure to call SetGroupNodeKey.

I tried overriding OnNodeAdded of the PartManager, and manually call UpdateLayout follow by Remeasure of the Group… didn’t work.

And you know what is strange, when I’m debugging my code and return to my app, the group size is correct. Same as if I close and re-open the form in which the Diagram was. And obviously, I tried a simple LayoutDiagram after doing my changes, but still didn’t work.

I’m lack of idea …

UpdateLayout is a UIElement method and has nothing to do with GoXam.
(Well, maybe not “nothing”, but it’s not something we implemented.)

Have you implemented your own layout(s)? Did you override DoLayout?

Well, I’m using 2 differents layouts. To display the Group, I’m using your VerticalLayout whitout any change, and to display the subgraph items, I’m using the GoXam TreeLayout. The thing is when VerticalLayout.DoLayout is called, the Group has not the right height, so the DoLayout is done using a wrong height. I tried to call the Remeasure method inside the DoLayout, but it did not work.

And by the way, I want to thank you for the help. Your support service is the best that I ever seen.

Part.Remeasure() just invalidates so that it get re-measured and re-arranged soon.

Hmmm. Try adding the following line after the first !n.Visible check, in VerticalLayout.DoLayout’s first loop:
new CircularVertex().Node = n;

This is just an educated hunch; I’m hoping it helps.

Nop, did not work…

Well, if that didn’t work, I don’t know what to try next.
That was one way of getting the same behavior as all of the other predefined layouts do when dealing with nodes that are groups that might have just had their layouts performed and therefore might not yet have accurate Bounds.

To confirm: your Diagram.Layout is an instance of VerticalLayout, and each Group.Layout is a TreeLayout?

Yep, exactly…

Could you check that the Bounds of each Group is the same after setting CircularVertex.Node as it was before setting it? And is it in fact the “wrong” value?

(BTW, any of the Vertex classes should have the effect that we want; CircularVertex isn’t special.)

Hahahah I got it!!!

The GridSnapEnabled property was set to True. That was the cause of all my problem. I don’t know why, but now it’s working perfectly.

Well no, forgot the last message. Yes it helps but my Group height still wrong. Why it was working is because I manually set the Node.Height to the Node.Bounds.Height.

And yes when I added the CircularVertex, the Bounds change, but at the screen, I got the wrong Height. Is it normal that the Node.Height is set to Undefined in the DoLayout method?

GridSnapEnabled shouldn’t have any effect on this issue.

If a Part hasn’t been measured and arranged so that it can be visible in its panel, then it could have the wrong values for its Bounds. However, it isn’t clear to me that the Height value would be “Undefined”, since that’s not even a number. Did you mean NaN? I would have thought that the default value for Height would be zero.

OK, I still don’t see why it’s not working for you, as it does for other layouts.
So let’s try an alernative solution. Don’t set Diagram.Layout. Instead implement a Diagram.LayoutCompleted event handler that constructs a VerticalLayout, sets its Diagram property, and then calls its DoLayout.

Not undefined but -1.#IND. I don’t think it’s the same as NaN.

I tried to create the VerticalLayout when the LayoutCompleted. It seems to work, but there is a lot of animated resize of the Group that’s not visually pleasing.

You could turn off layout animation by setting Diagram.LayoutManager.Animated = false.

Hi Walter, I still have some display issue. I took time to analyse more in details the thing and the problem is not comming from the VerticalLayout. It comming from the TreeLayout, well, look at the images below, it will be easier to understand.

Note that I disabled the VerticalLayout. What I do is connect 2 nodes togheter directly from the diagram. One of them is inside a Group and the other one is not. So, when the action of linking is perform, I’m adding programmatically the second node to the group using Model.SetGroupNodeKey.

1- In the first sequence, Group.Layout = DiagramLayout and it’s working well. The bounds of the group are like they should be.

2- In the second sequence, Group.Layout = TreeLayout and the Bounds of the group is not remeasure.

Is there anyway to force a remeasure of the Group.Bound follow by a Re-Layout? or any idea why the bounds is not remeasure?

You say you “disabled” VerticalLayout – what do you mean?
What’s the value of Diagram.Layout?

In our internal tests we hadn’t noticed that problem.
But I can investigate.

I disabled VerticalLayout just to be sure that that behaviour is not coming from this Layout. So Diagram.Layout is using the default Layout

I have a question for you. Can I mix action perform in the diagram with Transaction.

Because, what I’m doing is I handle the Model.Changed event, and when ModelChange=AddedLink, I start a transaction, SetGroupNodeKey for the 2 nodes connected to this link, commit transaction.

Is it the right way to do?

That’s OK, although you probably don’t need a transaction, because there’s one already ongoing at the time of the Changed event (check to be sure!). Still, the nested transaction doesn’t hurt, so you could keep it.

And I don’t see why you need to change the group membership for both nodes, but I guess that’s up to your app.

More serious is that you are doing this with every new link that is created. Are you sure you want that? It’s probable that you just want it when the user draws a new link. You can handle only those interactively-drawn cases by implementing a Diagram.LinkDrawn event handler.

Yep, good idea. But it still not resolve my Group.Bounds issue.

I confirmed that I cannot reproduce what I understand to be your problem.
But it just occurs to me now that I was using preliminary version 1.3 (both WPF and Silverlight), not version 1.2.6. Oops.
So when I get a chance I’ll try again.