Re: NSTableView Drag & Drop... Well, Maybe
Re: NSTableView Drag & Drop... Well, Maybe
- Subject: Re: NSTableView Drag & Drop... Well, Maybe
- From: mw <email@hidden>
- Date: Tue, 08 Oct 2002 16:21:22 -0400
On 10/8/02 3:01 PM, "Brian Webster" <email@hidden> wrote:
>
On Tuesday, October 8, 2002, at 01:32 PM,
>
email@hidden wrote:
>
>
> NSEnumerator *e = [tv selectedRowEnumerator];
[clip]
>
> while(index = [e nextObject]) {
>
> [employees removeObjectAtIndex:[index intValue]];
>
> }
>
>
There is a problem with this loop here. Each time you remove an object
>
from the employees array, the index of all the employees after the one
>
that is removed will shift down by one. Then, when you go to the next
>
selected row, it will no longer refer to the same person.
>
>
For example, if rows 1 and 3 are selected, removing row 1 will shift
>
the employee who was at row 3 down to row 2. Then, when you remove the
>
employee that is _now_ at row 3, you're actually removing the employee
>
that _was_ at row 4. You'll have to adjust your indices as you remove
>
each person in order to compensate for this.
Or I can just make a second array containing the people to remove, and then
use NSMutableArray's removeObjectsInArray method to take everything out that
way :-).
while(index = [e nextObject]) {
[peopleToRemove addObject:[employees objectAtIndex:[index intValue]]];
}
[employees removeObjectsInArray: peopleToRemove];
That seemed to work okay. But something is still broken (and it was the
original problem, too). Whenever any element of the array that was brought
from the pasteboard is accessed, an EXEC_BAD_ACCESS error is returned.
Remember, this array was just brought down from a "freeze-dried" state as an
NSData object back into an NSMutableArray. This takes place in the second
loop, as previously stated.
// Now we add this unarchived array to the employees array
e = [tv selectedRowEnumerator];
while(index = [e nextObject]) {
[employees insertObject:[unarchivedPeople objectAtIndex:i] atIndex:row];
i++;
row++;
}
Btw, I followed your suggestion about using the row parameter to correctly
place the objects back into their respective locations in the employees
array. But, whenever the first line of the while loop is accessed (the one
where an element of the previously "freeze-dried" array is placed into the
pre-existing employees array), I still get an EXEC_BAD_ACCESS signal along
with this error from GDB:
2002-10-08 16:10:53.117 RaiseMan[1712] *** -[NSConcreteMutableData
objectAtIndex:]: selector not recognized
My guess is that this error is being returned because it is attempting to
send a message to a dangling pointer. The employees array stores a group of
custom data type objects (subclass of NSObject, of course). Do I have to
impliment the NSCopying protocol so I can, perhaps, send a [MyObject copy]
message when inserting it (or them) into the array that is to be archived as
an NSData object for pasteboard placement? Just a thought, but I didn't
think making it that complicated would be necessary.
Any thoughts?
Thanks,
mw
_______________________________________________
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.