I'm following this tutorial, attempting to learn a bit about iPhone development, and there come a point where the author uses the stringWithContentsofURL method but xcode is telling me that there is no stringWithContentsofURL method found. I've done some searching and I've not been able to come up with a solution. This is a screen shot of the xcode window displaying the error:
alt text http://mywebprogrammer.com/so/obj-c%20problem%200.png
stringWithContentsofURL: is a class method, not an instance method, so you have to use it as
[NSString stringWithContentsOfURL:myURL]
or if you want to allocate it yourself, you would do:
[[NSString alloc] initWithContentsOfURL:myURL]
but then you would have to release it later
Its [NSString stringWithContentsOfURL]. Note: its the capital 'O' (in Of) not small 'o' as given by you. Also Its a static method so cannot be used against an object.
Related
I´m on Mac OS X and Xcode 4.5.2
When executing these lines:
NSString *asSrcFileName = #"chromebar.png"
NSString *asSrcExtName = #".png"
NSString *asTempName = [asSrcFileName stringByReplacingOccurrencesOfString:asSrcExtName withString:#""];
I get a strange view of my variables in the debugger. See rectangle:
I expected asTmp to be #"chromebar" after line three.
I´ve been using stringByReplacingOccurrencesOfString pretty often so far and have no idea what´s wrong. Somehow it looks like there is a unicode issue.
Anyone out there to shed some light on me?
Are you inspecting asSrcTempName after the variable has been initialized (the green line showing the current execution point is below the initialization)?
Otherwise it's probably only uninitialized memory and lldb is showing garbage from a previous run.
I could not reproduce your problem in Xcode 4.5.1.
I'm attempting to use this approach, described by Marco Arment, for checking if a class exists before using it. With the correct settings, classes are automatically weak-linked when it's appropriate. As Marco describes, "you can safely subclass or have pointers to whatever you want (as long as you’re careful not to instantiate them when they’re not available)".
My app runs fine on iOS 5. I've followed the conditions mentioned at the link:
Base SDK is Latest iOS (iOS 5.1)
Deployment Target is iOS 4.0
Compiler for C/C++/Objective-C is Apple LLVM compiler 3.1 (also tried LLVM GCC 4.2)
Any time I reference NSMetadataQuery I'm making sure the class exists first:
if ([NSMetadataQuery class] != nil) …
Despite all this my app crashes immediately on launch if I try to run it on an iPod touch with iOS 4.2.1:
dyld: Symbol not found: _OBJC_CLASS_$_NSMetadataQuery
I've tried commenting out all the code any my app runs fine. As soon as I add back in a single reference to NSMetadataQuery, it crashes. I've even tried this:
if ([NSMetadataQuery class] != nil) NSLog(#"OK");
Simply including that line, and no other reference to NSMetadataQuery, crashes the app. Even more strange, checking for other iOS 5 classes doesn't cause any problems:
if ([UIDictationPhrase class] != nil) NSLog(#"OK");
That works fine, as expected.
I have been able to work around the problem using the uglier NSClassFromString() to make sure the class exists, but I'd love to know why the other approach isn't working.
I don't have an explanation to this but I ran into the same problem as you. No matter what I/you do, NSMetadataQuery just won't be weak linked...
Refer to this answer, which is really the best one in another question:
https://stackoverflow.com/a/8426591/129202
In short, other auto weak linking seems to work, it's just NSMetadataQuery* that you have to remove from source and replace with id. Instantiate the class with NSClassFromString() etc. No hiccups on other classes like UIDocument however so you can safely use those in the normal sweat free way.
NSMetadataQuery is available in iOS 5.0 and above, so any versions below that has no clue as to what it is. By merely using it in your code, the class name will be added to a symbol table and looked-up when the app launches.
I use below code for open image with NSOpenPanel but doesn't work
//panel=NSOpenPanel
NSString *imgg = [NSString stringWithFormat:#"%#",panel.URL];
self.imgUser.image=[NSImage imageNamed:imgg];
The problem is that +[NSImage imageNamed:] doesn't load an image by URL. If you read the documentation, it explains what it actually does: it looks for an image stored in the cache under that name, or stored in the app's bundle or AppKit's framework under that filename.
There are a large number of ways to actually open an image by URL. The one you're probably looking for is:
NSImage *image = [[[NSImage alloc] initWithContentsOfURL:panel.URL] autorelease];
Also, as a side issue, the way you're trying to turn a URL into a path is incorrect. If you have an NSURL for file://localhost/Users/user437064/Pictures/mypic.jpg, just converting that to a string just gives you #"file://localhost/Users/user437064/Pictures/mypic.jpg". That isn't a path that you can use with path-based APIs. What you actually want is #"/Users/user437064/Pictures/mypic.jpg", and the way you get that is -[NSURL path]. So "NSString *imgg = [panel.URL path];". But this is irrelevant; unless you need to deal with very old versions of OS X, or out-of-the-way APIs, there's almost always a method that takes a URL for each method that takes a path, and often the path-based ones are deprecated.
As an even farther-off-the-side issue, you don't need stringWithFormat: to convert something to a string; "[panel.URL description]" gives the exact same result as "[NSString stringWithFormat:#"%#", panel.URL]", much more simply and a little more efficiently.
I am trying to write a category and override fontWithName:size in UIFont. I am doing this for unit testing to avoid crashes caused by font names that are available on ipad and not on OSX. So I need to return a simple font that exists on both platform doesn't matter what the nib or code requests.
I tried the following but I run into an infinite loop, any idea on how I can achieve this?
+ (UIFont *)fontWithName:(NSString *)fontName size:(CGFloat)fontSize
{
return [UIFont fontWithName:#"Arial" size:fontSize];
}
Edit:
I also tried returning a CTFont but my test target does not recognize CTFont? Any idea what header I should import to use CTFont?
+ (UIFont *)fontWithName:(NSString *)fontName size:(CGFloat)fontSize
{
return [[[NSFont alloc] init] autorelease];
}
The above solution is an answer to my question.
But for fixing the unit testing problem I ended up running them as application tests instead of logic tests, that way they run in the iOS environment and they don't crash. The change was to set my Bundle Loader to point to my application target, and set the Test Host to post to my Bundle Loader.
By creating a category that has a method with the same you have replaced the original method. Therefore the following call is a recursive one: [UIFont fontWithName:#"Arial" size:fontSize];
I would create a new method with a different name (especially as the fontName parameter of your new method is unused), and switch all existing calls to use that.
See the accepted answer to this question for further discussion: Using Super in an Objective C Category?
I have written this trivial action method associated to a textfield.
Every time I enter text into a textfield a search in a PDF is performed and PDFView automatically scroll to selection:
- (IBAction) search:(id)id
{
NSString *query = [self.searchView stringValue]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
}
Problem is that after 3 or 4 searches I get EXC_BAD_ACCESS on row (i).
If I debug I see that query contains an NSCFString and not an NSString.
I think it is a memory management problem..but where?
I replicated the same issue inside a trivial testcase:
#interface PDFRef_protoTests : SenTestCase {
#private
PDFDocument *document;
}
........
- (void)setUp
{
[super setUp];
document = [[PDFDocument alloc] initWithURL: #"a local url ..."];
}
- (void)test_exc_bad_access_in_pdfdocument
{
for (int i =0 ;i<100; i++)
{
NSString *temp;
if (i % 2 == 0) temp = #"home";
else if (i % 3 ==0) temp = #"cocoa";
else temp=#"apple";
PDFSelection *selection = [document findString: temp
fromSelection:nil
withOptions:NSCaseInsensitiveSearch];
NSLog(#"Find=%#, iteration=%d", selection, i);
}
}
Update:
1) It seems that it happens also if I use asynchronous search (method beginFindString: withOptions) every time I perform second search.
2) I found a similar problem to mine in MacRuby Issue Tracking: http://www.macruby.org/trac/ticket/1029
3) It seems that if I disable temporarily garbage collection it works but memory goes up.
I wrote something like:
[[NSGarbageCollector defaultCollector] disable];
[[NSGarbageCollector defaultCollector] enable];
surrounding search code
Another Update
Very weird thing is that sometimes all works. Than I clean and Rebuild and problem arises again. From a certain point of view is is not 100% reproducible. I suspect a bug in PDFKit or some compiler setting I have to do
Update Again
Dears it seems very crazy. I'd concentrate on testcase which is very trivial and which replicates easily the problem. What's wrong with it? This testcase works only if I disable (by code or by project setting) GC
Another Update
Boys it seems a bug but I downloaded an example called PDFLinker from Apple website (http://developer.apple.com/library/mac/#samplecode/PDFKitLinker2/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003594). This example implements a PDFViewer. Code of my app and this example are quite similars. For the same search action on same PDF, my memory rises at 300/400 MB while PDFLinker rises at 190MB. Clearly there is something wrong in my code. But I am comparing it bit by bit and I don't think I am inserting memory leaks (and Instrument doesn't give me any evidence). Maybe is there some project-wide setting ?
Update Yet
Changing from 64 bit to 32 bit memory consumption lowered. Surely there is a problem with 64bit and PDFKit. BTW still EXC_BAD_ACCESS on second search
SOLUTION
Crucial point is that PDFKit with Garbage collection is bugged.
If I disable GC all works correctly.
I had another issue that had complicated my analysis: I disabled GC on Project Setting but GC remained enabled on Target Settings. So Apple's example PDFLinked2 worked while mine not.
I agree you have found a bug in PDFKit.
I got various forms of errors (segmentation fault, selector not understood, etc) running your test case. Wrapping the code in #try/#catch doesn't prevent all errors associated with this method.
I also got errors printing the log message.
To work around the bug(s), I suggest you disable GC during your invocation of -findString:fromSelection:, as you've already discovered.
Also, be sure to make copies of the values of interest from selection before re-enabling GC. Don't just copy selection either.
If you conduct searches from multiple places in your code I also suggest you extract a separate method to perform the search. Then you can invoke that one to conduct the searches for you without duplicating the GC disable/enable nesting.
This sort of thing is usually evidence that you're hanging onto a pointer to an object that has been destroyed. Turn on zombie objects (with NSZombieEnabled) to see exactly where and when you're accessing a bad object.
Judging from your screen shot it doesn't seem like you have NSZombie turned on. Probably the reason why it doesn't help you. Here's how you turn it on:
How to enable NSZombie in Xcode?
The screenshot you provided was otherwise very useful, but you really need NSZombie to figure out this kind of errors. Well, unless it's obvious, which it isn't from the code you posted.
EDIT: I read the comment that you're using garbage collection. I'm an iOS developer, so I have very limited experience with garbage collection in Objective-C, but as far as I understand NSZombie doesn't work in a garbage collected environment.
I'm not sure it should be possible to get EXC_BAD_ACCESS in a garbage collected environment, unless you create your own pointer and try to call methods on it without having created an object and I don't see why you would do that.
I've heard that some frameworks doesn't work well with garbage collection, but I wouldn't think PDFKit was among them. Anyway, the solution might be to not use garbage collection. Perhaps you should file a bug report with Apple.
keep PDFSelection *selection as a member variable and pass it in fromSelection: instead of nil.
It is possible that PDFDocument keeps the returned PDFSelection instance to improve the performance.
Did you try retaining the searchview stringvalue object before using it?
As you say it happens when you type fast and it happens for async calls, it is possible that the object stringValue is pointing to is being released between the time your query object is pointing to it, and the time you use it int the search.
You could try something like this to see if the problem persists:
- (IBAction) search:(id)id
{
NSString *query = [[self.searchView stringValue] retain]; // get from textfield
selection = [document findString: query fromSelection:NULL withOptions:NSCaseInsensitiveSearch];
if (selection != nil)
{
[self.pdfView setCurrentSelection:selection];
[self.pdfView scrollSelectionToVisible:self.searchView];
}
[query release];
}
Of course there is also the possibility that document is relased. How do you declare it? is it a property with retain? Can it be released by the time you are searching?
EDIT:
I see that you posted the code with the second parameter as NULL, but in your screenshot, this value is nil.
The documentation says you should use NULL when you want to start the search from the beginning.
http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/QuartzFramework/Classes/PDFDocument_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40003873-RH2-DontLinkElementID_1
And as the compiler interprets nil and NULL differently, this could be leading to some weird behavior internally.