Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)

[Brian Stern]

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 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 this  
behavior.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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

So, one should release all outlets that are tied to the view _iff_  
it doesn't have a superview.  And then of course purge all support  
objects that would not be of any use.


Having said that, I'll probably adopt the following:

- (void)didReceiveMemoryWarning
{
   [super didReceiveMemoryWarning];
   if ([self.view superview] == nil)
   {


The problem with this code is that the view accessor causes the view  
to be loaded if it's not already loaded.  So simply by asking for  
self.view.superview you may be causing your entire view hierarchy to  
be loaded in from the nib.  This doesn't seem to be a good thing to do  
inside a memory warning.  Besides that, the code you showed is wrong.   
You have to have the call to super at the end of the method after you  
call self.view.superview, otherwise you're guaranteeing that the view  
will be loaded every time your method is called.


This is not just an academic point.  The way that many iPhone apps are  
constructed with navbars means that you've got a root view and then  
one or more other view controllers that get pushed.  The root view  
will participate in all memory warnings for the life of the app and  
may be unloaded many times.  And that's all fine.  It just doesn't  
make any sense to load it in response to a memory warning.


That's why I said upthread that self.view will never be non-nil.

I'm starting to think that maybe using the assign properties is the  
better way to handle this.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 assign attribute for the  
property -- and risk dangling pointers.


The override of setView is very similar to the viewDidUnload  
callback that I proposed as a solution for this.  It has its own  
further issues.  UIViewController calls [setView:nil] from its  
dealloc method so the subclass has to be prepared for this.  What  
I've done is to add all the public retain properties for all the  
outlets.  Additionally I've added a


-(void)releaseOutlets

method that uses the properties and sets them all to nil.  I call  
this method from my subclass's dealloc method and setView:  
override.  That way I only have one place to write the code that  
releases all the outlets.



Brian,

What is your reason for having a separate -releaseOutlets method to  
do this?


The sample that I gave (calling self.anOutlet = nil; when the  
argument to -setView: is nil) will do whatever releasing is required  
(if the anOutlet property is "retain") or simple zeroing the pointer  
(if the anOutlet property is "assign"). The fact that  
UIViewController calls -setView:nil from its -dealloc is just  
additional convenience. All of your outlets get cleaned up at the  
same time as the UIViewController cleans up the main view. There is  
no need to write any outlet related code in your -dealloc at all,  
since it is all handled via the superclass and the -setView: override.


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 is documented as setting its  
view to nil from its dealloc method.  Frankly I don't know why it does  
it. I don't think it needs to.  It could certainly change in the  
future.  In fact another best practice (I think this is from mmalc) is  
to not set properties to nil in dealloc but to simply release them.   
If this changed the retained outlets would leak.


I don't feel strongly about this, but not having the release code in  
my dealloc method makes me a little nervous.  I do understand that my  
releaseOutlets method gets called twice when the object is being  
dealloced.


In short, the way I think of it, -setView: _IS_ the one centralized  
place that deals with all view-related pointers, including all  
outlets. And UIViewController calls -setView: at all the necessary  
times (setup, memory warning, dealloc), so you don't have to do  
anything else.


I certainly had never thought of any reason to override this accessor  
before this issue came up.  loadView and viewDidLoad are the normal  
override points for view creation and there are others for view  
appearance and disappearance, as I'm sure you know.  It's just that  
there's no comparable override point for the view being unloaded, even  
though that's a normal part of view controller life on iPhone.


Brian
___

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]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 to be  
released.  The normal place to release objects is in their owner's  
dealloc method, and this also applies to outlets.


This is standard (best) practice for memory management.  It's not  
clear what the problem is here.
The only difference with outlets is that, if you don't follow best  
practice, you have to spend some time thinking about whether or not  
you have to release in dealloc (more on this below).


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.   
That's the reason I didn't do this earlier.  The one little paragraph  
in the documentation that addresses this says I 'should' do it this  
way but doesn't explain why.  I'll point out that the paragraph that  
explains memory management of outlets on Mac OS X on that page is half  
the length of the iPhone paragraph, and I'd maintain that the iPhone  
paragraph isn't long enough.


However, UIViewController has the ability to unload its view outlet  
in response to a memory warning.  Any subclass should also release  
its outlets in response to the memory warning, if the base class  
releases its view, but not otherwise.  So now there are three  
places to manage the memory of these outlets. The problem is that  
the base class doesn't always release its view in response to a  
memory warning and as far as I can tell the subclass has no clean  
way of telling if the view will be released or has been released.   
That's the problem.


You're shifting the goalposts; this is not the problem you  
originally described.


It's not me who has shifted the goalposts.  The whole playing field  
was moved out from under me when it was decided to retain outlets by  
default, which is different from how this all works on Mac OS X.


I'll admit that I was confused and probably a few other things a few  
days ago when I discovered that a huge memory leak was caused by  
outlets being retained behind my back.  And then I got a second kick  
in the shorts when I read your post pointing out that outlets need to  
be released in didReceiveMemoryWarning, which hadn't occurred to me  
was a side effect of their being retained.


In fact there have been several problems: You didn't understand the  
documentation as written; in testing the implementation of outlets  
you made a fundamental mistake; and -- as noted in my original  
message in this sub-thread -- the "situation" with outlets has  
heretofore been "a mess".


You can add to your list of problems 'insufficient documentation and  
education of memory management of outlets.'  If you want to believe  
that I'm just one yokel developer who can't read and understand the  
documentation that's your right.  I'm sure I'm not the only one.




To reiterate points that Jon and Joar have made:

You shouldn't have to think about something as mundane as "how do I  
manage memory for outlets?".  There are far more interesting issues  
for a programmer to spend their time on.


I couldn't agree with you more.

This is the reason for proposing a new "best practice" that will  
address all situations simply and easily.  *If* you know what you're  
doing -- and your "experiment" has shown that even relatively  
experienced developers may sometimes not "know what they're doing"  
-- then it is perfectly possible to deviate from the suggested  
pattern, but you then do this at your own risk.



I do, though, have to apologise for introducing a wrinkle (the  
problem of UIViewController's response to memory warnings) and then  
providing an incorrect solution.  I managed to mistake a question  
from some time ago for the answer -- mainly because I never received  
an answer.  I have now and can relay part of it (note to self: >).


I guess even 'relatively experienced developers may sometimes not  
"know what they're doing"'



 There are several issues:

The template clearly indicates what should be done:


Obviously the client code can't touch _view or self.view in  
didReceiveMemoryWarning.  That's why I said upthread that there's no  
clean way for the client code to tell if the view will be unloaded or  
has been unloaded.



In theory, you should simply check whether the view has a superview:
but since _view is declared as @package, you can't do that.
You could invoke 'view':
but th

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 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 subclass, and release outlets when the argument is  
nil. For example:


- (void)setView:(UIView *)aView;
{
if (!aView) {
self.anOutlet = nil;
self.anotherOutlet = nil;
self.thirdOutlet = nil;
}
[super setView:aView];
}

This will correctly clean up all of your outlets whenever the  
UIViewController unloads its view, and not otherwise.


Hope this helps,
- Greg

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 in their owner's  
dealloc method, and this also applies to outlets.


However, UIViewController has the ability to unload its view outlet  
in response to a memory warning.  Any subclass should also release  
its outlets in response to the memory warning, if the base class  
releases its view, but not otherwise.  So now there are three  
places to manage the memory of these outlets. The problem is that  
the base class doesn't always release its view in response to a  
memory warning and as far as I can tell the subclass has no clean  
way of telling if the view will be released or has been released.   
That's the problem.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 seems to  
stem from failure to write the accessors and reliance on syntactic  
sugar.  Just remember that


@property (nonatomic, retain) IBOutlet UILabel *label;

results in synthesis of the appropriate accessor methods.  It does  
nothing more than save you some typing and document your intention.   
The -set method that results from the above property declaration  
retains the new value and releases the old value.  The memory  
management is therefore all handled in one place just the way it  
should be and the way you want.


So what's the problem again ?


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 in their owner's dealloc method,  
and this also applies to outlets.


However, UIViewController has the ability to unload its view outlet in  
response to a memory warning.  Any subclass should also release its  
outlets in response to the memory warning, if the base class releases  
its view, but not otherwise.  So now there are three places to manage  
the memory of these outlets. The problem is that the base class  
doesn't always release its view in response to a memory warning and as  
far as I can tell the subclass has no clean way of telling if the view  
will be released or has been released.  That's the problem.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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  
retained them.  The responsibility for releasing them is implicitly  
passed on to some other code.  I misunderstood this after reading that  
paragraph a number of times because it is simply contrary to my  
understanding of Cocoa memory management.  I think it is contrary to  
the Cocoa memory management rules that the code that retains these  
objects isn't releasing them.


Now that I know that, there are still problems.  The outlets can be  
released in more than one place.  As mmalc mentioned, the view  
controller's view may be unloaded in response to a memory warning.   
However, the view won't be unloaded if the view controller is the  
frontmost view controller.  There's no simple way for a view  
controller subclass to know if it's the frontmost view controller or  
therefore if its view will be unloaded.  There is no viewDidUnload  
callback that would be the right place to release the outlets in this  
case.  The code that mmalc showed is not correct because it doesn't  
take into account the fact that the frontmost view controller won't  
unload its view.


In effect it is the UIViewController base class that is retaining the  
outlets, or causing them to be retained, when the nib is loaded.  But  
it abdicates responsibility for them.  The UIViewController base class  
is also the class that is releasing its view without any notification  
to the derived class that it should also release the outlets.


I haven't decided how I'm going to fix all this.  Either I'll add  
assign properties so the outlets are not retained or I'll release them  
all in viewDidLoad.


Most nib-loading on iPhone OS is done by UIViewController and I  
suppose most of my complaints above are with the UIViewController  
implementation.  In my code I would hardly ever have a reason to want  
to retain an outlet.  Having outlets be retained by default gives my  
code no benefit, and causes some complications.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 directly, and  
if it is an  object, it is retained. This means that for  
IBOutlets, with no  setters, they're retained in iPhone OS. This  
is different from Mac  OS X. If you're writing code on both  
platforms, or are planning to,  you should always use properties  
on both platforms since it makes  the decision to retain outlets  
explicit and obvious.



How come the documentation that mmalc quoted doesn't have this  
clear  statement?



which one did he quote, the one I suggested to you has it .. it's  
under Nib Object Retention. It's a page I have bookmarked because as  
I switch between iPhone and regular OSX I like to remind myself what  
it says. It's pasted below.


Yes, that's it.  I've read it plenty of times.





iPhone OS - managed memory model

Objects in the nib file are created with a retain count of 1 and  
then autoreleased. As it rebuilds the object hierarchy, however,  
UIKit reestablishes connections between the objects using the | 
setValue:forKey:| method, which uses the available setter method or  
retains the object by default if no setter method is available.


I admit that I didn't internalize this statement because the behavior  
is different from the Mac.  I also didn't internalize this because it  
seems to contradict the standard Cocoa memory management rules.  My  
code doesn't retain the outlets so it shouldn't have to release them.


If you define outlets for nib-file objects, you should also define a  
setter method for accessing that outlet.


Why SHOULD?


Setter methods for outlets should


Why SHOULD?

retain their values, and setter methods for outlets containing top- 
level objects must retain their values to prevent them from being  
deallocated. If you do not store the top-level objects in outlets,  
you must retain either the array returned by the | 
loadNibNamed:owner:options:| method or the objects inside the array  
to prevent those objects from being released prematurely.


In a nib loaded by UIViewController I have no access to the top level  
objects array so this isn't usually relevant.


The shoulds in there confused me.  The fact that the behavior is  
different from the Mac confused me.  The fact that the behavior seems  
contrary to standard Cocoa memory management rules confused me.  I  
assure you that I'm not the only person confused by this and who  
doesn't understand this.

___

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]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 Builder where the 'IBOutlet'  
text appears. If you're going to give your instance variables  
different names though, you need to put the IBOutlet qualifier on  
the property if you want it to be used.


I guess I just had a perfect storm of issues that made it appear  
that things were working differently from the way they were  
working.  My properties, though present, were ignored. The fact  
that it works differently from Mac OS makes it worse.


Which difference are you referring to? It sounds like you're  
referring to the fact that if a setter doesn't exist the variable is  
retained by setValue:forKeyPath:.


Yes, that's the one.


To avoid implementing setters, you're free to them out and let IB  
directly set you're iVars. If you do that, you'll just need to  
release them in dealloc. The best practices are there to help  
developers who are new to both platforms. If you feel that you have  
an adequate understanding of how the outlets are established, you're  
free to use a pattern that you prefer.


I understand it better now.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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've managed that  
property before I forget.


Yes, but this is exactly the point.  If I have no property for an  
Outlet it's still retained.


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. This means that for IBOutlets, with no  
setters, they're retained in iPhone OS. This is different from Mac  
OS X. If you're writing code on both platforms, or are planning to,  
you should always use properties on both platforms since it makes  
the decision to retain outlets explicit and obvious.


How come the documentation that mmalc quoted doesn't have this clear  
statement?






Jon Hess


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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  
names though, you need to put the IBOutlet qualifier on the property  
if you want it to be used.


I guess I just had a perfect storm of issues that made it appear that  
things were working differently from the way they were working.  My  
properties, though present, were ignored. The fact that it works  
differently from Mac OS makes it worse.


Thanks for the help guys.

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 the deallocs to match those retains.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 property, and the third no property.   
Unless they are released they are never dealloced.  All three act  
the same.



It would help if you declared/connected your outlets correctly...

//...

then you'll get the behaviour I described...


OK, fair enough.

You didn't address my other point regarding the memory warnings.  If  
the view controller is visible then it won't release the view  
hierarchy.  Your suggested code will null the outlet even though it  
still exists, resulting in bugs in some cases.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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.


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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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  
be released in sime situations -- e.g. a UIViewController whose  
view is released in didReceiveMemoryWarning. To ensure that you  
don't prolong the lifetime of objects you got from the nib, you  
should set (use your accessor methods to) set those variables to  
nil in the relevant method, e.g.:


@interface MyController : UIViewController {
UILabel *label;
...
}
@property (nonatomic, retain) IBOutlet UILabel *label;

then

- (void)didReceiveMemoryWarning {
 self.label = nil;
 [super didReceiveMemoryWarning];
}


OK, this issue has come up for me very recently.  It appears that  
on iPhoneOS IBOutlets are retained, regardless of the presence of  
properties.


No, on iPhone outlets are consistently *not* retained -- which is  
precisely why you do need to retain top-level objects on iPhone. But  
absent accessor methods, connections are made using KVC...

This is documented here:
	<http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/uid/1051i-CH4-SW6 
>


That's the vague documentation that I referred to.  What you're  
telling me is that where it says should in that paragraph it really  
means must.  OK, that's what I figured out a few days ago.


Where it says that it "retains the object by default if no setter  
method is available", that seems to contradict what you say about  
outlets not being retained.  Actually I didn't really absorb that  
statement before.  It means that if there's no property then the  
outlet will be retained.  OK.


My experience with the assign property is contrary to what the docs  
seem to be saying.  I think the outlet is retained even if there is an  
assign property.


As I stated originally, following the pattern I describe above makes  
memory management consistent in all situations.


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.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 interface, you want to make sure you break  
it if the view is supposed to disappear.
If you have a strong reference you want to make sure that the item  
is disposed of when the other items from the nib go away; if you  
have a weak reference you want to make sure you don't send a message  
to a deallocated object (it'll go when the view goes...).


UIViewController isn't guaranteed to release the view.  It only does  
this if the view isn't visible, based on its own heuristics.  My  
subclass has no real way to know if the view will be released or not.


If I release the outlets in viewDidLoad then I don't have this  
problem.  My code has no interest in maintaining a strong reference to  
its outlets.  The view hierarchy can do that just fine.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 something to go  
away


There is an extra retain on the Outlets.  It is unneeded.  The outlets  
are sufficiently retained by the view hierarchy.


Either I have to release in both dealloc and in  
didReceiveMemoryWarning, or I can have them in viewDidLoad.


Release also is sent when you transfer ownership of an object to  
another object.  I don't wish to have ownership of the outlets.  They  
can be owned by the view hierarchy.  So if I release them in  
viewDidLoad then I don't have to release them in two other places,  
which is obviously error prone.


Don't you find it odd that you need to release outlets in  
didReceiveMemoryWarning?

___

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]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 didReceiveMemoryWarning. To ensure that you don't  
prolong the lifetime of objects you got from the nib, you should set  
(use your accessor methods to) set those variables to nil in the  
relevant method, e.g.:


@interface MyController : UIViewController {
 UILabel *label;
 ...
}
@property (nonatomic, retain) IBOutlet UILabel *label;

then

- (void)didReceiveMemoryWarning {
   self.label = nil;
   [super didReceiveMemoryWarning];
}


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.

___

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]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 code is  
retaining the outlets  never releases them.  So it seems that  
client code must release  all outlets.



Seems to me that the outlets must have a retain count of at  
least  one when they're unarchived, as though they were alloc'd.  
It makes  sense that the programmer should have to manually  
release objects  in dealloc. How else would it happen?



IBOutlets are not necessarily top level objects.  Most are simply   
views that happen to be in the view hierarchy.  There will  
typically  be one top level object in an iPhone nib.  This will be  
the view  that belongs to UIViewController.  It is the  
UIViewController base  class that loads the nib.  As long as it  
retains that top level view  then all the subviews will also be  
retained.  They should be  released when the UIViewController  
releases its view outlet.



Right, and view is a property of UIViewController. When you have  
your  UIViewController release view, that is an example of the  
programmer  releasing an outlet assigned from IB, which you seem to  
be arguing  that the programmer shouldn't have to release objects  
given to it from  IB.


Luke

Exactly - most of the things you're hooking up in IB are your own  
objects, those outlets are just instance variables which are being  
set for you. It's your object, you have to deal with the lifetimes  
of the objects you refer to. I don't see why IB makes any  
difference, it's just calling setFoo: on some instance of your  
class, what you define setFoo to do is entirely up to you, but if it  
retains the argument, then you have to release it one day, in  
dealloc() would be the natural place.


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.


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 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.

___

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]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 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 it seems that client code must  
release all outlets.


Seems to me that the outlets must have a retain count of at least  
one when they're unarchived, as though they were alloc'd. It makes  
sense that the programmer should have to manually release objects  
in dealloc. How else would it happen?


IBOutlets are not necessarily top level objects.  Most are simply  
views that happen to be in the view hierarchy.  There will  
typically be one top level object in an iPhone nib.  This will be  
the view that belongs to UIViewController.  It is the  
UIViewController base class that loads the nib.  As long as it  
retains that top level view then all the subviews will also be  
retained.  They should be released when the UIViewController  
releases its view outlet.


Right, and view is a property of UIViewController. When you have  
your UIViewController release view, that is an example of the  
programmer releasing an outlet assigned from IB, which you seem to  
be arguing that the programmer shouldn't have to release objects  
given to it from IB.


Top.  Level.  Object.

Whatever code loads the nib is the owner of the array of top level  
objects and should retain them.  That object is UIViewController, not  
my subclass.


At any rate.  The problem is that this is poorly documented.

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 assign property the  
outlet is still retained.  Whatever code is retaining the outlets  
never releases them.  So it seems that client code must release all  
outlets.


Seems to me that the outlets must have a retain count of at least  
one when they're unarchived, as though they were alloc'd. It makes  
sense that the programmer should have to manually release objects in  
dealloc. How else would it happen?


IBOutlets are not necessarily top level objects.  Most are simply  
views that happen to be in the view hierarchy.  There will typically  
be one top level object in an iPhone nib.  This will be the view that  
belongs to UIViewController.  It is the UIViewController base class  
that loads the nib.  As long as it retains that top level view then  
all the subviews will also be retained.  They should be released when  
the UIViewController releases its view outlet.


Furthermore, NSBundle loadNibNamed:owner:options: on iPhone OS returns  
an array of the top level objects.  It would be trivial for the  
UIViewController base class object that is loading the nib to retain  
that array and of course release it in its dealloc.


If user code doesn't retain the outlets I don't understand why user  
code should be releasing those objects.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

[Brian Stern]

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 didReceiveMemoryWarning. To ensure that you don't  
prolong the lifetime of objects you got from the nib, you should set  
(use your accessor methods to) set those variables to nil in the  
relevant method, e.g.:


@interface MyController : UIViewController {
 UILabel *label;
 ...
}
@property (nonatomic, retain) IBOutlet UILabel *label;

then

- (void)didReceiveMemoryWarning {
   self.label = nil;
   [super didReceiveMemoryWarning];
}


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 it seems that client code must release all  
outlets.


The documentation on this is vague, with a lot of 'should's and not  
clear statements of what really happens.  Actually this isn't (only)  
related to didReceiveMemoryWarning (which I hadn't considered related  
to this problem until you raised it).


Is this the way that things are supposed to work on iPhone OS?

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about interface builder

[Brian Stern]

On Nov 17, 2008, at 6:19 PM, Kyle Sluder wrote:

On Mon, Nov 17, 2008 at 5:25 PM, Brian Stern  
<[EMAIL PROTECTED]> wrote:
I can tell you that the majority of iPhone developers are refusing  
to use

IB.  The reasons I usually see are


I didn't get the implication that the OP was doing iPhone development.
In fact, I'd be very surprised if he were, considering the situation
he described.


Um, OK.  I hijacked the thread.  You asked the question.  I replied in  
a little different direction because it's something I've been thinking  
about for a while.


