As mentioned in this previous post, we've been looking for ideas to further improve our WPF Docking/MDI product, which already is the market leader for docking tool window and MDI functionality.  We've committed to working on a complete internal restructuring of the product that we will call Docking/MDI vNext.  We're doing our best to keep the same general API surface, while providing even more advanced features in every area of the product.  We've collected suggestions from our customers over the past several years and are working to meet them as best we can with Docking/MDI vNext.

In today's post, I'd like to discuss a feature that has been requested by customers: tool window container title bar customizations.

Feature Description

There have been certain scenarios where a customer has wanted to add custom buttons or content into the tool window container title bar.  In the past, you could achieve this by making a clone of the ToolWindowContainer style/template and altering it to include your custom UI in the title bar area.  This works but is tedious and we wanted to make this sort of thing very easy to do for vNext.

In vNext, each ToolWindow now has a ContainerTitleBarContentTemplate property that can be set to a DataTemplate to show in the tool window container title bars.  This can be a button, a label, or any other UI element you can think of.

Usage Example

In this animated example, we show three auto-hide windows.  Each has custom content in the title bar.  The "Preview" tool window has a search button that renders with the same style as the other buttons.  The "Label" tool window has a status label in the title bar that currently says "Status" but could be data bound to a property. 

The "Status" tool window shows a custom circle indicator that says whether the "Is Approved" CheckBox is checked.  When the CheckBox is toggled, it updates a value in the tool window's data context and the indicator changes to another color.

As a bonus, we're also showing how custom content can be injected into auto-hide tabs.  The indicator for the "Status" tool window also appears there and updates live as well.

Summary

These are just some of the really advanced features we're adding to the product for vNext.

Docking/MDI vNext is currently still in early development stages but is progressing very well.  Please contact us via email if you are an existing customer and would like to sign up as a beta tester for vNext.  If you have any other suggestions for improving Docking/MDI, now is the time to get them in.  We'll post more updates on our vNext improvements soon.

In the meantime, please download our current Docking/MDI control product and give it a spin.

As mentioned in this previous post, we've been looking for ideas to further improve our WPF Docking/MDI product, which already is the market leader for docking tool window and MDI functionality.  We've committed to working on a complete internal restructuring of the product that we will call Docking/MDI vNext.  We're doing our best to keep the same general API surface, while providing even more advanced features in every area of the product.  We've collected suggestions from our customers over the past several years and are working to meet them as best we can with Docking/MDI vNext.

In today's post, I'd like to discuss a feature that has been heavily requested by customers over the years: docked size constraints.

Feature Description

In the current Docking/MDI product, there is a minimum size that docked tool windows can become but it is hardcoded.  We've had customers request the ability to configure a minimum size for certain tool windows.  Other customers have also requested the ability to set a maximum size.  Yet others would like to see fixed size tool windows.  None of those scenarios are currently supported.  Docking/MDI vNext changes that.

In Docking/MDI vNext, you're able to optionally specify minimum and maximum docked sizes for each tool window.  We've written a lot of complex logic to support this feature in our layouts.  As the DockSite changes size, the tool windows all reflow and do their best to adhere to the docked size constraints that have been given.  It works very nicely.

Want to have a fixed size tool window?  This can be achieved by simply setting the minimum docked size to be the same as the maximum docked size.

Best of all, splitting (also reimplemented for vNext) is fully aware of the constraints and won't let you drag splitters beyond what the the size constraints allow.

Usage Example

Let's have a look at how constraints work with splitters.  In the screenshot below, I've turned off live splitting so that we can see the splitter drag highlights.  In this layout, the Properties tool window has a minimum docked size constraint set.

As the mouse drags the splitter upward, you can see how the class view is allowed to become very short and the splitter is still tracking with the mouse.

Later, the mouse is dragging downward but the splitter has reached the point where the minimum constraint of the Properties tool window is.  Thus the mouse cursor is down below the splitter (I kept moving the mouse down), showing that the splitter can't go any further in that direction.

Summary

This is a great feature that we've spent a lot of time on for Docking/MDI vNext.  vNext is currently still in early development stages but is progressing very well.  Please contact us via email if you are an existing customer and would like to sign up as a beta tester for vNext.

