NSTableView jumps on selection… why?

Question

I've got an NSTableView with a single column, populated with NSTableViewDataSource methods (no bindings involved.) The NSTableView is inside an NSScrollView, as is the default behavior when you drag an NSTableView in from the library in Interface Builder. The contents of the tableview are populated based upon a search string that the user types, and are not changed after that point.

I am only implementing these two methods of the DataSource protocol:

- (NSInteger)numberOfRowsInTableView:(NSTableView *)tableView;
- (id)tableView:(NSTableView *)tableView objectValueForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;

After typing my search string, the focus is still in the NSTextField, but I can naturally scroll the tableview with my mouse's scroll wheel or with the arrows on the scroll bar. Neither causes the tableview to receive the focus ring. However, if I scroll down such that I am not at the top of the tableview and then click to highlight an individual row in the tableview, the tableview instead jumps back to the top, and then selects whatever row is under my mouse at that point. If I click on rows after that point, it works as expected.

In other words, if the NSTableView has the focus ring around it, clicking on a row highlights the expected row. If it does not have the focus ring around it, clicking on a row selects whatever row is at that position after scrolling to the top.

Any insight? I am running Snow Leopard, but I believe it happened when I was running Leopard as well.

Answer 1

Could it be that when the search NSTextField loses focus, it somehow fires a reloadData (or similar method) on the table view, which would empty out the view (resetting its scrolling position to the top) and then re-populating it instantaneously?

Answer 2

I had a similar bug once, and the cause was that my window controller was handling awakeFromNib and was setting the scroll position on the list so it would be in the right position when first loaded. However, I eventually realised that it was also getting awakeFromNib messages from the nib-based table view cells which are created as needed, which would sometimes mess with the table scroll value unexpectedly while scrolling. My fix was to make the window controller only set scroll position when handling the first awakeFromNib.