The Actipro Blog

All the latest UI control development news from Actipro

SyntaxEditor vNext IntelliPrompt Updates

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort (codenamed vNext) is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

The past three weeks or so, we've been plugging along on refactoring a lot of the internals of SyntaxEditor's IntelliPrompt UI features so that the same codebase can be shared across the WPF, UWP, and WinForms platforms.

While the WPF and UWP version's APIs are pretty much staying the same (with a couple minor tweaks to completion filters), the WinForms version will see some massive new capabilities, especially with completion.

IntelliPrompt Features Summary Video

Let's dig in and see a visual summary of some amazing completion list features that will be available in the all three SyntaxEditor vNext platforms.  This video shows the WPF SyntaxEditor editing a Python document using our advanced Python Language Add-on.

 

2018-12-12_10-46-08

Toggle Button and Tab Completion Filter UI

The completion list allows for toggle button and tab filters to be added.  Toggle button filters allow you to check the kinds of items you wish to see in the completion list.  If nothing is toggled, then all results are displayed.  Tab filters let you select between two or more main options, with one being an "All" option.

While the current WPF and UWP versions already support toggle button and tab filter UI, this is a new feature for the WinForms version.  And in vNext, the toggle buttons work more like they do in Visual Studio 2017.

Filtering Unmatched Items

As you type, the completion list filters out items that don't match.  This is an option already available in the WPF/UWP versions, but is new for the WinForms version.

Matched Text Highlights

When typing text, the letters in each item that match will be highlighted in the list.  This feature makes it clear why an item is matched and is especially useful when not filtering unmatched items, or using some more advanced item matcher algorithms like acronym or shorthand.

This feature is already available in the WPF version, but is new for the UWP and WinForms versions.

Python Language Add-on

As described in this previous post, the Python Language Add-on is new for the WinForms version of SyntaxEditor.

We've also updated the IntelliPrompt completion in the add-on to dynamically show toggle button and tab filter UI based on the items that are present.  For instance, in the animation above when there were no classes available in the list, there was no "Classes" toggle button in the UI.

New Icons

As described in this previous post, the WPF and UWP Metro icons used in IntelliPrompt have been drawn from scratch as vector icons and will render crisp and clear on any high DPI monitor. 

The WinForms version is getting Metro icons as well, whereas they only had Classic icons before.

What's Next

We have IntelliPrompt completion, parameter info, and quick info completed for all three platforms.  Next is to knock out code snippet UI and then all IntelliPrompt features should be about done.

WinForms SyntaxEditor vNext Updates

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort (codenamed vNext) is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

In today's post, I wanted to call out a couple of new WinForms SyntaxEditor vNext updates that are being made as part of unifying the codebase across all platforms.  These features were already available in the WPF and UWP versions.

Python Language Add-on

While we've had an advanced Python language add-on for the WPF and UWP versions of SyntaxEditor for a while, due to infrastructure differences, it was never available in WinForms. 

SyntaxEditorWinFormsPython

This is all changing in vNext.  The full add-on will be available, including automated IntelliPrompt as seen ion the WinForms SyntaxEditor screenshot above.

NavigableSymbolSelector Control

The WinForms version had a dropdown that sat above the editor and could be used for .NET language types and members.  The problem is that it was limited to the C# and VB languages only, since it shipped in the WinForms .NET Languages Add-on.

In vNext, we have a NavigableSymbolSelector control that can display one or two dropdowns.  And any language can be wired up to show symbols, not just C# and VB.  In the screenshot above, you can see Python showing the current function in it.

What's Next

We are currently working through porting IntelliPrompt feature areas to vNext.  Quick info and parameter info popups are completed.  Next, we will move onto completion lists.

SyntaxEditor vNext Vector and Metro Images

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort (codenamed vNext) is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

We've been plowing through remaining SyntaxEditor feature areas that need to be ported to our vNext codebase, and there are only a few left.  One that we just completed is updating images used in the product, which appear in IntelliPrompt popups and the NavigableSymbolSelector.

Vector Metro Images (WPF/UWP)

