This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello ProcessNode no longer exists in version 3.0. Is ProcessNode your own custom node implementation? If so, you'll need to handle the serialization logic for ProcessNode in the SerializeNodeCore override method. Let me know if you need help with this. -Jason Fauchelle |
|
|
Thank you. It is a custom node and I am going to try it when I get back to work. |
|
|
Thank you, and the serialization is working. But now I have problem with deserialization. In my project, node, connection and connectionpoint are all custom. The code snippet listed below is in the CustomXmlSerializer. In CreateNode, the custom node is created and returned. There are two things in CreateConnection:
|
|
|
Hello When the deserializer first creates the connections, it passes in temporary dummy values for the source and destination. This is because there are some scenarios (mostly related to connection-mounted-connections) where the source and destination data is not deserialized until later in the xml file. Whether or not your application has connection-mounted-connections, dummy values are always passed into this method. The correct source and destination values get updated via the ToConnectionPoint and FromConnectionPoint properties later. To resolve this, allow you ProcessStream constructor to accept DiagramConnectionPoint instances. If your constructor needs to do something with your own custom connection point types, you can attach an event handler to the PropertyChanged event of your connection. Then in the event handler check to see if either the source or destination properties have changed. If so, you can then do any custom logic that needs to be performed on your own connection point types. I've made a note to see if this can be improved for a future version. Let me know if you need further help. -Jason Fauchelle |
|
|
I am sorry that I still did not figure it out. As you said, I changed the constructor of custom connection to accept DiagramConnectionPoint. 1. In CreateConnection: how much I make use of the xml and segements 2. In ProcessStream_PropertyChanged, if I somehow created the new custom connection point, how do I replace that with the dummy ones? 3. Now, when the xml is de-serialized, nodes are displayed corrected, but none of the connections are shown. When I try to move around the nodes, the neighboring connections start to show up. What is wrong? Thank you very much for your help!
Code in ProcessStream
|
|
|
No problem. The base deserializer will take care of building and setting the custom connection points for you. The property changed handler is only required if you need to perform some custom logic on your custom connection points while the diagram is being built. Sorry I was not very clear on this part. If you do not need to do anything special with your custom connection points when they are set, then you can ignore the property changed handler. On your custom connection class, add another constructor that also takes in a list of segments. This constructor can call base and pass in the source, destination and segments - similar to what you're currently doing. You can see the ActivityDiagramConnection class in the ActivityDiagrams sample project for an example. Then in your deserializer, you can check to see if the given segments collection has more than 0 items in it, and if so, use the constructor that requires the segments. I have not been able to reproduce your invisible connections issue, but hopefully using the segments will resolve this. If your connections are still invisible, please send me a sample project and I'll be happy to debug this for you. -Jason Fauchelle |
|
|
It is working with the latest nightly build. Thank you, Jason! |
|