One new feature that has been requested by our customers is support for mouse wheel zooming.  Basically when you hold down the Ctrl key and turn the mouse wheel you can increase or decrease the zoom level of the editor.

Zooming in is ideal when you are doing overhead presentations.  Zooming out is useful for getting a larger picture of your document.

We’ve made this feature very configurable too.  The SyntaxEditor.ZoomLevel property sets the current scale factor of the control.  A value of 1.0 means 100%.  MinZoomLevel and MaxZoomLevel properties can be used to set the range of allowed ZoomLevel values.  The default minimum is 0.5 and the default maximum is 3.0, but these can be changed to anything you wish.

When the SyntaxEditor.IsMouseWheelZoomEnabled property is true (the default), mouse wheel zooming is enabled, allowing zooming between the minimum and maximum zoom level settings.

As the control is zoomed in or out via the mouse, a small adornment appears indicating the current zoom level percentage.  It subtly fades way over a brief period.  In addition if you are zooming in, it grows slightly and if you are zooming out, it shrinks slightly.  Altogether it’s a very nice way to know what zoom level you are at without having to bind to another control to tell you.

While these properties are all geared for easy use with the mouse wheel, you can also bind the ZoomLevel property to a Slider, perhaps in the status bar of your window.

UPDATE: See the second post on mouse wheel zooming for updated information and new features!

In addition to our work on SyntaxEditor for WPF, we are also actively building Editors for WPF. We previously announced that this product is going to include a parts-based editor, which will simplify data entry for various data types such as DateTime. We have completed most of the core functionality needed for building and presenting the various parts. We have also completed much of the work needed for a DateTime-specific implementation.

In the image above, there are two groups (one for the Date and one for the Time) seperated by the literal text "at" inside the DateTimeEditBox. Both groups include several parts, such as month, day, and year. Each part can then present, modify, or validate it's data independently. This allows the day part to be restricted to 28/29, 30, or 31 depending on the current month. Additionally, this allows the user to update the month and have the day automatically corrected. For example, if the current date is "1/31/2009" and the month is changed to 2, then the current date would be updated to "2/28/2009".

By default, the DateTimeEditBox will build and configure the groups/parts based on easy-to-use properties. More complex setups can be accomplished as needed by using the groups/parts directly in a custom parts-editor. Additionally, since each group/part is ultimately a WPF control, you can style them like any other control. This gives you more control over the look and feel of the groups/parts.

We intend to provide specific implementations of the parts-based editor for several .Net types, including DateTime, IPAddress, Color, Size, and more. If you would like to see a parts-based editor for a specific .NET type, please let us know now. Of course, you can always leverage the infrastructure we are building for any custom types you may have.

We’ll post some more screenshots in the coming weeks as progress is made on specific implementations.

One major area we’ve been working on for the past several weeks is how best to store data so that syntax highlighting can be fast yet not use much memory. 

In SyntaxEditor for WinForms, the Document had a Tokens collection that stored all parsed tokens in it.  The tokens then were used to provide syntax highlighting info to the views.  It was easy to pick up at any point for incremental parsing (when typing changes were made, etc.) since the existing tokens were readily available, and thus we’d be able to have lexical context information (which lexical scopes and states we are nested into at any given offset) very quickly.

While this works fine, there are some drawbacks:

• On initial document load, the entire document must be lexically parsed… this means a brief pause when opening large documents.
• The larger the document is, the more memory is used since tokens are stored for the entire document text.

Next Generation Updates

As mentioned in some previous posts, we’ve really been focusing on improving core features for our next generation text/parsing model.  Improvements fall into three areas:  feature set, performance improvements, and memory reduction.

We are really focused on enhancing the editing experience for large documents.  Our next gen design makes heavy use of virtualization techniques.  This means we have eliminated the need to parse the entire document on load, meaning a near-instant load time for large documents.  Additionally we no longer persist tokens in the document, meaning a huge memory reduction for large documents.

UPDATE: I should add that right now in the WPF control we can open a 10MB C# document about instantly and can start typing in it right away.  There is not noticeable slowdown in typing response speed or scrolling speed in a large document like this either, over that of a small document.

