The bug occurs in code that I wrote myself. Only the first column in the treeview is editable.
But it seems that the rest of the LO code never tries to edit
second or further columns in treeviews. Otherwise the bug would
have been found long ago.
Am 21.01.25 um 10:28 schrieb 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.)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