The WPF and UWP versions of SyntaxEditor have had Metro Light and Metro Dark image set options for quite a while now.  But they've always been raster (bitmap) graphics that don't appear crisp on high DPI monitors.  This is something we're addressing in vNext.

For vNext, all of the Metro images will be vector images.  They will look crisp and clear at 16x16 100% DPI, but will look just as good (if not better) when used on high DPI monitors.

Here's the images at 200%:

SyntaxEditorVectorImages

Metro Images for WinForms

The WinForms SyntaxEditor has only had the Classic image set in the past.  The Classic image set is similar to the full color gradient images found in earlier versions of Visual Studio.

In vNext, we're bringing the Metro Light and Metro Dark image sets as options to the WinForms SyntaxEditor, with the Metro Light set as the default.

What's Next

We are continuing to work through remaining feature areas that need porting to the vNext codebase.  The last big one to tackle is IntelliPrompt.  Some of the UI pieces involved in IntelliPrompt need to be updated a bit for compatibility between the three platforms.  Once we get that going, these new vector images will look amazing in the IntelliPrompt UI.

SyntaxEditor vNext Performance Tuning and Printing

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort (codenamed vNext) is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

For the last three weeks or so of SyntaxEditor vNext development, we've been working on performance profiling and printing support.

Performance Profiling

As part of vNext, we are doing our best to speed up the editor even more than before. 

The Universal Windows version of SyntaxEditor is many times faster than the current UWP SyntaxEditor.  A large part of that is due to the newer way we measure and render the control in vNext, which is significantly faster than what we were able to do in the past.  Other tunings also help.  Let's examine some performance results.

Using page-down to scroll through a large document, we're seeing a 3.5x speed increase in the vNext UWP SyntaxEditor!  UWP SyntaxEditor speed increases when dragging the scrollbar thumb are even more evident.  There is a bit of a lag in the current UWP SyntaxEditor, whereas in the vNext UWP SyntaxEditor, the display is instant and tracks with the dragged thumb perfectly.

Running the same page-down scrolling test in WinForms, we're seeing a 20% improvement in speed over the older version.  The WPF version is seeing a slight improvement in scrolling speed over before as well, although it has always scrolled extremely fast.

We are continuing to work on tuning the API to maximize performance when scrolling and editing.

Printing

Printing support has been added back into vNext for the WPF and WinForms versions.  We are currently working on the UWP version's printing support.  These features allow you to easily print out a document to paper, or a PDF file using the "Microsoft Print to PDF" virtual printer found in Windows 10.

What's Next

We are going to wrap up UWP printing support next, and then will move onto a few other areas left to port over to the API.  Large remaining areas include searching and IntelliPrompt feature APIs.

SyntaxEditor vNext Multiple Selection Pasting

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort (codenamed vNext) is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

As described in recent blog posts, we've been working on adding multiple caret/selection support to SyntaxEditor in vNext.  In this post, I'd like to show off a neat new feature related to copying/pasting text when there are multiple selections.

Pasting Demo

At the start of this animation, I do a line copy, which occurs when there is no selection and you press Ctrl+C.  Then I paste that line in three times.

Next I select the text "Actipro," then Ctrl+select the text "SyntaxEditor," and finally Ctrl+select the text "vNext."  The Ctrl+selections have allowed me to create three selections.  At this point I could type and it would replace each of those selections with what I typed.  Instead, I'm going to press Ctrl+C again to copy the selected text.

2018-08-02_11-15-36

When I copy multiple selections, each selection's text is appended together and delimited by a line terminator.  So if you would paste what I copied into Notepad, it would paste as:

Actipro
SyntaxEditor
vNext

In the animation, the next thing I do is put a caret in each of the three empty strings by Ctrl+clicking in them.  We just added some new vNext logic that will compare the number of selections with the number of lines in the pasted text.  When they are equal, as they are in this demo, each line in the pasted text will get pasted into the related selection.  The end result is you can see how each of the three selections I originally copied end up in a separate target selection.

Summary

Multiple caret/selection support touches many portions of the editor and we are continuing to work through updating all feature areas to support it.

Let us know what you think in the comments.

