I'd like to wait until one of guys from the VCL might be seeing it and maybe tell an opinion about."Guys from the VCL" hang around Delphi forums. This is FPC/Lazarus forum.
I could create a user in mantis and enter (and assign) it there, but i don't intend to install additional development subsystems (ie. trunk, version control systems) on my host), at least not these days.In order to report a bug you do not have to install anything.
Thought about to make a note in the bug tracker's item, but as the system is just being in progress to be migrated, i leave it to you if it should be corrected.I reopened issue:
No idea how to make TCustomListView.CNNotify fully functionalLCL code can be debugged, too.
No idea how to make TCustomListView.CNNotify fully functional but i added added a note in the bug tracker item.
Compiling for Windows x64? I didn't notice any difference after applying the change, do a "compile new" and using the testcase (listview_virtualMode_multiselect_wp_mod.zip) just as described (click on the last listitem, click on nowhere, and the messagebox still appears telling that for the last item Selected is still true).
I could locate the problem within customlistview.inc, TCustomListView.GetSelection - and here, it's due to the for-loopNo, it was not correct in 2.0.12. There "Selected" returned a wrong item in virtual mode. Now the feature is identical with the "normal" mode, both functionally and speed-wise.
potentiall along all items, if nothing is selected.
Now, a simple "if Selected = nil then exit; " might cost me 8 seconds
Until 2.0.12 all was fine, the listview did behave correct and fast. Why only had it been changed. A real nightmare!
Thanks to the new Gitlab repo, where i could easily fetch the really last version of customlistview.incThere was no need to wait for Gitlab really. Getting the sources from SVN used to be equally easy.
I encounttered a dramatic breakdown of performance on highlighy populated listview's contents.It would be helpful if you'd provide a simple basic demo showing this issue.
[...]
Now, a simple "if Selected = nil then exit; " might cost me 8 seconds
Until 2.0.12 all was fine, the listview did behave correct and fast. Why only had it been changed. A real nightmare!
Being not a core developer i cannot fix it, not deep enough insideYou didn't even try. It is Pascal code just like any other Pascal code.
My öast resort is really to hope that it won't occur with the RC2.Sure it will be in RC2 because the fix was merged there.
it's due to the for-loopI can't imagine that iterating over 17000 items just for checking whether the loop item is selected takes 8 seconds (**)...
potentiall along all items, if nothing is selected.
Now, a simple "if Selected = nil then exit; " might cost me 8 seconds
Being not a core developer i cannot fix it, not deep enough insideI agree with Juha. Core developers are no super-men. You are debugging deeply into the code, and it is hard to understand why you don't go deeper.
--primary-config-path=C:\laz-configs\laz-git
set path=c:\lazarus\fpc\fpc\3.2.2\bin\i386-win32
make bigide
About the patch (so easy, hu?): yes, i can confirm that it fixes the issue in all it's occurances .. no side effects so far that i could see.No, it's not easy. Due to the complexity of LCL, every change most likely will cause some kind of regression. It must be tested thoroughly.
Just removed the Windows-specifics from GetMem's sample project of reply #41 and tested it on Linux gtk2/gtk3/qt/qt5, as well as macOS cocoa to investigate if ListView virtual mode is working there too: yes, it is working in all these widgetsets (except for gtk3 which has problems with the ListView anyway).Thank you!
So, maybe it's time for some adventurous guys to convert the TShellListView to virtual mode, because the current non-virtual-mode ShellListView still has speed issues when reading folders with many items (at least on Windows where the built-in shell icons are extracted).I did take a quick look to ShellCtrls.pas, but is a non-trivial modification. More over is not my itch as @Juha would put it :D, I still prefer VST over anything. However if nobody offers to do the conversion in a reasonable amount of time, I will do it.
In my successful testings yesterday maybe i had been a bit too euphemistic .. it looked so fine, but i did miss a little thing. Namely the navigation by ArrowUp/ArrowDown keys. That falls back again to say 'Selected is Nil' where in fact items had been selected) by krys.Here we go again. :). I told you that each LCL modification is a double edged sword. Anyway I'm out of the office until Sunday. Please try to fix the issue if possible, if not I will take a look Sunday. Thank you.!
On top of Patch GetMem July 28, 2021:I ask you politely again to use Lazarus trunk sources and create a patch against it, or create a pull request in GitLab.
customlistview.inc, around line 350:
And i already told politely that i don't feel qualified enough and not familiar to jump into that role.I absolutely disagree. You already took that role because you publish fixes here in the forum. Adding them to bugtracker/GitLab is just a formal operation to make life easier for the developers. Everybody can write bug reports, you only must register to GitLab. A bugreport only requires you to write a bug description, steps to reproduce and a test project. And if available you should add a patch for the devs to see your solution. You show all these items here in your forum posts.