I was able to run your code and reproduced the problem you described. There wasn't anything wrong with your code, it's just that, as it turns out, the delay you had wasn't sufficient. The short answer is that you need to shift the while loop to the LEFT_CLICK callback (see attachment).
The long answer is that it became necessary to insert a delay (represented by the deferred callback) between waiting for the mouse to come up and the call to SetTableSelection. Otherwise, when the stack is unwound after the deferred callback, the table is still going to reset the selection to its default setting.
The only reason this worked when you clicked on the second column is because of a side-effect of setting the table selection,
which causes the active cell to be pinned to the new selection range (this happens whenever the active cell lies outside the new selection range; in this case, the active cell becomes the upper-leftmost cell of the range). When the stack is unwound, the new selection is reset to the the cell you clicked on "unioned" with the cell that was made active in SetTableSelection. The end result is that the strategy I had suggested to you would have only worked properly when you clicked on the last column of the table. Sorry about that...
I realize that this process is not as trivial as it should be. Ideally, you would receive a "new active cell" event, which you could then respond to by resetting the selection, without having to deal with deferred callbacks, or anything else of the sort. We have decided, in a future release, to greatly expand the set of events that the more complex controls in the library support, so that something like this can become a lot easier than it is now.
- luis