About Us

Actipro Software
is a leading provider of .NET user interface controls for the WPF, UWP, Silverlight, and WinForms frameworks,
and is most well-known for their SyntaxEditor syntax-highlighting code editor control.

Alongside the development of Docking/MDI vNext for WPF, we have been working on porting our WinRT/XAML Controls to the Universal Windows Platform (UWP). This is a full port of our existing controls available for the WinRT/XAML platform, but made for UWP and Windows 10 app development.

We are currently looking for beta testers for these controls. If you would like to participate in beta testing, please contact our support address.

We've spent the last several months working intensely on completely rebuilding the internals of our market-leading WPF Docking/MDI product. This project is called "Docking/MDI vNext" and keeps the same general API surface, while providing even more advanced features in every area of the product, evolving it into a true best-of-breed docking tool window and MDI functionality solution.

Project Status

Great news… after several months of development and testing, Docking/MDI vNext is now out of beta and considered complete! Check out our recent blog posts to see a list of several of the major features that are included in this new version.

The updates we made will be released as part of our WPF Controls 2016.1 offering that will likely officially roll out live in January or early February. We'll have a full summary of the new features on the blog then.

Looking for 2016.1 Preview Testers

If you would like to get a preview build of 2016.1 and start working with everything now, please write our support address. The major Docking/MDI vNext updates are considered code complete and stable at this point. We have new and updated samples and documentation, updated Prism 6.1 compatibility, and a lot more. The documentation gives detail on all new features and any breaking changes you might encounter. We'd love to get some more users including it their apps and giving us some final feedback before a public release.

We've spent the last several months working intensely on completely rebuilding the internals of our market-leading WPF Docking/MDI product. This project is called "Docking/MDI vNext" and keeps the same general API surface, while providing even more advanced features in every area of the product, evolving it into a true best-of-breed docking tool window and MDI functionality solution.

Beta Testing Progress

A couple weeks ago we began the beta testing process for Docking/MDI vNext and thus far, it's been going very well. The product has proven to be very stable and only a handful of minor tweaks and adjustments have been needed. At this point, the product is considered feature-complete for its first shipping version.

We've been spending time during this beta testing period improving some samples and adding/updating lots of product documentation. There are an enormous number of new features in vNext, so we want to make sure we cover everything.

What's Next

Our plan is to launch final 2015.1 version maintenance releases next week and then start transitioning internally to 2016.1 codebases. Then we'll begin swapping in Docking/MDI vNext in place of the classic Docking/MDI product and will get all the related samples, documentation, etc. merged and ready to go.

We've spent the last several months working intensely on completely rebuilding the internals of our market-leading WPF Docking/MDI product. This project is called "Docking/MDI vNext" and keeps the same general API surface, while providing even more advanced features in every area of the product, evolving it into a true best-of-breed docking tool window and MDI functionality solution.

Call for Beta Testers

We've been posting on our blog about many of the major new features coming your way in vNext. We're pleased to announce that all of those features are now code-complete and we are preparing for a private beta test.

We already have received numerous beta tester requests. If you have written us, we will be contacting you in the next several days!

If you are an existing customer and haven't yet contacted us about being a beta tester, please write our support address, tell us how you plan to use the vNext beta in your applications, and we'll get you signed up into the beta program. We look forward to hearing from you!

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, we'll show a new feature coming in Docking/MDI vNext that lets you limit floating window sizes.

Feature Description

Let's first have a look at a typical docking window layout here, where we have several tabbed documents that take up much of the screen real estate.

What happens when you drag to float a document, or float it via its context menu, is that you normally get a floating window of the same size. You can see this in the next screenshot, where much of the entire dock site is now covered by the floating window.

While apps like Visual Studio do this, we've added the ability for you to limit how large you want the floating window to be. In this last screenshot, we've handled a new dock site event that lets us customize the floating window size before it's displayed. We've limited its size to a maximum of 600x300 and the result is this appearance when the document is floated:

We personally like this feature because the document is still a decent size but doesn't obscure everything behind it.

Summary

The feature described above is completely optional. By default, everything will work as in the second screenshot when you float a large document. But by handling the new event and applying some size-limiting logic in it, you can easily get results like in the last screenshot.

Docking/MDI vNext is currently near the end of its code development stages. 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.

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.

As mentioned in the previous post, we are currently working on enhancements for the MVVM support our Docking/MDI controls provide. In today's post, we'll talk about new code being added that allows you to specify a default location for new tool windows that are opened.

Feature Description

As in the current version, when a tool window has already been in the dock site layout and then is closed, it leaves a breadcrumb behind so that it knows exactly where to appear when reopened later. In vNext, for tool windows that are being opened for the first time and don't yet have a breadcrumb available, default location information is now requested.

The new DockingWindow.WindowGroupName property can be set on tool windows that have an affinity. Each window in a 'group' should have the same property value. A window being opened for the first time will look for other open members of the group in the same state so that it can attach to them.

DockingWindow also has a new DefaultLocationRequestAction property that can be set to a lambda that is passed a special event args instance. The event args allows you to programmatically designate a dock target (such as a dock host or other tool window) and optional side upon which to dock. Then the new DockSite.WindowDefaultLocationRequested event fires and allows for the similar logic to be applied, but at a centralized location.

