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.

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.

We just released build 275 of SyntaxEditor and its add-ons.  This build has a lot of minor tweaks and bug fixes that have been made over the last 2-3 months.

In addition there have been some major enhancements in the .NET Language Add-on's IntelliPrompt capabilities.

Delegate Improvements

Delegates now have full IntelliPrompt capabilities, just like calling methods.  Note how in the screenshot above, a generic delegate is called and a DateTime value is properly returned as the value.  The member list shows the members of the DateTime return value.

Generic Methods

Generic methods can have their return type defined by the parameter that is passed to them.  In the example above, a field called ADateProp which is of type DateTime, is passed as a parameter to the generic method Echo.  IntelliPrompt correctly recognizes that per the definition of Echo, the return type is also DateTime.

Constructed Types

This feature has been highly requested... IntelliPrompt that functions on a constructed type expression.  In the screenshot above, the Append method's parameter info is displayed, following a new StringBuilder() call.

Beginnings of Lambda Expressions

Lambda expressions are a new concept in the latest C# and VB updates by Microsoft.  In the example above, a member list is displayed for the x variable introduced in a lambda expression.  IntelliPrompt determines that x is a DateTime based on the Func<DateTime, bool> declaration.

Note that not all Lambda expression IntelliPrompt works at this time but we will continue to improve IntelliPrompt in all areas as we move forward.

Enjoy the updates!

The latest build 274 of SyntaxEditor's .NET Language Add-on includes several improvements for generic method support.

First, if you call a generic method (defined as T GenMethod<T>()) passing the generic parameter type like (GenMethod<int>().), the member list that is displayed will be for int.

Second, generic methods on extension methods now resolve types properly as well.  This is especially useful with Linq as you can see in the screenshot above.  Above, ElementAt is a generic extension method defined on Linq's Enumerable class.  The first time it is applied, the string type is returned and the second time it is applied, the char type is returned.

We still have a little more work to do with generic methods but these are some great steps forward!

The latest build of the .NET Languages Add-on released today includes some great new features related to automated IntelliPrompt.

Extension Methods

This build adds IntelliPrompt support for extension methods, a new feature found in C# 3.0 and VB 9.0. 

Extension methods allow you to define new methods on existing types without having to sub-class or recompile the original type.  This means you can add functionality directly to types for which you don't have source code.

In the sample above, note the extension method ToStringExt is defined on the static ExtMethodProvider class.  In the TestMethod, we press "." to show a member list for its Int32 parameter val and that locates the ToStringExt method, including it in the available members for the Int32 parameter.

Extension methods can be defined in compiled assemblies or in code as above.  The most common use of extension methods is with LINQ.

Delegates

The latest build adds IntelliPrompt support for delegates.

EditorBrowsableAttribute Support

Support for recognition of the EditorBrowsable attribute is now available.

When the EditorBrowsable(EditorBrowsableState.Never) attribute is applied to a type or member, that type or member will no longer appear in member lists.

The attribute is recognized for both assembly-defined and source-defined types and members.

The latest build for SyntaxEditor's .NET Languages Add-on now includes complete generic type IntelliPrompt functionality.

This has been a highly requested feature by customers.  Now you can fully utilize the power of generic types such as generic collections, etc. with the .NET Languages add-on.

For instance, in the screenshot above, after you would complete the indexer reference and press ".", the member list that would display would be for type String.  Type String was declared as the "U" generic parameter in MyCollection, which was passed down to the base Collection generic type.  Therefore the String type was used to construct Collection.  With the most recent build, SyntaxEditor's .NET Languages Add-on can recognize that and provide proper IntelliPrompt related to it.

Enjoy the new features!