Re: NSUserDefaults not sticking
On 10 Sep 2014, at 3:43 pm, Rick C. rickcort...@gmail.com 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 standardUserDefaults] setObject:dataObject forKey:@“MyDataKey”]; Then being read: NSString *myStringObject = [[NSUserDefaults standardUserDefaults] stringForKey:@“MyStringKey]; NSData *myDataObject = [[NSUserDefaults standardUserDefaults] dataForKey:@“MyDataKey”]; I am not manipulating my .plist in any other way only using NSUserDefaults That should definitely work. Are you certain something else somewhere isn't using the same key to change the setting? Is it possible that the object passed to -setObject:forKey: isn't a NSString or NSData? The named getter methods also check the type - does it work if you use -objectForKey: instead? Try logging the objects, it's probably something you didn't expect. Are you calling synchronise too when you're writing? That isn't needed. It used to flush the defaults to disk but it no longer does anything AFAIK. It was never needed within a single app session, and was invoked automatically on quit. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 Preferences directory. If you're getting reports of this from users of your app, it might be worth asking them to run Disk First Aid. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to set UILabel height to even multiple of line height with auto-layout?
That's not the issue I'm having. Let's say, for example, that label3 contains abcdefghijklmnopqrstuvwxyz; the line height for the font 10; and when the label is laid out the label height is 25. This results in a label that looks like this: +——+ |abcdefghij| |klmnopqrst| |(blank) | +——+ The first two lines are visible, but the third line is not drawn because the label is not tall enough to completely draw the last line. My question, below, was trying to determine how I could adjust the label height so that it's an even multiple of the font's line height, so in this case the label height would be adjusted to 20 (2 x 10) and the text would be drawn like this: +——+ |abcdefghij| |klmnopqrs…| +——+ On Sep 9, 2014, at 5:45 PM, Cosmo dennisbi...@gmail.com wrote: In my experience, setting a label's numberOfLines property to 1 and its lineBrakeMode property to NSLineBreakByTruncatingTail is all it takes to get text to truncate. You can do it in code, or in IB if you’re laying out your tableViewCell in a storyboard or XIB. On Sep 9, 2014, at 12:48 PM, Steve Christensen puns...@mac.com wrote: I have a UITableViewCell with several stacked UILabels: - label1: set to 1 line, height = single line height, fixed bottom spacing - label2: set to 2 lines, height ≥ single line height, fixed bottom spacing - label3: set to 0 lines, height ≥ single line height, bottom spacing ≥ min spacing The layout works in the sense that everything lays out based on the constraints, but if label3's text doesn't entirely fit within the allotted space then I want to see it truncated with an ellipsis. Instead label3's height generally is not an even multiple of its line height so any lines that are not entirely visible just don't get drawn. I tried overriding -layoutSubviews or -updateConstraints in my UITableViewCell subclass, calling super, then figuring that I could set label3.numberOfLines based on the number of lines that evenly fit into the new value of label3.frame.size.height, but after calling super the height hadn't changed from its initial single-line value. Are these the right places to do this and I'm just missing some extra work or is there a better way? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 to run Disk First Aid. I’ve run into this problem during software development (can’t recall for shipping apps). Since it is just during development, I trash the preferences file for the app and the problem usually goes away. (I’m wondering if the file contents became corrupted) Todd ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 of this from users of your app, it might be worth asking them to run Disk First Aid. I’ve run into this problem during software development (can’t recall for shipping apps). Since it is just during development, I trash the preferences file for the app and the problem usually goes away. Part of the problem might be that you should avoid touching or viewing the plist files in ~/Library/Preferences. cfprefsd has gotten more and more aggressive about in-memory caching over the past few years, and the preferences files might be out of date. If you want to nuke an app's preferences, use `defaults delete your.bundle.identifier`. However, in the past that has sometimes not found the correct container. In that case you might still need to delete the appropriate plist, but you may need to log out and back in both before and after doing so to ensure that the changes are picked up by cfprefsd. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to copy Color Panel behaviour?
On 10 Sep 2014, at 01:56, Kyle Sluder k...@ksluder.com wrote:
On Tue, Sep 9, 2014, at 06:42 PM, Graham Cox wrote:
On 10 Sep 2014, at 7:13 am, Luc Van Bogaert luc.van.boga...@me.com
wrote:
This opens the panel without making it key, which is OK, but it still makes
the panel key when I click any of the responder objects in the panel, such
as a collectionview...
'becomesKeyOnlyIfNeeded' does what it says, but how does it define
'needed'. It does that by allowing the panel to become key if any of its
views or controls accept first responder. So to prevent that, these also
need to refuse FR by overriding -acceptsFirstResponder to return NO.
There's also the corresponding method, -needsPanelToBecomeKey, which is
used by things like text fields to ensure they actually work when
clicked on.
No succes so far with this.
I subclassed NSPanel and overridden:
- (BOOL) becomesKeyOnlyIfNeeded
{
return YES;
}
- (BOOL) canBecomeKeyWindow
{
return YES;
}
I also subclassed the collection view in the panel and overridden:
- (BOOL) acceptsFirstResponder
{
return NO;
}
- (BOOL) needsPanelToBecomeKey
{
return NO;
}
Clicking the collectionview still makes the panel the key window, which is
exactly what I'm trying to avoid.
--
Luc Van Bogaert
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to copy Color Panel behaviour?
On Sep 10, 2014, at 4:07 PM, Luc Van Bogaert luc.van.boga...@me.com wrote:
No succes so far with this.
I subclassed NSPanel and overridden:
- (BOOL) becomesKeyOnlyIfNeeded
{
return YES;
}
- (BOOL) canBecomeKeyWindow
{
return YES;
}
I also subclassed the collection view in the panel and overridden:
- (BOOL) acceptsFirstResponder
{
return NO;
}
- (BOOL) needsPanelToBecomeKey
{
return NO;
}
Clicking the collectionview still makes the panel the key window, which is
exactly what I'm trying to avoid.
What about the view hierarchy of the item that's actually been clicked within
the collection view? What is actually becoming first responder?
Also, the release notes from when -becomesKeyOnlyIfNeeded was added seem to
imply that it's for panels with NSNonactivatingPanelMask in their style mask.
The rest of the docs don't include the same caveat, but it's worth checking.
Regards,
Ken
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to copy Color Panel behaviour?
On 10 Sep 2014, at 23:32, Ken Thomases k...@codeweavers.com wrote:
On Sep 10, 2014, at 4:07 PM, Luc Van Bogaert luc.van.boga...@me.com wrote:
No succes so far with this.
I subclassed NSPanel and overridden:
- (BOOL) becomesKeyOnlyIfNeeded
{
return YES;
}
- (BOOL) canBecomeKeyWindow
{
return YES;
}
I also subclassed the collection view in the panel and overridden:
- (BOOL) acceptsFirstResponder
{
return NO;
}
- (BOOL) needsPanelToBecomeKey
{
return NO;
}
Clicking the collectionview still makes the panel the key window, which is
exactly what I'm trying to avoid.
What about the view hierarchy of the item that's actually been clicked within
the collection view? What is actually becoming first responder?
Also, the release notes from when -becomesKeyOnlyIfNeeded was added seem to
imply that it's for panels with NSNonactivatingPanelMask in their style mask.
The rest of the docs don't include the same caveat, but it's worth checking.
Those times I checked, it was the panel itself that was the first responder.
BUT, in the meantime, I decided to retry another route that I had been
experimenting with the last couple of days, and I have now found a working
solution, although maybe a little complicated.
It involves 'listening' for the mouseDown: event that is sent to the
NSThemeFrame object when you click the panel's titlebar. I'm using the panel's
'awakeFromNib' to replace the default NSThemeFrame' mouseDown: method with my
own implementation which allows the panel to become key (setting a BOOL
property), and then I send the panel a 'makeKeyWindow:' message. Second, I'm
using the window delegate to reset the ability of the panel to become key in
'windowDidResignKey:'.
So once I click out of the panel, its ability to become key is switched back
off again and things are back to their initial state.
I still am going to have to optimise this a little bit in the next few days.
Anyway, thanks for all the help and advice.
--
Luc Van Bogaert
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
FYI, SQLite-based geo-queries are broken in Yosemite DP7
(I know this technically isn't about Cocoa APIs, but cocoa-dev still seems like the most appropriate list. I suspect a lot of app developers don't read darwin-userlevel.) Those of you with Mac apps that do geo-querying using SQLite may be interested to know that your queries probably broke in Yosemite DP7. In that build, Apple upgraded SQLite to version 3.8.5, which has a regression[1] in the r-tree implementation that causes queries using joins to fail to return data. I have a brief test[2] that shows the problem. Essentially, if you have a table created with CREATE VIRTUAL TABLE … USING rtree and then query that table's x/y coords and use its primary key to join to another table (which is the most common way to do geo-querying) you'll probably get an empty result set instead of the data you wanted. I've filed a bug report with Apple, rdar://18247755 rdar://18247755, asking them to update to SQLite 3.8.6 which fixes the regression. But it's iffy whether they'll update SQLite so late in the release cycle. If geo-queries are important to your apps, you might want to vote by filing your own dups and referencing my Radar. (As of DP6, iOS 8 didn't have the buggy SQLite. I haven't yet had a chance to test with the GM candidate that was released this week, but it's obviously too late for Apple to fix it there.) —Jens [1]: http://www.sqlite.org/src/tktview?name=d2889096e7 http://www.sqlite.org/src/tktview?name=d2889096e7 [2]: https://gist.github.com/snej/f76733c4a65902ab7b32 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 figure out what is different about their cases that is causing me trouble… Regarding the lock files maybe the next time I get this reported I can inquire about this… 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… rc On Sep 10, 2014, at 2:14 PM, Graham Cox graham@bigpond.com wrote: On 10 Sep 2014, at 3:43 pm, Rick C. rickcort...@gmail.com 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 standardUserDefaults] setObject:dataObject forKey:@“MyDataKey”]; Then being read: NSString *myStringObject = [[NSUserDefaults standardUserDefaults] stringForKey:@“MyStringKey]; NSData *myDataObject = [[NSUserDefaults standardUserDefaults] dataForKey:@“MyDataKey”]; I am not manipulating my .plist in any other way only using NSUserDefaults That should definitely work. Are you certain something else somewhere isn't using the same key to change the setting? Is it possible that the object passed to -setObject:forKey: isn't a NSString or NSData? The named getter methods also check the type - does it work if you use -objectForKey: instead? Try logging the objects, it's probably something you didn't expect. Are you calling synchronise too when you're writing? That isn't needed. It used to flush the defaults to disk but it no longer does anything AFAIK. It was never needed within a single app session, and was invoked automatically on quit. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 the preferences system. That's what the `defaults` command uses too. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On 11 Sep 2014, at 10:32 am, Rick C. rickcort...@gmail.com 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 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 system to reset them (as Kyle pointed out). --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 6:42 PM, Graham Cox graham@bigpond.com 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 system to reset them (as Kyle pointed out). Interesting point here... I was recently trying to debug some things I was doing with NSUserDefaults (stuffing printer settings into flattened XML apparently coded as Base64), and ran across the problem that the .plist is not updated when you sync, so I was unable to look at the plist to confirm what was actually being stored, which made debugging significantly more obtuse. 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 something about the caching such that defaults, and I expect any other process outside the one making the changes, DOES NOT return the latest values you synched. It is absolutely the case that your app can use NSUserDefaults to update defaults, can synch them, can then read back the new values and confirm that NSUserDefaults is returning the latest values you gave it, and the defaults command line will at that point still be returning stale values from before your update. Now, whether this differs depending on whether or not you're running under the debugger, I didn't check. I figured out my bug and fixed it before I got to that point ;-) But basically, this is now a royal PITA to debug, because there does not seem to be ANY way to externally confirm what your program has written into the defaults db. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 7:41 PM, Kyle Sluder k...@ksluder.com 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… Continue using NSUserDefaults for all interaction with the preferences system. That's what the `defaults` command uses too. If that's true, then why does the 'defaults' program work for sandboxed apps, while NSUserDefaults does not? Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 7:04 PM, Scott Ribe scott_r...@elevated-dev.com 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 something about the caching such that defaults, and I expect any other process outside the one making the changes, DOES NOT return the latest values you synched. It is absolutely the case that your app can use NSUserDefaults to update defaults, can synch them, can then read back the new values and confirm that NSUserDefaults is returning the latest values you gave it, and the defaults command line will at that point still be returning stale values from before your update. It’s my understanding that this shouldn’t happen. If you can reproduce it, you should file a Radar. Also, you should almost never need to call -synchronize yourself. The framework does it at appropriate times. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On 11 Sep 2014, at 12:14 pm, Charles Srstka cocoa...@charlessoft.com 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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 9:39 PM, Graham Cox graham@bigpond.com wrote:
On 11 Sep 2014, at 12:14 pm, Charles Srstka cocoa...@charlessoft.com 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.
#import Foundation/Foundation.h
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSUserDefaults *def = [NSUserDefaults standardUserDefaults];
NSDictionary *domain = [def
persistentDomainForName:@com.apple.TextEdit];
NSLog(@%@, domain);
}
return 0;
}
returns:
2014-09-10 22:17:12.713 test[94866:303] {
NSNavLastRootDirectory = ~/Desktop;
NSNavPanelExpandedSizeForOpenMode = {767, 545};
NSNavPanelExpandedSizeForSaveMode = {585, 448};
NSNavPanelExpandedStateForSaveMode = 1;
}
Program ended with exit code: 0
$ defaults read com.apple.TextEdit
{
ABDirectoryResultColumnTitle = Phone;
Encodings = (
10,
4,
30,
5,
12,
2147486212,
2147485224
);
IgnoreHTML = 1;
NSColorPanelMode = 1;
NSColorPanelVisibleSwatchRows = 1;
NSColorPickerSlidersDefaults = 1;
NSDocumentSuppressTempVersionStoreWarning = 0;
NSFontPanelAttributes = 1, 0;
NSFontPanelPreviewHeight = 0;
NSNavBrowserPreferedColumnContentWidth = 186;
NSNavLastRootDirectory = ~/Desktop;
NSNavLastUserSetHideExtensionButtonState = 0;
NSNavPanelExpandedSizeForOpenMode = {585, 401};
NSNavPanelExpandedSizeForSaveMode = {808, 458};
NSNavPanelExpandedStateForSaveMode = 1;
NSNavSidebarWidth = 120;
NSTableView Columns NSNavOutlineColumnSearchSettings = (
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0b646973 706c6179 4e616d65 86,
306,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 076d6f64 44617465 86,
88,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c637265 6174696f 6e446174 6586,
95,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0e6c6173 744f7065 6e656444
61746586,
95,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 136b696e 64576974 686f7574
506c6174 666f726d 86,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c73686f 72745665 7273696f 6e86,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 096c6162 656c4e61 6d6586,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c706879 73696361 6c53697a 6586,
60
);
NSTableView Columns NSNavOutlineColumnSettings.v1 = (
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0b646973 706c6179 4e616d65 86,
313,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 076d6f64 44617465 86,
88,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c637265 6174696f 6e446174 6586,
95,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0e6c6173 744f7065 6e656444
61746586,
95,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 136b696e 64576974 686f7574
506c6174 666f726d 86,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c73686f 72745665 7273696f 6e86,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 096c6162 656c4e61 6d6586,
62,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c706879 73696361 6c53697a 6586,
60
);
NSTableView Hidden Columns NSNavOutlineColumnSearchSettings = (
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 076d6f64 44617465 86,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 0c637265 6174696f 6e446174 6586,
040b7374 7265616d 74797065 6481e803 84014084 8484084e 53537472
696e6701 8484084e 534f626a 65637400 8584012b 136b696e 64576974 686f7574
506c6174 666f726d 86,
Re: NSOutlineView
On 10 Sep 2014, at 12:49 pm, Shane Stanley sstan...@myriad-com.com.au wrote: FWIW, and this is unrelated to your problem, I'm not sure you should delete the empty custom views, but rather drag the outline view and text view/scroll view into them. At least, I did what you outlined on a project some time ago. When I recently tried to update the .xib version to adopt auto-layout, the upgraded .xib would not build: ibtoold[7281:507] Exception raised while unarchiving document objects - *** -[NSBigMutableString replaceCharactersInRange:withString:]: nil argument /* com.apple.ibtool.errors */ /Path/to/SMSDocument.xib: error: The document SMSDocument.xib could not be opened. The operation couldn’t be completed. (com.apple.InterfaceBuilder error -1.) Recovery Suggestion: Check the console log for additional information. Timing is everything. It looks like the problem has just been fixed. -- Shane Stanley sstan...@myriad-com.com.au www.macosxautomation.com/applescript/apps/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 8:19 PM, Charles Srstka cocoa...@charlessoft.com wrote:
Where did you get the idea that NSUserDefaults doesn't work for sandboxed
apps? It certainly does.
#import Foundation/Foundation.h
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSUserDefaults *def = [NSUserDefaults standardUserDefaults];
NSDictionary *domain = [def
persistentDomainForName:@com.apple.TextEdit];
NSLog(@%@, domain);
}
return 0;
}
Ahh, you want to read defaults for some other app. Nope. Can't
do that. Says so right in the doc:
Sandbox Considerations
A sandboxed app cannot access or modify the preferences for any other app. (For
example, if you add another app's domain using theaddSuiteNamed: method, you do
not gain access to that app's preferences.)
Attempting to access or modify another app's preferences does not result in an
error, but when you do, OS X actually reads and writes files located within
your app's container, rather than the actual preference files for the other
application.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On 11 Sep 2014, at 1:19 pm, Charles Srstka cocoa...@charlessoft.com 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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 10:34 PM, Marco S Hyman m...@snafu.org wrote:
On Sep 10, 2014, at 8:19 PM, Charles Srstka cocoa...@charlessoft.com wrote:
Where did you get the idea that NSUserDefaults doesn't work for sandboxed
apps? It certainly does.
#import Foundation/Foundation.h
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSUserDefaults *def = [NSUserDefaults standardUserDefaults];
NSDictionary *domain = [def
persistentDomainForName:@com.apple.TextEdit];
NSLog(@%@, domain);
}
return 0;
}
Ahh, you want to read defaults for some other app. Nope. Can't
do that. Says so right in the doc:
Sandbox Considerations
A sandboxed app cannot access or modify the preferences for any other app.
(For example, if you add another app's domain using theaddSuiteNamed: method,
you do not gain access to that app's preferences.)
Attempting to access or modify another app's preferences does not result in
an error, but when you do, OS X actually reads and writes files located
within your app's container, rather than the actual preference files for the
other application.
But we're not talking about a sandboxed app trying to access the preferences of
another app here. We're talking about a *non*-sandboxed app accessing the
preferences of an app that is sandboxed.
And this is in fact possible to do — by launching the defaults program and
parsing its output. It just doesn't work with NSUserDefaults.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
On Sep 10, 2014, at 10:50 PM, Graham Cox graham@bigpond.com wrote: On 11 Sep 2014, at 1:19 pm, Charles Srstka cocoa...@charlessoft.com 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. Fair point; sorry about that. Was in a hurry. The basic point is that NSUserDefaults and /usr/bin/defaults behave very differently when trying to access the preferences of a sandboxed application, suggesting that the latter is not a simple wrapper around the former. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUserDefaults not sticking
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 cocoa...@charlessoft.com wrote: On Sep 10, 2014, at 10:50 PM, Graham Cox graham@bigpond.com wrote: On 11 Sep 2014, at 1:19 pm, Charles Srstka cocoa...@charlessoft.com 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. Fair point; sorry about that. Was in a hurry. The basic point is that NSUserDefaults and /usr/bin/defaults behave very differently when trying to access the preferences of a sandboxed application, suggesting that the latter is not a simple wrapper around the former. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/rickcorteza%40gmail.com This email sent to rickcort...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
