A. Current status; just more realistic test case
For to have a more real-life impression showing the impact of the remaining part of the issue that is not yet covered by the patch, i created a test case using a ShellViewDemo i picked up from an older discussion in this forum. (Attached)
My motiviation to post this is to show that it is not a purely theoretical thing.
- Select a larger folder in the treeview, eg. C:\Windows\System32 or (hard-core:) C:\Windows\WinSxS
- In the listview, press <Ctrl><End> for to go to the end of the list
- Click the last row ... and wait ... wait ... until a message box appears that tells which item had been selected
More than 6 seconds for "System32", 30 seconds for "WinSxS" ...
That's exactly the situation i'm having in my own app.
New behaviour since 2.2. RC1.
B. Solution compromise
The following modification of TCustomListView.GetSelection would (equivalently to reverting the RC1 patch which caused the issue) regain the full speed of 2.0.12 with the price, of course, to return again a last element instead of the first element.
if not (lffSelectedValid in FFlags) or MultiSelect then
begin
FSelected := nil;
// d7_2_laz: Patch https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39324
if (not FOwnerData) or (FOwnerData and (FSelectedIdx > 0)) then begin
if (MultiSelect And (FOwnerData and (FSelectedIdx > 0))) then
FSelected := Items[FSelectedIdx]
else
for i := 0 to Items.Count - 1 do begin
if Items[i].Selected then begin
FSelected := Items[i];
break;
end;
end;
end;
Include(FFlags, lffSelectedValid);
end;
Try the change using the test case ....
Both are attached here.
Plus: full performance is back again ! The overall navigation performance of the app is noticeably better (and better than with 2.0.12)!
Minus: Last instead of first selected element will be returned at multiselect
Personally for me, the Plus would be much much more important than the Minus. First/last might be handled on application level.
Are there any different opinions?
What about - as compromise - to imply a property (maybe defaulted to "return first item", Delphi-like) that allows the developer to choose which behaviour /
option he prefers?
Something like FOwnerDataMultiSelectReturnLast := True (defaulted to False) .. FMultiSelectDelphiCompatility := true or such, let it up to the user.
if OwnerDataMultiSelectDelphiCompatility then .. existing code .. else ... reverted code as aboce.
I'd definitely (definitely!) would choose "speed" in very basic, fundamental operations and invest a bit of work on application level for the few cases when "first" is needed instead of "last".
What do you think? I'd highly be interested in!
Could this be a way out to shorten up this endless story, where i'm triggering the same issue again and again, because i'm suffering on it?