Re: Are there any NSUserDefaults keys which aren't valid?
Re: Are there any NSUserDefaults keys which aren't valid?
- Subject: Re: Are there any NSUserDefaults keys which aren't valid?
- From: Jonathan del Strother <email@hidden>
- Date: Thu, 26 Jan 2006 19:59:08 +0000
On 26 Jan 2006, at 19:32, j o a r wrote:
On 26 jan 2006, at 20.20, John Stiles wrote:
@synchronized may not be a sufficient workaround. When the AppKit
docs say that something isn't thread-safe, you are required to run
it on the main thread. Violate that contract and you are in
"unspecified behavior" territory.
Absolutely true! But, like was pointed out in the other thread on
this topic a few days ago:
<http://www.cocoabuilder.com/archive/message/cocoa/2005/8/11/144082>
If his users are using 10.4 and later, he probably shouldn't have
to lock at all.
Johathan; In the sample code provided, you haven't described the
"fileDate" variable. Can you tell us how it's created and used?
It's set up a little earlier on, via :
NSDate* fileDate = [[[NSFileManager defaultManager]
fileAttributesAtPath:file traverseLink:YES]
objectForKey:NSFileModificationDate];
'file' has been guaranteed to exist, using
if ([[NSFileManager defaultManager] fileExistsAtPath:file])
{...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden