Re: Mysterious crash with NSTableView

[Kyle Sluder]

> On Aug 29, 2016, at 6:39 AM, Andreas Falkenhahn  
> wrote:

> 
>> On 29.08.2016 at 02:10 Kyle Sluder wrote:
>> 
>> Delegates are different because they are often messaged in response to
>> various exogenous events. Some of these events might happen transiently
>> during window teardown, which is usually a time of massive fluctuation
>> in an app’s object graph. This is why -windowDidClose: is a good time to
>> nil out delegate properties that point back and the window controller
>> which ultimately owns the control.
> 
> So does this mean that this is potentially dangerous?
> 
>[NSApp runModalForWindow:win];
>[tableView setDelegate:nil];
>[tableView setDataSource:nil];
>[win release];
> 
> Should I move the "set to nil" calls to -windowDidClose instead?

Since you hold a strong reference to the window until after you clear out the 
delegate/dataSource backpointers, you know that the window cannot be 
reallocated until at least that point (but could be delayed to any arbitrary 
point in the future). So this approach is safe from window teardown causing the 
table view to message a zombie delegate.

--Kyle Sluder

> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Toolbar hiding on rotation?

[Alex Kac]

I figured it out :) Maybe its just monday morning fresh brain, I don’t know.

It turns out that the issue was that I am using a UISplitViewController AND the 
delegate methods:

-(UIViewController 
*)primaryViewControllerForCollapsingSplitViewController:(UISplitViewController 
*)splitViewController 

I was passing the view controller itself - not its parent navigation controller.


> On Aug 29, 2016, at 11:29 AM, Alex Kac  wrote:
> 
> I thought so as well. This is a pretty major project - 1600 classes, Mac/iOS 
> targets, and several third party libraries - so its quite possible somewhere 
> somehow there is something I’m unaware of, but that’s why I’m asking for help 
> in leads. I would think if its my code or even third party code, somewhere 
> “setToolbarHidden:” or “setTOolbarHidden:animated:” would be called, but its 
> not. Only other way I can think of it going away is some internal UIKit 
> methods or someone traversing the view hierarchy and removing the toolbar 
> view itself.
> 
> Relevant code:
> 
> to show the toolbar:
> navController.toolbarHidden = false
> 
> class PIMainViewNavigationController: UINavigationController {
> }
> 
> literally empty subclass because we look for specific view controllers that 
> are this class name (easy filter). However if I get rid of this class and 
> just use UINavigationController, I still have the same problem. No other 
> extensions on UINavigationController that *I*’m using. 
> 
> I’m pretty certain its some code somewhere doing this then…I just can’t 
> figure out what. So I’m hoping perhaps someone else has an idea where else to 
> look so I can identify it? Maybe I should try putting a breakpoint on 
> removeFromSuperview?
> 
>> On Aug 29, 2016, at 11:06 AM, David Duncan  wrote:
>> 
>> 
>>> On Aug 29, 2016, at 9:57 AM, Alex Kac  wrote:
>>> 
>>> I have a UINavigationController and UIViewController root that I set the 
>>> toolbarItems on. I obviously also tell it not to hide the toolbar. Great! 
>>> Works perfectly. But when I rotate, the toolbar is hidden - even if I 
>>> rotate back to portrait. I've set all the "hides*" properties such as 
>>> hidesBarsWhenVerticallyCompact to false (they were already false - but I 
>>> tried anyway), and it still hides the toolbar. I’ve put breakpoints 
>>> everywhere including symbolic ones for the toolbar hidden 
>>> properties/methods in UIKit. Since we are using a navigationcontroller 
>>> subclass, I even tried overriding the toolbar methods so that they can't 
>>> get set to true (hiding that is) and it still hides the toolbar. 
>>> 
>>> In some ways, I'm okay with it hiding going in landscape, but I'm not OK 
>>> with it not coming back when you go to portrait. The view debugger also 
>>> shows the toolbar is completely gone. So something in UIKit is removing the 
>>> toolbar view and never bringing it back - nothing I do can bring it back. 
>>> This is obviously disconcerting. My next step will be to just creating my 
>>> own toolbar instead of using Apple’s navcontroller toolbar, but if I can 
>>> get it to work, that’s my preference.
>>> 
>>> Any ideas?
>> 
>> This sounds suspect, as this is not the default behavior at all – that is, 
>> you can create a brand new project and configure a navigation controller to 
>> show the toolbar and it won’t hide it on its own.
>> 
>> What methods are you using to hide/show the toolbar? What other overrides 
>> are on your subclass? Any other libraries you have in your project, or 
>> categories on UINavigationController?
>> 
>> --
>> David Duncan
>> 
> 
> 
> Alex Kac - El capitán
> 


