Memory leak when using command delegates in context menu

GoXam
1

Dear Support,
I am using Context menus with a command delegate on nodes and links but for some reason after closing the diagram these nodes and links stay in memory. For some reason I am not able to remove the Mouseclick event delegates that this command delegate creates. Any sugestions on how I should deal with this?

Thanks,
Frank

2

What do you do when you “close the diagram”?
And how are the context menu and its commands defined?

3

Hi Walter,

Here is the template of a link:

And this is what I do in the unload event of the screen:

RemoveHandler myDiagram.SelectionDeleting, AddressOf myDiagram_SelectionDeleting

        For Each _node In myDiagram.NodesSource
            CType(_node, NodeBranchData).cslaObject = Nothing
        Next

        For Each _cable In myDiagram.LinksSource
            CType(_cable, CableLinkData).CSLAObject = Nothing

        Next

        myDiagram.LinksSource = Nothing
        myDiagram.LinkTemplate = Nothing
        myDiagram.LinkTemplateDictionary = Nothing
        myDiagram.NodesSource = Nothing
        myDiagram.NodeTemplate = Nothing
        myDiagram.NodeTemplateDictionary = Nothing

        myDiagram.Model = Nothing
        myDiagram = Nothing

Regards,
Frank

4
6

I didn’t see how your Node or Link template uses your custom commands.

Does your app enable the UndoManager?

You don’t set Diagram.UnloadingClearsPartManager to false, do you?

Setting all those properties to Nothing isn’t necessary.

7

Hi Walter,

These are the settings I have for the undomanager and the unloadingclearspartmanager

Model.HasUndoManager = False
UnloadingClearsPartManager=“True”

I tried to paste the xaml for the link template but after I reply I also do not see the xaml. How do I upload this so that you can see how the template is created?
Frank

8

Try pasting into a simple text editor first, and then copy and paste from there.

10

xx
xx <go:LinkPanel x:Name=“CableTemplateLinkPanel” go:Part.SelectionElementName=“CablePath” go:Part.SelectionAdorned=“True” go:LinkPanel.IsLinkShape=“True” xx go:Part.SelectionAdornmentTemplate="{StaticResource BoxNodeAdornmentTemplate}">
xx <go:LinkShape x:Name=“CablePath” Stroke="{Binding Path=Data.LinkColor, Mode=TwoWay}" StrokeDashArray="{Binding Path=Data.NewInstall,Mode=TwoWay,Converter={StaticResource xx NewInstallConverter}}" StrokeThickness=“2” />
xx
xx go:Link.Route
xx <go:Route Routing=“Orthogonal” Curve=“None” go:Part.Selectable=“True” RelinkableTo=“True” RelinkableFrom=“True” />
xx </go:Link.Route>
xx
xx
xx
xx input:ContextMenuService.ContextMenu
xx input:ContextMenu
xx <input:MenuItem x:Name=“ContextMenuLocateCable” CommandParameter="{Binding RelativeSource={RelativeSource Self}}" Command="{Binding LocateCableCommand,Source= xx {StaticResource OpBouwNetstrucViewModelViewSource}}" Header=“Locate” Visibility="{Binding Path=ShowGisLocation,Source={StaticResource xx OpBouwNetstrucViewModelViewSource}}" />
xx </input:ContextMenu>
xx </input:ContextMenuService.ContextMenu>
xx </go:LinkPanel>
xx

11

Hi Walter,

No luck, can I mail it to you?

Frank

12

sure, GoXam at our domain.

13

Apparently this is a flaw in ContextMenu defined in the Silverlight Toolkit.

The way to get around it is to call

    ContextMenuService.SetContextMenu(someElement,
null);

where someElement was declared with a ContextMenu:

  <input:ContextMenuService.ContextMenu>
    <input:ContextMenu>
        . . .
    </input:ContextMenu>
  </input:ContextMenuService.ContextMenu>

As a practical matter, this should only matter if you are going to be removing Diagrams dynamically from your app.