Introducing DevExpress WinForms Project Settings - Dropping Global Components

Throughout years of development, we have been adding components and static properties that allow you to instantly apply global settings across an entire project. Here are a few notable mentions:

  • DefaultFont - allows you to change the default font for all controls.
  • DefaultMenuFont - same as the DefaultFont, but affects only menus.
  • SetSkinStyle and the DefaultLookAndFeel component - theme an application using DevExpress skins.
  • ForceDirectXPaint - employs the DirectX engine instead of the default GDI+ rendering.
  • RightToLeft - specifies whether DevExpress controls should re-align to support locales with right-to-left writing.

While all of these definitely simplify the development process, we decided that centralized design-time access to all major project settings is even more convenient: you would have all available options right in front of you, out in the open, with no need to remember property names or manually add components.

That is precisely what are introducing in the v18.1 release. Whenever you start a new project, you can now right-click in the Visual Studio Solution Explorer and select DevExpress Project Settings to bring up a page that exposes major DevExpress project settings.

Project Settings

With this new settings page available, we are now able to deprecate certain global components. The first candidate is DefaultLookAndFeel, which has always caused issues when used incorrectly: it should be placed on the main project form only, but nothing stops a developer on your team from adding an instance to every Form or UserControl and creating a maintenance nightmare.

Note that we will keep the component available in the toolbox, to support scenarios where (out of habit or technical requirement) instances are added to forms at design time. An attempt to add a DefaultLookAndFeel instance will now trigger a message suggesting the settings page as a better alternative.

We might deprecate the DefaultBarAndDockingController for similar reasons — toolbars, menus, and docking MDI windows will now automatically recognize skins applied to parent forms and the component will be rendered useless.

We have spent much time taking all known use cases into consideration and we are not aware of scenarios that will cause issues. If you’d like to discuss your own circumstances, and especially if you believe that these changes will make your life harder, please don’t hesitate to get back to us and let us know!

We are also generally interested in your thoughts on these changes. Obviously the existing system has been unchanged in a very long time! Please get back to us if you have any comments, or suggestions for additional items that could be included in the settings page, perhaps repetitive project-wide actions you take every time you start a new project.

12 comment(s)
Alex Miller

I would prefer if it was an additional tab in the Project Properties. The project context menu is very-very crowded already. And this is likely something we'll set once when creating the project.

What exactly happen under the hood when we set the properties in that dialog? I have a 18.1 beta trial, I see the context menu entry, but it doesn't show the dialog.

3 April, 2018
David Gipson

OK. Looks great. When are you releasing it?

3 April, 2018
David Gipson

"That is precisely what are introducing in the v18.1 release. " When will this be released? I do not see it in my available downloads.

3 April, 2018
Dmitry Babich (DevExpress)

This feature is still under active development and will be released with the upcoming 18.1 release. We plan to make it available in May, 2018.

@Alex Yes, we have plans to embed our settings into the standard Project Properties window. We did some research in that area, but encountered some difficulties. Probably, we will manage to make it work by the official release.

3 April, 2018
Alex Miller

@Dmitry Great news. Centralizing all these settings is a really good idea.

I'm sure developing for VS holds many surprises :) I look forward to testing it.

3 April, 2018
Andreas Hess

We are dynamically setting a lot of DefaultBarAndDockingController fonts from code in application initialization. Will that still be possible?

3 April, 2018
Dmitry Babich (DevExpress)

@Andreas Sure, it will be possible. All corresponding classes will stay unchanged and your code will continue working as usual. Moreover, since the Settings page will contain only major settings, you are already using the best (and most robust) way to customize bar fonts.

4 April, 2018
Steve Sharkey

Sounds like a good plan to me. Always thought it was odd how it happened before but once you get used to it... It's just something you do - will be much clearer to new adoptees of DevExpress components.

4 April, 2018
Mohamed Al Zayani

Is this applicable to XAF?

4 April, 2018
Dennis (DevExpress Support)

@Mohamed: Yes. An XAF WinForms app is a regular .NET WinForms app built using DevExpress WinForms components for the UI. So, the DevExpress Project Settings context menu is available for the YourSolutionName.Win XAF project too. Changes in this dialog are stored in the app.config file and are in effect in the app. The only settings that will not be used by default are Skin Name and Skin Palette. That is because XAF manages skins using its own ChooseSkinController. Anyway, we already have a KB that shows how to integrate palettes for the Bezier skin in an XAF app:

Let me know in case of any questions.

4 April, 2018
Tomasz Jagusz

What about localization? Right now it is still very painful to remove default localizations and install new one (there are dozen of tickets for that, for example

Maybe You could add language selection to those properties?

Ideally when applying those settings missing localization DLL's should be downloaded and all unwanted should be removed.

6 April, 2018
Andrew Fraser

How do you now persist and reload a users choice of look and feel at runtime now you are deprecating the DefaultLookAndFeel component ?

I used to do:

UserLookAndFeel.Default.SkinName = Settings.Default.ChosenSkinName;


7 June, 2018

Please login or register to post comments.