Alex Kac - El capitán


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Toolbar hiding on rotation?

[Alex Kac]

I thought so as well. This is a pretty major project - 1600 classes, Mac/iOS 
targets, and several third party libraries - so its quite possible somewhere 
somehow there is something I’m unaware of, but that’s why I’m asking for help 
in leads. I would think if its my code or even third party code, somewhere 
“setToolbarHidden:” or “setTOolbarHidden:animated:” would be called, but its 
not. Only other way I can think of it going away is some internal UIKit methods 
or someone traversing the view hierarchy and removing the toolbar view itself.

Relevant code:

to show the toolbar:
navController.toolbarHidden = false

class PIMainViewNavigationController: UINavigationController {
}

literally empty subclass because we look for specific view controllers that are 
this class name (easy filter). However if I get rid of this class and just use 
UINavigationController, I still have the same problem. No other extensions on 
UINavigationController that *I*’m using. 

I’m pretty certain its some code somewhere doing this then…I just can’t figure 
out what. So I’m hoping perhaps someone else has an idea where else to look so 
I can identify it? Maybe I should try putting a breakpoint on 
removeFromSuperview?

> On Aug 29, 2016, at 11:06 AM, David Duncan  wrote:
> 
> 
>> On Aug 29, 2016, at 9:57 AM, Alex Kac  wrote:
>> 
>> I have a UINavigationController and UIViewController root that I set the 
>> toolbarItems on. I obviously also tell it not to hide the toolbar. Great! 
>> Works perfectly. But when I rotate, the toolbar is hidden - even if I rotate 
>> back to portrait. I've set all the "hides*" properties such as 
>> hidesBarsWhenVerticallyCompact to false (they were already false - but I 
>> tried anyway), and it still hides the toolbar. I’ve put breakpoints 
>> everywhere including symbolic ones for the toolbar hidden properties/methods 
>> in UIKit. Since we are using a navigationcontroller subclass, I even tried 
>> overriding the toolbar methods so that they can't get set to true (hiding 
>> that is) and it still hides the toolbar. 
>> 
>> In some ways, I'm okay with it hiding going in landscape, but I'm not OK 
>> with it not coming back when you go to portrait. The view debugger also 
>> shows the toolbar is completely gone. So something in UIKit is removing the 
>> toolbar view and never bringing it back - nothing I do can bring it back. 
>> This is obviously disconcerting. My next step will be to just creating my 
>> own toolbar instead of using Apple’s navcontroller toolbar, but if I can get 
>> it to work, that’s my preference.
>> 
>> Any ideas?
> 
> This sounds suspect, as this is not the default behavior at all – that is, 
> you can create a brand new project and configure a navigation controller to 
> show the toolbar and it won’t hide it on its own.
> 
> What methods are you using to hide/show the toolbar? What other overrides are 
> on your subclass? Any other libraries you have in your project, or categories 
> on UINavigationController?
> 
> --
> David Duncan
> 


Alex Kac - El capitán


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Toolbar hiding on rotation?

[Doug Hill]

> On Aug 29, 2016, at 9:57 AM, Alex Kac  wrote:
> 
> I have a UINavigationController and UIViewController root that I set the 
> toolbarItems on. I obviously also tell it not to hide the toolbar. Great! 
> Works perfectly. But when I rotate, the toolbar is hidden - even if I rotate 
> back to portrait. I've set all the "hides*" properties such as 
> hidesBarsWhenVerticallyCompact to false (they were already false - but I 
> tried anyway), and it still hides the toolbar. I’ve put breakpoints 
> everywhere including symbolic ones for the toolbar hidden properties/methods 
> in UIKit. Since we are using a navigationcontroller subclass, I even tried 
> overriding the toolbar methods so that they can't get set to true (hiding 
> that is) and it still hides the toolbar. 
> 
> In some ways, I'm okay with it hiding going in landscape, but I'm not OK with 
> it not coming back when you go to portrait. The view debugger also shows the 
> toolbar is completely gone. So something in UIKit is removing the toolbar 
> view and never bringing it back - nothing I do can bring it back. This is 
> obviously disconcerting. My next step will be to just creating my own toolbar 
> instead of using Apple’s navcontroller toolbar, but if I can get it to work, 
> that’s my preference.
> 
> Any ideas?

It's interesting you mention this since I just spent a bunch of time trying to 
get this toolbar thing working according to Apple HIG.

For example, it used to say that on iPad you should put the bar button items in 
the Navigation Bar but on iPhone they should be at the bottom in a Toolbar. Now 
they say to use the Size classes to determine this. For example, regular width 
they put buttons in nav bar but in compact width use toolbar. This is because 
compact width generally corresponds to iPhone. But just to make things 
complicated multitasking windows on iPad are compact width. Further, landscape 
iPhone 6 plus (e.g. 5.5" display) is regular width. Gah! This is kind of weird 
because the toolbar hides and shows based on device rotation and multitasking 
modes, which seems a little jarring to me. But hey, go with the flow.

That said, I'm looking at my code and I see that I implement this logic in 
traitCollectionDidChange. And I'm just using 
self.navigationController.toolbarHidden for toolbar hiding and it seems to work 
fine. See if this property works for you, and let us know. Otherwise, there 
might be some other code hiding the toolbar.

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Toolbar hiding on rotation?

[David Duncan]

> On Aug 29, 2016, at 9:57 AM, Alex Kac  wrote:
> 
> I have a UINavigationController and UIViewController root that I set the 
> toolbarItems on. I obviously also tell it not to hide the toolbar. Great! 
> Works perfectly. But when I rotate, the toolbar is hidden - even if I rotate 
> back to portrait. I've set all the "hides*" properties such as 
> hidesBarsWhenVerticallyCompact to false (they were already false - but I 
> tried anyway), and it still hides the toolbar. I’ve put breakpoints 
> everywhere including symbolic ones for the toolbar hidden properties/methods 
> in UIKit. Since we are using a navigationcontroller subclass, I even tried 
> overriding the toolbar methods so that they can't get set to true (hiding 
> that is) and it still hides the toolbar. 
> 
> In some ways, I'm okay with it hiding going in landscape, but I'm not OK with 
> it not coming back when you go to portrait. The view debugger also shows the 
> toolbar is completely gone. So something in UIKit is removing the toolbar 
> view and never bringing it back - nothing I do can bring it back. This is 
> obviously disconcerting. My next step will be to just creating my own toolbar 
> instead of using Apple’s navcontroller toolbar, but if I can get it to work, 
> that’s my preference.
> 
> Any ideas?

This sounds suspect, as this is not the default behavior at all – that is, you 
can create a brand new project and configure a navigation controller to show 
the toolbar and it won’t hide it on its own.

What methods are you using to hide/show the toolbar? What other overrides are 
on your subclass? Any other libraries you have in your project, or categories 
on UINavigationController?

--
David Duncan


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Toolbar hiding on rotation?

[Alex Kac]

I have a UINavigationController and UIViewController root that I set the 
toolbarItems on. I obviously also tell it not to hide the toolbar. Great! Works 
perfectly. But when I rotate, the toolbar is hidden - even if I rotate back to 
portrait. I've set all the "hides*" properties such as 
hidesBarsWhenVerticallyCompact to false (they were already false - but I tried 
anyway), and it still hides the toolbar. I’ve put breakpoints everywhere 
including symbolic ones for the toolbar hidden properties/methods in UIKit. 
Since we are using a navigationcontroller subclass, I even tried overriding the 
toolbar methods so that they can't get set to true (hiding that is) and it 
still hides the toolbar. 
 
In some ways, I'm okay with it hiding going in landscape, but I'm not OK with 
it not coming back when you go to portrait. The view debugger also shows the 
toolbar is completely gone. So something in UIKit is removing the toolbar view 
and never bringing it back - nothing I do can bring it back. This is obviously 
disconcerting. My next step will be to just creating my own toolbar instead of 
using Apple’s navcontroller toolbar, but if I can get it to work, that’s my 
preference.

Any ideas?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pixel-perfect migration from ATSUI to Core Text

[Jens Alfke]

> On Aug 29, 2016, at 8:46 AM, Ken Thomases  wrote:
> 
> First, this has nothing to do with Cocoa and so isn't appropriate for 
> Cocoa-Dev.

