Tweets by @Actipro
Please take some time to learn more about us and our product offerings.
As mentioned in this previous post, we've been looking for ideas to further improve our WPF Docking/MDI product, which already is the market leader for docking tool window and MDI functionality. We've committed to working on a complete internal restructuring of the product that we will call Docking/MDI vNext. We're doing our best to keep the same general API surface, while providing even more advanced features in every area of the product. We've collected suggestions from our customers over the past several years and are working to meet them as best we can with Docking/MDI vNext.
In today's post, I'd like to discuss a feature that has been heavily requested by customers over the years: docked size constraints.
In the current Docking/MDI product, there is a minimum size that docked tool windows can become but it is hardcoded. We've had customers request the ability to configure a minimum size for certain tool windows. Other customers have also requested the ability to set a maximum size. Yet others would like to see fixed size tool windows. None of those scenarios are currently supported. Docking/MDI vNext changes that.
In Docking/MDI vNext, you're able to optionally specify minimum and maximum docked sizes for each tool window. We've written a lot of complex logic to support this feature in our layouts. As the DockSite changes size, the tool windows all reflow and do their best to adhere to the docked size constraints that have been given. It works very nicely.
Want to have a fixed size tool window? This can be achieved by simply setting the minimum docked size to be the same as the maximum docked size.
Best of all, splitting (also reimplemented for vNext) is fully aware of the constraints and won't let you drag splitters beyond what the the size constraints allow.
Let's have a look at how constraints work with splitters. In the screenshot below, I've turned off live splitting so that we can see the splitter drag highlights. In this layout, the Properties tool window has a minimum docked size constraint set.
As the mouse drags the splitter upward, you can see how the class view is allowed to become very short and the splitter is still tracking with the mouse.
Later, the mouse is dragging downward but the splitter has reached the point where the minimum constraint of the Properties tool window is. Thus the mouse cursor is down below the splitter (I kept moving the mouse down), showing that the splitter can't go any further in that direction.
This is a great feature that we've spent a lot of time on for Docking/MDI vNext. vNext is currently still in early development stages but is progressing very well. Please contact us via email if you are an existing customer and would like to sign up as a beta tester for vNext.
If you have any other suggestions for improving Docking/MDI, now is the time to get them in. We'll post more updates on our vNext improvements soon.
In the meantime, please download our current Docking/MDI control product and give it a spin.
We've had a lot of customers throughout the years ask us for a sample that could show how to harness our SyntaxEditor .NET Languages Add-on and its automated IntelliPrompt within an ASP-style server tag context. This is especially useful for any sort of template generating scenario.
We had an internal sample that we would send customers upon request, but several months back, we cleaned it up, enhanced it, and added it as a new QuickStart sample. In this post, let's have a look at the QuickStart sample that was added to the SyntaxEditor for (WPF, Silverlight, and WinRT/XAML platforms) in the 2014.2 version showing how to achieve automated IntelliPrompt within ASP-style server tags.
In the animated presentation below, you can see how there is a basic parent language whose lexer only knows to tokenize and color the word "date" as a keyword. In real-world usage, the lexer could be made to fully colorize the text like normal. The lexer has hooks that cause a transition to the C# language found in our .NET Languages Add-on when ASP-style delimiters are encountered.
Both <% %> and <%= %> style tags are shown in this example. What happens behind the scenes is that the parent language's parser will code generate C# code. It will make a C# class named "__Generated" and a method named "__WriteOutput". All the text of the parent language is output within "Response.Write" method calls. C# code in the server tags is injected directly. The resulting full C# code is placed in a separate in-memory document and parsed. Finally the resulting parse data is returned, along with mapping data to know how offsets between the server tag range in the source document and those in the parsed C# document align.
Then there are several customized C# IntelliPrompt providers that know how to use that mapping data and translate offsets so that automated IntelliPrompt is fully functional within the server tag regions of the main source document, yet based on the generated C# code.
Tricky stuff, but it works great!
The full source sample described above was added in the first v2014.2 release of our WPF, Silverlight, and WinRT/XAML controls and is available for you to check out.