You misunderstand my original post.  Those points I listed were not  
mine.  They were the  points that I see every day posted on the non- 
Apple iPhone forums explaining why many developers don't use IB.


The points I listed after 'In Addition' are mine.

Apple is obviously failing, or at least not succeeding, in its task of  
educating iPhone developers.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about interface builder

[Brian Stern]

On Nov 17, 2008, at 4:59 PM, Kyle Sluder wrote:


Why does everyone new to the platform want to immediately discard IB?
It is the correct (yes, "correct", not "preferred", not "easiest", but
*correct*) way to implement your interface.


I can tell you that the majority of iPhone developers are refusing to  
use IB.  The reasons I usually see are


It's one more thing to learn.
It's not as good as GUI builders on other platforms.
Generating a UI in code gives more control.
For a long time IB was buggy and incomplete for iPhone development so  
developers got used to generating their UIs without it.


In addition:

The UI's on iPhone tend to be simpler and have fewer different views  
so whatever savings in time there might be with IB are not so  
pronounced.


Apple examples tend to not use IB.  For instance there are no Apple  
examples for UITableView that use IB.  The UICatalog example app,  
which demonstrates every UI element, is almost completely done in  
code.  IMO, there's no excuse for this.


Certain aspects of the UI must be done in code because things aren't  
revealed in IB or simply can't be done there.


Apple spending months diddling over its NDA meant that most iPhone  
developers found non-Apple forums to discuss iPhone development so any  
guidance that Apple might have had over how to write proper apps has  
been very late in coming.


I do use IB for a lot of my UI on iPhone but quite a bit of it is in  
code also.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Compare images in Cocoa

[Brian Stern]

On Oct 30, 2008, at 11:21 PM, Pierce Freeman wrote:

Hi everyone. I am wondering if there is some way to compare two  
images in
Cocoa, and then somehow spit out a percent of how similar they are.  
The only
way I could think of is comparing every pixel, but this seems like  
it would
take a long time, and even so I have no idea how to go about doing  
that.


Thanks for your help.


You don't say what you want this number for.  Are you trying to tell  
if two images of faces are of the same person?  Two images of  
buildings are of the same building?  Two images have similar colors in  
them?


FWIW, iterating over all the pixels in an image and doing some kind of  
simple math on the pixel values will not be very time-consuming.   
There are lots of Photoshop filters that do this and are very fast.


One thought that comes to mind is to calculate the histogram for the  
two images and compare them.  This could give a kind of simplistic %  
difference.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Can we ask iPhone questions yet?

[Brian Stern]

Apple has made an iPhone forum for iPhone developers available here




On Oct 27, 2008, at 6:19 PM, Karan, Cem (Civ, ARL/CISD) wrote:

Like the subject says, can we ask iPhone questions yet?  I'm stumped  
and I need help.



___

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]

Re: Apple Developer Forums

[Brian Stern]

On Oct 24, 2008, at 11:04 PM, Stefan Arentz wrote:

On Fri, Oct 24, 2008 at 12:15 PM, Randall Meadows <[EMAIL PROTECTED] 
> wrote:

It looks like we're legit to discuss now!

<http://devforums.apple.com/>


Personally I think this is a big joke.


But seriously, what we need is an OPEN discussion platform. Not some
apple moderated forum limited to developers.


There are plenty of them.  Just look.  That's of course what makes  
this all a joke.  There are tons of completely open forums, iPhone  
code archived on google.code, huge numbers of blogs with iPhone  
tutorials, all of this for the last six months.


Apple has been peeing in the iPhone development pool for a while.   
Until now they haven't taken a dump in the pool.  I'll say that this  
new forum is a baby-step in the right direction.  But it all remains  
to be seen.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Wasted Space and Kernighan

[Brian Stern]

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." -- Brian W. Kernighan




Personally I find debugging to be half as hard as writing the code in  
the first place.


Also, debugging my own clever code is rarely a problem.  Debugging  
someone else's clever code is another story.


Where do bindings fall in all this?  It's often like debugging someone  
else's clever code.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: How do I guarantee that an object is dealloced on the main thread?

[Brian Stern]

Ok, I've fixed this as recommended.  It really wasn't too difficult to  
move all the interesting bits of dealloc to the stop method, and to  
zero out all the instance variables after they're released so this can  
be safely called more than once.  This way I can call stop from the  
main thread and not worry about what thread dealloc will be called on.


I didn't write this code, it's a freely available server  
implementation, and it wasn't designed to be dealloced.  It is  
intended to just run until the app terminates, but that doesn't meet  
my needs.


Thanks for the input.

Brian



On Oct 5, 2008, at 6:08 PM, Jim Correia wrote:


On Oct 5, 2008, at 5:41 PM, Brian Stern wrote:

My main reason was just cleanliness.  Looking more closely at the  
code however, most of which I didn't write, there are some runloop  
sources that are removed and calls to NSObject  
cancelPreviousPerformRequestsWithTarge:selector:object. Most of the  
code that set those things up will have run on the main thread so  
should be cleaned up on the main thread. There's some other  
networking cleanup that I don't know if it's threadsafe or not.


It's conceivable that I can rework the cleanup so that most of it  
happens in the stop method and the dealloc method is mostly empty


That's probably the preferable solution to this problem, even if it  
is more work up front.


I guess from your question you don't have a one sentence answer to  
my question.



Using classic memory management, your object will be deallocated  
when its last owner releases it. If this object has been shared  
amongst threads, the it will be deallocated on the last thread which  
releases it.


Under garbage collection, you are encouraged not to implement a - 
finalize method. If you do implement one, there is no guarantee  
about the order it will be called in, if it will be called at all,  
or what thread it will be invoked on.


In your -stop method, you know you are done with the object, so  
doing your cleanup there (on the main thread, if necessary) seems  
like an appropriate solution.


- Jim

___

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]

Re: How do I guarantee that an object is dealloced on the main thread?

[Brian Stern]

On Oct 5, 2008, at 4:52 PM, Jim Correia wrote:


On Oct 5, 2008, at 4:43 PM, Brian Stern wrote:


This is the question I really wanted to ask:

I have an object X that is alloc/inited on the main thread.  This  
object creates some NSThreads with  
detachNewThreadSelector:toTarget:withObject, which have object X as  
their target.  At a later point I want to release object X and have  
it be dealloced on the main thread.


How do I guarantee that object X is dealloced on the main thread?

The problem is this: the NSThread objects retain object X.  I have  
a stop method in object X that sets a 'cancelled' global that the  
thread objects inspect and they then exit when it turns true.  So I  
send stop and then release on the main thread.  The thread objects  
exit and eventually release object X but the last release, which  
causes the dealloc, can be on any thread.


The real question is, why do you care what thread the -dealloc  
method runs on?


What non-memory management side effects does your -dealloc method  
have which much be run on the main thread?




My main reason was just cleanliness.  Looking more closely at the code  
however, most of which I didn't write, there are some runloop sources  
that are removed and calls to NSObject  
cancelPreviousPerformRequestsWithTarge:selector:object. Most of the  
code that set those things up will have run on the main thread so  
should be cleaned up on the main thread. There's some other networking  
cleanup that I don't know if it's threadsafe or not.


It's conceivable that I can rework the cleanup so that most of it  
happens in the stop method and the dealloc method is mostly empty but  
if there's a way to guarantee that dealloc runs on the main thread  
then I'd probably prefer that.


