Tweets by @Actipro
Please take some time to learn more about us and our product offerings.
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 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.
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:
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.
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.
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.
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.
Our Gauge product has just been updated with two new controls, lots of new features for the existing controls, and several bug fixes. This update is part of build 4.5.0480 that was released this past Friday.
Here are some details on some of the major new features and controls...
The CircularGauge and LinearGauge now support logarithmic scales with a configurable base. Logarithmic scales can be useful when more sensitivity is needs for lower values, since smaller values are spaced further apart.
A CircularGauge with a logarithmic scale using a base of 10
All the gauge controls allow more customization of the frame rendered. The frame rim is now independent of the frame background, which allows you to mix and match the various effects supported by each. In addition, a new glass effect has been added, which produces a more stunning look.
A CircularGauge shown with (left) and without (right) the new glass effect
The gauges now support being resized dynamically, so that the inner elements resize proportionally. This is accomplished by specifying percentage-based sizes, but fixed-based sizes can still be used if desired.
A CircularGauge sized 200x200 (left) and 300x300 (right)
The DigitalGauge can now scroll the text displayed to the left or right using a configurable interval. This allows long text to be presented to the end-user using a marquee effect.
A DigitalGauge using the new dot matrix character type with scrolling marquee functionality
Two new controls come with this update, an Led control and a ToggleSwitch control.
The Led control is great for presenting simple state (on, off, blinking) information to the end-user. The led light is fully animated and customizable, with options for the light shape and colors.
An Led with a red light
The ToggleSwitch control works much like the native WPF ToggleButton, but looks like a real-life switch. The switch is fully animated and customizable, with 2 styles to choose from.
A ToggleSwitch with a circular look
There are too many other new features to list here, but check out the latest build to try them out for yourselves.