We’ve been fascinated by Twitter and its ability to further connect people together.  If you aren’t familiar with it, it basically is a simple way to let people know what you’re doing.  You get up to 140 characters to say what’s going on and people who subscribe to your account can get notified of updates and reply if they wish.

We were thinking that it would be great to use this technology to keep our customers informed of what’s going on at Actipro.  So, without further ado, we’ve created the official Actipro company Twitter account.

Click the link below to jump right to our company Twitter page:

Actipro twitter account

Alternatively, use your Twitter client to start following the Actipro account.

We’ve gotten a lot of great feedback from people who like to read our blog updates and by starting to publish more minor updates on Twitter, we hope we can further communicate with you about what is going on at Actipro.

Please feel free to reply to our “tweets”, we’d love to talk to you.

Last week we discussed the concept of prioritized item matching algorithms and yesterday I talked about completion list matched text highlights.

We already have four matching algorithms in place for the default completion list implementation, two of which can be toggled on/off via options.  All the matching algorithms simply implement an interface.

Now wouldn’t it be neat if you could write your own customized matching algorithm? 

Well you can with SyntaxEditor, and it’s so easy too!

A SQL example

Let’s assume you are showing a list of SQL data objects and you want to implement a custom matcher that uses a regular expression to match
any item that has the typed text appearing after a "." or "_" character.  The default starts-with matcher should also be used to match text at the start of each item.

To start you’d make a custom class that inherits our RegexCompletionItemMatcherBase class.

   1: public class CustomCompletionItemMatcher : RegexCompletionItemMatcherBase {

   2:     ...

Next you’d override a GetRegex method to return the Regex to use.

   1: protected override Regex GetRegex(string text) {

   2:     // Make sure the text to highlight is surrounded with parenthesis 

   3:     //   so that SyntaxEditor can locate the captures

   4:     return new Regex(String.Format("[\\._]({0})", Regex.Escape(text)), 

   5:         RegexOptions.IgnoreCase | RegexOptions.Singleline);

   6: }

That’s it!  The RegexCompletionItemMatcherBase base class has all the code in it to automatically match items and highlight matched text based on your Regex.

Here’s what the list looks like at run-time:

Note that since we typed an L, the LOCATION.ID item was selected.  However you can see that CUSTOMER.LAST_NAME and EMPLOYEE.LAST_NAME also had their L characters highlighted that occurred after a period.  EMPLOYEE.CELL_NUMBER has L characters in it too but our algorithm didn’t match it because the L came after a letter and not a period or underscore.

More advanced implementations

While it is likely that the Regex-based item matcher will provide all the functionality you need for a custom item matcher implementation, sometimes you may require additional logic.  No problem, there is a more low-level CompletionItemMatcherBase base class that lets you implement any sort of logic you desire to match items and return highlighted ranges over item text.  All the base classes implement the ICompletionItemMatcher interface.

Continuing the series of posts regarding our advanced completion lists for the upcoming SyntaxEditor for WPF product, today I’d like to introduce another innovative new feature:  matched text highlights.

Remember that matches are made using a series of prioritized item matching algorithms, as discussed in a previous post.

The completion list auto-selects the closest matched item in the list as you type.  However another sort of useful visualization is to be able to see how typed text matches against other items as well.

This is where matched text highlights come in.  In the screenshot above, I typed as in the editor after displaying the completion list.  By default, the completion list auto-selected AStringValue in the list however I moved the selection down with the arrow key so you could see the highlights.

The AStringValue item has the AS characters highlighted because the top priority starts-with algorithm matched my typed text there.

The Equals item has its a and s characters highlighted because the shorthand algorithm matched my typed text there.  Shorthand also matched the as in GetHashCode. 

Just like with normal auto-selection, SyntaxEditor cycles through the prioritized list of item matching algorithms and uses the first one that matches an item to show highlights indicating where matches were made.

We really think end users will love this feature!

We’re sad to be ending SyntaxEditor “completion list” blog post week today. :)  There’s been a lot of good information presented on the upcoming features for SyntaxEditor for WPF.

To recap, we had these related posts:

• SyntaxEditor for WPF – Advanced completion list filtering
• SyntaxEditor for WPF - Completion list transparency
• SyntaxEditor for WPF - Completion list description tips
• SyntaxEditor for WPF - Completion list matching algorithms

For the final post in this series, I’d like to talk about options for how text is auto-completed upon a completion list selection.

The screens below are taken from the QuickStart we have on this topic.

The simple way