I guess from your question you don't have a one sentence answer to my  
question.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

How do I guarantee that an object is dealloced on the main thread?

[Brian Stern]

Hi All,

The thread "Re: premature dealloc of the datasource of a NSTableView  
crashes my application" made me think about this problem again.


This is the question I really wanted to ask:

I have an object X that is alloc/inited on the main thread.  This  
object creates some NSThreads with  
detachNewThreadSelector:toTarget:withObject, which have object X as  
their target.  At a later point I want to release object X and have it  
be dealloced on the main thread.


How do I guarantee that object X is dealloced on the main thread?

The problem is this: the NSThread objects retain object X.  I have a  
stop method in object X that sets a 'cancelled' global that the thread  
objects inspect and they then exit when it turns true.  So I send stop  
and then release on the main thread.  The thread objects exit and  
eventually release object X but the last release, which causes the  
dealloc, can be on any thread.


I attempted to synchronize the exit of the thread objects' main method  
using NSConditionLock.  The synchronization worked but the dealloc  
still occurred on a background thread because the release from the  
NSThread happens after the main method returns.


I also tried to synchronize based on receipt of the  
NSThreadWillExitNotification.  The synchronization succeeded but this  
also failed because the notification is also sent before the NSThread  
releases its target.


I couldn't figure out any notification that is sent by the threads  
that happens after the release of their target or after the die  
entirely.  I couldn't figure out what to wait for.


This question of stopping threads has been mentioned numerous times in  
the archives but I didn't see this issue addressed.


Any thoughts?


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: premature dealloc of the datasource of a NSTableView crashes my application

[Brian Stern]

On Oct 4, 2008, at 11:36 PM, Michael Ash wrote:


Absolutely not. Write your code to work with any order. In this case,
what you should do is write your data source to nil out the table's
reference to it when it goes away:

- (void)dealloc {
   [tableView setDataSource:nil];
   [super dealloc];
}


What prevents the tableview from being dealloced before the  
datasource?  In that case the datasource is messaging a stale pointer.


I think that something higher up in the ownership graph needs to  
manage this, like the window controller.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: External C function and duplicate symbol

[Brian Stern]

It seems that what you want is an inline C function.  I don't think  
this is part of the C language standard but gcc seems to have its own  
method of doing this.  Just do a find on 'inline' in the Frameworks to  
see how it's done.   Look at CGBase.h for instance.



On Oct 3, 2008, at 8:32 AM, Scott Andrew wrote:

What about using #pragma once at the top of the header file? The  
other solution is to move the functions to a C file and move just  
the function definitions to header files. I prefer the second for  
readability. I usually have a utils.c and a utils.h. I'm not a big  
fan of function implementations in header files.


Scott

On Oct 3, 2008, at 4:19 AM, Christian Giordano wrote:


Hi guys, I've few functions that I'm keeping on an external .h file.
If the header is included in more than a class I get duplicate symbol
error. I tried using #ifndef which I use on my C++ classes but didn't
bring any luck. I had a look to the various headers in the framework
and I saw they use the following sintax:

#define VEC_ZERO_2(a)   \
{   \
 (a)[0] = (a)[1] = 0.0; \
}

Isn't there a way to achieve the same but having parameters and  
returns typed?



___

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]

Re: NSString's "mutableCopy" creating a leak?

[Brian Stern]

Hi All,

Just a note.  Although the moderator doesn't wish to see discussion of  
list issues here he should be prepared for dozens, probably hundreds  
of questions here where the answers to the questions go something like  
"you can't send dealloc to objects", "you can't call drawRect from  
your code directly", "you can't draw from a secondary thread' and many  
more like that.  Perusal of the message boards that have grown up  
around iPhone development reveals lots and lots of questions along  
those lines.


While the lists here are Apple's, they exist and are valuable because  
we all contribute to them.


Scott, and the other moderators: I'm sorry that your management has  
failed you and not given you guidance about what was going to happen  
today and what you should do on this list regarding iPhone questions.   
However, everyone on this list moves on internet time.  Apple needs to  
keep up.  The time to decide what new lists should exist is quickly  
passing.  The people that this affects most are the subscribers to  
this list and we should have a say in what happens.


It sounds like the lawyers are still in charge.

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [Moderator] Please hold off on iPhone SDK discussions until the rules are clarified later today

[Brian Stern]

On Oct 1, 2008, at 12:47 PM, James wrote:

Quick question, what do they mean by Released and Unreleased  
software (just want the terminology correct).


While I'm not a lawyer I read those sentences several times also.   
What I believe it means is that released versions of the iPhone OS are  
no longer covered by the NDS.  Any beta versions that some developers  
might have access to would still be covered by the NDA.  The NDA  
covers Apple's IP not anyone elses.  'Released software' must mean  
Apple's software, meaning the iPhone OS and SDK.  Anything else  
doesn't make any sense to me.



Thanks,
james


On Oct 1, 2008, at 12:44 PM, CocoaDev Admins wrote:


For those of you who have seen

http://developer.apple.com/iphone/program


We have decided to drop the non-disclosure agreement (NDA) for  
released iPhone software.


We put the NDA in place because the iPhone OS includes many Apple  
inventions and innovations that we would like to protect, so that  
others don’t steal our work. It has happened before. While we have  
filed for hundreds of patents on iPhone technology, the NDA added  
yet another level of protection. We put it in place as one more way  
to help protect the iPhone from being ripped off by others.


However, the NDA has created too much of a burden on developers,  
authors and others interested in helping further the iPhone’s  
success, so we are dropping it for released software. Developers  
will receive a new agreement without an NDA covering released  
software within a week or so. Please note that unreleased software  
and features will remain under NDA until they are released.


Thanks to everyone who provided us constructive feedback on this  
matter.


-

Please hold off on discussion of the SDK on this list until I can  
verify how this is to be handled, and post another message.



Thanks

Scott
[Moderator]___


___

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]

Re: Problem with NSUserDefaultsController

[Brian Stern]

Apparently NSUserDefaults delays its saving until the next time  
through the event loop, perhaps by using one of the  
performSelector:afterDelay calls, or something like that.  Is it  
possible that this is what's causing your issues?


I ran into this problem when trying to save user defaults at app  
terminate time, when afterDelay never comes.



On Sep 1, 2008, at 4:07 PM, Mark Allan wrote:

>> I've been playing around with bindings to  
NSUserDefaultsController in

a very simple app to test saving preferences, but the
[sharedUserDefaultsController save:self] method seems to return  
immediately

without waiting for the save operation to complete.

The save does actually take place, which I can see if I open the  
plist file
in Property List Editor, but if the very next line after sending  
the save
message is one which reads a property from the plist, it's the  
old value

which gets returned rather than the newly saved one.


The -save: method is unintuitive in name. It does not, as you  
may  think,
save changes to disk. It simply commits any changes to the   
NSUserDefaults
object. It's a no-op if appliesImmediately is YES. The only way  
to  force a

save is to call -synchronize on NSUserDefaults.


Thanks but the problem is actually the exact opposite. The file  
IS  being
saved - it's the userdefaults object which doesn't contain the   
right value
unless there's some short delay between the save and  objectForKey  
messages.


Sorry, I misread your post. We will need to see some code to  
determine the

issue.


Calling -synchronize on the userDefaults object makes no difference.

I'm already setting appliesimmediately to YES so that I can have
Cancel and OK buttons, and in terms of saving/reverting the plist  
file

it's working fine. Do I need to perform some action to connect the
userdefaults object to the userDefaultsController object?


Well, not other than binding it to the shared user defaults (unless  
you are
creating it programmatically, where it is set on creation). My  
understanding
is that the NSUserDefaults object is responsible for writing to  
disk, so if

you get the disk commit, it must be in the shared defaults.


Exactly!  That's my understanding too, which is why I'm confused.

The complete Xcode project is available here:
http://idisk.mac.com/markallan-Public/TestingNSUserDefaultsController.zip

If anyone has time to cast an eye over it, I'd really appreciate it.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: array segment

[Brian Stern]

Is there an obj-C equivalent to Java's System.arraycopy() which will  
allow me to easily copy a segment of an NSArray into a new array?




subarrayWithRange:
Returns a new array containing the receiver’s elements that fall  
within the limits specified by a given range.




http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/Reference/Reference.html#/ 
/apple_ref/occ/instm/NSArray/subarrayWithRange:


There is an example in the docs.


___

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]

Re: Should I retain a variable returned from this accessor?

[Brian Stern]

On Aug 11, 2008, at 10:51 PM, Peter N Lewis wrote:



I'm no Cocoa expert, but I think you're wrong on this, you've missed  
out a crucial line:


At 3:12 PM -0400 11/8/08, Sean DeNigris wrote:

// Get uid to return
NSString* todoUid = [newTodo uid];

// Clean up
[newTodo release];
newTodo = nil;

return todoUid;


[newTodo release] is not [newTodo autorelease].  So it may  
immediately call dealloc and dealloc the uid returned by by [newTodo  
uid].  To avoid this, you could do:


Not really.  This line:

// Add the todo to my iCal calendar
[[myCalendar todos] addObject:newTodo];


would appear to add newTodo to an NSMutableArray, which implicitly  
retains it.  So this method retains newTodo twice but releases it  
once.  As a result the todoUid string won't be released, as you fear,  
upon sending release to newTodo.



NSString* todoUid = [[[newTodo uid] retain] autorelease];

It is quite possible that [newTodo uid] does exactly the above, but  
it might just return the internal ivar.  If this is not true, I  
would very much like to be corrected!


Advice on this list that I think is good advice is to always use  
autorelease unless there is really good reason not to (eg, with a  
large number of objects in a loop).


One can think of two kinds of objects that end up in the autorelease  
pools. Temporary objects that will be autoreleased in one autorelease  
cycle and other objects that will remain in the autorelease pool  
indefinitely because their purpose demands persistence.  In the name  
of efficiency one might prefer that objects in this second group not  
be put in autorelease pools since their memory management can be more  
precisely controlled with alloc/init and release.  Placing them in an  
autorelease pool will incur some overhead in memory and cpu time each  
time that the pool tries to drain. The pattern for this second kind of  
object is exactly what the OP used in his code.  alloc/init followed  
by a retain (usually implicit in addObject: or addSubview:) followed  
by release.  Usually the release is the next line after the  
addObject:, not at the end of the method as the OP used.


You can count this as 'a really good reason' or not but IMO the OP has  
no reason to autorelease the object as you suggest.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: How to debug a corrupted stack

[Brian Stern]

On Aug 7, 2008, at 9:49 PM, Gerriet M. Denkmann wrote:


Or does anyone have a better idea?



Define your own struct or Objective-C class that has the same members  
as UTCDateTime.  Copy the values from a UTCDateTime to your struct or  
class. Encode/Decode your struct or class from NSValue.  With a few  
utility routines to handle this for you this should be simple and safe.


Or:

Use NSData, add a category to NSData containing: dataWithUTCDateTime:,  
add the appropriate accesor for UTCDateTime and/or for the members of  
UTCDateTime.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: help linking sqlite3 wrapper

[Brian Stern]

On Aug 4, 2008, at 11:56 AM, John Velman wrote:


After making changes to move the download from sqlite to sqlite3, and
checking that I have  /usr/local/lib/libsqlite3.a, and putting
/usr/local/lib in the library search path of the project, the source  
for

the Demo compiles but does not link.


Did you add libsqlite3.a to your project?

BTW, unless you have a specific reason for not doing so I'd recommend  
you use the system-supplied sqlite dylib rather than a third party .a  
file.  This file is contained within the SDKs included with Xcode.  In  
that case add this file to your project:


/Xcode3.1/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib


___

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]

Re: Why can't I name a property `tag'?

[Brian Stern]

On Jul 10, 2008, at 12:44 PM, Michael Ash wrote:


On Thu, Jul 10, 2008 at 9:49 AM, an0 <[EMAIL PROTECTED]> wrote:

Thanks. But isn't it annoying for XCode to pretend to know something
for sure while in fact it is just a wrong guess? At least the warning
is very misleading.


The warning isn't misleading at all. Xcode is not pretending anything.
It *does* know it for sure, it's just *wrong*. The warning then
appears because this wrong information causes other problems in the
code later on, due to a mismatched type.

The compiler definitely should complain if it has two methods with the
same name but different return types to choose from, and it doesn't
know which one is right. I've seen it happen many times. If it didn't
happen to you, it's because either it wasn't seeing one of them, or
because you found a compiler bug.

This is an inherent hazard of using the "id" type. For best results,
you should avoid using any method name which is already in use unless
your return type is compatible with the one already in use.

Mike


Actually this problem extends not only to return types but also  
parameter types.  So if one has a class like this:


@interface MyDocument : NSDocument{
}
- (id)initWithData:(int)inData;
@end

And you try to build one:

MyDocument* doc = [[MyDocument alloc] initWithData:0];

You will receive an error:   "incompatible type for argument 1 of  
'initWithData:"


The problem of course is that alloc returns an id and gcc's method  
matching is finding a different declaration of initWithData in the  
Cocoa headers for another class.


So I would add "For best results, you should avoid using any method  
name that is already in use unless its return type and parameters are  
identical with the already existing method."


Obviously there is some potential for new versions of Cocoa to add new  
methods that conflict with your own methods.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Does this caution need fixed? (newb)

[Brian Stern]

On Jul 9, 2008, at 10:44 AM, Chris Paveglio wrote:

I'm trying to make sure that this part of my code is good and clean  
and not leaking. I believe that I have it right (but still think I  
have something wrong).
This code makes a list of file paths, and then copies the files or  
folders from their location to the destination the user selected. If  
the item already exists in the destination, I delete it first (to  
overwrite with new data, yes this is what I intend and the user is  
aware of how the app works).
I've read all your previous responses (Thanks) and it seems like  
since I am just using "normal" strings that they will be  
autoreleased on their own. There are now no compiler cautions and  
the app seems to work OK.
A side issue is that I want to add a 2 second delay before closing  
the sheet that is displayed, is NSTimer the correct item to use?

Chris


I have some stylistic comments on this code.

Your method is too large.  To make it smaller you should break it up  
into a number of smaller tasks.

As Jens mentioned a string like this

NSString *string1  = @"Library/Preferences/Adobe Photoshop CS3  
Settings";


is pretty much the same as a string like this: @"Library/Preferences/ 
Adobe Photoshop CS3 Settings"


I would build a method that does nothing but return the array or  
arrays that contain your manifest of files to save


-(NSArray)myPrefsArray
{
// build array here
return myPrefs;
}

I notice that your  myPrefsSaved array is derived from the myPrefs  
array but it just has the file name not the full path.  I'd use  
[astring lastPathComponent] to either build the second array or just  
call this method inside your loop.


I would break out the entire copy files loop into its own method.

Since you loop over the contents of the myPrefs array I wouldn't hard  
code the loop index to 8 or 9 I'd depend on the [myrefsArray length]  
value to index the loop.  You should also look at NSEnumerator and  
also fast enumeration as ways to drive this loop in a better way.


I notice that you call [myPrefs objectAtIndex:i] several times in your  
loop.  If you use NSEnumerator or fast enumeration you can avoid this  
otherwise just call it once at the top of the loop and save the value  
in a temp string variable.


Also, declaring the loop counter outside the loop is now old  
fashioned.  You can try this:


for (int i = 0; i < limit; i++)

You might need to set your C dialect setting to C99 or gnu99 if you're  
using an old project. I recommend it.


You don't check any errors from the file manager operations. What if  
the user chooses a folder on a locked volume or the disk gets full or  
the user chooses a network volume and the network drops out?  Your  
users will hate you if these things happen but your app fails  
silently.  You should both check for errors and report them to the user.


I don't see any problems in this code with leaking of objects.

I don't like the way that all the steps of this process are done one  
after another in a sequential fashion.  I would probably set up the  
tasks to be done in a separate thread or have each file copy be done  
inside a timer callback until all are done and show a progress window  
probably in place of a progress sheet (although it might work ok  
either way).


Regarding your 2 second delay you can use a timer or  
performSelector:withObject:afterDelay but both will require you to  
provide a callback method that will dismiss your sheet.


Good luck,

Brian


___

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]

Re: Crashes with no backtrace when printing

[Brian Stern]

On Jul 3, 2008, at 7:24 PM, Ben wrote:

I have just been getting my app to print two custom views. One uses  
a layer-backed NSView (many CALayer sublayers, in the region of 450- 
ish), one a plain NSView. Sometimes (rarely, but often enough), with  
no apparent pattern, the app is crashing just before showing the  
print dialog. The problem is that the backtraces I get are more or  
less as follows :


