On May 14, 2013, at 1:16 AM, Andy Lee wrote:
> I fiddled a bit with it, adding calls that don't take arguments like [self
> description] and [self self]. There was no dealloc until just before the
> method exited, after those calls. It *seems* that merely referring to self,
> whether as receive
On May 14, 2013, at 12:53 AM, Roland King wrote:
[...]
>> - (void) mouseDown: (NSEvent*) event
>> {
>>NSView* superView = [self superview];
>>[self removeFromSuperview];
>> //[superView addSubview: self];
>> }
>>
>> ...then dealloc does in fact get called. But if I uncomment that one
On May 13, 2013, at 21:30 , Andy Lee wrote:
> I believe ARC keeps it alive by virtue of self being a strong reference.
It isn't, not exactly. According to section 7.3 of the Clang ARC spec:
"The self parameter variable of an Objective-C method is never actually
retained by the implementation.
On 14 May, 2013, at 12:30 PM, Andy Lee wrote:
> On May 13, 2013, at 11:38 PM, Quincey Morris
> wrote:
>> On May 13, 2013, at 19:41 , Graham Cox wrote:
>>
>>> When you call -removeFromSuperview, the view is deleted, as there are no
>>> more references to it. The other methods are not called
Not only does this work, it also does not add duplicates to the subviews array.
Tom
On May 13, 2013, at 11:56 PM, Thomas Wetmore wrote:
> This works. Thanks for the tip.
>
> Tom Wetmore
>
> On May 13, 2013, at 11:38 PM, Quincey Morris
> wrote:
>
>> -- Invoke 'addSubview: self' without firs
On May 13, 2013, at 11:38 PM, Quincey Morris
wrote:
> On May 13, 2013, at 19:41 , Graham Cox wrote:
>
>> When you call -removeFromSuperview, the view is deleted, as there are no
>> more references to it. The other methods are not called because the object
>> ceases to exist.
>
> I believe yo
This works. Thanks for the tip.
Tom Wetmore
On May 13, 2013, at 11:38 PM, Quincey Morris
wrote:
> -- Invoke 'addSubview: self' without first removing self. The NSView
> machinery may be clever enough merely to move the view to the end of the
> subviews array, without actually removing and re
On 14 May, 2013, at 11:34, Graham Cox wrote:
>
> Or just do it manually. It's not incompatible with ARC which after all simply
> inserts the same calls. To my mind, it's clearer what's going on than relying
> on all those arcane magic pointer types.
>
> --Graham
>
>
You'd have to disable
On May 13, 2013, at 19:41 , Graham Cox wrote:
> When you call -removeFromSuperview, the view is deleted, as there are no more
> references to it. The other methods are not called because the object ceases
> to exist.
I believe your warning is apposite, but is not actually the cause of Tom's
p
On 14/05/2013, at 1:14 PM, Roland King wrote:
> That depends on whether the framework which is calling mouseUp:/mouseDown:
> retains the object on which it's calling it. If the framework is using ARC
> and a normal strong reference, then it would be retained and that would stop
> it deallocin
On 14 May, 2013, at 10:41 AM, Graham Cox wrote:
>
> On 14/05/2013, at 12:27 PM, Thomas Wetmore wrote:
>
>> Can anyone suggest why adding the three lines in mouseDown prevents
>> dragging? Using ARC.
>
>
> When you call -removeFromSuperview, the view is deleted, as there are no more
> refe
On 14/05/2013, at 12:27 PM, Thomas Wetmore wrote:
> Can anyone suggest why adding the three lines in mouseDown prevents dragging?
> Using ARC.
When you call -removeFromSuperview, the view is deleted, as there are no more
references to it. The other methods are not called because the object c
I've been experimenting with a UI for a program that manages many small,
draggable views, that can be moved around in the same superview. The following
mouse events work well for providing the dragging basics. However, when I drag
a view relative to the other views I also want it to end up on to
13 matches
Mail list logo
