• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Can't bind to NSApplication subclass on startup
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can't bind to NSApplication subclass on startup


  • Subject: Re: Can't bind to NSApplication subclass on startup
  • From: Ken Thomases <email@hidden>
  • Date: Wed, 16 Jul 2014 06:13:16 -0500

On Jul 16, 2014, at 6:03 AM, Jonathan Taylor <email@hidden> wrote:

    Class principalClass = NSClassFromString([infoDictionary objectForKey:@"NSPrincipalClass"]);
    printf("Principal class name from Class object: %s\n", object_getClassName(principalClass));

    NSApplication *applicationObject = [principalClass sharedApplication];
    printf("applicationObject class name %s\n", [applicationObject className].UTF8String);

Principal class name from Class object: SpimApplication

applicationObject class name NSApplication

Any thoughts as to why +sharedApplication, called on the correct principalClass object, should be resulting in only the superclass being instantiated?

[I know that we are strictly forbidden from overriding +sharedApplication, but just to see what happened I did try declaring it for SpimApplication, just calling through to super. My version *is* called, but unsurprisingly the returned object is of type NSApplication, so not sure that told me anything I didn’t already know]

This suggests that something has already called +sharedApplication on NSApplication before the code you showed (or NSApplicationMain()).  Obviously, +sharedApplication only _creates_ an object on the first call.  In that case, it uses the receiver class to instantiate the application object.  But in other cases, it just returns the previously created object and the receiver doesn't matter.

You need to track down that incorrect call to +sharedApplication.  You can set a symbolic breakpoint on +[NSApplication sharedApplication] but the breakpoint needs to be in effect before the process starts, not just by the time that main() is entered (which is where the debugger often stops when you tell it to break at launch).

Regards,
Ken

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Can't bind to NSApplication subclass on startup
      • From: Jonathan Taylor <email@hidden>
References: 
 >Can't bind to NSApplication subclass on startup (From: Jonathan Taylor <email@hidden>)
 >Re: Can't bind to NSApplication subclass on startup (From: Ken Thomases <email@hidden>)
 >Re: Can't bind to NSApplication subclass on startup (From: Jonathan Taylor <email@hidden>)

  • Prev by Date: Re: Can't bind to NSApplication subclass on startup
  • Next by Date: Re: Can't bind to NSApplication subclass on startup
  • Previous by thread: Re: Can't bind to NSApplication subclass on startup
  • Next by thread: Re: Can't bind to NSApplication subclass on startup
  • Index(es):
    • Date
    • Thread