Re: Can't drag a custom data object.

[Billy Flatman]

Hi Jens,

Thanks for your help. I've been trying to get the option 1 approach to work, 
but I don't know what I'm meant to do with my NSValue. I can't find how to 
convert it to an NSData type.

Thanks again,

Billy.

On 26 Apr 2010, at 15:46, Jens Alfke wrote:

> 
> On Apr 26, 2010, at 5:58 AM, Billy Flatman wrote:
> 
>> I'm trying to put a custom object into past board in order to perform a drag 
>> operation.
> 
> You can’t do that, for the same reason you can’t directly write a custom 
> object to a file. The pasteboard basically stores bytes, so it has to be able 
> to convert what you store in it to and from a stream of bytes. There are a 
> limited number of data types it understands — strings, numbers, arrays, 
> dictionaries and of course raw data.
> 
>>  ** This doesn't (actually stops drag and drop working for my 
>> application until I logout).
>>  [pboard setData:[items objectAtIndex:0] forType:kOutlineViewGroupType];
> 
> You’re passing the wrong type of object to the setData: parameter. Look at 
> the header or the docs — it takes an NSData. You’re passing it some other 
> custom object. The result is going to be an exception or a crash. (The reason 
> this doesn’t produce a warning at compile time is because -objectAtIndex: 
> just returns type id, which is compatible with anything (it’s like void* for 
> objects.) You have to pay attention to what type of object you know is in the 
> array.
> 
> If you want to put a custom object in the pasteboard, there are several ways:
> 
> (1) Wrap it in an NSValue via [NSValue valueWithPointer:]. This is kind of 
> dangerous because you have to make sure the object won’t get dealloced before 
> the pointer is eventually used, since -valueWithPointer: doesn’t retain the 
> object.
> (2) Store some value that refers to the object, like a row number or an 
> access key. You have to make sure that value will continue to work, i.e. the 
> row number remains correct.
> (3) Implement a way to serialize the object into data or a dictionary/array. 
> Implementing the NSCopying protocol is a standard way to do that.
> 
> The first two techniques are OK for drag-n-drop because the lifetime of the 
> pasteboard is limited. If you want to implement copy and paste you probably 
> need to go with #3 because the pasteboard could stay around for an arbitrary 
> amount of time.
> 
> —Jens

Billy Flatman
b.flat...@googlemail.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Can't drag a custom data object.

[Graham Cox]

On 27/04/2010, at 5:05 PM, Billy Flatman wrote:

> Hi Jens,
> 
> Thanks for your help. I've been trying to get the option 1 approach to work, 
> but I don't know what I'm meant to do with my NSValue. I can't find how to 
> convert it to an NSData type.


NSData* data = [NSKeyedArchiver archivedDataWithRootObject:myValue];

>> (3) Implement a way to serialize the object into data or a dictionary/array. 
>> Implementing the NSCopying protocol is a standard way to do that.


I think perhaps Jens meant SCoding, not NSCopying. If you have an object that 
you want to be able to cut/paste or drag, adopt the NSCoding protocol and 
archive it directly (as above, but don't bother with a NSValue).

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [iPhone] File coping application

[Thomas Engelmeier]

Am 26.04.2010 um 21:17 schrieb John Joyce:

>> For your personal pleasure: The iPhone is a MTP device, so you can use 
>> ImageCapture to copy "images" from / to your phone.
>> 
>> If you  don't want Stanza-like trouble and stay in the AppStore:  There is 
>> no official way.
>> 
>> HTH,
>>  Thomas
> Translation: 
> Though "possible", this is in direct violation of the agreement for the 
> iPhone OS SDK.
> 
> @Thomas,
> Correct as you are here, this potentially also could get you bonked off of 
> the mailing list.

If mentioning the iPhone implements the  _Multimedia_ Transfer Protocol (and 
not only the _Picture_ Transfer Protocol described in the 15470 standard) and 
it has a really good, brand new Cocoa counterpart with the new ImageCaptureCore 
in SnowLeopard brings me after nearly a decade on-list a ban, I've no problems 
with being not on this list - I'm here to discuss engineering topics, not to 
get a EULA lawyer for released, public APIs. 

To stay on topic:  I really recommend anyone to check out the new Snow Leopard 
IMageCaptureCore for dealing with MTP devices. My recommendation to test is 
using an iPhone and a cradle - attached 3rd party cameras usually suffer from a 
drastic battery drain so  you usually have to stop debugging after some hours 
(less than one hour for my DSLRs) for a recharging break. The testing drawback 
is the iPhone can not be remote controlled to take pictures (in contrary to 
most other PTP devices).

Regards,
TE




___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Paul Sanders]

> Um, actually the menu bar is on the primary display.  That's 
> the definition of the primary display
> -- it's the one with the menu bar.  Did you perhaps mean the 
> built-in display?

I was speaking from memory.  My recollection is that after I 
moved the menu bar the primary display, as reported by NSScreen, 
did not change.  But it was a while ago so I could be wrong and 
the docs agree with you.  This implies that the primary display 
can change at run time.

Paul Sanders. 



___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Paul Sanders]

> are you saying there is a way to set the min, max and value on 
> an
> nsscroller? sorry, not clear on that

Why do you need min and max anyway?  The current position is set 
as / returned as a float (or a double) between 0 and 1.  That 
represents the range of the scroller.  Interpret it however you 
like.

Paul Sanders.





___

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 arch...@mail-archive.com

Re: why doesn't the compiler complain?

[Paul Sanders]

> So I guess the compiler treats the *first* declaration of a 
> method
> name-and-signature that it encounters as the "real" one.
>
> Now, that's okay ...

Not really.  Without the warning flag it means that the type 
checking you would hope to get from the compiler is subverted. 
In your example it might let you pass an NSString to a method 
expecting an NSArray, which is likely to have unfortunate 
results.  Other, more insidious examples, are possible, 
including cases that could lead to a memory overwrite.  I think 
the fact that the warning is off by default is probably for 
historical reasons.  I'd like to see that changed. 
Unfortunately, setting it project-wide generates a warning 
(something like 'this flag pertains only to Objective-C') for .c 
and .cpp files, which is a bit of a pain, but one can probably 
set it with a #pragma.

Paul Sanders.



___

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 arch...@mail-archive.com

NewMovieFromDataRef crashes when QT movie URL is not found

[varaha murthy]

Hi,

I am trying to open a movie using the NewMovieFromDataRef api. But if the
movie URL is not found, I get a crash.
This is happening on OSX10.6.3. QT version 7.6.3. Following is the test app
that I tried. Is there any way/ api  to get around this crash ?.

#include 

#include 
#include 

int main (int argc, const char * argv[]) {
Movie  m = NULL;
Handle h = NULL;
short id = 0;
OSType outType;
short flags = newMovieActive;

EnterMovies();

OSErr err = QTNewDataReferenceFromURLCFString(CFSTR("
http://10.192.18.142/test.mov";),0,&h,&outType);
NewMovieFromDataRef(&m,flags,&id,h,outType) ;

ExitMovies();
return 0;
}
___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Bill Appleton]

you are right, that will work, thanks!





On Tue, Apr 27, 2010 at 2:57 AM, Paul Sanders wrote:

> > are you saying there is a way to set the min, max and value on
> > an
> > nsscroller? sorry, not clear on that
>
> Why do you need min and max anyway?  The current position is set
> as / returned as a float (or a double) between 0 and 1.  That
> represents the range of the scroller.  Interpret it however you
> like.
>
> Paul Sanders.
>
>
>
>
>
> ___
>
> 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/billappleton%40dreamfactory.com
>
> This email sent to billapple...@dreamfactory.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

menu madness with retain count

[Bill Appleton]

hi all,

i like to create some menus, set them as the main menu bar, then maybe
delete them, and create some more menus, use them, etc.

but i can't find any way to do this with cocoa

here is the problem

when you add a submenu (setSubMenu:forItem) the retain count on the submenu
goes up by one

but when you delete that item, or set its submenu to nil, the retain count
does not change

if you ever delete a menu that has a submenu you will get a crash, but there
is no way to unassociate the menu and the submenu

another problem: when you set the main menu bar  [NSApp setMainMenu:themenu]
the retain count on themenu goes up by a lot, i can't predict it, but maybe
4 or 5

if you set the main menu bar to nil the retain count does not change on the
original main menu

so given all this, i can't find a way to create and delete menus without
crashes or memory leaks

am i doing something wrong?



thanks

bill appleton
___

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 arch...@mail-archive.com

Re: Make About window respond to ⌘W in UI-le ss application

[Michael Dippery]

> Don't why it's not working for you.  My LSUIElement app similarly has no menu 
> bar or dock icon, but it's various ancillory windows (About plain vanilla 
> version, Preferences) respond to key board short cuts which are set in the 
> main menu nib.  I have done no special hacks to achieve this, it Just Works™.
> 
> Does your app have a MainMenu nib file?

Perhaps this is why it isn't working: I do have a MainMenu nib, but I have long 
since deleted the MainMenu object in MainMenu.nib. I tried to add a new menu 
with a Close option that responds to the appropriate keyboard shortcut, but I'm 
not sure how make that the "main" menu. Maybe that's the issue?




Michael Dippery
mdipp...@gmail.com | www.monkey-robot.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Keary Suska]

On Apr 27, 2010, at 7:46 AM, Bill Appleton wrote:

> i like to create some menus, set them as the main menu bar, then maybe
> delete them, and create some more menus, use them, etc.
> 
> but i can't find any way to do this with cocoa
> 
> here is the problem
> 
> when you add a submenu (setSubMenu:forItem) the retain count on the submenu
> goes up by one
> 
> but when you delete that item, or set its submenu to nil, the retain count
> does not change
> 
> if you ever delete a menu that has a submenu you will get a crash, but there
> is no way to unassociate the menu and the submenu
> 
> another problem: when you set the main menu bar  [NSApp setMainMenu:themenu]
> the retain count on themenu goes up by a lot, i can't predict it, but maybe
> 4 or 5
> 
> if you set the main menu bar to nil the retain count does not change on the
> original main menu
> 
> so given all this, i can't find a way to create and delete menus without
> crashes or memory leaks
> 
> am i doing something wrong?

Don't pay attention to retain counts. They rarely indicate anything useful. For 
instance, in your first case, how do you know that the menu hasn't autoreleased 
the submenu? -autorelease does not decrement the retain count, but promises 
release later on. Check after the runloop has run--you may see different 
results.

As far as crashing when removing a menu with a submenu, that shouldn't happen. 
Chances are, it is your code that is causing the crash (I say this from 
personal experience). Otherwise it is one nasty bug.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Graham Cox]

Bill, you need to learn about the concept of object ownership within Cocoa. 
Ownership is the model for memory management, retain count merely an 
implementation detail which can tell you nothing useful.

Menus own their submenus, so if you delete a menu with submenus, you don't need 
to also delete those submenus yourself. Chances are you are over-releasing them 
so when the parent menu is deleted, the submenu is no longer there and hence 
you get a crash.

You simply can't work with Cocoa without having a good solid understanding of 
memory management and particularly the concept of ownership. It's different 
from Carbon and different from C++ and so on. Your subject title is apt - using 
retain counts in an attempt to debug faulty memory management is the path to 
madness.

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

--Graham




On 27/04/2010, at 11:46 PM, Bill Appleton wrote:

> hi all,
> 
> i like to create some menus, set them as the main menu bar, then maybe
> delete them, and create some more menus, use them, etc.
> 
> but i can't find any way to do this with cocoa
> 
> here is the problem
> 
> when you add a submenu (setSubMenu:forItem) the retain count on the submenu
> goes up by one
> 
> but when you delete that item, or set its submenu to nil, the retain count
> does not change
> 
> if you ever delete a menu that has a submenu you will get a crash, but there
> is no way to unassociate the menu and the submenu
> 
> another problem: when you set the main menu bar  [NSApp setMainMenu:themenu]
> the retain count on themenu goes up by a lot, i can't predict it, but maybe
> 4 or 5
> 
> if you set the main menu bar to nil the retain count does not change on the
> original main menu
> 
> so given all this, i can't find a way to create and delete menus without
> crashes or memory leaks
> 
> am i doing something wrong?
> 
> 
> 
> thanks
> 
> bill appleton
> ___
> 
> 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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Make About window respond to ⌘W in UI-le ss application

[Ron Fleckner]

On 27/04/2010, at 11:49 PM, Michael Dippery wrote:

Don't why it's not working for you.  My LSUIElement app similarly  
has no menu bar or dock icon, but it's various ancillory windows  
(About plain vanilla version, Preferences) respond to key board  
short cuts which are set in the main menu nib.  I have done no  
special hacks to achieve this, it Just Works™.


Does your app have a MainMenu nib file?


Perhaps this is why it isn't working: I do have a MainMenu nib, but  
I have long since deleted the MainMenu object in MainMenu.nib. I  
tried to add a new menu with a Close option that responds to the  
appropriate keyboard shortcut, but I'm not sure how make that the  
"main" menu. Maybe that's the issue?




I think all you would have to do, if you have a nib named MainMenu.nib  
in your project, is to create a menu in it and give it whatever titles  
with shortcuts you want.  That menu will never be seen (because your  
app is LSUIElement == 1) but the short cuts will still work -- when  
your app has focus or is frontmost.


Ron

___

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 arch...@mail-archive.com

Re: Make About window respond to ⌘W in UI-le ss application

[Ron Fleckner]

On 27/04/2010, at 11:49 PM, Michael Dippery wrote:

Don't why it's not working for you.  My LSUIElement app similarly  
has no menu bar or dock icon, but it's various ancillory windows  
(About plain vanilla version, Preferences) respond to key board  
short cuts which are set in the main menu nib.  I have done no  
special hacks to achieve this, it Just Works™.


Does your app have a MainMenu nib file?


Perhaps this is why it isn't working: I do have a MainMenu nib, but  
I have long since deleted the MainMenu object in MainMenu.nib. I  
tried to add a new menu with a Close option that responds to the  
appropriate keyboard shortcut, but I'm not sure how make that the  
"main" menu. Maybe that's the issue?




I think all you would have to do, if you have a nib named MainMenu.nib  
in your project, is to create a menu in it and give it whatever titles  
with shortcuts you want.  That menu will never be seen (because your  
app is LSUIElement == 1) but the short cuts will still work -- when  
your app has focus or is frontmost.


Ron

Sorry, didn't read your email properly.  If you've already created a  
menu in your MainMenu nib and it's not working, perhaps you haven't  
actually made the connection in the nib.  If that's the case, then you  
just need to Control-drag from your Close menu item to the First  
Responder in the nib and connect it to the close: action.  If you've  
already done that and it still doesn't work then I'm lost.



___

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 arch...@mail-archive.com

Re: NewMovieFromDataRef crashes when QT movie URL is not found

[Fritz Anderson]

On 27 Apr 2010, at 7:12 AM, varaha murthy wrote:

> I am trying to open a movie using the NewMovieFromDataRef api. But if the
> movie URL is not found, I get a crash.
> This is happening on OSX10.6.3. QT version 7.6.3. Following is the test app
> that I tried. Is there any way/ api  to get around this crash ?.
...
>OSErr err = QTNewDataReferenceFromURLCFString(CFSTR("
> http://10.192.18.142/test.mov";),0,&h,&outType);
>NewMovieFromDataRef(&m,flags,&id,h,outType) ;

It has been more than 5 years (thank God) since I've had to deal with the 
QuickTime C API, so my question may be ignorant...

You collect the error return from QTNewDataReferenceFromURLCFString(), but you 
don't check the error, or any of the return values. What happens when you do?

In any event, this is a mailing list for discussion of development with the 
Cocoa application frameworks. The Quicktime-API list deals with the C API for 
QuickTime. All anyone here can do is read the documentation (which is 
appallingly bad, at least as supplied with Xcode 3.2) for you.

— F



___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Michael Ash]

On Tue, Apr 27, 2010 at 5:53 AM, Paul Sanders
 wrote:
>> Um, actually the menu bar is on the primary display.  That's
>> the definition of the primary display
>> -- it's the one with the menu bar.  Did you perhaps mean the
>> built-in display?
>
> I was speaking from memory.  My recollection is that after I
> moved the menu bar the primary display, as reported by NSScreen,
> did not change.  But it was a while ago so I could be wrong and
> the docs agree with you.  This implies that the primary display
> can change at run time.

NSScreen does not define the concept of the "primary" screen.

Perhaps you were thinking of +mainScreen? That one is defined as the
screen which contains the key window. Not a very useful definition for
most purposes, but there you are.

Mike
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Bill Appleton]

hi all,

i have read the memory rules a few times now, so does this sound right?

1) after i append an item i have created to a menu i have created, and i
don't want to own the menu item any more, i should release the item so that
the menu owns it

2) when i add a submenu i have created to a menu i have created, and i don't
want to own the submenu any more, i should release the submenu so that the
menu owns it

3) when i set the menus i have created for NSApp using setMainMenu then...
what? who owns them? how do i set more menus for NSApp? how do i get NSApp
to release the current set?


thanks,

bill






On Tue, Apr 27, 2010 at 7:12 AM, Graham Cox  wrote:

> Bill, you need to learn about the concept of object ownership within Cocoa.
> Ownership is the model for memory management, retain count merely an
> implementation detail which can tell you nothing useful.
>
> Menus own their submenus, so if you delete a menu with submenus, you don't
> need to also delete those submenus yourself. Chances are you are
> over-releasing them so when the parent menu is deleted, the submenu is no
> longer there and hence you get a crash.
>
> You simply can't work with Cocoa without having a good solid understanding
> of memory management and particularly the concept of ownership. It's
> different from Carbon and different from C++ and so on. Your subject title
> is apt - using retain counts in an attempt to debug faulty memory management
> is the path to madness.
>
>
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
>
> --Graham
>
>
>
>
> On 27/04/2010, at 11:46 PM, Bill Appleton wrote:
>
> > hi all,
> >
> > i like to create some menus, set them as the main menu bar, then maybe
> > delete them, and create some more menus, use them, etc.
> >
> > but i can't find any way to do this with cocoa
> >
> > here is the problem
> >
> > when you add a submenu (setSubMenu:forItem) the retain count on the
> submenu
> > goes up by one
> >
> > but when you delete that item, or set its submenu to nil, the retain
> count
> > does not change
> >
> > if you ever delete a menu that has a submenu you will get a crash, but
> there
> > is no way to unassociate the menu and the submenu
> >
> > another problem: when you set the main menu bar  [NSApp
> setMainMenu:themenu]
> > the retain count on themenu goes up by a lot, i can't predict it, but
> maybe
> > 4 or 5
> >
> > if you set the main menu bar to nil the retain count does not change on
> the
> > original main menu
> >
> > so given all this, i can't find a way to create and delete menus without
> > crashes or memory leaks
> >
> > am i doing something wrong?
> >
> >
> >
> > thanks
> >
> > bill appleton
> > ___
> >
> > 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/graham.cox%40bigpond.com
> >
> > This email sent to graham@bigpond.com
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSApplicationMain question

[Thomas Clement]

On Apr 27, 2010, at 4:48 PM, Michael Ash wrote:


On Tue, Apr 27, 2010 at 5:53 AM, Paul Sanders
 wrote:

Um, actually the menu bar is on the primary display.  That's
the definition of the primary display
-- it's the one with the menu bar.  Did you perhaps mean the
built-in display?


I was speaking from memory.  My recollection is that after I
moved the menu bar the primary display, as reported by NSScreen,
did not change.  But it was a while ago so I could be wrong and
the docs agree with you.  This implies that the primary display
can change at run time.


NSScreen does not define the concept of the "primary" screen.


From the documentation of the NSScreen class:

+ (NSArray *)screens

The screen at index 0 in the returned array corresponds to the primary  
screen of the user’s system. This is the screen that contains the menu  
bar and whose origin is at the point (0, 0).



I would suggest to the OP to look directly at the documentation.


Thomas___

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 arch...@mail-archive.com

Fastest way to check for descendants of an object

[Keith Blount]

Hello,

I have a model object that represents a single node in a tree (it can be used 
in an NSOutlineView for instance). As such, it has a "children" NSMutableArray 
iVar which can store other objects of the same class, which in turn may have 
their own children.

E.g:

@interface MyNode : NSObject
{
   NSMutableArray *children;
}
@end

Whereby "children" would contain instances of MyNode which in turn have 
"children" that may contain other instances of MyNode (obviously the above is 
just a grossly simplified version of my actual class which does much more).

There are occasions when I need to check if one node object is the descendant 
of another node object. My current code for this is as follows:

- (BOOL)isDescendantOfOrOneOfNodes:(NSArray*)nodes
{
// Returns YES if we are contained anywhere inside the array passed in, 
including inside sub-nodes.
NSEnumerator *enumerator = [nodes objectEnumerator];
id node = nil;
while (node = [enumerator nextObject])
{
if (node == self) return YES;  // Found ourself
// Check all sub-nodes
if ([[node children] count] > 0)
{
if([selfisDescendantOfOrOneOfNodes:[node children]])
returnYES;
}
}
// Didn't find self inside any of the nodes passed in
returnNO;
}

- (BOOL)isDescendantOfNodes:(NSArray*)nodes
{
// Returns YES if any node in the array passed in is an ancestor of ours.
NSEnumerator *enumerator = [nodes objectEnumerator];
id node = nil;
while (node = [enumerator nextObject])
{
// Note that the only difference between this and 
isAnywhereInsideChildrenOfNodes: is that we don't check
// to see if we are actually one of the items in the array passed in, 
only if we are one of their descendants.
// Check sub-nodes
if ([[node children] count] > 0)
{
if([selfisDescendantOfOrOneOfNodes:[node children]])
returnYES;
}
}
 
// Didn't find self inside any of the nodes passed in
returnNO;
}

So, in use, e.g:

if ([firstNode isDescendantOfOneOfNodes:[NSArray arrayWithObject:secondNode]])
// ... do something (e.g. prevent secondNode from being added as a child of 
firstNode).


My question is simply, is there a faster way of doing this? There are occasions 
when I need to run through and check potentially thousands of nodes each with 
thousands of descendants, and in this situation these checks can be quite 
time-consuming and slow things down. I know 10.5 introduced fast enumeration 
(e.g. "for (id node in nodes)"), and the only reason I'm not using that is that 
I need to support 10.4 too (I tested it and fast enumeration does speed things 
up a little, but not as much as I need at the volumes I'm talking about). So 
I'm just wondering if there is anything in the above that can be optimised to 
be faster. If not, I probably just need to re-examine where I'm calling these 
methods again, but I figured I'd start with first principles and initially 
check to see if there is any obvious quicker way of checking that an object is 
a descendant of another in the above situation that I might be missing.

Thanks and all the best,
Keith


  
___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Mike Abdullah]

Generally, you make MyNode also hold a weak reference to its parent node. (see 
NSTreeNode/NSView for example)

Then, when testing a node, can quickly recurse up the tree looking for a 
desired ancestor.

On 27 Apr 2010, at 16:33, Keith Blount wrote:

> Hello,
> 
> I have a model object that represents a single node in a tree (it can be used 
> in an NSOutlineView for instance). As such, it has a "children" 
> NSMutableArray iVar which can store other objects of the same class, which in 
> turn may have their own children.
> 
> E.g:
> 
> @interface MyNode : NSObject
> {
>   NSMutableArray *children;
> }
> @end
> 
> Whereby "children" would contain instances of MyNode which in turn have 
> "children" that may contain other instances of MyNode (obviously the above is 
> just a grossly simplified version of my actual class which does much more).
> 
> There are occasions when I need to check if one node object is the descendant 
> of another node object. My current code for this is as follows:
> 
> - (BOOL)isDescendantOfOrOneOfNodes:(NSArray*)nodes
> {
>// Returns YES if we are contained anywhere inside the array passed in, 
> including inside sub-nodes.
>NSEnumerator *enumerator = [nodes objectEnumerator];
>id node = nil;
>while (node = [enumerator nextObject])
>{
>if (node == self) return YES;  // Found ourself
>// Check all sub-nodes
>if ([[node children] count] > 0)
>{
>if([selfisDescendantOfOrOneOfNodes:[node children]])
>returnYES;
>}
>}
>// Didn't find self inside any of the nodes passed in
>returnNO;
> }
> 
> - (BOOL)isDescendantOfNodes:(NSArray*)nodes
> {
>// Returns YES if any node in the array passed in is an ancestor of ours.
>NSEnumerator *enumerator = [nodes objectEnumerator];
>id node = nil;
>while (node = [enumerator nextObject])
>{
>// Note that the only difference between this and 
> isAnywhereInsideChildrenOfNodes: is that we don't check
>// to see if we are actually one of the items in the array passed in, 
> only if we are one of their descendants.
>// Check sub-nodes
>if ([[node children] count] > 0)
>{
>if([selfisDescendantOfOrOneOfNodes:[node children]])
>returnYES;
>}
>}
> 
>// Didn't find self inside any of the nodes passed in
>returnNO;
> }
> 
> So, in use, e.g:
> 
> if ([firstNode isDescendantOfOneOfNodes:[NSArray arrayWithObject:secondNode]])
>// ... do something (e.g. prevent secondNode from being added as a child 
> of firstNode).
> 
> 
> My question is simply, is there a faster way of doing this? There are 
> occasions when I need to run through and check potentially thousands of nodes 
> each with thousands of descendants, and in this situation these checks can be 
> quite time-consuming and slow things down. I know 10.5 introduced fast 
> enumeration (e.g. "for (id node in nodes)"), and the only reason I'm not 
> using that is that I need to support 10.4 too (I tested it and fast 
> enumeration does speed things up a little, but not as much as I need at the 
> volumes I'm talking about). So I'm just wondering if there is anything in the 
> above that can be optimised to be faster. If not, I probably just need to 
> re-examine where I'm calling these methods again, but I figured I'd start 
> with first principles and initially check to see if there is any obvious 
> quicker way of checking that an object is a descendant of another in the 
> above situation that I might be missing.
> 
> Thanks and all the best,
> Keith
> 
> 
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net

___

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 arch...@mail-archive.com

Re: why doesn't the compiler complain?

[Matt Neuburg]

On or about 4/26/10 1:22 PM, thus spake "Greg Parker" :

> The compiler warns more aggressively for mismatches that do affect the call
> site's code. Those are more likely to be actual bugs, rather than correct but
> loosely-typed code. For example, if you change your example's parameter types
> to NSString* vs int, you'll get the warning even without any extra warning
> flags.

Just to clarify: you get the warning, but only when you try to *call* the
method that has multiple definitions (and then only when using dynamic
typing, of course).

In other words, this code by itself does not generate any warning:

@interface MyClass : NSObject {
}
- (void) tryme: (NSString*) s;
@end

@implementation MyClass
- (void) tryme: (NSString*) s {
;
}
@end
@interface MyClass2 : NSObject {
}
- (void) tryme: (int) s;
@end
@implementation MyClass2
- (void) tryme: (int) s {
;
}
@end

I guess I was hoping and expecting that the above would be sufficient to
generate a warning ("hey, you've defined methods with the same name but
different signatures; this could lead to trouble"). But the compiler is
silent. 

I see now, however, *why* the compiler is silent: it's because it weren't,
it would be too chatty. I turned on -Wselector and got 114 warnings... :)

m.

-- 
matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, 2nd edition
http://www.tidbits.com/matt/default.html#applescriptthings
Take Control of Exploring & Customizing Snow Leopard
http://tinyurl.com/kufyy8
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Fritz Anderson]

On 27 Apr 2010, at 10:28 AM, Bill Appleton wrote:

> 1) after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it
> 
> 2) when i add a submenu i have created to a menu i have created, and i don't
> want to own the submenu any more, i should release the submenu so that the
> menu owns it
> 
> 3) when i set the menus i have created for NSApp using setMainMenu then...
> what? who owns them? how do i set more menus for NSApp? how do i get NSApp
> to release the current set?

The "ownership" metaphor has this defect: It's not like property, which has 
only one owner at a time. The concept is, instead, "I need to keep a claim on 
this object, so it doesn't go away without my saying I'm done with it."

So -release doesn't _give_ ownership of the object to anything else. The 
"anything else" uses -retain or creation to _take_ ownership (maybe think of it 
as "responsibility") for the object if it is interested in it.

— F

___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Keith Blount]

Many thanks for the reply, much appreciated. That makes sense - the only (or 
rather difficulty) is ensuring the node always has an up-to-date reference to 
its parent given the number of scenarios in which it could change (for 
instance, if a node is copied etc).
Thanks again,
Keith




From: Mike Abdullah 
To: Keith Blount 
Cc: cocoa-dev@lists.apple.com
Sent: Tue, April 27, 2010 4:50:41 PM
Subject: Re: Fastest way to check for descendants of an object

Generally, you make MyNode also hold a weak reference to its parent node. (see 
NSTreeNode/NSView for example)

Then, when testing a node, can quickly recurse up the tree looking for a 
desired ancestor.


On 27 Apr 2010, at 16:33, Keith Blount wrote:

Hello,
>
>I have a model object that represents a single node in a tree (it can be used 
>in an NSOutlineView for instance). As such, it has a "children" NSMutableArray 
>iVar which can store other objects of the same class, which in turn may have 
>their own children.
>
>E.g:
>
>@interface MyNode : NSObject
>{
>  NSMutableArray *children;
>}
>@end
>
>Whereby "children" would contain instances of MyNode which in turn have 
>"children" that may contain other instances of MyNode (obviously the above is 
>just a grossly simplified version of my actual class which does much more).
>
>There are occasions when I need to check if one node object is the descendant 
>of another node object. My current code for this is as follows:
>
>- (BOOL)isDescendantOfOrOneOfNodes:(NSArray*)nodes
>{
>   // Returns YES if we are contained anywhere inside the array passed in, 
> including inside sub-nodes.
>   NSEnumerator *enumerator = [nodes objectEnumerator];
>   id node = nil;
>   while (node = [enumerator nextObject])
>   {
>   if (node == self) return YES;  // Found ourself
>   // Check all sub-nodes
>   if ([[node children] count] > 0)
>   {
>   if([selfisDescendantOfOrOneOfNodes:[node children]])
>   returnYES;
>   }
>   }
>   // Didn't find self inside any of the nodes passed in
>   returnNO;
>}
>
>- (BOOL)isDescendantOfNodes:(NSArray*)nodes
>{
>   // Returns YES if any node in the array passed in is an ancestor of ours.
>   NSEnumerator *enumerator = [nodes objectEnumerator];
>   id node = nil;
>   while (node = [enumerator nextObject])
>   {
>   // Note that the only difference between this and 
> isAnywhereInsideChildrenOfNodes: is that we don't check
>   // to see if we are actually one of the items in the array passed in, 
> only if we are one of their descendants.
>   // Check sub-nodes
>   if ([[node children] count] > 0)
>   {
>   if([selfisDescendantOfOrOneOfNodes:[node children]])
>   returnYES;
>   }
>   }
>
>   // Didn't find self inside any of the nodes passed in
>   returnNO;
>}
>
>So, in use, e.g:
>
>if ([firstNode isDescendantOfOneOfNodes:[NSArray arrayWithObject:secondNode]])
>   // ... do something (e.g. prevent secondNode from being added as a child of 
> firstNode).
>
>
>My question is simply, is there a faster way of doing this? There are 
>occasions when I need to run through and check potentially thousands of nodes 
>each with thousands of descendants, and in this situation these checks can be 
>quite time-consuming and slow things down. I know 10.5 introduced fast 
>enumeration (e.g. "for (id node in nodes)"), and the only reason I'm not using 
>that is that I need to support 10.4 too (I tested it and fast enumeration does 
>speed things up a little, but not as much as I need at the volumes I'm talking 
>about). So I'm just wondering if there is anything in the above that can be 
>optimised to be faster. If not, I probably just need to re-examine where I'm 
>calling these methods again, but I figured I'd start with first principles and 
>initially check to see if there is any obvious quicker way of checking that an 
>object is a descendant of another in the above situation that I might be 
>missing.
>
>Thanks and all the best,
>Keith
>
>
>
>___
>
>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/cocoadev%40mikeabdullah.net
>
>This email sent to cocoa...@mikeabdullah.net
>



  
___

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 arch...@mail-archive.com

Re: why doesn't the compiler complain?

[Joanna Carter]

Hi Matt

> I see now, however, *why* the compiler is silent: it's because it weren't,
> it would be too chatty. I turned on -Wselector and got 114 warnings... :)

You too eh? Wow, was that a surprise - my tutorial project gave me 3679!!!

Joanna

--
Joanna Carter
Carter Consulting
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Scott Ribe]

On Apr 27, 2010, at 9:28 AM, Bill Appleton wrote:

> after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it

Probably not, but it depends on how you created it. If you created it with a 
convenience method, then you don't own it and don't need to release it (unless 
you retained it). If you created it via [[... alloc] init...] then you own it 
and need to release it.

> when i add a submenu i have created to a menu i have created, and i don't
> want to own the submenu any more, i should release the submenu so that the
> menu owns it

Same answer as above.

> when i set the menus i have created for NSApp using setMainMenu then...
> what? who owns them? how do i set more menus for NSApp? how do i get NSApp
> to release the current set?

Presumably, NSApp will take ownership of the menu when you set the main menu, 
and give up ownership of the prior main menu. Menus in turn own their items.

Now, given the first two answers, maybe this will start to make more sense:


 
-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Quincey Morris]

On Apr 27, 2010, at 09:39, Keith Blount wrote:

> Many thanks for the reply, much appreciated. That makes sense - the only (or 
> rather difficulty) is ensuring the node always has an up-to-date reference to 
> its parent given the number of scenarios in which it could change (for 
> instance, if a node is copied etc).

Take a look at NSTreeNode to give you the tree structure with no work on your 
part. You could either use its representedObject property to hold a pointer to 
your MyNode objects (having removed their own parent/child properties), or 
subclass NSTreeNode as MyNode.

One extra advantage of using NSTreeNode is that it's already properly KVO 
compliant, which is important if you're going to bind an outline view to your 
tree. Was your home-grown implementation already KVO compliant? :)


___

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 arch...@mail-archive.com

Re: white screen windows at first

[vincent habchi]

Le 26 avr. 2010 à 23:35, Bill Appleton a écrit :

> hi all,
> 
> when my windows are first shown there is no drawing inside, they are white
> 
> but when i slowly move the mouse over to the close box and the close box
> responds to the mouse hover suddenly they draw their content properly
> 
> does this ring any bells with people? i'm not sure where to look in the docs
> for this one

Darn, I got that kind of behavior with my CALayers a while ago. They would not 
draw unless I moved the layers or zoomed on them. Did you try to look at 
background properties? Are your views layer backed?

Vincent___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Mike Abdullah]

Well that's pretty easy if you're writing proper accessor methods like:

- (NSArray *)children;
- (void)insertObject:(MyNode *)node inChildrenAtIndex:(NSUInteger)index;
- (void)removeObjectFromChildrenAtIndex:(NSUInteger)index;

Just call -setParent: or similar in the implementation.

On 27 Apr 2010, at 17:39, Keith Blount wrote:

> Many thanks for the reply, much appreciated. That makes sense - the only (or 
> rather difficulty) is ensuring the node always has an up-to-date reference to 
> its parent given the number of scenarios in which it could change (for 
> instance, if a node is copied etc).
> Thanks again,
> Keith
> 
> From: Mike Abdullah 
> To: Keith Blount 
> Cc: cocoa-dev@lists.apple.com
> Sent: Tue, April 27, 2010 4:50:41 PM
> Subject: Re: Fastest way to check for descendants of an object
> 
> Generally, you make MyNode also hold a weak reference to its parent node. 
> (see NSTreeNode/NSView for example)
> 
> Then, when testing a node, can quickly recurse up the tree looking for a 
> desired ancestor.
> 
> On 27 Apr 2010, at 16:33, Keith Blount wrote:
> 
>> Hello,
>> 
>> I have a model object that represents a single node in a tree (it can be 
>> used in an NSOutlineView for instance). As such, it has a "children" 
>> NSMutableArray iVar which can store other objects of the same class, which 
>> in turn may have their own children.
>> 
>> E.g:
>> 
>> @interface MyNode : NSObject
>> {
>>   NSMutableArray *children;
>> }
>> @end
>> 
>> Whereby "children" would contain instances of MyNode which in turn have 
>> "children" that may contain other instances of MyNode (obviously the above 
>> is just a grossly simplified version of my actual class which does much 
>> more).
>> 
>> There are occasions when I need to check if one node object is the 
>> descendant of another node object. My current code for this is as follows:
>> 
>> - (BOOL)isDescendantOfOrOneOfNodes:(NSArray*)nodes
>> {
>>// Returns YES if we are contained anywhere inside the array passed in, 
>> including inside sub-nodes.
>>NSEnumerator *enumerator = [nodes objectEnumerator];
>>id node = nil;
>>while (node = [enumerator nextObject])
>>{
>>if (node == self) return YES;  // Found ourself
>>// Check all sub-nodes
>>if ([[node children] count] > 0)
>>{
>>if([selfisDescendantOfOrOneOfNodes:[node children]])
>>returnYES;
>>}
>>}
>>// Didn't find self inside any of the nodes passed in
>>returnNO;
>> }
>> 
>> - (BOOL)isDescendantOfNodes:(NSArray*)nodes
>> {
>>// Returns YES if any node in the array passed in is an ancestor of ours.
>>NSEnumerator *enumerator = [nodes objectEnumerator];
>>id node = nil;
>>while (node = [enumerator nextObject])
>>{
>>// Note that the only difference between this and 
>> isAnywhereInsideChildrenOfNodes: is that we don't check
>>// to see if we are actually one of the items in the array passed in, 
>> only if we are one of their descendants.
>>// Check sub-nodes
>>if ([[node children] count] > 0)
>>{
>>if([selfisDescendantOfOrOneOfNodes:[node children]])
>>returnYES;
>>}
>>}
>> 
>>// Didn't find self inside any of the nodes passed in
>>returnNO;
>> }
>> 
>> So, in use, e.g:
>> 
>> if ([firstNode isDescendantOfOneOfNodes:[NSArray 
>> arrayWithObject:secondNode]])
>>// ... do something (e.g. prevent secondNode from being added as a child 
>> of firstNode).
>> 
>> 
>> My question is simply, is there a faster way of doing this? There are 
>> occasions when I need to run through and check potentially thousands of 
>> nodes each with thousands of descendants, and in this situation these checks 
>> can be quite time-consuming and slow things down. I know 10.5 introduced 
>> fast enumeration (e.g. "for (id node in nodes)"), and the only reason I'm 
>> not using that is that I need to support 10.4 too (I tested it and fast 
>> enumeration does speed things up a little, but not as much as I need at the 
>> volumes I'm talking about). So I'm just wondering if there is anything in 
>> the above that can be optimised to be faster. If not, I probably just need 
>> to re-examine where I'm calling these methods again, but I figured I'd start 
>> with first principles and initially check to see if there is any obvious 
>> quicker way of checking that an object is a descendant of another in the 
>> above situation that I might be missing.
>> 
>> Thanks and all the best,
>> Keith
>> 
>> 
>> 
>> ___
>> 
>> 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/cocoadev%40mikeabdullah.net
>> 
>> This email sent to cocoa...@mikeabdullah.net
> 
> 
>

Re: Creating temporary NSManagedObjects

[vincent habchi]

Quincey,

> Notwithstanding the discussion in this thread so far, I don't quite 
> understand why you wouldn't do this the easy way: create a NSManagedObject in 
> your managed context, and delete it when you're done with it.
> 
> The documentation explicitly describes the managed context as a "scratch 
> pad", where objects can come and go as you need them.

There is a simple reason: the objects in the Managed object context get 
"represented" on a third window, whose contents are drawn from an Entity mode 
NSArrayController that prepares its contents automatically. If I add my 
temporary object to the MOC, it automatically gets fetched and displayed in 
that window the very moment it is inserted; that's what I wanted to avoid 
because it is confusing and thus undesirable.

Vincent


___

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 arch...@mail-archive.com

Re: Creating temporary NSManagedObjects

[Joanna Carter]

Hi Vincent

> There is a simple reason: the objects in the Managed object context get 
> "represented" on a third window, whose contents are drawn from an Entity mode 
> NSArrayController that prepares its contents automatically. If I add my 
> temporary object to the MOC, it automatically gets fetched and displayed in 
> that window the very moment it is inserted; that's what I wanted to avoid 
> because it is confusing and thus undesirable.

Which is why I use the dictionary approach. It allows me to represent the 
single object, with all its relationships fetched from the MOC, without 
affecting the display of any other array controllers.

I have a tutorial that uses this approach. Would it help if I sent it to you?

Joanna

--
Joanna Carter
Carter Consulting

___

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 arch...@mail-archive.com

UIScrollView Sizing

[Bob Barnes]

   Hi,

 I have a UIScrollView that can contain a variable number of other UIViews 
(UILabels, UIImageViews, etc), but I'm confused as to how to manage the 
UIScrollView contentSize given the variability in the number of views it will 
contain. I'd like to use IB to create my view, but is this type of view better 
suiting to being built programmatically? UIScrollViews with variable content 
seems like a rather common paradigm and I'm wondering how folks approach this 
type of UI. 

thanks,

Bob___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Keith Blount]

Indeed, I believe that's my problem - currently when I add objects to my 
children array I do things such as [[myNode children] addObject:newNode], 
meaning I have nowhere to catch it. I'll update my code to add some accessors 
as you suggest, and change my - (NSMutableArray *)children accessor to - 
(NSArray *)children so that the compiler can catch any slips where I try to 
manipulate it directly. Regarding the weak reference to the parent, I guess I 
don't need to worry about that getting released because if it is, then so will 
the children be, or else by then they will refer to a different parent object.
Thank you!




From: Mike Abdullah 
To: Keith Blount 
Cc: cocoa-dev@lists.apple.com
Sent: Tue, April 27, 2010 6:37:25 PM
Subject: Re: Fastest way to check for descendants of an object

Well that's pretty easy if you're writing proper accessor methods like:

- (NSArray *)children;
- (void)insertObject:(MyNode *)node inChildrenAtIndex:(NSUInteger)index;
- (void)removeObjectFromChildrenAtIndex:(NSUInteger)index;

Just call -setParent: or similar in the implementation.


On 27 Apr 2010, at 17:39, Keith Blount wrote:

Many thanks for the reply, much appreciated. That makes sense - the only (or 
rather difficulty) is ensuring the node always has an up-to-date reference to 
its parent given the number of scenarios in which it could change (for 
instance, if a node is copied etc).
>Thanks again,
>Keith
>
>
>

From: Mike Abdullah 
>To: Keith Blount 
>Cc: cocoa-dev@lists.apple.com
>Sent: Tue, April 27, 2010 4:50:41 PM
>Subject: Re: Fastest way to check for descendants of an object
>
>Generally, you make MyNode also hold a weak reference to its parent node. (see 
>NSTreeNode/NSView for example)
>
>
>Then, when testing a node, can quickly recurse up the tree looking for a 
>desired ancestor.
>
>
>On 27 Apr 2010, at 16:33, Keith Blount wrote:
>
>Hello,
>>
>>I have a model object that represents a single node in a tree (it can be used 
>>in an NSOutlineView for instance). As such, it has a "children" 
>>NSMutableArray iVar which can store other objects of the same class, which in 
>>turn may have their own children.
>>
>>E.g:
>>
>>@interface MyNode : NSObject
>>{
>>  NSMutableArray *children;
>>}
>>@end
>>
>>Whereby "children" would contain instances of MyNode which in turn have 
>>"children" that may contain other instances of MyNode (obviously the above is 
>>just a grossly simplified version of my actual class which does much more).
>>
>>There are occasions when I need to check if one node object is the descendant 
>>of another node object. My current code for this is as follows:
>>
>>- (BOOL)isDescendantOfOrOneOfNodes:(NSArray*)nodes
>>{
>>   // Returns YES if we are contained anywhere inside the array passed in, 
>> including inside sub-nodes.
>>   NSEnumerator *enumerator = [nodes objectEnumerator];
>>   id node = nil;
>>   while (node = [enumerator nextObject])
>>   {
>>   if (node == self) return YES;  // Found ourself
>>   // Check all sub-nodes
>>   if ([[node children] count] > 0)
>>   {
>>   if([selfisDescendantOfOrOneOfNodes:[node children]])
>>   returnYES;
>>   }
>>   }
>>   // Didn't find self inside any of the nodes passed in
>>   returnNO;
>>}
>>
>>- (BOOL)isDescendantOfNodes:(NSArray*)nodes
>>{
>>   // Returns YES if any node in the array passed in is an ancestor of ours.
>>   NSEnumerator *enumerator = [nodes objectEnumerator];
>>   id node = nil;
>>   while (node = [enumerator nextObject])
>>   {
>>   // Note that the only difference between this and 
>> isAnywhereInsideChildrenOfNodes: is that we don't check
>>   // to see if we are actually one of the items in the array passed in, 
>> only if we are one of their descendants.
>>   // Check sub-nodes
>>   if ([[node children] count] > 0)
>>   {
>>   if([selfisDescendantOfOrOneOfNodes:[node children]])
>>   returnYES;
>>   }
>>   }
>>
>>   // Didn't find self inside any of the nodes passed in
>>   returnNO;
>>}
>>
>>So, in use, e.g:
>>
>>if ([firstNode isDescendantOfOneOfNodes:[NSArray arrayWithObject:secondNode]])
>>   // ... do something (e.g. prevent secondNode from being added as a child 
>> of firstNode).
>>
>>
>>My question is simply, is there a faster way of doing this? There are 
>>occasions when I need to run through and check potentially thousands of nodes 
>>each with thousands of descendants, and in this situation these checks can be 
>>quite time-consuming and slow things down. I know 10.5 introduced fast 
>>enumeration (e.g. "for (id node in nodes)"), and the only reason I'm not 
>>using that is that I need to support 10.4 too (I tested it and fast 
>>enumeration does speed things up a little, but not as much as I need at the 
>>volumes I'm talking about). So I'm just wondering if there is anything in the 
>>above that can be optimised to be faster. If not, I probably just need to 
>>re

Re: menu madness with retain count

[Jens Alfke]

On Apr 27, 2010, at 8:28 AM, Bill Appleton wrote:

1) after i append an item i have created to a menu i have created,  
and i
don't want to own the menu item any more, i should release the item  
so that

the menu owns it


Don't think of who "owns" an object. The memory model doesn't work  
that way — the whole point is that multiple objects can have  
references to another object without any of them having to be in  
charge of the referenced object's lifespan.


What you "own" are references. If you call a method that creates a  
reference, like +alloc, -retain or -copy, then you now own a reference  
to that object. For as long as you own that reference, the object will  
stay around. When you don't need the object anymore, you have to  
release that reference by telling the object to -release or - 
autorelease.


[And +1 on ignoring -retainCount. The only time this method is useful  
is if you are in gdb debugging some kind of tricky refcounting error;  
and even then you have to take its value with a grain of salt due to  
the effect of the autorelease pool.]


—Jens___

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 arch...@mail-archive.com

iPhone development without using the Xcode IDE

[Dominic Dauer]

Hi all,
I have the question whether it is possible to develop iPhone Apps without the 
use of the Xcode IDE. For example you could use the classic unix development 
tools manually, instead of using them full automatic by pressing the "build and 
run" button.
It is just curiosity which brings me to this question. I don't want to abstain 
from Xcode and his functions. 
 
Dominic D.

---
If there are any mistakes in my spelling, it would be very helpful to me and my 
English proficiency, when you rectify 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 arch...@mail-archive.com

Re: iPhone development without using the Xcode IDE

[Daniel Pasco]

As far as building from the command line is concerned, you can build your 
project without the IDE via the xcodebuild.  There's also a similar tool for 
running Package Maker.

These are useful for automated builds.  If you're looking at using Makefiles, 
configure and similar tools, I wouldn't bother.  Xcode works really well once 
you put in the time to learn how to use it.

-Daniel Pasco
Black Pixel
On Apr 27, 2010, at 11:49 AM, Dominic Dauer wrote:

> Hi all,
> I have the question whether it is possible to develop iPhone Apps without the 
> use of the Xcode IDE. For example you could use the classic unix development 
> tools manually, instead of using them full automatic by pressing the "build 
> and run" button.
> It is just curiosity which brings me to this question. I don't want to 
> abstain from Xcode and his functions. 
> 
> Dominic D.
> 
> ---
> If there are any mistakes in my spelling, it would be very helpful to me and 
> my English proficiency, when you rectify 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/daniel%40blackpixel.com
> 
> This email sent to dan...@blackpixel.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[vincent habchi]

Le 27 avr. 2010 à 20:42, Jens Alfke a écrit :

> What you "own" are references. If you call a method that creates a reference, 
> like +alloc, -retain or -copy, then you now own a reference to that object. 
> For as long as you own that reference, the object will stay around. When you 
> don't need the object anymore, you have to release that reference by telling 
> the object to -release or -autorelease.
> 
> [And +1 on ignoring -retainCount. The only time this method is useful is if 
> you are in gdb debugging some kind of tricky refcounting error; and even then 
> you have to take its value with a grain of salt due to the effect of the 
> autorelease pool.]

Yet, at the same time, you may want the dealloc: method to trigger some events. 
For example, if you have a CALayer that holds various sublayers, and that 
CALayer goes away, you may want all the sublayers to go away at the same time. 
Yet, this is impossible if some other object around locks a reference to the 
sublayers.

By the way, how are exactly multiple calls to [object autorelease] handled by 
the pool? Does this give rise to as many calls to release: as they are 
autorelease references stored, or does the pool directly adjust the retain 
count?

Vincent___

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 arch...@mail-archive.com

Re: Make About window respond to ⌘W in UI-le ss application

[Michael Dippery]

> Sorry, didn't read your email properly.  If you've already created a menu in 
> your MainMenu nib and it's not working, perhaps you haven't actually made the 
> connection in the nib.  If that's the case, then you just need to 
> Control-drag from your Close menu item to the First Responder in the nib and 
> connect it to the close: action.  If you've already done that and it still 
> doesn't work then I'm lost.

I was afraid I'd forgotten the step of hooking up the Close menu item I created 
to First Responder's close: action, so I went ahead and tried again. Here is 
exactly what I did:

1. Created a new menu in MainMenu nib with a single item, Close, with the key 
mnemonic ⌘W.
2. Hooked up the menu item to the close: action in First Responder.

When I loaded up the app's About window and hit ⌘W, I got the usual system beep 
I described before.

Of course, the issue is that I _still_ may not have something in the responder 
chain set up to properly the keyboard event, but I'm not really sure what to do 
even if I _could_ respond to the keyboard event somewhere else (e.g., my 
delegate); I don't have a reference to the About window -- I assume it's 
created programmatically in -[NSApp orderFrontStandardAboutPanel:], and I can't 
find a method for grabbing a reference -- so I'm not sure how I could close it 
from some other part of the code anyway.




Michael Dippery
mdipp...@gmail.com | www.monkey-robot.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Jens Alfke]

On Apr 27, 2010, at 11:58 AM, vincent habchi wrote:

Yet, at the same time, you may want the dealloc: method to trigger  
some events. For example, if you have a CALayer that holds various  
sublayers, and that CALayer goes away, you may want all the  
sublayers to go away at the same time. Yet, this is impossible if  
some other object around locks a reference to the sublayers.


Most of the time you just want your -dealloc method to call -release  
on objects it holds references to.  Or you might need to clean up some  
external resource (like closing a file), although it's often better to  
have an explicit -close method on your class to do this.


In your example, it doesn't matter if the sub-layers stay around,  
because they won't have a parent layer so won't be visible or consume  
any graphics resources. If you somehow forced those sub-layers to get  
dealloced at the same time as the parent layer, then any other object  
that had a reference to one would crash the next time it accessed it;  
bad news.


Remember that in a ref-counted (or GC'd) system you can't force an  
object to deallocate (even 'self'.) The deallocation is under control  
of all the other objects that have references, and the runtime itself.  
So you should never put any code into -dealloc or -finalize that  
absolutely has to run at a particular time.


By the way, how are exactly multiple calls to [object autorelease]  
handled by the pool? Does this give rise to as many calls to  
release: as they are autorelease references stored, or does the pool  
directly adjust the retain count?


Each call to -autorelease will cause one future -release call. So yes,  
the pool keeps a count of how many times -autorelease has been called  
for each object, and calls -release on it that many times when it  
drains.


—Jens___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Scott Ribe]

On Apr 27, 2010, at 12:58 PM, vincent habchi wrote:

> Yet, at the same time, you may want the dealloc: method to trigger some 
> events. For example, if you have a CALayer that holds various sublayers, and 
> that CALayer goes away, you may want all the sublayers to go away at the same 
> time. Yet, this is impossible if some other object around locks a reference 
> to the sublayers.

So what's the problem? If other objects are holding references to the 
sublayers, then they should no* go away. On the other hand, if your really need 
them to go away when the parent layer goes away, then other objects should not 
hold references to the sublayers. The sublayers will go away when no references 
to them exist any longer; it is the parent layer's responsibility to release 
the references it holds on them; it is other objects' responsibility to release 
any references they hold; it is your responsibility to determine whether or not 
other objects should ever hold references to the sublayers--and of course to 
manage (retain/release/autorelease) the references that you need.

> By the way, how are exactly multiple calls to [object autorelease] handled by 
> the pool? Does this give rise to as many calls to release: as they are 
> autorelease references stored, or does the pool directly adjust the retain 
> count?

Why would you care?

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: menu madness with retain count

[vincent habchi]

Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :

>> By the way, how are exactly multiple calls to [object autorelease] handled 
>> by the pool? Does this give rise to as many calls to release: as they are 
>> autorelease references stored, or does the pool directly adjust the retain 
>> count?
> 
> Why would you care?

Because earlier in this afternoon I decided to trace the retain/release 
messages sent to an object by overriding the respective methods and have them 
write the retain count before calling super methods. I registered most curious 
behaviors, for example objects released while the last time their retain count 
was printed it was equal to 2. No 1, no 0. That's why I asked, just to know if 
autorelease does not short-circuit the traditional release: call by accessing 
the retain count directly.

Vincent___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Klaus Backert]

On 27 Apr 2010, at 21:38, vincent habchi wrote:

Because earlier in this afternoon I decided to trace the retain/ 
release messages sent to an object by overriding the respective  
methods and have them write the retain count before calling super  
methods. I registered most curious behaviors, for example objects  
released while the last time their retain count was printed it was  
equal to 2. No 1, no 0. That's why I asked, just to know if  
autorelease does not short-circuit the traditional release: call by  
accessing the retain count directly.


As others have said: This is the way to madness. You didn't believe  
it, do you?


Klaus

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[vincent habchi]

Le 27 avr. 2010 à 21:17, Jens Alfke a écrit :

> Remember that in a ref-counted (or GC'd) system you can't force an object to 
> deallocate (even 'self'.) The deallocation is under control of all the other 
> objects that have references, and the runtime itself. So you should never put 
> any code into -dealloc or -finalize that absolutely has to run at a 
> particular time.

Yes, I've learned that the hard way. ;)
Cheers
Vincent___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Steve Bird]

On Apr 27, 2010, at 3:38 PM, vincent habchi wrote:

> Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :
> 
>>> By the way, how are exactly multiple calls to [object autorelease] handled 
>>> by the pool? Does this give rise to as many calls to release: as they are 
>>> autorelease references stored, or does the pool directly adjust the retain 
>>> count?
>> 
>> Why would you care?
> 
> Because earlier in this afternoon I decided to trace the retain/release 
> messages sent to an object by overriding the respective methods and have them 
> write the retain count before calling super methods. I registered most 
> curious behaviors, for example objects released while the last time their 
> retain count was printed it was equal to 2. No 1, no 0. That's why I asked, 
> just to know if autorelease does not short-circuit the traditional release: 
> call by accessing the retain count directly.

--- It can't.  It simply sends a release message at some future time.  Its 
purpose is to delay the actual release long enough for me to create an object 
and hand it to you, my caller.  

If I create this object, I cannot release it before I return to you - the 
object would disappear.  But if I don't ever release it, then it will never 
disappear.  So I autorelease it, and return it to you.

If you want to keep it around, then YOU retain it yourself, and release it when 
you see fit.  If you don't, then do nothing.

The fact that it's in the autorelease pool simply means it gets a release 
message at some point in the near future.  No more, no less.  If you've 
retained the object I gave you then this release does nothing noticeable.  If 
you haven't, then this release deallocates the object.

I'll say it again: being in the autorelease pool simply means you will get one 
release message when the runtime gets around to it.
If you are in the pool TWICE, you will get TWO release messages when the 
runtime gets around to it.

Over the years, I think that looking at the retain count is the #1 cause of 
hairpulling on this list.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
www.Culverson.com (toll free) 1-877-676-8175


___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Jens Alfke]

On Apr 27, 2010, at 12:38 PM, vincent habchi wrote:

I registered most curious behaviors, for example objects released  
while the last time their retain count was printed it was equal to  
2. No 1, no 0. That's why I asked, just to know if autorelease does  
not short-circuit the traditional release: call by accessing the  
retain count directly.


That sounds like an optimization in the runtime to avoid a couple of  
message-sends. You shouldn't override -retain or -release or make  
assumptions about how many times they're called; those are  
implementation details.


—Jens___

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 arch...@mail-archive.com

Re: menu madness with retain count

[vincent habchi]

Le 27 avr. 2010 à 21:57, Jens Alfke a écrit :

>> I registered most curious behaviors, for example objects released while the 
>> last time their retain count was printed it was equal to 2. No 1, no 0. 
>> That's why I asked, just to know if autorelease does not short-circuit the 
>> traditional release: call by accessing the retain count directly.
> 
> That sounds like an optimization in the runtime to avoid a couple of 
> message-sends. You shouldn't override -retain or -release or make assumptions 
> about how many times they're called; those are implementation details.

That's what I inferred too, and that's why I supposed the autorelease pool 
pokes directly somehow in retain counts to rise performance, but it may be, as 
you say, some optimizing behavior at runtime.

Ok, forget it. Extremely interesting, but I feel this thread is, as we say in 
French, a sea snake: we might never see its end.

Good night and thanks again!
Vincent___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Scott Ribe]

On Apr 27, 2010, at 1:38 PM, vincent habchi wrote:

> Because earlier in this afternoon I decided to trace the retain/release 
> messages sent to an object by overriding the respective methods and have them 
> write the retain count before calling super methods. I registered most 
> curious behaviors, for example objects released while the last time their 
> retain count was printed it was equal to 2. No 1, no 0. That's why I asked, 
> just to know if autorelease does not short-circuit the traditional release: 
> call by accessing the retain count directly.

Did you really mean "objects released while the last time their retain count 
was printed it was equal to..." as that's perfectly expected--releasing is just 
one perfectly normal way for the retain count to be decreased. In fact, an 
object being released after its retain count hits 0 is a bug.

Or did you mean "objects dealloc'd while the last time their retain count was 
printed it was equal to..." because that would be curious.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Scott Ribe]

On Apr 27, 2010, at 1:57 PM, Jens Alfke wrote:

> That sounds like an optimization in the runtime to avoid a couple of 
> message-sends. You shouldn't override -retain or -release or make assumptions 
> about how many times they're called; those are implementation details.

Actually, you can override retain & release. If there's any optimization in the 
runtime to avoid multiple release calls, it must be only be enabled for objects 
that do not override release.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: white screen windows at first

[Uli Kusterer]

On 27.04.2010, at 00:10, Bill Appleton wrote:
> i added flush window to the drawRect method -- no help
> 
> it IS calling draw rect right before the window is shown & then you see it
> --- all white

 Are you using multiple threads? I got effects like that when I was screwing up 
AppKit state by messing with non-thread-safe objects from multiple threads.

-- Uli Kusterer
Sole Janitor
http://www.the-void-software.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: white screen windows at first

[Bill Appleton]

hi vince,

my windows are NSBackingStoreBuffered

is that what you mean by background property? i am just using a subclassed
NSView & a CGContext for drawing

this is a very generic use of cocoa windows, i can't figure out what is
wrong

i noticed that if i show/hide a window it will stop working altogether --
can't resize it, etc.


