Setting a tag on NSProgressIndicator

2014-07-05 Thread Daniel Luis dos Santos 
Hello all,

I have the item prototype of a NSCollectionView. This prototype in declared in 
a NIB file along with its view.
Now I want to display an image in this view, but while it is loading I want to 
display a circular progress indicator instead of the loaded image.

I have subclassed NSView and made it the view of the item prototype, so I can 
trigger the image loading and the replacement of the progress
indicator with the image well.

In order for the progress indicator to start animating I have to call its 
startAnimation message. But I can’t have an outlet from the progress indicator
to the item view because the NSCollectionView creates new objects for its 
items. 

So the only way I can access the subviews, is to programatically get the 
subviews. For easing that process I would like to set a tag on the progress 
indicator, but Interface builder doesn’t let me. The option appears disabled.

How can I get the progress indicator object, or any object inside the superview 
?

Thanks
___

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: Setting a tag on NSProgressIndicator

2014-07-05 Thread Lee Ann Rucker 
Put your collection view prototype in a separate nib, make its File's Owner a 
subclass of NSCollectionViewItem, add IBOutlets to that.

The IconCollection sample app shows how to implement collection view prototypes 
in separate nibs. Having it in the same nib as the collection view is really 
only good for trivial implementations.


- Original Message -
From: "Daniel Luis dos Santos" 
To: "Cocoa-Dev List" 
Sent: Saturday, July 5, 2014 1:45:14 PM
Subject: Setting a tag on NSProgressIndicator

Hello all,

I have the item prototype of a NSCollectionView. This prototype in declared in 
a NIB file along with its view.
Now I want to display an image in this view, but while it is loading I want to 
display a circular progress indicator instead of the loaded image.

I have subclassed NSView and made it the view of the item prototype, so I can 
trigger the image loading and the replacement of the progress
indicator with the image well.

In order for the progress indicator to start animating I have to call its 
startAnimation message. But I can’t have an outlet from the progress indicator
to the item view because the NSCollectionView creates new objects for its 
items. 

So the only way I can access the subviews, is to programatically get the 
subviews. For easing that process I would like to set a tag on the progress 
indicator, but Interface builder doesn’t let me. The option appears disabled.

How can I get the progress indicator object, or any object inside the superview 
?

Thanks
___

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.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=p1QCZjOxsY7kY8QLYdN5SaHykQApcXo%2FcRo66QiJvX4%3D%0A&s=f13c07e34c40bcb0d3e6dd72fa098b974d94a21d7f9c4c731b3c14674a0d16bc

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: awakeFromNib multiple objects - all connected?

2014-07-05 Thread Rob Petrovec 

> On Jul 4, 2014, at 9:13 PM, Graham Cox  wrote:
> 
> 
> On 5 Jul 2014, at 1:56 pm, Trygve Inda  wrote:
> 
>> As long as A can call into B & C and know that B & C have their outlets
>> hooked up, that's fine.
> 
> You can rely on all outlets being connected. What you can't rely on is the 
> order in which each object's -awakeFromNib is called.
Actually, you can’t rely on all the outlets in the entire nib to be 
connected when the first awakeFromNib is called.  This is an undocumented 
behavior, so it can change out from under you at any time.  So you shouldn’t 
rely on this behavior just because it happens today, it could easily change in 
the some future release.

The only thing you can rely on, because it is documented, is that the 
outlets for ObjectA will be connected when ObjectA's -awakeFromNib is called, 
and the outlets for ObjectB will be connected when ObjectB's -awakeFromNib is 
called.  There is no guarantee on the order of when their awakeFromNib’s will 
be called, so if you need to do something in one object that calls into another 
object from the nib (that is not a subview) then you should do it later in the 
loading sequence.  Like when the nib’s owner has -awakeFromNib, windowDidLoad 
or -loadView called, or when the common-superview to ObjectA & ObjectB’s 
-awakeFromNib is called.

> On Jul 4, 2014, at 8:56 PM, Trygve Inda  wrote:
> 
>> 
>> On Jul 4, 2014, at 8:18 PM, Trygve Inda  wrote:
>> 
>>> When an object in a nib receives awakeFromNib are all the outlets throughout
>>> the entire nib hooked up, or only those outlets in the object that is
>>> receiving awakeFromNib?
>> 
>> All the outlets are hooked up. But not all the other objects in the nib have
>> run their -awakeFromNib methods yet, so you have to be cautious about calling
>> into other objects in the nib during your -awakeFromNib implementation.
>> 
>> —Jens
> 
> That's fine. My situation is I have a subclass of NSWindowController and
> several custom objects:
> 
> Owner (MyWindowController)
> 
> ControllerA
> 
> ControllerB
> ControllerC
> 
> These are all in the nib and I call init in such a way that Owner is passed
> a reference which it stores. When ControllerA gets an awakeFromNib it needs
> to call methods in ControllerB and ControllerC that require all the outlets
> to be hooked up.
> 
> I need to ensure ControllerA runs first so I do this by having an
> awakeFromNib in ControllerA, but not in B or C. So that when ControllerA
> gets awakeFromNib, it can manage things.
> 
> As long as A can call into B & C and know that B & C have their outlets
> hooked up, that's fine.
Having -awakeFromNib implemented in one object and not another does not 
determine the order.  So you can’t rely on ControllerB & ControllerC having 
their outlets connected when ControllerA’s -awakeFromNib is called.

A better, and less fragile approach would be to override the Owner’s 
-awakeFromNib (or better yet windowDidLoad since it is an NSWindowController 
subclass) and have it instruct ControllerA to do whatever it is you wanted 
ControllerA to do in its awakeFromNib.

Good luck...

—Rob



___

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: awakeFromNib multiple objects - all connected?

2014-07-05 Thread Kyle Sluder 
On Sat, Jul 5, 2014, at 08:10 PM, Rob Petrovec wrote:
> 
> > On Jul 4, 2014, at 9:13 PM, Graham Cox  wrote:
> > 
> > 
> > On 5 Jul 2014, at 1:56 pm, Trygve Inda  wrote:
> > 
> >> As long as A can call into B & C and know that B & C have their outlets
> >> hooked up, that's fine.
> > 
> > You can rely on all outlets being connected. What you can't rely on is the 
> > order in which each object's -awakeFromNib is called.
>   Actually, you can’t rely on all the outlets in the entire nib to be 
> connected when the first awakeFromNib is called.  This is an undocumented 
> behavior, so it can change out from under you at any time.  So you shouldn’t 
> rely on this behavior just because it happens today, it could easily change 
> in the some future release.

The resource programming guide explicitly describes the sending of
-awakeFromNib as occurring after all outlets have been set up:



--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: awakeFromNib multiple objects - all connected?

2014-07-05 Thread Roland King 

> 
> The resource programming guide explicitly describes the sending of
> -awakeFromNib as occurring after all outlets have been set up:
> 
> 
> 

[ oops didn't reply to the list ]

.. which is one of the things always bothered me when you load 
UIViewControllers + views from NIBs. In that NIB you usually have a 
UIViewController as file's owner, a view which is its view which has a load of 
subviews, plus some other top-level objects. Often some of the view's subviews 
are IBOutlets of the UIViewController, eg buttons you want to enable and 
disable etc. 

After awakeFromNib all the outlets are connected except for those to subviews 
of the UIViewController's view, they remain nil until after viewDidLoad. Other 
top-level object outlets are connected, but not the view nor its subviews. I 
always felt that broke the awakeFromNib contract; the objects are in the NIB, 
the outlets are in the NIB, surely they should be connected at awakeFromNib. 

___

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