[HeDiBo]

No change in 9.15 :huh:

[HeDiBo]

All problems solved:a3:

[HeDiBo]

'Support' wrote:

Sorry, just I don't know how to change this color.

Same problem for TcxRadioButton. Also in AC 9.15 :huh:

[HeDiBo]

This was my mistake. I did not set the NativeStyle to False :blush:

Problem solved.

[HeDiBo]

'Support' wrote:

It's worse because tested with latest version of DevExpress.

I will test it with old DevExpress now.

Although it's better now, the background of the down arrow is still not skinned properly:

[attachment=6890:DevExprBtnControl2.jpg]

[HeDiBo]

'HeDiBo' wrote:

However checkboxes that are disabled in a TsCheckListBox are still hardly different from enabled ones.

It would be better to dim the checkbox's text also, like DevExpr does.

Another problem is that the DevExpr TcxCheckListBox is not skinned in dark skins like TsChekcListBox is.

No changes in AC 9.15 :huh:

[HeDiBo]

Solved :a3:

[HeDiBo]

Solved :a3:

[HeDiBo]

'Support' wrote:

You are right, I will change it in the next release.

Solved :a3:

[HeDiBo]

'Support' wrote:

Thank you. But, you see this global blinking when application is activated/deactivated?

What you think about that?

First of all: the skin problems are there regardless of the selection issue. The sample project is simply an easy way to show these skin problems.

I tried to run programs that would show this global change. And there were not many. I started a text editor and highlighted some text: that changed color, but not so much that it bothered me. You really had to look to see it. When I ran a heavy program (LibreOffice) I saw the blinking you referred to. I can understand that this is unacceptable.

I also tried to find out how selection was set up by Windows messages. That would be a starting point of customizing the selection color (make the system ignore the message and do it yourself). But I could not find such messages :huh:. I have no idea how a selection is painted. Maybe you have some idea about this?

[HeDiBo]

I have modified the CheshireCat project to have a quick look at the effect with different skins.

I noticed a number of problems with some skins:

• The following skins have no contrast between highlighted text and highlighted background, making the text unreadable: DarkMetro, DarkMetro_contrast, MacOS2, Matrix, Matrix_contrast, Ubuntu, Underwater, Winter2003
• The next skins have no distinction between a normal background and a highlighted background making selection disappear: Emerald, Nautilus, Nautilus_contrast, Steam, Steam2,
• The Subway and Zest skins are flawed because they change the background color when the mouse hovers over it.

All these problems can be viewed in this project: [attachment=6886:CangeSysColor.zip]

[HeDiBo]

'HeDiBo' wrote:

Although the skinning is now much better, now the down arrow at the right end of the control is missing. This is now true for all skins. Here is the Cappuccino skin again:

[attachment=6874:DevExprCalendar.jpg]

Not fixed in AC 9.14 :wacko:

[HeDiBo]

'CheshireCat' wrote:

when colors are changed in this way, the user of your software should be able to turn off this behavior, for example via a menu option 😉

I agree. There should be a property in TsSkinManager, since it's an application wide setting.

[HeDiBo]

'Support' wrote:

I see now, the DrawingStyle property have influence.

You're right. DrawingStyle gdsThemed has the dark skin problem.

Isn't it just a matter of keeping the original DrawingStyle when grid must be skinned and setting it to gdsClassic. Then restoring its original if skinning is switched off?

I also noticed that in dark skins the row and column lines are too pronounced. I'll make a new topic of that.

[HeDiBo]

'Support' wrote:

Colors are changed in all applications in the system. You think, it's good?

It's not very good. But restoring the old colors when the application is deactivated and setting them on activate does not harm much. It's not perfect, but better than it's now.

[HeDiBo]

'Support' wrote:

Same demo as in other topic?

I has this effect in the demo if SkinData.CustomColor is True.

The color of background is White as defined in the “Color” property and Font color is taken from skin (gray).

It's the same demo, showing two problems with skins.

SkinData.CustomColor is False, as you can see in the demo. So, that's not the reason.

[HeDiBo]

'Support' wrote:

Sorry, test project is not attached.

Sorry, edited the post to attach it.

[HeDiBo]

'CheshireCat' wrote:

I have just tested it with the Activate and Deactivate events, it works reasonably good, but is of course not an optimal solution.

Maybe my simple solution can be expanded 😉

Well, it's already much better than what we have now. What do you think Serge?

[HeDiBo]

'Support' wrote:

I will think, but I can't promise a fast implementation of this feature.

Not to worry, I never use these dark skins myself. They are too gloomy for me.

However others may want to use them and the navigator is not good with dark skins.

[HeDiBo]

'HeDiBo' wrote:

That's even a better name. Like it :a3:

Good job. Contrast skins added to 9.13 :a3:

[Author]

Posts