PeterPanettone 157 Posted May 23 (edited) 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 Share this post Link to post
dummzeuch 1456 Posted May 23 I can confirm this. Unfortunately that's simply the default behaviour of any Windows program, and it gets aggravated by theming. Share this post Link to post
PeterPanettone 157 Posted May 23 (edited) 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 Share this post Link to post
corneliusdavid 183 Posted May 23 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. 2 Share this post Link to post
PeterPanettone 157 Posted May 24 (edited) 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 Share this post Link to post
dummzeuch 1456 Posted May 24 (edited) 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 2 Share this post Link to post
PeterPanettone 157 Posted May 24 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. Share this post Link to post
Uwe Raabe 1979 Posted May 24 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. Share this post Link to post
PeterPanettone 157 Posted May 24 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: Share this post Link to post
PeterPanettone 157 Posted May 24 (edited) 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 Share this post Link to post
PeterPanettone 157 Posted May 24 34 minutes ago, dummzeuch said: pay him for the effort Embarcadero IS being paid for the effort. Share this post Link to post
Uwe Raabe 1979 Posted May 24 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. 1 1 Share this post Link to post
dummzeuch 1456 Posted May 24 1 hour ago, PeterPanettone said: I didn't know you were violent or had violent fantasies. You definitely don't know me. 👿 1 Share this post Link to post
dummzeuch 1456 Posted May 24 The control is actually a TVirtualStringTree (with the name "VirtualStringTree1" ... somebody else to slap). 1 Share this post Link to post
PeterPanettone 157 Posted May 24 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. Share this post Link to post
PeterPanettone 157 Posted May 24 1 hour ago, dummzeuch said: You definitely don't know me. 👿 I assume you're not engaged in illegal activities. 😇 Share this post Link to post
PeterPanettone 157 Posted May 27 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" (!) Share this post Link to post
Uwe Raabe 1979 Posted May 27 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. 1 1 Share this post Link to post
PeterPanettone 157 Posted May 27 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. Share this post Link to post
Lajos Juhász 270 Posted May 27 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. Share this post Link to post
dummzeuch 1456 Posted May 27 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. Share this post Link to post
Lajos Juhász 270 Posted May 27 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. Share this post Link to post
dummzeuch 1456 Posted May 27 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. 😉 1 Share this post Link to post
Lajos Juhász 270 Posted May 27 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. Share this post Link to post
JonRobertson 63 Posted May 28 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. Share this post Link to post