Storyboard UISplitViewController difficulty
Oops, forgot my question: How can I work around this problem? I need to install the popover button item, but I don't have it. I tried setting the delegate in IB, given that it's all visible in the storyboard, but it won't let me set the split view delegate across scenes. --- It seems that when using storyboards, UISplitViewController gets loaded and calls its delegate before the related view controllers even get loaded. I'm trying to set my right-side view controller as the delegate in its -viewDidLoad, but at this point it's too late, and the willHide delegate method is not called, and consequently the popover button is not installed. Really, the related view controllers' -viewDidLoad methods should be called before the split view controller's -willAppear (which is what triggers the call to the delegate method). Barring that, the split controller should call the willHide delegate method should only be called after the related view controllers have loaded. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Storyboard UISplitViewController difficulty
It seems that when using storyboards, UISplitViewController gets loaded and calls its delegate before the related view controllers even get loaded. I'm trying to set my right-side view controller as the delegate in its -viewDidLoad, but at this point it's too late, and the willHide delegate method is not called, and consequently the popover button is not installed. Really, the related view controllers' -viewDidLoad methods should be called before the split view controller's -willAppear (which is what triggers the call to the delegate method). Barring that, the split controller should call the willHide delegate method should only be called after the related view controllers have loaded. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Invoking protocol method on the main thread
On Nov 15, 2012, at 3:17 PM, Graham Cox wrote:
> How can I invoke a method of my protocol on the main thread?
Aside from Greg's simple suggestion, GCD is your friend. Then you're not
beholden to a single method call, or the interface requirements of the
performSelector methods.
dispatch_async(dispatch_get_main_queue(), ^{ anything; });
--
Seth Willits
___
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: Safe to install NSTrackingArea on a subview?
On Nov 15, 2012, at 17:55 , Kyle Sluder wrote:
> In particular, I'm concerned about -updateTrackingAreas. This message is
> sent to the view, not the tracking area's owner, but the view itself
> doesn't know about the tracking area. If the owner doesn't happen to be
> a view in the same hierarchy, it's not guaranteed to have
> -updateTrackingAreas called.
A comment squirreled away in the Event Handling guide:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html
might be relevant to your question. It says:
> "Note that the Application Kit sends updateTrackingAreas to every view
> whether it has a tracking area or not."
If that's so, there'd only be a difficulty if the owner isn't a view.
> Additionally, if the owner is a view, it doesn't receive any information
> via -mouse{Entered,Exited,Moved}: or -cursorUpdate: to differentiate its
> own mouse actions from those of the tracking area. (Yes, there's the
> userInfo property of NSTrackingArea that gets attached to the NSEvent
> argument passed to the tracking area owner—*unless* it's a mouse-moved
> event in which case it doesn't!).
If the view to which the tracking area is attached is a subview of the owner,
then I'd guess this isn't much of a problem**. In more complicated cases, the
owner is likely keeping track of the inside/outside state anyway, which means
it can tell the mouse-moved events apart if it needs to (and it can also
distinguish them with a straightforward "point in rect" test, can't it?**).
** Assuming the code is careful to convert to the right coordinate system.
___
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
Safe to install NSTrackingArea on a subview?
I just put together a quick sample project to prove to myself that one
can safely install a tracking area on a subview:
http://www.optshiftk.com/wp-content/uploads/2012/11/SubviewTrackingArea.zip
But I'm still not convinced that this is guaranteed to work. It doesn't
help that using Google I cannot find any instance of -addTrackingView:
being sent to a receiver other than self except in extremely shady cases
like hacking with NSThemeFrame.
In particular, I'm concerned about -updateTrackingAreas. This message is
sent to the view, not the tracking area's owner, but the view itself
doesn't know about the tracking area. If the owner doesn't happen to be
a view in the same hierarchy, it's not guaranteed to have
-updateTrackingAreas called.
Additionally, if the owner is a view, it doesn't receive any information
via -mouse{Entered,Exited,Moved}: or -cursorUpdate: to differentiate its
own mouse actions from those of the tracking area. (Yes, there's the
userInfo property of NSTrackingArea that gets attached to the NSEvent
argument passed to the tracking area owner—*unless* it's a mouse-moved
event in which case it doesn't!).
So is this actually supported? My limited testing indicates it works,
but I would like to know for certain.
--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: Getting notified of any change to a specific NSManagedObject?
On Nov 15, 2012, at 17:04 , Kyle Sluder wrote: > Override -didChangeValueForKey:? Apparently we are strongly discouraged from overriding those methods. :-) -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Getting notified of any change to a specific NSManagedObject?
On Nov 15, 2012, at 4:19 PM, Rick Mann wrote: > I know I can use KVO on a specific property of my NSManagedObject, but is > there a way to get notified if any property changes? I'm trying to avoid a > bunch of -addObserver:… and -removeObserer:… calls. > > I know I can listen for the context did save notification, but I'd rather > catch the changes immediately. Override -didChangeValueForKey:? --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: Getting notified of any change to a specific NSManagedObject?
On Nov 15, 2012, at 16:32 , Sean McBride wrote: > On Thu, 15 Nov 2012 16:19:53 -0800, Rick Mann said: > >> I know I can use KVO on a specific property of my NSManagedObject, but >> is there a way to get notified if any property changes? I'm trying to >> avoid a bunch of -addObserver:… and -removeObserer:… calls. > > You could create a dependent key, that depends on all your keys of interest, > then you just observe that one key. Like: Hmm, that's not a bad idea. Thanks! -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Getting notified of any change to a specific NSManagedObject?
On Thu, 15 Nov 2012 16:19:53 -0800, Rick Mann said:
>I know I can use KVO on a specific property of my NSManagedObject, but
>is there a way to get notified if any property changes? I'm trying to
>avoid a bunch of -addObserver:… and -removeObserer:… calls.
You could create a dependent key, that depends on all your keys of interest,
then you just observe that one key. Like:
+ (NSSet*)keyPathsForValuesAffectingValueForKey:(NSString*)inKey
{
NSSet* set = [super keyPathsForValuesAffectingValueForKey:inKey];
if ([inKey isEqualToString:@"everything"])
{
set = [set setByAddingObjectsFromSet:[NSSet setWithObjects:
@"firstName",
@"lastName",
@"age",
nil]];
}
return set;
}
Cheers,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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: Getting notified of any change to a specific NSManagedObject?
On Nov 15, 2012, at 16:19 , Rick Mann wrote: > I know I can use KVO on a specific property of my NSManagedObject, but is > there a way to get notified if any property changes? I'm trying to avoid a > bunch of -addObserver:… and -removeObserer:… calls. > > I know I can listen for the context did save notification, but I'd rather > catch the changes immediately. Ah, I can use NSManagedObjectContextObjectsDidChangeNotification, although that will give me all objects, when really I just want one. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Getting notified of any change to a specific NSManagedObject?
I know I can use KVO on a specific property of my NSManagedObject, but is there a way to get notified if any property changes? I'm trying to avoid a bunch of -addObserver:… and -removeObserer:… calls. I know I can listen for the context did save notification, but I'd rather catch the changes immediately. -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Static table view cells inconsistently update
I have a view controller in a storyboard with a static content grouped-style table. One of the sections has seven table view cells, all built in "right detail" type. I have IBOutlet UILabel* references to each of the right-hand detail labels, and those get updated in my view controller. However, when the view first appears, most of the detail labels are not visible (a couple are). As the displayed model object is changed, the two visible ones change as you would expect. But the invisibles never appear. If I tap on a cell with an invisible detail, it suddenly appears, and then functions normally. They all look fine in IB, all contain the same text "Detail". Any idea why some are invisible until the cell is selected? TIA, -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Invoking protocol method on the main thread
On 16/11/2012, at 10:23 AM, Greg Parker wrote: > The simple solution is to declare your property as NSObject* . > D'oh!! Thanks - that was simple. I thought I'd tried it, but my syntax was wrong: I had NSObject* --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: Invoking protocol method on the main thread
On Nov 15, 2012, at 3:17 PM, Graham Cox wrote: > I have a formal protocol for a notification callback I want to make. The > protocol inherits the NSObject protocol. > > The caller accepts only objects conforming to this protocol as its delegate. > When it's time to invoke the callback, I'd like to do so on the main thread, > since the caller can be running on another thread. But > -performSelectorOnMainThread:withObject:waitUntilDone: is not part of the > NSObject protocol, it's part of the methods of NSObject, so my code won't > compile because id objects don't include this method. > > How can I invoke a method of my protocol on the main thread? > > > @protocol MyProtocol > > - (void) foo:(Caller*) caller; > > ... > > > @interface Caller : NSObject > > @property (assign) id delegate; > > ... > > > > [self.delegate performSelectorOnMainThread:@selector(foo) withObject:self > waitUntilDone:NO]; // method not found The simple solution is to declare your property as NSObject* . -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
Invoking protocol method on the main thread
Hi all, I have a formal protocol for a notification callback I want to make. The protocol inherits the NSObject protocol. The caller accepts only objects conforming to this protocol as its delegate. When it's time to invoke the callback, I'd like to do so on the main thread, since the caller can be running on another thread. But -performSelectorOnMainThread:withObject:waitUntilDone: is not part of the NSObject protocol, it's part of the methods of NSObject, so my code won't compile because id objects don't include this method. How can I invoke a method of my protocol on the main thread? @protocol MyProtocol - (void)foo:(Caller*) caller; ... @interface Caller : NSObject @property (assign) id delegate; ... [self.delegate performSelectorOnMainThread:@selector(foo) withObject:self waitUntilDone:NO];// method not found --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
Location permission alert self-dismisses
I've got this behavior in both the sim and on device that, after a fresh install of my app, upon launch it presents the alert requesting permission for location services, which then immediately disappears. I tried googling for a solution, but can't come up with suitable search terms that don't just give me a lot of reviews of iOS 6. Any idea what's going on? Thanks, -- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: What makes a URL Handler be persistent?
On Nov 14, 2012, at 4:48 PM, Jerry Krinock wrote: > Now, my app itself does not handle the URL directly. The URL handler is > actually installed in a faceless helper app which is in the main app's > Contents/Helpers/ directory. (This was done so I could control whether or > not my app is activated.) Here is the code: It’s an entry in the Info.plist that registers an app persistently as a handler for a URL scheme. Does your helper app have that entry? (It may be possible to register an app using code too, but the code snippet you gave is just for installing an AppleEvent handler in your process at runtime and has nothing to do with Launch Services registration.) —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: Manual reference counting and doubly-linked lists
On Nov 15, 2012, at 4:59 AM, William Squires wrote: > @interface Thing : NSObject > > @property (nonatomic, ???) Thing *nextThing; > @property (nonatomic, ???) Thing *prevThing; > > @end > > and somewhere I keep a reference to the 'head' of this doubly-linked list. > What should ??? be, "retain", or "assign" in order to work properly? If I was > using ARC instead, would they be "strong" or "weak"? Assuming the list > doesn't contain circular references (i.e. a<->b<->c<->a) will releasing my > 'head' reference properly clean up if I have: I think you should make one of the two retain (strong), the other assign (weak). E.g. nextThing is strong. That means when you release head, it releases thing1, which then releases its nextThing (thing2) etc., tearing the whole list down like dominoes and not leaking. However, you can still walk backwards using prevThing. You just have to make sure that when you sever the connection between an object and its nextThing, you also clear their prevThing, or you have a dangling pointer. You also need to be a bit careful when re-arranging objects. Before you disconnect some object's nextThing, retain the nextThing until you re-insert it, so it doesn't go away. While theoretically you could have a separate array for the retains and have thing unretained, that would be kind of pointless: You create linked lists for performance reasons, because look-up of the next object is fast. You're kind of defeating that benefit (at least for insertions and removals) if you still use an array to retain them. Also, NSArray is not a classic C-style linear array. If you look at the performance guarantees Apple gives, they're a little looser. What NSArray actually does internally is switch algorithms depending on how many items you put in it. So you might get a red/black tree (or whatever), or a straight C array, or a linked list already just by using NSArray. Also, look at for( object in collection ) and the fast enumeration stuff, which lets the NSArray be smart about iterating over your list of objects based on its own knowledge of what algorithm it is using. PS - Objective C is actually not that young ... it's from 1983. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ 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: Manual reference counting and doubly-linked lists
On 15 Nov, 2012, at 12:47 PM, Daniel DeCovnick wrote:
> Strong/retain for next, weak/assign for previous.
> On Nov 14, 2012, at 7:59 PM, William Squires wrote:
>
>>
>> @interface DoublyLinkedListClass
>>
>> @property (nonatomic, retain) Thing *head;
>>
>> @end
>>
>> "doublist.m"
>> @implementation DoublyLinkedListClass
>>
>> @synthesize head = _head;
>>
>> …
>>
>> -(void)dealloc
>> {
>> self.head = nil; // Is this begging for a problem?
> no in ARC (but it's unnecessary), yes in MRC; you should [head release];
> instead, or you'll leak memory.
>
> -Dan
Since the property is declared retain then setting it nil will release it just
as [ _head release ] would (_head is the actual iVar), so no leak there, and
that will begin the collapse the whole chain of linked objects.
I'll leave the debate about property accessors vs direct variable access in
init and dealloc well alone, either will work.
___
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: Mysterious crash report
On 14 Nov 2012, at 22:10, Graham Cox wrote: > > On 15/11/2012, at 8:59 AM, Nick Zitzmann wrote: > >> Oh. I understand how that could happen with GC if the app tried to re-use a >> finalized object, but the only resurrections I've seen happen under RR or >> ARC were zombies… Sorry. > > > Well, the crash is actually from libdispatch, so who knows what it's using? > > Our app actually only makes fairly light use of threads, and does not do any > communication over the network, etc, except as might be done behind the > scenes by standard classes. Apparently this occurred when cancelling a > document save, though it might have nothing directly to do with that. At the > time of the crash, NSToolbar was doing something on the main thread... > > That's the problem with this - even if I fully understood what it meant (I > don't) then it's not clear that the issue is in any way fixable in our app's > code. I believe the Versions system uses XPC internally. Does your app support Versions? ___ 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
