[no subject]

Hello I am trying to make a view that displays images and a table view's columns in this way: http://rghost.net/8kmdcTnnN/image.png and http://rghost.net/6BwyMsyXy/image.png Basically, there are several image views, and a table view with the corresponding number of columns. Each image above the

Images and NSTableView columns should scale together

Sorry, forgot to add a subject to my previous message :/ I am trying to make a view that displays images and a table view's columns in this way: http://rghost.net/8kmdcTnnN/image.png and http://rghost.net/6BwyMsyXy/image.png Basically, there are several image views, and a table view with the

ARC and Manual Memory Management

Hi, Has anyone come up with a way of having the source code support both ARC and Manual Memory Management without using #IFDEF or #IF ? I’ve never understood why the compiler doesn’t just ignore code like: [super dealloc]; [MyObj release]; If it’s being compiled for ARC, that way both could b

Re: ARC and Manual Memory Management

On Monday, August 10, 2015, Dave wrote: > Hi, > > Has anyone come up with a way of having the source code support both ARC > and Manual Memory Management without using #IFDEF or #IF ? You could use a macro, and if ARC is enabled, then simply have it evaluated to do nothing. This is common in ot

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:59, Dave wrote: > > Hi, > > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code like: > > [super dealloc]; > > [MyObj

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 13:21, Roland King wrote: > > >> On 10 Aug 2015, at 19:59, Dave > > wrote: >> >> Hi, >> >> Has anyone come up with a way of having the source code support both ARC and >> Manual Memory Management without using #IFDEF or #IF ? >> >> I’ve n

OS X Sharing Extension?

I have an OS X app for creating time-lapse movies from a series of still photos. I want to add a Sharing Extension that implements an "Open with..." item in the Sharing menu that has no UI, and just passes the URLs to be opened by a the extension’s container app. I've noticed there's an "Add to

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 8:35 AM, Dave wrote: > > That’s fair enough, I was wondering if there was any deep reason. The thing > is I have library classes that I use in older projects that are non-ARC, I > was trying avoid having two sets of more or less identical files. Just add the compiler fl

Re: Xcode Debugger Shows Incorrect Variable Information

> On Aug 9, 2015, at 5:28 PM, Graham Cox wrote: > > Have you set the debug build to optimise the code? Any optimization tends to > screw up what the debugger ‘knows’ about your code - symptoms very like what > you’ve described. You need to set optimization to ‘none’ for debug builds. My optim

Re: ARC and Manual Memory Management

On 10 Aug 2015, at 13:59, Dave wrote: > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code like: > > [super dealloc]; > > [MyObj release]; > >

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 1:11 PM, Uli Kusterer > wrote: > > The only reason I'm aware of is if you need to port to a platform that > doesn't support libArclite (like really old Mac/iOS versions). Targeting arclite isn’t such a good idea these days, IMO; I’ve found the later versions of Xcode som

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: > > On 10 Aug 2015, at 13:59, Dave wrote: >> Has anyone come up with a way of having the source code support both ARC and >> Manual Memory Management without using #IFDEF or #IF ? >> >> I’ve never understood why the compiler doesn’t just ignore

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >>> On 10 Aug 2015, at 13:59, Dave wrote: >>> >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Management without using #IFDEF or #IF ? >>> >>

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > > If it just ignored those constructs, it was be much less confusing, simply > because there would only one set of source code. It would be a mess, honestly. If you build + test a source file with ARC it’d be very easy to break it for MRR by forge

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 21:12, Dave wrote: > > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >> On 10 Aug 2015, at 13:59, Dave wrote: >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Management without using #IFDEF or #IF ? >>> >>> I’ve

Re: ARC and Manual Memory Management

On Mon, Aug 10, 2015 at 3:51 PM, Uli Kusterer wrote: > > > On 10 Aug 2015, at 21:12, Dave wrote: > > > > > >> On 10 Aug 2015, at 19:11, Uli Kusterer > wrote: > >> > >> On 10 Aug 2015, at 13:59, Dave wrote: > >>> Has anyone come up with a way of having the source code support both > ARC and Man

Why is overriding unavailable designated initializer of super required?

I've yet to understand this: https://gist.github.com/swillits/3133e114f770947b3cf6 If a subclass says that its superclass's designated initializer is unavailable (IOW, the subclass's designated initializer must be used), why does the compiler produce a warning that the superclass's designated

Re: Why is overriding unavailable designated initializer of super required?

On Aug 10, 2015, at 4:27 PM, Seth Willits wrote: > > I've yet to understand this: > https://gist.github.com/swillits/3133e114f770947b3cf6 > > > If a subclass says that its superclass's designated initializer is > unavailable (IOW, the subclass's designated initializer must be used), why > do

Re: Why is overriding unavailable designated initializer of super required?

> On Aug 10, 2015, at 1:27 PM, Seth Willits wrote: > > > I've yet to understand this: > https://gist.github.com/swillits/3133e114f770947b3cf6 > > > If a subclass says that its superclass's designated initializer is > unavailable (IOW, the subclass's designated initializer must be used), why

Re: Why is overriding unavailable designated initializer of super?required?

On Aug 10, 2015, at 13:27 , Seth Willits wrote: > > What am I missing? Coming at this from the other end (other than what Greg said): — I think you are misunderstanding what NS_UNAVAILABLE means (although I’m by no means sure about that). — You never needed to say anything about the “unavaila

Re: Why is overriding unavailable designated initializer of super required?

First off, thanks for the answer. Unfortunately either I'm still missing something, or perhaps my question wasn't precise enough... > On Aug 10, 2015, at 1:49 PM, Greg Parker wrote: > > Convenience initializers. > > Consider: a superclass that implements a designated initializer and a > co

Re: ARC and Manual Memory Management

I found fmdb’s solution instructive and very helpful. If you download the source and take a look it might give you some ideas. Rob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin reques

Re: Why is overriding unavailable designated initializer of super required?

> On Aug 10, 2015, at 3:50 PM, Seth Willits wrote: > > Say that I am taking this approach because it'd be impossible for a > YourSubclass instance to call initWithValue: on itself with an acceptable > "default" value; One is required by the client. > > Even though -init is unavailable, it's s

Re: Why is overriding unavailable designated initializer of super required?

> On Aug 10, 2015, at 4:29 PM, Greg Parker wrote: > > Writing a halting cover for the superclass's designated initializers is a > defensive measure. If you miss one of the convenience initializers then > getting an immediate crash with a crash log pointing to the initializer is > much better t