One feature that several customers have asked for is the ability for SyntaxEditor to automatically resize itself based on its text contents.  We didn't originally have this feature since it can be time-consuming (relatively speaking) and when editing huge documents, we didn't want to add any performance hits.

That being said, in the upcoming 2014.1 version of SyntaxEditor for WPF, Silverlight, and WinRT/XAML, we have added a new SyntaxEditor.IsViewLineMeasureEnabled property that can be set to true to activate view line measure behavior.  This means that you now can use SyntaxEditor in a layout scenario where its measured size will have an effect on its arranged size.

Multi-Line Editing Example

Let's check out an example of this in action.  Here we have a SyntaxEditor that has an XML language loaded and the new view line measure features enabled.  It's resizing itself vertically according to the number of lines in it:

Now if we press Enter a couple times, it auto-sizes to a larger height:

You can see how this would be useful when SyntaxEditor is hosted in controls like a StackPanel.

Single-Line Editing Example

We've also enhanced our single-line edit mode with a neat new feature.  Now if you set word wrap mode on and also have the view line measure features enabled, the single line will grow to render on multiple lines but will still not allow Enter to be pressed or inserted via pastes, etc.

This sort of feature is useful for scenarios where you want to allow a single line snippet of text to be edited but for the entire text to be visible.  Let's have a look:

Above we have a SyntaxEditor in single-line mode, with word wrap on, and view line measure enabled.  Let's type some more text:

Even though the text is still a single line (no line feeds are allowed in single-line mode), the word wrap caused the editor to grow taller.

Summary

These great new features will be available when the 2014.1 WPF, Silverlight, and WinRT/XAML versions are released in March.

Yesterday we announced that a new Metro Light theme is coming to our WinForms Controls in the 2014.1 version.  This new theme was modeled after Visual Studio 2013's appearance and helps give your app a sleeker look.

Differences in Auto-Hide Tab Behavior

In the newer Visual Studio versions, auto-hidden tool windows are represented by a UI element that no longer looks like a tab.  Instead, the "tab" contains the tool window's name with a thick line underneath. 

In this screenshot, you can see the mouse hovering over the Events auto-hide tab:

Another change in Visual Studio is that hovering over the tab no longer automatically shows the tool window in a flyout.  Users must now click to display the flyout.

Our DockManager already has a AutoHideShowOnMouseHover property that can be set to false to achieve that sort of behavior.  For the 2014.1 version, we have enhanced it further.  If the property is false, and a tool window's auto-hide tab is clicked while the related tool window flyout is displayed, the flyout will now toggle closed.  This achieves similar functionality to how Visual Studio 2013 works.

Summary

These additions to give your WinForms app a fresh new Metro look will be available in the 2014.1 version of our WinForms Controls.

We've had metro themes in our WPF control products for over a year now and recently announced that they are getting some very nice updates for their 2014.1, with a number of refinements and enhancements.

Today I'd like to announce that a Metro Light theme is coming to our WinForms Controls as well!  This new theme gives your WinForms apps a Visual Studio 2013-like appearance.

Theme Description

First, we've added an additional option to the WindowsColorSchemeType that is called MetroLight and uses a flat color scheme similar to Visual Studio 2013's look.

Next, we created brand new renderers for our Bars, Docking/MDI, and Navigation products that draw the controls using the Metro appearance.  SyntaxEditor and Wizard already look good in Metro Light with their existing renderers.

Here's the Bar Controls demo, showing off the new theme:

Notice how the entire window has a nice flat appearance and subtle touches like the dotted gripper title bars are included.

Summary

This great theme addition to give your WinForms app a fresh new Metro look will be available in the 2014.1 version of our WinForms Controls.

The past couple days, we've been working on enhancing our popular Metro Themes, mostly focusing on refinements and improvements to their use in our Docking/MDI product.

Our Metro Light, White, and Dark themes have been available since v2012.2 and not only theme the Actipro controls you use in your projects, but also can theme all the native WPF controls.  This allows your entire app to mesh together cleanly with a polished, professional appearance.

Theme Updates

Let's dive in and take a look at some of the updates that are coming.  First, here's a screenshot of our main Docking/MDI demo with the updated Metro Light theme:

Improvements include:

• Lighter dock site background that blends better with the window background.
• Subtle outline borders around the tabbed MDI and tool window containers.
• Tool window container title bars are no longer as in-your-face when not focused.
• Tool window container title bars now have a dotted region that help relay that they are grippable.
• New auto-hidden tool window tab appearance that is more like Visual Studio 2013.
• Tool window tab images hidden by default in Metro themes (but can be toggled back via a new option).
• Slightly lighter control backgrounds in Metro Dark theme.

Here's the same window in our Metro Dark theme:

Summary

Our feature rich Docking/MDI product, combined with our enhanced Metro themes, really provide sleek and clean docking window functionality for your WPF apps.  You won't beat the attention to detail that our themes provide.

These new features will be available in the 2014.1 version of Docking/MDI.

SyntaxEditor for WPF has a free add-on included with it that provides integration with ANTLR 3.4 parsers. The add-on is described in detail in this blog post from several years back.

What is ANTLR?

ANTLR, ANother Tool for Language Recognition, was created by Terence Parr and is one of the most widely-used parsing frameworks available.  ANTLR is a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions containing actions in a variety of target languages. ANTLR provides excellent support for tree construction, tree walking, translation, error recovery, and error reporting.

SyntaxEditor for WPF customers know that we also have our own LL(*) Parsing Framework that has a lot of benefits over ANTLR, but due to the general popularity of ANTLR, we are pleased to support it as well.

ANTLR v4

In the past few months, ANTLR v4 was released.  There is updated tooling for Visual Studio that allows ANTLR v4 parsers to generated.  The thing is that the entire infrastructure of ANTLR parsers has changed in v4, and with those breaking changes, it prevents our add-on from working.

In ANTLR v3, you could run the parser on the document text via our add-on (and in a worker thread so it doesn't block the main UI thread), and it would return the AST results of the parsing operation asynchronously when it completed.

In ANTLR v4, the parser is not the same as there is no automatic AST generation.  Parse results can be examined via the use of the visitor pattern or a parse tree walker.  If you wish to have your own AST, you have to roll your own and construct it using a visitor or walker.  This change negates a lot of the features our add-on provided since now, you basically must hand code an IParser service to install on your language.  SyntaxEditor is fully extensible for any custom parsers, so this can be added easily.  It's just that whatever code you need to do to generate an AST or other parse data by walking the parse tree must now be custom written.

What Do You Want?

We are writing this blog post to see what you, our customers, would like to see from us in terms of ANTLR support.  Do you still wish to have our add-on support ANTLR v3 as we move forward? 

The only piece that is really useful from our ANTLR add-on when used with the newer v4 design is the ICharStream implementation that allows the parser to directly read from our text storage facility.  Since it's only one class, do we just include it open source somewhere or make a separate v4 binary with it in there?

We'd love to hear your thoughts… Please comment below or email our support address!