LightSpeed

• Fixed an issue where auto through entity tables were not created during database sync if the source was a STI derived entity
• Added a check for the Client Profile when creating a new LightSpeed model

WPF Diagramming

• Fixed DiagramPrinter printing nodes whose elements had been set to invisible

We’d like to remind customers that most of the Mindscape crew will be at TechEd New Zealand for the first three days of next week and this is likely to impact forums support. Please be patient — we’ll respond to posts when we can.

LightSpeed

• Improved DTO guidance sample
• Added batch insert support for Amazon SimpleDB
• Fixed a couple of cases that could cause “unresolved identifier” alias errors in generated SQL

WPF Elements

• Added controls for single-day display — see the multiple schedule sample here
• Fixed an issue where TimePicker wasn’t showing the current value

WPF Diagramming

• Fixed an issue where printing wasn’t respecting node elements being hidden

As always, these fixes and enhancements are in the current nightlies — free and trial editions from the downloads page, retail editions from the store.

LightSpeed

• Now you don’t even need to leave the designer to get your database created. If the designer can’t find the database when you try to do an Update Database, it will now offer to create it for you — if you’re on SQL Server, MySQL or PostgreSQL, anyway. Let us know if you want this feature for other databases too. (Except Oracle. If you want it for Oracle… please don’t let us know.) Rumours that the next version of the designer will download and install the database software for you are greatly exaggerated.
• Fixed an error with client-side boolean literals.
• Fix for an error when projecting a property declared in a derived class when using class table inheritance.
• Fixed an issue where discriminators were not respected when joining to a derived class.
• Beta support for the SQL Server Compact 4 CTP. This requires an additional assembly reference: see here for instructions. At the moment, this is only runtime support: there’s no designer integration. Of course you can still use designer-built models with the LightSpeed runtime, you just won’t be able to do database sync or migrations.
• Ninja association support, or ‘cross-cutting composite keys’ as they are more prosaically known. We’ll post more about this later, but if you can’t wait, see here for the details.

WPF Property Grid

• Fix for an exception when editing a subnode in a collection when the collection contains expandable structs.

Don’t forget the WPF Elements 3.0 beta is now available to existing property grid customers. This contains some changes to the property grid so check it out sooner rather than later!

WPF Flow Diagrams

• We’ve added some hooks to make it easier to serialise custom connections. Here’s a sample.

All these features and fixes are available in current nightly builds — get free and trial editions from the downloads page, or retail versions from the store.

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.

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.

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.

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!

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 :-)

The standard DiagramNodeElement style uses a simple black colored Resizer, and blue gradient filled connection points as seen in below.

The best place to start is by copying the standard DiagramNodeElement style. Below I have provided the style used in the WPF Flow Diagrams product.

