> On 21 May 2015, at 2:41 pm, Quincey Morris
> wrote:
>
> It looks to me like the problem is that the NSWindowController’s “document”
> property is still set to the NSDocument object that was just deallocated
How did you determine that it’s this property that is stale? The stack trace
inclu
On May 21, 2015, at 00:18 , Graham Cox wrote:
>
> How did you determine that it’s this property that is stale?
Er, I think it was a deduction. The crash occurs during traversal of the
responder chain (apparently), and it’s got as far as the window controller
without crashing, and the document
> On 21 May 2015, at 5:45 pm, Quincey Morris
> wrote:
>
> On May 21, 2015, at 00:18 , Graham Cox wrote:
>>
>> How did you determine that it’s this property that is stale?
>
> Er, I think it was a deduction.
Ah, fair enough. It was my deduction as well, but I thought you’d arrived there
by
On 19 May 2015, at 17:52, Britt Durbrow
wrote:
> Yes, I am a bit concerned that it could become deprecated. I suppose that I
> could just override retain and release in that case; and track the retain
> count myself; although I seriously doubt that that functionality will be
> deprecated/remov
On May 21, 2015, at 01:33 , Graham Cox wrote:
>
> Therefore either the crash is not due to window.windowController.document
> being stale after all,
According to Instruments, there’s only one NSWindow object ever been allocated,
and only one NSWindowController, and both were created when the d
> On 21 May 2015, at 7:31 pm, Quincey Morris
> wrote:
>
> However, there is actually one more possibility: window.delegate. If that’s
> set to the document rather than the window controller, I suppose that might
> account for the crash. But I can’t imagine it would be.
Well, I was going to
> On 21 May 2015, at 8:09 pm, Graham Cox wrote:
>
> And just to verify this finding, if I add a -prepareSavePanel: method to my
> simple test app, I can reproduce the identical crash there. I’m thinking that
> could be worth a radar, because it’s pretty easy to forget to remove that
> referen
Thanks for digging in and tracking that down Bill! Very much appreciated!
It actually makes sense with what I'm now reading about Collection Views.
And thanks Kyle. I've seen that breakpoint behavior before and just dealt
with it ... but your statement about hardware exceptions really clarifies
it
On May 20, 2015, at 7:17 PM, Jens Alfke wrote:
>
>> On May 20, 2015, at 4:08 PM, Eric Wing wrote:
>>
>> You could use the Objective-C runtime to find out which things are
>> properties.
>
> You could, but isn’t it a lot easier to just look at the character before the
> name and check whethe
On May 20, 2015, at 7:16 PM, Michael David Crawford wrote:
> You could comment off their declarations in your header files, then
> have a look at which uses of them in your sources result in fatal
> compiler errors.
Bingo. That will do it.
Thanks much to everyone on this. It's certainly got
> On May 21, 2015, at 6:43 AM, Alex Zavatone wrote:
>
> Also, you can turn it off autosynthesis? How? That would be a big help for
> me to straighten out this iOS project where the original developers thought
> everything needed to be a java bean.
As Graham said, go to the build settings an
Ahh. A little follow up.
One area we all know about is that you can specialize the name of the
property's ivar like so:
@synthesize thing = _thing;
Which makes the internal and private ivar to be _thing while the property
becomes thing.
In my case, this helps to uncover where the original co
On May 21, 2015, at 03:09 , Graham Cox wrote:
>
> So it looks as if the mystery is solved
Yes. The funny thing is that I could have sworn that NSSavePanel wasn’t a
NSWindow subclass, but of course it is.
The other funny thing is that if you look in your Instruments data for the
allocation eve
> On May 21, 2015, at 9:28 AM, Alex Zavatone wrote:
>
> @synthesize thing = _thing;
> Which makes the internal and private ivar to be _thing while the property
> becomes thing.
> In my case, this helps to uncover where the original code is accessing the
> ivar as opposed to the property.
I al
Jens mentioned that it was possible to turn off the auto-synthesis of
properties in the build options of the target.
This would be quite useful to help me iron out items that need to be refactored
in my current project.
My google skills are weak. I can't find out how to do this. Anyone care t
On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote:
> Jens mentioned that it was possible to turn off the auto-synthesis of
> properties in the build options of the target.
>
> This would be quite useful to help me iron out items that need to be
> refactored in my current project.
>
> My goog
On 21 May 2015, at 12:27 PM, Kyle Sluder wrote:
>
> On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote:
>> Jens mentioned that it was possible to turn off the auto-synthesis of
>> properties in the build options of the target.
>>
>> This would be quite useful to help me iron out items that n
> On May 21, 2015, at 9:51 AM, Quincey Morris
> wrote:
>
>> 5 AppKit +[NSSavePanel _crunchyRawUnbonedPanel]
>
> The only way it could be any better is if it were huggable, too.
Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment”
sketch:
Inspector: People won't ex
On May 21, 2015, at 10:40 , Fritz Anderson wrote:
>
> I must have misinterpreted the question. I had understood Alex wanted a build
> option to turn off the auto-synthesis of properties, so the compiler could
> complain at every conflation of ivars with @propertys.
You didn’t misinterpret the
> On May 21, 2015, at 10:40 AM, Fritz Anderson wrote:
>
> I must have misinterpreted the question. I had understood Alex wanted a build
> option to turn off the auto-synthesis of properties, so the compiler could
> complain at every conflation of ivars with @propertys.
The warning causes the
> On 22 May 2015, at 2:28 am, Alex Zavatone wrote:
>
> if you use myThing, it's not visually obvious that you're directly accessing
> the ivar
This is where a consistent and deeply ingrained naming convention is useful.
The leading underscore has always been Cocoa’s “way” of doing that, and
> On 22 May 2015, at 3:02 am, Jens Alfke wrote:
>
>> Now that I have a path forward and understand why things are what they are,
>> this brings up the wonderful speed issue of "how much slower is property
>> access vs ivar access”.
>
> Yeah, I think we’ve had some vigorous debates about this
> On 22 May 2015, at 3:14 am, Jens Alfke wrote:
>
> Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment”
> sketch:
>
Spring Surprise: Pop one in your mouth and steel bolts plunge straight through
both cheeks!
—Graham
> On May 21, 2015, at 4:44 PM, Graham Cox wrote:
>> On 22 May 2015, at 3:02 am, Jens Alfke wrote:
>>
>>> Now that I have a path forward and understand why things are what they are,
>>> this brings up the wonderful speed issue of "how much slower is property
>>> access vs ivar access”.
>>
>> Y
24 matches
Mail list logo
