Hello,

I hope I can convey my issue clearly.

I am using savetoxml and loadfromxml with some customobjects, and I have come accross the scenario where the loadfromxml is getting called on the wrong custom object. For example, the loadfromxml is failing in my Alfadata.SchematicValveConnector
when attempting to read it's properties from the xml, and if I use the debugger, I see that the ByVal xmlElement As System.Xml.XmlElement looks like this in the debugger:

<Node Class="Alfadata.schematicEmptyConnector" Id="836" Version="1">
[...]
</Node>

Note, that it isn't a Alfadata.SchematicValveConnector element at all, so of course it cannot find the properties that a valveconnector expects.

Tracing through the xml looking for clues,
I found that another object has ID 836 listed in it's attachment section, but lists it as a SchematicValveConnector:
<Node Class="Alfadata.SchematicTableConnector" Id="350" Version="1">
<Bounds>2095.528, 1452.104, 37.59689, 2</Bounds>
<ZIndex>350</ZIndex>
<HyperLink />
<ToolTip />
<Locked>False</Locked>
<Visible>True</Visible>
<Printable>True</Printable>
<Brush Id="0" />
<Pen>
<Color>#00FFFFFF</Color>
<DashOffset>0</DashOffset>
<DashStyle>0</DashStyle>
<LineJoint>0</LineJoint>
<MiterLimit>10</MiterLimit>
<Width>0</Width>
</Pen>
<Font>
<Name>Tahoma</Name>
<Size>3.5</Size>
<Unit>0</Unit>
<Bold>False</Bold>
<Italic>False</Italic>
<Underline>False</Underline>
<Strikeout>False</Strikeout>
<GdiCharSet>0</GdiCharSet>
</Font>
<ShadowBrush Id="0" />
<ShadowOffsetX>0</ShadowOffsetX>
<ShadowOffsetY>0</ShadowOffsetY>
<SubordinateGroup>
<MainItem Id="350" ClassId="Alfadata.SchematicTableConnector" Version="1" />
<Attachments>
<Attachment>
<Item Id="836" ClassId="Alfadata.SchematicValveConnector" Version="1" />
<Type>6</Type>
<Data>3</Data>
<Percents>-9.466553, -9.466675, -28.13034, 7.466675</Percents>
</Attachment>
<Attachment>
<Item Id="985" ClassId="Alfadata.SchematicValveConnector" Version="1" />
<Type>6</Type>
<Data>3</Data>
<Percents>-9.466553, -9.466675, -28.13034, 7.466675</Percents>
</Attachment>
</Attachments>
<Visible>True</Visible>
<AutoDeleteItems>False</AutoDeleteItems>
<Expandable>False</Expandable>
<FollowMasterRotation>False</FollowMasterRotation>
<PrevRect>2095.528, 1452.104, 37.59689, 2</PrevRect>
<FollowMasterContainment>False</FollowMasterContainment>
</SubordinateGroup>

[...]


I am trying to figure out how it is possible for the attachment section to have this listed as a different type of object than the actual object was saved as, so I can fix it and prevent it from using the wrong custom object to load the XML with. Can you provide any direction?

Thanks again for your support.

Yes, I use the ZTop() function to ensure that the valve nodes are on top of the links and stuff.  Thank you, I will change how that works and see if that resolves the issue.

The fix that Bjorn implimented as follows has not corrected the issue.

   'ZTop will screw up the grouping for savetoxml, so we need to only ungroup and regroup to do a ztop.
    Private Sub fixed_ztop(ByVal node As ISchematicConnector)
       CType(node, MindFusion.Diagramming.DiagramNode).Detach()
       CType(node, MindFusion.Diagramming.DiagramNode).ZTop()
       node.AttachToTable()
    End Sub

Before the change to alter the Z-Index only a couple of the schematics files would cause issue. Now every save corrupts the XML file causing nodes to be lost and missing data.

Calling any of the Z* methods or setting ZIndex while saving a file is the cause of this problem, not the fix. You should not change Z order while a file is being saved or loaded.

When saving XML files, ZIndex values are used as identifiers. During some serialization event, such value might have already been saved as a node's id in a group, and if you change it from the event handler, this will lead to various problem when loading the file later.

Perhaps you should add breakpoints to all lines that set ZIndex or call Z* methods, and see which one is called while SaveToXml runs. It might be something buried down a deep call stack that you might not be expecting to run during serialization.

Stoyan

I cannot find any part of our code where any ".Z" methods are being called. The only one I can find is the Diagram.cs file of MindFusions where the FixZOrder function is called.

Is there any way to completely remove or rebuild the Z-indexes prior to saving.

If I take a legacy version the read and write binary it works fine but then we have issues saving / loading between winforms and ASP .NET.