<Style x:Key="NodeStyle" TargetType="{x:Type ms:DiagramNodeElement}">
    <Setter Property="FocusVisualStyle" Value="{x:Null}" />
    <Setter Property="Template">
      <Setter.Value>
        <ControlTemplate TargetType="ms:DiagramNodeElement">
          <Grid Canvas.Left="{TemplateBinding Left}" Canvas.Top="{TemplateBinding Top}">
              <ms:MoveThumb Element="{Binding RelativeSource={RelativeSource TemplatedParent}}" 
                             Focusable="True" Clip="{TemplateBinding Geometry}"
                             Style="{StaticResource {x:Static ms:MoveThumb.InvisibleStyleKey}}" Cursor="SizeAll" Name="Mover" />
            <ms:Resizer Element="{Binding RelativeSource={RelativeSource TemplatedParent}}" Name="Resizer" />
            <ContentPresenter Name="ContentPresenter" />
            <ms:ConnectionPointThumb ConnectionPoint="{Binding Content.DefaultConnectionPoint, RelativeSource={RelativeSource TemplatedParent}}"
                                        Width="{Binding ActualWidth, RelativeSource={RelativeSource TemplatedParent}}"
                                        Height="{Binding ActualHeight, RelativeSource={RelativeSource TemplatedParent}}"
                                        IsHitTestVisible="False" Focusable="True" Visibility="Collapsed"
                                        Name="Connector" Style="{StaticResource {x:Static ms:MoveThumb.InvisibleStyleKey}}" />
            <ItemsControl ItemsSource="{Binding Content.ConnectionPoints, RelativeSource={RelativeSource TemplatedParent}}" 
                          ItemTemplate="{StaticResource ConnectionPointTemplate}"
                          Name="Connectors"
                          Visibility="{TemplateBinding ShowConnectionPoints, Converter={StaticResource bvc}}">
              <ItemsControl.RenderTransform>
                <TranslateTransform X="{Binding (Canvas.Left), RelativeSource={RelativeSource TemplatedParent}, Converter={StaticResource Negative}}"
                                    Y="{Binding (Canvas.Top), RelativeSource={RelativeSource TemplatedParent}, Converter={StaticResource Negative}}" />
              </ItemsControl.RenderTransform>
              <ItemsControl.ItemsPanel>
                <ItemsPanelTemplate>
                  <Canvas />
                </ItemsPanelTemplate>
              </ItemsControl.ItemsPanel>
              <ItemsControl.ItemContainerStyle>
                <Style>
                  <Setter Property="Canvas.Left">
                    <Setter.Value>
                      <MultiBinding Converter="{StaticResource CPX}">
                        <Binding />
                        <Binding Path="Formatter.Layout" RelativeSource="{RelativeSource AncestorType={x:Type ms:DiagramSurface}}" />
                        <Binding Path="Position" />
                      </MultiBinding>
                    </Setter.Value>
                  </Setter>
                  <Setter Property="Canvas.Top">
                    <Setter.Value>
                      <MultiBinding Converter="{StaticResource CPY}">
                        <Binding />
                        <Binding Path="Formatter.Layout" RelativeSource="{RelativeSource AncestorType={x:Type ms:DiagramSurface}}" />
                        <Binding Path="Position" />
                      </MultiBinding>
                    </Setter.Value>
                  </Setter>
                </Style>
              </ItemsControl.ItemContainerStyle>
            </ItemsControl>
          </Grid>
          <ControlTemplate.Triggers>
            <Trigger Property="IsSelected" Value="False">
              <Setter TargetName="Resizer" Property="Visibility" Value="Collapsed" />
            </Trigger>
            <Trigger Property="IsResizable" Value="False">
              <Setter TargetName="Resizer" Property="Visibility" Value="Collapsed" />
            </Trigger>
            <DataTrigger Binding="{Binding IsReadOnly, RelativeSource={RelativeSource AncestorType={x:Type ms:DiagramSurface}}}" Value="True">
              <Setter TargetName="Resizer" Property="Visibility" Value="Collapsed" />
              <Setter TargetName="Mover" Property="Visibility" Value="Collapsed" />
              <Setter TargetName="Connector" Property="Visibility" Value="Collapsed" />
              <Setter TargetName="Connectors" Property="Visibility" Value="Collapsed" />
            </DataTrigger>
            <DataTrigger Binding="{Binding CanModifyConnectivity, RelativeSource={RelativeSource AncestorType={x:Type ms:DiagramSurface}}}" Value="False">
              <Setter TargetName="Connector" Property="Visibility" Value="Collapsed" />
              <Setter TargetName="Connectors" Property="Visibility" Value="Collapsed" />
            </DataTrigger>
            <MultiDataTrigger>
              <MultiDataTrigger.Conditions>
                <Condition Binding="{Binding Path=(ms:CursorAction.Current), Converter={StaticResource CursorActionTypeConverter}, RelativeSource={RelativeSource AncestorType={x:Type ms:DiagramSurface}}}" 
                           Value="{x:Static ms:CursorActionType.CreateConnection}" />
                <Condition Binding="{Binding IsReadOnly, RelativeSource={RelativeSource AncestorType={x:Type ms:DiagramSurface}}}"
                           Value="False" />
              </MultiDataTrigger.Conditions>
              <Setter TargetName="Mover" Property="IsHitTestVisible" Value="False" />
              <Setter TargetName="Connector" Property="IsHitTestVisible" Value="True" />
              <Setter TargetName="Connector" Property="Visibility" Value="Visible" />
            </MultiDataTrigger>
          </ControlTemplate.Triggers>
        </ControlTemplate>
      </Setter.Value>
    </Setter>
  </Style>

Â
Phew! That’s a lot of XAML! Good news though – you only need to tweak parts of it to start styling your own nodes.

