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.
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.