As mentioned in one of our previous posts, we’ve been working on a port of our SyntaxEditor Web Languages Add-on from WinForms to the WPF version of SyntaxEditor.  We’re finishing up some last features on it before it will be ready to launch alongside WPF Studio 2010.2 in the coming weeks.

The advanced XML syntax language implementation in the add-on allows you to specify XML schemas to use for validation and to drive automated IntelliPrompt for the end user.  In the previous post on the subject we showed how to create an XHTML editor in a few lines of code with automated IntelliPrompt popups.

One feature we just implemented was the ability to properly support xs:any nodes defined in the XML schemas.  xs:any allows a schema to indicate that elements from any, other, or specific namespaces can be included as content within another element.

Best of all, we ported this new functionality back to the WinForms Web Languages Add-on too!

Let’s see an example…

Here is the WPF SyntaxEditor showing an XSLT document loaded.  The XSLT is doing a transform to HTML.  In the screenshot the mouse is over the xsl:value-of element, showing a quick info tip.  Now let’s start typing a new start tag…  More...

We’ve just sent out our July 2010 newsletter to subscribers and have posted it online as well in case you are not a subscriber.

You can view the newsletter online via this link:

• View newsletter

We list our development plan for the next several months at the end of the newsletter in its What’s next? section.

We’ve just released new SyntaxEditor for WinForms and UIStudio for WinForms maintenance releases the other day.  The new SyntaxEditor build has numerous functionality updates, adds three new sample languages (C, C++, and RTF), and improves the .NET Language Add-on’s automated IntelliPrompt in Visual Basic.  Enjoy!

We’ve started some work on doing updates to what are known as “dynamic languages” in SyntaxEditor 4.0.  These languages allow you to define a lexer in terms of explicit and regular expression pattern groups and make it very simple to get syntax highlighting working fast.

In the next-generation framework we’re prototyping out with the WPF version of SyntaxEditor, we’ve renamed these to be called “dynamic lexers” instead, since for the most part, they just control how the lexer tokenizes and highlights text.  Thus they can really be used with any language.

Anyhow, while we’re pretty happy with the XML format for defining dynamic lexers right now, we’d love to get additional input on new features you’d like to see or ideas for improvement.  Please post your comments or email them over.

As we move forward on new features for SyntaxEditor for WPF, the next feature area we’ve been focusing on is adding core support for triggering syntactic/semantic parsing (commonly called “parsing”) following document text changes.  SyntaxEditor for WinForms has a very nice system for this that allows a worker thread to perform the parsing operations and then report back to the document when complete.  It’s a core item for getting advanced IntelliPrompt features such as those found in our .NET Languages Add-on working.

Parsing can take time to perform since you generally use the phase to build a tree-based model of the document via an abstract syntax tree, along with performing syntax checking.  More...

On Friday we released new builds of all our WinForms / ASP.NET products.  The big updates were some enhancements to the renderer management framework that is used primarily in UIStudio and SyntaxEditor.  All the controls in these products would attach to an event on the renderer they used (typically a default global renderer) that told them if a renderer property was modified.  This way the control instances would know when to redraw themselves.  The problem was that sometimes even after a control was done being used, unless you called Dispose on the control (which forced removal of the event tie), the control may still be retained in memory due to this event tie. 

What we did in this new build is update our renderers to support a weak event pattern.  All the controls now use that pattern, meaning that the event tie will no longer keep the controls in memory, thus helping prevent against any possible memory leak scenarios.

We’ve had a lot of requests lately for improved support when using any sort of interop control (generally WinForms-based) within our Docking & MDI for WPF product.  In should be noted that interop content may also include things like DirectX content, etc.

The main problem is this, WPF renders any interop content on top of WPF content on the same root window.  The issues are described lower down in this topic:

http://msdn.microsoft.com/en-us/library/ms742522.aspx

In addition to the content rendering issues in WPF, there are some focus handling issues when dealing with interop controls.

What are we doing about it?

We have begun moving forward with finding ways to work around the above issues.  Today I’d like to talk about a new workaround included in build 482 that was just released.

One major issue with Docking & MDI was that auto-hide flyouts would appear below interop content that was located in the MDI area.  I’m happy to say that we’ve come up with a new property on DockSite that helps with this particular issue.

By setting the new DockSite.UseHostedAutoHidePopups property to false, you can now achieve auto-hide flyouts that appear above interop content.  In the screenshot above, you’ll notice a WPF tool window flys out on top of documents that contain a SyntaxEditor for WinForms control instance and a WinForms WebBrowser control instance.

