objc [66375] class Foo is implemented in both BundleA and BundleB

Class Foo is a base class. It is subclassed in BundleA, BundleB, … BundleZ. The runtime still throws that message, regardless. There are one or two methods implemented in the base class and not in the subclasses. You can see this effect if you download, build, and run Apple’s BundleLoader sample

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 5:16 PM, Roland King wrote: > >> >> 2016-05-10 16:58:36.066 iApp[2549:2131821] *** Terminating app due to >> uncaught exception 'NSInternalInconsistencyException', reason: '( >>"> NO; view = ; target= <(action=oneFingerDoubleTap:, >> target=)>; numberOfTapsRequired =

Re: Receiver type for instance message is a forward declaration

> > 2016-05-10 16:58:36.066 iApp[2549:2131821] *** Terminating app due to > uncaught exception 'NSInternalInconsistencyException', reason: '( >" NO; view = ; target= <(action=oneFingerDoubleTap:, > target=)>; numberOfTapsRequired = 2>", >" ; target= <(action=tapAndAHalf:, > target=)>>",

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 5:04 PM, Quincey Morris > wrote: > > On May 10, 2016, at 16:43 , Roland King > wrote: >> >> Well no he hasn’t > > Correct … no he hasn’t. I mis-edited a longer draft of the post. > >> Now that I've changed things over to use the context value, I g

Re: Receiver type for instance message is a forward declaration

On May 10, 2016, at 16:43 , Roland King wrote: > > Well no he hasn’t Correct … no he hasn’t. I mis-edited a longer draft of the post. > Now that I've changed things over to use the context value, I get this at the > moment I add an NSOperation to the NSOperationQueue: > > [uploadQueue add

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 4:55 PM, Carl Hoefs > wrote: > > >> On May 10, 2016, at 4:39 PM, Quincey Morris >> wrote: >> >> On May 10, 2016, at 16:22 , Carl Hoefs > > wrote: >>> >>> I will set 'context' and use it in my check instead. >> >> Yup, use the co

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 4:39 PM, Quincey Morris > wrote: > > On May 10, 2016, at 16:22 , Carl Hoefs > wrote: >> >> I will set 'context' and use it in my check instead. > > Yup, use the context to decide whether to call super *and return* but nothing > el

Re: Receiver type for instance message is a forward declaration

> On 11 May 2016, at 07:39, Quincey Morris > wrote: > > On May 10, 2016, at 16:22 , Carl Hoefs wrote: >> >> I will set 'context' and use it in my check instead. > > Yup, use the context to decide whether to call super *and return* but nothing > else. Once you get past that check, don’t call

Re: Receiver type for instance message is a forward declaration

> On 11 May 2016, at 07:22, Carl Hoefs wrote: > >> >> > Okay... It appears that for some odd reason, once in a blue moon, 'object' > and 'keyPath' aren't what they're supposed to be, so I super it, and it blows. > …. > > I will set 'context' and use it in my check instead. > -Carl Well yo

Re: Receiver type for instance message is a forward declaration

On May 10, 2016, at 16:22 , Carl Hoefs wrote: > > I will set 'context' and use it in my check instead. Yup, use the context to decide whether to call super *and return* but nothing else. Once you get past that check, don’t call super. > It appears that for some odd reason, once in a blue moon

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 4:13 PM, Quincey Morris > wrote: > > On May 10, 2016, at 16:05 , Carl Hoefs > wrote: >> >> I'm not sure how context is to be used here > > It has to be a value that’s unique to the piece of code that tests it. In > effect, this me

Re: Receiver type for instance message is a forward declaration

On May 10, 2016, at 16:11 , Jens Alfke wrote: > > what goes wrong if it’s NULL If anything else uses NULL, then your observation is not uniquely identified, which means that: — you might respond to a notification registered by an ancestor class of your observer instance, breaking some of its

Re: Receiver type for instance message is a forward declaration

> On 11 May 2016, at 07:11, Jens Alfke wrote: > > >> On May 10, 2016, at 4:05 PM, Carl Hoefs >> wrote: >> >> Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to >> be used here... Is this an arbitrary value that I check in >> -observeValueForKeyPath? > > Yes, but I’

Re: Receiver type for instance message is a forward declaration

On May 10, 2016, at 16:05 , Carl Hoefs wrote: > > I'm not sure how context is to be used here It has to be a value that’s unique to the piece of code that tests it. In effect, this means unique to the class that creates and responds to the observations. If you’re in Obj-C, the usual trick is t

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 4:05 PM, Carl Hoefs > wrote: > > Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to be > used here... Is this an arbitrary value that I check in > -observeValueForKeyPath? Yes, but I’m not aware of it being required … what goes wrong if it’s NULL

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 3:52 PM, Quincey Morris > wrote: > > On May 10, 2016, at 13:38 , Carl Hoefs > wrote: >> >> At last, it blew again! > > Well, here’s the exception message: > >> An -observeValueForKeyPath:ofObject:change:context: message was receiv

