Bug in SalInstanceTreeView::set_column_editables() ?

[Michael Weghorn]

On 2025-01-14 21:47, Jan Rheinländer wrote:
> maybe there is a bug in SalInstanceTreeView::set_column_editables():
> 
> It calls SvTabListBox::SetTabEditable(), which sets the EDITABLE flag in 
> mvTabList array of SvLBoxTab.
> 
> But the parent class SvTreeListBox keeps another array of SvLBoxTab 
> called aTabs.
> 
> When the user presses the mouse button on a cell in a treeview, 
> SvImpLBox::MouseButtonDown() is called.
> 
> It gets the tab SvTreeListBox::GetTab(), which retrieves it from the 
> aTabs array.
> 
> Then it checks the EDITABLE flag with SvLBoxTab::IsEditable().
> 
> But of course the EDITABLE flag has been set in the mvTabList array of 
> the subclass SvTabListBox.
> 
> The net result is that only the first column is editable, since that is 
> always set to editable by default (in both tab arrays).
> 
> Is this a bug? And how to fix it? What is the point of the second tab 
> array in the subclass?

Unfortunately, I don't have definitive answers to this and I'm not 
particularly familiar with that code myself, but it sounds like it could 
be a bug. Do you know a way to trigger this scenario from an actual 
dialog/... or are the above observations so far completely based on 
reading code?

Unless anybody else has more insights, looking into code using that (and 
maybe finding a way to trigger and debug into it) might possibly help to 
get a better understanding why that separate tab array might be there 
and how it's used. (And maybe gives more clarity on whether it makes 
actually sense and/or how to resolve the potential issue you're mentioning.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20250121/a99d7b54/attachment.sig>