Hi Jules,
Currently, TableListBox only supports row selection. I would think that the full TableListBox should have also “column” selection, but I can understand that would take some time. Instead, or in the meantime, it would be great if TableListRowComp were moved to the header file (i.e. right now that component is somewhat private in that I can’t subclass it because it’s in a cpp file and that isn’t available via the header includes). That way, adding selection would be a simple matter of subclassing and implementing the needed methods.
What does column selection even mean in the context of a multi-row list?
Are you sure that you don’t just want a TableListBox that is rotated 90 degrees?
Well, a “ListBox” is a multi-row list, while a “TableListBox” is more of an N by N matrix, right?
So… say you have an "excel sheet and want to select the cell in row 2, column 3.
Unless, perhaps I’m using the wrong component.
TableListBox is not a spreadsheet.
This having been said, you could always subclass it and provide your own custom appearance for the selected row, which also takes into account a “currently selected column” highlight.
I guess I misunderstood the TableListRowComp as a component that allows x y “cells” where each can have a custom component. Otherwise, what is the difference with a ListBox?
Anyway, I have subclassed TableListRowComp, but even then, selection is not as simple because of the way the model and the row components interact with mouse clicks and arrows. To properly implement selection, this would have to happen in the row component, hence my request to move the row component to the header file (and in fact, it would also require to make the “updateColumnComponents()” method in TableListBox to be made protected (as it actually would need to get overridden by the subclass.
A generic spreadsheet / grid component would certainly be a very useful addition to Juce.
Yeah… the TableListBox was never intended to be used as a spreadsheet. That might indeed be a useful component to have, but if I was writing it, I think I’d make it a separate class altogether.
Thanks for the clarification. So far I’ve been able to get around the small issues that come from using a TableListBox as a “grid” component, but if at any point I decide to write a proper “GridComponent”, I’ll certainly share it.
Cheers.