Normally the text displayed in the completion list for an item is the same text that is inserted.  That is what happens by default.

However SyntaxEditor has the ability to insert alternate text both before and after the caret.  Several variations are shown in the following sections.

Alternate text inserted before the caret

In this sample, we have a br tag.  It shows br in the list but when it auto-completes, it inserts <br/> into the document.

Note that the caret is moved after the inserted text.

Alternate text inserted to surround the caret

In this sample, we have a comment.  It shows !-- in the list but when it auto-completes, it inserts <!-- --> into the document.

Note that the caret is automatically moved within the comment’s delimiters following insertion.

This is another similar example.  For the hyperlink, it shows a in the list but when it auto-completes, it inserts <a href=”” into the document.

Again the caret is automatically moved, but this time to within the href attribute value.

With the SyntaxEditor completion object model, you have total control over what is inserted and where the caret moves.  It’s very easy to set up.

Allowed characters

One other thing I’d like to discuss while showing these samples is the topic of allowed characters.  By default, only letters, digits, and underscores are allowed characters.  If you type any other character while a completion list is open, it will either auto-complete or cancel depending on whether you have a full selection in the list or not.

SyntaxEditor lets you customize the allowed characters.  For this QuickStart we added the ! and - characters as allowed characters so that comments can be typed.

Enjoy the weekend.  We will get into some new feature areas soon!

“IntelliPrompt completion list” week continues with today’s hot new feature: matching algorithms.

Matching algorithms are what are used to select an item in the completion list as you type in the editor. 

Default matching algorithm

Normal completion lists match with an algorithm in which the typed characters are compared against the start of each item like in this screenshot:

The default algorithm has the highest priority when attempting to match items.  If no match is made, the next active algorithm is used.

Acronym matching algorithm

Next in priority is an optional algorithm in which the first and every uppercase letter is examined for a match.

For words that contain underscores, the first and every character following an underscore are examined for a match instead.

If no match is made, the next active algorithm is used.

Shorthand matching algorithm

Next in priority is another optional algorithm in which the supplied text provides a wildcard sort of pattern.  A match is made if all the characters appear somewhere in the item text.

Shorthand provides the most flexibility since it allows substring matches anywhere in the items.

If no match is made, the fallback algorithm is used.

Fallback partial matching algorithm

Finally if no match as been made yet, a partial match can be made at the item that starts with text closest to the typed text.

Case sensitivity

By default, matching is done such that matches that actually match the case of the typed text are returned first.  If none are found, an insensitive match is returned instead.

This default can be disabled so that insensitive matches are always used.

Match target text

Completion list items each have display text and text that is actually inserted into the document.  By default the text that will be inserted into the document is matched against.  However you can change it to match against the display text if you prefer.

Note that in most cases, the display text and text to insert actually are the same thing.

Summary

As you can see, the multi-algorithm approach provides some really nice functionality for end users.  And there are plenty of other options so that you can tailor the user interface how you wish.

These are just some of the advancements we’re making in SyntaxEditor for WPF that make all the difference between our product and the competition.

This week has unofficially become “completion list feature” blog post week! :)  Make sure you check out our previous two posts, on completion list filtering and transparency.

Let’s continue the fun with some screens of description tips in action.  Please note that the screenshots below have been scaled down to fit within the blog.

Description tips in action

In the screenshot above, the completion list is displayed and upon the highlighting of an item in the list, a description tip appears.  In this case, it’s a description tip for an integer field similar to our our .NET Languages Add-on shows description tips.

Here we show a description tip for the base Object’s Equals method.  Note how images and multiple font characteristics can be applied in the description tips to render some very readable content.

Content on-demand

In SyntaxEditor for WinForms, each completion list item could be assigned a description that was used to build the content for the description tip.  In our next generation design for the WPF version, we’ve made it so you assign a content provider to each item instead.  The content provider is called on-demand to retrieve the content to display.

This means you use less overall memory for completion lists since you don’t need to build descriptions up-front.  However we have a number of content provider implementations pre-built so you still can build and assign them up-front if you wish.

In advanced languages though, like our .NET Languages Add-on when later implemented for the WPF version, we’ll want to have a single content provider that we assign to all member items, maybe another for type items, etc.  The one for member items would be used for items such as in the screenshots above.  It would have access to the core member information being represented by the related item and would look up XML documentation on-demand to construct richly formatted description tips like in the screens.

Multiple types of content providers

There are three built-in content providers that ship with SyntaxEditor for WPF. 

