Selection in FormDesigner Structure barely visible when not focused

[PeterPanettone 157]

When you select an object in the FormDesigner Structure Panel, its visibility is very good when the FormDesigner Structure Panel is focused.

 

But when the FormDesigner Structure Panel loses focus, the selection of the object becomes barely visible:

 

 

Please compare the two colors. Can anyone confirm this?

Edited May 23 by PeterPanettone

[dummzeuch 1453]

I can confirm this. Unfortunately that's simply the default behaviour of any Windows program, and it gets aggravated by theming.

[PeterPanettone 157]

2 hours ago, dummzeuch said:

that's simply the default behaviour of any Windows program

This may be true if you use just primitive standard controls without modification. But couldn't a smarter design easily override this annoyance? Aren't there any smart UI developers at Embarcadero?

Edited May 23 by PeterPanettone

[corneliusdavid 175]

7 hours ago, dummzeuch said:

Unfortunately that's simply the default behavior of any Windows program, and it gets aggravated by theming.

Yes, this has annoyed me in nearly every Windows program for many years. I often want to highlight something or select a row in a list, then go to a different program and look back at the other program to type something in that is similar or whatever and when I look back, the highlight is gone until I switch focus back to that program. I don't understand why someone thought this was better and designed the OS this way.

[PeterPanettone 157]

8 hours ago, corneliusdavid said:

Yes, this has annoyed me in nearly every Windows program for many years. I often want to highlight something or select a row in a list, then go to a different program and look back at the other program to type something in that is similar or whatever and when I look back, the highlight is gone until I switch focus back to that program. I don't understand why someone thought this was better and designed the OS this way.

As I said, correctly configuring the control a developer could easily override this annoyance.

Edited May 24 by PeterPanettone

[dummzeuch 1453]

22 hours ago, PeterPanettone said:

correctly configuring the control a developer could easily override this annoyance.

No. It's not a matter of configuring the control. To overcome this annoyance, one must owner draw it, which is quite a lot of work.

The correct way would be to slap the stupid idiot^D^D^D^D^D^D^D^D^DUX designer at Microsoft who made this decision until he sees the light and reverts it.

Since this is not going to happen, every software developer must decide for himself whether he thinks it's worth the effort to fix this annoyance everywhere. Usually the decision will be to not bother unless his customers complain loudly and/or pay him for the effort.

Edited May 25 by dummzeuch

[PeterPanettone 157]

4 minutes ago, dummzeuch said:

The correct way would be to slap the stupid idiot^D^D^D^D^D^D^D^D^DUX designer at Microsoft

I didn't know you were violent or had violent fantasies.

[Uwe Raabe 1970]

I am not sure if that actually is a native Windows control. Given the context aware, mixed font style and color node drawing it could as well be a TVirtualTreeView descendant.

[PeterPanettone 157]

Usually, this behavior is controlled by HideSelection, which is nicely demonstrated in this example (try it out - it does work perfectly):

 

https://docwiki.embarcadero.com/CodeExamples/Sydney/en/HideSelection_(Delphi)

 

I don't know which control type Embarcadero uses for the FormDesigner Structure tree - but using a control type that supports HideSelection can easily overcome the annoyance.

 

Even a simple TTreeView has this property:

 

[PeterPanettone 157]

6 minutes ago, Uwe Raabe said:

TVirtualTreeView descendant

TVirtualTreeView is highly configurable. The developer only has to take 5 minutes and switch on his brain.

 

Moreover, look at my TTreeView example above where HideSelection = False.

Edited May 24 by PeterPanettone

[PeterPanettone 157]

34 minutes ago, dummzeuch said:

pay him for the effort

Embarcadero IS being paid for the effort.

[Uwe Raabe 1970]

43 minutes ago, PeterPanettone said:

The developer only has to take 5 minutes and switch on his brain.

Before doing so, the developer needs to get assigned a task for it. This requires the product management to schedule such a task, which itself requires that there actually exists a request for it. If there isn't already one in the issue tracker I suggest to create one.

[dummzeuch 1453]

1 hour ago, PeterPanettone said:

I didn't know you were violent or had violent fantasies.

You definitely don't know me. 👿

[dummzeuch 1453]

The control is actually a TVirtualStringTree (with the name "VirtualStringTree1" ... somebody else to slap).

[PeterPanettone 157]

17 minutes ago, dummzeuch said:

The control is actually a TVirtualStringTree

TVirtualStringTree allows the developer to customize the appearance of nodes, including their colors, even when the control is not focused. This can be achieved by handling the OnBeforeItemPaint or OnAfterItemPaint events and using the OnGetNodeData event to provide the data for each node.

[PeterPanettone 157]

1 hour ago, dummzeuch said:

You definitely don't know me. 👿

I assume you're not engaged in illegal activities. 😇

[PeterPanettone 157]

On 5/24/2024 at 11:46 AM, Uwe Raabe said:

Before doing so, the developer needs to get assigned a task for it. This requires the product management to schedule such a task, which itself requires that there actually exists a request for it. If there isn't already one in the issue tracker I suggest to create one.

I HAVE created one. But it was closed with the response: "Works as expected" (!)

[Uwe Raabe 1970]

Well, it is definitely not a bug, so in case you filed it as a bug the "Works as expected" is indeed a valid answer. A dimmed selection color is actually standard behavior for non-focused Windows controls.

 

Better file it as a feature request, as it asks for a change of the current, technically correct behavior.

[PeterPanettone 157]

9 minutes ago, Uwe Raabe said:

technically correct behavior

An error is also a "technically correct behavior," as the IDE, in that case, does not deliver the result expected by the user, i.e., working in a rational and efficient way.

[Lajos Juhász 264]

3 minutes ago, PeterPanettone said:

An error is also a "technically correct behavior," as the IDE, in that case, does not deliver the result expected by the user, i.e., working in a rational and efficient way.

 

It does deliver according to the MS user interface guidelines. You don't have to like it, however the norm in UI design is to follow the OS guidelines as most of the users expect that.

 

[dummzeuch 1453]

3 minutes ago, PeterPanettone said:

An error is also a "technically correct behavior," as the IDE, in that case, does not deliver the result expected by the user, i.e., working in a rational and efficient way.

In that case you should file a bug report on Embarcadero's definition of bug. Good luck with that.

 

Or, you could simply heed Uwe's advice to file a feature request for what you actually want them to do.

I think your chances would be much better with that, but I still wouldn't hold my breath.

[Lajos Juhász 264]

5 minutes ago, dummzeuch said:

that case you should file a bug report on Embarcadero's definition of bug. Good luck with that.

I believe it would be easier to push Microsoft to change the decisions how the User Interface on Windows should work.

[dummzeuch 1453]

2 hours ago, Lajos Juhász said:

I believe it would be easier to push Microsoft to change the decisions how the User Interface on Windows should work.

Hey, we are back to slapping the UX designer who made that stupid decision. 😉

[Lajos Juhász 264]

1 minute ago, dummzeuch said:

Hey, we are back to slapping the UX designer who made that stupid decision. 😉

 

I am on the side of the current Windows UI.

[JonRobertson 58]

On 5/27/2024 at 4:11 AM, Lajos Juhász said:

I believe it would be easier to push Microsoft to change the decisions how the User Interface on Windows should work.

Probably. Microsoft changes how they think the Windows UI should work on a regular basis.