Re: Possibly dumb NSTableView problem
Re: Possibly dumb NSTableView problem
- Subject: Re: Possibly dumb NSTableView problem
- From: Ryan Stevens <email@hidden>
- Date: Sun, 1 Apr 2007 12:06:42 -0700
Check your numbers. Check your arrays.
It sounds like when you reloadData one of your tables is getting the
number of rows from the longer array and then trying to get the data
from the shorter....maybe...
On Apr 1, 2007, at 10:33 AM, I. Savant wrote:
Have you set a breakpoint and used the debugger to identify the
point at which you're receiving the "beyond bounds" error? Once it
breaks at that point, you can examine the state of your app.
The problem is, your code calls a bunch of your other code and
you haven't specified anything about where the problem is actually
occurring (which may or may not be within the code you *did* list).
It's simply not realistic to expect a good answer with the
information you've provided.
--
I.S.
On Apr 1, 2007, at 1:27 PM, rob colonna wrote:
That's pretty hard to do, as it's lengthy, but I will try to boil
it down a bit. These are the things I'm doing on
SelectionDidChange to make sure that whatever was working with the
data from the one selection resets to be ready to work with the
new selection (i.e selects nothing or just the first row of a
table). All of this completes successfully. Is there anything
else I can do to NSTableView to essentially return it to a clean,
non-interacted-with state?
- (void)tableViewSelectionDidChange:(NSNotification *)aNotification {
//irrelevant stuff
if(lastAccount!=[accountsListingTable selectedRow]) {
NSLog(@"changing account");
[mainAccountTable scrollRowToVisible:0];
[mainAccountTable setNeedsDisplay:YES];
[mainAccountTable selectRowIndexes:[NSIndexSet indexSetWithIndex:
0] byExtendingSelection:NO];
[self generateOnTheFlySelections]; //processes some stuff based
on selected row or rows
lastAccount=[accountsListingTable selectedRow]; //keeps track
of whether or not a change has been made in the selection table
[self rollBackUpdate]; //updates a user-interface item based on
the new data
[rollbackSlider setIntValue:[rollbackSlider maxValue]]; //
updates a user-interface item based on the new data
[self updateCategoryMenus]; //updates a user-interface item
based on the new data
}
...
}
The error message I get in the console is
2007-04-01 13:16:06.928 spendthrift3[3133] *** -[NSCFArray
objectAtIndex:]: index (20) beyond bounds (4)
after switching from a data set with many records to one with only
four. The offending index is not necessarily the selected one; as
near as I can tell, it has to do with the rows that are displayed
in the table view (row 20 was at the top of the table when I
triggered that error, row 40something was selected). This made me
think that it was in my table data source methods for a while, but
they all seem to be working okay. Other than that, I went through
every objectAtIndex I had that ran in the display-update sequence,
and they all seem to come off okay. This is why I was somewhat
curious as to exactly what an NSTableView might be doing after
selectionDidChange. Unfortunately, the rest of the code is
sufficiently scattered that it'd be difficult to tell a coherent
story of what's going on, but if you have any ideas, I appreciate it.
Thanks for your time,
rob colonna
On Apr 1, 2007, at 11:47:48, I. Savant wrote:
On Apr 1, 2007, at 11:37 AM, rob colonna wrote:
Or is it more likely that there lurks something in my code
that's still referring to an item 11 selected, out of a possible
10?
That sort of depends on your code. Perhaps you should post it?
--
I.S.
____________________________________
rob colonna http://blackllamafaction.org/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden