On Nov 18, 2008, at 12:32 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:11 AM, Roland King wrote:
Brian Stern wrote:
On Nov 17, 2008, at 11:35 PM, Roland King wrote:
Yes, but this is exactly the point. If I have no property for
an Outlet it's still retained. If I have a property for an
outlet that is assign, and not retain the outlet is still
retained, and I still must release it, even though I never
retained it.
When you say I can manage the outlets any way I like this is
wrong. They are managed for me. I want them to not be
retained. I don't have that option.
Now that I understand this I can live with it. But it still
makes no sense to me.
_______________________________________________
That's not what the documentation says and it's not my
experience either. The documentation says (section titled NIB
Object Retention) that each object in the NIB file is created
with a retain count of 1 and then autoreleased. Then they are
hooked up using setValue:forKey: which uses the setter method if
it exists. It also explicitly tells you that if you don't retain
the array of top-level objects you're going to lose them.
So if you have an outlet which is assign, and the setter method
is correct, the object will be created with retain count of 1,
autoreleased, then the setter method will be called and assign
it (no retain) and you do not have to release it. Why do you
think that you do?
I've done this, I have this exact patten in some of my iPhone
code, I have a delegate property which is assign and it is
assigned and it goes away when it's supposed to go away.
OK. The reason I believe that is because I fixed a massive
memory leak a couple days ago that I tracked down to this issue.
I built a simple test application that demonstrates that outlets
that have no properties or have assign properties are retained
anyway and must be released.
Here's my test project:
http://bellsouthpwp2.net/b/r/brians99/projects/TestPropertiesAndOutlets.zip
There are three labels that are outlets. One has a retain
property, one an assign property, and the third no property.
Unless they are released they are never dealloced. All three act
the same.
in your .h file. When you hook them up in IB (I can't open that
here so I'm afraid I can't look) what is the name of the thing you
bind to, label1 or mLabel1? I think you'll find it's mLabel1 right?
I believe what you're doing is accessing the variables DIRECTLY in
each binding because you have defined those at outlets, not the
properties, and in that case yes they get retained as you know and
as the documentation says.
What I think you wanted was this
MyLabel *mLabel1;
@property( nonatomic, assign ) IBOutlet MyLabel *label1;
to define the PROPERTY as the outlet, not the variable.
You're right. I guess I didn't know there was a difference in the
semantics based on the position of the IBOutlet.
I know I'm repeating myself, but I just want to be clear. The problem
here isn't the position of 'IBOutlet' the problem is that the instance
variable and property have different names. Referring to the outlet
'mLabel' is different than referring to the outlet 'label'. One will
result in looking for a setter called 'setMLabel:' and the other will
result in looking for a setter named 'setLabel:' If the property and
the instance variable had the same name, it wouldn't matter where you
placed the IBOutlet modifier.
Jon Hess
In the end though I'm still pretty much forced to have properties
for these outlets even though I don't want them.
--
Brian Stern
[EMAIL PROTECTED]
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
