Re: Best way to put a fixed view in a UITableViewController scene?
Not if your UITableView has only one section and you use the section's header view in the way Marcelo suggests. Sections headers scroll up to the top and then remain there - visible - while additional cells scroll underneath it… Op Nov 27, 2013, om 4:30 AM heeft Rick Mann rm...@latencyzero.com het volgende geschreven: On Nov 26, 2013, at 19:18 , Marcelo Alves marcelo.al...@me.com wrote: Probably I’m missing something or I’m just naïve (or stupid), but what about the tableHeaderView (or tableFooterView) property? (not the same as section headers) It scrolls with the table content. -- Rick ___ 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/diederik%40tenhorses.com This email sent to diede...@tenhorses.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
iTunes Parental Preferences doesn't change on editing plist file on Mavericks OS X
Hi all, I have an application which monitors the iTunes plist file to control the Parental tab settings and I am running to an issue on Mavericks 10.9. On Mountain Lion 10.8.x and Lion OS X 10.7.x , I would monitor and update the plist file present at path ~/Library/Preferences/com.apple.iTunes.plist for some of the settings and the same would reflect on Parental control tab in iTunes Preference window User Interface. On OSX Mavericks 10.9, updating iTunes plist file does not reflect on the Parental control tab in iTunes Preference window User Interface. But If I change the settings by navigating to the Parental control tab in Preferences window, the same would reflect in the ~/Library/Preferences/com.apple.iTunes.plist. How can I monitor the iTunes plist file on Mavericks OS X so that if I update few fields at ~/Library/Preferences/com.apple.iTunes.plist file , the same would reflect on the UI as well. thanks, ~Arjun ___ 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: Best way to put a fixed view in a UITableViewController scene?
Multiple sections. -- Rick On Nov 27, 2013, at 1:03, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: Not if your UITableView has only one section and you use the section's header view in the way Marcelo suggests. Sections headers scroll up to the top and then remain there - visible - while additional cells scroll underneath it… Op Nov 27, 2013, om 4:30 AM heeft Rick Mann rm...@latencyzero.com het volgende geschreven: On Nov 26, 2013, at 19:18 , Marcelo Alves marcelo.al...@me.com wrote: Probably I’m missing something or I’m just naïve (or stupid), but what about the tableHeaderView (or tableFooterView) property? (not the same as section headers) It scrolls with the table content. -- Rick ___ 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/diederik%40tenhorses.com This email sent to diede...@tenhorses.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
Re: Best way to put a fixed view in a UITableViewController scene?
I do the following, the property *tableView in UITableViewController is not backed by a _tableView instance variable, so I synthesize that (@synthesize tableView = _tableView;) and then in viewDidLoad: if (!_tableView [self.view isKindOfClass:[UITableView class]]) self.tableView = (UITableView *)self.view; self.view = [[[UIView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame] autorelease]; self.tableView.frame = self.view.bounds; [self.view addSubview:self.tableView]; Then add whatever fixed view to self.view. Better maybe is adding a view to self.tableView and then offset the view while scrolling, as described in the WWDC 2011 Session 125... HTH On Nov 27, 2013, at 10:14 AM, Rick Mann rm...@latencyzero.com wrote: Multiple sections. -- Rick On Nov 27, 2013, at 1:03, Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: Not if your UITableView has only one section and you use the section's header view in the way Marcelo suggests. Sections headers scroll up to the top and then remain there - visible - while additional cells scroll underneath it… ___ 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: Best way to put a fixed view in a UITableViewController scene?
On Nov 27, 2013, at 01:37 , Ray Raphaël cocoa-...@deployedsmarts.com wrote: I do the following, the property *tableView in UITableViewController is not backed by a _tableView instance variable, so I synthesize that (@synthesize tableView = _tableView;) and then in viewDidLoad: if (!_tableView [self.view isKindOfClass:[UITableView class]]) self.tableView = (UITableView *)self.view; self.view = [[[UIView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame] autorelease]; self.tableView.frame = self.view.bounds; [self.view addSubview:self.tableView]; Then add whatever fixed view to self.view. Yeah, that's what I used to do. But in this era of autolayout, I can't make it work any more. Better maybe is adding a view to self.tableView and then offset the view while scrolling, as described in the WWDC 2011 Session 125... I've been experimenting with this approach. You can drop a tableHeaderView into the view in IB, and I've been offsetting that. Got it all pretty much working, but I'm not sure I can slide-hide/show with animation in that approach. Maybe a view that's NOT the tableViewHeader will work a bit better. iOS 7 complicates things by having the table view up under the top bar, which requires an extra scroll offset that doesn't get set until sometime well after viewDidLoad. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Responder chain query
On 21 Nov 2013, at 22:29, jonat...@mugginsoft.com wrote:
Looking at the action responder chain for a document based app (fig 1-10):
https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/EventArchitecture/EventArchitecture.html
This shows that the action responder chain extends past the window controller
up to the document controller.
Sometimes I want to respond to an action and then forward it on up the
responder chain like so:
[self.nextResponder tryToPerform:selector with:sender];
However, in this case the responder chain followed terminates at the window
controller (as does the event message window controller).
This means that higher level items like NSDocument etc are never queued as
part of the chain search.
Will I have to manually patch up the responder chain to include the higher
level items when doing this sort of thing?
I guess the answer is yes.
The following has been included in
https://github.com/mugginsoft/XSViewController
Jonathan
#import NSResponder+XSViewController.h
NSString *XSVChainTypeKey = @ChainType;
@implementation NSResponder (XSViewController)
#pragma mark -
#pragma mark Event responder chain
- (NSArray *)xsv_eventResponderChain
{
return [self xsv_eventResponderChainFromResponder:nil];
}
- (NSArray *)xsv_eventResponderChainFromSelf
{
return [self xsv_eventResponderChainFromResponder:self];
}
- (NSArray *)xsv_eventResponderChainFromResponder:(NSResponder *)responder
{
return [self xsv_responderChainFromResponder:responder
options:@{XSVChainTypeKey: @(XSVEventChainType)}];
}
#pragma mark -
#pragma mark Action responder chain
- (NSArray *)xsv_actionResponderChain
{
return [self xsv_actionResponderChainFromResponder:nil];
}
- (NSArray *)xsv_actionResponderChainFromSelf
{
return [self xsv_actionResponderChainFromResponder:self];
}
- (NSArray *)xsv_actionResponderChainFromResponder:(NSResponder *)responder
{
return [self xsv_responderChainFromResponder:responder
options:@{XSVChainTypeKey: @(XSVActionChainType)}];
}
#pragma mark -
#pragma mark Responder chain construction
- (NSArray *)xsv_responderChainFromResponder:(id)initialResponder
options:(NSDictionary *)options
{
// Chain should conform to description given here:
//
https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/1060i-CH3-SW2
NSMutableArray *chain = [NSMutableArray arrayWithCapacity:10];
// If no initial responder then use the window first responder
if (!initialResponder) {
if (![self respondsToSelector:@selector(window)]) {
return chain;
}
NSWindow *window = [(id)self window];
initialResponder = [window firstResponder];
}
// This is going nowhere...
if (!initialResponder) {
return chain;
}
// Probe the accessible chain. By default this will be the event chain
NSResponder *responder = initialResponder;
do {
[chain addObject:responder];
} while ((responder = responder.nextResponder));
responder = [chain lastObject];
// Append action responder chain items
if ([options[XSVChainTypeKey] integerValue] == XSVActionChainType) {
// A window is required
if (![self respondsToSelector:@selector(window)]) {
return chain;
}
NSWindow *window = [(id)responder window];
if (!window) {
return chain;
}
// Append the top level action responder chain
NSArray *actionTopLevelChain = [self
xsv_actionResponderChainAboveControllerForWindow:window];
[chain addObjectsFromArray:actionTopLevelChain];
}
return chain;
}
- (NSArray *)xsv_actionResponderChainAboveControllerForWindow:(NSWindow *)window
{
// Chain should conform to description given here:
//
https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/1060i-CH3-SW2
id windowDelegate = [window delegate];
NSWindowController *windowController = [window windowController];
NSDocument *document = [windowController document];
id appDelegate = [NSApp delegate];
NSMutableArray *chain = [NSMutableArray arrayWithCapacity:5];
if (!window) {
return chain;
}
if (windowDelegate) {
[chain addObject:windowDelegate];
}
if (document) {
[chain addObject:document];
}
[chain addObject:NSApp];
if (appDelegate) {
[chain addObject:appDelegate];
}
if (document) {
[chain addObject:[NSDocumentController sharedDocumentController]];
}
return chain;
}
@end
___
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:
Re: iTunes Parental Preferences doesn't change on editing plist file on Mavericks OS X
On Nov 27, 2013, at 1:10 AM, Arjun SM arjun...@gmail.com wrote: Hi all, I have an application which monitors the iTunes plist file to control the Parental tab settings and I am running to an issue on Mavericks 10.9. Editing plist files directly is not and has never been a supported way of changing or monitoring user defaults. Use CFPreferences or NSUserDefaults. --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: Can't remove autoresizing constraints?
On Nov 26, 2013, at 9:56 PM, Rick Mann rm...@latencyzero.com wrote: In my ongoing experimentation with getting a fixed view above my table view, I'm trying to do what I did successfully in the days before autolayout: separate the UITV's view and tableView properties. This works, but I can't figure out how to make it work with autolayout constraints. The problem is that IB/iOS create autoresizing mask constraints on the table view. By the time I can setTranlates to NO, it's too late, the constraints are made. So I try to remove them in -viewDidLoad, by calling: [self.tableView.superview removeConstraints: self.tableView.constraints] But this has no effect. I tried calling it on self.tableView, as well. The constraints are still there after removal. I'm doing this in an attempt to programmatically create constraints for both the table view and the banner view that live within a programmatically-created UIView. I need the constraints because the banner slides in from the top when shown, and slides out when hidden (this part is currently working with the view container solution I have). The timing of the addition and removal of autoresizing mask constraints is not documented. Experimentally, one can deduce that this is done during the updateConstraints phase on the Mac, but there might be other times at which this happens. Either way, the relationship between a UITVC's view and tableView is not yours to modify. In the time you've spent trying to hack this, you could have moved your cells to XIBs and implemented a static data source in your own banner-and-table-view presenting view controller. --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: NSTask and 10.9 [SOLVED]
NSString *scriptPath = [[NSBundle mainBundle] pathForResource:@DeleteHidden ofType:nil]; NSTask *task; task = [[NSTask alloc] init]; [task setLaunchPath:scriptPath]; The script DeleteHidden had line endings of cf,lf which caused an exception on 10.9 removing the cr via a hex editor resolved the 10.9 issue Thanks to all for the cycles. -koko On Nov 26, 2013, at 11:04 AM, Kyle Sluder k...@ksluder.com wrote: On Tue, Nov 26, 2013, at 09:37 AM, koko wrote: On Nov 26, 2013, at 10:26 AM, Kyle Sluder k...@ksluder.com wrote: Error 2 is ENOENT. The path you passed to -setLaunchPath: does not exist. Not possible as [task setLaunchPath:rootScriptPath]; where rootScriptPath is NSString *rootScriptPath = [[NSBundle mainBundle] pathForResource:@DeleteHiddenRoot ofType:nil]; Well, you never actually proved that this method returns something other than nil. But we'll assume you verified that even passing a hardcoded, known-good path to -setLaunchPath: causes the same symptoms. so do you know if Mavericks disallows NSTask access to the App Bundle? Perhaps. Starting in Mavericks, all the binaries within a signed bundle must be themselves signed before the bundle is signed, because their signatures form part of the bundle's designated requirement. I've only seen this discussed in the context of frameworks, but I would not be surprised if it also applied to scripts or other tasks launched via posix_spawn. For more details, see Craig Hockenberry's blog post: http://furbo.org/2013/10/17/code-signing-and-mavericks/ --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: NSTask and 10.9 [SOLVED]
On Nov 27, 2013, at 7:59 AM, koko k...@highrolls.net wrote: NSString *scriptPath = [[NSBundle mainBundle] pathForResource:@DeleteHidden ofType:nil]; NSTask *task; task = [[NSTask alloc] init]; [task setLaunchPath:scriptPath]; The script DeleteHidden had line endings of cf,lf which caused an exception on 10.9 removing the cr via a hex editor resolved the 10.9 issue Ha! Indeed, I can reproduce this on my machine using Terminal.app: % cat foo #!/bin/sh echo Hello, world % ./foo zsh: ./foo: bad interpreter: /bin/sh^M: no such file or directory So technically posix_spawn wasn't lying—when it parsed your shebang line, it saw `#!/bin/shCR`, and couldn’t find a shell named `shCR` to launch it. --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: iOS screen physical size (or px density)
Roland is 100% correct here. You can't reliably predict what the device identifiers will be and filing bugs is the best way to register your needs. The fact that you could guess device identifiers has more to do with the fact that there have only been 2 released generations of the iPad mini and less to do with any patterns you may think you have seen. -- David Duncan @ My iPhone On Nov 26, 2013, at 8:45 AM, Roland King r...@rols.org wrote: Rubbish. And any reading of the Apple Dev Forums will find many messages from Apple engineers telling you NOT to do that, NOT to guess, NOT to make assumptions based on what you think identifiers are or are going to be and to stick to the API points there are. They also ask people file bug reports with use cases about why one might need the physical device screen size, which I have done. On 26 Nov, 2013, at 9:41 pm, Maxthon Chan xcvi...@me.com wrote: There is no reason for Apple to provide such an clearly redundant API point. Developers can somehow predict the new devices’ identifiers and the sizes are largely correctly guessed so a quick table look-up will work very well. On Nov 26, 2013, at 21:38, Igor Elland igor.ell...@me.com wrote: If there isn't a proper API point for it, then I'm not doing it. I’m quite sure there’s no public API to get the physical screen size or otherwise differentiate between the regular size screen iPad and the mini. ___ 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/david.duncan%40apple.com This email sent to david.dun...@apple.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
Preferences caching?
Apparently, OS X 10.9 caches preference files. This is the first I’ve heard about it (on a discussion on Ars Technica of all places). Is there any documentation about this, like an explanation as to what purpose this has? I noticed recently that after deleting my app’s prefs file, I was still getting an old value coming up, despite changing it in the defaults plist I use with -registerDefaults: on startup. I was unable to track down where this old value was coming from, and gave up, baffled, since it was only a curiosity in that case. Now I know why. However, if something really seriously does need changing, then this caching means I’m not going to be able to test it without writing code to forcibly update the user defaults, rather than just passively changing the value in my plist and trashing the prefs file. That’s a pretty major problem. Also, very rarely, but once in a while, deleting the prefs file can be a useful solution to get a user around a problem due to a bug, etc. If that’s no longer an option, we are going to be stuck with bugs that are going to be very hard to triage in the field. That’s a pretty major problem. Please someone tell me there’s a way to opt out of this travesty? At this rate I’ll be writing a full-on replacement for NSUserDefaults just to get back the behaviour it’s always had in the past. What good is this change anyway? —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: Preferences caching?
The preferences file has always been considered an implementation detail. I'm not up on all the reasons for the change, but you should be able to use the 'defaults' command line tool to do the same thing that trashing prefs used to do. Something like 'defaults delete com.yourcompany.yourapp' should do the trick. -- David Duncan @ My iPhone On Nov 27, 2013, at 2:02 PM, Graham Cox graham@bigpond.com wrote: Apparently, OS X 10.9 caches preference files. This is the first I’ve heard about it (on a discussion on Ars Technica of all places). Is there any documentation about this, like an explanation as to what purpose this has? I noticed recently that after deleting my app’s prefs file, I was still getting an old value coming up, despite changing it in the defaults plist I use with -registerDefaults: on startup. I was unable to track down where this old value was coming from, and gave up, baffled, since it was only a curiosity in that case. Now I know why. However, if something really seriously does need changing, then this caching means I’m not going to be able to test it without writing code to forcibly update the user defaults, rather than just passively changing the value in my plist and trashing the prefs file. That’s a pretty major problem. Also, very rarely, but once in a while, deleting the prefs file can be a useful solution to get a user around a problem due to a bug, etc. If that’s no longer an option, we are going to be stuck with bugs that are going to be very hard to triage in the field. That’s a pretty major problem. Please someone tell me there’s a way to opt out of this travesty? At this rate I’ll be writing a full-on replacement for NSUserDefaults just to get back the behaviour it’s always had in the past. What good is this change anyway? ―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/david.duncan%40apple.com This email sent to david.dun...@apple.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
Re: Preferences caching?
On 27 Nov 2013, at 8:18 pm, David Duncan david.dun...@apple.com wrote: The preferences file has always been considered an implementation detail. I'm not up on all the reasons for the change, but you should be able to use the 'defaults' command line tool to do the same thing that trashing prefs used to do. Something like 'defaults delete com.yourcompany.yourapp' should do the trick. Great. For me. For users in the field, the command line is the badlands, and we can’t expect many users to be comfortable doing that. Trashing a file is at least something they can understand, even if sometimes even that can be an ordeal getting them to the ~/Library/Preferences folder, now it’s hidden by default. Really, Apple are supposed to be the champions of the average user aren’t they? Have they talked to any recently? Honestly, it would serve everyone well if every developer served a month in a call centre. I guess we’re going to have to put a button somewhere that’s going to do this for them. Sigh. ―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: Preferences caching?
While I agree that sometimes deleting a prefs file is useful, its not really a good idea - never was. Its still asking the user to muck around app internals. The fact that mavericks now caches really shouldn’t matter. I think if deleting your prefs file is a common case, or even somewhat common, or used at all - then yes, its far more appropriate for you to have a button. Asking the user to trawl through internal implementation details of the system was never a good idea. So in this case, I think Apple is doing the right thing. On Nov 27, 2013, at 12:27 PM, Graham Cox graham@bigpond.com wrote: On 27 Nov 2013, at 8:18 pm, David Duncan david.dun...@apple.com wrote: The preferences file has always been considered an implementation detail. I'm not up on all the reasons for the change, but you should be able to use the 'defaults' command line tool to do the same thing that trashing prefs used to do. Something like 'defaults delete com.yourcompany.yourapp' should do the trick. Great. For me. For users in the field, the command line is the badlands, and we can’t expect many users to be comfortable doing that. Trashing a file is at least something they can understand, even if sometimes even that can be an ordeal getting them to the ~/Library/Preferences folder, now it’s hidden by default. Really, Apple are supposed to be the champions of the average user aren’t they? Have they talked to any recently? Honestly, it would serve everyone well if every developer served a month in a call centre. I guess we’re going to have to put a button somewhere that’s going to do this for them. Sigh. ―Graham Alex Kac - President and Founder Web Information Solutions, Inc. If at first you don't succeed, skydiving is not for you. -- Francis Roberts ___ 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: Preferences caching?
On Wed, Nov 27, 2013, at 11:27 AM, Graham Cox wrote: Really, Apple are supposed to be the champions of the average user aren’t they? Have they talked to any recently? Honestly, it would serve everyone well if every developer served a month in a call centre. If you think deleting a plist in ~/Library/Preferences is a solution to any problem to which run `defaults delete` is not, I think you're concerned about a very narrow definition of average user. --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: Preferences caching?
On Nov 27, 2013, at 2:18 PM, David Duncan david.dun...@apple.com wrote:
The preferences file has always been considered an implementation detail. I'm
not up on all the reasons for the change, but you should be able to use the
'defaults' command line tool to do the same thing that trashing prefs used to
do. Something like 'defaults delete com.yourcompany.yourapp' should do the
trick.
On Nov 27, 2013, at 2:02 PM, Graham Cox graham@bigpond.com wrote:
Apparently, OS X 10.9 caches preference files. This is the first I’ve heard
about it (on a discussion on Ars Technica of all places). Is there any
documentation about this, like an explanation as to what purpose this has?
Please someone tell me there’s a way to opt out of this travesty? At this
rate I’ll be writing a full-on replacement for NSUserDefaults just to get
back the behaviour it’s always had in the past. What good is this change
anyway?
On one of the forums or mailing lists a little while ago, an apparently
knowledgeable Apple engineer reported that it has NEVER been proper to manually
delete preferences files but that it did happen to work most of the time before
Mavericks. Now in Mavericks it doesn't work, as you've discovered. Here is an
AppleScript (written using new Mavericks techniques, so don't run it on older
systems) that I wrote to do it right using the defaults tool. I put this script
in my Script Menu and it is now even easier than before to delete preferences
files. (But note the caution at the end about Sandboxed applications, for which
I don't have an answer.)
(*
This script removes the preferences cache and file for non-sandboxed
applications.
Starting with Mavericks, application preferences may be cached in such a way
that deleting a preferences file is not immediately effective. This script for
OS X 10.9 Mavericks immediately removes any cached preferences for the chosen
application and then deletes the preferences file or files. The script reports
whether cached preferences were found and deleted before giving you the option
to delete the preferences file or files. The application must not be running.
Authentication with an administrator password is required.
*)
use scripting additions
choose application with title Delete Preferences for Application with prompt
Choose an application: as alias
set info to (info for result)
set displayName to displayed name of info
if application displayName is running then
display alert \ displayName \ is running. message
Preferences should not be deleted while the application is running. Quit
application \ displayName \ and run this script again. buttons {OK}
default button OK
else
set bundleID to bundle identifier of info
try
do shell script defaults delete -app quoted form of
displayName with administrator privileges
display alert Cached preferences of \ displayName \
were deleted. message You can now delete the preferences file. buttons
{Cancel, Delete} default button Delete cancel button Cancel
on error errMsg number errNum
if errNum is 1 then
display alert \ displayName \ has no cached
preferences. message You can delete the preferences file. buttons {Cancel,
Delete} default button Delete cancel button Cancel
end if
end try
do shell script rm -rf ~/Library/Preferences/ bundleID * -- for
non-sandboxed apps
-- The following statement removes the preferences file from a
sandboxed application's container, but then the application's preferences
system gets confused and the application will not create a new preferences
file. Therefore, don't do it.
--do shell script rm -rf ~/Library/Containers/ bundleID
*/Data/Library/Preferences/ bundleID * -- for sandboxed apps
end if
--
Bill Cheeseman - b...@cheeseman.name
___
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: Preferences caching?
On 27 Nov 2013, at 8:42 pm, Kyle Sluder k...@ksluder.com wrote: If you think deleting a plist in ~/Library/Preferences is a solution to any problem to which run `defaults delete` is not, I think you're concerned about a very narrow definition of average user. Well, I’m more concerned about the “below average” user then. Like it or not we can’t choose our users, and many fall into the category where using a GUI to locate and drag a file to the trash is infinitely preferable to opening terminal and typing commands that have to be letter-perfect. That may be second-nature to us, and so we forget just how afraid of this some users can be. Thankfully, this is extremely rare, and in many cases I’m afraid “trashing the prefs” is akin to voodoo as a solution for a problem, but it’s often put out there (not by us if we really don’t think it will help I hasten to add). Adding a button it is, I agree it’s better all round. So let me turn this into a dev question then. Do I need to actually run a command line task to do this, or is there some API I can use? For example, what does + resetStandardUserDefaults achieve? Anything useful in this case? —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: Preferences caching?
On Wed, Nov 27, 2013, at 11:53 AM, Graham Cox wrote: So let me turn this into a dev question then. Do I need to actually run a command line task to do this, or is there some API I can use? For example, what does + resetStandardUserDefaults achieve? Anything useful in this case? Not what you want. Use -[NSUserDefaults removePersistentDomainForName:] with your app's bundle ID. --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: Preferences caching?
On 27 Nov 2013, at 9:00 pm, Kyle Sluder k...@ksluder.com wrote: On Wed, Nov 27, 2013, at 11:53 AM, Graham Cox wrote: So let me turn this into a dev question then. Do I need to actually run a command line task to do this, or is there some API I can use? For example, what does + resetStandardUserDefaults achieve? Anything useful in this case? Not what you want. Use -[NSUserDefaults removePersistentDomainForName:] with your app's bundle ID. Thanks, that’s a good one to know. The documentation doesn’t even begin to suggest this method would be appropriate. Am I right in thinking I’ll have to also reload my defaults plist and use -registerDefaults: after this? —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: Preferences caching?
On 27 Nov 2013, at 9:12 pm, Graham Cox graham@bigpond.com wrote: Not what you want. Use -[NSUserDefaults removePersistentDomainForName:] with your app's bundle ID. Thanks, that’s a good one to know. The documentation doesn’t even begin to suggest this method would be appropriate. Am I right in thinking I’ll have to also reload my defaults plist and use -registerDefaults: after this? Well, this seems to work just fine, so I’m fairly happy with that solution - thanks :) The only thing I can see being an issue with this approach is that if something in the prefs prevents the app launching successfully. We’ve had that happen in the past, luckily only once in a blue moon (and the root cause of that particular bug has long been dealt with). I guess if/when it crops up again we’ll just have to navigate the unfortunate user through the command line. Thankfully, that won’t have to be me, we have far more patient people to do that. —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: Preferences caching?
On Nov 27, 2013, at 11:53 AM, Graham Cox wrote: On 27 Nov 2013, at 8:42 pm, Kyle Sluder k...@ksluder.com wrote: If you think deleting a plist in ~/Library/Preferences is a solution to any problem to which run `defaults delete` is not, I think you're concerned about a very narrow definition of average user. Well, I’m more concerned about the “below average” user then. Like it or not we can’t choose our users, and many fall into the category where using a GUI to locate and drag a file to the trash is infinitely preferable to opening terminal and typing commands that have to be letter-perfect. That may be second-nature to us, and so we forget just how afraid of this some users can be. If they're that naive a user, they can't navigate the GUI to get to the prefs - ~/Library has been hidden by default for years now. Thankfully, this is extremely rare, and in many cases I’m afraid “trashing the prefs” is akin to voodoo as a solution for a problem, but it’s often put out there (not by us if we really don’t think it will help I hasten to add). Adding a button it is, I agree it’s better all round. So let me turn this into a dev question then. Do I need to actually run a command line task to do this, or is there some API I can use? For example, what does + resetStandardUserDefaults achieve? Anything useful in this case? —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: Preferences caching?
On 27 Nov 2013, at 10:20 pm, Lee Ann Rucker lruc...@vmware.com wrote: If they're that naive a user, they can't navigate the GUI to get to the prefs - ~/Library has been hidden by default for years now. Yes, that was a bit of a headache when the folder was hidden by default, and we had to add additional steps to option-click in the ‘Go’ menu. But that’s still much easier than command line typing. When I said “afraid” I could equally have said “incompetent”. But if you think using a command line is as easy as navigating a GUI - even a hidden one - I suggest you take a few calls from actual users who need help of this nature. You’ll soon understand the difference the first time they don’t type EXACTLY what you tell them, which is almost every. single. time. Us developers are FAR from typical users. After all, the Mac pioneered the GUI for exactly this reason. —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: Preferences caching?
On Nov 27, 2013, at 11:53 , Graham Cox graham@bigpond.com wrote: in many cases I’m afraid “trashing the prefs” is akin to voodoo as a solution for a problem, but it’s often put out there (not by us if we really don’t think it will help I hasten to add). Adding a button it is, I agree it’s better all round FWIW I would say: right diagnosis, wrong solution. What on earth is going on with your app(s) that requires preferences to be deleted? If, after all these years of your being a very accomplished developer, your apps aren’t robust enough to deal with unusable or inconsistent values in prefs — or, more to the point, put the prefs into such a state to begin with — then I humbly suggest you treat that as a major bug, and fix it. It’s certainly true that there have been been scenarios in the past where some condition external to your app code could cause a corruption — e.g. a crash — but I think you can look at the new Mavericks caching as Apple’s side of a commitment to avoiding that. Now, a crash or sudden termination in your app can’t corrupt the prefs, since the user defaults daemon doesn’t crash too. Is there a genuine reason why you can’t robustify your app’s dealings with preferences, and avoid the entire problem of deleting them? ___ 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: Preferences caching?
On 27 Nov 2013, at 10:43 pm, Quincey Morris quinceymor...@rivergatesoftware.com wrote: FWIW I would say: right diagnosis, wrong solution. What on earth is going on with your app(s) that requires preferences to be deleted? If, after all these years of your being a very accomplished developer, your apps aren’t robust enough to deal with unusable or inconsistent values in prefs — or, more to the point, put the prefs into such a state to begin with — then I humbly suggest you treat that as a major bug, and fix it. Absolutely correct, and we have very diligently done this whenever it has arisen. Is there a genuine reason why you can’t robustify your app’s dealings with preferences, and avoid the entire problem of deleting them? The point is, if we could predict all bugs, they wouldn’t be there. We’ve had rare cases in the past where a prefs file has caused an issue. Obviously we did not anticipate it, otherwise it would have been discovered in testing and fixed before it got out into the wild, but we know that nobody’s perfect, and not every case can be tested for. Therefore we approach things with the cautious knowledge that no matter how hard we try, there will always be bugs. Since we’ve experienced bugs caused by prefs in the past, it’s not impossible that there could be other bugs triggered by bad prefs in the future. We need to have something up our sleeves if that occurs (like having a fire department). Deleting the prefs file has been an acceptable solution in the past because we know it’s super-rare that it’s needed. We always follow up where we can and find out the real cause and fix it, so these problems are virtually non-existent now, but we can’t be 100% certain. One of the things that our app allows is that the user can build vector “styles” in pretty much any way that they can imagine. It means that there are literally billions of combinations. Each tool in the app might be working with any style at any time, and as a courtesy to the user we save the tool’s style data in the prefs so they can pick up where they left off. When we’ve had a problem with prefs, it’s usually turned out to be a user-built style that contains crazy values. We’ve worked extremely hard to make sure “crazy” values are impossible, but you can only make an app foolproof, not damn fool proof, and occasionally something totally unanticipated slips through. These days such occurrences are very rare, but as I say, we can’t guarantee there is certainty, given the sheer number of combinations making it impossible to test them exhaustively. But the other reason it’s nice to have a quick way to restore the original defaults is in development and testing itself, so that a “clean install” can be tested as well as an update where an existing set of prefs needs to be considered. In this case the command line is fine, but clicking a button even better. Even developers and testers like an easy life. —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: Preferences caching?
On Nov 27, 2013, at 14:12 , Graham Cox graham@bigpond.com wrote: We’ve had rare cases in the past where a prefs file has caused an issue. Obviously we did not anticipate it, otherwise it would have been discovered in testing and fixed before it got out into the wild, but we know that nobody’s perfect, and not every case can be tested for. Therefore we approach things with the cautious knowledge that no matter how hard we try, there will always be bugs. Since we’ve experienced bugs caused by prefs in the past, it’s not impossible that there could be other bugs triggered by bad prefs in the future. We need to have something up our sleeves if that occurs (like having a fire department). Deleting the prefs file has been an acceptable solution in the past because we know it’s super-rare that it’s needed. We always follow up where we can and find out the real cause and fix it, so these problems are virtually non-existent now, but we can’t be 100% certain. One of the things that our app allows is that the user can build vector “styles” in pretty much any way that they can imagine. It means that there are literally billions of combinations. Each tool in the app might be working with any style at any time, and as a courtesy to the user we save the tool’s style data in the prefs so they can pick up where they left off. When we’ve had a problem with prefs, it’s usually turned out to be a user-built style that contains crazy values. We’ve worked extremely hard to make sure “crazy” values are impossible, but you can only make an app foolproof, not damn fool proof, and occasionally something totally unanticipated slips through. These days such occurrences are very rare, but as I say, we can’t guarantee there is certainty, given the sheer number of combinations making it impossible to test them exhaustively. But the other reason it’s nice to have a quick way to restore the original defaults is in development and testing itself, so that a “clean install” can be tested as well as an update where an existing set of prefs needs to be considered. In this case the command line is fine, but clicking a button even better. Even developers and testers like an easy life. You make reasonable points, but the fact that your explanation does a lot of tap dancing to get there might suggest an overreaction (in the need for a button, I mean, not in the explanation). And, a button is an awfully visible UI element for what should be so rare a problem. In these circumstances, I’d suggest you consider an “alternate” menu item, rather than a button. For example, an alternate to your app — Preferences…, but with the Option key held down. That way, it’s hidden normally, but the reset procedure is easy to explain, even to damn fools. Plus, it’s really, really easy to set this up IB these days. ___ 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: Can't remove autoresizing constraints?
On Nov 27, 2013, at 07:36 , Kyle Sluder k...@ksluder.com wrote: Either way, the relationship between a UITVC's view and tableView is not yours to modify. In the time you've spent trying to hack this, you could have moved your cells to XIBs and implemented a static data source in your own banner-and-table-view presenting view controller. I could have, perhaps, but then I'd just have to do that again next time. It completely discards all the benefits of the new paradigm, and was worth pursuing. That judgement, however, does not explain why I can't remove existing constraints. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Preferences caching?
What on earth is going on with your app(s) that requires preferences to be deleted? If, after all these years of your being a very accomplished developer, your apps aren’t robust enough to deal with unusable or inconsistent values in prefs — or, more to the point, put the prefs into such a state to begin with — then I humbly suggest you treat that as a major bug, and fix it. Ha! Tell that to Apple. There is more than one Apple support note where one of the troubleshooting steps is to trash your preferences. An example off the top of my head: http://support.apple.com/kb/TS3893?viewlocale=en_USlocale=en_US In this case it is such a common thing to do that there is a third party application to save, trash, and restore those specific preferences for you. ___ 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: Preferences caching?
On Nov 27, 2013, at 15:15 , Marco S Hyman m...@snafu.org wrote: Tell that to Apple. Dear Apple, you have a major bug in Final Cut Pro that causes it to go kerflooey when its preferences get into a state it doesn’t expect. Please fix it. Marco, don’t you agree that (now, 10+ years into the OS X era) trashing prefs is the same kind of voodoo as fixing file permissions? That’s not to say there aren’t circumstances where those are the right things to do, but I think we’re beyond the point where they should be a regular part of any magical support incantation. I note that even Graham described his need as “rare cases”. ___ 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: Preferences caching?
On 28 Nov 2013, at 7:53 AM, Graham Cox graham@bigpond.com wrote: I guess if/when it crops up again we’ll just have to navigate the unfortunate user through the command line. Or write a one-line AppleScript script: do shell script defaults delete ... Save it as a code-signed app, send it to them, and tell them to double-click. A lot easier than navigating Library folders for the average user. -- 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
Autosizing an iPhone
A universal app. On iPad: UIView:; frame = (321 0; 447 1024); with three subviews (top to bottom); UINavigationBar:; frame = (0 0; 447 44); opaque = NO; autoresize = W+BM; UIWebView: frame = (0 44; 447 936); clipsToBounds = YES; autoresize = W+H; UIToolbar:; frame = (0 980; 447 44); opaque = NO; autoresize = W+TM; This is all as it should be. On iPhone it is more complicated: UIWindow:; frame = (0 0; 320 480); opaque = NO; autoresize = W+H; UIView:; frame = (0 0; 320 480); autoresize = W+H; UILayoutContainerView:; frame = (0 0; 320 480); autoresize = W+H; UILayoutContainerView: UINavigationTransitionView:; frame = (0 0; 320 480); clipsToBounds = YES; autoresize = W+H; UINavigationBar:; frame = (0 20; 320 44); opaque = NO; autoresize = W; , UIToolbar:; frame = (0 436; 320 44); opaque = NO; UINavigationTransitionView: UIViewControllerWrapperView:; frame = (0 0; 320 480); autoresize = W+H; UIViewControllerWrapperView: UIView:; frame = (-96 0; 320 480); _UIParallaxDimmingView: 0x12e2dbb0; frame = (0 0; 320 480); opaque = NO; UIView: 0x125dfe30; frame = (0 0; 320 480); UIView: 0x125dfe30; _UIParallaxDimmingView: 0x12e2d7a0; frame = (0 0; 320 480); opaque = NO; _UIParallaxDimmingView: UIImageView:; frame = (-9 0; 9 480); alpha = 0; opaque = NO; UIView:; frame = (0 0; 320 480); autoresize = RM+BM; UIView: UIWebView: 0x125e1d60; frame = (0 240; 320 0); clipsToBounds = YES; autoresize = W+H; Note: this WebView has a rather narrow height - making it very hard to see. What I see is: top: Navigation bar (ok) middle: just background (+ maybe a very small WebView ?) botton: Toolbar (ok) The WebView has constraints: Top Space to Navigation Bar = Auto (=0) Bottom Space to Toolbar = Auto (=0) Works fine on iPad where the WebView lives in a view with its two siblings; but on iPhone the WebView is an only child - no idea how the autosizing is supposed to work in this case. The iPhone shows the nib which contains Navigation Bar, WebView, ToolBar via: [ self.navigationController pushViewController: self.detailViewController animated: YES ]; navigationController is an UINavigationController detailViewController is a subclass of UIViewController Gerriet. ___ 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
