The anchor points overlaying looks like a bug, where the visuals for the old AnchorPattern are not removed from the WPF visual tree. We'll post a fixed version today. The resizing problem seems to be the same bug - the newly assigned anchor points are moved correctly, but the old ones are not associated with the node anymore and are not processed when the node is resized.

Stoyan

Thanks.

FYI, This does fix the anchor points issue, but now when my node is first placed it is extremely tiny (seems like it isn't respecting the bounds I set for it).

The workaround for this is to call UIElement.Measure() before adding the element to the diagram (via the Nodes collection).

Also if my nodes expand, the diagram does not enlarge (it's contained in a scrollviewer and the bars do not show up). Calling ResizeToFitItems() fixes this, but generally in WPF the parent container automatically takes care of this. For example, a normal treeview will add scrollbars automatically when the treeview items are expanded if they are too large for the container. The treeview template is merely an itemspresenter inside of a scrollviewer, so it seems like this behavior is automatically provided by the WPF layout system. It seems like WPF Diagram does not properly participate in this system? This seems like the reason why I need to resize the node when its content expands -  unless I am wrong, I believe this shouldn't be necessary.

Thanks again for all your help.

In that latest version the Diagram calls Arrange(availableSize) on a UIElement when one is added, so it corresponds to the DiagramNode.Bounds.Size, which was needed for tooltips to work correctly. I suppose we should do the opposite when adding UIElements not derived from DiagramNode, and update the adapter's Bounds from the element's DesiredSize. We'll also add an auto-update property to DiagramNodeAdapter, so that the adapter nodes update their and the diagram's Bounds when the hosted UIElement requests a ne size.

Stoyan