SyntaxEditor vNext Multiple Caret/Selection Progress

BlogPostBanner-SyntaxEditor-DevNotes

As mentioned in a previous post, we have been working on refactoring the core internal implementation of our SyntaxEditor code editor control on the WPF, UWP, and WinForms platforms.  This effort is being made to bring all three platforms onto the same codebase for easier updating moving forward, and to enhance features wherever possible.

We are continuing development on our SyntaxEditor control, adding many modern features under a unified API design.  One enormous feature area getting added is multiple carets/selections.  We briefly proposed adding this feature several months ago in this blog post to gather feedback.

Now that we've had time to iterate on development of it, I wanted to share a demo so you can see how it works.

Multiple Carets/Selections Demo

In this screen capture animation, we show how SyntaxEditor vNext will support multiple carets/selections.

2018-07-18_11-41-52

I first select a word using my mouse and click/dragging like normal.  Then I select text under it while holding the Ctrl key and click/dragging.  Afterward I notice I accidentally selected too many characters.  I hold Ctrl and click the second selection to collapse it.  Then I hold Ctrl and click/drag to make the correct selection.

Next I hold Ctrl and click in another word to add a third caret.  I remove that same third caret by Ctrl+clicking on it again.  This is a nice feature for when you accidentally add a caret/selection you didn't mean to add.

Finally, edit actions like typing will affect all selections.  You can see in the animation how typing "Foo" affects the two selections.  Pressing Ctrl+Z for undo applies to all the selections.

Summary

Adding multiple caret/selection support is a massive feature area that touches many portions of the product.  While it's taken a while to implement, we're very pleased with the progress thus far and think it will really be exciting for end users.

Let us know what you think of this feature area in the comments.

SyntaxEditor vNext Is Progressing

BlogPostBanner-SyntaxEditor-DevNotes

We've spent the past three months mostly working on redesigning some of the core implementation of our SyntaxEditor control and wanted to give an update today on where things stand.  From this point forward, we'll call this development effort "SyntaxEditor vNext".

Unified Text Rendering Engine

The first phase of this was described in our previous Building a Better SyntaxEditor Text Rendering Engine post.  What we've done is come up with a common API that can be used for text rendering and is the same across WPF, UWP, and WinForms.  It allows consumers of this text rendering API (namely SyntaxEditor) to have a single way to perform all its core text formatting/rendering, etc. 

This is important because when we have a common API wrapper for performing those difficult and very platform-specific tasks, we are able to consolidate all the code that calls into that API to be more or less platform agnostic.  And that means the WinForms SyntaxEditor will see some huge benefits.  More on that below.

Universal Windows

The new UWP text rendering engine implementation is much, much faster than the current way we render text in the UWP SyntaxEditor.  In fact it might even be rendering faster than the WPF version now!  The new UWP text rendering engine also allows for more culture-sensitive logic involving caret movement, right-to-left text, etc.

Windows Forms

The new WinForms text rendering engine implementation is also faster than before and now supports culture-sensitive logic involving caret movement, right-to-left text, etc. 

WPF

The WPF text rendering engine implementation has always been the most advanced one, and it's getting even better.  It features improved efficiency and handles extremely long lines better.

Getting the WinForms SyntaxEditor on the Common Codebase

Per above, a key benefit of having a common API for text formatting/rendering is to finally make progress on migrating the WinForms SyntaxEditor to share code with the other newer platforms that already share a majority of code.  This would mean that the WinForms version would get all the benefits of the more advanced add-ons found in the WPF version, etc. 

This is huge for WinForms SyntaxEditor customers, and parity with the WPF version is something many customers have asked for.

Refactoring the SyntaxEditor Internals

In more recent weeks, we've been refactoring a lot of SyntaxEditor's internals that are related to views, including view management, splitting, scrolling, etc.  We're building a new internal codebase for those features that works the same across WPF, UWP, and WinForms.  And best of all, we're doing our best to keep the same public API as the current WPF version so that there will be minimal breaking changes.

The refactoring is going well thus far, but it is a long process since we're adding feature areas back in one by one with more efficient code and in numerous cases, with additional features.  Here's some examples of improvements in the scrolling area‚Ķ

