Archive for the ‘WPF Diagramming’ Category

WPF Diagramming 2.0 Planning

Tagged as WPF, WPF Diagramming

We have started work on the next generation of our popular diagramming products and wanted to get some feedback from current users. Let your minds run wild with the possibilities of what would help you build some truly stunning applications with WPF diagramming.

Some of our plans are…

When your powers combine…
Currently we’re retailing two diagramming products – WPF Flow Diagrams and WPF Star Diagrams. We’ll be merging these two into a single “WPF Diagramming” product. Developers have always been able to build far more than just Flow Diagrams and Star Diagrams with the foundation classes so we decided to simplify things and just have one tidy package for all customers. All customers who have active subscriptions to one of the diagramming products will be upgraded automatically to the joint offering of course :-) As an aside, that also means now is the best value time to purchase licenses!

Additional layout options
We’ve always included a force directed layout algorithm and a tree layout algorithm in the Star Diagrams product. We’re now working on making these work seamlessly with other diagram types as well as including several new layout algorithms to create even more attractive diagrams easily. Part of this work includes new path finding algorithms as well, so once the nodes are laid out nicely, you can control what routing algorithm is used to draw the connections between nodes.

More samples
Diagramming is a large domain to be working in and that means creating custom diagrams is not always as easy as you might hope. To help improve the situation for users, we’re planning to ship more samples that provide additional detail on how to achieve certain diagram types, work with custom nodes, configure layouts and path finding etc.

A whole bunch more
Obviously we’re including a slew of smaller feature enhancements and improvements, but what’s most important to us is that we get your feedback on what you would like to see. We’ve had solid feedback since we launched these products which has helped in the incremental improvements, and as we’re actively investing in 2.0 it’s important to hear your latest requests :-)

Never used our diagramming products? Check out WPF Flow Diagrams or WPF Star Diagrams.

Add your comments
Posted by John-Daniel Trask on 1 June 2010

Nightly news, 28 May 2010

Tagged as LightSpeed, News, Silverlight Elements, WPF Diagramming

We’ve not posted a Nightly News for a couple of weeks because we’ve been shipping releases rather than nightlies — see the Silverlight Elements 1.1 and LightSpeed 3.1 announcements. Still, here’s what’s new and not in those releases.

LightSpeed

• We’ve fixed a bug with ordering on group keys that were obtained by traversals.
• We’ve fixed an error that occurred in certain join-and-project scenarios if your entity had a property name that was the same as a property name that could be translated to SQL.
• Fixed a spurious warning relating to a designer option

WPF Diagramming

• Extensibility improvements to the connection remover and relocator
• Fixed a couple of cropping issues in image export

Silverlight Elements

• Resolved an issue relating to the order that properties were set in the Slider and DualSlider when using XAML

We’ve also got work in progress on our WPF Diagramming products and on porting some of the cool new Silverlight Elements controls to WPF. We’ll bring you an update on those as soon as they’re available.

Add your comments
Posted by Ivan Towlson on 27 May 2010

WPF Diagramming: Connection validation and an API change

Tagged as Products, WPF, WPF Diagramming

One important feature that some diagrams need is connection validation. That is, the ability to control which diagram nodes are allowed to be connected together. For example, you might want node A to be connectable only to node B. Or you may want to prevent start nodes being connected to end nodes. Many different diagrams will require their own unique connection validation which is why WPF Diagramming provides a way for you to customize this logic. The two interfaces that you need to consider when providing your own logic is the IDiagramConnectionBuilder and the IDiagramConnectionRelocator. The connection builder contains a method for building a connection and adding it to the diagram, and the relocator has a method for performing the connection relocation. Originally, custom connection validation would be taken place in your own implementations of these methods. A disadvantage of doing it this way is that the user interface is oblivious to this validation. Because of this, the user would only know if a connection can not be made between particular nodes after they let go of the mouse button and find that no connection is created. However, a recent modification to these two interfaces solves this issue. In this blog post we look at this modification that has been made, as well as how to provide your own connection validation logic to your applications.

Connection builder and connection relocator API change.

Both the IDiagramConnectionBuilder and the IDiagramConnectionRelocator now has an additional method that returns whether or not they are allowed to perform their respective actions. The new connection builder method is called CanCreateConnection which has the following parameters:

• IDiagramModel. This is simply the diagram that the new connection is going to be added to.
• IDiagramConnectionPoint. This is the connection point where the new connection is going to originate. Using the Connectable property on this connection point gives us access to the diagram node that the connection will be attached to.
• ConnectionDropTarget. This is a new type of object that contains information about where the user is dragging the end of the connection to.

This method is also called in the situation where the user has just pressed the mouse button on a connection point thumb in preperation to create a connection. This allows you to provide connection validation logic that prevents certain types of connections being made on certain types of nodes. One thing to be aware of is that the ConnectionDropTarget parameter will be null to represent this situation.

