const
  AutoSizeWidth = LVSCW_AUTOSIZE{_USEHEADER};

in C:\lazarus\lcl\interfaces\win32\win32wscustomlistview.inc

this was done in revision 24774 by Paul and the commit message was "don't reset autosized width of listview column".

I suppose this was originally meant to use LVSCW_AUTOSIZE_USEHEADER instead of LVSCW_AUTOSIZE. I have tried to modify it and use LVSCW_AUTOSIZE_USEHEADER wherever LVSCW_AUTOSIZE is used (see attached diff) (there is another occurrence in TWin32WSCustomListView.ItemSetText where the above constant is not used (obviously forgotten to substitute it) and there it must also be set to LVSCW_AUTOSIZE_USEHEADER) and now the listview will correctly include the column header in the calculation. I can't see any "resetting" of the width or any other unwanted behavior, instead it now behaves as one would expect from it.

Bernd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listview_autosize.diff
Type: text/x-diff
Size: 1681 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100808/eb668486/attachment.bin>

The change "AutoSizeWidth = LVSCW_AUTOSIZE{_USEHEADER}" is not related to the commit message. I just also played around autosizing and did not change anything regards autosizing, just made a const for the future solution.

LVSCW_AUTOSIZE_USEHEADER does not solve the autosize problem because it applies the width according to your actual content and does not resize after you add/remove more items. Therefore another solution is needed.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

LVSCW_AUTOSIZE_USEHEADER does not solve the autosize problem because it applies the width according to your actual content and does not resize after you add/remove more items. Therefore another solution is needed.

On my windows XP it does resize on every added item. I used the same test program that I used in my previous post about the slowness, this program will add items with increasing size (remove all beginupdate and the visible:=false to watch it in real time, its slow enough to watch it) and from what I can see here it will perfectly recalculate the size after each item is added.

Maybe the problem you observed is because you forgot one instance if this constant in TWin32WSCustomListView.ItemSetText where you forgot to replace LVSCW_AUTOSIZE with AutoSizeWidth.

Bernd

Bernd Kreuss wrote

On my windows XP it does resize on every added item.

And the next step to improve it (performance-wise) would be to call it in TWin32WSCustomListView.ItemSetText only if the updatecount is zero and in enduptade once for every autosized column if the updatecount is reaching zero.

Bernd Kreuss wrote

And the next step to improve it (performance-wise) would be to call it in TWin32WSCustomListView.ItemSetText only if the updatecount is zero and in enduptade once for every autosized column if the updatecount is reaching zero.

Please create a bug report and attach the patch and example to it.

And please don't remove AutoSizeWidth constant, just replaced the missed place where it had to be used.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

And please don't remove AutoSizeWidth constant, just replaced the missed place where it had to be used.

Ok, I will do this.

And to fix the slowness problem I will probably also have to introduce a new public function GetUpdateCount() in TCustomListView to be able to read the list view's FUpdateCount from within the TWin32WSCustomListView class if I don't find a simpler way to access this information. I hope this is ok. After these changes the listview will not only behave more correctly but also be orders of magnitude faster :-)

Bernd

You can add it to the protected section and access using TListViewAccess class. Therefore class public interface will stay as is.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

You can add it to the protected section and access using TListViewAccess class.

This is interesting. I didn't know that I can access protected methods from the *outside* by simply deriving a class in the same unit from where I want to access them.

I was always under the impression that I would have to always write a public getter method because they were only visible from *within* the class and under no circumstances from the outside. I was already starting to write getters in the TCustomListViewAccess class when I discovered by accident that it would also compile and work without them. The code completion did not show them!

Bernd

Zitat von Bernd Kreuss :

Please create a bug report.

Mattias

Paul Ishenin wrote

Please create a bug report and attach the patch and example to it.

http://bugs.freepascal.org/view.php?id=17141

Done :-)

Bernd