Since document tokens are no longer persisted like in SyntaxEditor for WinForms and are retrieved on-demand, determining the lexical context for a given offset was a trick to determine.  We’ve been at it for a while and finally have a good system for tracking and retrieving context info to allow incremental lexical parsing to resume near a specified offset after text updates.  This was a big hurdle to cross, so…

What’s Next

We’re going to clean up some of the code and add in a way to load dynamic language definitions that you created for SyntaxEditor for WinForms.  Then we’ll finally be ready to start a closed alpha test on what has been implemented so far!

SyntaxEditor 4.0 for WinForms has a neat feature that a lot of people may not know about.  It has a complete statistics engine built-in that can calculate a number of useful statistics about your text content.  The statistics can easily be obtained for the selected text within a view, the entire document, or even for your own custom text strings. 

Language definitions can append new statistics too.  For instance, a C# language definition may add a statistic counting the number of lines that contain comments.  This is extremely useful for apps that may examine a directory structure to calculate comment coverage over source code files.

SyntaxEditor for WPF also contains this text statistics engine (just added it today).  Check out the screenshot below of the QuickStart for this feature.

The display of text statistics for the contents of a SyntaxEditor for WPF control

As you type in the document on the left, the statistics in the right ListView update live.  The ListView is populated by calling a method on the statistics results object to return a list of statistic items (each one with a name and value) and having that list be bound to the ListView.ItemsSource.

In this post I’d like to talk about an exciting new feature we’ve recently implemented in our SyntaxEditor for WPF codebase.  Again, we haven’t released the product yet but there is a lot of interest in it so I’ve been trying to post on some of the things we’re working on.  Everything discussed here is part of our next generation text/parsing model, which we eventually plan on making available to SyntaxEditor for WinForms too.

Be warned, this post gets a bit technical and is really meant for all the SyntaxEditor geeks out there! :)

Feature Overview

A snapshot of a document provides an immutable read-only representation of the document at a certain time.  The document always references the most current snapshot.

However say you start some time-consuming parsing on the most current snapshot, which we'll call snapshot 1.  While the parsing is executing, more text changes in the document are made, bringing us to what we'll call snapshot 2.  Then assume snapshot 1's parsing completes and returns an AST of the document.  All the offsets for the AST are based on the text found in snapshot 1.  Since snapshot 2 is the the most current snapshot, the offsets for the AST are most likely incorrect since they were not based on snapshot 2.

SyntaxEditor can translate offsets from one snapshot to another, taking any text changes into account.  So if we wanted to jump directly to a class name, whose offset we know from the AST based on snapshot 1, we can translate the offset from snapshot 1 to the current snapshot (snapshot 2), and move the caret right to the translated offset.

A QuickStart Example

Let’s walk through a QuickStart to show off this feature.  In this QuickStart we have two SyntaxEditor controls.  They both start off with the same document text, however they are separate documents.  The upper editor is read-only and just shows the original contents of both editors.  The lower editor can be modified.

Both documents initially contain what is visible in the screenshot above in the upper editor, which is class declarations for MyClassA and MyClassB.  In the lower editor we deleted the MyClassA declaration.  Note the yellow line modification mark in the selection margin where our change was made.

Now back in the upper editor, we highlight the word MyClassB.  Then we click the Translate Selection button.  This takes any text changes that have been made since the original text was set, and translates the offsets of the upper editor’s selection to where the same offsets should now be in the lower editor.

The result is in the screenshot, where it highlights the lower editor’s MyClassB text.  If there was not translation mechanism in place, the selection would have been incorrectly made somewhere in the comment area of the lower editor instead.

Real-World Examples

Here are two real-word examples of using this sort of feature.

