Avoid diagram layout reset when switching tabs

Hi,
I’m new to Go Diagram, and I write a WPF application which uses a TabControl, and has a diagram in each control. I noticed that whenever I switch between tabs, the tab control layout is set again, with animation.
I want to avoid this, so if users drag nodes, and then switch to another tab, and back to the current tab, their manual layout changes will be saved.

Can this be done?

Thanks,
splintor

That’s not the normal behavior. The normal behavior is what I think you want. So there’s something going on when switching tabs.

I’m wondering if you are accidentally resetting the Diagram.Model or the …Model.NodesSource, or if you are unintentionally adding or removing a node or link, or calling LayoutManager.InvalidateLayout, or calling DiagramLayout.Invalidate, or setting DiagramLayout.InvalidLayout, when switching tabs.

That’s what I thought, but in my code, there is nothing I see that is causing this.

You can check for yourself with this simple XAML:




<go:Diagram Name=“Diagram1”>
go:Diagram.Layout
<go:TreeLayout />
</go:Diagram.Layout>
go:Node



</go:Node>
go:Node



</go:Node>
go:Node



</go:Node>
</go:Diagram>


Other stufff goes here…



If you drag a node, and then go to Tab2 and then back to Tab1, the nodes are re-arrange. Obviously, the problem doesn’t occur if don’t set the diagram’s layout, but that doesn’t help…

I’ll be happy if you could help. I have no idea what cause it to redo the layout when switching tabs.

Thanks,
splintor

Hello,

I’ve notice the same thing switching between two usercontrol.

First I load the diagram, i set some scale, some node location, i use scrollbar to see a particular zone
then I switch (diagramcontrol.hide)

Then i come back to the diagram, i have loose my scale and my position scrollbar. But I keep right the node locations

The last point is due, in my mind, to the use of this binding
go:Node.Location="{Binding Path=Data.Location, Mode=TwoWay}"

Must i do other similar binding for scale and scrollbar position ?

Aurore

This is due to a change we made to avoid memory leaks with data-bindings.

Try setting Diagram.UnloadingClearsPartManager to False, for those Diagrams that are inside TabControls.

Perhaps we should set it to false automatically if we can recognize standard situations where unloading and then reloading the diagram is common.

We decided to make the default value true in order to minimize the number of memory leaks, because that’s not a situation that developers or users would see easily.

Cool!
This indeed solves the problem, thanks.

To avoid memory leak, do I need to set it back to true in the code behind when the window is closed?

Also, this sounds very strange, that switching tabs unloads the diagram. When I have a text box in a tab, and I switch to other tabs, the text box retains it’s value and it’s selection. Why does the TabControl unload the diagram?

No, don’t worry about memory leaks unless you are discarding the Diagram and replacing it with an arbitrary number of other Diagrams. Most applications just use a fixed number of Diagrams (or other Controls for that matter), so there isn’t a problem. In other words, most applications could blindly set UnloadingClearsPartManager to false without any problems.

Maybe some day Microsoft will fix its memory leak problems in both WPF and Silverlight, and this issue will go away.

I believe all of the controls in a tab are unloaded when switching to another tab.

Hi Walter, and thanks again for the useful replies.

From what I checked, the controls are not really unloaded from memory when switching tabs, but only from the visual tree. However, the Unload event does happen, which cause the diagram to clear nodes positions in case it has a layout (as I said, if it doesn’t have a layout, nodes positions are kept).
I guess that’s why simple controls like TextBox can retain their content and state, as their uninstall event does nothing.

If I plan to and and remove TabItems, where each has a diagram in it, do you think I need to fear from memory leaks?

Regards,
splintor

That depends on your code/data-bindings.

A quick web search reveals many complaints and warnings, such as:

WPF memory leak, by design: KB938416

common memory leaks

WPF Memory Leak