thanks,

bill




On Tue, Apr 27, 2010 at 10:31 AM, vincent habchi  wrote:

> Le 26 avr. 2010 à 23:35, Bill Appleton a écrit :
>
> > hi all,
> >
> > when my windows are first shown there is no drawing inside, they are
> white
> >
> > but when i slowly move the mouse over to the close box and the close box
> > responds to the mouse hover suddenly they draw their content properly
> >
> > does this ring any bells with people? i'm not sure where to look in the
> docs
> > for this one
>
> Darn, I got that kind of behavior with my CALayers a while ago. They would
> not draw unless I moved the layers or zoomed on them. Did you try to look at
> background properties? Are your views layer backed?
>
> Vincent
___

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 arch...@mail-archive.com

Re: white screen windows at first

[Bill Appleton]

no threads

i have been disabling things to the point that it is mainly just the windows

i noticed that if i show/hide a window it will stop working altogether --
can't resize it, etc.


thanks,

bill




On Tue, Apr 27, 2010 at 1:34 PM, Uli Kusterer
wrote:

> On 27.04.2010, at 00:10, Bill Appleton wrote:
> > i added flush window to the drawRect method -- no help
> >
> > it IS calling draw rect right before the window is shown & then you see
> it
> > --- all white
>
>  Are you using multiple threads? I got effects like that when I was
> screwing up AppKit state by messing with non-thread-safe objects from
> multiple threads.
>
> -- Uli Kusterer
> Sole Janitor
> http://www.the-void-software.com
>
>
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: white screen windows at first

[Uli Kusterer]

On 27.04.2010, at 00:10, Bill Appleton wrote:
> i added flush window to the drawRect method -- no help
> 
> it IS calling draw rect right before the window is shown & then you see it
> --- all white

 Oh, also: if your code throws exceptions, those can abort important processes 
like redraws, you may want to set breakpoints on C++ throws and 
objc_exception_throw and see if any of these gets triggered and by whom. Also, 
throwing C++ exceptions through C or ObjC code and ObjC exceptions through C or 
C++ code can royally screw you.

-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.masters-of-the-void.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Bill Appleton]

>> Over the years, I think that looking at the retain count is the #1 cause
of hairpulling on this list.


it's too bad this is unreliable

an object should be able to return this info

and it isn't simple, it gets convoluted in process

if i add a submenu to an item then it is retained by the menu

but then if i then set that submenu to nil is it still retained?

if retained count was accurate you could test it on final release, etc






On Tue, Apr 27, 2010 at 12:53 PM, Steve Bird  wrote:

>
> On Apr 27, 2010, at 3:38 PM, vincent habchi wrote:
>
> > Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :
> >
> >>> By the way, how are exactly multiple calls to [object autorelease]
> handled by the pool? Does this give rise to as many calls to release: as
> they are autorelease references stored, or does the pool directly adjust the
> retain count?
> >>
> >> Why would you care?
> >
> > Because earlier in this afternoon I decided to trace the retain/release
> messages sent to an object by overriding the respective methods and have
> them write the retain count before calling super methods. I registered most
> curious behaviors, for example objects released while the last time their
> retain count was printed it was equal to 2. No 1, no 0. That's why I asked,
> just to know if autorelease does not short-circuit the traditional release:
> call by accessing the retain count directly.
>
> --- It can't.  It simply sends a release message at some future time.  Its
> purpose is to delay the actual release long enough for me to create an
> object and hand it to you, my caller.
>
> If I create this object, I cannot release it before I return to you - the
> object would disappear.  But if I don't ever release it, then it will never
> disappear.  So I autorelease it, and return it to you.
>
> If you want to keep it around, then YOU retain it yourself, and release it
> when you see fit.  If you don't, then do nothing.
>
> The fact that it's in the autorelease pool simply means it gets a release
> message at some point in the near future.  No more, no less.  If you've
> retained the object I gave you then this release does nothing noticeable.
>  If you haven't, then this release deallocates the object.
>
> I'll say it again: being in the autorelease pool simply means you will get
> one release message when the runtime gets around to it.
> If you are in the pool TWICE, you will get TWO release messages when the
> runtime gets around to it.
>
> Over the years, I think that looking at the retain count is the #1 cause of
> hairpulling on this list.
> 
> Steve Bird
> Culverson Software - Elegant software that is a pleasure to use.
> www.Culverson.com (toll free) 1-877-676-8175
>
>
> ___
>
> 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/billappleton%40dreamfactory.com
>
> This email sent to billapple...@dreamfactory.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Kyle Sluder]

On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
 wrote:
>>> Over the years, I think that looking at the retain count is the #1 cause
> of hairpulling on this list.
>
>
> it's too bad this is unreliable
>
> an object should be able to return this info

Why? It serves you no purpose. Once you hand an object off to the
framework, how do you know what it does with that object?

> and it isn't simple, it gets convoluted in process
>
> if i add a submenu to an item then it is retained by the menu
>
> but then if i then set that submenu to nil is it still retained?

Don't focus on the object itself. Focus on your reference to the
object. If you want to hold a reference for a while, you need to
retain the thing that lives on the other end of that reference. When
you no longer need that reference, you release the thing at the other
end of the reference.

The reference is a cable to which a valuable object is attached. Your
hands are concerned about holding on to your end of the cable.

> if retained count was accurate you could test it on final release, etc

The retain count *is* accurate; it accurately accounts for every
-retain/-release pair that has been performed on that object, whether
you performed it or not.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Bill Bumgarner]

On Apr 27, 2010, at 1:49 PM, Bill Appleton wrote:

> it's too bad this is unreliable
> 
> an object should be able to return this info

An object does return this info, the problem is that the # is a meaningless 
internal implementation detail of the Cocoa frameworks.

For example, if you create an instance of NSNumber, you might actually get an 
allocated instance or you might get an additional reference to an already 
existing implementation.  With NSString, you might get a constant string (i.e. 
retain counts are entirely meaningless), a cached instance of one of the more 
common strings, a substring of one of the former two, or you might get a new 
allocation.  NSImage may or may not return a new instance depending on cache 
availability.

Similarly, when you give an object to any API in the framework, what the 
framework does with it internally is an implementation detail and one that 
might change from release to release.  When you create an NSMenuItem instance 
and hand it off to the framework, it might be retained once, twice, 10 times or 
not at all (remember: if you want to keep an object around, you need to 
maintain a retain on it).

All of this is why trying to do debugging on absolute retain counts is a waste 
of time.

> and it isn't simple, it gets convoluted in process

As do the implementation details of most highly optimized complex software 
systems

> if i add a submenu to an item then it is retained by the menu
> 
> but then if i then set that submenu to nil is it still retained?

Maybe so, maybe not.  Implementation detail.  Maybe it is retained until the 
next pass through the main event loop?  Maybe it is pushed into the autorelease 
pool?  Maybe the retain is held for as long as some internal structure is kept 
about.

The point is that you don't know, can't know, and shouldn't care.   The 
absolute retain count is irrelevant.

> if retained count was accurate you could test it on final release, etc

The retain count is accurate.  Is always accurate.  It is just that the value 
of the retain count may be influenced by factors well beyond your control.

All you care about is the retain count delta.   "My code caused the retain 
count to increase by 1, therefore my code *must* decrease the retain count by 
1."  "My code is 'passing' a reference to this object from thread A to thread 
B, therefore I *must* have an explicit retain in A and a release in B."

Frankly, the -retainCount method should be deprecated and, eventually, removed.

b.bum

___

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 arch...@mail-archive.com

Re: UIScrollView Sizing

[Fritz Anderson]

On 27 Apr 2010, at 12:58 PM, Bob Barnes wrote:

> I have a UIScrollView that can contain a variable number of other UIViews 
> (UILabels, UIImageViews, etc), but I'm confused as to how to manage the 
> UIScrollView contentSize given the variability in the number of views it will 
> contain. I'd like to use IB to create my view, but is this type of view 
> better suiting to being built programmatically? UIScrollViews with variable 
> content seems like a rather common paradigm and I'm wondering how folks 
> approach this type of UI. 

Pseudocode, written in Mail. I have code that does this right, but I don't have 
access to it just now. Expect to debug, or to get a better answer from someone 
else:

#define VIEW_WIDTH  320.0
// or whatever

UIScrollView *  scrollView = ...
CGSize  totalSize = { VIEW_WIDTH, 0.0 };

//  Assuming you want to stack the views vertically
for (each view I want to add) {
UIView *aView = [[AViewClass alloc] init...];
//  ... other initialization that sets bounds
[scrollView addSubview: aView];

CGRect  frameRect = aView.frame;
frameRect.origin.y = totalSize.height;
aView.frame = frameRect;
totalSize.height = CGRectGetMaxY(frameRect);
}

scrollView.contentSize = totalSize;

/* Reiterate disclaimers */

— F

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Shawn Erickson]

On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
 wrote:
>>> Over the years, I think that looking at the retain count is the #1 cause
> of hairpulling on this list.
>
>
> it's too bad this is unreliable
>
> an object should be able to return this info
>
> and it isn't simple, it gets convoluted in process
>
> if i add a submenu to an item then it is retained by the menu
>
> but then if i then set that submenu to nil is it still retained?
>
> if retained count was accurate you could test it on final release, etc

The retain count is accurate and it is tested on the "final" release
to make the decision about deallocating the object.

What isn't useful about retain count it trying to poke at the value at
any given point in time and trying to make sense of why the count is a
particular value. The Cocoa framework, etc. can retain and
release/autorelease objects that you use as you use them with various
framework APIs. When and what it does in an implementation detail that
easily changes between OS released, etc.. Also the retain count
doesn't reflect any pending autoreleases.

If you want to evaluate object life cycle issues you should use
Instruments (Object Allocations, Zombies, and/or Leaks templates).
Using Instruments you can get timeline of retain / release /
autorelease messages sent to a given object.

You can expect the framework and any properly written code to retain
objects as needed to ensure they live as long as needed. When no
longer needed they will release/auotorelease their "claim" on the
object (balance any retains they sent to establish a "claim").

One of the biggest problem folks have when first getting into Cocoa
development is over thinking memory management... it truly is simple
and the core memory management model is follow pervasively in all
frameworks provide by Apple and third parties.

-Shawn
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Gary L. Wade]

On 04/27/2010 1:58 PM, "Bill Bumgarner"  wrote:

> Frankly, the -retainCount method should be deprecated and, eventually,
> removed.

I wouldn't go THAT far; after all, when you're tracking a memory leak,
checking your influence on the retain count is important to your
investigation.  Hopefully that's why the original poster is looking at it.


___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Bill Bumgarner]

On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:

> On 04/27/2010 1:58 PM, "Bill Bumgarner"  wrote:
> 
>> Frankly, the -retainCount method should be deprecated and, eventually,
>> removed.
> 
> I wouldn't go THAT far; after all, when you're tracking a memory leak,
> checking your influence on the retain count is important to your
> investigation.  Hopefully that's why the original poster is looking at it.

The combination of leaks, zombies, heap, and malloc stack logging are much 
*much* more powerful and effective than trying to debug a leak, over-retain or 
under-retain with -retainCount.

b.bum

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Gary L. Wade]

On 04/27/2010 2:12 PM, "Bill Bumgarner"  wrote:

> 
> On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
> 
>> On 04/27/2010 1:58 PM, "Bill Bumgarner"  wrote:
>> 
>>> Frankly, the -retainCount method should be deprecated and, eventually,
>>> removed.
>> 
>> I wouldn't go THAT far; after all, when you're tracking a memory leak,
>> checking your influence on the retain count is important to your
>> investigation.  Hopefully that's why the original poster is looking at it.
> 
> The combination of leaks, zombies, heap, and malloc stack logging are much
> *much* more powerful and effective than trying to debug a leak, over-retain or
> under-retain with -retainCount.
> 
> b.bum
> 

Yes, but how would you use those to determine why an Apple framework now
chooses to retain a delegate (I'm referring to one particular one I
discovered), thereby causing a retain cycle?  It's not a memory leak in the
sense that Instruments or leaks would ever catch it.  Calling -retainCount
immediately before and after the -setDelegate call is pretty much the only
way.


___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Jack Nutting]

On Tue, Apr 27, 2010 at 11:12 PM, Bill Bumgarner  wrote:
>
> The combination of leaks, zombies, heap, and malloc stack logging are much 
> *much* more powerful and effective than trying to debug a leak, over-retain 
> or under-retain with -retainCount.
>
> b.bum

Hear, hear.  I haven't called retainCount in well over a decade. Not
as a matter of principle, but as a result of learned experience and
reasoning: attempting to track down memory leaks or premature deallocs
by examining the value of retainCount *does*not*work*.  The value it
returns for any framework class is only meaningful, necessarily,
within that framework or a framework it's using; The only time that
retainCount can be assumed to have any meaningful value to you as a
developer is in case you have your own class that overrides all the
memory-management methods and handles them completely on its own, so
that you can e.g. do your own caching of objects you create.

-- 
// jack
// http://nuthole.com
// http://learncocoa.org
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Uli Kusterer]

On 27.04.2010, at 17:28, Bill Appleton wrote:
> 1) after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it

 Depends on how you create the item. If you create them in a way that you have 
to release it, you have to release it. As soon as you add it to a menu, that 
menu will retain it or copy it if it wants to keep it around, and you can 
release your reference to it. If you create the item autoreleased (e.g. using a 
factory method), of course you don't release it.

> 2) when i add a submenu i have created to a menu i have created, and i don't
> want to own the submenu any more, i should release the submenu so that the
> menu owns it

 Same as with menu item. If you create it so you own it, you release it once 
*you* are done with it. Everyone else (including the menu item whose submenu 
you set it as) will retain it or copy it if they want to keep it around.

> 3) when i set the menus i have created for NSApp using setMainMenu then...
> what? who owns them? how do i set more menus for NSApp? how do i get NSApp
> to release the current set?

 Again, the application will retain the menu you give it as the main menu (and 
that in turn will retain all its items, which in turn will retain their 
submenus which will retain their items which...) and if you created it so you 
have to release it, you ca release it once you don't need it anymore.

 To get the shared application singleton to release its main menu, you'll have 
to set a different main menu. You might be able to set the main menu to NIL, or 
you may have to create a minimal main menu (with an application menu), but 
that's pretty much it.

 If you have problems changing the main menu, I'd suggest leaving the main menu 
and the application menu the same, and just editing the main menu by 
adding/deleting menu items and submenus. Messing with the main menu like that 
seems to be one of the less explored areas of MacOS X. Also, keep in mind that, 
at least on 10.5 and later, you can hide menu items (and thus menus) if you 
find that recreating a "special" menu doesn't make it special anymore.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Shawn Erickson]

On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
 wrote:

> Yes, but how would you use those to determine why an Apple framework now
> chooses to retain a delegate (I'm referring to one particular one I
> discovered), thereby causing a retain cycle?  It's not a memory leak in the
> sense that Instruments or leaks would ever catch it.

If you use the Object Allocations template (with retain tracking
enabled) in Instruments then yes you can track down those type of
issues easily ... far more easily then trying to probe retainCount in
code yourself. I likely have use Instruments to track down every
conceivable problem that may make you want to look at retainCount...
you don't have to modify any code either.

