Re: NSArrayController selection bug?
Re: NSArrayController selection bug?
- Subject: Re: NSArrayController selection bug?
- From: Henrik Wittland <email@hidden>
- Date: Tue, 11 Nov 2003 00:38:39 +0100
Am 10.11.2003 um 23:02 schrieb mmalcolm crawford:
On Nov 10, 2003, at 12:12 PM, Jesse Grosjean wrote:
But an exception is thrown when the last item in the table view is
selected and I remove an item from my model's mutable array directly
(but in a KVC compliant way), instead of going through the
NSArrayControllers "remove" action. You can duplicate the problem by
adding the following method to the MyDocument class that comes with
the ControllerPlay example program that ships with 10.3. And then
connect a button action to it.
- (IBAction)modelRemove:(id)sender {
NSMutableArray *c = [self contentArray];
[c removeObjectAtIndex:0];
[self setContentArray:c];
}
Run the example. Insert an item or two into the table, and then after
making sure that the last item is selected click your new "remove
from model" button and you will get the error.
As far as I'm aware (**although this is the subject of some debate,
for which I'm awaiting resolution**) this isn't a bug.
It is a BUG. But the problem is that the example is not KVC compliant
and so thats also a BUG. So this BUG is found by a BUG :-)
The array itself is not observed, so you're changing the array behind
the controller's back. Granted you're calling setContentArray, but
you're passing in the same object, so I'd guess that there's some
optimisation to ensure no notification is sent.
No. NSKeyValueChangeSetting notification is send to the
NSArrayCotroller. The KVC compliant call to a setXXX: method always
post this kind of
notification. (Always means you never will get
NSKeyValueChangeInsertion, NSKeyValueChangeRemoval or
NSKeyValueChangeReplacement
this way. This is why i said its not KVC compliant to call a setXXX:
method for a mutable toManyProperty (if you don't change the array
pointer)).
But in the example the pointer to the array is not changing and so the
NSArrayController seems to think nothing has changed and it sets the
selection to the old indexset which leads to the error.
The appropriate thing to do is either to send a message to the
controller (which seems like a fairly logical thing to do since it's
managing the display...?)
The notification is send.
or implement the mutable array accessors and call
removeObjectFromContentArrayAtIndex: [The principle is that the
standard accessors are considered to be for immutable data types (to
preserve encapsulation).]
Yes. This is the right way to go. You have to decide if your array is
mutable or immutable in the API of your model.
If it is immutable you should implement:
- (NSArray *)contentArray;
- (void)setContentArray:(NSArray *)array;
And use it the right way. In this case there is no BUG:
Or if your array is mutable you should implement:
- (NSArray *)contentArray;
-(void)insertObject:(id)anObject inContentArrayAtIndex:(unsigned
int)index;
-(void)removeObjectFromContentArrayAtIndex:(unsigned int)index;
And use it the right way. In this case there is the BUG. The
NSArrayController always selects the wrong object and if you select the
last object there is the following error:
[NSCFArray objectAtIndex:]: index (x) beyond bounds (x)
But even without this error the selection in the array after the
removel of an object is wrong.
In the first case the selection is always the right one !!!!! But with
a different semantic !!!!
<http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueCoding/Concepts/AccessorConventions.html>;
- (unsigned int)countOf<Key>;
- (id)objectIn<Key>AtIndex:(unsigned int)index;
- (void)insertObject:(id)anObject in<Key>AtIndex:(unsigned int)index;
- (void)removeObjectFrom<Key>AtIndex:(unsigned int)index;
- (void)replaceObjectIn<Key>AtIndex:withObject:
I've put an example of the different cases at:
http://homepage.mac.com/mmalc/CocoaExamples/AddBehindTheScenes.zip
mmalc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
Regards,
Henrik
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.