Closed schinagl closed 2 years ago
wow. That is weird. @malxau-msft, can you confirm and also surface any other hidden behavior?
If you would like to debug this, the easiest way is to add debug_diff.txt and step by step go up and out with Shift F11, and then go down until you arrive around Sel_BlockHiLite(). I am sure with source this more fun:-)
is an innocent victim. The issue is that you can't press underscore without holding shift, and holding shift causes the list to multiselect everything between its current location and its new one. This can be seen by holding shift and pressing any alphabetic character. This behavior exists in NT 3.1, and the same behavior with can be displayed with many other characters - ~, #, ^, +, ...
I don't know if whoever added this to the list box intended it though. It's interesting that it wasn't carried forward into ListView, so explorer doesn't behave this way.
Then I would go with this Always select item with WM_CHARTOITEM. See comment in code
Problem
The directory pane suffers from some weird behavior of the list box. If you press _ it selects from anchor to caret:
But all you wanted was to type 'int_' have 'int_bla.dll' selected
Comments on the code
Well this was hard to find out, but it seems the used listbox in Winfile from comctl32.dll has a virtual key behind '_', which selects all items from anchor to caret. In wfdir.c:603 @ WMCHARTOITEM at the return of the 'case', the actual position is returned with respect to the typed character. If e.g. anchor = 2, and caret = 2, and this case statements returns 5, because the item with '_' was on the 5th position, then internally the caret is set to 5. This works perfectly as long the typed character is != '_'. If it was '\' the comctl32.dll magic happens, and it selects from anchor (2) to recently returned and set caret (5). But you don't want this.
To solve this we check for the magic '_' character and then select it via LB_SETSEL and thus correct anchor and caret before.
It is definitely comctl32.dll which causes this unexpected selection, because I debugged this and it happens within Sel_BlockHilite() inside comctl32.dll. If this is a bug or a feature, I don't know.
I also checked with a very old version on this branch, and this behavior is in ever since.