Scrolling Improvements

Scrolling has been improved so that you can easily scroll an editor view to any line and even designate if that line should appear near the top/center/bottom of the view, and how far to pixel offset from that location.  This will be wonderful for features like go to line.

When resizing an editor view that is scrolled to the right, if you now resize it even wider, the view lines will anchor to the right when appropriate to make sure not too much whitespace appears at the right side of the view.  In the current SyntaxEditor implementations, the horizontal scrollbar wouldn't scroll at all in that scenario, leading to a lot of extra blank space on the right side of the view.

When vertically scrolling through documents with various view line widths, the current SyntaxEditor implementations will adjust the horizontal scrollbar maximum mostly based on the visible view lines' maximum width.  The newer implementation tries to remember longer line max widths it's seen in the past and prevents a lot of the horizontal scrollbar maximum jumpiness that can happen when scrolling vertically.

Summary

We're really excited about where things are heading.  Not only are we getting a better internal codebase for managing a lot of view-related features, we're adding features as we go, and are consolidating the WPF, UWP, and WinForms codebases such that they will share 95%+ of the code.  This will allow for language add-on codebases to be shared across all platforms.  And the public SyntaxEditor API changes for the WPF/UWP platforms will be kept to a minimum.

If you have any specific view-oriented features that you'd like to see in SyntaxEditor, now is the time to get your suggestions in. 

We're chatting daily about progress in our Slack workspace and would love for you to discuss SyntaxEditor with us there.

Building a Better SyntaxEditor Text Rendering Engine

BlogPostBanner-SyntaxEditor-DevNotes

The past several weeks, we've been prototyping a new core text rendering engine for future use with SyntaxEditor (and possibly other products) that can be used across multiple platforms.  This text rendering API is the same across all supported platforms, which currently are WPF, UWP, and WinForms.  The implementation of that common API is platform-specific behind the scenes since each UI platform supports rendering text in very different ways.

SyntaxEditor would be a consumer of that text rendering API.  By using that text rendering API that is common across platforms, we could consolidate all the SyntaxEditor logic related to text formatting, rendering, and hit testing to be the same.

Platform Benefits

First the UWP version's text rendering implementation in this new engine is lightning fast, and would yield a massive rendering speed increase when merged into the UWP SyntaxEditor, compared to our current way of rendering text in the UWP SyntaxEditor.  It also would be more culture-sensitive with better logic on caret movement, right-to-left text, etc.

The WinForms version's implementation is also fast and compared to the current WinForms SyntaxEditor's way of rendering text, would gain culture sensitivity for caret movement, right-to-left text, etc.  Having a common text rendering API with other platforms would also be a big step in moving the WinForms SyntaxEditor down a path towards using the same general SyntaxEditor API as the other newer UI platforms use.  A future goal is to make this happen so that changes we make to features, add-ons, etc. can flow freely between all the SyntaxEditor platforms.

Finally the WPF version's text rendering is already very fast and culture-sensitive, but there are several logic enhancements we're making to improve speed when rendering long lines.

What's Next

We're still working on everything, but so far, tests in separate projects are very promising for the future of this text rendering API experiment.

Once things are finalized a bit more, we may plug it into one of the platforms like UWP to begin actual usage testing with SyntaxEditor.  This process will take some time since we will have to pull out all the plumbing for the current SyntaxEditor text rendering implementation, and adjust things to work with this new API.  We will give some updates once we make progress on that end.

Filed under: Actipro, In development

WPF Controls 2017.1 Beta Testers Requested

PostBannerWPFControlsDevNotes

Hey everyone, we've been working very diligently on the 2017.1 version of our WPF controls for the past several months and a public beta is almost ready.  We'd love as many customers as possible to participate in the beta.  First, let's give an overview of what's new in the 2017.1 version.

Editors Reimagined

In the 2017.1 version, we reimplemented all Editors controls to be faster and more lightweight in terms of elements/bindings, and to use a common codebase with the Universal Windows Editors product.  The new designs are better optimized for use in large quantities such as within data grids or property grids.

