date:20081214



On Dec 14, 2008, at 6:35 AM, John Love wrote:

BOOL ExcelActive = NO;
NSWorkspace  *workSpace;
NSArray  *runningAppDictionaries;
NSDictionary *aDictionary;

workSpace = [NSWorkspace sharedWorkspace];
runningAppDictionaries = [workSpace launchedApplications];

for (aDictionary in runningAppDictionaries) {

		if ([[aDictionary valueForKey:@"NSApplicationName"]  
isEqualToString:@"Microsoft Excel"]) {

ExcelActive = YES;
break;
}

}

return ExcelActive;

Same NO return value.


Works for me.  What do you see if you NSLog the application name in  
each iteration of the loop?



for (aDictionary in runningAppDictionaries) {
		NSLog(@"app name: [...@]", [aDictionary  
valueForKey:@"NSApplicationName"]);
		if ([[aDictionary valueForKey:@"NSApplicationName"]  
isEqualToString:@"Microsoft Excel"]) {



And is there some reason you break with Cocoa coding convention by  
naming a local variable ExcelActive instead of excelActive?


--Andy

___

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

Cocoa equivalent of std::vector ?


Hi all,

I need to create an array of values of a specific type, and I'd prefer  
to have it as a set of values rather than pointer to values (mostly  
performance reasons), so not an NSMutableArray. I couldn't find  
anything in Cocoa to do this, am I missing something or is it just not  
a "Cocoa-ish" way of doing things ? :-)


Thx,

--
Guillaume
http://telegraph-road.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

Submenu in ToolbarItem

2008-12-14 Thread Gerriet M. Denkmann

I have an NSToolbar which has NSToolbarItems with [toolbarItem view] =  
NSButton.


When [toolbar displayMode] = NSToolbarDisplayModeLabelOnly and I press  
the label [toolbarItem menuFormRepresentation] shows its submenu.
Otherwise (Icon visible) [toolbarItem label] gets shown, which does  
nothing.


The documentations says: "If a toolbar item’s custom menu form  
representation has a submenu, then the toolbar drops down that submenu  
under the toolbar item in Text Only Mode"

So this is the expected behaviour.

But I want some way to get this submenu, even when the Icon (in my  
case the button) is shown.

How?

I do not insist on using NSButtons - I just need something which can  
be on or off like an NSOnOffButton.



Another (minor) problem: when the [toolbarItem menuFormRepresentation]  
is in the NSOnState, the toolbar does not show the '✓' (CHECK MARK).
So I add (or remove, depending on state) the  '✓' to the title. But  
then the overflow menu item contains two check marks: one for its  
state and another in the title. Looks kind of silly.



Kind regards,

Gerriet.

___

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: Cocoa equivalent of std::vector ?

2008-12-14 Thread Jean-Daniel Dupas



Le 14 déc. 08 à 13:34, Guillaume Laurent a écrit :


Hi all,

I need to create an array of values of a specific type, and I'd  
prefer to have it as a set of values rather than pointer to values  
(mostly performance reasons), so not an NSMutableArray. I couldn't  
find anything in Cocoa to do this, am I missing something or is it  
just not a "Cocoa-ish" way of doing things ? :-)


Thx,

--



You can use a CFArrayRef.

CFMutableArrayRef myArray = CFArrayCreateMutable(kCFAllocatorDefault,  
0, NULL);


Note that an array created with custom callback (null here) is not  
tool-free bridgable with NSArray (base methods like retain, release  
will works, but accessing the array content with NSArray methods is  
not safe).




___

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: Cocoa equivalent of std::vector ?



On Dec 14, 2008, at 13:45 , Jean-Daniel Dupas wrote:



Le 14 déc. 08 à 13:34, Guillaume Laurent a écrit :


Hi all,

I need to create an array of values of a specific type, and I'd  
prefer to have it as a set of values rather than pointer to values  
(mostly performance reasons), so not an NSMutableArray. I couldn't  
find anything in Cocoa to do this, am I missing something or is it  
just not a "Cocoa-ish" way of doing things ? :-)


Thx,

--



You can use a CFArrayRef.

CFMutableArrayRef myArray =  
CFArrayCreateMutable(kCFAllocatorDefault, 0, NULL);


Yes, a friend of mine pointed me to that solution, but as far as I can  
see, it's still an array of pointers, not an array of values (and its  
API is fugly if you ask me :-) )


--
Guillaume
http://telegraph-road.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: Cocoa equivalent of std::vector ?



On Dec 14, 2008, at 13:52 , jonat...@mugginsoft.com wrote:

You can of course use straight ahead C but if it's a Cocoa app then  
it's most effective to use the standard classes.

NSValue can used to wrap data types of constant length.


That was my first thought but I still have an array of pointers to  
NSValue objects, plus I have the penalty of encoding/decoding the value.


--
Guillaume
http://telegraph-road.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: override hide on deactivate?


On Dec 14, 2008, at 7:26 AM, Chunk 1978 wrote:

do you mean:

-=-=-=-=-

- (BOOL)hidesOnDeactivate
 {
 [self setHidden:YES];
 return NO;
 }

-=-=-=-=-

?


That wouldn't work, because setHidden: is an NSView method and  
presumably you're overriding hidesOnDeactivate in an NSWindow subclass.


From a quick test, it seems that hidesOnDeactivate is not called  
every time the app deactivates, as I think you're assuming.  It's only  
called once or twice as the window is set up.


If you need something to happen when the app activates or deactivates,  
you could either implement the corresponding application delegate  
methods or register for the corresponding notifications.  See  
applicationWillBecomeActive: and applicationWillResignActive:.


--Andy

___

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: Using NSWorkspace's launchedApplication to detect running App

2008-12-14 Thread John Love



On Dec 13, 08, at 12:21 PM, Jean-Daniel Dupas wrote:

Because operator overriding does not exists in Obj-C and so, == is a  
pointer comparaison and not a string comparaison.


use the isEqual: method to compare two object.




Thanks to everyone who chimed in .. and here are my changes:

BOOL ExcelActive = NO;
NSWorkspace  *workSpace;
NSArray  *runningAppDictionaries;
NSDictionary *aDictionary;

workSpace = [NSWorkspace sharedWorkspace];
runningAppDictionaries = [workSpace launchedApplications];

for (aDictionary in runningAppDictionaries) {

		if ([[aDictionary valueForKey:@"NSApplicationName"]  
isEqualToString:@"Microsoft Excel"]) {

ExcelActive = YES;
break;
}

}

return ExcelActive;

Same NO return value.

I then tried this variation, with the same NO return value:

NSArray *applArray;

applArray = NSWorkspace sharedWorkspace] launchedApplications]
	  filteredArrayUsingPredicate:[NSPredicate  
predicateWithFormat:
	 @"%K contains %@", @"NSApplicationName",  
@"Microsoft Excel"]]
	   
valueForKey:@"NSApplicationName"];


if ([applArray count] > 0)   return YES;
else return NO;


One footnote .. there are problems with Microsoft Excel as reported by  
HAS of appscript.  He points out difficulties with Excel, in  
particular, with respect to Excel documents.  Don't know about the app- 
level.



___

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: override hide on deactivate?

do you mean:

-=-=-=-=-

- (BOOL)hidesOnDeactivate
  {
  [self setHidden:YES];
  return NO;
  }

-=-=-=-=-

?

sure, that might work, but what i meant is that my hidesOnDeactivate
method isn't being called at all.  my original post with NSBeep() was
just a test...

On Sun, Dec 14, 2008 at 1:33 AM, Graham Cox  wrote:
>
> On 14 Dec 2008, at 1:59 pm, Chunk 1978 wrote:
>
>> i'm attempting to hide some
>> views inside the window (by setting their alpha to 0.0 )
>
>
> Wouldn't calling -setHidden:YES be a better plan?
>
> --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: Cocoa equivalent of std::vector ?



On Dec 14, 2008, at 14:05 , Ken Thomases wrote:


It's not the Cocoa way of doing things, for a whole raft of reasons.

However, if you use Objective-C++, you can just go ahead and use  
std::vector.



Thanks, I'll first try the "Cocoa way", and go C++ if I really have to.

