Sorting table data when set up as an indicator

[tstanley]

I have a table set up with all the columns set as indicators.  As such, I can't edit the contents of the table by selecting a cell and typing in something, which is good.  However, I noticed I can still change the table by selecting a bunch of stuff, right clicking, and choosing the "Sort" option.  It seems that I should not be able to do this if it's supposed to be an indicator.  It's not a big deal because I found that I can get rid of the "Sort" option by using the HideBuiltInCtrlMenuItem() function.  Likewise turning the whole table into an indicator also works, but then I lose the ability to allow the user to select a range of cells.  

Anyhow, not a big deal because I can use HideBuiltInCtrlMenuItem() to keep the users from changing the tables in this way, but still seems kind of weird.  

[LuisG]

You raise an interesting point. But after having thought about it for a while, I think the current behavior is correct, for the following reasons:

a) In your case, all the cells are indicators, but it's possible to make only individual cells be indicators. As such, the policy for sorting (if it took into account the individual indicator-state of each cell) would have to be to allow non-indicator cells to be moved, but not allow moving indicator cells. And if you're sorting multiple columns, that would require all the cells from each column that are in the same row as the indicator cell to also be locked in place. This would make for a confusing and undesirable user experience, as some rows might sort correctly while others don't.

b) the purpose of making a cell an indicator is to not allow the end user to change its value interactively. And you bring up a good point by arguing that if you make, say, cell (5,2) an indicator, but the control then allows you to swap cell (5,2) with cell (5,5) then, in a sense, the value of cell (5,2) has changed. But this is somewhat dependent on your perspective. For example, imagine that you have a table with user records, and you have something like this:

Row 1: <last name 1> <first name 1> <date of birth 1>

Row 2: <last name 2> <first name 2> <date of birth 2>

Now imagine that, for some reason, you want to disallow users from altering the second user's date of birth, so you make that cell an indicator. Now, if someone ends up swapping the two rows (for example, because they might want to sort their records alphabetically, by last name) you could view that as the cell's value changing. But in this case, that's not relevant. What matters is that that person's data was not changed.

I realize that this scenario is but one example, and it would be quite easy to come up with an example in which swapping cells really does present a problem. But as long as there are scenarios in which swapping is okay, that's still an argument against the control enforcing an outright prohibition against swapping indicator cells. Ultimately, it's up to the developer to decide what makes sense in his or her case, and then hide or show that menu item based on that decision. As you ended up doing.

Luis

[tstanley]

I understand that in a table where some things are indicators and some aren't, defining the behavior of the sort command would be very tricky, and likely would not please everyone.  

However, in your example, there could be a problem if the user just selected, for example, just the <last name> column and sorted it, because then the first names and last names would no longer match up, which means the data the table is presenting is just wrong.  And since everything is an indicator, there would be no way for the user to fix this (well, without the programmer coding in some additional functionality).  Now, I could see how, by chaining callbacks or some other tricks, you could programmically make it so the sort option only comes up when the user has selected entire rows, ensuring that data contained in the rows does not get mismatched while still allowing the user to change the order of the rows.  However, I don't see a way to keep the user from messing around with the 'sort by row values' options in the sort popup, which means that the user could end up with mismatched column names and data and no way to change it back, like having the birthdates in the "First Name" column.  So I don't really see a situation where I could give access to the built-in sort command on a table of indicators without a big warning of "use with care", which would seem strange to the users that I would give them access to it at all.  

With all that said, I'm still fine with leaving things the way they are, since it's trivial to disable the sort option when I don't want it present.

[LuisG]

You're absolutely right. The example I gave is too simplistic and it would indeed require some additional programmer gymnastics in order to behave correctly. I had considered that the programmer would probably have to check the right-click event and hide the Sort item whenever the selection was not suitable. But I hadn't considered that the end user could then still configure the sort, in the dialog that comes up, such that it would end up not making any sense.

So yes, in some cases, the programmer has no choice but to disable that menu item. If sorting is still desirable, it's always possible for the programmer to add a new item to the menu and then implement sorting it by calling the SortTableCells function, which is the programmatic way of sorting a range of cells.

Luis