I am trying to include Growl support in an app, but it is crashing when setting the delegate. As per http://growl.info/documentation/developer/implementing-growl.php , I am just setting the delegate like so [GrowlApplicationBridge setGrowlDelegate:#""]; as I am only needing Growl for basic usage, but upon running it crashes.
Xcode shows the following warning on that line:
Semantic Issue: Incompatible pointer types sending 'NSString *' to parameter of type 'NSObject<GrowlApplicationBridgeDelegate> *'
Any ideas on how to resolve this?
Fixed: I set added to my header file and set the delegate to self
Fixed 2: It actually wasn't that, it was the version of growl sdk I was using having a bug in it, fixed with v1.2.2 of growl.
Don't set the delegate (leave out that line) and you should be fine.
If you need a delegate that you have to set it to an instance of a class that implements the protocol.
Cast it to an untyped object to eliminate the warning.
[GrowlApplicationBridge setGrowlDelegate:(id)#""];
It was the version of growl sdk I was using having a bug in it, fixed with v1.2.2 of growl.
Related
I added the Parse SDK today (1.2.15) to an existing project which targets iOS7 and is built in Xcode5. I followed the instructions on https://parse.com/apps/quickstart#ios/native/existing exactly. Some things work, like creating and saving a PFObject. Certain functions however cannot be found by the compiler. For instance [PFUser enableAutomaticUser]; generates the error
AppDelegate.m:21:13: No known class method for selector 'enableAutomaticUser'
and [PFAnalytics trackAppOpenedWithLaunchOptions:launchOptions]; generates the error
AppDelegate.m:20:6: Use of undeclared identifier 'PFAnalytics'
Are the docs out of date and have these methods moved? I have tried restarting Xcode and cleaning my project. I can see the PFAnalytics.h file if I expand Parse.Framework in Xcode, and when I look at PFUser.h I can see a declaration of enableAutomaticUser;. Why can Xcode see some Parse classes and methods but not others?
My problem was that Framework Search Paths in Build Settings contained two directories, and one was invalid, resulting in this very strange behavior where some methods in Parse worked and others didn't.
I've been playing with pyobjc and seem to be getting this warning for I believe the following code.
warning:
Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7
and later. It should not be used in new applications. Use
convertRectToBacking: instead.
Code:
def findFile_(self, parent):
panel = NSOpenPanel.openPanel()
panel.setCanChooseDirectories_(YES)
panel.setAllowsMultipleSelection_(NO)
panel.setTitle_("Please Choose a File")
panel.setPrompt_("Choose")
panel.runModal()
I am not calling this, is it a pyobjc issue?
How do you fix this?
All help is appreciated.
PyObjC does not call "userSpaceScaleFactor" without explicitly being asked to do so.
The openradar link you mention indicates that the message is caused by a bug in NSOpenPanel (or rather, NSOpenPanel hasn't been updated to full retina support yet).
Already checked this question: Weak linking UIPopoverBackgroundView
and already read: http://www.marco.org/2010/11/22/supporting-older-versions-of-ios-while-using-new-apis#fnref:1
I have a custom PopoverBackgroundView declared in a .h and implemented in a .m file. Then, in just one file, I instantiate it like this
self.settingsPopover.popoverBackgroundViewClass = [CustomPopoverBackgroundView class];
I´ve tried doing it like marco says in the link above:
if ([UIPopoverBackgroundView class] != nil) {
self.settingsPopover.popoverBackgroundViewClass = [CustomPopoverBackgroundView class];
}
But I get the same launch error when I run in a 4.3 ipad simulator
dyld: Symbol not found: _OBJC_CLASS_$_UIPopoverBackgroundView
My base sdk is IOS 5.1, and my target deployment is 5.1 as well. Im using LLVM compiler 4.0.
Any ideas? Thanks a lot!
Have you tried using respondsToSelector with the relevant UIPopoverController setBackgroundViewClass method? Remember that properties automatically generate setter and getter methods that you can use in addition to the normal property syntax.
The reason why you're still getting linker errors is because you're still trying to call a method on that class, which doesn't exist.
If it's a case that the entire class doesn't exist, Apple recommends using NSClassFromString(#"UIPopoverController") and checking if the returned result is nil.
Recently I upgraded my project settings in Xcode 4.3 and now I use the latest llvm debugger: lldb
However (sometimes) I have the impression the debugger is not giving me the correct info? Could this be possible?
For example, The debugger says _documentsItem is nil (both in in the console and when mouse-over-ing the ivar). But I know it's NOT, that is why I can see it (an UIBarButtonItem) and more important that is why the app stopped at the shown breakpoint)
if (_documentsItem) { ...
In fact most of my properties return nil too :(
Is there a way I make sure the debugger is doing fine?
I've met similar issues in Xcode 4.3. And press "Option" while click "run" and changed it back to stable gdb.
It is definitely nil.
Look at the address that its been allocated. 0x00000 is nil.
This is a bug with XCode, which still hasn't been resolved, as of 4.3.2. Switch back to GDB, even if XCode complains about your project settings.
For view property value, use
"po self.yourproperty"
I am seeing some strange behavior with Objective-C blocks in a large project. Everywhere that there is a Block property that is defined as copy, there is a crash when the app attempts to reference the property later on. Overriding the setter implementation from the #synthesize'd implementation and explicitly calling Block_copy() does the trick, but interestingly when the same code is used in another project context the properties work as expected.
This must be some kind of project setting or dependency issue. Anyone run into this sort of thing before?
Thank you Bavarious. The underlying issue is libSystem library linked into the app.
The fix is to remove "-weak_library /usr/lib/libSystem.B.dylib" from the target's Linker Flags and replace it with "-weak-lSystem".