The first is based on the overview at the start of this post.  Say you have an AST that you generate based on one snapshot, and you use the resulting AST to render a TreeView containing the document outline.  A common feature is to allow double-clicking on a TreeView node to jump right the related declaration in code.  However considering that the TreeView is generally not in sync with the editor due to typing, etc., in the past it’s been a problem to ensure that we move the caret to the right spot.  With the use of the SyntaxEditor snapshot translation feature, we can almost always go to the correct spot, the only exception being if a text change has been made over the target offset after the time that the TreeView’s snapshot was taken.  However even in that case, the end result is still close.

The second example is find/replace results.  Say you do a replace all operation on a document and list the replace locations in a ListBox.  You could store the snapshot made after each replace in the related ListBox items.  This would allow you to move directly to the replaced text on double-clicks, even after multiple edits have been made following the replace all operation.

Conclusion

I hope that by illustrating this example you can see the power that this mechanism provides.  It will help ensure consistency for the end user’s point of view when making a lot of changes and dealing with find/replace results, AST-related operations, etc.

These sort of things are just some of the core enhancements we’re working on for the design of SyntaxEditor for WPF.  More to come!

We recently released our Actipro Icons product that is a huge bundle of some of the most professionally-designed bitmap icons that you’ll find on the web.  Actipro Icons includes over 1,750 unique icon designs.  Each design comes in 16x16 and 32x32 sizes, normal, hot, and disabled states, and is available in alpha-blended PNG and Icon formats.

View our initial blog post about Actipro Icons

Customer requests

Following the release of Actipro Icons, we’ve had a handful of customers (mostly our WPF Studio customers) asking for XAML-based icons.

I’d like to talk a bit about XAML icons and more importantly, to get your feedback.  We want to know what you’d like to see and whether it would be worth it to invest time in development of a XAML icons product.

Bitmap vs. XAML icons

The benefit of bitmap icons (like in our Actipro Icons product) are that they are touched-up to look spectacular at 16x16 and 32x32 sizes.  The downside is that when doing animation on them or scaling them up, they appear pixelated.

XAML icons are vector-based and are a native format to WPF.  They scale and rotate just as crisp and clear as at their target size and orientation.  This means they are ideal for various animations and/or other effects.  Additionally, when zooming in either via WPF scaling or Windows’ Magnifier, or when using alternate DPIs, they continue to look great.

Where most vector icon designers go wrong

Nearly all vector icon developers create their icons at 256x256 size and a small handful of them sell XAML-based copies of them.  Why is this bad?  Well at 256x256 and even probably down at 64x64 size, the icons will look perfect.  However realistically, how many of us use icons at those sizes? 

I would argue that 99% of icon usage is at 16x16 or 32x32 size, or sizes close to those.  Even if you have a well designed icon for 256x256 size, as soon as you scale it down to 32x32 or below, it will look blurry and many features of the icon such as borders will be invisible.  This is not good, and brings us back to where bitmap icons really shine.

Our take on the right way to create XAML icons

There has to be a solution that allows us to use vector-based XAML icons and still have them be detailed and distinguishable at small sizes like 16x16.  Here’s what we came up with in the event we do pursue a XAML icons product…

First, we still make a large 256x256 icon size for those who want the ultimate detail level for large size images.  Second, in addition to that size, we develop more customized variations of each icon that are meant to be used at smaller sizes such as one for 16x16 and one for 32x32.

Since most usage of icons is at or around 16x16 or 32x32 sizes, these special variations would be near their bitmap icon counterparts in quality and clarity.  Yet they would still be able to be scaled up and down per WPF animations and effects, and would not suffer from pixelation.

Note that XAML icons made at 16x16 would use very large borders and more contrast for the icon content, since that would show up best at the small size.  Whereas the larger variations would include more detail not found in the smaller variations, smaller borders, and more gradient effects, etc.

Styles

Icons can be designed using various styles.  Common styles are the Vista style, the Office 2007 style, or older XP styles.  Personally, I prefer the Office 2007 style of icon when used within applications.  I feel it’s more approachable.

Reply with your feedback

We really want to hear your feedback on these ideas since it will guide us to determine whether we should pursue a XAML icons product or not.  Also tell us which “style” would you like XAML icons to be in, either Office 2007, Vista, or another style?