presentationControllerForPresentedViewController(…) is called multiple times

Currently, my code instantiates a new UIPresentationController subclass each time presentationControllerForPresentedViewController(…) is called. Unfortunately, when I present a VC, presentationControllerForPresentedViewController(…) is called three times! This seems wasteful, at best, and possi

Re: Receiver type for instance message is a forward declaration

On May 10, 2016, at 13:38 , Carl Hoefs wrote: > > At last, it blew again! Well, here’s the exception message: > An -observeValueForKeyPath:ofObject:change:context: message was received but > not handled. > Key path: operations > Observed object: {name = 'Upload Queue'} > Change: { >kind =

Re: Receiver type for instance message is a forward declaration

> On May 10, 2016, at 1:38 PM, Carl Hoefs > wrote: > > )}: An -observeValueForKeyPath:ofObject:change:context: message was received > but not handled. > Key path: operations > Observed object: {name = 'Upload Queue'} An object got a KVO notification but doesn’t have a observer method to handl

Re: Protecting against "app nap"

> On May 10, 2016, at 10:26 AM, Jonathan Taylor > wrote: > > However, I was a bit surprised to find that I seem to need to explicitly > retain the object I get back [this is non-ARC code…] if I want my request to > remain in effect or even for the object to remain allocated to allow me to >

Xcode user defined settings from pre-action

Is there any way of passing values from a build pre-action into the user defined settings of the project? The only good way I found so far is to pass them to the xcodebuild command line - that doesn't really help much when not building from the command line though. As a work around it seem like o

Re: Receiver type for instance message is a forward declaration

> On May 9, 2016, at 1:51 PM, Quincey Morris > wrote: > > Perhaps it’s worth going back to that, in the hope that your crashes get more > frequent, and you can investigate what really causes them. At last, it blew again! Can someone interpret this? The context is that I touched a button in m

Too many wakes >15 in 300 seconds when app is in the background - iOS

The subject sort of sums it all up, but I'm not looking for what might cause this. What the main question is here is, "is our app causing the wake ups or is the system and what exactly constitutes a wake?" FYi, our app uses PJ_SIP and we have ipChange notifications being sent from a 2011 copy

Re: Protecting against "app nap"

Did you try clicking “Prevent app nap” in the “Info” inspector for the app? Paul > On May 10, 2016, at 10:26 AM, Jonathan Taylor > wrote: > > Hi all, > > I’m hoping somebody can help me work out how to protect my code against the > effects of “app nap”. This code is driving a scientific exp

Protecting against "app nap"

Hi all, I’m hoping somebody can help me work out how to protect my code against the effects of “app nap”. This code is driving a scientific experiment, unattended, and it is catastrophic when the OS decides that my timers running at 10Hz should only be fired every 10 seconds or so… which it tur

Re: How to keep things alive in Arc?

> On May 9, 2016, at 6:38 AM, gerti-cocoa...@bitart.com wrote: > This was recommended to me by folks "in the know": > > Thing *aThing = [ Thing new ]; > > ... > > (void)aThing; This is not guaranteed to keep aThing alive for its full scope. You should use the pre

Re: XCode snapshot function?

> On May 9, 2016, at 11:49 PM, Jens Alfke wrote: > > >> On May 9, 2016, at 6:48 PM, Graham Cox wrote: >> >> So what’s the best way to mothball and archive my project in its current >> state so I can then fork it for the next version, and so on? > > Git. The Snapshot feature was basically m

Re: NSTableView is messaging zombie delegate

> On May 6, 2016, at 1:03 PM, Matthew LeRoy wrote: > > Hello, > > I'm having an issue where an NSTableView appears to be messaging its delegate > after the delegate has been deallocated, causing an EXC_BAD_ACCESS crash. It > doesn't always happen, but it happens regularly. My understanding is

Re: XCode snapshot function?

Yes! > On May 10, 2016, at 01:49, Jens Alfke wrote: > > >> On May 9, 2016, at 6:48 PM, Graham Cox wrote: >> >> So what’s the best way to mothball and archive my project in its current >> state so I can then fork it for the next version, and so on? > > Git. The Snapshot feature was basicall

Re: XCode snapshot function?

> On May 9, 2016, at 9:48 PM, Graham Cox wrote: > > So what’s the best way to mothball and archive my project in its current > state so I can then fork it for the next version, and so on? I use the Finder's contextual menu "Compress" command to Zip the project folder, then drag the Zip file