ListBox.SortColumn is not fired if the ListBox is empty!

I implemented an error checking at the beginning of the SortColumn Event, then I tested it and…

when the ListBox is empty (one column only, no Row), the event is not fired.

Why do I implement a test there ?

Because I need a PopupMenu Value, and if this Control have not set any, I must not execute the code.

NB: the Column.Heading have a valid string contents.

I add a Row (using Edit.Paste), then click in the Row Header and get my error message. :innocent:

At last, I checked using Xojo 2022r4.1 and I get the same behavior.

Thinking loud, but… if there are no contents to sort in that column, why the event should be fired? :thinking:

1 Like

Yes, you are correct, but I could not have been able to test my Error condition to avoid a (potential) crash.

This ListBox does not allows manual Row Addition, so I add a default Row (Cmd-V) and was able to check the potential (?) Error.

This is what Xojo says when you add ColumnSorted
image

I think it should fire even if the column is empty.

If for some reason, the behavior is correct (as designed) then Xojo may add ‘when the column is not empty’ to make the behavior clear.

I definitively agree.

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.

3 Likes

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

1 Like

I can see where if the listbox is completely empty, then sorting is a meaningless action.

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.

That was my first feeling, and the reason why I set (check for condition) code there.

hi
put the following code to your listbox event ColumnSorted:

listbox.ColumnSortDirectionAt(0) = DesktopListBox.SortDirections.None

and if you press the header it will not sort the contents of the specific column (you will have to do it for all the columns if you wish so).

Regards

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.

-karen

If there are zero rows, as in the OP, why should the event fire? It’s not that the column has no data, the entire listbox is empty.

More questions without answers:

  • if there is 1 row, why the event fire? We need at least 2 rows to sort make sense, so why fire with 1 row and not with 0?
  • if there are 0 or 1 rows, why the sort indicator change? if the contents are not changed, why the indicator change?
1 Like

Firing is useful and costless. Not firing is limiting.

2 Likes

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.