> On 2015 Nov 01, at 04:58, Michael de Haan wrote:
>
> NSUserDefaults.standardUserDefaults().removePersistentDomainForName(bundleIdentifier!)
That line of code seems like it is pulling the rug out from under Cocoa
Bindings, which might explain why they don’t work.
A better way to reset to d
> On Jun 28, 2015, at 11:35 PM, Henrik Granaas-Helmers wrote:
>
> Hi there,
>
> I am new to Apple development, and new to this list. I have two questions
> about memory on OS X.
>
> 1. NSUserDefaults seems to allocate 16 MB memory at load. I can't see myself
> using a megabyte—let alone 16 o
> On Jun 28, 2015, at 11:35 PM, Henrik Granaas-Helmers wrote:
>
> 1. NSUserDefaults seems to allocate 16 MB memory at load. I can't see myself
> using a megabyte—let alone 16 of those. It would be very interesting to know
> why it allocates so much, and if there is a way to encourage NSUserDef
On Jun 28, 2015, at 23:35 , Henrik Granaas-Helmers wrote:
>
> 1. NSUserDefaults seems to allocate 16 MB memory at load. I can't see myself
> using a megabyte—let alone 16 of those. It would be very interesting to know
> why it allocates so much, and if there is a way to encourage NSUserDefaults
Makes sense, but I would have a much bigger problem if it would be every
non-admin account I think. But yeah I need to fix my code and go from there.
I’ll let you guys know if I have problems after that thanks!
rc
> On Dec 13, 2014, at 6:31 AM, Seth Willits wrote:
>
>> On Dec 11, 2014, at
So I found some old code where I was using NSAppleScript with "defaults write"
ouch! :-) Sorry about that but curious why would this fail at times? Pretty
sure that switching it to the proper NSUserDefaults will work fine…
> On Dec 11, 2014, at 10:24 PM, gweston wrote:
>
> Rick C. wrote:
> On Dec 10, 2014, at 11:05 PM, Rick C. wrote:
>
> I write an NSString and NSData object to my app’s .plist and of course read
> it back when needed and this works fine 99% of the time. On occasion a user
> reports some trouble to me and I ask for the .plist and find out that this
> NSString/
> On Dec 10, 2014, at 11:05 PM, Rick C. wrote:
>
> Hi,
>
> Digging deeper I find that most often the user has their home folder on a
> different drive (external?) than the actual app. What would be the solution
> to make sure these objects are written properly in this case?
There's nothing
Rick C. wrote:
I write an NSString and NSData object to my app’s .plist and of course read it
back when needed and this works fine 99% of the time. On occasion a user
reports some trouble to me and I ask for the .plist and find out that this
NSString/NSData object is missing. Digging deeper I
1. Only certain ones that I know of
2. At application launch
3. No
4. I think Mavericks but not 100% certain
5. For the affected users yes
6. Not sure about this could check
7. Upon my request yes
8. Not sure would have to check
On Sep 11, 2014, at 3:21 PM, Bavarious wrote:
> Em 11/09/2
Em 11/09/2014, à(s) 01:07, Rick C. escreveu:
>
> This is all very interesting and shows that there are issues out there, but
> back to my original issue if I’m writing and reading via NSUserDefaults and
> its not returning the expected values what else could be the trouble?
1) Do all preferenc
This is all very interesting and shows that there are issues out there, but
back to my original issue if I’m writing and reading via NSUserDefaults and its
not returning the expected values what else could be the trouble?
rc
On Sep 11, 2014, at 11:59 AM, Charles Srstka wrote:
> On Sep 10, 2
On Sep 10, 2014, at 10:50 PM, Graham Cox wrote:
> On 11 Sep 2014, at 1:19 pm, Charles Srstka wrote:
>
>> NSDictionary *domain = [def persistentDomainForName:@"com.apple.TextEdit"];
>
>
> The documentation states that this is not supported under sandboxing.
>
> When you say "does not ... work
On Sep 10, 2014, at 10:34 PM, Marco S Hyman wrote:
> On Sep 10, 2014, at 8:19 PM, Charles Srstka wrote:
>
>>
>>> Where did you get the idea that NSUserDefaults doesn't work for sandboxed
>>> apps? It certainly does.
>>
>> #import
>>
>> int main(int argc, const char * argv[]) {
>> @autore
On 11 Sep 2014, at 1:19 pm, Charles Srstka wrote:
> NSDictionary *domain = [def persistentDomainForName:@"com.apple.TextEdit"];
The documentation states that this is not supported under sandboxing.
When you say "does not ... work", you really need to make clear what you mean.
--Graham
___
On Sep 10, 2014, at 8:19 PM, Charles Srstka wrote:
>
>> Where did you get the idea that NSUserDefaults doesn't work for sandboxed
>> apps? It certainly does.
>
> #import
>
> int main(int argc, const char * argv[]) {
>@autoreleasepool {
>NSUserDefaults *def = [NSUserDefaults stand
On Sep 10, 2014, at 9:39 PM, Graham Cox wrote:
> On 11 Sep 2014, at 12:14 pm, Charles Srstka wrote:
>
>> If that's true, then why does the 'defaults' program work for sandboxed
>> apps, while NSUserDefaults does not?
>
>
> Where did you get the idea that NSUserDefaults doesn't work for sandb
On 11 Sep 2014, at 12:14 pm, Charles Srstka wrote:
> If that's true, then why does the 'defaults' program work for sandboxed apps,
> while NSUserDefaults does not?
Where did you get the idea that NSUserDefaults doesn't work for sandboxed apps?
It certainly does.
--Graham
On Sep 10, 2014, at 7:04 PM, Scott Ribe wrote:
>
> The real point: plenty of sites on the web state that the .plist no longer
> represents the current state, but that the defaults command will read the
> current state so you can use it for debugging. They are wrong. Apparently
> there's someth
On Sep 10, 2014, at 7:41 PM, Kyle Sluder wrote:
> On Wed, Sep 10, 2014, at 07:32 PM, Rick C. wrote:
>> And about not relying on the .plist if we don’t rely upon it how do we
>> write our prefs? I understand I should not manipulate it directly, but I
>> am calling everything via NSUserDefaults…
>
On Sep 10, 2014, at 6:42 PM, Graham Cox wrote:
> Then you should be fine. The point is that the .plist does not necessarily
> represent the current state of the defaults for your app. Trashing it for
> example no longer resets the defaults like it used to, you have to go through
> the defaults
On 11 Sep 2014, at 10:32 am, Rick C. wrote:
> And about not relying on the .plist if we don’t rely upon it how do we write
> our prefs? I understand I should not manipulate it directly, but I am
> calling everything via NSUserDefaults…
Then you should be fine. The point is that the .plist d
On Wed, Sep 10, 2014, at 07:32 PM, Rick C. wrote:
> And about not relying on the .plist if we don’t rely upon it how do we
> write our prefs? I understand I should not manipulate it directly, but I
> am calling everything via NSUserDefaults…
Continue using NSUserDefaults for all interaction with
Thanks to everyone for the help. I’m pretty sure about this Graham but I will
take one last look. Problem is I’m never able to reproduce this issue and as I
mentioned this is happening to a very small percentage of users which would
seem to mean it’s not my code (???). It’s just trying to fig
On Wed, Sep 10, 2014, at 11:15 AM, Todd Heberlein wrote:
> > in the past few years when it's happened it's been an early symptom of
> > filesystem corruption. Sometimes there have been a bunch of leftover
> > temporary lock(?) files in the Preferences directory.
> >
> > If you're getting reports
> in the past few years when it's happened it's been an early symptom of
> filesystem corruption. Sometimes there have been a bunch of leftover
> temporary lock(?) files in the Preferences directory.
>
> If you're getting reports of this from users of your app, it might be worth
> asking them t
I've run into issues of app preferences/defaults not persisting (across lots of
apps, not necessarily just my own), and in the past few years when it's
happened it's been an early symptom of filesystem corruption. Sometimes there
have been a bunch of leftover temporary lock(?) files in the Prefe
On 10 Sep 2014, at 3:43 pm, Rick C. wrote:
> Thanks for the help. So I have double-checked and the info in question that
> is not sticking is NSString/NSData being written:
>
> [[NSUserDefaults standardUserDefaults] setObject:stringObject
> forKey:@“MyStringKey”];
> [[NSUserDefaults standard
Are you calling synchronise too when you're writing?
[[NSUserDefault standardUserDefaults] synchronise]
Verstuurd vanaf mijn iPhone
> Op 10 sep. 2014 om 07:43 heeft "Rick C." het volgende
> geschreven:
>
> Thanks for the help. So I have double-checked and the info in question that
> is no
Thanks for the help. So I have double-checked and the info in question that is
not sticking is NSString/NSData being written:
[[NSUserDefaults standardUserDefaults] setObject:stringObject
forKey:@“MyStringKey”];
[[NSUserDefaults standardUserDefaults] setObject:dataObject
forKey:@“MyDataKey”];
On 9 Sep 2014, at 3:36 pm, Rick C. wrote:
> I write some data to my .plist using standard NSUserDefaults
Are you writing the .plist file, or are you using the NSUserDefaults object
exclusively? From 10.9 the .plist isn't updated by NSUserDefaults, so values
there can be very much out of date
On Jul 26, 2013, at 5:15 PM, Keith Knauber wrote:
> From Apple Docs:
> Values returned from NSUserDefaults are immutable, even if you set a mutable
> object as the value. For example, if you set a mutable string as the value
> for "MyStringDefault", the string you later retrieve usingstringForK
Hi Quincey,
Your suggested fix works fine, except I used -arrayForKey rather than
-arrayValueForKey (which I couldn't find). Thanks for the explanation!
Cheers,
Martin
On Aug 10, 2012, at 07:15 AM, Quincey Morris
wrote:
> On Aug 9, 2012, at 22:49 , Martin Hewitson wrote:
>
>> I have a tab
On Aug 9, 2012, at 22:49 , Martin Hewitson wrote:
> I have a table view bound to shared user defaults with a key which returns an
> array of strings.
> I have a button for creating a new entry. This calls a piece of code like
> this:
>
>
> NSUserDefaults *defaults = [NSUserDefaults standard
On 2009 Dec 12, at 22:47, Joar Wingfors wrote:
> That's strictly speaking only true for NSDictionary, where you can't
> configure how keys are added to the dictionary. CFDictionary allows full
> control over that, and doesn't even require for the keys to be objects.
OK, I ammended the bug to e
On 12 dec 2009, at 22.04, Jerry Krinock wrote:
>> And although NSDictionary and CFDictionary objects allow their keys to be
>> objects of any type, if the keys are not string objects, the collections are
>> not property-list objects.
>
> Actually, there's a third bug, since that statement is i
On 2009 Dec 12, at 10:20, Chris Parker wrote:
> And although NSDictionary and CFDictionary objects allow their keys to be
> objects of any type, if the keys are not string objects, the collections are
> not property-list objects.
Actually, there's a third bug, since that statement is incorrect.
As Clark noted elsewhere, you're using a string key properly with
NSUserDefaults itself and NSUserDefaults and CFPreferences both require that
the entire subtree of the value be a properly formed property list object.
For NSDictionaries that means all keys must be strings for the entire tree. Th
On 12 Dec 2009, at 14:58, Jerry Krinock wrote:
>
> On 2009 Dec 11, at 23:21, Clark Cox wrote:
>
>> The message printed is unfortunate, as it doesn't really tell you what
>> is wrong (please file a bug). It's fine to have numbers as keys in
>> dictionaries; however keys property lists (and there
On 2009 Dec 11, at 23:21, Clark Cox wrote:
> The message printed is unfortunate, as it doesn't really tell you what
> is wrong (please file a bug). It's fine to have numbers as keys in
> dictionaries; however keys property lists (and therefore in user
> defaults) must be strings.
Well, maybe the
On Fri, Dec 11, 2009 at 11:10 PM, Jerry Krinock wrote:
> Sorry for the wonky subject. It's easier to explain in code:
>
> NSNumber* innerKey = [NSNumber numberWithInt:0] ;
> NSDictionary* dic = [NSDictionary dictionaryWithObject:@"Hello"
> forKey:inn
Fair enough, I s'pose that makes sense for most apps.
Since I'm targeting 10.4+, and, actually, am using CFPreferences
instead of NSUserDefaults, I wrote a simple "autosynchronize"
mechanism that synchronizes preferences if needed at the end of the
runloop. It lets multiple defaults be changed at
No, it does actually behave as documented. In 10.6 I know it syncs
after 15
seconds.
In 10.6, I've noticed that my app and other apps are leaving some
empty files in ~/Library/Preferences such as
"com.apple.iTunes.eq.plist.Z9l0HBm".
Is it possible for these relics to occur if the automa
Hi Jens,
On Tue, Sep 8, 2009 at 4:24 PM, Jens Alfke wrote:
>
> On Sep 8, 2009, at 4:13 PM, Sidney San Martín wrote:
>
> "Because this method is automatically invoked at periodic intervals, use
>> this method only if you cannot wait for the automatic synchronization (for
>> example, if your appl
On Sep 8, 2009, at 4:24 PM, Jens Alfke wrote:
On Sep 8, 2009, at 4:13 PM, Sidney San Martín wrote:
"Because this method is automatically invoked at periodic
intervals, use this method only if you cannot wait for the
automatic synchronization (for example, if your application is
about to exi
On Sep 8, 2009, at 4:13 PM, Sidney San Martín wrote:
"Because this method is automatically invoked at periodic intervals,
use this method only if you cannot wait for the automatic
synchronization (for example, if your application is about to exit)"
To my knowledge that's always been incorr
That's how I do it. I also use setValue:forKey: when passing
NSLocalizedString()
-Steve
On Sep 3, 2009, at 5:05 PM, Oftenwrong Soong wrote:
Hi all,
Why does NSUserDefaults provide method stringForKey but not a method
setString:forKey (akin to setBool:forKey, setFloat:forKey, etc.)?
Thi
On Sep 3, 2009, at 5:05 PM, Oftenwrong Soong wrote:
Why does NSUserDefaults provide method stringForKey but not a method
setString:forKey (akin to setBool:forKey, setFloat:forKey, etc.)?
This does not seem symmetric.
I'm using setObject:forKey when saving a NSString to the defaults
databas
As NSString, NSData, NSDictionary, etc are derived from NSObject, they can
be easily set with -setObject:forKey:, whereas int, float, NSInteger, etc
are scalar types and thus cannot be set with this method. Thus, they have
convenient setters/getters, whereas object types have convenient getters
onl
rick
From: Jerry Krinock
To: cocoa dev
Sent: Monday, August 31, 2009 2:04:17 AM
Subject: Re: nsuserdefaults woes
On 2009 Aug 30, at 08:11, Rick C. wrote:
> if that's the only way i'll have to look into it. one question though, is
> there anything i could have done that
On 2009 Aug 30, at 08:11, Rick C. wrote:
if that's the only way i'll have to look into it. one question
though, is there anything i could have done that i can no longer
read using addSuiteNamed along with arrayForKey like i mentioned in
my original post?
Maybe it's not an array any more
2009 9:33:33 PM
Subject: Re: nsuserdefaults woes
I may be wrong, because I'm in a hurry here, but I believe ethat -addSuiteNamed
only works for reading preferences. If you want to write preferences to
another app you've got to use the CFPrefe
I may be wrong, because I'm in a hurry here, but I believe ethat -
addSuiteNamed only works for reading preferences. If you want to
write preferences to another app you've got to use the CFPreferences
API (unfortunately).
___
Cocoa-dev mailing li
Hey Todd,
This worked for me...
In interface builder, you will need an Array controller
Mode: ClassClass Name:NSMutableDictionary
Content Array bound to Shared User Defaults Controller - controller
key:values - modal key path:yourDefaultsKey
Make sure handles content as a compound value
Not sure how to best join a thread since there's no "Reply" link on
Apple Mailing Lists, but...
I've been struggling to do what Daniel wants for a week and can't
figure it out either. My user defaults are not a flat list and I need
to be able to bind to subdictionary values in Interface Build
On Sat, Aug 30, 2008 at 4:35 PM, Brad Gibbs <[EMAIL PROTECTED]> wrote:
> While I did learn some things from this, I'm confused about NSUserDefaults
> and the values it can store. I created an NSMutableDictionary to register
> the defaults, which is, I believe archived as a property list. Floats c
Thanks for all of the responses. After some monkeying around, I
figured out that I'd used an NSNumber where I should have used an
NSString. The code is now compiling and running happily.
While I did learn some things from this, I'm confused about
NSUserDefaults and the values it can store
On 30 Aug 2008, at 2:04 pm, Graham Cox wrote:
You can really tell
I meant of course that you CAN'T really tell...
G.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Cont
On 30 Aug 2008, at 11:54 am, Brad Gibbs wrote:
NSLog(@"gradient angle is %d", [elementBarGradientAngleTextField
intValue]);
[defaults setInteger:[elementBarGradientAngleTextField intValue]
forKey:ICNElementBarGradientAngleKey];
NSLog(@"Element bar angle is now: %d",
[ICNElementBarGradie
On Aug 29, 2008, at 8:54 PM, Brad Gibbs wrote:
I'm having a hard time with what should be a simple task - storing
an integer for a gradient angle as a user default and then updating
the screen. When I quit the app and open it again, the NSTextField
shows the last value I set for the gradie
On 30 Aug 2008, at 12:14 pm, Andrei Kolev wrote:
Brad,
You can't store an int into [...] user defaults.
Sure you can:
- (void)setInteger:(NSInteger)value forKey:(NSString *)defaultName;
Note that NSInteger == int, so the book doesn't have a typo, it's just
using the pre-Leopard type co
Well, it appears that I need to convert either an NSNumber or an
NSString to a CGFloat, rather than an int:
- (void)drawInRect:(NSRect)rect angle:(CGFloat)angle
There don't appear to be any methods in either NSNumber or NSString to
do this
On Aug 29, 2008, at 7:36 PM, Brad Gibbs wrote
Brad,
You can't store an int into a Dictionary or user defaults. For the
objects you can use, see here:
http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/AboutPropertyLists.html#/
/apple_ref/doc/uid/20001010
NSNumber and NSString should work.
Also, [ICNEleme
Thanks.
I'd read that dictionaries and plists were particular in the types
they accept, but I was looking at page 201 of Hillegass (3rd edition),
which shows:
- (void)setInteger:(int)value forKey:(NSString *)defaultName
and
- (int)integerForKey:(NSString *)defaultName
and blindly followe
I'm having a hard time with what should be a simple task - storing an
integer for a gradient angle as a user default and then updating the
screen. When I quit the app and open it again, the NSTextField shows
the last value I set for the gradient, but with the following code:
- (IBAction)ch
On Mar 9, 2008, at 10:50 AM, Trygve Inda wrote:
In Carbon I could do:
CFPropertyListCreateDeepCopy (kCFAllocatorDefault, localDict,
kCFPropertyListMutableContainersAndLeaves);
Is there a NSDictionary way to do this?
The above. An NSDictionary is toll-free bridged to CFDictionaryRef,
so go
>> Is it enough then to take the dictionary I get back and do a [dict
>> mutableCopy]?
>>
>> Will this cascade down to the "subdicts" (dicts within the top level
>> dict).
>
>
> No it won't. mutableCopy only operates on one particular object and
> not all its contained objects. While that beh
On Mar 9, 2008, at 5:58 AM, Trygve Inda wrote:
On 8 Mar '08, at 1:57 PM, Trygve Inda wrote:
Is this expected? Can I rely on it? I will never need to change
dict, but I
am modifying items within a known sub Dictionary.
Don't rely on this; it's entirely possible this behavior could change
in
>
> On 8 Mar '08, at 1:57 PM, Trygve Inda wrote:
>
>> Is this expected? Can I rely on it? I will never need to change
>> dict, but I
>> am modifying items within a known sub Dictionary.
>
> Don't rely on this; it's entirely possible this behavior could change
> in the future, causing your app to
On Mar 8, 2008, at 6:16 PM, Jens Alfke wrote:
Don't rely on this; it's entirely possible this behavior could
change in the future, causing your app to throw an exception.
Something much like that happened in 10.4 (I think) — maybe it was
the mutability of collections read from property lis
On 8 Mar '08, at 1:57 PM, Trygve Inda wrote:
Is this expected? Can I rely on it? I will never need to change
dict, but I
am modifying items within a known sub Dictionary.
Don't rely on this; it's entirely possible this behavior could change
in the future, causing your app to throw an exce
71 matches
Mail list logo