After modifying the parts of the style that you need to customize, you then need to tell the DiagramSurface that this is the style you want to use. This is easily done by setting the NodeStyleSelector property of the IDiagramFormatter that you give to the DiagramSurface. If you wanted to use your style on all the different types of nodes in a diagram, then you would use the following code.

<ms:FixedStyleSelector x:Key="{x:Static styles:GradientStyle.NodeStyleSelectorKey}" Style="{StaticResource NodeStyle}" />

So why make your own node element style?

The node element style is the best way to incorporate your own SizeThumb and ConnectionPointThumb styles on your nodes. This is done simply by making your own style for these thumbs, and then setting them on the appropriate controls found within the node element style. This allows you to achieve the effects in the following images.

Changing the color of the Resizer, and only including the corner thumbs.

Changing the look of the outbound connection point thumbs to have a transparent green fill.

Another useful tip with creating your own node styles is to add MouseDoubleClick or MouseRightButtonDown event handlers to the MoveThumb within the style. This will allow you to define appropriate actions to occur when the user double clicks or right click on a node. And since the MoveThumb in the standard node style is the most exposed control, it is the best place to attach such event handlers.

Node element styles are not limited to being applied to all the nodes in a single diagram. By using a TypeStyleSelector instead of a FixedStyleSelector, you can have some types nodes with different colored connection points compared to other nodes. Or some nodes could have the standard Resizer, while other nodes use a Resizer that only allows nodes to be square shaped.

Need any help with making your own node element styles? Drop a comment on this blog or put a post up on the forum. We’d love to hear from you!

Want to play with WPF Diagrams? Download the free trials of WPF Flow Diagrams or WPF Star Diagrams.

Say we want to design a node representing some kind of intersection in a network. The intersection has input flows and output flows. Each input and output connection should have its own connection point to make it easier to follow the diagram, rather than having all the connections bunched up on one point. To make it flexible for the user, we want to be able to have a variable number of connection points on the node. Hence we want to be able to dynamically add and remove connection points from instances of this node.

Here is how we go about implementing such a node:

1. We start by creating a new class that extends from FlowDiagramNode.

2. Include an ObservableCollection<IDiagramConnectionPoint> field to hold all the connection points. I’m calling this _connectionPoints.

3. In the constructor, we setup all the initial connection points on this node, and add them all to the observable collection as follows:

public SampleNode1()
{
    _connectionPoints = new ObservableCollection<IDiagramConnectionPoint>();
 
    _connectionPoints.Add(new InboundConnectionPoint(this, Edge.Top));
    _connectionPoints.Add(new OutboundConnectionPoint(this, Edge.Bottom));
}

4. Now we want to override the FlowDiagramNode.ConnectionPoints property to return the observable collection.

5. As both outbound and inbound connection points are stored in the same collection, we need to implement the InboundConnectionPointsCore and OutboundConnectionPointsCore properties in a way that looks through our observable collection and picks out the appropriate points to return. One way to do this is as follows:

protected override IList<InboundConnectionPoint> InboundConnectionPointsCore
{
    get
    {
        List<InboundConnectionPoint> result = new List<InboundConnectionPoint>();
        foreach (IDiagramConnectionPoint point in _connectionPoints)
        {
            InboundConnectionPoint p = point as InboundConnectionPoint;
            if (p != null) { result.Add(p); }
        }
        return result;
    }
}

6. Done!

Connection points can now be freely added or removed from the observable collection which results in dynamic connection point creation and deletion at the graphical layer. Note that the above code simply illustrates how to get dynamic connection point creation and deletion working, some more logic is required to specify when exactly the connection point collection is modified. How you add and remove connection points is up to you as it’s likely application specific. You could allow there to always be 1 unused connection point available on a node by adding or deleting connection points when connections are made or removed from the node. Or you could have a control somewhere in your application or on the node itself which the user can use to specify the number of input and output points.

Here are a couple of screenshots of one possible way dynamic connection point creation could be implemented. First we have network intersection node with one input point on the top, and one input point on the bottom as its initial state.

When the user introduces an input flow to the connection point on the top, a new  input point can be added to the node as seen in the next screenshot. This will allow additional inbound connections being introduced by the user if necessary.

The WPF Diagramming products support this type of customisation because we know that nearly every application will require something different. Need to have a minimum or maximum number of connections? No problem – do whatever you require!

If you want to create some amazing diagrammatic visualizations with WPF then check out our WPF Flow Diagrams or WPF Star Diagrams products.