Re: XGDragView bug

[Willem Rein Oudshoorn]

Enrico Sersale <enrico@www.imago.ro> writes:


> > Ok, I am able to reproduce it, but for me it is not as simple
> > as it seemed.  I have to:
> > 1 - Move icon A from Shelf to Finder
> > 2 - Move icon A a little on the Finder shelf, so it disappears
> > 3 - Repeat step 1
> > 4 - Notice: CRASH as soon as the icon A enters the Finder.

[Text skipped]

> > But let me describe what I have found so far.
> >
> > A - the DnD code references an deallocated object.
> > B - the deallocated object is a FinderShelfIcon
> > C - the FinderShelfIcon is deallocated when you start
> >     dragging in step 3
> 
> Are you sure of this? This is *very* important. It should be deallocated
> after step 2, when is removed from its superView...

YES, I am sure.  I added a dealloc method in FinderShelfIcon and put a 
breakpoint there.
The backtrace shows that the pasteboard releases the object.  This is logical 
because
the data on the DragPasteboard is never removed, only replaces when a new drag 
starts.

I do not know how OpenStep does this.  Should the Drag code explicitly clear the
DragPasteboard??

> (Here I've a little problem with my very poor English: what means exactly
> to trigger?)

It is probably my english :-(.  I meant that the second drag action
puts objects on the pasteboard.  The pasteboard replaces its content
and that means that the old content is released.  This, being the final
release of the FinderShelfIcon, leads to a dealloc.

The real mystery, however, is why GNUstep thinks this FinderShelfIcon
is still an NSView which is displayed in the Finder.  

> If I've understand correctly "triggered" (but I don't know), It seems more
> a pasteboard problem.

Could be.  But I do not have this problems with other applications.  So
I still have the impression that it is perhaps a bug in GWorkspace which
only now surfaces.  

> I've downloaded just now core.20020110.tar.bz2 and the problem
> already exist.

Thanks,

Wim Oudshoorn.