The event TRIGGER is an “User click”, the ACTION is “Call a sorting column method”, so it must be considered a BUG, as the TRIGGER occurs but the method is not called and should be. The contents to be sorted or whatever are not important at this stage. If empty, the internal sorting method should just return as if it did its job.
Agree too. Imagine you want to save as a user preference the sorted column number you can do it with ColumnSorted event only if the column have data it must be considered a BUG
You would be creating an unexpected exception to the general rule. A button always fires when pressed, for example; the behavior AFTER firing can be anything, if the triggered method will ignore such click in case of a listbox being empty, or with background cells in blue, or some property = 777, must be determined in the event action, not beforehand, and it should ALWAYS fire. I can, for example set some default sort direction and save it, even without any data there… yet.
But doing so has no effect. Clicking a listbox header (not buttton) affects the data currently in the listbox. Data added after are added to the end in the order they are added.
If you wish so. If you return true, it makes nothing to the column/sorting. And even if you do it so (return true at the end), you can change properties and take any actions while invoked. You could even set a property like currentColumnInFocus and set a different color for it. Many possibilities.
As said, the trigger happened (click), so the action MUST fire.
The CompareRow event can use data from multiple columns to control sort order (i know I have coded that way)…
Because of that, as long as there is more than one row of data, the CompareRows event should fire and the list box should try to sort even if the column header clicked on is for an empty column.
This behavior have an additional bug. The ColumnSorted(column As Integer) As Boolean Event (bad name, should be ColumnSort, ColumnSortRequest… as it can be avoided) can be overridden returning True. That means, the column sort won’t happen and the users can do whatever they want instead, but… the sort direction indicator flips anyway? Why? You took over the action, it should not change if returning True. People could decide at runtime to perform a “Shuffle Column” instead AND manually set the indicator to whatever ColumnSortDirection they wanted at end, but Xojo make “residual assumptions” and sets the direction to some undesirable value running over the manual overridden one.