WinForms Default Settings: Some changes afoot in v17.1

Default settings: they can be a force for good and then quite quickly they can be a right royal pain. After all, when we supply some advanced functionality as part of our suites and controls, it’s good to have a reasonable default setting for the new property or behavior. The issue then becomes what happens when we add some more behavior and suddenly the current default setting is no longer the optimal or better one. What to do? Alter it and have it result in some breaking change in your app? Mmm.

Wrenchv17.1 of the WinForms suite of controls brings numerous new features, features that we are starting to describe in blog posts. As part of these new, and we hope, better features, we’re changing some default settings. First, let me list the changes I’m talking about, and then I’ll describe how we’re going to mitigate them.

  • With the Data Grid, Vertical Grid and Tree List end-users will be able to modify unbound columns' expressions by using the advanced Expression Editor dialog, which supports auto- completion and syntax highlighting.
  • Automatic filtering rows for Data Grid and Tree List now allow end-users to change the filtering condition from the default "Equals" (or "Like") to any other condition, e.g. "Starts With" or "Is Not Like".
  • Data Grid now prefers speed rather than absolute precision when calculating the best widths for columns.
  • Excel-inspired filtering menus are now the default filters for Data Grid and Tree List controls.
  • End-users can now hold the "Ctrl" key when dragging Data Grid column headers to the group panel. This allows end-users to apply joint data grouping by multiple columns at once.
  • The default Ribbon style is now "Office 2013".
  • Tree List control now enables filtering and shows its Find panel out-of-the-box.

I’m sure that you’ll agree that these changes and defaults are very beneficial to your users, but I’m sure there are occasions when you’d rather introduce such changes in a step-wise fashion over a period of time rather than just have them all suddenly appear when you upgrade to v17.1. For new apps, sure, have at it, let’s use them all.

To help you out, we have also added a new static property: DefaultSettingsCompatibilityMode. To revert all these defaults to their previous values in one go, simply change this property value from Latest to v16. (Refer to this documentation article to see the complete property list this setting affects.) I’m sure you can see where this is going in the future: adding other enumeration values for later version numbers to revert defaults back to a known point.

WPF Rich Text Editor: Upcoming Breaking Change

Starting with v17.1, we are improving how we generate the ribbon for the WPF Rich Text Editor with regard to where we source the images used. Although we shall be maintaining the current behavior alongside the new enhancements for v17.1, this backward compatibility will be removed in v17.2, causing a possible breaking change.

WrenchCurrently the ribbon generation process uses images from two different sources: the DevExpress.RichEdit.Core.dll assembly, as well as the WinForms Rich Text Editor (no, that is not a typo!). To put it mildly, this is not optimal. In v17.1, we have copied these images to the DevExpress.Images.dll assembly as well, and the new ribbon generation code for the Rich Text Editor will source the images from there. However, this could cause a breaking change since we are referencing an assembly that you may not be deploying as part of your app.

Please note that the images are exactly the same, they are just provided in a different assembly.

Of course, this double collection of ribbon images could be a source of future bugs: we have to ensure any new or changed images are compiled into two completely different assembly sets. Indeed you could view this as a special kind of “code duplication”. Hence, in v17.2 we shall be removing these Rich Edit ribbon images from the Core assemblies, and from then on they will only be available from the Images assembly.

To avoid future problems, when you upgrade to v17.1, please ensure that the DevExpress.Images.dll assembly is included in your build process.

DevExpress VCL Subscription: Tokyo or Bust!

Tokyo at nightLast week, Embarcadero released the next major version of RAD Studio, v10.2. In keeping with their new convention of naming major releases after major cities (Seattle for v10.0, then Berlin for v10.1), this particular version is named after Tokyo. Welcome to RAD Studio 10.2 Tokyo!

As it turned out, supporting this particular version was not too onerous: the changes for code targeting VCL on Windows are small and easily catered for. (The main new feature is of course Linux support for server apps, something that  does not fall within our user experience purview.) Consequently, I am able to announce that we have already added support for RAD Studio Tokyo in v16.2.5.

Even better: it’s already ready for downloading from the Client Center: just log in and click the download link. The trial version also has been updated to install with Tokyo.

Enjoy!

(Tokyo by Moyan Brenn, on Flickr. CC 2.0 license.)

Visual Studio 2017 launch: our products are ready, are you?

Today, March 7, is a big day in the Microsoft developer world: Visual Studio 2017 has been released.

VS2017 launch date - 7 March 2017

So, where does DevExpress stand with regard to our .NET products? Will we be ready? Will you be able to download VS2017 on Day One and use your favorite user interface controls, tools and frameworks with it? I’m sure it will come as no surprise that we have been diligently working with the betas of VS2017 to ensure that you can start immediately.

In fact, on February 28 (a week ago) we released DevExpress Universal and DevExtreme 16.2.5 as well as CodeRush 16.2.6, and it is these builds which have our official support for VS2017. So if you are a “real” active customer, staying abreast of our latest releases, you already have the right bits for the Visual Studio 2017 launch. There is nothing else to download.

I’m certainly ready for this new version of Visual Studio. VS2015 is so passé! VS2017 is where it’s at!

DevExpress Logify: Readying for release

Six weeks ago I announced a brand new product from DevExpress, a crash reporting tool codenamed DevExpress Logify, and invited customers to apply for the initial beta. I can report that the beta so far has been a success: we’ve been able to validate our expectations about the kinds and rates of crash reports third-party applications might produce, and have started fine-tuning our logging servers and reporting subsystems. That work continues (and I dare say will never stop), but we are getting very close to release.

Logify

In this post I would therefore like to expand on the pricing structure we’ve decided on for Logify. In essence, customers will be able to purchase one of several service bands or levels of Logify tooling.

Firstly, we will be providing a 30-day trial of the product for new users. This gives those customers the ability to test Logify and the various clients, see what it can do, and even more importantly provide an estimate of how many logs their applications produce.

Secondly, here are the various levels, and the pricing list for each. All levels provide for the use of all platform client libraries (currently: .NET, JavaScript, and node.js), a general template for notifications, predefined rules for automatically ignoring certain exceptions, and the ability to read and use map files for JavaScript applications (a.k.a. “unmapping”).

Starter level: $50/month. This level has a limit of 30,000 reports per month, for up to 20 application keys, and allows for customized settings.

Standard level: $150/month. This level raises the report limit to 300,000, for up to 100 application keys, and allows for customized notifications and provides access to all the auto-ignoring settings.

Premier level: $300/month. This level includes: up to 500,000 reports per month, unlimited application keys, attachments, minidumps, and a programming API.

Of course, should you have requirements for even greater customizations, or a greater report count, please contact us for some custom pricing.

During this transitory period as we make the final preparations for release, we would still encourage you to apply for the beta, especially as we have now published the proposed pricing structure. Remember: In order to join the beta we will need to understand the basics of your application, what devices and run-times it runs on, the competency of your user base, and so on. If you wish to be considered for the DevExpress Logify beta, please contact us by email (support@devexpress.com), with a subject line of “Logify Beta”, and we’ll follow up with a short questionnaire.

More Posts