I assume that adding and deleting columns from a listbox is done like:
myListbox.columnCount = myListbox.columnCount + 1
and
myListbox.columnCount = myListbox.columnCount - 1
I also assume that removing a column will destroy all the data in the cells of that column. Not so it seems:
window has a 1 col listbox
add 10 rows and put stuff in each cell
append a 2nd column, this one needs 100 rows so append an extra 90 blank rows
fill the cells of the new col with 100 values: everything looks fine
delete this 2nd most recently added column using myListbox.columnCount = myListbox.columnCount - 1
hold on, we need that 2nd column after all, but we only need 10 rows in it, not 100, so re-add a 2nd column: myListbox.columnCount = myListbox.columnCount + 1
now just fill the top 10 cells of this re-added column (I used -ve numbers for illustration in the png below).
What I expected is a listbox with 2 columns, and with data in the top 10 rows of each, what you get instead is this:
As you can see, the previous 90 trailing values arose from the dead. This cannot be normal behavior. I now worry that celltags, columntags, etc also persist, and could now cause big leaks if these variants hold onto large objects.
Here is a simple project that you can try for yourself:
IRC, from when i started with the product (almost 19 years ago!) you could could aways save data in non-existent columns.
i think it used to be considered a feature- one that originated before cell tags existed to hold info not to be displayed (the other way was 0 width columns) so it is no surprise that the data remains after columns get deleted…
The listbox design has always obviously been primarily row centric…
I suspect that it was originally conceived as being only a single column list control, and everything else was tacked on afterwards over the years.
In any case, you are right. Since the advent of Cell, Row and Colum tags, they should delete the info for columns that removed to prevent leaks that logically would not be expected. I would go so far as saying we should only be able to save data to cells that actually exists now.
Yes that might brake some old code, and I hate that and usually don’t want that to happen… but in this case that is code that needs to updated badly!
Worst: you can add data in a non existent Cell if your Row is Editable and the ListBox have empty space at the right of it: just click there (on an existant Row) and add data.
Beware: that data will be lost once you left that non existant Cell.
Then given all this, we definitely need a dedicated listbox.deleteColumnAt(index) method to completely remove a column and any data it contains (cells, tags, etc)