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
|
Is there a reason why FlowDiagramModel isn't a DependencyObject? There have been several cases where I've had to workaround this limitation when I want to place Dependency Properties on derived types. One example of where this comes up is when I want to animate automatic layout of the diagram model. |
|
|
FlowDiagramModel isn't a DependencyObject because it's just part of the model: we weren't expecting that it would need to participate in the DP system e.g. for animation. I don't think there would be any issues with making it a DependencyObject, as I don't believe there'd be any need to access it across threads, but it would be useful if you could give a simple example of how you would like to use DPs on the FlowDiagramModel -- e.g. do you see yourself placing it in the XAML and storyboarding it there, or loading and attaching a storyboard through code; how do you see your derived type consuming the animated value, etc.? |
|
|
I have extended the FlowDiagramModel class because that is the first place in the class hierarchy where nod locations can be applied en masse. Ideally I would expose 2 dependency properties. The first would be a target layout (essentially a dictionary mapping Nodes -> Bounds). The second would be a double in the range of 0.0 to 1.0 that determines the extent to which the flowDiagram has been transformed from its previous layout to the newly defined layout. We have wired up a graph layout component that provides well organized layout services. Instead of simply snapping to the algorithmic layout when we apply an autolayout, we are instead doing a BeginAnimation with a simple linear DoubleAnimation of the previously mentioned double Dependency Property. Since the FlowDiagramModel can't expose a DependencyProperty, we are exposing the DP on the DiagramSurface and then using events to propagate the DP down to the FlowDiagramModel. This works, but it's inconvenient. As before, I'd be happy to give you a demo of the app and walk you throught the code, if that would be useful to you. WRT code vs. XAML, we're currently invoking the BeginAnimation through code as part of the Click event for an autolayout event. This is largely a consequence of the eventing workaround that we need to do on the diagram surface, however. We would probably move this code into XAML if we could do it exclusively through DPs. |
|
|
Hello Scott, Sorry for the late reply. This may be too late to be useful to you, but I've updated the FlowDiagramModel class to derive from DependencyObject, and this change will be in nightly builds dated 3 June 2009 and above, available from about 1430 GMT. I'd certainly be interested in seeing what you're doing as it sounds pretty cool -- I will drop you a line privately. |
|