> Calling -retainCount immediately before and after the -setDelegate call is 
> pretty much the only
> way.

Simply not true.

-Shawn
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Julien Jalon]

ObjectAlloc instrument is your friend. Configure it to record retains
and releases. Much more accurate, much easier to understand what's
going on.

On Tuesday, April 27, 2010, Gary L. Wade  wrote:
> On 04/27/2010 2:12 PM, "Bill Bumgarner"  wrote:
>
>>
>> On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
>>
>>> On 04/27/2010 1:58 PM, "Bill Bumgarner"  wrote:
>>>
 Frankly, the -retainCount method should be deprecated and, eventually,
 removed.
>>>
>>> I wouldn't go THAT far; after all, when you're tracking a memory leak,
>>> checking your influence on the retain count is important to your
>>> investigation.  Hopefully that's why the original poster is looking at it.
>>
>> The combination of leaks, zombies, heap, and malloc stack logging are much
>> *much* more powerful and effective than trying to debug a leak, over-retain 
>> or
>> under-retain with -retainCount.
>>
>> b.bum
>>
>
> Yes, but how would you use those to determine why an Apple framework now
> chooses to retain a delegate (I'm referring to one particular one I
> discovered), thereby causing a retain cycle?  It's not a memory leak in the
> sense that Instruments or leaks would ever catch it.  Calling -retainCount
> immediately before and after the -setDelegate call is pretty much the only
> way.
>
>
> ___
>
> 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/jjalon%40gmail.com
>
> This email sent to jja...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: menu madness with retain count

[Gary L. Wade]

On 04/27/2010 2:27 PM, "Shawn Erickson"  wrote:

> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
>  wrote:
> 
>> Yes, but how would you use those to determine why an Apple framework now
>> chooses to retain a delegate (I'm referring to one particular one I
>> discovered), thereby causing a retain cycle?  It's not a memory leak in the
>> sense that Instruments or leaks would ever catch it.
> 
> If you use the Object Allocations template (with retain tracking
> enabled) in Instruments then yes you can track down those type of
> issues easily ... far more easily then trying to probe retainCount in
> code yourself. I likely have use Instruments to track down every
> conceivable problem that may make you want to look at retainCount...
> you don't have to modify any code either.
> 
>> Calling -retainCount immediately before and after the -setDelegate call is
>> pretty much the only
>> way.
> 
> Simply not true.
> 
> -Shawn

That's how I found the cause of Apple's bug, but I verified what I was
seeing by using -retainCount before and after, so yes, that simply is true.


___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Uli Kusterer]

On 27.04.2010, at 11:53, Paul Sanders wrote:
> I was speaking from memory.  My recollection is that after I 
> moved the menu bar the primary display, as reported by NSScreen, 
> did not change.  But it was a while ago so I could be wrong and 
> the docs agree with you.  This implies that the primary display 
> can change at run time.

 Maybe you were asking for the -mainScreen? In Carbon and some other 
documentation, the screen with the menu bar is called the "main" screen. But in 
Cocoa, the -mainScreen method actually returns the screen on which the window 
that is currently "main" is placed. Tricks many people.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Scott Ribe]

On Apr 27, 2010, at 2:49 PM, Bill Appleton wrote:

> and it isn't simple, it gets convoluted in process

It is simple. It is very, very simple. You're over-thinking it.

You are responsible for your references to the submenu. The menu is responsible 
for managing its references to its submenus. You're conflating the two 
unnecessarily.


-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Paul Sanders]

Actually, I think I was just plain wrong but what I meant was 
[[NSScreen screens] objectAtIndex: 0].

Paul Sanders.

- Original Message - 
From: "Uli Kusterer" 
To: "Paul Sanders" 
Cc: "Cocoa-Dev (Apple)" 
Sent: Tuesday, April 27, 2010 10:34 PM
Subject: Re: NSApplicationMain question


On 27.04.2010, at 11:53, Paul Sanders wrote:
> I was speaking from memory.  My recollection is that after I
> moved the menu bar the primary display, as reported by 
> NSScreen,
> did not change.  But it was a while ago so I could be wrong 
> and
> the docs agree with you.  This implies that the primary 
> display
> can change at run time.

 Maybe you were asking for the -mainScreen? In Carbon and some 
other documentation, the screen with the menu bar is called the 
"main" screen. But in Cocoa, the -mainScreen method actually 
returns the screen on which the window that is currently "main" 
is placed. Tricks many people.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de




___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Shawn Erickson]

On Tue, Apr 27, 2010 at 2:32 PM, Gary L. Wade
 wrote:
> On 04/27/2010 2:27 PM, "Shawn Erickson"  wrote:
>
>> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
>>  wrote:
>>
>>> Yes, but how would you use those to determine why an Apple framework now
>>> chooses to retain a delegate (I'm referring to one particular one I
>>> discovered), thereby causing a retain cycle?  It's not a memory leak in the
>>> sense that Instruments or leaks would ever catch it.
>>
>> If you use the Object Allocations template (with retain tracking
>> enabled) in Instruments then yes you can track down those type of
>> issues easily ... far more easily then trying to probe retainCount in
>> code yourself. I likely have use Instruments to track down every
>> conceivable problem that may make you want to look at retainCount...
>> you don't have to modify any code either.
>>
>>> Calling -retainCount immediately before and after the -setDelegate call is
>>> pretty much the only
>>> way.
>>
>> Simply not true.
>>
>> -Shawn
>
> That's how I found the cause of Apple's bug, but I verified what I was
> seeing by using -retainCount before and after, so yes, that simply is true.

1) If you used Instruments you could track down this issue directly
without modification of code, which was my point and counters your
point of having to use retainCount to find something like this.

2) Your use of retainCount is flawed since how do you know that
setDelegate: (or any method for that matter) isn't written something
like the following (or any of countless other ways that could cause a
temporary retain). Wrapping a call to this method with retainCount
wouldn't account for the autorelease and hence would make you think it
is incorrectly retaining something. If you used instruments you would
get the whole picture and not make an incorrect read on the situation.

- (void) setDelegate:(id)delegate {
...do things...
[[delegate retain] autorelease];
...do things...
_delegate = delegate;
}
___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Shawn Erickson]

On Tue, Apr 27, 2010 at 2:40 PM, Paul Sanders
 wrote:
> Actually, I think I was just plain wrong but what I meant was
> [[NSScreen screens] objectAtIndex: 0].

At one point in time I recall NSScreen not reliably updating its
information on mode switches of displays. I cannot recall the
specifics but I am fairly sure it was a bug in the early days of Mac
OS X.

-Shawn
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Gary L. Wade]

On 04/27/2010 2:46 PM, "Shawn Erickson"  wrote:

[ removed lots of bad assumptions by Shawn ]

Shawn, it is apparent your understanding of reality is flawed when it comes
to my efforts to track down the bug in Apple's code, so please go away.
This thread is over.


___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Uli Kusterer]

On 27.04.2010, at 23:22, Gary L. Wade wrote:
> Calling -retainCount
> immediately before and after the -setDelegate call is pretty much the only
> way.

Nope. It'll only lead to pain and suffering. And false positives. What if 
setDelegate was implemented thus:

-(void) setDelegate: (id)dele
{
mDelegate = dele;

[self detachNewThreadSelector: @selector(useDelegateOnThread:) withObject: 
dele];
}

This will retain the delegate to hand it off to the other thread. Depending on 
how long that other thread takes and how good a day your scheduler has, the 
thread may be finished and mDelegate may contain a weak reference to the 
delegate, or the thread may take longer, and then your code looking at the 
retain count will think it was a strong reference.

There is no substitute to reading the documentation.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Shawn Erickson]

On Tue, Apr 27, 2010 at 2:56 PM, Gary L. Wade
 wrote:
> On 04/27/2010 2:46 PM, "Shawn Erickson"  wrote:
>
> [ removed lots of bad assumptions by Shawn ]
>
> Shawn, it is apparent your understanding of reality is flawed when it comes
> to my efforts to track down the bug in Apple's code, so please go away.

Your efforts to locate a bug in Apple's code is orthogonal (and
frankly unimportant) to the discussion on the proper way to detect a
retain cycle, over retain, under release, over release, etc. I was not
questioning any aspect of you having found a bug or not.

I was questioning your following statement...

"Yes, but how would you use those to determine why an Apple framework now
chooses to retain a delegate (I'm referring to one particular one I
discovered), thereby causing a retain cycle?  It's not a memory leak in the
sense that Instruments or leaks would ever catch it."

...because Instruments with the Object Allocations template can be
used to directly find that type of issue and the code paths involved.
I know because I have used it to do exactly that on several occasions.

You then followed this statement saying that...

"Calling -retainCount immediately before and after the -setDelegate
call is pretty much the only way."

...which I noted is incorrect because 1) you should use Instruments
instead to get a more complete picture of the situation and 2)
attempting to use retainCount can easily mislead you because of
temporary retains (aka retains balanced with autorelease) which would
make the retain count appear to increase when in fact in the near
future it will decrease.

I am sorry if this hit a nerve but you have to understand posting
questionable information to a public forum can easily mislead others
into false beliefs and practices. We all have to attempt to keep
accurate information available to list members.

I encourage you to understand the points I and others are trying to
make here and not take them personally.

-Shawn
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Laurent Daudelin]

Can you guys maybe agree that you disagree and put it to rest?

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://nemesys.dyndns.org
Logiciels Nemesys Software  
laurent.daude...@gmail.com
Photo Gallery Store: 
http://laurentdaudelin.shutterbugstorefront.com/g/galleries___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Bill Bumgarner]

On Apr 27, 2010, at 3:05 PM, Uli Kusterer wrote:

> On 27.04.2010, at 23:22, Gary L. Wade wrote:
>> Calling -retainCount
>> immediately before and after the -setDelegate call is pretty much the only
>> way.
> 
> Nope. It'll only lead to pain and suffering. And false positives. What if 
> setDelegate was implemented thus:
> 
> -(void)   setDelegate: (id)dele
> {
>mDelegate = dele;
> 
>[self detachNewThreadSelector: @selector(useDelegateOnThread:) withObject: 
> dele];
> }

Grand Central Dispatch can confuse matters further and in subtle ways.  
Consider:

dispatch_async(..., ^{... time consuming maybe ...; 
dispatch_async(dispatch_get_main_queue(), ^{ ... dele ...}); });

In this case, the two dispatch_asyncs are going to call Block_copy() in a 
predictable order but with a high degree of variability in timing (both due to 
time consumed in outer block and workload on main queue).  End result is that 
the retain count will be changing behind your back regardless of what you are 
doing in other threads.   More confusing, still, if the scheduling of the inner 
block on the main queue happens before your code runs, but the block's 
execution is blocked by your code running on the main queue, you *might* see a 
retain from the first block and *will* see the retain from the second block.

b.bum
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Uli Kusterer]

On 27.04.2010, at 22:49, Bill Appleton wrote:
> an object should be able to return this info
> 
> and it isn't simple, it gets convoluted in process

 Let me exaggerate for a paragraph to hopefully bring across a point:

 The main objective of Cocoa's design is not to produce the most efficient code 
(for that you'd write your whole application in assembler), or to write code 
where everything is set in stone at compile-time (for that you'd use C++). The 
main objective of Cocoa's design is to make it easy to write object-oriented, 
modular, encapsulated software.

 And encapsulation is exactly what looking at the retain count violates.

 In an ideal world, every subsystem of your program would be completely 
self-sufficient and independent of the rest, to make it easy to thoroughly test 
it. The problem is that no real-world program fits this description. The idea 
behind retain counting is that each subsystem only has to care about itself, 
about the reference(s) to a shared resource that *it* holds.

 It does not (and actually, should not) have to care about references anyone 
else holds to the same resource. As long as everyone else obtains and gives up 
their references properly, the resource eventually is reclaimed. And this holds 
true not just for the traditional concept of a subsystem, but also for each 
subroutine as a "micro-subsystem".

 There is documentation about who retains what. The memory management 
documentation mentions some of it (the naming conventions for methods), there's 
a convention that, generally, you do not retain your owner (because it very 
likely already retains you and you don't want closed circles because then you'd 
never get released), so generally delegates aren't retained.

 I'm not saying there aren't bugs. For example, bindings were notorious for 
causing retain circles when you bound to File's Owner in a NIB, and that was 
fixed in 10.5, IIRC. But generally, documentation informs you of this. And when 
it doesn't, people have usually figured it out using Instruments, or by 
following the calls to retain/release/autorelease on an object.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Shawn Erickson]

On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
 wrote:

>For example, bindings were notorious for causing retain circles when you bound 
>to File's Owner in a NIB, and that was fixed in 10.5, IIRC.

Fairly sure it is still an issue unless you are using a
NSWindowController subclass as the File's Owner (at least on 10.5 not
looked at 10.6 directly).

-Shawn
___

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 arch...@mail-archive.com

Re: white screen windows at first

[Bill Appleton]

this problem must be because i am using core graphics

i painted a big red rectangle in drawRect and then went on and called my
core graphics code

the big red rectangle comes up every time

but only after resizing do i see the stuff i draw with core graphics

so i am getting the draw rect events but for some reason i am using core
graphics wrong or didn't set it up right to be used

does this make sense to anybody?


thanks,

bill









On Tue, Apr 27, 2010 at 1:41 PM, Uli Kusterer
wrote:

> On 27.04.2010, at 00:10, Bill Appleton wrote:
> > i added flush window to the drawRect method -- no help
> >
> > it IS calling draw rect right before the window is shown & then you see
> it
> > --- all white
>
>  Oh, also: if your code throws exceptions, those can abort important
> processes like redraws, you may want to set breakpoints on C++ throws and
> objc_exception_throw and see if any of these gets triggered and by whom.
> Also, throwing C++ exceptions through C or ObjC code and ObjC exceptions
> through C or C++ code can royally screw you.
>
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.masters-of-the-void.com
>
>
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Make About window respond to ⌘W in UI-le ss application

[Ron Fleckner]

On 28/04/2010, at 5:06 AM, Michael Dippery wrote:

Sorry, didn't read your email properly.  If you've already created  
a menu in your MainMenu nib and it's not working, perhaps you  
haven't actually made the connection in the nib.  If that's the  
case, then you just need to Control-drag from your Close menu item  
to the First Responder in the nib and connect it to the close:  
action.  If you've already done that and it still doesn't work then  
I'm lost.


I was afraid I'd forgotten the step of hooking up the Close menu  
item I created to First Responder's close: action, so I went ahead  
and tried again. Here is exactly what I did:


1. Created a new menu in MainMenu nib with a single item, Close,  
with the key mnemonic ⌘W.

2. Hooked up the menu item to the close: action in First Responder.

When I loaded up the app's About window and hit ⌘W, I got the usual  
system beep I described before.


Of course, the issue is that I _still_ may not have something in the  
responder chain set up to properly the keyboard event, but I'm not  
really sure what to do even if I _could_ respond to the keyboard  
event somewhere else (e.g., my delegate); I don't have a reference  
to the About window -- I assume it's created programmatically in - 
[NSApp orderFrontStandardAboutPanel:], and I can't find a method for  
grabbing a reference -- so I'm not sure how I could close it from  
some other part of the code anyway.




Aha! I just checked the Close item in my main menu nib's menu (which I  
hadn't deleted, so it's still the default one) and Control-clicking  
that reveals its (the menu item's) connections and it connects to  
performClose: in First Responder, not close:.  So try connecting to  
that and see how it goes.  Sorry for not checking before.


Ron

___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Keith Blount]

Sorry, I missed this reply earlier. Unfortunately I can't use NSTreeNode 
because I'm tied to providing support for Tiger for the foreseeable future, and 
NSTreeNode is Leopard and above only. Thus I'm not able to use bindings for my 
outline views (I remember spending weeks trying to bend NSTreeController to do 
things like drag and drop back when it was first introduced in Tiger until I 
realised I had written more code working around its initial limitations than I 
had in my original data source methods; and now, because I'm tied to Tiger, I 
haven't been able to take advantage of the vast improvements that have come 
since then, sadly. I don't want to think about the amount of code I'll be able 
to strip out when I drop Tiger support...).

Thanks and all the best,
Keith



  
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Greg Guerin]

Bill Appleton wrote:

3) when i set the menus i have created for NSApp using setMainMenu  
then...
what? who owns them? how do i set more menus for NSApp? how do i  
get NSApp

to release the current set?



You are not responsible for NSApplication's retention or release of  
menus.  It alone is responsible for that.


You set more menus for NSApplication by calling its setMainMenu:  
method with a different set of menus.  That's all you need to know,  
and all you need to do.  What happens in NSApplication as a result of  
calling setMainMenu: is not your responsibility.


To get the current main menu, call NSApplication's mainMenu method.   
You could use this to get the current main menu, which you will not  
own unless you retain.


  -- GG

___

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 arch...@mail-archive.com

Re: NSApplicationMain question

[Michael Ash]

On Tue, Apr 27, 2010 at 11:29 AM, Thomas Clement  wrote:
>
> On Apr 27, 2010, at 4:48 PM, Michael Ash wrote:
>
>> On Tue, Apr 27, 2010 at 5:53 AM, Paul Sanders
>>  wrote:

 Um, actually the menu bar is on the primary display.  That's
 the definition of the primary display
 -- it's the one with the menu bar.  Did you perhaps mean the
 built-in display?
>>>
>>> I was speaking from memory.  My recollection is that after I
>>> moved the menu bar the primary display, as reported by NSScreen,
>>> did not change.  But it was a while ago so I could be wrong and
>>> the docs agree with you.  This implies that the primary display
>>> can change at run time.
>>
>> NSScreen does not define the concept of the "primary" screen.
>
> From the documentation of the NSScreen class:
>
> + (NSArray *)screens
>
> The screen at index 0 in the returned array corresponds to the primary
> screen of the user’s system. This is the screen that contains the menu bar
> and whose origin is at the point (0, 0).

My bad, thanks for the info.

Mike
___

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 arch...@mail-archive.com

Re: Fastest way to check for descendants of an object

[Michael Ash]

On Tue, Apr 27, 2010 at 2:05 PM, Keith Blount  wrote:
> Indeed, I believe that's my problem - currently when I add objects to my 
> children array I do things such as [[myNode children] addObject:newNode], 
> meaning I have nowhere to catch it. I'll update my code to add some accessors 
> as you suggest, and change my - (NSMutableArray *)children accessor to - 
> (NSArray *)children so that the compiler can catch any slips where I try to 
> manipulate it directly. Regarding the weak reference to the parent, I guess I 
> don't need to worry about that getting released because if it is, then so 
> will the children be, or else by then they will refer to a different parent 
> object.

One pattern which can help prevent memory management trouble with this
sort of thing is to always zero out the weak reference any time a
child is removed or the parent is destroyed. Do a setParent:nil when
you remove children, and set all of your children's parents to nil in
dealloc, and that will ensure that they don't end up trying to message
a stale reference.

Mike
___

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 arch...@mail-archive.com

Re: menu madness with retain count

[Charles Srstka]

On Apr 27, 2010, at 3:49 PM, Bill Appleton wrote:

> if i add a submenu to an item then it is retained by the menu
> 
> but then if i then set that submenu to nil is it still retained?
> 
> if retained count was accurate you could test it on final release, etc


Well, the direct answer is no, since -[NSMenuItem setSubmenu:] is just an 
accessor method, most of which in Cocoa look something like this:

- (void)setSubmenu:(NSMenu *)submenu {
if(someIvar != submenu) {
[someIvar release];
someIvar = [submenu retain];

// maybe do some other stuff
}
}

As you can see, passing nil to a setter in a Cocoa object typically causes the 
existing ivar to be released, before the new one is set to nil. There are, of 
course, variations on this - the method could use -autorelease instead of 
-release, it could use -copy instead of -retain, it could simply be a 
@synthesized setter in Mac OS X 10.5 and higher, etc. But the one thing that is 
certain is that you don’t have to worry about this sort of thing. If NSMenuItem 
was the object that retained the submenu, then NSMenuItem is the object that 
has responsibility for releasing it, not you. Once you pass the menu to 
NSMenuItem, you can be sure that NSMenuItem will do the right thing with it, 
and the only way you need to worry about it being released is if *you* are 
retaining it. If NSMenuItem were failing to release the submenu, that would be 
a bug in NSMenuItem, and not your problem. At this stage in Cocoa’s maturity, 
such a bug in such a basic class would be quite unlikely, but even assuming 
such a bug did exist, if you attempted to “fix” the bug by releasing the 
submenu yourself, then your app would crash as soon as Apple fixed the bug with 
a software update.

Charles___

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 arch...@mail-archive.com

Finder file label from cocoa?

[Rainer Standke]

Hello,

is there a way to get to the finder label of a file from Cocoa? I'd like to be 
able to get & set them.

Thanks,

Rainer___

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 arch...@mail-archive.com

Re: white screen windows at first

[Bill Appleton]

hi all,

this is helping

one thing you app migrators out there need to remember is that cocoa draws
the window before it is visible

so there is a timing issue

i will check these issues tomorrow


thanks,

bill





On Tue, Apr 27, 2010 at 4:24 PM, Jesper Storm Bache wrote:

> I though I saw that you said that you create windows before you
> call NSApplicationMain.
> If this is so, why are you getting draw operations?
> The typical use case is that you create windows after the NSApplication has
> entered its event loop. This is done as windows are flushed when
> NSApplication (internally) calls nextEventMatchingMask.
> If you create a bunch of windows outside the event loop & if it takes
> longer than 1 second to initialize then a potential window server "update
> disablement" times out and you may see flashing at the time of the first
> event. "disablement" is initiated when someone calls NSDisableScreenUpdates
> or disableScreenUpdatesUntilFlush - when this happens updates must be
> re-enabled within a second to avoid flicker. AppKit internally calls these
> methods in a number of cases (such as when it changes the frame of a
> window).
>
> You can see if the window server times out by looking at the window server
> log in the console.
>
> Jesper
>
>
>
>
> On Apr 27, 2010, at 4:01 PM, Bill Appleton wrote:
>
> i have tried that way
>
> *CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort];
> *
>
> and this way
> *
> NSWindow *mywindow;
>
> CGContextRef context = [[mywindow graphicsContext] graphicsPort];*
>
> they return the same pointer
>
> then i have also looked at the CGContextRef i get
>
> -- the transformation matrix is identity
>
> -- the clip bounds box looks fine
>
> but you can NOT draw into that cg context!
>
> later, if you resize & muck around, you can...
>
>
>
> thx
>
> bill
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 27, 2010 at 3:43 PM, Jesper Storm Bache wrote:
>
>> How do you get your coregraphics context?
>> You should do:
>>
>> CGContextRef context = reinterpret_cast([[NSGraphicsContext
>> currentContext] graphicsPort]);
>>
>> Jesper Storm Bache
>>
>> On Apr 27, 2010, at 3:36 PM, Bill Appleton wrote:
>>
>> > this problem must be because i am using core graphics
>> >
>> > i painted a big red rectangle in drawRect and then went on and called my
>> > core graphics code
>> >
>> > the big red rectangle comes up every time
>> >
>> > but only after resizing do i see the stuff i draw with core graphics
>> >
>> > so i am getting the draw rect events but for some reason i am using core
>> > graphics wrong or didn't set it up right to be used
>> >
>> > does this make sense to anybody?
>> >
>> >
>> > thanks,
>> >
>> > bill
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Apr 27, 2010 at 1:41 PM, Uli Kusterer
>> > wrote:
>> >
>> >> On 27.04.2010, at 00:10, Bill Appleton wrote:
>> >>> i added flush window to the drawRect method -- no help
>> >>>
>> >>> it IS calling draw rect right before the window is shown & then you
>> see
>> >> it
>> >>> --- all white
>> >>
>> >> Oh, also: if your code throws exceptions, those can abort important
>> >> processes like redraws, you may want to set breakpoints on C++ throws
>> and
>> >> objc_exception_throw and see if any of these gets triggered and by
>> whom.
>> >> Also, throwing C++ exceptions through C or ObjC code and ObjC
>> exceptions
>> >> through C or C++ code can royally screw you.
>> >>
>> >> -- Uli Kusterer
>> >> "The Witnesses of TeachText are everywhere..."
>> >> http://www.masters-of-the-void.com
>> >>
>> >>
>> >>
>> >>
>> > ___
>> >
>> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> >
>> > Please do not post admin requests or moderator comments to the list.
>> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> >
>> > Help/Unsubscribe/Update your Subscription:
>> > http://lists.apple.com/mailman/options/cocoa-dev/jsbache%40adobe.com
>> >
>> > This email sent to jsba...@adobe.com
>>
>>
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Finder file label from cocoa?

[Sean McBride]

Rainer Standke (li...@standke.com) on 2010-04-27 20:14 said:

>Hello,
>
>is there a way to get to the finder label of a file from Cocoa? I'd like
>to be able to get & set them.

In 10.6 you can use NSWorkspace's:

- (NSArray *)fileLabels
- (NSArray *)fileLabelColors

On older OSes, you'll need to use the Core Services (aka Carbon) File
Manager.  Check Files.h.

Sean


___

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 arch...@mail-archive.com

Getting a bezier path for a character

[danchik]

Hi, I been trying to figure out how to get the Bezier path for a character
in different fonts,
but can't quiet figure out why things dont work in some fonts.

Some (many) fonts do not rednder the right path for the glyph,
a 'W' in in "Arial Black" for example is fine (looks like W), but in
"Arial Hebrew" it looks like a J
in some other fonts it just looks like a square box (as it is missing) yet
it does exist in that font if I just use TextEdit for example

I did something like this to get the path:

NSTextStorage* storage = [[[NSTextStorage alloc] initWithString:@"W"]
autorelease];
NSLayoutManager* layout = [[[NSLayoutManager alloc] init] autorelease];
NSFont *font = [NSFont fontWithName:FONT_NAME_HERE size:200];

[layout setTextStorage:storage];

NSGlyph glyph = [layout glyphAtIndex:gindex];

NSBezierPath path = [NSBezierPath bezierPath];
[path moveToPoint: NSMakePoint(0, -[font descender])];
[path appendBezierPathWithGlyphs: &glyph count: 1 inFont: font];


I even tried avoiding the layout manager all together by making NSImage
and pulling glyph from font:
NSGlyph glyph = [font glyphWithName:@"W"];
then locking focus on image before getting the bezierpath:inFont but same
results

Any help would be apreciated
Thank You


___

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 arch...@mail-archive.com

Design for cleaning up Undo for a tree of objects

[Graham Cox]

Hi all, got a bit of an architectural issue that I'm having a problem solving, 
so I thought I'd throw it out there and see if anyone can offer a way forward.

I have a tree of objects of various kinds. Each node in the tree keeps a weak 
reference to its parent node. These references are nilled out whenever a node 
is removed from its parent, and set whenever they are added. The root of the 
tree is owned by a document (indirectly, but it amounts to that). The root of 
the tree also refers to the document's undo manager.

Various changes to properties of nodes are undoable. This is accomplished by 
the node getting the undo manager from the root. It does this by traversing 
upwards through the tree to the root - it does not keep a ref to the undo 
manager itself. Once obtained, the node sets up the undo task directly using 
the undo manager. Typically the node is the task's target, so is not retained 
by the undo manager.

Here's the problem: Any tasks on the undo stack that refer to a particular 
target must be removed when that target is dealloced. Obviously the clear place 
to do this is in the -dealloc method. That's fine if the node is still part of 
the tree at that point, but there's no guarantee that it is. If it is not, it 
cannot obtain the undo manager needed to remove itself from.

It might seem that when the parent of a node is set to nil (on removal, for 
example), that could also be the time to clean out any undo tasks pertaining to 
that object. Unfortunately that isn't the case - the object might be being 
temporarily removed only to be re-added elsewhere, so any undos relating to it 
would get cleaned out when they might still be required.

I'm thinking that maybe each node needs a weak ref to the undo manager so that 
it can find it at dealloc time, but given the potentially thousands of nodes 
that's an awful lot of extra pointers that are not needed at the moment. It 
also creates the headache of needing to ensure that the ref is never stale, for 
example if a node is moved to a tree belonging to another document the ref will 
need to be updated.

Is there another solution I'm missing?

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Getting a bezier path for a character

[Jens Alfke]

On Apr 27, 2010, at 6:45 PM, danc...@rebelbase.com wrote:


Some (many) fonts do not rednder the right path for the glyph,
a 'W' in in "Arial Black" for example is fine (looks like W), but in
"Arial Hebrew" it looks like a J
in some other fonts it just looks like a square box (as it is  
missing) yet

it does exist in that font if I just use TextEdit for example


You might be running into font substitution. Not every font has glyphs  
for every character, so the text system will substitute missing glyphs  
from some other fallback font. So for example if I look at Arial  
Hebrew in Font Book and check the Repertoire preview, it doesn't show  
any Roman letters, only Hebrew ones (and Roman digits.) Thus, I think  
the "W" you see is substituted from a different font, probably regular  
Arial or Lucida Grande.


I haven't used the glyph APIs before, but I'd guess that the NSGlyph  
ID you get is for the effective font, not necessarily the one you  
specified. Thus the mismatch.


—Jens___

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 arch...@mail-archive.com

Re: Design for cleaning up Undo for a tree of objects

[Jens Alfke]

On Apr 27, 2010, at 6:55 PM, Graham Cox wrote:

Here's the problem: Any tasks on the undo stack that refer to a  
particular target must be removed when that target is dealloced.


I don't know your app, but this sounds backwards to me. Don't tasks/ 
nodes need to be kept around for as long as an undo item refers to  
them? Otherwise, what happens when the user tries to undo/redo that  
step?


In other words, I would expect that an undo item would have strong  
references to the tree nodes it affects.


—Jens___

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 arch...@mail-archive.com

Re: Design for cleaning up Undo for a tree of objects

[Graham Cox]

On 28/04/2010, at 12:00 PM, Jens Alfke wrote:

> 
> On Apr 27, 2010, at 6:55 PM, Graham Cox wrote:
> 
>> Here's the problem: Any tasks on the undo stack that refer to a particular 
>> target must be removed when that target is dealloced.
> 
> I don't know your app, but this sounds backwards to me. Don't tasks/nodes 
> need to be kept around for as long as an undo item refers to them? Otherwise, 
> what happens when the user tries to undo/redo that step?
> 
> In other words, I would expect that an undo item would have strong references 
> to the tree nodes it affects.
> 
> —Jens


