RadioGroup layout

[bazzer747 25]

I have a RadioGroup setup with all letters of the alphabet (for filtering surnames on first letter). The items are entered A, B, C, D, E ... etc and are spread over 9 columns and 3 rows (dictated by the space available on a form.

However, the buttons don't display in a left-to-right format but a top-down format, so along the top row I see A, D, G, J ... etc. and A, B, C are column 1, D, E, F column 2 and so on.

 

This layout isn't very User friendly in my view, and I suppose I could add the items in an order that visually fixes it so the top row reads A, B, C, D ... etc. 

 

Just wondering if there is another way? (Couldn't see a property that does this; BiDiMode I thought might do it but doesn't).

[Stano 143]

Use the GroupBox, place RadioButtons on it and group them. Thus, only one can be selected/checked.

[Guest]

I would suggest a panel with speedbuttons. Create it dynamically. You can keep it narrow or let it reflow if it's is made wider. "Modern" VCL have some layout-reflow classes, i have not used them, but they might come in handy. Cannot say. Speedbutton advantage is that it will not "take" focus from the control that is "navigated".

 

I also agree that the "tile" way of displaying lists (you see in in windows explorer too except for "details") is bad. I would quess it's a cultural thing.

Edited September 27, 2020 by Guest
advantage of speedbutton

[dummzeuch 1505]

SpeedButtons have the drawback that you can't select and press them with the keyboard. I wrote a hack for simulating SpeedButtons with BitButtons which gets around this limitation.

 

But on the other hand, if you have a keyboard, you could simply press the appropriate key rather than fiddling with the mouse....

[David Heffernan 2345]

Imagine if you have users with names that don't begin with one of the 26 letters used in the English language? 

 

What you should do is abandon this UI approach and let the user type. 

Edited September 27, 2020 by David Heffernan

[Guest]

The UI approach is often constrained by clients who has gotten the idea that since they pay, they can destroy the project with bad ideas. Mainly because the users are terrified of having to re-learn anything. In my experience, after whining a bit, when the product is useable, they have often forgot about the "disaster". Humans are easier to "meld" than [UI] code.

 

However, if this is a requirement, then it is. When i was forced to implement a "A-Z control" i let the control read off the already compiled "filter list" (unique column values of a grid). So if anyone has the name Önneforss then the Ö will have a button that comes in the end if the user has a germanic-based language and after O if it is set for English or some other language that do not recognize "Ö" as a letter, but surely this is basic stuff that even end-users can understand, and i do not see the relevance of discussing it here. But as always, the more dynamic eye-candy you implement, the more the cores on the client machine will have to work. Ending up with a "sluggish" UI is a dire possibility and after measuring you could suggest your clients to type instead.

[aehimself 396]

13 minutes ago, David Heffernan said:

Imagine if you have users with names that don't begin with one of the 26 letters used in the English language? 

 

What you should do is abandon this UI approach and let the user type. 

Indeed. This reminds me to https://qz.com/679782/programmers-imagine-the-most-ridiculous-ways-to-input-a-phone-number/