--
Guillaume
http://telegraph-road.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: Cocoa equivalent of std::vector ?


On Dec 14, 2008, at 6:34 AM, Guillaume Laurent wrote:

I need to create an array of values of a specific type, and I'd  
prefer to have it as a set of values rather than pointer to values  
(mostly performance reasons), so not an NSMutableArray. I couldn't  
find anything in Cocoa to do this, am I missing something or is it  
just not a "Cocoa-ish" way of doing things ? :-)


It's not the Cocoa way of doing things, for a whole raft of reasons.

However, if you use Objective-C++, you can just go ahead and use  
std::vector.


Cheers,
Ken

___

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: Cocoa equivalent of std::vector ?

2008-12-14 Thread Jean-Daniel Dupas



Le 14 déc. 08 à 14:42, Guillaume Laurent a écrit :



On Dec 14, 2008, at 13:45 , Jean-Daniel Dupas wrote:



Le 14 déc. 08 à 13:34, Guillaume Laurent a écrit :


Hi all,

I need to create an array of values of a specific type, and I'd  
prefer to have it as a set of values rather than pointer to values  
(mostly performance reasons), so not an NSMutableArray. I couldn't  
find anything in Cocoa to do this, am I missing something or is it  
just not a "Cocoa-ish" way of doing things ? :-)


Thx,

--



You can use a CFArrayRef.

CFMutableArrayRef myArray =  
CFArrayCreateMutable(kCFAllocatorDefault, 0, NULL);


Yes, a friend of mine pointed me to that solution, but as far as I  
can see, it's still an array of pointers, not an array of values  
(and its API is fugly if you ask me :-) )


An Array of pointer or any value that have a size smaller or equal to  
pointer size (fit perfectly to store an array of integer).
If your value is bigger than a pointer, you will have to use the Obj-C+ 
+ 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

Notification Sent When Window Is Ordered Back?

is this possible?  what method do i override when the window is
ordered back, or has resigned as key window... i'm attempting to set
some actions into play when a window is ordered back or no longer key:

-=-=-=-

- (void)orderBack
{
NSString *updateWindowNotification = @"updateWindowNotification";
[notificationCenter postNotificationName:updateWindowNotification 
object:self];
}

-=-=-=-
___

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

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

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

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

Re: Notification Sent When Window Is Ordered Back?

2008-12-14 Thread Michael Babin


On Dec 14, 2008, at 8:50 AM, Chunk 1978 wrote:


is this possible?  what method do i override when the window is
ordered back, or has resigned as key window... i'm attempting to set
some actions into play when a window is ordered back or no longer key:

-=-=-=-

- (void)orderBack
{
NSString *updateWindowNotification = @"updateWindowNotification";
	[notificationCenter postNotificationName:updateWindowNotification  
object:self];

}

-=-=-=-


Look at the documentation for -[NSWindow resignKeyWindow] and/or - 
[NSWindow resignMainWindow]:





Note that you don't need to actually override the method for this one  
behavior (delegate method windowDidResignKey and notification  
NSWindowDidResignKeyNotification are both available).


___

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

NSDictionary valueForKeyPath:

2008-12-14 Thread jonat...@mugginsoft.com

I was surprised to learn that a hierarchy of NSDictionary objects can  
be queried with valueForKeyPath:


NSDictionary *dict0 = [NSDictionary dictionaryWithObjectsAndKeys:@"got  
me!", @"2", nil];
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:dict0,  
@"1", nil];

NSLog([dict valueForKeyPath:@"1.2"]);

This is powerful functionality.

Am I blind (again), or is this fact omitted from the docs? Or is it  
implicit from the nature of KVC?

Googling turns up references to the same functionality in WebObjects.

Jonathan Mitchell

Central Conscious Unit
http://www.mugginsoft.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: Notification Sent When Window Is Ordered Back?

honest to god, i have zero idea why this isn't working... i've simply
added this to my window's class and declared it in the header, but
when the window resigns key by switching to another app, i see the
window being ordered back, but NSLog does not output the message

-=-=-=-

- (void)windowDidResignKey:(NSNotification *)notification
{
NSLog(@"window resigned key");
}

-=-=-=-

On Sun, Dec 14, 2008 at 10:07 AM, Michael Babin  wrote:
> On Dec 14, 2008, at 8:50 AM, Chunk 1978 wrote:
>
>> is this possible?  what method do i override when the window is
>> ordered back, or has resigned as key window... i'm attempting to set
>> some actions into play when a window is ordered back or no longer key:
>>
>> -=-=-=-
>>
>> - (void)orderBack
>>{
>>NSString *updateWindowNotification = @"updateWindowNotification";
>>[notificationCenter postNotificationName:updateWindowNotification
>> object:self];
>>}
>>
>> -=-=-=-
>
> Look at the documentation for -[NSWindow resignKeyWindow] and/or -[NSWindow
> resignMainWindow]:
>
> 
>
> Note that you don't need to actually override the method for this one
> behavior (delegate method windowDidResignKey and notification
> NSWindowDidResignKeyNotification are both available).
>
>
___

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: Notification Sent When Window Is Ordered Back?

i've set the window class to be it's own delegate:

- (id)init
{
if (self = [super init])
{
[self setDelegate:self];
}
return self;
}

so shouldn't writing this method in the window's class work?

- (void)windowDidResignKey:(NSNotification *)notification
{
NSLog(@"window resigned key");
}

??

On Sun, Dec 14, 2008 at 10:28 AM, Chunk 1978  wrote:
> honest to god, i have zero idea why this isn't working... i've simply
> added this to my window's class and declared it in the header, but
> when the window resigns key by switching to another app, i see the
> window being ordered back, but NSLog does not output the message
>
> -=-=-=-
>
> - (void)windowDidResignKey:(NSNotification *)notification
>{
>NSLog(@"window resigned key");
>}
>
> -=-=-=-
>
> On Sun, Dec 14, 2008 at 10:07 AM, Michael Babin  wrote:
>> On Dec 14, 2008, at 8:50 AM, Chunk 1978 wrote:
>>
>>> is this possible?  what method do i override when the window is
>>> ordered back, or has resigned as key window... i'm attempting to set
>>> some actions into play when a window is ordered back or no longer key:
>>>
>>> -=-=-=-
>>>
>>> - (void)orderBack
>>>{
>>>NSString *updateWindowNotification = @"updateWindowNotification";
>>>[notificationCenter postNotificationName:updateWindowNotification
>>> object:self];
>>>}
>>>
>>> -=-=-=-
>>
>> Look at the documentation for -[NSWindow resignKeyWindow] and/or -[NSWindow
>> resignMainWindow]:
>>
>> 
>>
>> Note that you don't need to actually override the method for this one
>> behavior (delegate method windowDidResignKey and notification
>> NSWindowDidResignKeyNotification are both available).
>>
>>
>
___

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: NSDictionary valueForKeyPath:


On Dec 14, 2008, at 9:21 AM, jonat...@mugginsoft.com wrote:

I was surprised to learn that a hierarchy of NSDictionary objects  
can be queried with valueForKeyPath:


NSDictionary *dict0 = [NSDictionary  
dictionaryWithObjectsAndKeys:@"got me!", @"2", nil];
NSDictionary *dict = [NSDictionary  
dictionaryWithObjectsAndKeys:dict0, @"1", nil];

NSLog([dict valueForKeyPath:@"1.2"]);

This is powerful functionality.

Am I blind (again), or is this fact omitted from the docs? Or is it  
implicit from the nature of KVC?


It's implicit in two facts:

1) The default implementation of -valueForKeyPath: resolves down to a  
series of -valueForKey: calls
2) The override of -valueForKey: on NSDictionary resolves to a call to  
-objectForKey: in most cases


Cheers,
Ken

___

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: Notification Sent When Window Is Ordered Back?

NSWindow has no instance method named windowDidResignKey:.  Michael  
referred you to a *delegate* method with that name, and an *instance*  
method named resignKeyWindow.


It might help to slow down and read these emails and the docs they  
refer to a little more carefully. :)


--Andy


On Dec 14, 2008, at 10:28 AM, Chunk 1978 wrote:


honest to god, i have zero idea why this isn't working... i've simply
added this to my window's class and declared it in the header, but
when the window resigns key by switching to another app, i see the
window being ordered back, but NSLog does not output the message

-=-=-=-

- (void)windowDidResignKey:(NSNotification *)notification
{
NSLog(@"window resigned key");
}

-=-=-=-

On Sun, Dec 14, 2008 at 10:07 AM, Michael Babin  
 wrote:

On Dec 14, 2008, at 8:50 AM, Chunk 1978 wrote:


is this possible?  what method do i override when the window is
ordered back, or has resigned as key window... i'm attempting to set
some actions into play when a window is ordered back or no longer  
key:


-=-=-=-

- (void)orderBack
  {
  NSString *updateWindowNotification =  
@"updateWindowNotification";
  [notificationCenter  
postNotificationName:updateWindowNotification

object:self];
  }

-=-=-=-


Look at the documentation for -[NSWindow resignKeyWindow] and/or - 
[NSWindow

resignMainWindow]:




Note that you don't need to actually override the method for this one
behavior (delegate method windowDidResignKey and notification
NSWindowDidResignKeyNotification are both available).



___

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/aglee%40mac.com

This email sent to ag...@mac.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: NSDictionary valueForKeyPath:

2008-12-14 Thread jonat...@mugginsoft.com



On 14 Dec 2008, at 16:06, Ken Thomases wrote:



I was surprised to learn that a hierarchy of NSDictionary objects  
can be queried with valueForKeyPath:


NSDictionary *dict0 = [NSDictionary  
dictionaryWithObjectsAndKeys:@"got me!", @"2", nil];
NSDictionary *dict = [NSDictionary  
dictionaryWithObjectsAndKeys:dict0, @"1", nil];

NSLog([dict valueForKeyPath:@"1.2"]);

This is powerful functionality.

Am I blind (again), or is this fact omitted from the docs? Or is it  
implicit from the nature of KVC?


It's implicit in two facts:

1) The default implementation of -valueForKeyPath: resolves down to  
a series of -valueForKey: calls
2) The override of -valueForKey: on NSDictionary resolves to a call  
to -objectForKey: in most cases



Thanks Ken

The docs on NSDictionary -valueForKey: do mention it.
Blind and stupid.

Jonathan Mitchell

Central Conscious Unit
http://www.mugginsoft.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: Notification Sent When Window Is Ordered Back?

oh... woops!  ha... this coffee hasn't kicked in yet... sorry about that...   :)

On Sun, Dec 14, 2008 at 11:08 AM, Andy Lee  wrote:
> NSWindow has no instance method named windowDidResignKey:.  Michael referred
> you to a *delegate* method with that name, and an *instance* method named
> resignKeyWindow.
>
> It might help to slow down and read these emails and the docs they refer to
> a little more carefully. :)
>
> --Andy
>
>
> On Dec 14, 2008, at 10:28 AM, Chunk 1978 wrote:
>
>> honest to god, i have zero idea why this isn't working... i've simply
>> added this to my window's class and declared it in the header, but
>> when the window resigns key by switching to another app, i see the
>> window being ordered back, but NSLog does not output the message
>>
>> -=-=-=-
>>
>> - (void)windowDidResignKey:(NSNotification *)notification
>>{
>>NSLog(@"window resigned key");
>>}
>>
>> -=-=-=-
>>
>> On Sun, Dec 14, 2008 at 10:07 AM, Michael Babin 
>> wrote:
>>>
>>> On Dec 14, 2008, at 8:50 AM, Chunk 1978 wrote:
>>>
 is this possible?  what method do i override when the window is
 ordered back, or has resigned as key window... i'm attempting to set
 some actions into play when a window is ordered back or no longer key:

 -=-=-=-

 - (void)orderBack
  {
  NSString *updateWindowNotification = @"updateWindowNotification";
  [notificationCenter postNotificationName:updateWindowNotification
 object:self];
  }

 -=-=-=-
>>>
>>> Look at the documentation for -[NSWindow resignKeyWindow] and/or
>>> -[NSWindow
>>> resignMainWindow]:
>>>
>>>
>>> 
>>>
>>> Note that you don't need to actually override the method for this one
>>> behavior (delegate method windowDidResignKey and notification
>>> NSWindowDidResignKeyNotification are both available).
>>>
>>>
>> ___
>>
>> 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/aglee%40mac.com
>>
>> This email sent to ag...@mac.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: Notification Sent When Window Is Ordered Back?

2008-12-14 Thread James Bucanek

Chunk 1978  wrote (Sunday, December 14, 2008 8:28 
AM -0500):

> honest to god, i have zero idea why this isn't working...

> - (void)windowDidResignKey:(NSNotification *)notification
>   {
>   NSLog(@"window resigned key");
>   }

Probably because it's resignKeyWindow: not windowDidResignKey:

-- 
James Bucanek

___

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

Cocoa Development in Bratislava ?

2008-12-14 Thread Gustavo Pizano

Hello I just wanted to know if there is any person (Company) who  
develops in Cocoa in Bratislava (Slovakia).


Thanks

Gustavo
 
___


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: Notification Sent When Window Is Ordered Back?

ok... so here's a strange issue:

resigning the key window works fine

-=-=-=-
- (void)resignKeyWindow
{
NSLog (@"Out");
}
-=-=-=-

but if i also include the following method, resignKeyWindow no longer
works, and i only receive logs for becomeKeyWindow:

-=-=-=- 
- (void)becomeKeyWindow
{
NSLog (@"In");
}
-=-=-=-

writing instead becomeMainWindow works better, but in order for it to
work i need to set canBecomeKeyWindow:NO on all the other windows
produced by this window (like the NSColorPanel)...


On Sun, Dec 14, 2008 at 11:34 AM, James Bucanek  wrote:
> Chunk 1978  wrote (Sunday, December 14, 2008 8:28 
> AM -0500):
>
>> honest to god, i have zero idea why this isn't working...
>
>> - (void)windowDidResignKey:(NSNotification *)notification
>>   {
>>   NSLog(@"window resigned key");
>>   }
>
> Probably because it's resignKeyWindow: not windowDidResignKey:
>
> --
> James Bucanek
>
>
___

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: Notification Sent When Window Is Ordered Back?

2008-12-14 Thread jonat...@mugginsoft.com


ok... so here's a strange issue:

resigning the key window works fine

-=-=-=-
- (void)resignKeyWindow
{
NSLog (@"Out");
}
-=-=-=-

but if i also include the following method, resignKeyWindow no longer
works, and i only receive logs for becomeKeyWindow:

-=-=-=- 
- (void)becomeKeyWindow
{
NSLog (@"In");
}
-=-=-=-

You seem a bit mixed up here (but then it is Cocoa).
Have you subclassed NSWindow or are you using a delegate?
SubClassing NSWindow is tricker than using the delegate approach.

-becomeKeyWindow is not a delegate method but a class method.
If you override it in an NSWindow subclass and don't pass it on to the  
super class you will muck up the window handling.


You don't need to read the Cocoa docs you need to inject them into  
your bloodstream!




writing instead becomeMainWindow works better, but in order for it to
work i need to set canBecomeKeyWindow:NO on all the other windows
produced by this window (like the NSColorPanel)...


On Sun, Dec 14, 2008 at 11:34 AM, James Bucanek > wrote:
Chunk 1978  wrote (Sunday, December 14,  
2008 8:28 AM -0500):



honest to god, i have zero idea why this isn't working...



- (void)windowDidResignKey:(NSNotification *)notification
{
NSLog(@"window resigned key");
}


Probably because it's resignKeyWindow: not windowDidResignKey:

--
James Bucanek



___

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/jonathan%40mugginsoft.com

This email sent to jonat...@mugginsoft.com


Jonathan Mitchell

Central Conscious Unit
http://www.mugginsoft.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: nib loading / displaying question.

2008-12-14 Thread Bill Bumgarner


On Dec 13, 2008, at 11:56 PM, aaron smith wrote:

Ah, yeah that was it. And I had the "release when closed" box checked
in IB, which was causing it to crash. Unchecked that and we're all
good.


Sort of.

How many times will the user display the about panel in an average  
session of working with your app?


Most likely, the answer is once.

Given that, do you really want to cash the about panel and all related  
objects?   CPU wise, it costs nothing.  Memory wise, it is a bunch of  
objects.   As well, there is the window server's bit of bookkeeping  
related to the window.


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: Cancel CGEvent

2008-12-14 Thread sheen mac


Hi,

I tried that, passed NULL at the callback.
But it didn't works MouseMove event. All other
cases of mouse its works good.



Thanks In Advance,
Sheen 




--- On Sun, 12/14/08, Jean-Daniel Dupas  wrote:

> From: Jean-Daniel Dupas 
> Subject: Re: Cancel CGEvent
> To: sheen4...@yahoo.com
> Cc: cocoa-dev@lists.apple.com
> Date: Sunday, December 14, 2008, 12:09 AM
> Le 13 déc. 08 à 19:19, sheen mac a écrit :
> 
> > Hi All,
> > 
> > Is  it possible to cancel CGEvent for mouse at
> CGEventTrapCallBack ?.
> > Could suggest some link info?.
> > 
> > Thanks In Advance,
> > Sheen
> 
> 
> From the CGEventTapCallBack reference:
> 
> If the event tap is an active filter, your callback
> function should return one of the following:
> 
>   • The (possibly modified) event that is passed in. This
> event is passed back to the event system.
> 
>   • A newly-constructed event. After the new event has
> been passed back to the event system, the new event will be
> released along with the original event.
> 
>   • NULL if the event passed in is to be deleted.
> 
> 
> 
> Did you try that and it didn't work, or have you just
> miss that in the reference ?



___

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: open package installer in bundle resources directory not working

On Sat, Dec 13, 2008 at 5:28 PM, Iceberg-Dev  wrote:
>
> On Dec 13, 2008, at 12:46 PM, Kyle Sluder wrote:
>
>> 3) Why all this trouble of launching executables?  There's a reason
>> Launch Services is a public framework; use that.  Don't use
>> -[NSWorkspace openFile:], because that's not guaranteed to open the
>> package in Installer.app.  Instead, use LSOpenURLsWithRole:
>>
>> http://developer.apple.com/DOCUMENTATION/Carbon/Reference/LaunchServicesReference/Reference/reference.html#//apple_ref/doc/uid/TP3998-CH1g-TPXREF104
>
> Just in case:
>
> I've been using NSWorkspace exactly for this for more than 6 years now.
>
> Still waiting for a report from a user stating it does not open
> Installer.app but another application...

Although it's only about ten more seconds of typing to use
-openFile:withApplication: instead and simply avoid the possibility
altogether.

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: NSTimer EXC_BAD_ACCESS

2008-12-14 Thread Jens Bauer

That's an easy one. -Easy for me, because I had much trouble with it  
earlier. =)


Remember to retain your timer:

- (void)timerStop
{
if(timer)
{
[timer invalidate];
[timer release];
timer = NULL;
}
}

- (void)timerStart:(double)aSecondInterval
{
[self timerStop];
	timer = [[NSTimer scheduledTimerWithTimeInterval:aSecondInterval  
target:self selector:@selector(_updateDisplay:) userInfo:NULL  
repeats:YES] retain];

}

...and make timer a member variable of your class.

You probably experience your crash, because the timer is autoreleased.  
If you retain it, it'll live. However, you'll have to remember the  
timer object, so you can stop it later, so add NSTimer *timer; as a  
member variable of your class...


- (void)dealloc
{
[self timerStop];
[super dealloc];
}


Love,
Jens

On Dec 14, 2008, at 06:07, Daniel Luis dos Santos wrote:


Hello,

I have a NSTimer that is created every time I press a button. It  
then calls the update function successively until some amount of  
time passes.
When I press the button again I get a EXC_BAD_ACCESS on the timer's  
initialization :


	NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval: step  
target: self

selector: @selector(_updateDisplay:) userInfo: nil repeats: 
YES];

step is a double, and _updateDisplay has the right signature.
The stack trace is something like :

#0  0x90705558 in tiny_malloc_from_free_list
#1  0x906fe3ed in szone_malloc
#2  0x906fe2f8 in malloc_zone_malloc
#3  0x932b9451 in _CFRuntimeCreateInstance
#4  0x9327f844 in CFDateCreate
#5	0x93329f63 in -[__NSPlaceholderDate  
initWithTimeIntervalSinceReferenceDate:]

#6  0x9332a7fd in +[NSDate dateWithTimeIntervalSinceNow:]
#7	0x9034aa3f in +[NSTimer(NSTimer)  
scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:]


I haven't any idea,...

___

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/jensbauer%40christian.net

This email sent to jensba...@christian.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: [ANN] AppKiDo{-for-iPhone} 0.982


On Dec 11, 2008, at 5:41 PM, Andy Lee wrote:

Release notes to come later -- gotta run to CocoaHeads...


Release notes are now posted:



--Andy




http://homepage.mac.com/aglee/downloads/AppKiDo-0.982.tgz
http://homepage.mac.com/aglee/downloads/AppKiDo-for-iPhone-0.982.tgz

Same source code for both:

http://homepage.mac.com/aglee/downloads/AppKiDo-src-0.982.tgz

--Andy



___

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: open package installer in bundle resources directory not working

2008-12-14 Thread Kyle Sluder

On Sun, Dec 14, 2008 at 2:03 PM, Michael Ash  wrote:
> Although it's only about ten more seconds of typing to use
> -openFile:withApplication: instead and simply avoid the possibility
> altogether.

If you're using this method, make sure to use -[NSWorkspace
absolutePathForAppBundleWithIdentifier:] to get the path for the
second argument.

(And yes, I recommended Launch Services because I overlooked this method.)

--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: NSTimer EXC_BAD_ACCESS

2008-12-14 Thread mmalc Crawford



On Dec 14, 2008, at 11:52 AM, Jens Bauer wrote:


because the timer is autoreleased.

This is not the case -- see  ("Memory Management").


mmalc

___

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

Accepting iCal events dropped on my application's icon

2008-12-14 Thread Yang Meyer


Hello,

I am trying to enable dropping dragged iCal events onto my Cocoa  
application's icon, e.g. in the Dock.


While it was fairly straightforward to support ICS files that are  
dragged from the Finder (setting NSFilenamesPboardType with extension  
"ics" in the target's document types, and implementing - 
(BOOL)application:(NSApplication *)sender openFile:(NSString *)path in  
my application's delegate), I haven't been able to support iCal events  
that are dragged directly from iCal.


I analogously tried defining a document type for what I presume will  
be an NSFilesPromisePboardType, but I'm not sure what to put in the  
fields. Neither using extension "ics" nor MIME type "text/calendar"  
works. As for my NSFilenamesPboardType document type, I set the Store  
Type to "In memory".


So in essence my question is: How can I tell my application to accept  
iCal events dragged directly from the iCal GUI?


If you have any tips or pointers, I'd be very grateful!

Thanks,
Yang
___

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

Unexpected behaviour with autorelease pool

2008-12-14 Thread Krishna Kotecha

Hi,

I am seeing some unexpected behaviour and was hoping someone might be able
to shed some light on this.

I have a basic Counter class. The relevant methods for the problem are:

-init
{
if (self = [super init]) {
//counter = [[NSNumber alloc] init];
counter = [NSNumber numberWithInt:0];  // lets grab an autorelease object
}
return self;
}

-(void) dealloc
{
[counter release];
[super dealloc];
}

I also have some client code (a Foundation Tool project):

int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

// Next two lines will cause a runtime error. I understand this, as I am
releasing
// an object I dont own...
//
// NSNumber* myNumber = [NSNumber numberWithInt:22];
// [myNumber release];

// Question: Why don't the next 2 lines cause a runtime error?
// In the Counter:dealloc method, I am also releasing an object I dont
own...
 Counter* myCounter = [[Counter alloc] init];
[myCounter release];

[pool drain];
return 0;
}

As the comment say, I would expect an error to occur due the fact
Counter:dealloc: is releasing an autorelease object. However the application
exits cleanly.

Shouldn't this code be causing an error at some point? And if not, why not?

Any insights or explanations any one has on this would be appreciated.
Thanks.

Regards,

Krishna
___

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

Problem with Bindings, Core Data, Data Model, NSPathControl

2008-12-14 Thread Keith Lander

I am fairly new to Cocoa (but not programming). I have a data model  
containing an entity with a String attribute representing a path to a  
folder. I am trying to use IB to bind an NSPathControl widget to the  
attribute in the window controller. I assume I need a value  
transformer to convert NSURL to String and back. I have written a  
crude one to do this, but it fails. In IB I have set the content path  
to the attribute name and the value transformer to the name of the  
transformer class. When I run the app the transformer is called during  
initialisation, but the value passed is an instance of NSCVString,  
which makes no sense to me.


Has anyone any idea what could be wrong or could point me to a  
tutorial that deals with this.


Cheers
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: Unexpected behavior with autorelease pool

2008-12-14 Thread Nick Zitzmann



On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote:


As the comment say, I would expect an error to occur due the fact
Counter:dealloc: is releasing an autorelease object. However the  
application

exits cleanly.

Shouldn't this code be causing an error at some point? And if not,  
why not?



No, it should not. It is perfectly legal for autorelease pools to  
release memory created by other objects. It would, however, cause a  
crash if the pool was popped before the object with the number was  
released, and you tried to access the number pointer. It would only  
cause a runtime error instead of a crash if you had zombies turned on.


Nick Zitzmann




___

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: Unexpected behaviour with autorelease pool

I think I have found the answer to your question; when executing the  
following code, I get a few strange results...


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSNumber *n0 = [NSNumber numberWithInt:1];
NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSNumber *n1 = [NSNumber alloc];
NSLog(@"n1: %d", [n1 retainCount]);
n1 = [n1 initWithInt:1];
NSLog(@"n1: %d", [n1 retainCount]);
[n1 release];

[pool release];

The code above results in the following log:
2008-12-14 22:32:54.997 SmallTest[556:10b] n0: 2 <===  
Thats strange

2008-12-14 22:32:55.003 SmallTest[556:10b] n0: 1

2008-12-14 22:32:55.004 SmallTest[556:10b] n1: -1 <===  
That is normal
2008-12-14 22:32:55.005 SmallTest[556:10b] n1: 2 <===  
Whow, overretained an object ;-)


My guess is that NSNumber is over-retaining itself within its  
initializer. Nothing for you to worry about.
This is a typical worry-case for that nice Apple programmer... You  
should file a bug-report...


Filip van der Meeren
fi...@code2develop.com
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 18:55, Krishna Kotecha wrote:


Hi,

I am seeing some unexpected behaviour and was hoping someone might  
be able

to shed some light on this.

I have a basic Counter class. The relevant methods for the problem  
are:


-init
{
if (self = [super init]) {
//counter = [[NSNumber alloc] init];
counter = [NSNumber numberWithInt:0];  // lets grab an autorelease  
object

}
return self;
}

-(void) dealloc
{
[counter release];
[super dealloc];
}

I also have some client code (a Foundation Tool project):

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

// Next two lines will cause a runtime error. I understand this, as  
I am

releasing
// an object I dont own...
//
// NSNumber* myNumber = [NSNumber numberWithInt:22];
// [myNumber release];

// Question: Why don't the next 2 lines cause a runtime error?
// In the Counter:dealloc method, I am also releasing an object I dont
own...
Counter* myCounter = [[Counter alloc] init];
[myCounter release];

   [pool drain];
   return 0;
}

As the comment say, I would expect an error to occur due the fact
Counter:dealloc: is releasing an autorelease object. However the  
application

exits cleanly.

Shouldn't this code be causing an error at some point? And if not,  
why not?


Any insights or explanations any one has on this would be appreciated.
Thanks.

Regards,

Krishna
___

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/filip%40code2develop.com

This email sent to fi...@code2develop.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: Problem with Bindings, Core Data, Data Model, NSPathControl

2008-12-14 Thread Quincey Morris


On Dec 14, 2008, at 09:59, Keith Lander wrote:

I am fairly new to Cocoa (but not programming). I have a data model  
containing an entity with a String attribute representing a path to  
a folder. I am trying to use IB to bind an NSPathControl widget to  
the attribute in the window controller. I assume I need a value  
transformer to convert NSURL to String and back. I have written a  
crude one to do this, but it fails. In IB I have set the content  
path to the attribute name and the value transformer to the name of  
the transformer class. When I run the app the transformer is called  
during initialisation, but the value passed is an instance of  
NSCVString, which makes no sense to me.


The value transformer is on the path control binding? Then it makes  
sense that your transformer should be invoked to transform a string to  
a url. (That is, the forward direction of the transformer goes from  
model class to interface class.) Are you expecting the reverse  
direction?



___

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: Unexpected behaviour with autorelease pool


On Dec 14, 2008, at 3:36 PM, Filip van der Meeren wrote:

I think I have found the answer to your question; when executing the  
following code, I get a few strange results...


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSNumber *n0 = [NSNumber numberWithInt:1];
NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSNumber *n1 = [NSNumber alloc];
NSLog(@"n1: %d", [n1 retainCount]);
n1 = [n1 initWithInt:1];
NSLog(@"n1: %d", [n1 retainCount]);
[n1 release];

[pool release];

The code above results in the following log:
2008-12-14 22:32:54.997 SmallTest[556:10b] n0: 2 <===  
Thats strange

2008-12-14 22:32:55.003 SmallTest[556:10b] n0: 1

2008-12-14 22:32:55.004 SmallTest[556:10b] n1: -1 <===  
That is normal
2008-12-14 22:32:55.005 SmallTest[556:10b] n1: 2 <===  
Whow, overretained an object ;-)


My guess is that NSNumber is over-retaining itself within its  
initializer. Nothing for you to worry about.
This is a typical worry-case for that nice Apple programmer... You  
should file a bug-report...


This is why examining retain counts will only confuse you.

It is perfectly reasonable for NSNumber to vend cached, shared copies  
of commonly used values.  For example, 0 or 1.


Stop trying to figure out what the retain count "should be" at any  
given point, nor having expectations about when exactly an object will  
be fully released and hence deallocated.


Just pay attention to your own responsibilities.

Regards,
Ken

___

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: Unexpected behaviour with autorelease pool

2008-12-14 Thread Nick Zitzmann



On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote:


-(void) dealloc
{
[counter release];
[super dealloc];
}



Guess what I overlooked? My apologies; Flip is probably correct.

Nick Zitzmann




___

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: Unexpected behaviour with autorelease pool

2008-12-14 Thread Jean-Daniel Dupas



Le 14 déc. 08 à 22:36, Filip van der Meeren a écrit :

I think I have found the answer to your question; when executing the  
following code, I get a few strange results...


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSNumber *n0 = [NSNumber numberWithInt:1];
NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSNumber *n1 = [NSNumber alloc];
NSLog(@"n1: %d", [n1 retainCount]);
n1 = [n1 initWithInt:1];
NSLog(@"n1: %d", [n1 retainCount]);
[n1 release];

[pool release];

The code above results in the following log:
2008-12-14 22:32:54.997 SmallTest[556:10b] n0: 2 <===  
Thats strange

2008-12-14 22:32:55.003 SmallTest[556:10b] n0: 1

2008-12-14 22:32:55.004 SmallTest[556:10b] n1: -1 <===  
That is normal
2008-12-14 22:32:55.005 SmallTest[556:10b] n1: 2 <===  
Whow, overretained an object ;-)


My guess is that NSNumber is over-retaining itself within its  
initializer. Nothing for you to worry about.
This is a typical worry-case for that nice Apple programmer... You  
should file a bug-report...



DO NOT MAKE ANY assumption over retainCount. NSNumber is not over  
retaining, it is caching small number for efficiency. This is not a bug

Respect the Memory management rules and all will be fine.

___

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: Unexpected behaviour with autorelease pool


Thank you, I was just replying to your mail ;-)

Filip van der Meeren
fi...@code2develop.com
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 22:49, Nick Zitzmann wrote:



On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote:


-(void) dealloc
{
[counter release];
[super dealloc];
}



Guess what I overlooked? My apologies; Flip is probably correct.

Nick Zitzmann




___

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/filip%40code2develop.com

This email sent to fi...@code2develop.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: Unexpected behaviour with autorelease pool


