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
|
I'm trying to implement this and it looks like I need some help.
Thanks, -Scott |
|
|
Hello Scott For your first point, I have now made this property settable. Sorry for the inconvenience. We should be putting this into a nightly build this week. For the second point. You can cast the Connections or Nodes properties from your FlowDiagramModel object into an INotifyCollectionChanged. To this you can add to the CollectionChanged event handler which will be notified whenever connections or nodes are being added or removed from thier respective collections. Hope this helps you. For the third point, I have just added a CanConnectToConnections property to the DiagramSurface class. Setting this to false will disable the ability for users to create connection-mounted-connections. Again we should have this out this week. For the last point, just need a bit of clarification. In terms of your intentions of reusing node builders, it sounds like you mean to have a single class for building multiple types of node, but we are not sure how you wish to be able to use it. Are you thinking of a single instance of this across all the DiagramNodeTools, or would it be okay to give each DiagramNodeTool its own instance? We shall let you know when these fixes are available to you. |
|
|
Let's ignore #4, because I think I'm trying to do something unusual and I have a reasonable workaround for it. For #2, I was originally working under the guidance of the help (CHM) file. I've copied the relevant portion below. Hooking the Node and Connection builder (esp with your change for #1) is rather easy. Just create a builder class that adds the node/connection to the underlying business objects. Then we create a type that derives from DiagramModel and listens to the business objects to update itself (one-way observer). This works great. HOWEVER, it only seems to work for node/connection additoins. There aren't any hooks I can find to handle when nodes/connections are deleted. Is the recommended model that we use the builders to handle additions and listen for collection removals on the viewmodel? I.e, we one-way observe into the model from the viewmodel on deletes and into the viewmodel from the model on adds? That feels a little awkward, but I suppose it's workable. Using FlowDiagramModel as a ViewModelFlowDiagramModel may be used as a model class in itself, or as a view model class sitting over a business class. In the latter case you will need to create adapter code to synchronise the model (business object) and view model (flow diagram model). If two-way synchronisation is required (for example, if you are using the standard toolbox items, which create nodes at the FlowDiagramModel level), please note that the Nodes and Connections lists provide change notifications: cast the lists to INotifyCollectionChanged and subscribe to the CollectionChanged event. However, it is recommended that you try to avoid two-way synchronisation because of the potential complexity: instead, consider creating custom tooling (for example, custom implementations of IDiagramNodeBuilder) that modifies the underlying business object, and use the (one-way) observer pattern to propagate changes to the view model (and thereby to the view). |
|
|
ACtually, I'm going to take back that I think it's workable. For deletes, we would effectively have to create 2-way sync code on both the business objects and the viewmodel. If we do all that work for deletes, we might as well use the same approach for add - rather than having a hybrid with the observer pattern. I guess what I'm asking for is either a class I can implement or a method I can override to prevent deletes from being sent directly to the DiagramModel. Instead I will send it to my business objects. e.g. to parallel the INodeBuilder maybe we have INodeRemover. |
|
|
Hello Scott We like your idea of an IDiagramNodeRemover and IDiagramConnectionRemover and so we will start working on this soon and plan to get it up early next week. Cheers |
|
|
I've got plenty to do between now and then. Early next week should be fine. Thanks for all your help on this. |
|
|
I was thinking about this a little more. How are you going to handle the case of a connection endpoint being changed from one node or node connectionpoint to another. Will you issue a IDiagramConnectionRemover for the first pair of endpoints and then a IDiagramConnectionBuilder for the new pair of endpoint (of which one is the same)? Alternatively, will you add a 5th type of handler called something like IDiagramConnectionRerouter? I can see merits to both approaches, but I prefer the latter. In short, the new builder model would model the 5 events that affect the structural layout of the graph/diagram:
|
|
|
Hello Scott Indeed I prefer the latter one as well. Cheers |
|
|
Hello Scott I have now provided IDiagramNodeRemover, IDiagramConnectionRemover and IDiagramConnectionRelocator interfaces and a default implementation to these. You can also find 3 new properties for each of these types on IDiagramModel. Simply setting these properties to an appropriate instance will have all node removals, connection removals, and connection relocation actions going through them. These are all available to you through the latest nightly build. Let us know how this works out for you. Regards |
|
|
Excellent, thanks. We'll implement this in our app first thing tomorrow morning! I'll let you know if we run into any issues. |
|
|
Apologies for not getting to this sooner. Why isn't IDiagramModel one of the parameters on RelocateConnection? I have extended the DiagramModel, so having a handle directly to that is extremely helpful. I have to do some acrobatics to get back to my derived type based on the connection and connectionpoints.
|
|
|
Hello Scott Sorry about this and thanks for pointing it out. Regards |
|