If the node is a parameter to an undoable operation (removeNode, addNode, e.g.) 
then that's true, the undo task retains the node. If the node is a target for a 
task however, it is not retained. The UM does not retain its targets (this 
makes sense if you consider that a document owns its UM, and a document could 
well be the target of an undo task, as well as being in line with the usual 
rule that targets are not retained).

In general the sequence of events keeps things in order - for example if a node 
is removed then an undo task exists to undo that removal which retains the node 
that was removed. Because the UM is retaining the node, other undo tasks that 
target it can still exist, so they can happily live in the undo stack with 
their weak refs and all is well. But eventually tasks might get removed from 
the undo stack, for example when its limit is reached such that old tasks are 
discarded. At that point, the remove task might get discarded, which releases 
the node, causing it to be dealloced. Other tasks still on the stack that 
target that node are now stale - they should have been removed by the dealloc 
of the node but were not.

If you notice, NSDocument calls -removeAllActionsWithTarget:self on its UM in 
its -dealloc method. This seems to me to be the right thing to do and the right 
time to do it. But the same diligence needs to be applied to all objects that 
talk directly to the undo manager, which requires that such objects can find 
the UM at -dealloc time somehow.

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Selecting an object based on the value of one of its attributes

[Lynn Barton]

Newbie question: Consider an array of dictionary objects, all of the same 
class. One of the ivars of that class is an NSString which is unique for each 
instance. Does there already exist a method that will identify the one 
dictionary object that has a given value of that ivar, without me having to 
write code to examine all of the objects one by one? I have searched the 
documentation without finding such a method.
Lynn Barton
___

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 arch...@mail-archive.com

Re: Selecting an object based on the value of one of its attributes

[Graham Cox]

On 28/04/2010, at 12:37 PM, Lynn Barton wrote:

> Newbie question: Consider an array of dictionary objects, all of the same 
> class. One of the ivars of that class is an NSString which is unique for each 
> instance. Does there already exist a method that will identify the one 
> dictionary object that has a given value of that ivar, without me having to 
> write code to examine all of the objects one by one? I have searched the 
> documentation without finding such a method.
> Lynn Barton


You could use NSPredicate to "filter" your collection based on your unique 
string property being equal to the one sought. If they are unique it will 
return exactly one item (or none, if it doesn't exist).

See [NSArray filteredArrayUsingPredicate:]

It's unclear whether that would be actually any faster than doing a linear 
search yourself - it might be slower, in that it wouldn't return as soon as it 
found the item, but would always check every element.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Selecting an object based on the value of one of its attributes

[Roland King]

Graham Cox wrote:

On 28/04/2010, at 12:37 PM, Lynn Barton wrote:



Newbie question: Consider an array of dictionary objects, all of the same 
class. One of the ivars of that class is an NSString which is unique for each 
instance. Does there already exist a method that will identify the one 
dictionary object that has a given value of that ivar, without me having to 
write code to examine all of the objects one by one? I have searched the 
documentation without finding such a method.
Lynn Barton




You could use NSPredicate to "filter" your collection based on your unique 
string property being equal to the one sought. If they are unique it will return exactly 
one item (or none, if it doesn't exist).

See [NSArray filteredArrayUsingPredicate:]

It's unclear whether that would be actually any faster than doing a linear 
search yourself - it might be slower, in that it wouldn't return as soon as it 
found the item, but would always check every element.

--Graham




I think that as Graham suggests that would be slower than searching 
yourself, but it is a method and it does exist and it's "free", so you 
could try that and if it's fast enough for you, that's great.


Actually iterating the list however yourself is very simple  and 
possibly only the same number of lines of code as making a predicate. 
(code typed in mail)


YourObject *found = nil;
for( YourObject *obj in yourArrayOfObjects )
if( [ [ obj thePropertyYouWant ] isEqualToString:yourThing ] )
{
found = obj;
break;
}
// if found isn't nil, you found one, if it is, you failed.

Finally - are these all your objects and are you always looking for the 
same property of them? If so instead of dumping them into an array you 
could build a dictionary of them as you insert them, keyed by that 
string property, then go look it up later when you want it.

___

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 arch...@mail-archive.com

Re: Selecting an object based on the value of one of its attributes

[Lynn Barton]

On Apr 27, 2010, at 8:06 PM, Roland King wrote:

> Graham Cox wrote:
>> On 28/04/2010, at 12:37 PM, Lynn Barton wrote:
>>> Newbie question: Consider an array of dictionary objects, all of the same 
>>> class. One of the ivars of that class is an NSString which is unique for 
>>> each instance. Does there already exist a method that will identify the one 
>>> dictionary object that has a given value of that ivar, without me having to 
>>> write code to examine all of the objects one by one? I have searched the 
>>> documentation without finding such a method.
>>> Lynn Barton
>> You could use NSPredicate to "filter" your collection based on your unique 
>> string property being equal to the one sought. If they are unique it will 
>> return exactly one item (or none, if it doesn't exist).
>> See [NSArray filteredArrayUsingPredicate:]
>> It's unclear whether that would be actually any faster than doing a linear 
>> search yourself - it might be slower, in that it wouldn't return as soon as 
>> it found the item, but would always check every element.
>> --Graham
> 
> I think that as Graham suggests that would be slower than searching yourself, 
> but it is a method and it does exist and it's "free", so you could try that 
> and if it's fast enough for you, that's great.
> 
> Actually iterating the list however yourself is very simple  and possibly 
> only the same number of lines of code as making a predicate. (code typed in 
> mail)
> 
> YourObject *found = nil;
> for( YourObject *obj in yourArrayOfObjects )
>if( [ [ obj thePropertyYouWant ] isEqualToString:yourThing ] )
>{
>found = obj;
>break;
>}
> // if found isn't nil, you found one, if it is, you failed.
> 
> Finally - are these all your objects and are you always looking for the same 
> property of them? If so instead of dumping them into an array you could build 
> a dictionary of them as you insert them, keyed by that string property, then 
> go look it up later when you want it.
GREAT IDEA ! I'll try it. Thanks to you and Graham.
Lynn
___

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 arch...@mail-archive.com

Re: white screen windows at first

[Jesper Storm Bache]

FYI: the screen disabling stuff is unlikely to be the issue here (as I 
mentioned in a sub-sequent email). One reason is that it only is used for 
windows that are already visible.
Both Cocoa and Carbon will send you a draw request before your window is 
visible (to avoid a white flash), so that would be the current best bet.
Good luck,
Jesper

On Apr 27, 2010, at 6:12 PM, Bill Appleton wrote:

hi all,

this is helping

one thing you app migrators out there need to remember is that cocoa draws the 
window before it is visible

so there is a timing issue

i will check these issues tomorrow


thanks,

bill





On Tue, Apr 27, 2010 at 4:24 PM, Jesper Storm Bache 
mailto:jsba...@adobe.com>> wrote:
I though I saw that you said that you create windows before you call 
NSApplicationMain.
If this is so, why are you getting draw operations?
The typical use case is that you create windows after the NSApplication has 
entered its event loop. This is done as windows are flushed when NSApplication 
(internally) calls nextEventMatchingMask.
If you create a bunch of windows outside the event loop & if it takes longer 
than 1 second to initialize then a potential window server "update disablement" 
times out and you may see flashing at the time of the first event. 
"disablement" is initiated when someone calls NSDisableScreenUpdates or 
disableScreenUpdatesUntilFlush - when this happens updates must be re-enabled 
within a second to avoid flicker. AppKit internally calls these methods in a 
number of cases (such as when it changes the frame of a window).

You can see if the window server times out by looking at the window server log 
in the console.

Jesper




On Apr 27, 2010, at 4:01 PM, Bill Appleton wrote:

i have tried that way

CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort];

and this way

NSWindow *mywindow;

CGContextRef context = [[mywindow graphicsContext] graphicsPort];

they return the same pointer

then i have also looked at the CGContextRef i get

-- the transformation matrix is identity

-- the clip bounds box looks fine

but you can NOT draw into that cg context!

later, if you resize & muck around, you can...



thx

bill










On Tue, Apr 27, 2010 at 3:43 PM, Jesper Storm Bache 
mailto:jsba...@adobe.com>> wrote:
How do you get your coregraphics context?
You should do:

CGContextRef context = reinterpret_cast([[NSGraphicsContext 
currentContext] graphicsPort]);

Jesper Storm Bache

On Apr 27, 2010, at 3:36 PM, Bill Appleton wrote:

> this problem must be because i am using core graphics
>
> i painted a big red rectangle in drawRect and then went on and called my
> core graphics code
>
> the big red rectangle comes up every time
>
> but only after resizing do i see the stuff i draw with core graphics
>
> so i am getting the draw rect events but for some reason i am using core
> graphics wrong or didn't set it up right to be used
>
> does this make sense to anybody?
>
>
> thanks,
>
> bill
>
>
>
>
>
>
>
>
>
> On Tue, Apr 27, 2010 at 1:41 PM, Uli Kusterer
> mailto:witness.of.teacht...@gmx.net>>wrote:
>
>> On 27.04.2010, at 00:10, Bill Appleton wrote:
>>> i added flush window to the drawRect method -- no help
>>>
>>> it IS calling draw rect right before the window is shown & then you see
>> it
>>> --- all white
>>
>> Oh, also: if your code throws exceptions, those can abort important
>> processes like redraws, you may want to set breakpoints on C++ throws and
>> objc_exception_throw and see if any of these gets triggered and by whom.
>> Also, throwing C++ exceptions through C or ObjC code and ObjC exceptions
>> through C or C++ code can royally screw you.
>>
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> http://www.masters-of-the-void.com
>>
>>
>>
>>
> ___
>
> Cocoa-dev mailing list 
> (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at 
> cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jsbache%40adobe.com
>
> This email sent to jsba...@adobe.com





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSCalendar date calculation anomaly

[Scott Ribe]

I have an int representing the number of days since 1/1/2001, and wish to get 
an NSDate representing that date in the system's local time zone:

NSDateComponents *dc = [[[NSDateComponents alloc] init] autorelease];
[dc setDay: numdays];
NSDate * cd = [[NSCalendar currentCalendar] dateByAddingComponents: dc toDate: 
[NSDate dateWithString: @"2001-01-01"] options: 0];
NSLog( @"date 1: %@", [cd description] );
[dc setDay: 0];
[dc setSecond: -[[NSTimeZone systemTimeZone] secondsFromGMTForDate: cd]];
cd = [[NSCalendar currentCalendar] dateByAddingComponents: dc toDate: cd 
options: 0];
NSLog( @"date 2: %@", [cd description] );

If for example numdays is the number of days from 1/1/2001 to 5/4/2010, then 
the output is this:

2010-04-27 21:33:55.803 PedCard[95387:a0f] date 1: 2010-05-03 17:00:00 -0600
2010-04-27 21:33:55.804 PedCard[95387:a0f] date 2: 2010-05-03 23:00:00 -0600

And, BTW, my current time zone is MDT, so -0600 is not correct, it should be 
-0700. So what's going on? I would expect those dates to be:

2010-05-03 17:00:00 -0700
2010-05-04 00:00:00 -0700

It seems as though some calls are using one time zone and some are using 
another??? I do not do anything in my app to set a local or default time zone, 
and I have not changed the time zone in my system preferences in a very long 
time. (Multiple reboots ago.) Add to that, the code did produce the correct 
date a few times earlier tonight... Also, it doesn't seem to make a difference 
whether I use systemTimeZone or localTimeZone.

OS X 10.6.3, Xcode 3.2.2

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: NSCalendar date calculation anomaly

[Scott Ribe]

Digging under the covers:

CFGregorianUnits gu = { 0, 0, numdays, 0, 0, 0 };
CFAbsoluteTime at = CFAbsoluteTimeAddGregorianUnits( 0, NULL, gu );
cd = [NSDate dateWithTimeIntervalSinceReferenceDate: at];
NSLog( @"date 4: %@", [cd description] );

Produces: "date 4: 2010-05-04 18:00:00 -0600", which is at least the right 
moment in time, even though it is not displayed correctly.

While trying to use the time zone explicitly:

CFGregorianUnits gu = { 0, 0, numdays, 0, 0, 0 };
CFAbsoluteTime at = CFAbsoluteTimeAddGregorianUnits( 0, CFTimeZoneCopySystem(), 
gu );
cd = [NSDate dateWithTimeIntervalSinceReferenceDate: at];
NSLog( @"date 4: %@", [cd description] );

Produces: "date 4: 2010-05-04 17:00:00 -0600", which is wronger ;-)




-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 arch...@mail-archive.com

Re: NSCalendar date calculation anomaly

[Kyle Sluder]

On Tue, Apr 27, 2010 at 8:45 PM, Scott Ribe  wrote:
> NSDate * cd = [[NSCalendar currentCalendar] dateByAddingComponents: dc 
> toDate: [NSDate dateWithString: @"2001-01-01"] options: 0];

This is a wrong. You don't need to go from a string to a date here.
You are violating the requirement laid out in the documentation: "You
must specify all fields of the format string, including the time zone
offset, which must have a plus or minus sign prefix." And if you ever
want to convert a string to a date, you should be using an
NSDateFormatter anyway.

So don't do this. Just use -initWithTimeIntervalSinceReferenceDate:
instead. The reference date is conveniently 2001-01-01 00:00:00 +.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Design for cleaning up Undo for a tree of objects

[Markus Spoettl]

On Apr 27, 2010, at 9:55 PM, Graham Cox wrote:
> Here's the problem: Any tasks on the undo stack that refer to a particular 
> target must be removed when that target is dealloced. Obviously the clear 
> place to do this is in the -dealloc method. That's fine if the node is still 
> part of the tree at that point, but there's no guarantee that it is. If it is 
> not, it cannot obtain the undo manager needed to remove itself from.
> 
> It might seem that when the parent of a node is set to nil (on removal, for 
> example), that could also be the time to clean out any undo tasks pertaining 
> to that object. Unfortunately that isn't the case - the object might be being 
> temporarily removed only to be re-added elsewhere, so any undos relating to 
> it would get cleaned out when they might still be required.
> 
> I'm thinking that maybe each node needs a weak ref to the undo manager so 
> that it can find it at dealloc time, but given the potentially thousands of 
> nodes that's an awful lot of extra pointers that are not needed at the 
> moment. It also creates the headache of needing to ensure that the ref is 
> never stale, for example if a node is moved to a tree belonging to another 
> document the ref will need to be updated.
> 
> Is there another solution I'm missing?


I'm not sure I follow entirely, I sounds like there's some information missing 
that explains why the node deletion itself isn't an undoable operation. Which 
appears to me is causing the problem. 

If it was undoable, the node would never get deallocated it would just be 
stored someplace else (UM). The target weak ref in the undo operations recorded 
before the node deletion would still be valid, and that's what's important. No?

There are probably good reasons why the node removal isn't undoable and the 
problem is legitimate, I just can't think of one right now.

Regards
Markus
--
__
Markus Spoettl

___

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 arch...@mail-archive.com