Some hint as to work with DevExpress Skins (Designtime)

[Guest]

The DevExpress skinning system is a beast. Normally most things work well. However, when your TdxBarManager and your TdxRibbon component and their helpers and all becomes advanced and convoluted enough and especially when you are using visual inheritance the skinning system can get into update notification loops that can consume up to 15 minutes on a modern dev machine. I have found that the following actions will alleviate the problem;

 

1. For all of you projects; select "Project|Modify Skin options..."

1a. Uncheck "Enable Skin Support".

1b. Click "Default"

 

Now - you will not get into the "problem" of the IDE filling up your TForm units with skin units in the uses.

 

2. For all projects, put the TdxSkinController component on a DataModule and include that DM in your project. Copy all (desirable) skin units to this module. They are not needed anywhere else.

2a. The DFM setting of the component must be "UseSkins = false". Perhaps even "UseNative = false" but that i can not confirm.

 

Normally when you code and use the "Design" view in the IDE you never open the skinning unit.

This leaves the IDE completely without skinning. And THAT may help a lot and save a lot of time. At least here in my machine 🙂

 

Also note that if you have several projects in a project group, opening a project that was not prepared like above containing a TdxSkinUnit can start the notification loop hysteria for an opened unrelated project. That is the skinning update notification are IDE-global.

 

If you do not like the idea of having a separate DataModule, then disabling skins (2a above) might also help. One benefit, however, of putting the skinning in DataModule's is that you can have one with just the controller component and other ones with the skins uses clauses. You could then choose the "Only Bezier" for one distribution and "All Skins" for another.

 

HTH (Hope this Helps).

 

Regards!

 

I'm aware DX skins can be loaded dynamically, this post do not apply to that usage of DX skins.

Edited October 26, 2018 by Guest

[Guest]

Oh, BTW - when this start to happen you will see a lot of flickering toolbars as they would be represented floating dancing around at the top of the "design" view.

[Lars Fosdal 1793]

@Dany Marmur- Do you mind if we move this to the Delphi Third party section?

[Alexander Elagin 143]

I also came to the same solution a few years ago. I have a single datamodule responsible for visual settings which includes a SkinController, a set of required skins and skin support units - like dxSkinsdxBarPainter, dxSkinscxPCPainter etc - in the "uses" section and some other components and procedures (like DX string resources localization, skin switching etc.) This approach makes it extremly easy to customize an application without, well, polluting the "uses" section of all forms with skin-related modules.

Edited October 26, 2018 by Alexander Elagin

[Guest]

@Lars Fosdal, of course not 🙂 all whats best for the forum!

 

/D

[Guest]

@Alexander Elagin, the team seems too house-proud of their IDE plugins.

 

They should have been able to recommend me this approach from start. Instead i have two (one private) extensive tickets about it. Going over 4 months (!). It was when they suggested (after a lot of back-and-forth) that i uncheck "UseSkins" that i finally realised.

 

In previous project (2013.x.x) i coded mostly "dynamically" (i.e not very much in DFMs) and never saw this problem. This time i'm building the project differently, taking advantage of design-time functionality, so when this thing hit, it hit hard.

[Bill Meyer 337]

Good info. I am on the verge of tangling with that beast, and am glad I won't have to find my way to that approach on my own. 

 

I know  the DevExpress components are well liked, but I find a good deal of their stuff to be overly complex. And the documentation seems only to be reference material, not introductory and tutorial. Facing a 4,500 page reference manual is a lot like having no docs at all.

[Guest]

@Bill Meyer, some comments out of the air:

 

There is a learning curve, most definitely. IMHO it pays off in the end.

 

I will confess, i'm re-writing an application/framework and this time is the second using DX VCL. Last time i did a complete re-write was in 2010-2012, moving to DX from more or less pure VCL. When looking at that project... well... knowing so much more now i choose different approaches.

 

Without paying up for support it would be impossible. Often the team needs time to fish out facts regarding the products. The support-team IMHO, is not super-god at suggestion approaches (i.e. strategies) as they are very own-product-centric. Thousgh, i should say that the dev-team manages a huge codebase and they do it pretty well.

 

When they craft new stuff they do it /almost/ 100% by the book, this is very good for extend-ability. Sometimes when looking at a "new" component or library it's like "uh, this is already an application". Now let's tweak it!

 

If this forum can help you in the tackling, that would be great, no?

Regards and good luck!

 

/D