If you allocate the object yourself, like the following:


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSNumber *n = nil;
NSInteger wh = 0;

srand(time(NULL));
for(int i = 0; i < 100 * 1000; ++i)
{
n = [[NSNumber alloc] initWithInt:rand()];
if([n retainCount])
++wh;
[n release];
}

NSLog(@"Result: %d", wh);

[pool release];

then you should be able to release it. OS X can't cache random  
numbers...
I dumped the code above in a forloop, running 100,000 times... with  
random numbers to be inserted.

Memory-requirements started to go up, up and up...
And guess what the value of "wh" was ? That is right: 100,000!

Filip van der Meeren
fi...@code2develop.com
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 22:47, Ken Thomases wrote:


On Dec 14, 2008, at 3:36 PM, Filip van der Meeren wrote:

I think I have found the answer to your question; when executing  
the following code, I get a few strange results...


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

NSNumber *n0 = [NSNumber numberWithInt:1];
NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSLog(@"n0: %d", [n0 retainCount]);
[n0 release];

NSNumber *n1 = [NSNumber alloc];
NSLog(@"n1: %d", [n1 retainCount]);
n1 = [n1 initWithInt:1];
NSLog(@"n1: %d", [n1 retainCount]);
[n1 release];

[pool release];

The code above results in the following log:
2008-12-14 22:32:54.997 SmallTest[556:10b] n0: 2 <===  
Thats strange

2008-12-14 22:32:55.003 SmallTest[556:10b] n0: 1

2008-12-14 22:32:55.004 SmallTest[556:10b] n1: -1 <===  
That is normal
2008-12-14 22:32:55.005 SmallTest[556:10b] n1: 2 <===  
Whow, overretained an object ;-)


My guess is that NSNumber is over-retaining itself within its  
initializer. Nothing for you to worry about.
This is a typical worry-case for that nice Apple programmer... You  
should file a bug-report...


This is why examining retain counts will only confuse you.

It is perfectly reasonable for NSNumber to vend cached, shared  
copies of commonly used values.  For example, 0 or 1.


Stop trying to figure out what the retain count "should be" at any  
given point, nor having expectations about when exactly an object  
will be fully released and hence deallocated.


Just pay attention to your own responsibilities.

Regards,
Ken



___

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: Unexpected behaviour with autorelease pool


On Dec 14, 2008, at 4:01 PM, Filip van der Meeren wrote:


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSNumber *n = nil;
NSInteger wh = 0;

srand(time(NULL));
for(int i = 0; i < 100 * 1000; ++i)
{
n = [[NSNumber alloc] initWithInt:rand()];
if([n retainCount])
++wh;
[n release];
}

NSLog(@"Result: %d", wh);

[pool release];

then you should be able to release it. OS X can't cache random  
numbers...
I dumped the code above in a forloop, running 100,000 times... with  
random numbers to be inserted.

Memory-requirements started to go up, up and up...
And guess what the value of "wh" was ? That is right: 100,000!


And you imagine this proves what, exactly?

Of course wh is 100,000.  What else could it be?  Your "if([n  
retainCount])" will (and should) always evaluate to true.


With respect to a constantly increasing memory requirement, that  
doesn't contradict anything you're entitled to expect from memory  
management.  Nobody made any promises to you that the allocation and  
initialization of an NSNumber instance did not allocate and then  
autorelease some intermediate objects.  It has always been possible  
that loops like yours might accumulate autoreleased objects, even if  
you yourself are not autoreleasing objects (or using convenience  
constructors which often, but not always, return autoreleased objects).


Again, what were you trying to prove?

Regards,
Ken

___

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: first responder stopped working

2008-12-14 Thread Sean Murphy


On Dec 13, 2008, at 11:50 PM, John Nairn wrote:

My application frequently recreates a window which involves deleting  
all the subviews and adding new ones (while keeping the window  
open). It used to work, but now when it reloads, it fails to accept  
the one view I designate to the be the first view.


After the window is recreated I perform a delayed method and use

 if(firstCell!=nil)
 {   id aView = [firstCell theView];
 if([aView acceptsFirstResponder])
 {   [[self window] makeFirstResponder:aView];
 }
 else
 NSLog(@"does not accept to be responder");
 }

This used to work, but has recently stopped working. When the window  
displays, the view (firstCell is my object and the views are all  
NSTextField views) does get selected. If I tab, one of two things  
happens:


1. It tabs to the next view making it look like the view is  
partially made the first responded, but never selected


2. Other times the window freezes up with this error message

*** NSRunStorage, _NSBlockNumberForIndex(): index (4294967294)  
beyond array bounds (30)


which I do not recognize in my code.


Hey John,

I have a couple of suggestions you can try in this situation...

- You can check out -[NSWindow setAutorecalculatesKeyViewLoop:] or  
just -[NSWindow recalculateKeyViewLoop] to have AppKit automatically  
attempt to connect the loop based on geometric ordering.


- When you fill the window's content view with your new subviews, if  
you have the same few collections of views which will always be  
loaded, you can create the parent views in Interface Builder, and wire  
up the nextKeyViews on entire collection of subviews there, and then  
just swap in a ready to go parent view into your window.


- Finally, you can try to debug your current setup.  If there is an  
array out of bounds messaging being logged, there should be an  
exception you can catch.  On leopard, add a symbolic breakpoint on  
objc_exception_throw, and then examine the stack trace in gdb to find  
out more about what is going on.


You can also throw F-Script Anywhere into your program, and examine  
the views of your window, checking out what their nextKeyView is set  
to, to help debug this further.


Good luck,
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

Re: Unexpected behaviour with autorelease pool


I suggest you run my code, on your system.
Do not start up leaks, start up Activity Monitor and watch your memory  
closely.
If your system doesn't crash/hangs before you can stop it, then you  
will see that the app is consuming memory like the Americans are  
consuming oil.
And according to me, my program respects the Memory Management rules.  
So I say there is a bug.


Filip van der Meeren
fi...@code2develop.com
http://www.sourceforge.net/projects/perlmanager
http://www.sourceforge.net/projects/xlinterpreter

On 14 Dec 2008, at 23:14, Ken Thomases wrote:


On Dec 14, 2008, at 4:01 PM, Filip van der Meeren wrote:


NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSNumber *n = nil;
NSInteger wh = 0;

srand(time(NULL));
for(int i = 0; i < 100 * 1000; ++i)
{
n = [[NSNumber alloc] initWithInt:rand()];
if([n retainCount])
++wh;
[n release];
}

NSLog(@"Result: %d", wh);

[pool release];

then you should be able to release it. OS X can't cache random  
numbers...
I dumped the code above in a forloop, running 100,000 times... with  
random numbers to be inserted.

Memory-requirements started to go up, up and up...
And guess what the value of "wh" was ? That is right: 100,000!


And you imagine this proves what, exactly?

Of course wh is 100,000.  What else could it be?  Your "if([n  
retainCount])" will (and should) always evaluate to true.


With respect to a constantly increasing memory requirement, that  
doesn't contradict anything you're entitled to expect from memory  
management.  Nobody made any promises to you that the allocation and  
initialization of an NSNumber instance did not allocate and then  
autorelease some intermediate objects.  It has always been possible  
that loops like yours might accumulate autoreleased objects, even if  
you yourself are not autoreleasing objects (or using convenience  
constructors which often, but not always, return autoreleased  
objects).


Again, what were you trying to prove?

Regards,
Ken



___

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: Unexpected behaviour with autorelease pool


On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote:

If your system doesn't crash/hangs before you can stop it, then you  
will see that the app is consuming memory like the Americans are  
consuming oil.
And according to me, my program respects the Memory Management  
rules. So I say there is a bug.


Then you misunderstand.  Nothing in the Memory Management rules will  
protect you, your program, or the system against your program  
consuming large amounts of RAM or VM.


They just prevent leaks.  But not all memory consumption constitutes a  
leak.


There are implications to delayed release (a.k.a. autorelease pools)  
that apply even if you are following the rules.  You are responsible  
for understanding and dealing with those implications.


If you think there's a bug, please point to the contractual obligation  
on the part of the frameworks which you feel isn't being honored.