Please post comments here or send us an e-mail.  Thanks for your help!

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!

The past several days we’ve been working on a batch update feature.  Before I get into what that means, let’s first discuss how SyntaxEditor for WinForms works. 

The Problem

Each call to SyntaxEditor 4’s Document.InsertText, DeleteText, and ReplaceText methods is its own atomic unit, meaning that UI updates and a lot of other processing occurred after each individual change.  While normally this is ok, sometimes when doing thousands of sequential replace operations in a document, it can take a bit to update.

The Solution

In the next generation text model that we’re prototyping for our SyntaxEditor for WPF control (and will eventually migrate the WinForms control to use it as well), we’ve made a number of improvements for this particular problem.

In the new model, the document class still has InsertText, DeleteText, and ReplaceText methods.  If you call those directly then they will be executed like in the SE4 model.  However you now have an option to call a method named BeginTextChange.  What this does is allows you to start a “group” of replace operations.  Each BeginTextChange must eventually be followed by a corresponding EndTextChange.  The calls may be nested too.  Upon the final EndTextChange call, the batch of replace operations are executed as a single atomic unit.

The object model is such than an ITextChange is a thing that contains some high level data and a list of ITextChangeOperation objects.  Each ITextChangeOperation represents a single replace operation.  So when the document’s TextChanged event fires, it passes along in its event arguments the ITextChange.

A Real-World Sample

As a real world example, say you are going to be performing 1000 replace operations immediately to maybe properly indent 1000 lines of code, so one replace operation for each line of code.  Here is an ideal place to use the Begin/EndTextChange model.  You would start with a call to BeginTextChange, then call ReplaceText for each of your 1000 replace operations, then call EndTextChange.  At the time you call EndTextChange, the single ITextChange (containing 1000 ITextChangeOperation objects) that has been cached up is passed along to the undo mechanism, UI, etc. via the document’s TextChanged event.  Therefore for all these replace operations, the UI and other things only update once, thereby really speeding up response time.

The Bottom Line

I know that a lot of you are anxious to get your hands on SyntaxEditor for WPF and it’s taking a bit to get ready, however I hope that by posting information like this, you can see we’re really focusing on improving core fundamental structures and methodologies.  These things are going to open up a whole new realm of possibilities for the control.  While this does delay the initial release, in the long run we’ll have a far better and more robust product than any of our competition.

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’re very happy to announce the release of a brand new media product that can be used by any application or web developer:  Actipro Icons.

Let's face it, most developers don't have the graphical skills it takes to make quality icons. And even if they do, proper icon creation takes a huge time investment. This is where Actipro Icons comes into play.

Actipro Icons provides a low-cost, yet complete solution for your graphics needs when building applications. It is a professionally-designed bundle of 10 categorized icon sets, containing over 1,750 unique icon designs, all in the Office 2007 style.

When counting the size, state, and format variations of each design, there are over 21,000 images included in the bundle.

Learn more about Actipro Icons

Multiple Sizes and States

All of the Actipro Icons (see our preview page) are implemented in 16x16 and 32x32 pixel sizes, with normal, hot and disabled states for each.

The sample images above show the six variations of a "slide-show play" icon that are included in both alpha-blended PNG and Icon formats.

Pixel-Perfect Quality at Small Sizes

When comparing icon sets with other competitors, it's extremely important to look closely at the quality of the icons at the 32x32 and 16x16 pixel sizes, since nearly all practical icon usage is at those resolutions.

Here's where our product stands out. Most icon sets are designed for 256x256 size and then are just scaled down to 32x32 and 16x16 sizes. As any graphics designer will tell you, once you scale down an image like this, the result is a very poor quality image that is full of anti-aliasing and a has a general lack of clarity.

Actipro Icons are different. Every single one of our icons have been "cleaned up" following scaling, and a good amount of extra work has been done in some cases to get icons looking spectacular in 32x32 and 16x16 sizes. We fully encourage you to compare the quality of our icons with competitors.

Download Sampler

Download a free sampler containing several icons so that you can see the quality for yourself:

Download sampler