We recommend that if you do not host WinForms content in your documents, you should still keep DockSite.UseHostedAutoHidePopups its default value of true.

This was very tricky to implement and is a major step forward for the product!

Moving forward

We still have some more areas to work on.  It’s likely that the next area will be a workaround so that the dock guides (when dragging a window) will appear on top of interop content.  Stay tuned!

As of today’s releases of our Windows Forms products, we have dropped support for VS 2003 projects and .NET 1.1 builds of our component libraries.  At this point, VS 2008 has been out for some time and anyone doing Windows Forms development should be on .NET 2.0 or later.

The latest maintenance releases now have both Visual Studio 2008 and Visual Studio 2005 sample projects included.

All the component libraries are built targeting .NET 2.0.  Please note that libraries that target .NET 2.0, can be used in any later .NET framework as well, such as .NET 3.0 or 3.5.

We just released build 276 of SyntaxEditor and its add-ons.  This build has more general tweaks and bug fixes, along with some major updates to the IntelliPrompt capabilities for C#/VB via the .NET Languages Add-on.

Here are some of the major new updates.  There are a lot of small enhancements in IntelliPrompt across the board as well.

Anonymous Types

IntelliPrompt now works for anonymous types.  It will construct a type definition behind the scenes that contains the properties you specify and will use that type definition for constructing IntelliPrompt UI.

In the screen above, both abc and def are implicitly defined anonymous types.  You can see how SyntaxEditor correctly identifies the Now property on the abc anonymous type as a DateTime.

Extension Method Application

We have really enhanced the way that we determine which extension methods are applied to various types.  In previous builds there were a number of cases where extension methods could be applied to inappropriate types.  With our new code updates, the add-on attempts to resolve the parameters down to really determine if an extension method applies to a type, even if the type is a complex generic one.

In the screen above, note how the AGoodTextExt extension method appears in the member list, while ABadTestExt does not since the latter is for enumerable int objects, not enumerable char objects.

Extension Method Quick/Parameter Info

The code updates also include some more updates to the quick and parameter info that is displayed for extension methods.  It will attempt to resolve the generic parameters into their "real" types for display to the end user.

In the screen above, the quick info used to say IEnumerable<T> in previous builds, but now says IEnumerable<int>.  We will be making other improvements in this area in the future.

Implicit Variable Declarations in VB

While our C# implementation has had var support for a while, we now have implicit variable declarations working in VB as well.

In the screen above, SyntaxEditor correctly displays the members for the ApplicationException type since that type was used to initialize the variable var.

One area that we definitely want to improve with SyntaxEditor is the ability to have good response and performance when editing large files.  In SyntaxEditor for WinForms, there are a number of options you can turn off to help improve performance, yet it would would be much better to be able to leave options on and still have decent performance.  Also when editing huge documents, performance should still be considered good, not just satisfactory.

In our newer internal design that we're prototyping out in SyntaxEditor for WPF, we have already started implementing a number of improvements we've been brainstorming on for a long time.  Let's call these new ideas SyntaxEditor Next since after the WPF version is completed, we'll probably be looking at implementing similar techniques in the WinForms version 5.0.

Here is a list of some of the improved areas (let's assume a large document is 10MB in size for these comparisons):

• Document loading - When loading a very large document, it may take 10-15 seconds to load and display in SyntaxEditor for WinForms.  In SyntaxEditor Next, it loads and displays instantaneously.
• Typing performance - When editing a large document in SyntaxEditor for WinForms, there can be a noticeable delay when typing each character.  With our SyntaxEditor Next design, there is almost no noticeable slowdown in typing.
• Word wrap activation - When switching to word wrap mode in SyntaxEditor for WinForms, very large documents might notice up to a several second delay before the switch is complete.  In SyntaxEditor Next, the change is instantaneous.
• Word wrap memory - In SyntaxEditor for WinForms, word wrap mode took up a lot of additional memory when working with large files.  In SyntaxEditor Next, it uses almost no additional memory.

The observations above are comparisons made on the same 10MB file with highlighting enabled.

Please note that while SyntaxEditor for WPF (SyntaxEditor Next prototype) doesn't have outlining or semantic parsing implemented yet, to compare apples to apples we turned off outlining and semantic parsing in the WinForms version.  Therefore we are very optimistic that the performance results above can be maintained once outlining and semantic parsing are added to SyntaxEditor for WPF.