Regards,
Ken

___

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: Unexpected behaviour with autorelease pool



On 14 Dec 2008, at 23:27, Ken Thomases wrote:


On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote:

If your system doesn't crash/hangs before you can stop it, then you  
will see that the app is consuming memory like the Americans are  
consuming oil.
And according to me, my program respects the Memory Management  
rules. So I say there is a bug.


Then you misunderstand.  Nothing in the Memory Management rules will  
protect you, your program, or the system against your program  
consuming large amounts of RAM or VM.




The Memory Management won't protect me indeed, but still, NSNumber is  
the basic foundation of our OS, I know dozens of ways to create the  
object without autoreleasing it inside somewhere.
There has to be a better way to do this, this isn't just some other  
virtual machine that releases objects when its pool is full. This is  
native, no garbage collector is going to save us!
That is why I think that the basic building blocks of our framework  
should be able to create themselves without putting a big restraint on  
the system.


They just prevent leaks.  But not all memory consumption constitutes  
a leak.


But they are a pain in the buttocks, and certainly if you want to  
create a small but efficient terminal app.





There are implications to delayed release (a.k.a. autorelease pools)  
that apply even if you are following the rules.  You are responsible  
for understanding and dealing with those implications.


If you think there's a bug, please point to the contractual  
obligation on the part of the frameworks which you feel isn't being  
honored.


Regards,
Ken


___

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: Unexpected behaviour with autorelease pool


On 14 Dec 2008, at 23:27, Ken Thomases wrote:


On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote:

If your system doesn't crash/hangs before you can stop it, then you  
will see that the app is consuming memory like the Americans are  
consuming oil.
And according to me, my program respects the Memory Management  
rules. So I say there is a bug.


Then you misunderstand.  Nothing in the Memory Management rules will  
protect you, your program, or the system against your program  
consuming large amounts of RAM or VM.




The Memory Management won't protect me indeed, but still, NSNumber is  
the basic foundation of our OS, I know dozens of ways to create the  
object without autoreleasing it inside somewhere.
There has to be a better way to do this, this isn't just some other  
virtual machine that releases objects when its pool is full. This is  
native, no garbage collector is going to save us!
That is why I think that the basic building blocks of our framework  
should be able to create themselves without putting a big restraint on  
the system.


They just prevent leaks.  But not all memory consumption constitutes  
a leak.


But they are a pain in the buttocks, and certainly if you want to  
create a small but efficient terminal app.





There are implications to delayed release (a.k.a. autorelease pools)  
that apply even if you are following the rules.  You are responsible  
for understanding and dealing with those implications.


If you think there's a bug, please point to the contractual  
obligation on the part of the frameworks which you feel isn't being  
honored.


Regards,
Ken


___

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: Unexpected behaviour with autorelease pool


On Dec 14, 2008, at 4:38 PM, Filip van der Meeren wrote:

[...] NSNumber is the basic foundation of our OS, I know dozens of  
ways to create the object without autoreleasing it inside somewhere.


Really?  Since you're invoking closed-source framework code, it's hard  
to imagine how you can possibly know that.  And even if you had the  
source code to look at, or you looked at its disassembly, that doesn't  
change the fact that it is only responsible for its contractual  
obligations.  And within those obligations, it's free to create and  
autorelease intermediate temporary objects, or return to you an object  
which has been retained and autoreleased (on top of the one reference  
ownership that you definitely receive).



There has to be a better way to do this, this isn't just some other  
virtual machine that releases objects when its pool is full. This is  
native, no garbage collector is going to save us!
That is why I think that the basic building blocks of our framework  
should be able to create themselves without putting a big restraint  
on the system.


What big constraint?  I think you mean a tiny constraint magnified  
many times over by your own deliberate iteration.  When you do that,  
you are responsible for draining the autorelease pool on a regular  
basis.


But even with lots of iteration, I don't see the big constraint.  I  
actually did run your code.  It completed in under 40 milliseconds  
with no evident strain on my system.  It completed so quickly that I  
didn't even have the opportunity to see its memory usage in Activity  
Monitor.


Thinking that you perhaps meant a loop of 100,000 invocations of your  
code, with its own 100,000-iteration loop inside, I tried that.  It  
takes longer, and uses nearly 100% of one of my CPU cores, of course,  
but its memory usage is constant and my system is still perfectly  
responsive.  (I changed the NSLog call to printf to avoid polluting my  
console log with 100,000 copies of the output line.)


For reference, I'm using a 2.4 GHz iMac with 2GB of RAM.  Mac OS X  
10.5.5.



They just prevent leaks.  But not all memory consumption  
constitutes a leak.


But they are a pain in the buttocks, and certainly if you want to  
create a small but efficient terminal app.


Huh?  What's the "they" in the above statement?  What's preventing you  
from creating small, efficient terminal tools?


Regards,
Ken

___

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: Unexpected behaviour with autorelease pool

2008-12-14 Thread Krishna Kotecha

Hi,
Just wanted to thank everyone who responded to my question.

I'm trying to get the memory management stuff down cold, hence I was
breaking the memory management rules in my Counter class and was perplexed
by the results I got.

The explanations here have certainly helped increase my understanding on the
issue and given me some more things to think about!

Thanks again.

Regards,

Krishna
___

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: Unexpected behaviour with autorelease pool

On 14 Dec 2008, at 23:57, Ken Thomases wrote:

On Dec 14, 2008, at 4:38 PM, Filip van der Meeren wrote:

[...] NSNumber is the basic foundation of our OS, I know dozens of
ways to create the object without autoreleasing it inside somewhere.

Really? Since you're invoking closed-source framework code, it's
hard to imagine how you can possibly know that. And even if you had
the source code to look at, or you looked at its disassembly, that
doesn't change the fact that it is only responsible for its
contractual obligations. And within those obligations, it's free to
create and autorelease intermediate temporary objects, or return to
you an object which has been retained and autoreleased (on top of
the one reference ownership that you definitely receive).

I am basing my comments on
http://www.koders.com/objectivec/fid92844506886795F3D6CA4417B418B12A1F7EB99B.aspx?s=NSGetSizeAndAlignment

There has to be a better way to do this, this isn't just some other
virtual machine that releases objects when its pool is full. This
is native, no garbage collector is going to save us!
That is why I think that the basic building blocks of our framework
should be able to create themselves without putting a big restraint
on the system.

What big constraint? I think you mean a tiny constraint magnified
many times over by your own deliberate iteration. When you do that,
you are responsible for draining the autorelease pool on a regular
basis.

But even with lots of iteration, I don't see the big constraint. I
actually did run your code. It completed in under 40 milliseconds
with no evident strain on my system. It completed so quickly that I
didn't even have the opportunity to see its memory usage in Activity
Monitor.

Thinking that you perhaps meant a loop of 100,000 invocations of
your code, with its own 100,000-iteration loop inside, I tried
that. It takes longer, and uses nearly 100% of one of my CPU cores,
of course, but its memory usage is constant and my system is still
perfectly responsive. (I changed the NSLog call to printf to avoid
polluting my console log with 100,000 copies of the output line.)

For reference, I'm using a 2.4 GHz iMac with 2GB of RAM. Mac OS X
10.5.5.

They just prevent leaks. But not all memory consumption
constitutes a leak.

But they are a pain in the buttocks, and certainly if you want to
create a small but efficient terminal app.

Huh? What's the "they" in the above statement? What's preventing
you from creating small, efficient terminal tools?

Regards,
Ken

I do know that it is impossible for me to win the autorelease war, I
personally love NSAutoreleasePool, and at the same time hate it.

So I am going to stop this discussion.

___

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: Unexpected behaviour with autorelease pool

On Sun, Dec 14, 2008 at 12:55 PM, Krishna Kotecha
 wrote:
> Shouldn't this code be causing an error at some point? And if not, why not?
>
> Any insights or explanations any one has on this would be appreciated.

All C programmers (and therefore all Objective-C programmers) must be
familiar with the phrase "undefined behavior".

Simply put, undefined behavior is the term the language spec uses most
of the time when you go off the rails. Accessing a bad pointer is
undefined behavior. Calling printf when the format string doesn't
match the arguments is undefined behavior. Bad memory management is
undefined behavior.

