Re: NSDocument window opens - even if the document didn't read properly.
Re: NSDocument window opens - even if the document didn't read properly.
- Subject: Re: NSDocument window opens - even if the document didn't read properly.
- From: Mike Abdullah <email@hidden>
- Date: Mon, 30 Jul 2012 09:35:55 +0100
On 29 Jul 2012, at 19:47, Pascal Harris wrote:
> Mike,
>
> Thanks for taking time on a Sunday to reply promptly. I'm very grateful. Taking each point
>
> On 29 Jul 2012, at 19:10, Mike Abdullah <email@hidden> wrote:
>
>> Hello, there are many things wrong with your code. I’m noting them below.
>>
>> On 29 Jul 2012, at 18:53, Pascal Harris wrote:
>>
>>> I hope that someone here might be able to help me with a couple of queries.
>>>
>>> 1. I'm trying to open a document (NSDocument). If the file is good then my program opens it without problem. If the document fails to parse correctly then the NSDocument window still opens - but it opens empty. Of course, if parsing of the document fails then I want the document window not to open at all. The document data gets read as so and if it fails then I return NO - the document window still opens though. Can anyone suggest what I might have missed or messed up?
>>>
>>> - (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError
>>> {
>>> BOOL success = NO;
>>>
>>> success = [self loadTextViewWithInitialData: data];
>>
>> Uh-oh, if this call failed, you’re returning NO without filling in the error pointer. This will either blow up or provide a poor message to the user. Hopefully your -loadTextView… method can report why it failed.
> Good point - I've now fixed this. That still doesn't explain why the window stays open though. When I fix this problem, it doesn't provide an error message to the user either. Perhaps this is connected to the reason that the window opens anyway, even if the data can't be read.
>
> NSMutableDictionary *errorDetail = [NSMutableDictionary dictionary];
> [errorDetail setValue:@"This file is corrupted and could not be read." forKey:NSLocalizedDescriptionKey];
>
> *outError = [NSError errorWithDomain:NSOSStatusErrorDomain code:1 userInfo:
> errorDetail];
As Quincey points out, you should check the outError pointer first before filling it in. Also, we already have NSFileReadCorruptFileError which would seem the most appropriate error code here.
>
>
>>
>>> if (!success)
>>> {
>>> NSArray* paths = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES);
>>
>> Cocoa has URL-based methods for this in NSFileManager these days; you should consider adopting them.
> Thank you - I will. But I want to get this working first. By examining the path provided in the string, I can see that the destination is valid - and I've used code like this successfully in the past. Is the problem that the file being copied is also the file that I'm attempting (unsuccessfully) to open? Is it that there's a temporary lock on the file that prevents it from copying successfully?
Unlikely.
>
>
>>
>>> NSString* URLString = [[[paths objectAtIndex:0] stringByAppendingString:[self fileURL].lastPathComponent]stringByAppendingString:@".bad"];
>>
>> This is some seriously mangled code. Cocoa provides path manipulation-specific string routines. USE THEM.
>>
>>> NSURL* destinationURL = [NSURL URLWithString:[URLString stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
>>
>> This is NOT how you convert from a path to a URL. Use +fileURLWithPath: instead.
> Again, it's worked in the past. I changed it to fileURLWithPath - but the end result is the same.
If it worked in the past, the strings you had were NOT file paths. Just because a URL object is created does not necessarily mean it’s the one you’re expecting.
>
>>
>>> BOOL success = [[NSFileManager defaultManager] copyItemAtURL:[self fileURL] toURL:destinationURL error:nil];
>>
>> You’ve just stored success into a *new* variable. I’m guessing you wanted to store it into the existing success variable. Unless you’ve changed the default compiler settings, the compiler should be warning you here that the success variable is unused. Compiler warnings are useful. HEED THEM.
> I do use the variable - just not in that little example I gave. And rest assured that I heed all compiler warnings, and deal with them.
Alright, show us the real code then! It’s impossible for us to debug code we can’t see.
Also I forgot to mention that since -copyItem… can return an error, you should make use of that in your routine.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden