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 see you've canvassed for suggestions for your 2.0 diagramming in (http://www.mindscape.co.nz/blog/index.php/2010/06/01/wpf-diagramming-2-0-planning/). I've been using this to develop a fairly complex UI and do have some suggestions you may or may not like to think about. These are all the opinions of my current cup of coffee, and may not represent my employer etc etc. Firstly : Dynamic connection points. You have a demo on how people can implement their own custom multi-connection points, which I've used as the basis for my own implementation. However a more pre-rolled solution would be fantastic. Almost all of the work we're using diagramming for has data-driven numbers of control points. This would include:
Secondly : Performance. The current zsorting implementation doesn't scale to a few hundred nodes with a few more hundred connections. That would be really nice. Those are just off the top of my head. I'll see if I think of anything else as I go along. :) Cheers -d |
|
|
Hello Thanks for the suggestions. I have already made some improvements to the foundation in terms of connection point usage. I will now use the points you mentioned here to make even further modifications. For your "Node Style Templates driving connection points" suggestion, if you could post an example image or a deeper description of how you would like to be able to do this then that would be great. Thanks again and keep the suggestions rolling in. Cheers |
|
|
Ok, it's convoluted but... My node template looks a little like this: <DataTemplate x:Key="MyNodeTemplate"> each child control might also have it's own named connection points, it doesn't matter. In my UI, users cannot resize nodes vertically, only horizontally. I hook the BoundsChangeRequested event and set the mindscape node's bounds based on querying the size of the actual child controls in the node, hence making the node magically size to whatever it contains (The node displays very different sized controls based on data). The attached property (MyNamespace:MyAttachedPropertyHelper.InputSlotName) meanwhile, hooks the LayoutUpdated event of the visual element it's attached to (in this case the ellipse "decorator") and explicitly sets data on the Node which says where in the layout the ellipse has been laid out. That data is then used by my IPositionCalculator to tell mindscape where the connection physically is. The practical upshot is that wherever WPF lays out the ellipse (which depends on the stackpanel, the other controls, etc), connections to that point are drawn. this means that I can logically draw connections to something inside my row (in the case above, I'm drawing a kind of binary tree, where the node has two inputs - a Child A and a Child B. Thus it's quite important that the little arrow points at the control inside the node representing the correct node. clear as mud?
|
|
|
Yup, clear as transparent mud. Thanks for the detailed description, I'll look into making this more elegant for you to do. In the meantime, any suggestions for how the ideal API for you should look would be handy. Regards |
|