The key thing about undefined behavior is that it is *not* a synonym
for "generates an error message and crashes". Instead, it means that
your system is free to do whatever it wants. Another key phrase here
is "nasal demons". In other words, a conforming compiler could, upon
encountering undefined behavior, cause demons to fly out of your nose.
More likely it will simply crash. But the universe of "undefined
behavior" includes the behavior that you actually want to see! Upon
accessing a bad pointer you may get the value you wanted anyway.
Screwing up your printf arguments might produce the output you were
trying to get. Bad memory management might still work despite the
broken code.

So that's all that's going on here. You're invoking undefined behavior
but still surviving the experience. That's par for the course. It's
one of the things that makes programming in C so "fun": when you screw
up, it's likely that the problem will remain hidden, or will disappear
when you run the debugger, or will only happen on your client's
computer and not on yours.

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: NSTask with ssh-agent

2008-12-14 Thread James W. Walker



On Dec 13, 2008, at 5:51 PM, James W. Walker wrote:

I'm using NSTask to run Mercurial, which internally uses ssh to  
communicate with a server.  It works when there is no pass phrase on  
the private key, but what if there is one?  I've heard that Leopard  
has a built-in ssh-agent that integrates with the Keychain, but I  
don't understand how to take advantage of that.  Any clues?


Never mind, I figured it out myself.  It's about environment  
variables.  Normally, NSTask copies the host environment to the task,  
but I was using setEnvironment.  To fix it, I needed to make a make a  
mutable copy of the current environment dictionary, add to that, and  
then set it in the task.




smime.p7s
Description: S/MIME cryptographic signature
___

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: Unexpected behaviour with autorelease pool

On Sun, Dec 14, 2008 at 5:38 PM, Filip van der Meeren
 wrote:
>
> On 14 Dec 2008, at 23:27, Ken Thomases wrote:
>
>> On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote:
>>
>>> If your system doesn't crash/hangs before you can stop it, then you will
>>> see that the app is consuming memory like the Americans are consuming oil.
>>> And according to me, my program respects the Memory Management rules. So
>>> I say there is a bug.
>>
>> Then you misunderstand.  Nothing in the Memory Management rules will
>> protect you, your program, or the system against your program consuming
>> large amounts of RAM or VM.
>>
>
> The Memory Management won't protect me indeed, but still, NSNumber is the
> basic foundation of our OS, I know dozens of ways to create the object
> without autoreleasing it inside somewhere.
> There has to be a better way to do this, this isn't just some other virtual
> machine that releases objects when its pool is full. This is native, no
> garbage collector is going to save us!
> That is why I think that the basic building blocks of our framework should
> be able to create themselves without putting a big restraint on the system.

There is no big restraint on the system. If you have a long-running
loop such as in your example code then you *must* create and destroy
inner autorelease pools within the loop if you intend to keep memory
consumption at reasonable levels. This is documented and discussed,
and should hardly be a surprise. That you alloc/init your objects
instead of using convenience constructors is no surprise. You *cannot*
rely on code you do not control not to autorelease objects just
because you're using "direct" methods.

Follow the rules. It's the only way. The rules say that you need an
autorelease pool in a tight, long-running loop. You can't ignore that
just because you think you shouldn't need it in this particular case.

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: Unexpected behaviour with autorelease pool


On 15 Dec 2008, at 00:09, Michael Ash wrote:


On Sun, Dec 14, 2008 at 12:55 PM, Krishna Kotecha
 wrote:
Shouldn't this code be causing an error at some point? And if not,  
why not?


Any insights or explanations any one has on this would be  
appreciated.


All C programmers (and therefore all Objective-C programmers) must be
familiar with the phrase "undefined behavior".

Simply put, undefined behavior is the term the language spec uses most
of the time when you go off the rails. Accessing a bad pointer is
undefined behavior. Calling printf when the format string doesn't
match the arguments is undefined behavior. Bad memory management is
undefined behavior.

The key thing about undefined behavior is that it is *not* a synonym
for "generates an error message and crashes". Instead, it means that
your system is free to do whatever it wants. Another key phrase here
is "nasal demons". In other words, a conforming compiler could, upon
encountering undefined behavior, cause demons to fly out of your nose.
More likely it will simply crash. But the universe of "undefined
behavior" includes the behavior that you actually want to see! Upon
accessing a bad pointer you may get the value you wanted anyway.
Screwing up your printf arguments might produce the output you were
trying to get. Bad memory management might still work despite the
broken code.

So that's all that's going on here. You're invoking undefined behavior
but still surviving the experience. That's par for the course. It's
one of the things that makes programming in C so "fun": when you screw
up, it's likely that the problem will remain hidden, or will disappear
when you run the debugger, or will only happen on your client's
computer and not on yours.


Lol, I completely agree. And am wondering now why I did not came up  
with this, instead of creating autoreleasepool wars with Ken.





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/filip%40code2develop.com

This email sent to fi...@code2develop.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

controlTextDidChange for UITextField?

2008-12-14 Thread Debajit Adhikary

Is there any way to call a method each time the text of a UITextField
changes?
controlTextDidChange does not seem to exist for UITextField's
___

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: Newbie Q: Why is UIWindow in the AppDelegate not an ivar?

2008-12-14 Thread Debajit Adhikary

It turns out the window can in fact be accessed as
[[UIApplication sharedApplication] keyWindow]  // readonly property


On Sat, Dec 13, 2008 at 7:45 PM, Luke Hiesterman  wrote:

> Generally speaking you will do well for yourself to follow Apple's example
> over Erica's. I haven't actually read her book but I've had several examples
> come to my attention of where she doesn't do things in the best way.
>
> Erica is a talented hacker but please get in the habit of following the
> canonical examples. These have been thoroughly vetted and approved my many
> experts.
>
> Luke
>
> Sent from my iPhone.
>
>
> On Dec 13, 2008, at 7:22 PM, Debajit Adhikary  wrote:
>
>  I meant to ask what the tradeoffs are between declaring the UIWindow
>> object
>> as an instance variable in the AppDelegate vs. as a local object in
>> -applicationDidFinishLaunching:
>>
>> The specific example I'd mentioned was from Erica Sadun's book, and
>> looking
>> at Apple's sample code, and the code that XCode generates, it seems that
>> the
>> UIWindow object is typically declared as an instance variable in the
>> AppDelegate and seems the way to go (as opposed to Erica Sadun's example
>> of
>> using a local UIWindow object).
>>
>>
>> On Sat, Dec 13, 2008 at 6:34 PM, Debajit Adhikary > >wrote:
>>
>>  When you create an iPhone app, in the AppDelegate, why is the
>>> UIWindow created locally within -applicationDidFinishLaunching and not
>>> declared
>>> as an ivar? The functionality does not seem to change either way. I'd
>>> like to know how one approach is better than the other.
>>>
>>> What I presume is that the window object really doesn't need to be
>>> accessed
>>> from outside later. But doesn't declaring it as an ivar make it more
>>> accessible from the "outside" allowing greater application extensibility?
>>>
>>> @implementation AppDelegate
>>>
>>> - (void) applicationDidFinishLaunching:(UIApplication*) application
>>> {
>>>  UIWindow* window = ... ;
>>>  [window addSubView: ...];
>>>  [window makeKeyAndVisible];
>>> }
>>>
>>> ...
>>> @end
>>>
>>>
>>>  ___
>>
>> 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/luketheh%40apple.com
>>
>> This email sent to luket...@apple.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: NSTimer EXC_BAD_ACCESS

2008-12-14 Thread Kyle Sluder

On Sun, Dec 14, 2008 at 2:52 PM, Jens Bauer  wrote:
> You probably experience your crash, because the timer is autoreleased. If
> you retain it, it'll live. However, you'll have to remember the timer
> object, so you can stop it later, so add NSTimer *timer; as a member
> variable of your class...

Take a look at the stack trace again.  It's happening within the call
to +[NSTimer scheduledTimerWithInterval:target:selector:userInfo:repeats:].
 The problem can't be that he hasn't retained a timer he hasn't
created yet.

--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: Now contents of the layer not being rotated [was Re: Rotating a CALayer more than once is not working ]