If no dock target is designated by the action or event, then the window will dock against the primary dock host using the side specified by the window's new DefaultDockSide property.

Summary

With the properties and events mentioned above, vNext now gives you full control over where brand new tool windows will open in a layout by default. These capabilities are essential for MVVM scenarios.

If you don't want to get into writing any code, simply set the WindowGroupName and DefaultDockSide properties. Or if you do wish to have more complex logic and find-grained control, use either the DefaultLocationRequestAction or WindowDefaultLocationRequested event to supply your logic. The choice is yours!

Docking/MDI vNext is currently still in mid-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.

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.

As mentioned in the previous post, we are currently working on enhancements for the MVVM support our Docking/MDI controls provide. In today's post, I'd like to list some key updates that will improve MVVM usage.

IsOpen and IsActive Properties

In the current version of Docking/MDI, you are able to two-way bind to the DockingWindow.IsOpen property. When set to true, the docking window will be opened and added to the layout. Likewise, setting IsOpen to false will close the docking window and remove it from the layout.

For vNext, we're adding an IsActive property that effectively returns when DockSite.ActiveWindow is the docking window. A number of customers requested that we add this property and make it settable. If you bind to the property and set IsActive to true, it will not only open the window, but will also ensure it is activated (has focus).

State Property

The current version has a DockingWindow.State property, but it is read-only. For vNext, we are adding a setter so that your view models can bind to it. As an example, this allows you to create a new tool view model, set its State property to AutoHide, and then set IsOpen = true to effectively open the container tool window in auto-hide state.

No Need for an Attached Behavior

The current version requires an attached behavior for MVVM scenarios that would watch DockSite events and open/position docking windows appropriately. With the various property and functionality enhancements we're making, this no longer is needed for common scenarios.

Specifying a Default Dock Location - Feedback Wanted

A next step we are going to be working on is how to specify the default location for tool windows that are created in MVVM scenarios. We want your feedback for this. Please let us know how you'd like to be able to specify that a container docking window should default dock to the right side of the dock site, or dock below another tool window, or attach to another tool window, or auto-hide to the bottom, or float at a location, etc. for MVVM scenarios. Now is the time to submit your feedback for this feature. Thanks for your help!

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.

Our current production version of Docking/MDI fully supports the optional MVVM pattern for managing both tool and document windows. The design generally follows that of a standard ItemsControl.

We are revisiting all of this right now in our vNext implementation and want to hear from you, our customers, on what improvements or feature additions would help you out when working with MVVM-based docking windows.

What API additions/changes would you like to see?

What MVVM-related functionality would you like to see added?

What are any pain points you've encountered with MVVM support in the current version?

What MVVM framework, if any, do you use within your app that you'd like to integrate docking windows with?

If you could reply to the above questions in the comments or email our support address, it would be most welcome. Now is the time to send your feedback as we are currently working in this area. Thanks!

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 our previous post, we showed several new tabbed MDI features including read-only glyphs, tab layout kinds, and context menu options. In today's post we'll show another new feature coming to tabbed MDI, which is the optional new tab button.

Feature Description

When the new tab button is enabled, a button shows up at the end of the tab list. This tab button is best used when the tab overflow mode is set to shrink tabs. Upon clicking the new tab button, an event fires allowing you to be notified that the end user is requesting a new tab.

Here's a small demo we made with tabs that look like a Chrome browser. The animation sequence shows how tabs can be dragged around in an animated fashion and then when the new tab button is clicked, new tabs are added.

The sample above is using a completely custom tab and new tab button chrome. Default styling of a new tab button has a plus button glyph.

Summary

New tab buttons are great for use in certain application scenarios such as browsers. vNext easily brings the option of using them to your own apps.

Docking/MDI vNext is currently still in mid-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.

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 the last post, we showed how vNext will support full-featured tabbed MDI with docked tool windows in a floating container. In today's post, we will focus on several other new features coming to tabbed MDI.

Feature Description

First, we have a new built-in read-only glyph that shows in a tab when the document window is marked read-only. You can see it at the beginning of the animation sequence below.

Second, we've added the ability to designate the kind of layout a tab will use when in tabbed MDI mode. The default option is Normal. There also is a Pinned layout kind. Pinned tabs appear to the left of normal tabs and have an unpin button on them. When unpinned, a pinned tab returns back to Normal state. A third state is a Preview state where the tab appears on the right side of the container using an alternate appearance, and has a Keep Tab Open button on it, also available on the context menu. Clicking that button returns the tab to a Normal state. A preview tab is generally used as a temporary tab that can disappear when no longer needed.

Third, we've added more menu items to the context menu that shows for tabbed MDI. In the animation sequence, you can see new Close Others and Close All Documents menu items. Close Others will close all other tabs in the same container. Close All Documents will close all tabs in any tabbed MDI container.

Summary

These are all advanced features that have been requested by our customers and are coming to Docking/MDI vNext.

Docking/MDI vNext is currently still in mid-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.