viewDidLoad and KVO
I often have a view controller that displays a view associated with a model object. So, I'll have a foo property on that VC, and in the prepareForSegue call that presents the VC, I'll setFoo on it. In my -setFoo: method, I set up KVO on the properties of the foo that I'm interested in displaying. In the -observe... method, I update the various bits of UI as properties change. This generally works very well, except when I get to the VC via a segue. -prepareForSegue gets called before -viewDidLoad, so none of the IBOutlets exist yet. I can solve this by doing an explicit UI update step in -viewDidLoad, but that ends up effectively duplicating the UI update code. I can load the view in -setFoo: by referencing self.view, but this seems like a hack. What are other people doing to address this? Any best practice you guys like? -- 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: viewDidLoad and KVO
In my -setFoo: method, I set up KVO on the properties of the foo that I'm
interested in displaying. In the -observe... method, I update the various
bits of UI as properties change.
If you're doing something like this:
- (void)setFoo: (Foo *)aFoo
{
[foo removeObserver:self forKeyPath:@whatever...];
foo = aFoo;
[foo addObserver:self forKeyPath:@whatever...;
}
we used that pattern for a while but were constantly getting bit by observers
on objects being dealloced or KVO firing and triggering unwanted side effects
if we called setFoo: in dealloc. So we did a complete switch over to doing
[self addObserver:self forKeyPath:@foo.whatever...
in init, and removeObserver in dealloc, because you can remove an observer on
yourself in dealloc without the observers still registered warning.
Since it's on self, you can set it before foo exists, and setFoo: triggers it.
Plus we could use synthesized setters.
- Original Message -
From: Rick Mann rm...@latencyzero.com
To: Cocoa Developers cocoa-dev@lists.apple.com
Sent: Wednesday, June 4, 2014 10:03:20 PM
Subject: viewDidLoad and KVO
I often have a view controller that displays a view associated with a model
object. So, I'll have a foo property on that VC, and in the prepareForSegue
call that presents the VC, I'll setFoo on it.
In my -setFoo: method, I set up KVO on the properties of the foo that I'm
interested in displaying. In the -observe... method, I update the various bits
of UI as properties change.
This generally works very well, except when I get to the VC via a segue.
-prepareForSegue gets called before -viewDidLoad, so none of the IBOutlets
exist yet.
I can solve this by doing an explicit UI update step in -viewDidLoad, but that
ends up effectively duplicating the UI update code.
I can load the view in -setFoo: by referencing self.view, but this seems like a
hack.
What are other people doing to address this? Any best practice you guys like?
--
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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0Am=qYOnOaiiYwn8zuydsyBcZuhg6AnT0QTIlKRcBpdwfnM%3D%0As=a80229e6e590ffa9a96606cdc929d245804adff0b0a29bb275a85110c02b83bb
This email sent to lruc...@vmware.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: viewDidLoad and KVO
On Jun 5, 2014, at 00:26 , Lee Ann Rucker lruc...@vmware.com wrote:
If you're doing something like this:
- (void)setFoo: (Foo *)aFoo
{
[foo removeObserver:self forKeyPath:@whatever...];
foo = aFoo;
[foo addObserver:self forKeyPath:@whatever...;
}
we used that pattern for a while but were constantly getting bit by observers
on objects being dealloced or KVO firing and triggering unwanted side effects
if we called setFoo: in dealloc. So we did a complete switch over to doing
[self addObserver:self forKeyPath:@foo.whatever...
in init, and removeObserver in dealloc, because you can remove an observer on
yourself in dealloc without the observers still registered warning.
Since it's on self, you can set it before foo exists, and setFoo: triggers
it. Plus we could use synthesized setters.
I collect the removeObserver calls into an ignoreFoo method, and similarly
the addObserver in an observeFoo method. Then in -dealloc I call -ignoreFoo.
I've never run into the (annoying) registration mismatch errors.
Your suggestion is a good one, but I don't think it solves the problem I have
of -setFoo: being called before -viewDidLoad (before the IBOutlets are non-nil).
--
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: Drawing custom contiguous selection highlight in view-based NSOutlineView
On 05 Jun 2014, at 05:18, Graham Cox graham@bigpond.com wrote: On 5 Jun 2014, at 12:54 pm, Lee Ann Rucker lruc...@vmware.com wrote: It does? When I saw your subject line I thought you were were talking about SourceView style, because I have one - it's view-based - and I'd been wondering if it was possible to get a unified multi-selection gradient. Actually I see different things in different apps - Mail has a gradient for each row even for contiguous selections. iTunes unifies the selection for its main list views (playlists only allow a single selection). It's hard to find an app that uses a source-style list that allows multiple selections, so I might be imagining it. But I'd still like to know if it can be done. --Graham Take a look at the tool you daily use :) Xcode has continuous background gradients in it's source-list style OutlineView ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ 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: Drawing custom contiguous selection highlight in view-based NSOutlineView
On 5 Jun 2014, at 7:42 pm, Michael Starke michael.sta...@hicknhack-software.com wrote: Take a look at the tool you daily use :) Xcode has continuous background gradients in it's source-list style OutlineView Good call :) well, that shows exactly what I'm talking about... but also suggests that it isn't view-based but cell based. BTW, I tried overriding the -highlightSelectionInClipRect: method but it isn't called at all for a view-based table. I also tried a hack where my custom row view called back into the superview (the table view) to draw a contiguous highlight but I couldn't get that to work properly, because it messes fairly substantially with the drawing order. Stumped. --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: viewDidLoad and KVO
Why don't you use viewWillAppear and viewDidDisappear, to register and
unregister observers to your foo property object?
If you don't use ARC, be carefull to unregister on dealloc too!
El 05/06/2014, a las 09:30, Rick Mann rm...@latencyzero.com escribió:
On Jun 5, 2014, at 00:26 , Lee Ann Rucker lruc...@vmware.com wrote:
If you're doing something like this:
- (void)setFoo: (Foo *)aFoo
{
[foo removeObserver:self forKeyPath:@whatever...];
foo = aFoo;
[foo addObserver:self forKeyPath:@whatever...;
}
we used that pattern for a while but were constantly getting bit by
observers on objects being dealloced or KVO firing and triggering unwanted
side effects if we called setFoo: in dealloc. So we did a complete switch
over to doing
[self addObserver:self forKeyPath:@foo.whatever...
in init, and removeObserver in dealloc, because you can remove an observer
on yourself in dealloc without the observers still registered warning.
Since it's on self, you can set it before foo exists, and setFoo: triggers
it. Plus we could use synthesized setters.
I collect the removeObserver calls into an ignoreFoo method, and similarly
the addObserver in an observeFoo method. Then in -dealloc I call
-ignoreFoo. I've never run into the (annoying) registration mismatch errors.
Your suggestion is a good one, but I don't think it solves the problem I have
of -setFoo: being called before -viewDidLoad (before the IBOutlets are
non-nil).
--
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/alejandro.visiedo%40gmail.com
This email sent to alejandro.visi...@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
Re: viewDidLoad and KVO
On 5 Jun 2014, at 3:03 pm, Rick Mann rm...@latencyzero.com wrote:
I can solve this by doing an explicit UI update step in -viewDidLoad, but
that ends up effectively duplicating the UI update code.
I can load the view in -setFoo: by referencing self.view, but this seems like
a hack.
What are other people doing to address this? Any best practice you guys
like?
I guess this is really a question about the timing of the -setFoo: call
relative to the -loadView call, and that would probably imply that calling
-setFoo: is actually the responsibility of a higher-level controller than this
one (probably the object that alloc/inits the view controller). So maybe you
could set up a simple informal delegate method such that the VC has the
higher-level controller as its delegate, and when -viewDidLoad: is called, it
asks the delegate to provide 'foo' at that time.
As far as observing 'foo' via KVO, the way I generally like to do this is to
have my VC implement methods that have the exact same form (as setters) as the
properties they're interested in on the model object, then my observer method
boils down to a very simple trampoline:
- (void) observeValueForKeyPath:
{
[self setValue:[changeDict objectForKey:NSKeyValueChangeNewKey]
forKey:keyPath];
}
This leverages the automatic unwrapping of property values that KVC already
does, so I don't have to do it again myself. This is so general I have it
wrapped up into a simple base class that all of these similar view controllers
subclass - each subclass then just adds the setKey : methods it needs.
For setting up and tearing down the KVO, I do as you do, but something that can
simplify this is to get the observed objects to vend a list of observable
properties that the observer can simply iterate over and add itself as an
observer for each one. This is typically a class method. The downside would be
that there may well be properties of no interest, but this approach implies you
still need a cover method for those properties, but of course you can also
override -setValue:forUndefinedKey: not to throw an exception but to ignore
instead. Otherwise, just observing the properties of interest one by one is
also fine. I have found though that by generalising the approach, if you have a
large number of similar but variant interfaces on a large number of similar but
variant model objects, it can generalise away a lot of the tedium. I've
actually found this approach a lot easier to live with than bindings, which
also claim to generalise the problem (as well as moving it into IB), but can be
opaque as a result.
In terms of setting up the initial state of the UI, provided -setFoo: is called
at the right time (after the view is loaded), then passing the
NSKeyValueObservingOptionInitial as a flag to the -addObserver: call ensures
that the same trampolining method is used both for initial setup and ongoing
changes to the model property.
As for tear-down at dealloc time, -setFoo:nil is fine, as it then tears down
the observation on the existing (retained) foo object prior to releasing it.
I've not run into issues with the unregistering observations error, at least
not since this was improved a lot a few OS versions back.
--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: Drawing custom contiguous selection highlight in view-based NSOutlineView
Take a look at the tool you daily use :) Xcode has continuous background gradients in it's source-list style OutlineView Yeah, but we all know Apple gets to cheat :) - Original Message - From: Michael Starke michael.sta...@hicknhack-software.com To: cocoa-dev cocoa-dev@lists.apple.com Sent: Thursday, June 5, 2014 2:42:49 AM Subject: Re: Drawing custom contiguous selection highlight in view-based NSOutlineView On 05 Jun 2014, at 05:18, Graham Cox graham@bigpond.com wrote: On 5 Jun 2014, at 12:54 pm, Lee Ann Rucker lruc...@vmware.com wrote: It does? When I saw your subject line I thought you were were talking about SourceView style, because I have one - it's view-based - and I'd been wondering if it was possible to get a unified multi-selection gradient. Actually I see different things in different apps - Mail has a gradient for each row even for contiguous selections. iTunes unifies the selection for its main list views (playlists only allow a single selection). It's hard to find an app that uses a source-style list that allows multiple selections, so I might be imagining it. But I'd still like to know if it can be done. --Graham Take a look at the tool you daily use :) Xcode has continuous background gradients in it's source-list style OutlineView ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ 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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0Am=riT2NDI4aO2Vs4SoRbkWVoHzbZpgVgrrEp8lhbKcmzI%3D%0As=58f0398d56dc7b6bb063a5f4beb3e5f81dc0c3bb25f521b9305b6958e547915c This email sent to lruc...@vmware.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: Drawing custom contiguous selection highlight in view-based NSOutlineView
On 5 Jun 2014, at 14:03, Graham Cox graham@bigpond.com wrote: On 5 Jun 2014, at 7:42 pm, Michael Starke michael.sta...@hicknhack-software.com wrote: Take a look at the tool you daily use :) Xcode has continuous background gradients in it's source-list style OutlineView Good call :) well, that shows exactly what I'm talking about... but also suggests that it isn't view-based but cell based. BTW, I tried overriding the -highlightSelectionInClipRect: method but it isn't called at all for a view-based table. I also tried a hack where my custom row view called back into the superview (the table view) to draw a contiguous highlight but I couldn't get that to work properly, because it messes fairly substantially with the drawing order. Stumped. You could use your current approach to calculate + draw different gradients for each row to give the overall effect of a single gradient. No idea how messy this would be to implement! Jonathan ___ 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: viewDidLoad and KVO
On Jun 5, 2014, at 06:26 , Alejandro Visiedo García
alejandro.visi...@gmail.com wrote:
Why don't you use viewWillAppear and viewDidDisappear, to register and
unregister observers to your foo property object?
If you don't use ARC, be carefull to unregister on dealloc too!
That, combined with observing on self.foo, might work, except that the
appear/disappear calls aren't guaranteed to be balanced.
El 05/06/2014, a las 09:30, Rick Mann rm...@latencyzero.com escribió:
On Jun 5, 2014, at 00:26 , Lee Ann Rucker lruc...@vmware.com wrote:
If you're doing something like this:
- (void)setFoo: (Foo *)aFoo
{
[foo removeObserver:self forKeyPath:@whatever...];
foo = aFoo;
[foo addObserver:self forKeyPath:@whatever...;
}
we used that pattern for a while but were constantly getting bit by
observers on objects being dealloced or KVO firing and triggering unwanted
side effects if we called setFoo: in dealloc. So we did a complete switch
over to doing
[self addObserver:self forKeyPath:@foo.whatever...
in init, and removeObserver in dealloc, because you can remove an observer
on yourself in dealloc without the observers still registered warning.
Since it's on self, you can set it before foo exists, and setFoo: triggers
it. Plus we could use synthesized setters.
I collect the removeObserver calls into an ignoreFoo method, and similarly
the addObserver in an observeFoo method. Then in -dealloc I call
-ignoreFoo. I've never run into the (annoying) registration mismatch errors.
Your suggestion is a good one, but I don't think it solves the problem I
have of -setFoo: being called before -viewDidLoad (before the IBOutlets are
non-nil).
--
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/alejandro.visiedo%40gmail.com
This email sent to alejandro.visi...@gmail.com
--
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
Simple question? NSButton/checkbox color
I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Something like this: is what I’m after. ___ 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: Simple question? NSButton/checkbox color
On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Something like this: is what I’m after. ___ 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/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com 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: Simple question? NSButton/checkbox color
On Jun 5, 2014, at 5:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. The NDA has been significantly loosened this year, so I can tell you that there is no support for legacy UI on Yosemite. --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: Simple question? NSButton/checkbox color
OK maybe I’m not being clear. We need to have a checkbox that can be colored, exactly the same way that the Calendar app on both color their checkboxes for the calendar they are representing. Right now the only way I can think of doing that is to create a checkbox image, and color it, and use that. Obviously if we do that, we have to have different images for Mavericks and Yosemite. So we have to mimic Yosemite. I’d prefer NOT to have to create mimicked checkbox images. That’s what I’m trying to prevent. I’m asking all the AppKit gurus here if there is a better way, a more proper way, to color a checkbox control without having to use images to mimic the UI of the OS we’re running on. On Jun 5, 2014, at 6:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Alex Kac - President and Founder Web Information Solutions, Inc. “Don't forget until too late that the business of life is not business but living.” -- B.C. Forbes, ___ 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