Every new edit box control has more fine-grained control over the step values.  Now a native TextBox control is used for input, which allows for more free-form editing, IME input, and better UIA support.

BrushEditBoxOpened

New and improved drop-down pickers have been designed for each edit box.  The pickers are optimized for mouse, pen, and touch-based entry.  The screenshot above shows the BrushEditBox and the new BrushPicker drop-down control.  Altering any edit box's drop-down is simply a matter of providing an alternate Style for its picker control.

TimeEditBoxOpened

New edit boxes have been added for the Byte, Int16, and Single numeric types, along with dedicated date-only (DateEditBox) and time-only (TimeEditBox seen above) variations of DateTimeEditBox.

Tree Controls Added

Our customers have requested custom tree controls from us for a while now and we delivered in this version.  We now offer a new TreeListBox control that is a single column tree similar to a native TreeView but optimized for MVVM usage, virtualization, and speed.  It supports nearly all of the advanced features you'll find in a tree control like the Visual Studio Solution Explorer tree.

TreeListViewColumnReordering

We also offer a new TreeListView control that is built upon the TreeListBox control but displays multiple columns similar to a ListView.  Each column supports its own distinct user interface via data templates.

Both of these controls are packaged in a new Grids product.

PropertyGrid Reimagined

While the PropertyGrid control found in our 2016.1 and earlier versions was very feature-rich, its performance sometimes left much to be desired and customization via property editors wasn't very straightforward.

PropertyGridIntro

In the 2017.1 version, PropertyGrid has been rewritten from scratch and constructed around the foundation provided by the new TreeListBox and TreeListView controls.  It's now lightning fast and loads complex objects (like the properties of itself) almost instantly.  A lot of this is due to simplification of the internal object model, use of virtualization techniques, and fewer overall UI elements.  You'll definitely notice the speed increase.

The core object model used to track properties and categories has been improved and creating custom property editors is much more straightforward now.

The new PropertyGrid is part of the Grids product as well.

Beta Testers Wanted

If you'd like to help us beta test the product, please write our support address and let us know your existing 2016.1 license information.  We will notify you as soon as the public beta is ready and will send you a 2017.1 license if your subscription is still active. 

The code for the beta is near complete and should be pretty stable.  We have a full array of samples and documentation has been completely updated, including conversion notes.

We also will be chatting about the beta in our Slack channels so please join if you have Slack.

Tags: , ,

TreeListView - A Multi-Column Variant of TreeListBox

PostBannerWPFControlsDevNotes

In the last blog post on our TreeListBox control development, we announced that the TreeListBox control was ready for closed alpha testing.  TreeListBox is a new control that has much of the same functionality as the tree control found in the Visual Studio Solution Explorer.

In today's post, I'd like to announce a new TreeListView control that is now also ready for alpha testing.  The TreeListView control is a multi-column variant of the TreeListBox control that renders similar to a standard ListView but has all the tree and advanced features found in TreeListBox.

TreeListViewColumnReordering

The animation above shows several of the features found in this new control such as node expansion, column resizing, column reordering, column header context menus, and more.

Feature Progress

Thus far these TreeListView features have been completed:

  • All features found in TreeListBox.
  • Templates, template selectors, or text property bindings used to specify custom content for each cell.
  • Column width can be a specific pixel value, auto (size to header, cells, or both), or star-sized.
  • Optional minimum and maximum widths for column auto/star-sizing modes.
  • Columns can optionally be resized, reordered, and have visibility toggled by the end user.
  • Frozen columns that don't scroll horizontally.
  • Set which column renders the indentation and expander buttons.
  • Column headers have a built-in context menu, and the headers themselves can be hidden.
  • Size columns to fit contents.
  • Optional grid line display.
  • Numerous events for column resizing, reordering, visibility changes, and header menu requests.

Summary

If you would like to start working with either of the controls and provide us with feedback, please write our support address or chat with us on Slack to sign up for testing.  Now is the time to contribute your additional feature ideas and report bugs.  Anyone who has a WPF Studio license is fully licensed to use the control in their apps.

TaskWideContactUs TaskWideChatWithUs