There is a CoreText mailing list at lists.apple.com , 
I believe.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Pixel-perfect migration from ATSUI to Core Text

[Ken Thomases]

On Aug 29, 2016, at 9:55 AM, Andreas Falkenhahn  wrote:
> 
> I'm migrating some code from ATSUI to Core Text. It's pretty raw stuff, i.e. 
> it does
> all the layouting itself and only uses ATSUI/Core Text to draw single lines 
> of text to
> raw pixel buffers and obtain measurements.
> 
> The raw pixel data emitted by ATSUDrawText() and CTLineDraw() seems to match 
> exactly.
> Also, the measurements returned by ATSUI/Core Text seem to match most of the 
> time. Thus,
> it's usually the case that the pixels in text generated using ATSUI match 
> exactly the
> text pixels generated by Core Text. 
> 
> That's nice to see and I didn't expect that but it activated a perfectionist 
> tendency
> in me so that I ran some hardcore tests with lots of different texts printed 
> in different
> sizes and layouts to see if I could find a deviation between ATSUI and Core 
> Text. And I
> did ;) It happens only in very rare cases but sometimes the cursor advance 
> returned by
> ATSUI is a pixel off from the cursor advance returned by Core Text. But only 
> very
> seldomly. However, in complex layouts this can then accumulate and lead to an 
> entirely
> different layout if wordwrapping is involved.

First, this has nothing to do with Cocoa and so isn't appropriate for Cocoa-Dev.

That said, when drawing strings, there are the functions 
CGContextSetShouldSubpixelPositionFonts() and 
CGContextSetAllowsFontSubpixelPositioning().  Those can be used to turn off 
sub-pixel positioning of glyphs.  It may be that ATSUI wasn't capable of that 
and so turning it off gets you the same positioning as ATSUI.

There doesn't seem to be a direct way to ask Core Text for the measurements 
corresponding to that drawing mode.  So, you may need to ask your CTLine for 
its CTRuns and then ask the CTRun for the individual glyph advances.  Then, you 
would apply ceil() or round() to each and add the results together to get a 
total.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Pixel-perfect migration from ATSUI to Core Text

[Andreas Falkenhahn]

I'm migrating some code from ATSUI to Core Text. It's pretty raw stuff, i.e. it 
does
all the layouting itself and only uses ATSUI/Core Text to draw single lines of 
text to
raw pixel buffers and obtain measurements.

The raw pixel data emitted by ATSUDrawText() and CTLineDraw() seems to match 
exactly.
Also, the measurements returned by ATSUI/Core Text seem to match most of the 
time. Thus,
it's usually the case that the pixels in text generated using ATSUI match 
exactly the
text pixels generated by Core Text. 

That's nice to see and I didn't expect that but it activated a perfectionist 
tendency
in me so that I ran some hardcore tests with lots of different texts printed in 
different
sizes and layouts to see if I could find a deviation between ATSUI and Core 
Text. And I
did ;) It happens only in very rare cases but sometimes the cursor advance 
returned by
ATSUI is a pixel off from the cursor advance returned by Core Text. But only 
very
seldomly. However, in complex layouts this can then accumulate and lead to an 
entirely
different layout if wordwrapping is involved.

That's why I'd like to ask the question if there is a way around this. Here are 
the
relevant code pieces:

---

CTFontRef font = CTFontCreateWithName(CFSTR("Arial"), 39, NULL);
CFStringRef keys[] = {kCTFontAttributeName};
CFTypeRef values[] = {font};
CFDictionaryRef attr = CFDictionaryCreate(NULL, (const void **) &keys, 
(const void **) &values, 1, &kCFTypeDictionaryKeyCallBacks, 
&kCFTypeDictionaryValueCallBacks);
CFAttributedStringRef attrString = CFAttributedStringCreate(NULL, 
CFSTR("W"), attr);
CTLineRef line = CTLineCreateWithAttributedString(attrString);
CGFloat cursor_advance = CTLineGetOffsetForStringIndex(line, 1, NULL);

printf("CORE TEXT: %.14g\n", cursor_advance);

CFRelease(line);
CFRelease(attrString);
CFRelease(attr);
CFRelease(font);

---

ATSUFontID fontID;
ATSUStyle style;
ATSUTextLayout tl;
ATSUAttributeTag styleTags[2];  
ATSUAttributeValuePtr styleValues[2];
ByteCount styleSizes[2];
Fixed fsize;
UniChar textbuf[] = {'W'};
UniCharArrayOffset newOffset;   
ATSUCaret mainCaret, secondCaret;
Boolean caretIsSplit;