The new connection relocator method is called CanRelocateConnection and contains all the parameters as previously mentioned as well as the IDiagramConnection that is being relocated. One thing to note is that the IDiagramConnectionPoint parameter is the connection point that the connection is still attached to, and the ConnectionDropTarget holds information about the end of the connection that the user is dragging.

Custom connection validation logic

Now that we know the basics, lets implement our own connection validation logic for a flow diagram to follow. Our logic will simply prevent any StartNode elements from being directly connected to an EndNode element. We want both our IDiagramConnectionBuilder and IDiagramConnectionRelocator implementations to share the same connection validation logic, so we can write it in a static method as follows:

public static class ConnectionValidationLogic
{
  public static bool ValidateConnection(IDiagramConnectionPoint connectionPoint, ConnectionDropTarget dropTarget)
  {
    bool canCreateConnection = true;
    if (dropTarget != null)
    {
      IDiagramConnectable source = connectionPoint.Connectable;
      IDiagramConnectable destination = dropTarget.Connectable;
      if (source is StartNode && destination is EndNode)
      {
        canCreateConnection = false;
      }
    }
    return canCreateConnection;
  }
}

For our validation logic we will only be interested in the source and destination of the connection. So the only parameters we need for this method is the IDiagramConnectionPoint and the ConnectionDropTarget object. As previously mentioned, the drop target object will be null in a special situation so we include a null check around the rest of our logic. We can aquire the source item of the connection by using the Connectable property on the connection point, and the destination item can be obtained with dropTarget.Connectable. Then all our logic needs to do is return false if the source is a StartNode and the destination is an EndNode. Later when we give this logic to the diagram, we will get the following results:

Here on the left we can see the user is creating a connection from the start node and hovering the mouse over the process node. Our validation logic allows this and so the connection points on the process node are shown. However, when hovering the mouse over the end node, the validation logic notices that this is illegal and so the connection points stay hidden.

Now that we have set up the validation logic, we need to make a connection builder and connection relocator implementation that uses it. We can do this easily by extending the FlowDiagramConnectionBuilder and DefaultDiagramConnectionRelocator classes and overiding the appropriate methods. In the implementation of these methods, we simply make a call to our static validation logic method, and return the result as follows:

public class ValidatingConnectionBuilder : FlowDiagramConnectionBuilder
{
  public override bool CanCreateConnection(IDiagramModel diagram
                                                          IDiagramConnectionPoint fromConnectionPoint,
                                                          ConnectionDropTarget dropTarget)
  {
    return ConnectionValidationLogic.ValidateConnection(fromConnectionPoint, dropTarget);
  }
}

Providing the diagram with the validation logic.

Now all thats left to do is give our custom logic to the diagram. This is easily done by setting the appropriate diagram properties to be instances of our connection builder and relocator classes.

FlowDiagramModel diagram = new FlowDiagramModel();
diagram.DefaultConnectionBuilder = new ValidatingConnectionBuilder();
diagram.ConnectionRelocator = new ValidatingConnectionRelocator();

And thats it!

There are many connection validation scenarios that can be handled in this way. You could prevent certain types of nodes being directly connected to themselves, only allow specific types of connections to be made between certain node types, or even prevent particular diagram node instances from being connected together. If you download the latest nightly build you will find a new project in the flow diagram samples solution called ConnectionValidationSample. The sample prevent StartNodes being connected to EndNodes, DecisionNodes can only be accessed by a StartNode, and data-ProcessNodes can not connect to themselves. Use this to see how it all works and give you ideas to implement your own validation logic.

Try this out if you are in need of custom connection validation. If you are having trouble getting it to work or can’t seem to get the logic right for a certain scenario, then let us know in our forum, or put a comment on this blog post.

Add your comments
Posted by Jason on 13 April 2010

WPF Diagrams: Custom Diagram Node Data

Tagged as WPF, WPF Diagramming

You may know that in WPF Flow Diagrams you can create your own custom node types to hold any additional data that they need. These nodes can be styled however you want, and also can be integrated into the serialization and undo features. This is useful when you want to create your own kind of node to represent a specific process that has its own attributes.

But what if you have various kinds of data objects that you want to be held by any type of diagram node? Or maybe you’re happy with the standard node types that we provide, but want them to hold more data without creating your own node types? Say for example you are creating a diagram where each node represents a task involved in completing a project. You may want each node including start and end nodes to contain text, as well as a list of people responsible for completing the task. Sure, you could create some custom node types that contain this additional data, but it would be nice if we could simply use the node’s Data property to hold any data we need

This has always been possible, but in the past it’s been slightly problematic due to the standard styles and serializer assuming that nodes only hold string content. However, if you download the latest update of WPF Flow Diagrams, you will find it is now easier to allow any kind of node to hold any kind of custom data that you need.

