Small problem with NSTableView delegate

Gregory Weston <uce RemoveThis @splook.com> wrote:

<snip>

Looks like I'm confusing datasources and delegates. Sorry about that - I
assume it's datasources I'm actually have an issue with.

> Beyond that what I'm finding confusing is *when* the data source method
> you reference above is being invoked as compared to when you expect it
> to be invoked. The method above is generally only meaningful when
> editing has been completed, but double-clicking would *start* editing
> and a row of -1 is clearly out of range so I'd think your sanity
> checking in the process of responding to the set would just ignore such
> invocations.

The actual code in question is simply this:

-(void)tableView:(NSTableView*)aTableView setObjectValue:(id)anObject
forTableColumn:(NSTableColumn *)aTableColumn row:(int)row

{
NSLog(@"selectedRow = %d", [aTableView selectedRow]);
NSLog(@"Attempting to alter item number %d", row);

[array replaceObjectAtIndex:[aTableView selectedRow]
withObject:anObject];

}

where 'array' is an NSMutableArray.


The confusing thing (to me) is that the example I based it on (from
Cocoadev) used the 'row' variable to alter the array.

The above code _seems_ to work, but I'll take another look at it and
work through some other examples.

Many thanks.

Jim
--
"My idea of a fair fight: I'm in a main battle tank. My opponent
is 3 miles away, on a hill top, armed with a pistol."
- Dave the Australian.
http://www.UrsaMinorBeta.co.uk http://twitter.com/GreyAreaUK

In article <1iqy8tp.1nzy7tt188r0w0N%jim@magrathea.plus.com>,
jim.DeleteThis@magrathea.plus.com (jim) wrote:

> Gregory Weston <uce.DeleteThis@splook.com> wrote:
>
> <snip>
>
> Looks like I'm confusing datasources and delegates. Sorry about that - I
> assume it's datasources I'm actually have an issue with.
>
> > Beyond that what I'm finding confusing is *when* the data source method
> > you reference above is being invoked as compared to when you expect it
> > to be invoked. The method above is generally only meaningful when
> > editing has been completed, but double-clicking would *start* editing
> > and a row of -1 is clearly out of range so I'd think your sanity
> > checking in the process of responding to the set would just ignore such
> > invocations.
>
> The actual code in question is simply this:
>
> -(void)tableView:(NSTableView*)aTableView setObjectValue:(id)anObject
> forTableColumn:(NSTableColumn *)aTableColumn row:(int)row
>
> {
> NSLog(@"selectedRow = %d", [aTableView selectedRow]);
> NSLog(@"Attempting to alter item number %d", row);
>
> [array replaceObjectAtIndex:[aTableView selectedRow]
> withObject:anObject];
>
> }
>
> where 'array' is an NSMutableArray.
>
>
> The confusing thing (to me) is that the example I based it on (from
> Cocoadev) used the 'row' variable to alter the array.
>
> The above code _seems_ to work, but I'll take another look at it and
> work through some other examples.
>
> Many thanks.
>
> Jim

I'm going to claim that something's up elsewhere in your code. I'm
having no luck finding any documented circumstance under which the
setter is invoked at the start of editing or under which it's invoked
with a row index of -1. I just threw together the most trivial table
editing sample and at least by default there's no such behavior.

Here's the implementation of my data source:

- (void)awakeFromNib
{
a = [[NSMutableArray alloc] initWithObjects:@"a", @"b", @"c", nil];
}

- (int)numberOfRowsInTableView:(NSTableView *)aTableView
{
return [a count];
}

- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(int)rowIndex
{
NSLog(@"Getting row %d", rowIndex);
return [a objectAtIndex:rowIndex];
}

- (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject
forTableColumn:(NSTableColumn *)aTableColumn row:(int)rowIndex
{
NSLog(@"Setting row %d to %@", rowIndex, anObject);
[a replaceObjectAtIndex:rowIndex withObject:anObject];
}

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix

On 2008-11-25, Gregory Weston <uce RemoveThis @splook.com> wrote:
>
> I'm going to claim that something's up elsewhere in your code.

Almost certainly, yes

> I'm
> having no luck finding any documented circumstance under which the
> setter is invoked at the start of editing or under which it's invoked
> with a row index of -1.

The 'start of editing' bit was certainly me just mistaking what it does -
you're correct that it gets invoked at the _end_ of editing. I see that now.

The row index of -1 is still puzzling, but I'll do what you did and throw
together a small test app and see what I get. Hopefully I'll be able to
figure out what it is I've done wrong.

The fact that it's currently working (or, at least, appears to) is neither
here nor there to me, as _something_ isn't right.

I'll puzzle it out.

Many thanks for your time.

Jim
--
http://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK
"My idea of a fair fight: I'm in a main battle tank. My opponent
is 3 miles away, on a hill top, armed with a pistol."
- Dave the Australian.

Gregory Weston <uce.DeleteThis@splook.com> wrote:

> I'm going to claim that something's up elsewhere in your code.

And indeeed there was.

For some reason - I blame the government - I'd added a '[aTableView
reloadData]' line in my

-(id)tableView:(NSTableView*)aTableView
objectValueForTableColumn:(NSTableColumn*)aTableColumn row:(int)row

method, which was (a) completely superfluous, and (b) downright wrong.
It must have reset the 'row' value, hence 'row' being -1 but
'selectedRow' being correct.

Stupid, stupid, stupid of me. At least I founf it though. It was
starting to drive me slightly mad.

Jim
--
"My idea of a fair fight: I'm in a main battle tank. My opponent
is 3 miles away, on a hill top, armed with a pistol."
- Dave the Australian.
http://www.UrsaMinorBeta.co.uk http://twitter.com/GreyAreaUK

In article <1ir1y6k.1k93et415dsg2dN%jim@magrathea.plus.com>,
jim.RemoveThis@magrathea.plus.com (jim) wrote:

> Gregory Weston <uce.RemoveThis@splook.com> wrote:
>
> > I'm going to claim that something's up elsewhere in your code.
>
> And indeeed there was.
>
> For some reason - I blame the government - I'd added a '[aTableView
> reloadData]' line in my
>
> -(id)tableView:(NSTableView*)aTableView
> objectValueForTableColumn:(NSTableColumn*)aTableColumn row:(int)row
>
> method, which was (a) completely superfluous, and (b) downright wrong.
> It must have reset the 'row' value, hence 'row' being -1 but
> 'selectedRow' being correct.
>
> Stupid, stupid, stupid of me. At least I founf it though. It was
> starting to drive me slightly mad.
>
> Jim

Happens to everyone. Somewhere along the line we all do

if(bargle);
{
// stuff we don't expect to execute every time.
}

Glad to hear you found it.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix

Gregory Weston <uce.TakeThisOut@splook.com> wrote:

> Glad to hear you found it.

[self LART];

Jim
--
'Cloverfield' in nine words: "What is it?!" "We're gonna die!" BOOM!
Roll credits.

http://www.ursaminorbeta.co.uk http://twitter.com/greyareauk