If you have any other suggestions for improving Docking/MDI, now is the time to get them in.  We'll post more updates on our vNext improvements soon.

In the meantime, please download our current Docking/MDI control product and give it a spin.

We've had a lot of customers throughout the years ask us for a sample that could show how to harness our SyntaxEditor .NET Languages Add-on and its automated IntelliPrompt within an ASP-style server tag context.  This is especially useful for any sort of template generating scenario.

We had an internal sample that we would send customers upon request, but several months back, we cleaned it up, enhanced it, and added it as a new QuickStart sample.  In this post, let's have a look at the QuickStart sample that was added to the SyntaxEditor for (WPF, Silverlight, and WinRT/XAML platforms) in the 2014.2 version showing how to achieve automated IntelliPrompt within ASP-style server tags.

Usage Example

In the animated presentation below, you can see how there is a basic parent language whose lexer only knows to tokenize and color the word "date" as a keyword.  In real-world usage, the lexer could be made to fully colorize the text like normal.  The lexer has hooks that cause a transition to the C# language found in our .NET Languages Add-on when ASP-style delimiters are encountered.

Both <% %> and <%= %> style tags are shown in this example.  What happens behind the scenes is that the parent language's parser will code generate C# code.  It will make a C# class named "__Generated" and a method named "__WriteOutput".  All the text of the parent language is output within "Response.Write" method calls.  C# code in the server tags is injected directly.  The resulting full C# code is placed in a separate in-memory document and parsed.  Finally the resulting parse data is returned, along with mapping data to know how offsets between the server tag range in the source document and those in the parsed C# document align.

Then there are several customized C# IntelliPrompt providers that know how to use that mapping data and translate offsets so that automated IntelliPrompt is fully functional within the server tag regions of the main source document, yet based on the generated C# code.

Tricky stuff, but it works great!

Summary

The full source sample described above was added in the first v2014.2 release of our WPF, Silverlight, and WinRT/XAML controls and is available for you to check out.

Let's have a look at a new feature that came to the advanced XML language for SyntaxEditor for WPF (via its Web Languages Add-on) in the latest 2014.2 maintenance release: the ability to auto-complete XML end tags.

Feature Description

The advanced XML language already has auto-end tag insertion features that occur as you type the > character at the end of a start tag.  In that scenario, the end tag is inserted immediately after the caret.  There are other times where you have deleted some text that may include an end tag that you wish to type back in again.

Say that you are editing a block of XML and start to type an end tag.  After typing the < character, the completion list will contain an item for closing the nearest open ancestor element (if any):

In the example above, you can see the "/colors" item in the completion list and how selecting it auto-completes the end tag.

End tag auto-completion also works if you put the caret after a </ and press Ctrl+Space, as in this example:

In the example above, Ctrl+Space is pressed at the caret's location to auto-complete the "colors>" text.

Summary

The features described above were added in the latest v2014.2 maintenance releases of our WPF Controls and are available for use.

Feature Description

SyntaxEditor documents have always had the ability to be fully read-only and developers can also can cancel specific text change events for more fine-grained control. That being said, there are many cases where developers want to have an easy way to tell SyntaxEditor that a certain of text should not be editable by the end user.  That's where read-only regions come into play.

Read-only regions are implemented using our powerful tagging mechanism.  There is a new IReadOnlyRegionTag interface (with related ReadOnlyRegionTag implementation class) that can be used to mark read-only regions.  Getting going is as easy as tagging a text range using an instance of that class.

Best of all, the ReadOnlyRegionTag class also implements IClassificationTag, which associates the tag with a classification type for read-only text and gets styled with a silver background.  Of course this is fully customizable if you wish to have a different appearance, or no appearance difference at all.

When the end user attempts to edit anything that would cross within a read-only range, the text change will realize that it intersects a read-only range and will cancel.  The text range protected by the read-only region remains unchanged.

This is a very handy feature for certain scenarios and was highly requested by our customers.

Summary

The read-only region features described above were added in the latest v2014.2 maintenance releases of our WPF, Silverlight, and WinRT/XAML controls and are available for use.