We’ve been hard at work on some very major new Docking/MDI for WPF features that will be coming in the WPF Studio 2009.2 release.  In this post I’d like to give a quick preview of some enhancements: floating documents, maximizing rafting windows, and custom rafting window chrome.

Here is a screenshot showing the new enhancements:

VS 2010-like floating documents

The biggest new feature is the ability for tabbed documents to be able to be dragged outside of the MDI area into a floating state, where they can be placed on a second monitor if desired.  In the screenshot, the WelcomeDocument.rtf docking window is a document window.  It can be docked anywhere in the tabbed MDI area or can be floated such as it is shown.  Note the document’s icon even appears in its titlebar.

Maximizing rafting windows

Rafting windows are containers for docking windows that are in a floating state.  Now all rafting windows can have the ability to toggle between maximized and restored states.  You can see the maximized button on each of the rafted windows in the screenshot.

Custom chrome for rafting windows

All rafting window titlebars and borders in version 2009.2 will have a custom chrome that matches the current application theme.  In the 2009.1 version, rafting windows let the system draw the titlebars and borders.  By having the rafting windows be themed, they truly match the application’s theme.  This is especially useful for our built-in themes like the Office blue, silver, and black ones.  The rafting window in the screenshot that contains the Solution Explorer and Class View shows the new chrome, in this case for Aero theme.

Release timeframe

We have one more WPF Studio 2009.1 maintenance release planned for the coming weeks.  After that we will prepare for the first WPF Studio 2009.2 release, which will contain all the functionality described here.

Remember that if you purchase WPF Studio 2009.1 now, you will get the 2009.2 version free when it is released since all WPF Studio license purchases come with a year of free upgrades to new versions.

One highly requested feature for SyntaxEditor for WPF is the ability to be notified when a mouse hover occurs so that IntelliPrompt quick info tips can be displayed in response.  Since WPF doesn’t include a mouse hover event, we implemented one ourselves that fires for editor views.

We didn’t stop there though.  We wanted to make it simple for a language to provide quick info popups in response to mouse hover events.  Thus we came up with the new IQuickInfoProvider service.  This service can be registered with a language.  It has three methods on it:

   1: object GetContext(IHitTestResult hitTestResult);

   2: object GetContext(IEditorView view, int offset);

   3: void RequestSession(IEditorView view, object context, bool canTrackMouse);

We offer a QuickInfoProviderBase abstract class that should be used as a base class for any implementations of IQuickInfoProvider that you create.  QuickInfoProviderBase fully implements mouse tracking such that when a mouse hover occurs over an editor view, it calls the GetContext overload that accepts an IHitTestResult.  The IHitTestResult comes from our previously-discussed hit testing feature.  The default implementation of this overload is to call the other GetContext overload if the hit is over a character in the text area.

The GetContext methods should return some object that gives detail about what is at the specified hit or offset, or a null reference if it is not important.  This could be some object as simple as an IToken or some more complex context object.  The important part is that it supports value equality (Equals method implementation) since as the mouse moves, the context returned by GetContext is compared against the context of any already-open quick info session to see if the existing session should be closed or kept open. 

By using GetContext, the quick info provider knows when the mouse moves outside of the the region that is appropriate to an already-open quick info session, and when to open a new quick info session.  Once a new quick info session is needed, the RequestSession method is called.  It is passed the editor view instance, the context object returned by GetContext, and whether the mouse should be tracked (false when quick info is displayed in response to a toolbar button click for example).

Your RequestSession implementations are expected to create a new quick info session, store the passed context in the session, generate content for the quick info popup, and open the session (display the popup).

By using this new provider mechanism, it’s very easy for languages to automatically support quick info display with a minimal amount of work.  All the mouse handling is done for you.  This feature will be in the next build and we’ve updated our quick info sample to show how easy it is to use.

The next build of SyntaxEditor for WPF will have a number of new properties added to the SyntaxEditor control that let you configure the caret and selection brushes used in the control:

• CaretBrush
• SelectionBackgroundActive
• SelectionBorderActiveBrush
• SelectionBackgroundInactive
• SelectionBorderInactiveBrush

We’ve also built a new QuickStart showing how easy it is to change colors and give your editor a truly unique look.

These sort of features will also be available in the upcoming Microsoft .NET 4.0 release for common controls such as TextBox too.  See this post for caret brush details and this post for selection brush details.

With these new features in SyntaxEditor, you’ll be able to ensure your SyntaxEditor caret and selection brushes match those of the other native WPF controls, even when you create custom themes.