The first lets you simply pass back a WPF UIElement that you’d like displayed in the description tip.  This allows you to place any WPF content in the description tip.

The second accepts a string and renders the text content as plain text within a TextBlock that is displayed in the description tip.

The third, and this is the “fun” one, is one that also accepts a string of HTML subset markup and transforms the markup to UIElements that render like in the screens above.  Font properties can be set over spans and images and hyperlinks are supported.

Extensibility in mind

Since the content provider (and most of the rest of our next generation design) is implemented as interfaces, you can create your own customized content providers to return whatever you need.

As you can see, the model for building this rich UI is very open and extensible, and there’s plenty more to come.

Another feature of the completion list implementation we’re doing in SyntaxEditor for WPF is transparency. 

When the completion list is displayed, you can hold down the Ctrl key and the completion list smoothly fades out to be mostly transparent.  Releasing the Ctrl key fades the list back to be fully-opaque again.

The benefit of this feature is that the end user can quickly view the code covered up by the completion list if they need to.

We’re currently working on implementing completion lists in SyntaxEditor for WPF.  Completion lists are basically the mechanism used to provide “complete word” and “member list” functionality found in applications like Visual Studio.

While we’re covering all the basics associated with such functionality, we’re taking functionality to the next level in our implementation.  One area in which we’re delving is advanced completion list filtering.

What is filtering?

Normally completion lists appear like in the screenshot above.  They are a list of items and as you type in the editor, the selected item in the completion list is updated to reflect the item that most closely matches what you have typed.  You then can press Tab or Enter to insert the complete text associated with the item.  They help increase the productivity of end users while typing.

Completion list filtering is a feature that allows the presented items in the list to be filtered down.  This is most useful when you potentially have hundreds of items in a completion list and want the ability for the end user to narrow down the items that are displayed.

SyntaxEditor for WPF contains a feature-rich model for supporting filtering, as we’ll discuss below.

Adding filters to a completion list session

Each time a completion list is displayed, it is called a session.  The session has a large number of properties available that allow you to completely customize its behavior.  One such property is a collection of filters.

Each filter is simply an object that has a Filter method which can return whether an item should be excluded from the displayed items.  The simplest implementation of a filter would be programmatically activated and deactivated by you, the developer.  When active, the filter is applied to the items.

But what if we want to give the end user control of which filters are active?  SyntaxEditor has some very nice features for allowing this, where each filter can tell the completion list how UI should be created to support toggling of the filter.

Filter buttons

One option for filter UI is the creation of a toggle button.  If the toggle button is checked, the filter is not applied (because filters exclude items).  When the toggle button is unchecked by the end user, the filter becomes active and is applied.

In the screenshots above, the left completion list shows the default unfiltered view.  In the right completion list, the method filter has been activated, thereby excluding all members from the list.

Each filter button supports a tooltip so that the end user can hover over it with the mouse to get a better explanation of what it does.

Filter button groups

What if you have multiple “groups” of filters and want to separate them somehow in the UI?  No problem, each filter can be assigned a group name.  The UI generator automatically appends separators between groups.

In the screenshots above, a second group containing a single Inherited filter button has been added.  Note the separator between the two groups.

In this sample, when the Inherited button is unchecked, it excludes all members that were inherited from Object. 

It is important to note that anything can be placed in the content of these filter buttons.  You could do images and text if you wished.

Filter tabs

Tabs are another sort of UI that can be generated for filters.  With tabs, the related filter is applied only when the tab is selected.  There is a special “All” tab that can be added that deactivates any filters that are applied by tabs.

In the screenshots above, the left completion list has its “All” tab selected meaning the Public members filter is not applied.  If we click the right tab, the Public members filter is applied.

Combining buttons and tabs

Want to combine both filter buttons and tabs?  No problem, SyntaxEditor can handle it all!

In the screenshots above, the left completion list shows all filters deactivated.  The right completion list shows only public members (due to the filter tab selection) and does not show the IntValueChanged event due to the unchecked Events filter button.

Customizability is key

The screenshots above all illustrate how we plan on implementing member list filtering when we get past the core SyntaxEditor for WPF development and into development of a .NET Languages Add-on version that can be used with it.

It’s rather easy for anyone to create filters just like above because you have total control over what filters are available and how they should be generated in the UI. 

We foresee each language developer using our extensible object model to make customized filters for each language and in some cases, context within a language.  For instance, this walkthrough showed a member list.  However if we are editing C# and want to shows namespaces, types, and members, you may wish to have a completely different set of filters displayed.