Attaching to program: `/Path/goes/here', process 14859.
Cannot access memory at address 0x9ead7
Cannot access memory at address 0x9ead7
(gdb) bt
#0  0x0009ead3 in ?? ()
#1  0x0018ee80 in ?? ()
Cannot access memory at address 0x9ead7




What good is a debugger that can't give a stack trace when the app  
crashes?


See this recent thread on xcode_users:

http://lists.apple.com/archives/xcode-users/2008/Jun//msg00735.html

Activity Monitor is your friend.

In the end file a bug report against gdb and the debugger.  Maybe  
they'll fix it.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: re-factoring a category into a class instance

[Brian Stern]

On Jun 10, 2008, at 5:05 PM, Paul Archibald wrote:


Comrades:

I am working on a file-handling Cocoa app that (at this point) has a  
single window. We are adding a second window (really sort of a non- 
modal dialog) to do some extra processing of the target files. The  
interface for the new window is already built (with IB), but is not  
hooked up yet.


So, the way this started was as a AppController(ExtraCategory)  
thing, with the NIB file having a single controller object. I don't  
like that method, because there is a lot of data and code that would  
need to be replicated in the main AppController to handle the work  
that the ExtraCategory does. What I would like to do is put all the  
ExtraCategory stuff into its own class, but I am not sure how. My  
inclination is toward making the ExtraCategory into a  
NSWindowResponder, but the documentation I have read so far makes it  
look like that is more intended for document-based apps, which this  
is not. Also, I don't quite see (looking at some example code) how  
an extra controller is instantiated by the main app controller.




Since there's no such thing as NSWindowResponder I assume what you  
meant was NSWindowController.  And that's what you should use.   
There's no limitation of NSWindowController being only available or  
useful in document based apps.


You can instantiate it in the nib with IB or in code.  I usually  
instantiate it in code and have it load the nib and be the file's owner.


@implementation MyWinController

- (id)initWithWhatever:(whatever*)whatever
{
self = [super initWithWindowNibName:kMyWindowNibName];
if (self) {
// Add your subclass-specific initialization here.
// If an error occurs here, send a [self release] message and  
return nil.

}
return self;
}

// etc.


// instantiate it in your app controller something like this:

- (void)showMyWindow
{
if (! mMyWinController)
{
		mMyWinController = [[MyWinController alloc]  
initWithWhatever:whatever];

}

[mMyWinController showWindow:self];
}



___

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]

Re: App hangs when displaying any sheet in 10.5 [SOLVED]

[Brian Stern]

On Jun 6, 2008, at 1:58 AM, Graham Cox wrote:

I agree, the compiler ought to be able to use the return type to  
disambiguate two otherwise identically named methods (or warn of the  
mismatch) - but it clearly doesn't.


My experimentation reveals, with the Xcode 2.5 tools, that the return  
type of the first method in scope is used.  That is, given two methods  
in two different classes with the same names and different return  
types the one that comes first in the compilation unit rules the  
expected return type when sending the specified message to an id  
variable.


Also, if code attempts to send a message to an id variable and that  
message isn't in scope then warnings are issued and an assumption that  
the message returns a type of id and takes varargs is used.


It seems almost certain that you had a 'position' method that returned  
an integer type in scope somehow otherwise you either would have  
gotten a warning or the code would have correctly expected a float.


Having said that, I can see why the code wouldn't work correctly but I  
don't really know why it would result in memory corruption. Possibly  
it's in the position method or in objc_msgSend, which was called  
incorrectly instead of objc_msgSend_fpret.




On 6 Jun 2008, at 3:37 pm, Hamish Allan wrote:

On Fri, Jun 6, 2008 at 6:26 AM, Graham Cox <[EMAIL PROTECTED]>  
wrote:


I guess the question is, given an object type 'id', which method  
signature
will the compiler go with? Does the return type affect the method  
signature?

(In C++ it doesn't for example), so two methods:

- (CGPoint) position;
- (float)   position;

might well have identical signatures. The compiler doesn't have an  
object
type to narrow it down, so which will it use - the first it finds  
maybe.


I'd have thought that in the case:

// id anonymous
float f = [anonymous position];

the compiler ought to assume that the method being used is the one
returning a float, or if not at least warn about an implicit cast  
from

CGPoint to float. Perhaps if it were -(int)position rather than
-(CGPoint)position, you might not expect a warning, but in that case
you would expect a cast, so it shouldn't break.

However, that does appear to be what is happening. In the absence of
any other explanation, I'd call it a compiler bug.

Hamish



___

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]

Re: App hangs when displaying any sheet in 10.5 [SOLVED]

[Brian Stern]

On Jun 5, 2008, at 11:26 AM, Graham Cox wrote:

OK, I found the culprit. As suspected, it has nothing to do with  
sheets.


I'm using a sorting function with NSMutableArray:

static int cmpColorStops (DKColorStop* lh, DKColorStop* rh, void  
*context)


In my original code, the sort function was declared:

static int cmpColorStops (id lh, id rh, void *context);

Which compiled just fine. Problem is that rp = [rh position]; was  
returning some utterly bogus value, because the assumption was an  
int(?) was being returned from the anonymous object type, not a  
float. Specifically typing the parameters to the sort function  
removes this ambiguity. As it turns out, the bogus values did sort  
correctly, because their relative values were in the right order,  
which is why I've never spotted this before. What I'm still not  
clear about is how this can cause memory corruption, because a float  
and an int are the same size. I'm also not sure why it was OK on  
Tiger (though possibly just due to chance layout differences in  
memory).


While float and int are the same size they are returned from functions  
in different registers (on both ppc and intel). If the calling  
function expects a float returned type but an int is returned instead  
the calling function will certainly get a bogus value. In addition it  
may save and restore the wrong registers and not save and restore a  
register that needs to be preserved, resulting in memory corruption.


The 'may not respond to selector' warning might be expected in cases  
like this.


Normally assigning a float to an int is perfectly legal so no warning  
should be generated on that account.  Perhaps if there were a warning  
indicating that two different return types are possible it might help  
in cases like this.



Further thought: could it be that in Tiger, no Cocoa objects declare  
a method called -position, so it correctly picked up my private  
object's method signature. In Leopard, both CALayer and  
NSPositionalSpecifier declare a -position method, so the compiler is  
assuming one of those for the anonymous objects. CALayer's version  
returns a CGPoint, which being larger than a float could explain the  
memory corruption?


I've actually run into almost the same bug before and it was equally  
hard to track down. It would be useful if there was a compiler  
warning for an implicit cast or mismatch of return type in cases  
like this, because otherwise they are devilishly hard to spot. If  
there is such a warning, please tell me, so I can spare myself  
future hunts of this kind (this one has taken a solid 11 hours to  
find and fix, primarily because cause and effect were completely  
unrelated!)


Thanks to everyone who pitched in - very grateful.

cheers, Graham



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSTableView

[Brian Stern]

On May 23, 2008, at 4:03 PM, john darnell wrote:


The code meant to be used in response for the requirement in the
Companion article to return the value of a given cell in the table  
looks

like this:


- (id) directoryTable: (NSTableView *) aTableView
objectValueForTableColumn:(NSTableColumn *) aTableColumn row: (int)
rowIndex


Your method name is wrong. The name of the datasource method must be:  
tableView:objectValueForTableColumn:row:


This is documented in the NSTableDataSource Protocol Reference and the  
Table View Programming Guide.



{
  NSLog(@"Row index is %d", rowIndex);

  NSString *file = [arrayOfFiles objectAtIndex:rowIndex];
  return [file self];
}



Your line return [file self] is odd.  Just: return file;

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: File's Owner

[Brian Stern]

On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:

I decided to once again go verbatim through Cocoa Fundamentals. So  
far it has been largely "uh-huh, yep", but the File's Owner, my  
nemesis, comes up again.


File's Owner is a title. It is similar, in a way, to the title:  
President of the United States. Every four years Americans elect the  
POTUS. The individual who is POTUS changes, the title remains the same.


Software development, in this case Cocoa, is not a democracy. You, the  
developer, are absolute dictator of your code. You, the developer,  
have the absolute power, and in fact the responsibility, to choose the  
object that is the File's Owner for each nib in your application.


Why must you do this? What is the point of this title of File's Owner?

Consider the nibs in your application. They contain a description of a  
UI with some number of views and other objects. When a nib is loaded  
into your application this description is turned into a view hierarchy  
of real objects, usually rooted in a NSWindow.


How can this newly created View hierarchy communicate with the rest of  
the application, and visa versa? The answer is outlets. Where are the  
outlets? In the File's Owner.


The object that has the outlets that are assigned to when the  nib is  
loaded can be of any kind. That's why the documentation calls File's  
Owner a proxy. It's also why you must tell IB the Class of the File's  
Owner for a given nib.  The File's Owner icon in the IB window is  
there so you can set the outlets and actions of it so that you can  
make the connections between the new objects in the nib and the  
already existing objects in the application. It's a representation, or  
a title, of the real object that owns the nib.



--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Loading a .nib?

[Brian Stern]

On May 2, 2008, at 7:33 PM, J. Todd Slack wrote:


Hi,

One question though.

When I use:

[NSBundle loadNibNamed:@"SettingsDialog" owner:self]; // the nib  
name is SettingsDialog.nib


Xcode complains that this is the first time that self is used.



You probably want to create an instance of a NSWindowController  
subclass and have it load the bundle.


Also, simply converting your .c to a .m doesn't turn your plugin into  
a friendly Cocoa host.  You probably need to call NSApplicationLoad(),  
create an NSAutoReleasePool and wrap your objective-C code in a @try  
block so exceptions don't propagate back through your C code and to  
the host app.


Isn't there some sample code for building Cocoa iTunes plugins  
available somewhere that will answer these questions for you?


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Tight loop processing

[Brian Stern]

On Apr 10, 2008, at 2:00 PM, Don Arnel wrote:
I've got a Cocoa application which runs a simulation loop 1000s of  
times. Of course, this prevents any user interaction with the rest  
of the program while the simulation is running. When I was  
programming for Windows there was a call in Visual Basic  
(app.DoEvents()) which would process any pending events. You could  
put DoEvents() inside long loops to prevent blocking user input.  Is  
there a similar way to handle this in Cocoa?


NSTimer may be a simple way to implement this.  Your code is called  
back by the timer at the specified interval.  Your code would probably  
run one iteration of the simulation at each callback.   User interface  
events would be processed between timer callbacks. Coding this is  
likely to be simpler than using threads.


http://developer.apple.com/documentation/Cocoa/Conceptual/Timers/Timers.html

--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Adding commandline batch mode to Cocoa app

[Brian Stern]

On Mar 23, 2008, at 4:43 AM, Carsten wrote:


Ah, okay, I see now. My script will just launch the application
executable with a specific commandline that forces it into batch mode,
so the difference in functionality or convenience between a symlink to
a tool and a generated one-liner script (plus some error handling for
a broken link) is probably too small to bother about the development
of the tool, I think.


And what will your app do if it is already running in non-batch mode  
when the user runs this script?


From the beginning "mode" has been a four letter word among Mac  
developers.


You could do worse than to follow Photoshop's model for this problem.   
Have a menu item that opens a dialog and allows the user to set up  
batch processing.  Make your app scriptable and allow the user to  
access the batch functionality from Applescript.


If you want to be fancy you can auto-generate applescripts that do  
whatever the user has done in the Batch window.  Photoshop has this  
functionality and it's called droplets.  (I don't know how they work  
actually but they appear to be applescripts or applescripts plus  
something else.)


Who is the target audience for your application?  If it at all  
includes "regular Mac users" then any solution that involves the  
Terminal and /usr/bin is not a good solution.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: fileExistsAtPath with * to indicate random

[Brian Stern]

On Mar 10, 2008, at 12:10 PM, Mr. Gecko wrote:


I'm needing my application to find out if ImageMagick is installed.


You should look at Launch Services.  This Carbon API will tell you the  
application that will open for a given document or kind of document.


"The Launch Services function LSFindApplicationForInfo locates an  
application based on its name, creator signature, bundle ID, or any  
combination of these characteristics."


Look at LSGetApplicationForInfo, LSFindApplicationForInfo,  
LSGetApplicationForURL and related APIs.


--
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/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]