We’ve had a lot of requests from customers asking what we’re currently focusing our development efforts on. Let me post some details on the work we’re doing right now.
SyntaxEditor for WPF
SyntaxEditor continues to be a main focus for our development time. The past several weeks we’ve been more into the backend document/parsing functionality which is why we haven’t posted many updates here in the blog. Unfortunately with those things, there isn’t much to show. :)
Today I’d like to talk about a couple new features that have been in development recently.
Reducing Memory and Processing for Large Files
A key enhancement that we’ve been focusing on is making strong efforts to dramatically improve support for large files.
A previous post (Large file editing in SyntaxEditor for WPF looks great so far) described a number of improvements we already made in that area.
One key drawback to how SyntaxEditor 4.0 does semantic parsing (not normal lexical parsing for highlighting) is that it creates a full text string copy of the document right before parsing occurs and the semantic parsing works on that. While this is fast and ok for small-medium size documents, there are two bad things about this design. First, it takes time to construct a full string copy of the document. Usually this is pretty fast in practice though. The more important thing is the memory usage involved. We now essentially have two full copies of the document in memory, one stored by the document and the copy that will be used for semantic parsing.
So you may be asking, why is a copy made for semantic parsing? The reason is that semantic parsing works on a worker thread so that it doesn’t interfere with the UI response speed. Say you kick off a semantic parsing operation and while it’s executing the user is typing more into the document. That would cause issues if the semantic parser was referencing the live document since all of a sudden, offsets may be invalid. Therefore the semantic parser has its own immutable copy of the document text at the time the parser started, and we don’t need to worry about issues introduced by threading and user modifications during parsing.
Back to what’s new. Now we have a way that stores text and is able to reuse most of the memory between text changes. Best of all, each copy of the text between changes is completely immutable. This means that:
- The text copies are completely thread-safe since they are immutable.
- There is no complete reconstruction of the text needed for passing to a semantic parser, thereby reducing processing time.
- Most of the memory used to store two or more copies of the text (between changes) is shared between the copies, thereby reducing overall memory usage dramatically.
So as you can see, with some of the improvements we’ve been working on, this will really help with editing large files where processing speed and memory usage issues come into play.
Custom Highlighting of Text
A lot of customers in the past have request an ability to integrate into the syntax highlighting engine and change certain spans before they are displayed to the end user. We’ve developed a nice system that should allow for this.
Essentially the language first runs its lexer to parse text and determine how it should be highlighted. Then you can optionally add in classes to layer on top of that. Each layer can look at previously run layers and view them, alter them, or add completely new spans for syntax highlighting that override ones in previously run layers.
How can this be used? Say you are using a C# language that we develop but you want to highlight instances of URLs in comments, and lets assume our C# language doesn’t do that by default. This is where you’d let our default language syntax highlighting run, then you add in a layer on top of that which can examine the highlighting spans and even see the tokens used to create them. You can look for comment text and if you find some, examine the text for a URL. If found add a new syntax highlighting span in your own layer that overrides the highlighting in the lowest layer and underlines the text. Each layer gets “merged” together so you could just have your span say to add underlines but use the lowest layer’s colors.
This is still work in progress but the concepts are mostly in place already and we see this as introducing a whole new level of flexibility that isn’t available in SyntaxEditor 4.0.
Alpha Version
We get daily emails asking for a release date. We want to get everything completed as fast as possible but we are taking our time and trying to develop a solid framework that should support a new generation of code editing functionality. That being said we are getting closer to having an alpha version with limited functionality ready for closed testing. We still have some pieces to get in place first but we are getting closer each day. Keep an eye on this blog. We’ll post more details soon.
Editors for WPF
The second main product we’re working on is Editors. This product’s controls are intended to be used embedded in grids, property grids, or used standalone.
One of the core controls that will be offered in the Actipro Editors product is a parts-based editor. This editor will be extremely useful for working with objects like DateTime, as it allows the individual fields, such as the month or year, to be modified and configured independently. For example, this means that the "month" can be restricted to a static list of items (e.g. Jan, Feb, Mar, etc.) or the "day of the month" can be restricted to a specific range based on the current month (e.g. 1-28/29 for February).
Additionally, an associated spinner control can be used to update the active field, such as the "day of the month" or the "year". A drop-down button will be available, which can show a popup using any control or controls. These controls can be used to edit any or all of the fields. For example, a calendar and clock could be used (as seen in Microsoft Vista) to modify either the date or time of a DateTime object.
We plan on offering several controls that derive from the parts-based editor and are specifically designed for some common types, such as DateTime. This will get you up and running faster for the common types, while still allowing you to build your own parts-editor for your own types.
There are a lot of other features that we planned for this control, which we’ll get into in future posts.