ATSUCreateStyle(&style);
ATSUCreateTextLayout(&tl);
ATSUFindFontFromName("Arial", 5, kFontFullName, kFontNoPlatform, 
kFontRomanScript, kFontNoLanguageCode, &fontID);   

styleTags[0] = kATSUFontTag;
styleTags[1] = kATSUSizeTag;

fsize = FloatToFixed(39);

styleValues[0] = &fontID;
styleValues[1] = &fsize;

styleSizes[0] = sizeof(ATSUFontID);
styleSizes[1] = sizeof(Fixed);

ATSUSetAttributes(style, 2, styleTags, styleSizes, styleValues);
ATSUSetTextPointerLocation(tl, textbuf, 0, 1, 1);
ATSUSetRunStyle(tl, style, kATSUFromTextBeginning, kATSUToTextEnd);
ATSURightwardCursorPosition(tl, 1, kATSUByCharacter, &newOffset);
ATSUOffsetToPosition(tl, newOffset, TRUE, &mainCaret, &secondCaret, 
&caretIsSplit);

printf("ATSUI: %.14g\n", (double) FixedToFloat(mainCaret.fX));

ATSUDisposeTextLayout(tl);
ATSUDisposeStyle(style);

---

Both code snippets calculate the cursor advance after the "W" character in
Arial, 39pt. These are the results:

CORE TEXT: 36.81005859375
ATSUI: 38

As you can see, ATSUI demands a slightly higher advance than Core Text. 

Do you think it is possible to make ATSUI and Core Text return *identical* 
cursor
advancements for all fonts and sizes?

Full example program attached for reference. 

-- 
Best regards,
 Andreas Falkenhahn  mailto:andr...@falkenhahn.com

main.c
Description: Binary data
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 29.08.2016 at 02:10 Kyle Sluder wrote:

> Delegates are different because they are often messaged in response to
> various exogenous events. Some of these events might happen transiently
> during window teardown, which is usually a time of massive fluctuation
> in an app’s object graph. This is why -windowDidClose: is a good time to
> nil out delegate properties that point back and the window controller
> which ultimately owns the control.

So does this mean that this is potentially dangerous?

[NSApp runModalForWindow:win];
[tableView setDelegate:nil];
[tableView setDataSource:nil];
[win release];

Should I move the "set to nil" calls to -windowDidClose instead?

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mysterious crash with NSTableView

[Andreas Falkenhahn]

On 27.08.2016 at 23:54 Quincey Morris wrote:

> On Aug 27, 2016, at 13:55 , Andreas Falkenhahn  wrote:
>
> I still don't know whether setting the delegate to nil
> before release is a general rule or does it only apply to NSTableView?
>
> It’s not clear what delegate you mean by “button delegate”, but it
> doesn’t really matter. 

Oops, I meant the button target as Kyle has already pointed out.

> Incidentally, while it might be a noble goal to have your software
> support OS versions all the way back to 10.6 or 10.5

Just 10.6 for x86. 10.4 for PowerPC but the PowerPC version of my
app uses Carbon anyway.

> Lastly, I may have lost track of things during the series of
> threads we’ve had about memory management in your app, but I can’t
> now understand why you don’t adopt ARC. I guess I thought it was
> because you were maintaining existing code, which presumably did its
> manual memory management properly. But if you’re writing new code,
> or even updating old code, there is literally no downside (AFAIK) in
> switching to ARC. Isn’t it a positive upside in source files shared
> between Mac and other platforms of your app, to not need retain and
> release calls? Note also that ARC and manual memory management can
> be intermixed in the same target freely (though not in the same
> source file), provided the existing manual memory management does follow the 
> rules.
> Since you’re not 100% familiar with the rules, why not just switch to ARC?

The actual Cocoa code in my app is really just a few kilobytes. It's
not complicated at all so there is no pressure to simplify things by
using ARC. If this was a huge project with lots of new code to be
written, it would be a different matter, but it's really just a few
lines. So it's a nice exercise for understanding manual memory management
with Cocoa.

Of course, I might switch to ARC sooner or later but I first
like to learn and understand the old way of doing things... maybe this
also helps me to appreciate ARC more once I start using it ;)

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com