SyntaxEditor - ASP-Style Server Tags with IntelliPrompt

by Avatar Bill Henning (Actipro)
Friday, February 13, 2015 at 1:25pm

PostBannerSyntaxEditorDevNotes

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.

SyntaxEditorServerTags

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.

TaskDownload TaskLiveDemo TaskBuyNow

SyntaxEditor - XML End Tag Completion

by Avatar Bill Henning (Actipro)
Friday, January 30, 2015 at 9:59am

PostBannerSyntaxEditorDevNotes

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):

SyntaxEditorEndTagAutoComplete1

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:

SyntaxEditorEndTagAutoComplete2

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.

TaskDownload TaskLiveDemo TaskBuyNow

SyntaxEditor - Read-Only Regions

by Avatar Bill Henning (Actipro)
Tuesday, January 27, 2015 at 2:10pm

PostBannerSyntaxEditorDevNotes

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.

SyntaxEditorReadOnlyRegion

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.

TaskDownload TaskLiveDemo TaskBuyNow

Actipro Blog 2014 Q4 Posting Summary

by Avatar Bill Henning (Actipro)
Sunday, January 4, 2015 at 2:32pm

BlogSummaryBlogPostBanner

What We Accomplished

In this quarter, we published large maintenance releases for the 2014.2 versions of our WPF, Silverlight, WinRT/XAML, and WinForms controls.  These versions included several new controls and some big feature enhancements for our existing controls.  Check out the release posts for more detail.

What’s Coming Next

We've started work on our 2015.1 versions of our controls.  These will feature some new controls, major improvements to our SyntaxEditor Python Language Add-on, and many other updates.  One thing we're working on is rewriting much of the core of our Docking/MDI for WPF product so that we can support even more advanced features found in the latest IDEs.

Blog Post List

Control Product Development