On Wed, Nov 19, 2008 at 5:41 PM, mmalcolm crawford <[EMAIL PROTECTED]> wrote:
>
> On Nov 19, 2008, at 2:29 PM, Michael Ash wrote:
>
>> On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
(This is the one t
On Nov 19, 2008, at 2:29 PM, mmalcolm crawford wrote:
> You send a release message to instance variables for which there is a
> corresponding retain or copy property.
which is why I originally said:
>>> (This is the one thing I hate the *most* about properties - they
>>> really feel glued on, at
On Nov 19, 2008, at 3:05 PM, Ricky Sharp wrote:
Now, when you say "call through your properties in init/dealloc", is
that explicitly for things set up with @property? Or, has what I've
been doing all these years with calls to accessors in init/dealloc
really "bad"?
There's no differenc
On Nov 19, 2008, at 4:11 PM, j o a r wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that "best practices"
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The of
On Nov 19, 2008, at 1:57 PM, Brian Stern wrote:
I'm starting to think that maybe using the assign properties is the
better way to handle this.
That's certainly one approach, and one that was considered.
The problem is that you then have to think through every outlet
declaration to make s
On Nov 19, 2008, at 2:29 PM, Michael Ash wrote:
On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford <[EMAIL PROTECTED]
> wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
(This is the one thing I hate the *most* about properties - they
really
feel glued on, at this point, rather than b
On Nov 19, 2008, at 2:22 PM, Brian Stern wrote:
That is indeed correct. The official guideline is, AFAIK, to not
call through your properties in init / dealloc.
For whatever reason UIViewController sets its view property to nil
from its dealloc method. Greg's override of setView is based
On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford <[EMAIL PROTECTED]> wrote:
>
> On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
>>
>> (This is the one thing I hate the *most* about properties - they really
>> feel glued on, at this point, rather than being a language feature that
>> the "whole com
On Nov 19, 2008, at 5:11 PM, j o a r wrote:
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that "best practices"
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The of
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that "best practices"
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
Correct.
(This is the one thing I hate the *most* about properties - they
re
On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote:
My understanding (and I'm a noob in this) is that "best practices"
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
That is indeed correct. The official guideline is, AFAIK, to not call
throu
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
There are competing issues. Following this best practice forces me
to add public properties for all my outlets that my code never
uses. This violates encapsulation and seems wasteful and error-prone.
No, it's not. The nib-loading mechanis
On Nov 19, 2008, at 4:41 PM, Ricky Sharp wrote:
From Apple's template code, didReceiveMemoryWarning does have these
code comments generated:
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
// Release anything that's not essential, such as cached data
> But if your dealloc is like this...
>
> - (void)dealloc
> {
> self.thisProp = nil;
> self.thatProp = nil;
> ...
> }
>
> then you'll be calling the accessors and the right thing will happen
> (i.e. release if necessary). This is what I currently do for all dev
> work (iPhone or M
On Nov 19, 2008, at 10:13 AM, Brian Stern wrote:
I think that you're probably right and that it's redundant.
Needless to say, mmalc's best practice has the outlets being
released in dealloc. That's why I had that code there in the first
place.
FWIW, I don't think that UIViewController
On Nov 19, 2008, at 10:29 AM, Greg Titus wrote:
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is
in many respects academically unsatisfying.
(b) For non-top-level-object, specify an a
On Nov 19, 2008, at 7:00 AM, Brian Stern wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in
many respects academically unsatisfying.
(b) For non-top-level-object, specify an assign attribute for the
property -- and risk dang
On Nov 19, 2008, at 3:59 AM, mmalcolm crawford wrote:
On Nov 18, 2008, at 10:01 AM, Brian Stern wrote:
OK Erik, I'll bite. What you describe above is correct as far as
it goes. However, when you say all the memory management is
handled in one place, of course it's two. The object has t
On Nov 17, 2008, at 9:33 PM, Jeff Laing wrote:
How about:
http://developer.apple.com/samplecode/CacheInfo-MacOSX/listing1.html
(for example) which has the IBOutlet tag on the instance variables
rather than the properties; I'll bet its different because properties
and instance vars have the same
On Nov 18, 2008, at 10:01 AM, Brian Stern wrote:
OK Erik, I'll bite. What you describe above is correct as far as it
goes. However, when you say all the memory management is handled in
one place, of course it's two. The object has to be released. The
normal place to release objects is
Thanks Greg,
That does work and has no bad side effects. I can leave in the retain
properties and release the outlets in the view controller's dealloc
method.
Thanks,
Brian
On Nov 18, 2008, at 1:19 PM, Greg Titus wrote:
Brian,
The way to handle this is to _not_ respond to memory warn
Brian,
The way to handle this is to _not_ respond to memory warnings in
subclasses (at least not for the purposes of view outlet handling -
there may be other non-view memory you want to free up in response to
a memory warning). Instead, implement -setView: in your
UIViewController subcla
On Nov 18, 2008, at 9:15 AM, Erik Buck wrote:
If you write correct accessors for all outlets, then the retain/
release memory management is entirely handled in one method. the -
set retains the new value and releases the old value.
Any confusion regarding memory management for IB outlets se
If you write correct accessors for all outlets, then the retain/release memory
management is entirely handled in one method. the -set retains the new value
and releases the old value.
Any confusion regarding memory management for IB outlets seems to stem from
failure to write the accessors an
On Nov 18, 2008, at 2:12 AM, Jonathan Hess wrote:
Which parts do you feel are contrary? I'm guessing it's that outlets
with no setters are retained.
Yes, that's the root of the whole issue. The fact is that outlets
without setters that are retained aren't released by the code that
retai
On Nov 18, 2008, at 1:14 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:59 AM, Roland King wrote:
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is
that if a setter exists, it is called. If a setter does not
On Nov 18, 2008, at 12:59 AM, Roland King wrote:
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is
that if a setter exists, it is called. If a setter does not
exist, the instance variable is looked up and set
On Nov 18, 2008, at 1:00 AM, Jonathan Hess wrote:
On Nov 18, 2008, at 12:49 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Normally instance variables and properties share the same name,
Normally in your code maybe, not mine.
so it doesn't matter to Interface
On Nov 18, 2008, at 12:49 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change
automagically. These days when I add any property I go right to
the de
On Nov 18, 2008, at 12:49 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Normally instance variables and properties share the same name,
Normally in your code maybe, not mine.
so it doesn't matter to Interface Builder where the 'IBOutlet' text
appears. If you'
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is that
if a setter exists, it is called. If a setter does not exist, the
instance variable is looked up and set directly, and if it is an
object, it is retained. Thi
On Nov 18, 2008, at 12:43 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:34 AM, Jonathan Hess wrote:
The solution to a memory leak should never be an unbalanced release.
What I did to fix this was to add all of the properties to all of
the outlets so they'd all be retained through those
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change automagically.
These days when I add any property I go right to the dealloc
method (and init if I have one) and ensure I'v
On Nov 18, 2008, at 12:35 AM, Jonathan Hess wrote:
Normally instance variables and properties share the same name,
Normally in your code maybe, not mine.
so it doesn't matter to Interface Builder where the 'IBOutlet' text
appears. If you're going to give your instance variables different
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 propert
I simply don't need properties for all my Outlets, except for this
issue. I also don't really like making all my outlets implicitly
public. But I'm forced to do that.
Here's one way to avoid making your outlets public:
// Header
@interface MyClass : NSObject {
@private
IBOutlet UIL
On Nov 18, 2008, at 12:34 AM, Jonathan Hess wrote:
The solution to a memory leak should never be an unbalanced release.
What I did to fix this was to add all of the properties to all of the
outlets so they'd all be retained through those properties. Then I
added all the releases to all
On Nov 18, 2008, at 1:11 PM, 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 th
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change automagically.
These days when I add any property I go right to the dealloc method
(and init if I have one) and ensure I've managed that property
before I forget.
Yes, but
On Nov 18, 2008, at 12:13 AM, mmalcolm crawford wrote:
On Nov 17, 2008, at 8:53 PM, Brian Stern wrote:
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 prop
On Nov 17, 2008, at 10:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewControl
> If you declare a property:
>
> @property (nonatomic, assign) MyLabel *label1;
>
> but make the connection in IB to mLabel1, then the property accessor
> isn't used. So the outlet is set using setValue:forKey:. Which
> results in the value being retained, precisely as described in the
> docume
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 t
On Nov 17, 2008, at 8:53 PM, Brian Stern wrote:
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
releas
On Nov 17, 2008, at 9:11 PM, Roland King wrote:
I'm a bit limited at work, no Mac here, so I took a look with
wordpad .. how nice.
You've defined the actual label pointers as IBOutlet, like this
IBOutlet MyLabel* mLabel1;
and then called the properties label1 etc.
in your .h file. When
On Nov 17, 2008, at 9:10 PM, Brian Stern wrote:
I simply don't need properties for all my Outlets, except for this
issue. I also don't really like making all my outlets implicitly
public. But I'm forced to do that.
You can use the readonly option for your properties. Alternatively,
you
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 relea
On Nov 17, 2008, at 11:51 PM, mmalcolm crawford wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
On Nov 17, 2008, at 11:58 PM, mmalcolm crawford wrote:
On Nov 17, 2008, at 8:34 PM, Brian Stern wrote:
Don't you find it odd that you need to release outlets in
didReceiveMemoryWarning?
Not at all -- assuming that you have a reference -- strong or weak
-- to an item in the user interfac
On Nov 17, 2008, at 8:34 PM, Brian Stern wrote:
Don't you find it odd that you need to release outlets in
didReceiveMemoryWarning?
Not at all -- assuming that you have a reference -- strong or weak --
to an item in the user interface, you want to make sure you break it
if the view is sup
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
This way I only have to release them in one spot, not two.
No, it doesn't.
There is no sense at all in releasing outlets in viewDidLoad.
Follow the pattern I described and it'
On Nov 17, 2008, at 8:05 PM, Roland King wrote:
The iPhone version of nib unarchiving and hookup seemed very
consistent to me, it makes use of properties or setFoo: if you have
them, allowing you to manage objects any way you like.
This applies to both iPhone and Mac OS X/desktop.
This is
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
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewControlle
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 outl
On Nov 17, 2008, at 11:20 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
Why would you be releasing outlets when the view just loaded?
Generally releasing happens when you're ready for some
On Nov 17, 2008, at 8:17 PM, Brian Stern wrote:
I think it makes more sense to release the Outlets in viewDidLoad.
Why would you be releasing outlets when the view just loaded?
Generally releasing happens when you're ready for something to go
away
On Nov 17, 2008, at 8:15 PM, Brian Stern wrote:
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.
I never said this. I compared having objects unarchived from a nib to
being alloc'd, w
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewController whose view
is released in didReceiveMemoryWarn
On Nov 17, 2008, at 11:05 PM, Roland King wrote:
OK, this issue has come up for me very recently. It appears
that on iPhoneOS IBOutlets are retained, regardless of the
presence of properties. Even worse, in the presence of an
assign property the outlet is still retained. Whatever c
OK, this issue has come up for me very recently. It appears that
on iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an assign property the
outlet is still retained. Whatever code is retaining the outlets
never releases them. So
On Nov 17, 2008, at 10:53 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:46 PM, Brian Stern wrote:
On Nov 17, 2008, at 10:17 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that
on iPhone
On Nov 17, 2008, at 7:46 PM, Brian Stern wrote:
On Nov 17, 2008, at 10:17 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that
on iPhoneOS IBOutlets are retained, regardless of the presence of
p
On Nov 17, 2008, at 10:17 PM, Luke the Hiesterman wrote:
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that
on iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an assig
On Nov 17, 2008, at 7:12 PM, Brian Stern wrote:
OK, this issue has come up for me very recently. It appears that on
iPhoneOS IBOutlets are retained, regardless of the presence of
properties. Even worse, in the presence of an assign property the
outlet is still retained. Whatever code is
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewController whose view
is released in didReceiveMemoryWarn
On Nov 17, 2008, at 3:06 PM, mmalcolm crawford wrote:
Going forward, you're encouraged to declare outlets as follows:
@interface AppController : NSObject {
NSTextField *myTextField;
...
}
@property (nonatomic, retain) IBOutlet NSTextField *myTextField;
Jeff asked (posted with permission):
On Nov 17, 2008, at 1:46 PM, Andy Lee wrote:
You don't have ivars "along with" outlets. An outlet *is* a
particular kind of ivar. It's an object reference that is declared
in such a way that IB recognizes it and allows you to assign its
value graphically in IB. Typically the declaration
On Nov 17, 2008, at 2:36 PM, Greg Deward wrote:
In my example, I have the following items in my App Controller class:
Text Field (along with an IBOutlet)
Button (along with an IBOutlet)
Table View (along with an IBOutlet)
Mutable Array instance variable
The
On Mon, Nov 17, 2008 at 11:36 AM, Greg Deward <[EMAIL PROTECTED]> wrote:
> Luke / Randall,
>
> Thanks for replying. I did not want to embarrass Mr. Hillegass with my
> ignorance, but his book IS the one I am trying to follow. I am currently
> working on his "To Do List" example in Chapter 6 (page
Luke / Randall,
Thanks for replying. I did not want to embarrass Mr. Hillegass with
my ignorance, but his book IS the one I am trying to follow. I am
currently working on his "To Do List" example in Chapter 6 (page 110).
In my example, I have the following items in my App Controller class
As you pointed out, you have two kinds of relationship in IB: outlets and
actions.
>From a single object, you designate either an outlet object or a target object.
For the target case, you have to specify the associated action selector.
Usually though, you don't draw both kinds of connection from
On Nov 17, 2008, at 11:09 AM, Greg Deward wrote:
Good afternoon!
I am trying to learn Cocoa and am having difficulty remembering
which direction to CTRL-drag controls to wire up the controls in
Interface Builder. For example, dragging from my button to my App
Controller (NSObject) or vic
With new versions of IB, it's not even necessary to remember. Simply
right-click on an object and it will bring up a HUD with the list of
outlets or sent messages or whatever you need. Alternatively, you can
view this list in the outlets tab of the inspector window.
Even if the outlet you n
74 matches
Mail list logo
