How does the classic Win32 ListView handle incremental searching?
The classic Win32 ListView supports incremental search: You can start typing the name of an item to search for it. But it’s a bit more complicated than that.
You see, there’s more than one way that people expect type-to-search to work. In one pattern, you type the first letter of the thing you want, and the system finds the first item that starts with that letter. If that’s not the one you want, you press that same letter again, and the system finds the second item that starts with that letter. Keep pressing that same letter until you get to the item you want. This is how list box searching worked in Windows 1.0.
Another pattern is to type the first letter of the thing you want, and the system finds the first item that starts with that letter. If that’s not the one you want, then type the second letter of the thing you want, and the system finds the first item whose first two letters match the letters you typed. Keep typing more and more letters until you get to the item you want.
Which pattern should the classic Win32 ListView control use?
If you type the same letter over and over again, then the classic Win32 ListView assumes that you are using the first pattern, and each time you press the same letter again, it selects the next item that starts with that letter. But if you type different letters, then the classic Win32 ListView assumes that you are typing a prefix, and it selects the first item that starts with that prefix.
For example, suppose that you have a ListView with the following items:
- Cougar
- Leopard
- Lemur
- Lion
- Llama
- Tiger
You type L, and this selects Leopard, the first animal on the list that begins with L.
You type another L. Since this is now two L’s, the Win32 ListView is in “repeated letter” mode, and it selects the second L-animal, which is Lemur.
Now you type A. This is no longer a repeat of the same letter, so the Win32 ListView switches to “prefix” mode, and it selects the first item which begins with “LLA”, which is Llama.
Light
Dark
18 comments
It seems funny at first glance, but when think about it, it makes some sense.
It makes sense until you want to find the item named “LL” and there are thousands of items between it and the first item beginning with L.
The fact that most computer keyboards come with a Down Arrow key might be the reason why I never knew the first mode of type-to-search existed.
I knew the first mode existed back in the days of Windows 3.x, but I thought it had been replaced by the second mode in the Windows 95 era (makes sense for large lists of items: type the first three or four letters to navigate near the item you want, then use the down arrow to hit the target). In fact, my owner drawn list control implements just a version of the second mode (complete with a timeout reset, so you can start typing another sequence right away if you don’t find what you want).
I love the Win32 list view control.
And the company I work for (as a software developer) uses it very, very extensively.
Win32 may not be the newest and hottest platform, but it is absolutely amazing. It is extremely well suited for keyboard-heavy power users and its long-term stability is simply outstanding. Apps you wrote 20 years ago or more still work on Windows 11. And I feel confident that the Win32 apps I develop today will still work 20 years from now.
This is why I love Win32.
This is also why I love WinForms, since most of its controls are wrappers over the Win32 controls.
this comment has been deleted.
This comment has been deleted.
I also love WinForms, especially since the Form Designer is one of the best available. I just can’t get any decent GUI done with text based sourcing (XAML, HTML, MAUI, what the hell is that even?)
It’s a blessing but also a curse. Being Win32 based it brings a whole can of issues when you want to do custom drawing of the controls. E.g. a tree view control with custom drawn nodes looks fine on first glance, but the whole animated expanding/collapsing animation wreaks havoc on the passed device contexts.
Every now and again I attempt to do a GUI system similar to forms, but with fully managed background.
But on the other hand it’s just so much you have to do: All this keyboard handling is so important, also accessability (which someone seriously botched with Forms .NET 6.0, try clicking a button that shows a modal OpenFileDialog)
You don’t need a graphical designer with XAML because it’s all flow-based and does a superior job of filling available screen space with information and child controls. If you create Hello World in a XAML project and immediately jump to Canvas for absolute positioning, you missed the whole point.
Flow based GUI is nice for cute little mobile apps where controls fly all over the place. But not for productive GUIs. Try building something like Visual Studio or any application with more than 5 buttons on a dialog.
Users HATE shifting layouts.
@Georg Rottensteiner Visual Studio GUI is literally made with XAML, as is the majority of Windows 11 shell at this point; It is perfectly possible and reasonbly easy to do so, but like any technology with a different paradigm it’ll take time to adjust where you’ll most be fighting to reconcile differences in approach and looking down upon any difference rather than appreciating the reason for it. The styling/templating and animation system of XAMKL for example is a massive boon.
The only problem with XAML is that it’s nearly impossible to position and size controls in absolute coordinates. (e.g. 75 px wide by 23 px high, 11 px from right edge and 11px up from bottom edge)
The other issue is that it doesn’t support Dialog Units. (e.g. 50 horizontal dlus wide by 14 vertical dlus high, 7 horizontal dlus from the right edge, 7 vertical dlus up from the bottom edge).
https://i.stack.imgur.com/PgNaP.png
“I just can’t get any decent GUI done with text based sourcing”
Visual Studio itself is actually built of WPF\XAML, so it is possible, but probably 100x more work. But I guess it is the price to pay for total isolation of code and UI (if that is a goal).
WinForms is what MFC should have been, if Microsoft teams weren’t so against following the developer experience from other C++ vendors, like OWL, VCL, Qt.
Sadly they never produced another worthwhile C++ framework for Windows development (nope, WinUI C++ isn’t it).
So we’re left with WinForms, WPF and eventually calling into native libraries for the C++ stuff that might be needed.
After over a decade of using and mastering WPF, I can tell you there isn’t a single application I would pick C++ over C# for. When there’s enough language boilerplate it can create a lethargy that prevents you from really filling out algorithms properly.
I hate how we lost a lot of these little niceties in the XAML world, like the people who created the control libraries either didn’t care, weren’t power users, or totally lacked long-term vision. Lasso selection is another one.
It seems unfortunate that the “prefix” mode only works if the list is alphabetically sorted – as soon as it isn’t, the search becomes repeated-letter-mode only. Is there a good reason for that?
(For the specific example, someone decided to stick a “Match Windows display language” at the very top of the region list in intl.cpl, and now instead of being able to type “Lit” I have to press “L L L L L L L L L L L L, oops I overshot it, UpArrow” every time.)
“Classic ListView”.
Man i’m old.