So you have some custom data objects that you want to be held by any node in a diagram. There are 2 main things you need to do: tell the diagram surface how to display the data content of a node, and tell the serializer how to serialize and deserialize your data objects.

Custom node content templates

The IDiagramFormatter interface now contains a property called NodeContentTemplateSelector. This can be set up to select a DataTemplate based on both the type of a diagram node, and the type of data that it holds. So you can have all nodes displaying each type of custom data the same way, or start nodes could display data differently to end nodes. So for each of the different types of node content that you want to display, you need to create a DataTemplate. These data templates will be templating your custom data, so you can have bindings to properties in your data objects to make them look however you want. Set these data templates into whatever data template selector you need, and set the selector into the NodeContentTemplateSelector of the IDiagramFormatter your using.

Here is an example of the effects you can achieve with templating custom node content.
(You can download this sample here to see how it works. Make sure you’ve also downloaded the latest update of WPF Flow Diagrams)

The start node simply contains a string. It gets a default template containing a TextBox where the text is a binding to the Data property of the node.

The next node contains custom data that has a string and an arbitrary object. The template selected for this type of node content displays the string but nothing else. This is useful when you want nodes to store custom data, but don’t want to change the appearance of the node.

The next node contains custom data that has a string and some data that represents a square. The template selected for this type of data displays the string, and also a coloured square. The template could also use attributes from the data to change the apperance of the square. For example its size and colour.

The last 2 nodes are different, but contain the same type of data. I have set up the template selector to use a different DataTemplate depending on the type of node ignoring the fact that the type of data is the same.

Custom node content serialization

Serializing your own custom data objects is fairly straight forward. IFlowDiagramSerializer now has a NodeContentSerializer property. All you need to do is make your own implementation of the new INodeContentSerializer interface. In the serialize method, you are given the data object that needs to be serialized. If you are serializing to XML, you just need to use the given XmlWriter to write any attributes your data objects have. If you have more than one type of custom data object, then you should also write some kind of attribute to the XmlWriter that indicates what type of data you are writing.

Now in the deserialize method, you get an XmlReader, and need to return an object. If you have multiple types of data objects, then you will first want to find out what type of object you are deserializing. This can be done by checking the value of the previously mentioned attribute. When you know what you are deserializing, you can read the values of the attributes that you wrote to XML, and create an instance of your data object based on these values.

If you haven’t tried the WPF Flow Diagrams yet and want to create some very slick looking diagrams then download the trial version now and let us know what you think!

Add your comments
Posted by Jason on 7 January 2010

Improved support options for customers

Tagged as LightSpeed, MegaPack, Products, SimpleDB Management Tools, VS File Explorer, WPF Diagramming, WPF Elements, WPF Property Grid

Hand in hand with our recent volume discounts and LightSpeed 3.0 release we have started to put in place an improved support capability for customers who need priority support options or may occasionally want to escalate support beyond what we normally offer.

Tooting our own horn a little, we have had very positive feedback from many customers who have said our support is fantastic. We hope this addition helps us maintain end user happiness as we continue to grow and our support load scales up.

What is priority support?

Priority support is the option to ensure that your request is dealt with promptly, and is reviewed before and prioritised over normal forum posts. It is also useful for folks who wish to not use the forum which is quite open and may not be viable for talking about sensitive parts of a software system.

Can I use it for feature requests?

No, we still urge that feature requests be posted in the forums so that others may discuss them (and because we don’t think it’s fair to charge you for suggesting cool features!). Features are still only added to products at our discretion.

How much does priority support cost?

We have priced support at $199 USD per priority support issue OR at $499 for a 5 pack of support issues, a 50% saving. You will be able to see if you have support tickets in your store account page. We have been issuing 1 priority support ticket per customer to LightSpeed 3.0 customers and upgrading Enterprise Edition customers. For other products, we’re in the process of migrating Enterprise customers to have a priority ticket added to their account.

The pricing is designed to be very cost effective and is inexpensive compared to the support options offered for other software (for example, one commercial NHibernate support vendor quotes 600 Euro, approximately $870 USD, per incident for ad hoc support).

You can purchase Priority support tickets in our online store.

Do I need it? Should I put all my requests through priority support?

If you need a guaranteed response, or a quick response is crucial to you, or you don’t want to discuss your issue on the public forum, then you should put a request through priority support. The forum will still get monitored actively by Mindscape staff and questions will be answered, but there are no guarantees around response times (our response times have usually been pretty good, but never guaranteed!).

Priority support is for those times when you need additional help and you don’t want to rely on the forums. You are welcome to simply buy a support ticket as you need them for $199 USD however it may be wiser to simply purchase a 5 pack in order to save 50%.

If I’ve missed any questions you have then please post a comment – I’m happy to answer them :-)

Add your comments
Posted by John-Daniel Trask on 15 December 2009