date:20080805



Le 5 août 08 à 08:13, Gerriet M. Denkmann a écrit :

I want to get the colour of a symlink (NOT the colour of the thing  
the symlinks points at).

Is there a Cocoa way to get this?

Currently I am using FSPathMakeRef (or CFURLGetFSRef) to get an  
FSRef, and then FSGetCatalogInfo to get the colour.


But both FSPathMakeRef and CFURLGetFSRef seem to follow through  
symlinks (not aliases though).
So I always get the colour of the destination (or an error if the  
symlink is broken).


How can I get the colour of my symlink?

Kind regards,

Gerriet.


Have a look at FSPathMakeRefWithOptions();
Hint: the only option currently available for this function is  
kFSPathMakeRefDoNotFollowLeafSymlink



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Bindings to display an NSArray of NSStrings as a single NSString?

Bindings are made fpr entities (not only core data entiities, but  
entities). It is a *Key-Value*-Technologie. Strings have no  
properties, no keys, are not entities.


Maybe you can fake it, if you add a category to the strings:
@implementation NString( MirrorAddition )
- (NSString*)reflection { return self; }
@end

using reflection as the model key path. But propably it is a design  
problem.


Amin

Am Mo,04.08.2008 um 19:32 schrieb Dustin Robert Kick:

This seems like it would be common enough, to me, that it would have  
bindings for it.  I can't find anything, and am thinking I will  
write an NSValueTransformer to do this (also thought there might be  
a value transformer for this, but no).  Am I missing something?  I  
thought that there should be either a [EMAIL PROTECTED] operator,  
or a patternValue binding, or an NSValueTransformer to do this, but  
I haven't found anything.  I thought I might be able to get  
something by using [EMAIL PROTECTED], or something  
similar, but that wouldn't work either.



Dustin  
KC9MEL  


___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Irritating Problem with NSString Method and File Paths

The file is inside your application directory? Than you should use  
NSBundles's API to find resources.


NSString* thePath = [[NSBundle mainBundle] pathForResource:filename  
ofType:@txt]


Amin

Am Mo,04.08.2008 um 06:43 schrieb Patrick Walker:

It seems that whenever I use Xcode to spawn the program, it is able  
to find the file but when spawning the program from Finder, it can  
never, ever find the file.  I've been looking online and no one  
seems to have come across this before or maybe it's because it's so  
late that I'm not seeing the obvious.


	NSString *fileContents = [[NSString alloc] initWithContentsOfFile: 
[filename stringValue]


   encoding:NSASCIIStringEncoding

  error:nil];
Filename is an NSTextField outlet, btw.

We've tried all sorts of things to try and find the file,  
File.txt, ./File.txt, ~/File.txt, ./File.txt.   I can understand  
maybe the ~ doesn't work for all shells but explicitly using
./File.txt should be opening the file in the current directory with  
the executable, shouldn't it?  Do I *really* have to append a huge  
long path each time I want to open a file?


Any ideas?  It says path and the documentation says that it has to  
be NSString.  I've used filepaths before for open() but those are C  
strings and those are full paths though, i.e., /dev/stdout.  It's  
such a simple problem what am I missing here?

___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Properties and memory management

2008-08-05 Thread Uli Kusterer


On 05.08.2008, at 05:55, Jonathan Hess wrote:
The implementation of the property will manage the retaining and the  
releasing. You only need to worry about sending retain and release  
messages manually if you access the instance variable directly (not  
through a property). The only place you would typically need to do  
that would be in your dealloc method.



 Although in dealloc

self.myProperty = nil;

would also work, which has the added benefit that you'll notice when  
you're talking to an object that has already been released, because  
then all its object ivars will be NIL.


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 [EMAIL PROTECTED]

Re: File's Owner problems



On Aug 4, 2008, at 11:38 PM, Chris Idou wrote:

I've got a class, let's call it Foo, that loads a NIB called Bar.  
In IB, the File's owner of Bar is set to class Foo. When Foo loads  
Bar, passing self as the file's owner, Foo.awakeFromNib gets called  
during the nib loading process.


Is that meant to happen? It doesn't make sense to me.

http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_3.html 



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 [EMAIL PROTECTED]

Resizing a NSImage in a Cocoa command line tool

2008-08-05 Thread Dimitri Bouniol

I have been trying relentlessly to resize a NSImage and save it as a  
png file in a command line tool (not a windowed app, but I included  
AppKit to get NSImage support). I tried using setScalesWhenResized  
along with setSize to no avail (image is not resized when saved), and  
I also tried locking focus to another image and drawing at a smaller  
size, but that simply crashes with the following:


2008-08-03 20:49:40.127 imagecompressor[16757:10b] _NXCreateWindow:  
error setting window property (1002)
2008-08-03 20:49:40.132 imagecompressor[16757:10b] _NXPlaceWindow:  
error setting window shape (1002)
2008-08-03 20:49:40.132 imagecompressor[16757:10b]  
_NSShapePlainWindow: error setting window shape (1002)
2008-08-03 20:49:40.144 imagecompressor[16757:10b]  
PScurrentwindowbounds: CGSGetWindowBounds returned error (1002)
Sun Aug  3 20:49:40 imagecompressor[16757] Error:  
CGSImageDataLockDevice: Bad device image source
Sun Aug  3 20:49:40 imagecompressor[16757] Error:  
ripc_DrawWindowContents - Cannot acquire window image
2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** - 
[NSCachedImageRep representationUsingType:properties:]: unrecognized  
selector sent to instance 0x116c30
2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** Terminating app  
due to uncaught exception 'NSInvalidArgumentException', reason: '*** - 
[NSCachedImageRep representationUsingType:properties:]: unrecognized  
selector sent to instance 0x116c30'

2008-08-03 20:49:40.146 imagecompressor[16757:10b] Stack: (
2527650123,
2500743419,
2527679306,
2527672652,
2527672850,
11646,
10094
)
Trace/BPT trap

I hope someone could come to my aid!
--
定魅刀利
Dimitri Bouniol
[EMAIL PROTECTED]
http://www.appkainime.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 [EMAIL PROTECTED]

Re: Properties and memory management



On Aug 5, 2008, at 3:00 AM, mmalc crawford wrote:

No, this is not the case -- Ken's reply was correct.  If you use  
automatic KVO notifications, your accessors will still have side  
effects.


Although I should add that of course by the time you reach dealloc you  
should not have observers...


The general point still stands, though.  The correct pattern is:
Set instance variables directly in init methods, and release them  
directly in dealloc.


On Aug 5, 2008, at 2:57 AM, Uli Kusterer wrote:

Though I vaguely remember getting lectured by someone about why it's  
better to *always* use the accessors a while ago ... wish I  
remembered what the reasoning behind that was, and why I thought it  
might be a good idea to follow that, but OTOH didn't follow it :-/


Other than in init, you should always use accessors to set values  
because:
(a) The accessors might have side-effects (such as emitting KVO change  
notifications) that your application relies on;
(b) Accessors are typically the best place to put memory management  
code.  If you push all your memory management to accessors, then  
you're much less likely to make a mistake somewhere along the line...


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 [EMAIL PROTECTED]

Re: Properties and memory management

2008-08-05 Thread Uli Kusterer


You may fire off observer methods too, which is probably undesirable.


 Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY()  
macros for these purposes, and since most of my code still needs to be  
10.4-compatible, I've mostly been using those:


http://www.zathras.de/angelweb/sourcecode.htm#UKHelperMacros

 Though I vaguely remember getting lectured by someone about why it's  
better to *always* use the accessors a while ago ... wish I remembered  
what the reasoning behind that was, and why I thought it might be a  
good idea to follow that, but OTOH didn't follow it :-/


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 [EMAIL PROTECTED]

Re: Properties and memory management





Am Di,05.08.2008 um 12:05 schrieb mmalc crawford:



On Aug 5, 2008, at 3:00 AM, mmalc crawford wrote:

No, this is not the case -- Ken's reply was correct.  If you use  
automatic KVO notifications, your accessors will still have side  
effects.


Although I should add that of course by the time you reach dealloc  
you should not have observers...

That is, what I wrote. (accidentally not to the list)


The general point still stands, though.

For what reason?


The correct pattern is:
Set instance variables directly in init methods, and release them  
directly in dealloc.


On Aug 5, 2008, at 2:57 AM, Uli Kusterer wrote:

Though I vaguely remember getting lectured by someone about why  
it's better to *always* use the accessors a while ago ... wish I  
remembered what the reasoning behind that was, and why I thought it  
might be a good idea to follow that, but OTOH didn't follow it :-/


Other than in init, you should always use accessors to set values  
because:
(a) The accessors might have side-effects (such as emitting KVO  
change notifications) that your application relies on;
(b) Accessors are typically the best place to put memory management  
code.  If you push all your memory management to accessors, then  
you're much less likely to make a mistake somewhere along the line...

Sic!
Why does this reasons do not apply to -init and -dealloc?

The only reason for direct accesses are side-effects in the setters,  
which you do not want to apply at -deallocation time. I think, that  
this is rare.


Amin




mmalc




Amin Negm-Awad
[EMAIL PROTECTED]





Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Localize App Title?



On Aug 5, 2008, at 3:40 AM, Chunk 1978 wrote:


and then of course i have a Localizable.Strings file in the app's
resources... so is there someway to do the same with the name of the  
app?


http://developer.apple.com/cgi-bin/search.pl?q=localize+application+namenum=10site=default_collection 



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 [EMAIL PROTECTED]

Re: Properties and memory management – sorr y, not send to the list



Am Di,05.08.2008 um 11:57 schrieb Uli Kusterer:


You may fire off observer methods too, which is probably undesirable.


Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY()  
macros for these purposes, and since most of my code still needs to  
be 10.4-compatible, I've mostly been using those:


http://www.zathras.de/angelweb/sourcecode.htm#UKHelperMacros

Though I vaguely remember getting lectured by someone about why it's  
better to *always* use the accessors a while ago ... wish I  
remembered what the reasoning behind that was, and why I thought it  
might be a good idea to follow that, but OTOH didn't follow it :-/


The advantages are:
- You have only one place per property, which handles the memory  
management. Just imagine, that you change the type of reference from  
hard to weak. You have to handle that change only inside the setter.
- You have side-effects you want to use at deallocation time, too: the  
property refers to something outside, which has to be deallocated,  
turn of, … manually. Think of a guard wiith property that adds  
observations to another object. Changing the proprety (the referred  
object) in any case (including the case of deallocation) should delete  
the observation. So the settter is a single place, where you can  
handle it.


disadvantages:
- side-effects at dellocation time, which you do not want to use: I  
mentioned undo registration.


But I think, that the problem figured out by Ken (being observed in - 
dealloc), does not exist . Observations has to be removed by every  
object which sends a retain to an instance Before the deallocation  
takes place (-dealloc is called after a -retain) the obseving object  
already had to be removed. If there is still an observation of an  
object running through -dealloc, you have another problem. No observed  
object should disappear.


My 0,05 $

Amin




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 [EMAIL PROTECTED]

Re: Message Framework and Garbage Collection

2008-08-05 Thread Ruotger Skupin


Hi B.

I'm trying not to sound mean or angry here but I doubt that Apple will  
fix such an obvious bug in a deprecated framework, since it didn't do  
so already. So filing a radar bug seems to be a waste of time (again).


Does anyone know, a way to send a mail programmatically in the  
background, i.e. without opening a mailto:; url?


Ruotger

On 04.08.2008, at 20:28, Bill Bumgarner wrote:


On Aug 4, 2008, at 10:35 AM, Ruotger Skupin wrote:
I'm trying to use the Message Framework with Garbage Collection  
enabled and it crashes deep down in the framework. With retain/ 
release it works fine. Am I correct in assuming that since it is  
deprecated for 10.5 it can't be used with GC?


Is there anything that can be used instead?


If it is in 10.5, it should work.  Please file a radar.

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 [EMAIL PROTECTED]

Re: Properties and memory management



On Aug 5, 2008, at 2:48 AM, Negm-Awad Amin wrote:

This is the mirror of the problem, when you initialize an object.  
Of course, theoretically in both cases the usage of setters are  
dangerous. In most cases the  deallocation of the object in reverse  
order to its initialization will not lead to any problems. It is no  
problem, when you have synthisized accessors, because they have noch  
side-effects.


No, this is not the case -- Ken's reply was correct.  If you use  
automatic KVO notifications, your accessors will still have side  
effects.
Again per Ken's reply, you should typically set instance variables  
directly in init methods, and release them directly in dealloc.


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 [EMAIL PROTECTED]

Re: Localize App Title?

i've localized the info.plist file, and added these keys to the english
subfile:

keyLSHasLocalizedDisplayName/key

true/

keyCFBundleDisplayName/key

stringNew App Title/string


but it still shows my original app name...




On Tue, Aug 5, 2008 at 7:04 AM, mmalc crawford [EMAIL PROTECTED] wrote:


 On Aug 5, 2008, at 3:40 AM, Chunk 1978 wrote:

  and then of course i have a Localizable.Strings file in the app's
 resources... so is there someway to do the same with the name of the app?


 
 http://developer.apple.com/cgi-bin/search.pl?q=localize+application+namenum=10site=default_collection
 

 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 [EMAIL PROTECTED]

Re: Properties and memory management

2008-08-05 Thread Ken Ferry

On Tue, Aug 5, 2008 at 1:12 AM, Uli Kusterer
[EMAIL PROTECTED] wrote:
 On 05.08.2008, at 05:55, Jonathan Hess wrote:

 The implementation of the property will manage the retaining and the
 releasing. You only need to worry about sending retain and release messages
 manually if you access the instance variable directly (not through a
 property). The only place you would typically need to do that would be in
 your dealloc method.


  Although in dealloc

self.myProperty = nil;

 would also work, which has the added benefit that you'll notice when you're
 talking to an object that has already been released, because then all its
 object ivars will be NIL.

A disadvantage of this approach is that you'll be invoking the setter
when your object is partially torn down.  If you later override or
implement the method, you are not likely to be thinking about the
possibility that the object is not in a valid state.  Calling methods
from init has the same issue.

You may fire off observer methods too, which is probably undesirable.

-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 [EMAIL PROTECTED]

Re: image type of the AdressBook image data

2008-08-05 Thread Heinrich Giesen



On 05.08.2008, at 10:03, Wayne Shao wrote:


The imageData method returns NSData*.  Is there anyway to know the
image type (e.g, PNG, TIFF, or JPEG) of the data?



besides that what Ken Ferry wrote you may also use (as I do) a low level
way to determine the image type: check for the magic number of image  
data.


   const unsigned char *bytes = [imageData bytes];
   //NSLog( @%02x %02x %02x %02x , bytes[0], bytes[1], bytes[2],  
bytes[3] );

   BOOL isTIFF_BigEndian = (bytes[0]=='M')  (bytes[1]=='M');
   BOOL isTIFF_LittleEndian = (bytes[0]=='I')  (bytes[1]=='I');
   BOOL isJPEG= (bytes[0]==0xff)  (bytes[1]==0xd8)  (bytes[2] 
==0xff);
   BOOL isPNG = (bytes[0]==0x89)  (bytes[1]=='P')  (bytes[2] 
=='N')  (bytes[3]=='G')
  (bytes[4]==0x0d)  (bytes[5]==0x0a)  (bytes[6] 
==0x1a)  (bytes[7]==0x0a);
   BOOL isGIF = (bytes[0]=='G')  (bytes[1]=='I')  (bytes[2] 
=='F');
   BOOL isPDF = (bytes[0]=='%')  (bytes[1]=='P')  (bytes[2] 
=='D')

  (bytes[3]=='F')  (bytes[4]=='-');
   BOOL isBMP = (bytes[0]=='B')  (bytes[1]=='M');
   BOOL isICNS= (bytes[0]=='i')  (bytes[1]=='c')  (bytes[2] 
=='n')  (bytes[3]=='s');



The Carbon/Cocoa functions and methods do nothing else, they test the  
magic number.


Heinrich

--
Heinrich Giesen
[EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Properties and memory management



Am Di,05.08.2008 um 12:00 schrieb mmalc crawford:



On Aug 5, 2008, at 2:48 AM, Negm-Awad Amin wrote:

This is the mirror of the problem, when you initialize an object.  
Of course, theoretically in both cases the usage of setters are  
dangerous. In most cases the  deallocation of the object in reverse  
order to its initialization will not lead to any problems. It is no  
problem, when you have synthisized accessors, because they have  
noch side-effects.


No, this is not the case -- Ken's reply was correct.  If you use  
automatic KVO notifications, your accessors will still have side  
effects.
Again per Ken's reply, you should typically set instance variables  
directly in init methods, and release them directly in dealloc.


No, I think, that you should never, never have an observation, when - 
dealloc is running. *This* is the problem, not the KVO-Messages. If  
you are in -dealloc, the instance *will* be deleted. Since this  
happens running up the class hierarchy, the observing object has no  
chance to remove its observation before the object is deallocated. So  
in the moment of -dealloc (NSObject) you have an observation to an  
dead object. *This* is the fault.


You always have to remove the observation before there is the chance  
of losing the object.

mmalc



Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Localize App Title?

i'm fairly new to localization, but i can't figure out how to localize the
app's name.  this is how i localize the strings in my app:

static NSString * CONSTwelcome;


-(void)awakeFromNib

{

CONSTwelcome = NSLocalizedString (@Welcome!, nil);
bla bla bla
}

and then of course i have a Localizable.Strings file in the app's
resources... so is there someway to do the same with the name of the app?
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Localize App Title?



Le 5 août 08 à 13:25, Chunk 1978 a écrit :

i've localized the info.plist file, and added these keys to the  
english

subfile:

keyLSHasLocalizedDisplayName/key

true/

keyCFBundleDisplayName/key

stringNew App Title/string


but it still shows my original app name...


Please read the documentation.

http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#/ 
/apple_ref/doc/uid/20001431-110725



CFBundleDisplayName:
[…]
Before displaying a localized name for your bundle, the Finder  
compares the value of this key against the actual name of your bundle  
in the file system. If the two names match, the Finder proceeds to  
display the localized name from the appropriate InfoPlist.strings file  
of your bundle. If the names do not match, the Finder displays the  
file-system name.





___

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

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

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

This email sent to [EMAIL PROTECTED]

Using performSelector: on super

2008-08-05 Thread [EMAIL PROTECTED]


Hello list

My superclass (SuperSocket) provides a private method -close.
My subclass overrides this private method as follows:

- (void)close
{
SEL closeSelector = @selector(close);

if ([SuperSocket instancesRespondToSelector:closeSelector]) {   
[super performSelector:closeSelector];  // seems to send to self
} else {
NSAssert (NO, @SuperSocket no longer responds to close 
message.);
}

// subclass additional code
}

If I am not mistaken this code appears to send the close selector to  
the self object.
If [super performSelector:closeSelector] is replaced by [super close]  
then the super object receives the close message as expected.


I know that [super respondsToSelector: closeSelector] is equivalent to  
[self respondsToSelector: closeSelector] as the methods tests the  
object as a whole (see NSObject Protocol Reference entry for  
respondsToSelector;);

So is that the story here?
Or am I on the wrong page entirely.


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Automatic population of NSTableView with custom columns at launch time

2008-08-05 Thread Rick Hoge




Hmmm.  Does not seem to be doing it.


Unfortunately, I'm out of ideas; these were mainly off the top of  
my head. Without seeing your specific source code, I can't offer  
any more suggestions -- it is quite possible something else is  
wrong (ie: the identifier isn't set). You probably want to debug  
the app to find out why/when your columns are being removed, and go  
from there. You can try breaking on the internal tableview methods,  
_readPersistentTableColumns and _writePersistentTableColumns,  
however, these methods are purely internal, and may be removed in  
future releases. In other words, don't call them or override them.


The more I google on this, the more it looks like many people have had  
the same problem without ever getting resolved.  I've filed a bug  
report (6125547).


The other weird thing is that I can't find the file autosave file  
(which I called MyDocTableInfo) anywhere.  I thought that if I could  
locate this file and query the property list I might get some idea of  
what's going on.  However it's nowhere that I can find (neither with  
Spotlight, manual searching, or ls -R | grep MyDocTableInfo).


Seems like there needs to be more documentation on this, and that the  
functionality could be enhanced.  If it did what I thought it would do  
(restoring all columns, including those created programatically) it  
would be amazing.  Manual tracking of columns could easily get *very*  
messy...


I don't see why columns added through code couldn't be autosaved - all  
the information provided for nib-defined columns is available.


Rick






Thanks anyway -

Of course it never hurts to actually show some code (in case this  
might prompt an idea).


This is a test method that adds a column and then sets the autosave  
info - I wouldn't actually use it this way, but for testing it does  
the steps in the suggested order.


-(IBAction)addTableColumnTest:(id)sender {

 // documentTable is an IBOutlet
 // autoSaveTableName:  is empty in the nib

 // Get existing column to copy some formatting info
 NSTableColumn *prototypeColumn = [[documentTable tableColumns]  
lastObject];


 //  Create and add the new column
 NSTableColumn *newColumn = [[NSTableColumn alloc]  
initWithIdentifier:@comments]; // app is GC
 [[newColumn headerCell] setStringValue:@Comments]; // Assign  
header text
 [[newColumn dataCell] setFont:[[prototypeColumn dataCell]  
font]]; // Copy font from existing table column
 [newColumn bind:@value toObject:documentArrayController  
withKeyPath:@arrangedObjects.comments options:nil];

 [documentTable addTableColumn:newColumn];

 // Set the autoSave info
 [documentTable setAutosaveTableColumns:YES];
 [documentTable setAutosaveName:@MyDocTableInfo];

}






You are correct, step #3 shouldn't be required.

If all else fails, you may have to hand-roll a solution where you  
don't use the tableview logic, and store out the widths/table  
columns yourself.


-corbin





I set autoSaveFileName to nil in the nib file, then do the  
following in my code:


1) add the new table columns (addTableColumn: etc.)

2) call setAutosaveName:@someFile , call  
setAutosaveTableColumns:YES


3) manually change width of table column in UI just in case this  
will force an autosave


4) quit app

On next launch, the column I added in step 1 is not there.   
Changes to width of columns defined in the nib are preserved though.


Also is step 3 really needed to force an autosave?  Ideally the  
added columns would have to be 'remembered' even if the user does  
not resize any...


thanks for the suggestions, though!

Rick

On 4-Aug-08, at 7:05 PM, Corbin Dunn wrote:

Are you calling setAutosaveName: yourself? Set it to nil in the  
nib. Then, call it yourself. Before you call it, print out all  
the table columns to see what they are. Then, load your  
tablecolumns that you want (add new ones). Then call  
setAutosaveName:something. Change the width of a column in your  
GUI. This should save out the autosave values. Quit your app.  
Restart it. Are the columns restored?


This pattern should work; I use it internally in the open and  
save panel.


corbin

On Aug 4, 2008, at 3:36 PM, Rick Hoge wrote:



Thanks for the suggestion -

I tried calling setAutosaveTableColumns: after adding a column  
from code, but on next launch it only showed the columns that  
are defined in the nib with IB.


Rick

On 4-Aug-08, at 5:39 PM, Corbin Dunn wrote:

If you add all the columns (and remove old ones) before calling  
setAutosaveName:, or setAutosaveTableColumns:, then it should  
work out okay; it will restore all of the widths, positions, etc.


corbin

On Aug 4, 2008, at 2:03 PM, Rick Hoge wrote:



I'm working on an application that will allow users to add  
columns of descriptive information to an NSTableView - the  
available columns are determined at launch time by loading a  
dictionary.


In my test app, I can add columns to my table no problem.  Now  
I am trying to decide on a robust

Re: Automatic population of NSTableView with custom columns at launch time

2008-08-05 Thread Rick Hoge



One other thing I'm not sure I understand -

Are you calling setAutosaveName: yourself? Set it to nil in the nib.  
Then, call it yourself.


Why can't this be set in the nib?  I would have thought this is the  
logical place to set it, and that once set any changes to the table  
would be recorded.


What happens differently when the values (autosave and file name) are  
set in the code?


Thanks again for the reply and sorry if this is dense - just trying to  
make sure I understand the suggestions.


Rick


Before you call it, print out all the table columns to see what they  
are. Then, load your tablecolumns that you want (add new ones). Then  
call setAutosaveName:something. Change the width of a column in  
your GUI. This should save out the autosave values. Quit your app.  
Restart it. Are the columns restored?


This pattern should work; I use it internally in the open and save  
panel.


corbin

On Aug 4, 2008, at 3:36 PM, Rick Hoge wrote:



Thanks for the suggestion -

I tried calling setAutosaveTableColumns: after adding a column from  
code, but on next launch it only showed the columns that are  
defined in the nib with IB.


Rick

On 4-Aug-08, at 5:39 PM, Corbin Dunn wrote:

If you add all the columns (and remove old ones) before calling  
setAutosaveName:, or setAutosaveTableColumns:, then it should work  
out okay; it will restore all of the widths, positions, etc.


corbin

On Aug 4, 2008, at 2:03 PM, Rick Hoge wrote:



I'm working on an application that will allow users to add  
columns of descriptive information to an NSTableView - the  
available columns are determined at launch time by loading a  
dictionary.


In my test app, I can add columns to my table no problem.  Now I  
am trying to decide on a robust and efficient way to make sure  
that the set of columns chosen by the user, and their geometry,  
is saved when quitting the app and restored at the next launch.


I can think of a number of brute force ways to do it - save an  
array of column identifiers and/or value bindings to user  
preferences, for example.


I know it's possible to autosave column layout information under  
Leopard through the framework, and this appears to work.  The  
autosave info appears to restore the geometry of columns defined  
in the nib file, but it won't force a reload of columns created  
programatically in the last session.  I suspect that the autosave  
file may actually contain the identifiers of all columns  
displayed as of the last application quit, and wonder if there is  
a way, during nib loading, to access this list so I can  
initialize the table.


I don't like having the same information stored multiple places  
(i.e. my own NSArray in user prefs replicating info that might be  
more complete in the NSTableView autosave file) if I can avoid  
it, but can't seem to find a way to get at all the info in this  
file.


If anyone has some good examples of how this can be done, or some  
past experience to share on what works well, I'd be very grateful.




(43092.6825)





(43092.6825)

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread Clark Cox

On Tue, Aug 5, 2008 at 5:41 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Hello list

 My superclass (SuperSocket) provides a private method -close.
 My subclass overrides this private method as follows:

 - (void)close
 {
SEL closeSelector = @selector(close);

Note, for getting the selector that the current method was called
with, you can just use _cmd:



if ([SuperSocket instancesRespondToSelector:closeSelector]) {
[super performSelector:closeSelector];  // seems to send to
 self
} else {
NSAssert (NO, @SuperSocket no longer responds to close
 message.);
}

// subclass additional code
 }

 If I am not mistaken this code appears to send the close selector to the
 self object.

Correct.

 If [super performSelector:closeSelector] is replaced by [super close] then
 the super object receives the close message as expected.

Remember, there is no such thing as a super object. super is just
a keyword that tells the compiler to skip searching the current class
for methods. It doesn't change which object the message is sent to.

 I know that [super respondsToSelector: closeSelector] is equivalent to [self
 respondsToSelector: closeSelector] as the methods tests the object as a
 whole (see NSObject Protocol Reference entry for respondsToSelector;);
 So is that the story here?

Correct.

 Or am I on the wrong page entirely.

If you *really* need to call [super close] without hard-coding the
message (i.e. using an arbitrary selector), you can get the method's
IMP and call that like a function:

void (*functionPointer)(id,SEL,...) = [SuperSocket
instanceMethodForSelector: _cmd];
functionPointer(self,_cmd);

-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

On Tue, Aug 5, 2008 at 9:38 AM, Clark Cox [EMAIL PROTECTED] wrote:

 If [super performSelector:closeSelector] is replaced by [super close] then
 the super object receives the close message as expected.

 Remember, there is no such thing as a super object. super is just
 a keyword that tells the compiler to skip searching the current class
 for methods. It doesn't change which object the message is sent to.

  Or, for the documentation's take:

  
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_9_section_5.html#

--
I.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 [EMAIL PROTECTED]

Re: Automatic population of NSTableView with custom columns at launch time

2008-08-05 Thread Rick Hoge



More observations on this -

Unfortunately, I'm out of ideas; these were mainly off the top of  
my head. Without seeing your specific source code, I can't offer  
any more suggestions -- it is quite possible something else is  
wrong (ie: the identifier isn't set).


The identifier is definitely set in the columns I'm adding.

You probably want to debug the app to find out why/when your  
columns are being removed, and go from there. You can try breaking  
on the internal tableview methods, _readPersistentTableColumns and  
_writePersistentTableColumns, however, these methods are purely  
internal, and may be removed in future releases. In other words,  
don't call them or override them.


I made an NSTableView subclass with overrides of these internal  
methods (just calling super) and noticed the following things:


- _writePersistentTaboleColumns is called when a column is resized,  
but *not* when a column is added
-   if I force a call to the above method by resizing a column, a call  
to [self tableColumns] includes columns added in code


- if I quite and relaunch, _readPersistentTableColumns is called but  
after sending the same message to super the table still contains only  
the nib columns


Rick


You are correct, step #3 shouldn't be required.

If all else fails, you may have to hand-roll a solution where you  
don't use the tableview logic, and store out the widths/table  
columns yourself.


-corbin





I set autoSaveFileName to nil in the nib file, then do the  
following in my code:


1) add the new table columns (addTableColumn: etc.)

2) call setAutosaveName:@someFile , call  
setAutosaveTableColumns:YES


3) manually change width of table column in UI just in case this  
will force an autosave


4) quit app

On next launch, the column I added in step 1 is not there.  Changes  
to width of columns defined in the nib are preserved though.


Also is step 3 really needed to force an autosave?  Ideally the  
added columns would have to be 'remembered' even if the user does  
not resize any...


thanks for the suggestions, though!

Rick

On 4-Aug-08, at 7:05 PM, Corbin Dunn wrote:

Are you calling setAutosaveName: yourself? Set it to nil in the  
nib. Then, call it yourself. Before you call it, print out all the  
table columns to see what they are. Then, load your tablecolumns  
that you want (add new ones). Then call  
setAutosaveName:something. Change the width of a column in your  
GUI. This should save out the autosave values. Quit your app.  
Restart it. Are the columns restored?


This pattern should work; I use it internally in the open and save  
panel.


corbin

On Aug 4, 2008, at 3:36 PM, Rick Hoge wrote:



Thanks for the suggestion -

I tried calling setAutosaveTableColumns: after adding a column  
from code, but on next launch it only showed the columns that are  
defined in the nib with IB.


Rick

On 4-Aug-08, at 5:39 PM, Corbin Dunn wrote:

If you add all the columns (and remove old ones) before calling  
setAutosaveName:, or setAutosaveTableColumns:, then it should  
work out okay; it will restore all of the widths, positions, etc.


corbin

On Aug 4, 2008, at 2:03 PM, Rick Hoge wrote:



I'm working on an application that will allow users to add  
columns of descriptive information to an NSTableView - the  
available columns are determined at launch time by loading a  
dictionary.


In my test app, I can add columns to my table no problem.  Now  
I am trying to decide on a robust and efficient way to make  
sure that the set of columns chosen by the user, and their  
geometry, is saved when quitting the app and restored at the  
next launch.


I can think of a number of brute force ways to do it - save an  
array of column identifiers and/or value bindings to user  
preferences, for example.


I know it's possible to autosave column layout information  
under Leopard through the framework, and this appears to work.   
The autosave info appears to restore the geometry of columns  
defined in the nib file, but it won't force a reload of columns  
created programatically in the last session.  I suspect that  
the autosave file may actually contain the identifiers of all  
columns displayed as of the last application quit, and wonder  
if there is a way, during nib loading, to access this list so I  
can initialize the table.


I don't like having the same information stored multiple places  
(i.e. my own NSArray in user prefs replicating info that might  
be more complete in the NSTableView autosave file) if I can  
avoid it, but can't seem to find a way to get at all the info  
in this file.


If anyone has some good examples of how this can be done, or  
some past experience to share on what works well, I'd be very  
grateful.




(43092.6825)





(43092.6825)





(43092.6825)

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators

Re: Resizing a NSImage in a Cocoa command line tool

2008-08-05 Thread Ken Ferry

Hi Dimitri,

The size property describes a more abstract size than pixels.  If you
set it, you're changing the DPI of the image you write out, not how
many pixels it has.

It's not safe in general to use AppKit from an app that cannot connect
to the window server �C see
http://developer.apple.com/technotes/tn2005/tn2083.html#SECLIVINGDANGEROUSLY.
 If you _can_ connect to the window server (i.e. this app isn't
running headless on some machine where you aren't logged in to
console) then you might just need to call NSApplicationLoad() in your
main method.  This function does some AppKit global setup that is
normally done in NSApplicationMain, but NSApplicationLoad returns
control to you.

That said, if you can restrict yourself to NSBitmapImageRep, that
should work without a windowserver connection.  You can draw from your
original bitmap into a new, smaller one like this:

NSBitmapImageRep *newBitmap = [[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:NULL pixelsWide:pixelsWide
pixelsHigh:pixelsHigh bitsPerSample:8 samplesPerPixel:4 hasAlpha:YES
isPlanar:NO colorSpaceName:NSCalibratedRGBColorSpace
bitmapFormat:NSAlphaFirstBitmapFormat bytesPerRow:0 bitsPerPixel:32];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:[NSGraphicsContext
graphicsContextWithBitmapImageRep:newBitmap]];
[oldBitmap drawInRect:NSMakeRect(0,0,pixelsWide,pixelsHigh)];
[NSGraphicsContext restoreGraphicsState];

and write it to png data with -[NSBitmapImageRep
representationUsingType:properties:].

Also, the technote I referenced above doesn't mention that the
CoreGraphics framework is daemon safe, which it is.

-Ken
Cocoa Frameworks

On Tue, Aug 5, 2008 at 2:44 AM, Dimitri Bouniol [EMAIL PROTECTED] wrote:
 I have been trying relentlessly to resize a NSImage and save it as a png
 file in a command line tool (not a windowed app, but I included AppKit to
 get NSImage support). I tried using setScalesWhenResized along with setSize
 to no avail (image is not resized when saved), and I also tried locking
 focus to another image and drawing at a smaller size, but that simply
 crashes with the following:

 2008-08-03 20:49:40.127 imagecompressor[16757:10b] _NXCreateWindow: error
 setting window property (1002)
 2008-08-03 20:49:40.132 imagecompressor[16757:10b] _NXPlaceWindow: error
 setting window shape (1002)
 2008-08-03 20:49:40.132 imagecompressor[16757:10b] _NSShapePlainWindow:
 error setting window shape (1002)
 2008-08-03 20:49:40.144 imagecompressor[16757:10b] PScurrentwindowbounds:
 CGSGetWindowBounds returned error (1002)
 Sun Aug  3 20:49:40 imagecompressor[16757] Error: CGSImageDataLockDevice:
 Bad device image source
 Sun Aug  3 20:49:40 imagecompressor[16757] Error: ripc_DrawWindowContents
 - Cannot acquire window image
 2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** -[NSCachedImageRep
 representationUsingType:properties:]: unrecognized selector sent to instance
 0x116c30
 2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** Terminating app due
 to uncaught exception 'NSInvalidArgumentException', reason: '***
 -[NSCachedImageRep representationUsingType:properties:]: unrecognized
 selector sent to instance 0x116c30'
 2008-08-03 20:49:40.146 imagecompressor[16757:10b] Stack: (
2527650123,
2500743419,
2527679306,
2527672652,
2527672850,
11646,
10094
 )
 Trace/BPT trap

 I hope someone could come to my aid!
 --
 定魅刀利
 Dimitri Bouniol
 [EMAIL PROTECTED]
 http://www.appkainime.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/kenferry%40gmail.com

 This email sent to [EMAIL PROTECTED]

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Colour of Symlink

2008-08-05 Thread Gerriet M. Denkmann



On 5 Aug 2008, at 14:37, Jean-Daniel Dupas wrote:


Le 5 août 08 à 08:13, Gerriet M. Denkmann a écrit :

I want to get the colour of a symlink (NOT the colour of the thing  
the symlinks points at).

Is there a Cocoa way to get this?

Currently I am using FSPathMakeRef (or CFURLGetFSRef) to get an  
FSRef, and then FSGetCatalogInfo to get the colour.


But both FSPathMakeRef and CFURLGetFSRef seem to follow through  
symlinks (not aliases though).
So I always get the colour of the destination (or an error if the  
symlink is broken).


How can I get the colour of my symlink?



Have a look at FSPathMakeRefWithOptions();
Hint: the only option currently available for this function is  
kFSPathMakeRefDoNotFollowLeafSymlink


Thank you very much, this is exactly what I was looking for. Only I  
was looking at the wrong place. The only location where this function  
is mentioned (at least in the Tiger documentation) is the Core  
Services Reference Update (without any info except the name) and  
Files.h in MacOSX10.4u.sdk (with all the info needed).


So, I would never have found it without your kind help.

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 [EMAIL PROTECTED]

Re: Message Framework and Garbage Collection

2008-08-05 Thread Nick Zitzmann



On Aug 5, 2008, at 4:18 AM, Ruotger Skupin wrote:

Does anyone know, a way to send a mail programmatically in the  
background, i.e. without opening a mailto:; url?



You can either write your own code to talk directly to an SMTP server,  
or use Pantomime, or use the Scripting Bridge. Check the archives for  
more details.


Nick Zitzmann
http://www.chronosnet.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 [EMAIL PROTECTED]

Re: Colour of Symlink

2008-08-05 Thread Sean McBride

On 8/5/08 8:34 PM, Gerriet M. Denkmann said:

Thank you very much, this is exactly what I was looking for. Only I
was looking at the wrong place. The only location where this function
is mentioned (at least in the Tiger documentation) is the Core
Services Reference Update (without any info except the name) and
Files.h in MacOSX10.4u.sdk (with all the info needed).

When it comes to functions in the Carbon File Manager, searching through
Files.h is often very helpful, the header is very well commented.
FSPathMakeRefWithOptions is just under FSPathMakeRef.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

indexed accessor properties and NSArray/NSMutableArray's

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this is  
my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the Array,  
it will use the Array directly. You can supply them if you want in  
which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you mutate  
it using KVC or bindings to a brand new array, not very efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be replaced  
each time. (this surprised me). If you want the efficient insert/ 
remove for your NSMutableArray property, you have to write the  
accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need the  
accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have mutable  
access you *must* implement two extra methods. However if your entire  
property is an NSArray or subclass thereof, you don't have to  
implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in the  
case of an NSArray, it would realize the property was a MutableArray,  
and mutate it directly, but no, it does it the slow way.


I could imagine not bothering to write the mutator methods just seeing  
that it worked automagically and never realising that the entire Array  
is being swapped out each time I changed it, probably not very  
efficient. So the moral of the story for me is .. if I want any multi- 
value for a key, even if the underlying instance variable is an array,  
write the accessor/mutator methods every time.





___

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

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

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

This email sent to [EMAIL PROTECTED]

IKSlideshow Question

2008-08-05 Thread Robert McCullough

The IKSlideshowDataSource protocol for IKSlideshow includes several  
optional methods, one of which is nameOfSlideshowItemAtIndex.  
However, this method NEVER seems to be called. Anyone know why?

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's

The basic problem is, that KVO needs Notification-Messages. If you use  
KVC-compliant accessor methods this will be done for you by a faked  
class.


If you have a mutable array and change the content (removal, insertion  
…), there is no chance of the KVO-runtime system to get a notification  
about this. Since you do not use the official methods, nobody does  
this work for you. So the work is undone: No snchronization.


You can (and in this case: have to) trigger the notifications  
manually. Something like this:

// typed in Mail.app, no warranty for nothing:
NSMutableArray* myRefs = self.myRefs;
[self willChange:NSKeyValueChangeInsertion valuesAtIndex:[NSIndexSet  
indexSetWithIndex:0] withKey:@myRefs];

[myRefs insertObject:… atIndex:0];
[self didChange:NSKeyValueChangeInsertion valuesAtIndex:[NSIndexSet  
indexSetWithIndex:0] withKey:@myRefs];


Amin

Am Di,05.08.2008 um 17:22 schrieb Roland King:

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this is  
my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the  
Array, it will use the Array directly. You can supply them if you  
want in which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you mutate  
it using KVC or bindings to a brand new array, not very efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be  
replaced each time. (this surprised me). If you want the efficient  
insert/remove for your NSMutableArray property, you have to write  
the accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need  
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have  
mutable access you *must* implement two extra methods. However if  
your entire property is an NSArray or subclass thereof, you don't  
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in  
the case of an NSArray, it would realize the property was a  
MutableArray, and mutate it directly, but no, it does it the slow way.


I could imagine not bothering to write the mutator methods just  
seeing that it worked automagically and never realising that the  
entire Array is being swapped out each time I changed it, probably  
not very efficient. So the moral of the story for me is .. if I want  
any multi-value for a key, even if the underlying instance variable  
is an array, write the accessor/mutator methods every time.





___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's


On Aug 5, 2008, at 10:22 AM, Roland King wrote:

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this  
is my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the  
Array, it will use the Array directly. You can supply them if you  
want in which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you  
mutate it using KVC or bindings to a brand new array, not very  
efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be  
replaced each time. (this surprised me). If you want the efficient  
insert/remove for your NSMutableArray property, you have to write  
the accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need  
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have  
mutable access you *must* implement two extra methods. However if  
your entire property is an NSArray or subclass thereof, you don't  
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in  
the case of an NSArray, it would realize the property was a  
MutableArray, and mutate it directly, but no, it does it the slow way.


I could imagine not bothering to write the mutator methods just  
seeing that it worked automagically and never realising that the  
entire Array is being swapped out each time I changed it, probably  
not very efficient. So the moral of the story for me is .. if I  
want any multi-value for a key, even if the underlying instance  
variable is an array, write the accessor/mutator methods every time.


Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed accessors.  
This seems to work in my testing, at least.


-Jeff

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: GetDblTime, 64-bit, and cocoa

2008-08-05 Thread Sean McBride

On 7/22/08 11:48 AM, [EMAIL PROTECTED] said:

i need to set a timer when i get a first mouse click and perform
something if i don't get another click within the double click time.
i found this old thread (from 2003) in the archives:
http://www.cocoabuilder.com/archive/message/cocoa/2003/10/22/90328
from that thread, it would appear that the best solution may be to
use GetDblTime. but this is a 32-bit only solution. is there a
documented (cocoa) way to do this that may be future/64-bit safe?

Since no one else has replied, I'll just say that I searched around and
have come to the same conclusion as you.  It looks like it was
deprecated without any replacement being added.  You should definitely
file a bug.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's



On Aug 5, 2008, at 11:50 PM, Jeff Johnson wrote:


On Aug 5, 2008, at 10:22 AM, Roland King wrote:

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this  
is my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the  
Array, it will use the Array directly. You can supply them if you  
want in which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you  
mutate it using KVC or bindings to a brand new array, not very  
efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be  
replaced each time. (this surprised me). If you want the efficient  
insert/remove for your NSMutableArray property, you have to write  
the accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need  
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have  
mutable access you *must* implement two extra methods. However if  
your entire property is an NSArray or subclass thereof, you don't  
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in  
the case of an NSArray, it would realize the property was a  
MutableArray, and mutate it directly, but no, it does it the slow  
way.


I could imagine not bothering to write the mutator methods just  
seeing that it worked automagically and never realising that the  
entire Array is being swapped out each time I changed it, probably  
not very efficient. So the moral of the story for me is .. if I  
want any multi-value for a key, even if the underlying instance  
variable is an array, write the accessor/mutator methods every time.


Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed accessors.  
This seems to work in my testing, at least.


-Jeff



An ArrayController is doing it for me. I started with the property  
being an NSArray(), to see what happened, and the entire NSArray() was  
switched on each addition, I know this because I implemented setkey  
and stuck a breakpoint in it. That made sense. Then I changed it all  
to NSMutableArray, the instance variable, the property accessor  
methods, everything but still it called the setkey mehtod and  
replaced the entire Array and didn't mutate the one in the property.  
Only after I put in the indexed accessors did it start using them.


The method you mention is what I was just about to try out in a  
standalone piece of code to check it, it'll be interesting if that  
does mutate the array directly, I did expect however that  
NSMutableArray, being as it's 'the' array controller, would be calling  
the correct KVC-compliant methods. Perhaps it's working differently as  
the ArrayController is bound to the property.



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's



Am Di,05.08.2008 um 17:50 schrieb Jeff Johnson:


On Aug 5, 2008, at 10:22 AM, Roland King wrote:

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this  
is my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the  
Array, it will use the Array directly. You can supply them if you  
want in which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you  
mutate it using KVC or bindings to a brand new array, not very  
efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be  
replaced each time. (this surprised me). If you want the efficient  
insert/remove for your NSMutableArray property, you have to write  
the accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need  
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have  
mutable access you *must* implement two extra methods. However if  
your entire property is an NSArray or subclass thereof, you don't  
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in  
the case of an NSArray, it would realize the property was a  
MutableArray, and mutate it directly, but no, it does it the slow  
way.


I could imagine not bothering to write the mutator methods just  
seeing that it worked automagically and never realising that the  
entire Array is being swapped out each time I changed it, probably  
not very efficient. So the moral of the story for me is .. if I  
want any multi-value for a key, even if the underlying instance  
variable is an array, write the accessor/mutator methods every time.


Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed accessors.  
This seems to work in my testing, at least.
Yup, that works, because the methods -mutableArrayValueForKey:, - 
mutableArrayValueForKeyPath:, -mutableSetValueForKey: and - 
mutableSetValueForKeyPath: manually triggers the notifications.


But:

1. I thought, that it is a miracle to him, why only the specified  
patterns work, but no other.


2.1. If -mutableCollectionValueForKey: should work efficient, you have  
to return a mutable ivar on your accessors (getter). This means, that  
*everyone* can change items in that collection without triggering kvo.  
This is the opposition of encapsulation and very, very dangerous.


2.2. It is possible to give the accessors an immutable type (NSArray,  
NSSet) and in reality return a mutable instacne. IIRC, - 
mutableCollectionValueForKey: will check the returned class of the  
instance, not for the type of the arguments. (I'm nut sure about  
this, but nearly. You can check it in the debugger by looking on the  
instance addresses.)


Amin




-Jeff

___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: image type of the AdressBook image data

2008-08-05 Thread Wayne Shao

Heinrich, Ken,

Thank you both for the information.

Wayne

On Tue, Aug 5, 2008 at 2:51 AM, Heinrich Giesen
[EMAIL PROTECTED] wrote:

 On 05.08.2008, at 10:03, Wayne Shao wrote:

 The imageData method returns NSData*.  Is there anyway to know the
 image type (e.g, PNG, TIFF, or JPEG) of the data?


 besides that what Ken Ferry wrote you may also use (as I do) a low level
 way to determine the image type: check for the magic number of image data.

   const unsigned char *bytes = [imageData bytes];
   //NSLog( @%02x %02x %02x %02x , bytes[0], bytes[1], bytes[2], bytes[3]
 );
   BOOL isTIFF_BigEndian = (bytes[0]=='M')  (bytes[1]=='M');
   BOOL isTIFF_LittleEndian = (bytes[0]=='I')  (bytes[1]=='I');
   BOOL isJPEG= (bytes[0]==0xff)  (bytes[1]==0xd8)  (bytes[2]==0xff);
   BOOL isPNG = (bytes[0]==0x89)  (bytes[1]=='P')  (bytes[2]=='N') 
 (bytes[3]=='G')
  (bytes[4]==0x0d)  (bytes[5]==0x0a)  (bytes[6]==0x1a)
  (bytes[7]==0x0a);
   BOOL isGIF = (bytes[0]=='G')  (bytes[1]=='I')  (bytes[2]=='F');
   BOOL isPDF = (bytes[0]=='%')  (bytes[1]=='P')  (bytes[2]=='D')
  (bytes[3]=='F')  (bytes[4]=='-');
   BOOL isBMP = (bytes[0]=='B')  (bytes[1]=='M');
   BOOL isICNS= (bytes[0]=='i')  (bytes[1]=='c')  (bytes[2]=='n') 
 (bytes[3]=='s');


 The Carbon/Cocoa functions and methods do nothing else, they test the magic
 number.

Heinrich

 --
 Heinrich Giesen
 [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's



On Aug 5, 2008, at 11:50 PM, Jeff Johnson wrote:


On Aug 5, 2008, at 10:22 AM, Roland King wrote:

I've now read the KVC documentation quite a number of times ..  
especially with regards to indexed accessor properties trying to  
really understand them. After a bit of messing about in code this  
is my understanding ..


1) if your property is an array you don't need to supply the  
countOfkey and objectInkeyAtIndex: methods for reading the  
Array, it will use the Array directly. You can supply them if you  
want in which case it will use them.


2) If you don't supply the mutable access methods  
insertObject:inkeyAtIndex: and removeObjectFromkeyAtIndex: but  
your property is a NSArray, it will still actually work, what will  
happen is the entire array property will be set each time you  
mutate it using KVC or bindings to a brand new array, not very  
efficient.


3) 2) above is true not only for an NSArray, (obviously as it's not  
mutable) but for an NSMutableArray too. Even if your property is a  
NSMutableArray which could be mutated, if you haven't supplied the  
mutable access methods, it won't be, the entire array will be  
replaced each time. (this surprised me). If you want the efficient  
insert/remove for your NSMutableArray property, you have to write  
the accessor methods explicitly.



1) didn't suprise me as the documentation indicates you only need  
the accessor methods when the property isn't an array.
2) surprised me a bit as the documentation states that to have  
mutable access you *must* implement two extra methods. However if  
your entire property is an NSArray or subclass thereof, you don't  
have to implement them, it just does it rather slowly.
3) did surprise me a bit given that 2) worked, I expected if it was  
smart enough to work around the absence of the mutator methods in  
the case of an NSArray, it would realize the property was a  
MutableArray, and mutate it directly, but no, it does it the slow  
way.


I could imagine not bothering to write the mutator methods just  
seeing that it worked automagically and never realising that the  
entire Array is being swapped out each time I changed it, probably  
not very efficient. So the moral of the story for me is .. if I  
want any multi-value for a key, even if the underlying instance  
variable is an array, write the accessor/mutator methods every time.


Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed accessors.  
This seems to work in my testing, at least.


-Jeff



I don't get that in my testing. As trivial an example as I can make  
below, Foo, one property, prop, it's a NSMutableArray*, has a getter  
and a setter. The main() function calls


[ [ foo mutableArrayValueForKey:@prop ] addObject:@something ]

and that replaces the array by calling setProp:, doesn't mutate the  
one there.


Only when I add both (not just the insert, but both insert and remove)  
of the mutator methods, will access via the mutableArrayForKey call  
insertObject:inPropAtIndex:




@interface Foo : NSObject {
NSMutableArray *prop;
}

-(id)init;
-(void)dealloc;

-(NSMutableArray*)prop;
-(void)setProp:(NSMutableArray*)propVal;

@end



@implementation Foo

-(id)init
{
self = [ super init ];
if( self )
{
prop = [ [ NSMutableArray alloc ] init ];
}

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

-(NSMutableArray*)prop
{
return prop;
}
-(void)setProp:(NSMutableArray*)propVal
{
[ propVal retain ];
[ prop release ];
prop = propVal;
}

@end



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

Foo *foo = [ [ Foo alloc ] init ];

[[ foo mutableArrayValueForKey:@prop ] addObject:@Another  
String ];


[pool drain];
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 [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's


On Aug 5, 2008, at 11:56 AM, Roland King wrote:


On Aug 5, 2008, at 11:50 PM, Jeff Johnson wrote:


Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed  
accessors. This seems to work in my testing, at least.


-Jeff



I don't get that in my testing. As trivial an example as I can make  
below, Foo, one property, prop, it's a NSMutableArray*, has a  
getter and a setter. The main() function calls


[ [ foo mutableArrayValueForKey:@prop ] addObject:@something ]

and that replaces the array by calling setProp:, doesn't mutate the  
one there.


Only when I add both (not just the insert, but both insert and  
remove) of the mutator methods, will access via the  
mutableArrayForKey call insertObject:inPropAtIndex:




@interface Foo : NSObject {
NSMutableArray *prop;
}

-(id)init;
-(void)dealloc;

-(NSMutableArray*)prop;
-(void)setProp:(NSMutableArray*)propVal;

@end



@implementation Foo

-(id)init
{
self = [ super init ];
if( self )
{
prop = [ [ NSMutableArray alloc ] init ];
}

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

-(NSMutableArray*)prop
{
return prop;
}
-(void)setProp:(NSMutableArray*)propVal
{
[ propVal retain ];
[ prop release ];
prop = propVal;
}

@end



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

Foo *foo = [ [ Foo alloc ] init ];

[[ foo mutableArrayValueForKey:@prop ] addObject:@Another  
String ];


[pool drain];
return 0;
}



Roland,

Right, that's because you've defined a setter. See the search  
algorithm documented for mutableArrayValueForKey: at http:// 
developer.apple.com/documentation/Cocoa/Reference/Foundation/ 
Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html#// 
apple_ref/doc/uid/2471-BABJFEAE. Try removing the setter.


-Jeff

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's



Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed accessors.  
This seems to work in my testing, at least.
Yup, that works, because the methods -mutableArrayValueForKey:, - 
mutableArrayValueForKeyPath:, -mutableSetValueForKey: and - 
mutableSetValueForKeyPath: manually triggers the notifications.




not for me it doesn't, see my other reply, without the mutator methods  
defined in the class, it doesn't preserve the NSMutableArray, it  
changes it for a new array.


Note none of my mail has been about triggering notifications nor have  
I been talking about using 'behind the scenes' ways of changing  
arrays. My mail has been only about how, when you use a correct KVC  
pattern, a binding or mutableArrayValueForKey: and the property you're  
mutating happens to actually be an Array, it actually ends up getting  
mutated when you do, or do not, provide the mutable accessor methods.



But:

1. I thought, that it is a miracle to him, why only the specified  
patterns work, but no other.


Not so. The documentation says this

The key-value coding methods mutableArrayValueForKey: and  
mutableArrayValueForKeyPath: provide mutable access to a to-many  
relationship, regardless of the class used to model the relationship.  
In order to support these methods, your class must implement two  
additional methods for each of these keys: - 
insertObject:inKeyAtIndex: and -removeObjectFromKeyAtIndex:.


however in the case of an NSArray property, even if you do not  
implement them, mutableArrayValueForKey: still provides mutable access  
to the contents of the array property, albeit by changing the entire  
property for a brand new array. The specified pattern says I *must*  
implement those methods for it to work, however it worked even when I  
didn't, I went to find out why.





2.1. If -mutableCollectionValueForKey: should work efficient, you  
have to return a mutable ivar on your accessors (getter). This  
means, that *everyone* can change items in that collection without  
triggering kvo. This is the opposition of encapsulation and very,  
very dangerous.




That I agree with - and my test in the last mail seems to indicate  
that encapsulation is preserved. I wasn't able to get  
mutableanything to change the array directly. That's good.


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's


On Aug 5, 2008, at 11:01 AM, Negm-Awad Amin wrote:

2.1. If -mutableCollectionValueForKey: should work efficient, you  
have to return a mutable ivar on your accessors (getter). This  
means, that *everyone* can change items in that collection without  
triggering kvo. This is the opposition of encapsulation and very,  
very dangerous.


You don't need a getter if you use accessInstanceVariablesDirectly  
(which returns YES by default).


-Jeff

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's




Am Di,05.08.2008 um 19:11 schrieb Roland King:



Roland,

How are you mutating your array? If you do [[myObject  
mutableArrayValueForKey:@myArray] addObject:anObject], it should  
preserve the current NSMutableArray even without indexed  
accessors. This seems to work in my testing, at least.
Yup, that works, because the methods -mutableArrayValueForKey:, - 
mutableArrayValueForKeyPath:, -mutableSetValueForKey: and - 
mutableSetValueForKeyPath: manually triggers the notifications.




not for me it doesn't, see my other reply, without the mutator  
methods defined in the class, it doesn't preserve the  
NSMutableArray, it changes it for a new array.


Note none of my mail has been about triggering notifications nor  
have I been talking about using 'behind the scenes' ways of changing  
arrays. My mail has been only about how, when you use a correct KVC  
pattern, a binding or mutableArrayValueForKey: and the property  
you're mutating happens to actually be an Array, it actually ends up  
getting mutated when you do, or do not, provide the mutable accessor  
methods.

Okay, I misunderstood your mail.
Sorry for sending the answer directly …



But:

1. I thought, that it is a miracle to him, why only the specified  
patterns work, but no other.


Not so. The documentation says this

The key-value coding methods mutableArrayValueForKey: and  
mutableArrayValueForKeyPath: provide mutable access to a to-many  
relationship, regardless of the class used to model the  
relationship. In order to support these methods, your class must  
implement two additional methods for each of these keys: - 
insertObject:inKeyAtIndex: and -removeObjectFromKeyAtIndex:.


however in the case of an NSArray property, even if you do not  
implement them, mutableArrayValueForKey: still provides mutable  
access to the contents of the array property, albeit by changing the  
entire property for a brand new array. The specified pattern says I  
*must* implement those methods for it to work, however it worked  
even when I didn't, I went to find out why.


No, I think you misunderstood the documentation. It says, that you  
have to implement this methods to get mutable *access*. Mutable access  
means in this context, that mutating accessor mathods are used. To  
change the array or build a new array and than sending a setProperty- 
message to the holding instance is not mutable access, because  
semantically *setting* an (old or new) array is no mutation of an  
existing array.


Hmm, I know, that I speak englisch very badly. Did you understand,  
what I want to say?





2.1. If -mutableCollectionValueForKey: should work efficient, you  
have to return a mutable ivar on your accessors (getter). This  
means, that *everyone* can change items in that collection without  
triggering kvo. This is the opposition of encapsulation and very,  
very dangerous.




That I agree with - and my test in the last mail seems to indicate  
that encapsulation is preserved. I wasn't able to get  
mutableanything to change the array directly. That's good.




Amin Negm-Awad
[EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

How is image drawing rate effected by image resolution and size?

2008-08-05 Thread Frederick Bartram

I am having difficulty understanding the issues involved in image  
drawing speed.


I have a large, ~10K x 10K image in a scrolling view. The image is  
loaded as a PNG file into an NSImageView from a nib. I am getting  
large differences in the image drawing speed that I do not understand.  
The image at a resolution of 72dpi, at the default settings as loaded  
from the nib, draws very,very slowly.


If I change the size of the image either larger or smaller, drawing  
rate increases dramatically.
If I change the resolution from 72dpi to 96dpi, for example, but not  
the total pixel count then the image drawing rate also improves greatly.


Can someone provide some guidance as to what is happening?

Many thanks,

RickB
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: GetDblTime, 64-bit, and cocoa

2008-08-05 Thread Gary L. Wade

Well, the global domain has this key:

com.apple.mouse.doubleClickThreshold

On 7/22/08 11:48 AM, [EMAIL PROTECTED] said:

i need to set a timer when i get a first mouse click and perform
something if i don't get another click within the double click time.
i found this old thread (from 2003) in the archives:
http://www.cocoabuilder.com/archive/message/cocoa/2003/10/22/90328
from that thread, it would appear that the best solution may be to
use GetDblTime. but this is a 32-bit only solution. is there a
documented (cocoa) way to do this that may be future/64-bit safe?

Since no one else has replied, I'll just say that I searched around and
have come to the same conclusion as you.  It looks like it was
deprecated without any replacement being added.  You should definitely
file a bug.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Loading a class with a specific superclass from a bundle

2008-08-05 Thread Elan Feingold


Hi,

I can load the principal class of a bundle with:

NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
Class exampleClass = [bundleToLoad principalClass]);

However, I have a situation where I have a bundle that has a class  
*without* a principal class, but it has a class that is a subclass of  
a specific other class. Is there any way to iterate through classes  
offered by a bundle and pick out the ones that derive from a specific  
superclass?


Thanks,

-elan
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: reloading an NSTreeController

2008-08-05 Thread Jonathan Dann



On 4 Aug 2008, at 14:04, Gerriet M. Denkmann wrote:



On 3 Aug 2008, at 16:53, Jonathan Dann wrote:


On 3 Aug 2008, at 04:35, Gerriet M. Denkmann wrote:


On 3 Aug 2008, at 05:51, Jonathan Dann wrote:


On 1 Aug 2008, at 14:04, Gerriet M. Denkmann wrote:

But all disclosure triangels are now closed. Is there some way  
to reopen them to the previous state?
I have the strong feeling that I will have to handle this  
myself. Ok. So be it.


It's a common problem.  Can I point you here:

http://www.cocoabuilder.com/archive/message/cocoa/2008/2/23/199705


Thank you very much for this link. You provide there a very clever  
solution, but, as you aptly put in your posting: It uses  
NSTreeNode and -representedObject, so is 10.5 only.
But alas!, I need Tiger 10.4.11. (And am reluctant to use private  
methods which you hint at in your posting).


Ah, sorry about that, I didn't realise.  What you can do is have a  
look at


http://www.wilshipley.com/blog/2006/04/pimp-my-code-part-10-whining-about.html

Wil gives a few category methods like -objectAtIndexPath:  You can  
(maybe) get the index path the _NSArrayControllerTreeNode and then  
get your real object, in which you have an isExpanded flag.


I had a look at this. It seems that to get the real object one has  
to recursively search the whole tree.


You're right, it's a shame these methods aren't available out of the  
box.




In my case it seems to be much simpler just to forget about  
NSTreeController and use the good old DataSource.
This is not a question about premature optimization (the trees in my  
case are quite small) but just a disgust about the silly design of  
the 10.4 NSTreeController.


Thanks for your help!

Kind regards,

Gerriet.



Not a problem, sometimes it is easier to use a datasource rather than  
battle for ages to patch up other code.  Do what works for you.


Glad to be of help.

Jonathan

http://espresso-served-here.com



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 [EMAIL PROTECTED]

Re: Loading a class with a specific superclass from a bundle

2008-08-05 Thread Bill Bumgarner


On Aug 5, 2008, at 11:19 AM, Elan Feingold wrote:

I can load the principal class of a bundle with:

NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
Class exampleClass = [bundleToLoad principalClass]);

However, I have a situation where I have a bundle that has a class  
*without* a principal class, but it has a class that is a subclass  
of a specific other class. Is there any way to iterate through  
classes offered by a bundle and pick out the ones that derive from a  
specific superclass?


class *without* a principal class doesn't make sense.

- all bundles have a principal class,  automatically (and semi- 
randomly) chosen if you don't specify it


- all classes have a super class (unless it is a root class)

If you go to the target inspector's Properties tab in your Xcode  
project, you can specifically set the bundle's principal class.


b.bum




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 [EMAIL PROTECTED]

Re: Loading a class with a specific superclass from a bundle



Am Di,05.08.2008 um 20:41 schrieb Bill Bumgarner:


On Aug 5, 2008, at 11:19 AM, Elan Feingold wrote:

I can load the principal class of a bundle with:

NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
Class exampleClass = [bundleToLoad principalClass]);

However, I have a situation where I have a bundle that has a class  
*without* a principal class, but it has a class that is a subclass  
of a specific other class. Is there any way to iterate through  
classes offered by a bundle and pick out the ones that derive from  
a specific superclass?


class *without* a principal class doesn't make sense.

- all bundles have a principal class,  automatically (and semi- 
randomly) chosen if you don't specify it


- all classes have a super class (unless it is a root class)

If you go to the target inspector's Properties tab in your Xcode  
project, you can specifically set the bundle's principal class.


b.bum
If I understood this mail correct, he has a bundle with a class C,  
which is not the principal class, but a (single?) subclass of another  
(propably abstract?) class  T (which can change). He does not know the  
name of C and tries to iterate through all classes in the bundle to  
find it.


- (Class)loadSubclassOfClass:(Class)T {
// ???
}

IIRC, somebody wrote code to extract classes (on a first step class  
names) from a bundle. I couldn''t google it. :-(


I understand the problem, that he does not know the subclass C of the  
bundle class T in the loading application. But the programmer of the  
bundle knows his class hierarchy. So he can write a principal class  
with the intention to return all classes in that bundle. The principal  
class only needs a class methode +myClassHierarchy.


Amin



___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: GetDblTime, 64-bit, and cocoa

2008-08-05 Thread Sean McBride

On 8/5/08 2:00 PM, Gary L. Wade said:

Well, the global domain has this key:

com.apple.mouse.doubleClickThreshold

Good find.  Alas, the only hits on Apple's website are posts on this
list, which pretty much makes it an undocumented API; as opposed to
GetDblTime() which was a supported API.  Still, for 64 bit, I guess it's
the only choice.

--

Sean McBride, B. Eng [EMAIL PROTECTED]
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: How is image drawing rate effected by image resolution and size?

Le 5 août 08 à 19:48, Frederick Bartram a écrit :

I am having difficulty understanding the issues involved in image
drawing speed.

I have a large, ~10K x 10K image in a scrolling view. The image is
loaded as a PNG file into an NSImageView from a nib. I am getting
large differences in the image drawing speed that I do not
understand. The image at a resolution of 72dpi, at the default
settings as loaded from the nib, draws very,very slowly.

If I change the size of the image either larger or smaller, drawing
rate increases dramatically.
If I change the resolution from 72dpi to 96dpi, for example, but not
the total pixel count then the image drawing rate also improves
greatly.

Can someone provide some guidance as to what is happening?

Many thanks,

RickB

The NSImage use differents representations to store your image data,
and probably create NSCachedImageRep when the image does not have
expected caracteristics (72 dpi ) and when you resize it.
The NSCchedImageRep use an internal representation that is optimal for
drawing, that probably explain your difference.

See the Image section of Cocoa Drawing guide for details and some tips
to change the caching behavior of an image:

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Images/chapter_7_section_2.html

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote 
(Tuesday, August 5, 2008 5:41 AM +0100):

My superclass (SuperSocket) provides a private method -close.


Others have adiquetly explained the whole 'self' vs. 'super' 
issue, but this statement still has me stumped and I'm wondering 
why this even came up.


There is no such thing as a private method in Objective-C. The 
@private, @protected, @public keywords only work on instance 
variables. So if the super class implements -close, there should 
never be anything stopping your subclass from simply calling 
[super close].


--
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 [EMAIL PROTECTED]

ERROR in Xcode 3 Unleashed

2008-08-05 Thread Fritz Anderson

I want you to be aware of an error in Chapter 8 (page 97) of my book,  
Xcode 3 Unleashed.


This chapter covers setting up for version control with Subversion,  
and advises that the following be added to the global-ignores line of  
the ~/.subversion/config file:


build * .nib *.so *.pbxuser *.mode* *.perspective*

THIS IS IN ERROR. The added text should properly be

build *~.nib *.so *.pbxuser *.mode* *.perspective*

Depending on how you read the line, this would exclude either all .nib  
packages, or worse, ALL files, from version control.


You'll be tipped off to the error if the checked-out copy of your  
project is empty, or lacks NIB files. Regardless, you will have to  
take corrective action now.


The remedy is

1) Edit the ~/.subversion/config file as shown.

2) Use the Finder (or the command line, if you prefer) to visit each  
working-copy directory you checked out since you originally edited  
~/.subversion/config. Identify the files that are missing, and copy  
them into the working directory from your original project directory.


3) On the command line, do a svn add, listing the formerly-missing  
files.


It is important you do this to avoid loss of data.


The editing process had been plagued with dropped tildes, and this one  
slipped through. I deeply apologize for this error. My publisher and I  
are doing what we can to correct 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 [EMAIL PROTECTED]

Re: Loading a class with a specific superclass from a bundle

2008-08-05 Thread Michael Ash

On Tue, Aug 5, 2008 at 2:19 PM, Elan Feingold [EMAIL PROTECTED] wrote:
 Hi,

 I can load the principal class of a bundle with:

 NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
 Class exampleClass = [bundleToLoad principalClass]);

 However, I have a situation where I have a bundle that has a class *without*
 a principal class, but it has a class that is a subclass of a specific other
 class. Is there any way to iterate through classes offered by a bundle and
 pick out the ones that derive from a specific superclass?

Start here:

http://www.cocoadev.com/index.pl?FindingAllSubclassesOfAClass

Using that code as a base, it's pretty easy to add an extra filter
that checks the bundle of each returned class and accepts only those
that are in the specified bundle.

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 [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread Shawn Erickson

On Tue, Aug 5, 2008 at 12:18 PM, James Bucanek [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote (Tuesday,
 August 5, 2008 5:41 AM +0100):

 My superclass (SuperSocket) provides a private method -close.

 Others have adiquetly explained the whole 'self' vs. 'super' issue, but this
 statement still has me stumped and I'm wondering why this even came up.

 There is no such thing as a private method in Objective-C. The @private,
 @protected, @public keywords only work on instance variables. So if the
 super class implements -close, there should never be anything stopping your
 subclass from simply calling [super close].

True however...

It could be that he has a method defined in a class continuation
(Objective-C 2.0) or private category in an implementation file. This
would result in subclasses not seeing the methods declaration.

So if the subclass attempts to send such a method at a minimum the
compiler may warn about it not responding to that method (depends on
the packaging of the super class in question) and at worst the
compiler could emit a call chain that incorrectly passes parameters
and/or fetches the return value as result of incorrect assumptions
about parameter/return types (should see a warning as well).

-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 [EMAIL PROTECTED]

Re: Using performSelector: on super

 There is no such thing as a private method in Objective-C. The @private,
 @protected, @public keywords only work on instance variables. So if the
 super class implements -close, there should never be anything stopping your
 subclass from simply calling [super close].

  In this case, [super close] and [self close] are the same thing.
Because you never overrode the -close method in your subclass, it
doesn't matter, but if you ever do decide to override -close in your
subclass, all the parts where you call [super close] will be broken.

  I'm going to make a bold statement: You should only ever call [super
someMethod] from within an overridden someMethod implementation. I
believe this is true in all cases (because I can't at the moment
imagine a case where you'd do otherwise). Third party opinions are
welcome.

--
I.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 [EMAIL PROTECTED]

Re: ERROR in Xcode 3 Unleashed

2008-08-05 Thread Fritz Anderson


On 5 Aug 2008, at 2:37 PM, Kyle Sluder wrote:


Sounds like the book was typeset in TeX.  I've been there before.  ;-)


You got it. Colored, indented, and brace-balanced source code was an  
adventure, too.


— 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 [EMAIL PROTECTED]

Re: Loading a class with a specific superclass from a bundle

2008-08-05 Thread Chris Hanson


On Aug 5, 2008, at 11:19 AM, Elan Feingold wrote:


I can load the principal class of a bundle with:

NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
Class exampleClass = [bundleToLoad principalClass]);


Actually, this loads the bundle and then gets its principal class.   
Loading a bundle will load all of the classes in it, regardless of  
whether you're just asking for the principal class


However, I have a situation where I have a bundle that has a class  
*without* a principal class, but it has a class that is a subclass  
of a specific other class. Is there any way to iterate through  
classes offered by a bundle and pick out the ones that derive from a  
specific superclass?


As others have explained, a bundle always has a principal class; if  
one isn't specified, one of the classes defined within the bundle will  
be returned.


What you probably want to do is load the bundle and then look through  
the Objective-C runtime for classes whose superclass is one of those  
you care about.  You can use objc_getClassList to iterate over the  
classes known to the runtime, and objc_getSuperclass to locate the  
superclass of a class.  (There's no objc_getSubclassList.)


  -- Chris

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread Andy Lee


On Aug 5, 2008, at 3:39 PM, I. Savant wrote:

 I'm going to make a bold statement: You should only ever call [super
someMethod] from within an overridden someMethod implementation. I
believe this is true in all cases (because I can't at the moment
imagine a case where you'd do otherwise). Third party opinions are
welcome.


The one case that comes to mind is when a designated initializer calls  
its superclass's different designated initializer.


--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 [EMAIL PROTECTED]

Re: Using performSelector: on super

On Tue, Aug 5, 2008 at 4:20 PM, Andy Lee [EMAIL PROTECTED] wrote:

 The one case that comes to mind is when a designated initializer calls its
 superclass's different designated initializer.

  BINGO! We have a winner! :-)

--
I.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 [EMAIL PROTECTED]

Re: Properties and memory management

2008-08-05 Thread Marcel Weiher



On Aug 5, 2008, at 2:57 , Uli Kusterer wrote:


You may fire off observer methods too, which is probably undesirable.


Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY()  
macros for these purposes, and since most of my code still needs to  
be 10.4-compatible, I've mostly been using those:


http://www.zathras.de/angelweb/sourcecode.htm#UKHelperMacros

Though I vaguely remember getting lectured by someone about why it's  
better to *always* use the accessors a while ago ... wish I  
remembered what the reasoning behind that was, and why I thought it  
might be a good idea to follow that, but OTOH didn't follow it :-/


So why not go one step further and let macros generate the accessor  
for you (of course using the ASSIGN() macro inside those generated  
accessors)?


Marcel

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

I. Savant mailto:[EMAIL PROTECTED] wrote (Tuesday, 
August 5, 2008 12:39 PM -0400):



There is no such thing as a private method in Objective-C. The @private,
@protected, @public keywords only work on instance variables. So if the
super class implements -close, there should never be anything stopping your
subclass from simply calling [super close].


In this case, [super close] and [self close] are the same thing.
Because you never overrode the -close method in your subclass, it
doesn't matter, but if you ever do decide to override -close in your
subclass, all the parts where you call [super close] will be broken.


The OP did override -close in their subclass and were attempting 
to call [super close] from the subclass' -close method. The OP 
stated that they couldn't simply use [super close] because 
-close was private, which didn't make any sense to me.


--
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 [EMAIL PROTECTED]

Re: Using performSelector: on super

Shawn Erickson mailto:[EMAIL PROTECTED] wrote (Tuesday, August 
5, 2008 12:38 PM -0700):



On Tue, Aug 5, 2008 at 12:18 PM, James Bucanek [EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote (Tuesday,
August 5, 2008 5:41 AM +0100):


My superclass (SuperSocket) provides a private method -close.


Others have adiquetly explained the whole 'self' vs. 'super' issue, but this
statement still has me stumped and I'm wondering why this even came up.

There is no such thing as a private method in Objective-C. The @private,
@protected, @public keywords only work on instance variables. So if the
super class implements -close, there should never be anything stopping your
subclass from simply calling [super close].


True however...


clip

and at worst the
compiler could emit a call chain that incorrectly passes parameters
and/or fetches the return value as result of incorrect assumptions
about parameter/return types (should see a warning as well).


I don't see how that is possible. The only difference between 
[self method] and [super method] is the former calls 
objc_msgSend and the later calls objc_msgSendSuper. In the OP's 
situation, the methods must have the same prototype and the 
determination of what -close method is implemented by the 
superclass is done at runtime by objc_msgSendSuper. So there 
aren't any compiler assumptions that could influence this 
(beyond the compiler complaining that it doesn't think that the 
superclass actually implements the method).


--
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 [EMAIL PROTECTED]

Re: Using performSelector: on super

On Tue, Aug 5, 2008 at 4:31 PM, James Bucanek [EMAIL PROTECTED] wrote:

 The OP did override -close in their subclass and were attempting to call
 [super close] from the subclass' -close method. The OP stated that they
 couldn't simply use [super close] because -close was private, which didn't
 make any sense to me.

  Yes, I was ignoring that part because I assumed it was just poorly
phrased (and later corrected). Perhaps, Jonathan, you could elaborate
on what leads you to believe the -close method is private?

--
I.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 [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread Michael Ash

On Tue, Aug 5, 2008 at 8:41 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 Or am I on the wrong page entirely.

I'd suggest that you need to re-evaluate if this method should be private.

In OO languages with access controls, private usually means that
it's hidden from subclasses too. Protected is used to describe
things that can be accessed by subclasses but not be random externals.
Of course, ObjC supports protected methods even less than it supports
private methods.

But in general, if you want to call this method, you should show it to
the compiler. The simplest way to do that is to simply put it in the
superclass's header. Add a comment like only call from a subclass if
it's not supposed to be used in the general case. For things like this
I like to put the method in a separate category with an obvious name
like Subclasses to make the separation even more clear.

If you don't control this class, then you can declare the -close
method in a category in your own code, to tell the compiler that the
method really does exist.

And then in both cases, you can simply do [super close] instead of
this performSelector: stuff.

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 [EMAIL PROTECTED]

Re: Loading a class with a specific superclass from a bundle



Le 5 août 08 à 21:59, Chris Hanson a écrit :


On Aug 5, 2008, at 11:19 AM, Elan Feingold wrote:


I can load the principal class of a bundle with:

NSBundle* bundleToLoad = [NSBundle bundleWithPath:@...];
Class exampleClass = [bundleToLoad principalClass]);


Actually, this loads the bundle and then gets its principal class.   
Loading a bundle will load all of the classes in it, regardless of  
whether you're just asking for the principal class


However, I have a situation where I have a bundle that has a class  
*without* a principal class, but it has a class that is a subclass  
of a specific other class. Is there any way to iterate through  
classes offered by a bundle and pick out the ones that derive from  
a specific superclass?


As others have explained, a bundle always has a principal class; if  
one isn't specified, one of the classes defined within the bundle  
will be returned.


What you probably want to do is load the bundle and then look  
through the Objective-C runtime for classes whose superclass is one  
of those you care about.  You can use objc_getClassList to iterate  
over the classes known to the runtime, and objc_getSuperclass to  
locate the superclass of a class.  (There's no objc_getSubclassList.)


What about NSBundleDidLoadNotification?

The notification object is the NSBundle instance that dynamically  
loads classes. The userInfodictionary contains the following  
information:
	@NSLoadedClasses An NSArray object containing the names (as  
NSString objects) of each class that was loaded



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread [EMAIL PROTECTED]


Sorry for the inaccuracy.

I am well aware that there is no such thing as a true private method   
in Objective-C, though it seems generally common to refer to such  
contraptions (A, B and Y's Cocoa Programming contains such usage,  
page 81).


I of course mean that the SuperSocket class responds to the -close  
method but does not declare it in its interface file.
-close is indeed declared as a method on a SuperSocket category  
defined within SuperSocket.m


I was using performSelector: merely to keep the compiler content.
Declaring a further accessible category on SuperSocket to announce the  
existence of -close accomplished the same thing.


At least my initial lassitude in declaring that category ultimately  
decreased the sum total of my ignorance.

No more super self confusion for me!


On 5 Aug 2008, at 21:39, I. Savant wrote:

On Tue, Aug 5, 2008 at 4:31 PM, James Bucanek  
[EMAIL PROTECTED] wrote:


The OP did override -close in their subclass and were attempting to  
call
[super close] from the subclass' -close method. The OP stated that  
they
couldn't simply use [super close] because -close was private,  
which didn't

make any sense to me.


 Yes, I was ignoring that part because I assumed it was just poorly
phrased (and later corrected). Perhaps, Jonathan, you could elaborate
on what leads you to believe the -close method is private?

--
I.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 [EMAIL PROTECTED]

CGGStackRestore: gstack underflow

2008-08-05 Thread Gordon Apple

I'm getting  a ton of console messages:

Tue Aug  5 16:34:13 Macintosh-5.local RTP[2209] Error: CGGStackRestore:
gstack underflow.

What should I be looking for to find the problem?



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: CGGStackRestore: gstack underflow

2008-08-05 Thread Kyle Sluder

On Tue, Aug 5, 2008 at 5:44 PM, Gordon Apple [EMAIL PROTECTED] wrote:
 What should I be looking for to find the problem?

I'm not a CoreGraphics expert, but my first instinct is too many calls
to -[NSGraphicsContext restoreGraphicsState].

--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 [EMAIL PROTECTED]

Re: Properties and memory management

2008-08-05 Thread Uli Kusterer



On 05.08.2008, at 22:24, Marcel Weiher wrote:



On Aug 5, 2008, at 2:57 , Uli Kusterer wrote:

You may fire off observer methods too, which is probably  
undesirable.


Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY()  
macros for these purposes, and since most of my code still needs to  
be 10.4-compatible, I've mostly been using those:


http://www.zathras.de/angelweb/sourcecode.htm#UKHelperMacros

Though I vaguely remember getting lectured by someone about why  
it's better to *always* use the accessors a while ago ... wish I  
remembered what the reasoning behind that was, and why I thought it  
might be a good idea to follow that, but OTOH didn't follow it :-/


So why not go one step further and let macros generate the accessor  
for you (of course using the ASSIGN() macro inside those generated  
accessors)?



 Well, I'm using ASSIGN in the mutators. Did you have an even more  
cunning plan that would work?


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 [EMAIL PROTECTED]

Re: Using performSelector: on super

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote 
(Tuesday, August 5, 2008 2:19 PM +0100):



Sorry for the inaccuracy.


No problem.


I of course mean that the SuperSocket class responds to the -close
method but does not declare it in its interface file. -close is indeed
declared as a method on a SuperSocket category defined within
SuperSocket.m

I was using performSelector: merely to keep the compiler content.
Declaring a further accessible category on SuperSocket to announce the
existence of -close accomplished the same thing.


Then let me make two points and one suggestion.

In your original code, you had

SEL closeSelector = @selector(close);
if ([SuperSocket instancesRespondToSelector:closeSelector]) {
...

This does not, as I think you believe, test to see if an object 
of the class SuperSocket responds to the -close message. In 
fact, it tests to see if the class object for SuperSocket 
responds to the +close message. SuperSocket is a reference to 
the single Class object defined for SuperSocket, it it not a 
proxy for an instance of the SuperSocket class.


To determine if an instance of an object SuperSocket responds to 
a particular method, I believe that you'd have to use 
SuperSocket's Class object reference and use 
class_getInstanceMethod to determine if it actually implements a 
-close method. If you wanted to find out if any of its 
superclass' implemented it, you'd have to walk of the chain of 
parent Class objects until you hit NSObject.


As for the compiler warning, that could easily be suppressed 
with (believe it or not)


[(id)super close];  // superclass assumed to implement close

If you really want your code to dynamically alter execution 
depending on whether the close method is implemented by the 
superclass, I would suggest something like


try
{
[(id)super close];  // call superclass' -close, if implemented
...
}
catch
{
if (method not implemented exception)
// code that gets called if superclass doesn't 
implement -close

...
}
--
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 [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread Charles Steinman

--- On Tue, 8/5/08, James Bucanek [EMAIL PROTECTED] wrote:

 In your original code, you had
 
  SEL closeSelector = @selector(close);
  if ([SuperSocket
 instancesRespondToSelector:closeSelector]) {
  ...
 
 This does not, as I think you believe, test to see if an
 object 
 of the class SuperSocket responds to the -close message. In
 
 fact, it tests to see if the class object for SuperSocket 
 responds to the +close message.

That isn't correct. The +instancesRespondToSelector: method tells whether 
*instances* of a class respond to a selector. To test whether the class object 
responds to a given selector, you'd use [SuperSocket respondsToSelector:].

Cheers,
Chuck


  
___

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

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

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

This email sent to [EMAIL PROTECTED]

How to enable/disable buttons immediately after focus transfer

2008-08-05 Thread an0

I know how to do this for NSValidatedUserInterfaceItem by implementing
`- (BOOL)validateUserInterfaceItem:(id  NSValidatedUserInterfaceItem
)anItem'; however, NSSegmentedControl and NSButton do not conform to
NSValidatedUserInterfaceItem protocol, then how can I switch the
enable status of  these controls as an IMMEDIATE response to the focus
transfer?
Thanks in advance.
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Bindings to display an NSArray of NSStrings as a single NSString?

2008-08-05 Thread Hamish Allan

On Mon, Aug 4, 2008 at 6:32 PM, Dustin Robert Kick [EMAIL PROTECTED] wrote:

 This seems like it would be common enough, to me, that it would have
 bindings for it.

You could add a category to NSArray...

@implementation NSArray (ArrayOfStringsAsSingleString)
- (NSString *)arrayOfStringsAsSingleString { return [self
componentsJoinedByString:@, ]; }
@end

...and then bind to values.arrayOfStringsAsSingleString.

Hamish
___

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

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

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

This email sent to [EMAIL PROTECTED]

control user interface of an external application

2008-08-05 Thread falcon


Hello,

I have an application written using Qt. Is there any way to control it  
from another cocoa application?

For example something like following:

1) Get Qt application handle (or what ???)
2) Send something like keyboard event Tab to change active control  
till the necessary one.
3) Send keyboard event 5 (number 5) to change the value of the  
active control

4) Send Tab till OK button
5) Send event Enter

Thanks,
Alex




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Using performSelector: on super

Charles Steinman mailto:[EMAIL PROTECTED] wrote (Tuesday, 
August 5, 2008 4:20 PM -0700):



--- On Tue, 8/5/08, James Bucanek [EMAIL PROTECTED] wrote:


In your original code, you had

SEL closeSelector = @selector(close);
if ([SuperSocket
instancesRespondToSelector:closeSelector]) {
...

This does not, as I think you believe, test to see if an
object of the class SuperSocket responds to the -close 
message. In


fact, it tests to see if the class object for SuperSocket 
responds to the +close message.


That isn't correct. The +instancesRespondToSelector: method 
tells whether *instances* of a class respond to a selector. To 
test whether the class object responds to a given selector, 
you'd use [SuperSocket respondsToSelector:].


My bad, you're absolutely correct. I just misread it as respondsToSelector:.

--
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 [EMAIL PROTECTED]

Re: [SOLVED] Resizing a NSImage in a Cocoa command line tool

2008-08-05 Thread Dimitri Bouniol


Thank you very much - that worked perfectly.

On Aug 5, 2008, at 7:20 AM, Ken Ferry wrote:


Hi Dimitri,

The size property describes a more abstract size than pixels.  If you
set it, you're changing the DPI of the image you write out, not how
many pixels it has.

It's not safe in general to use AppKit from an app that cannot connect
to the window server – see
http://developer.apple.com/technotes/tn2005/tn2083.html#SECLIVINGDANGEROUSLY 
.

If you _can_ connect to the window server (i.e. this app isn't
running headless on some machine where you aren't logged in to
console) then you might just need to call NSApplicationLoad() in your
main method.  This function does some AppKit global setup that is
normally done in NSApplicationMain, but NSApplicationLoad returns
control to you.

That said, if you can restrict yourself to NSBitmapImageRep, that
should work without a windowserver connection.  You can draw from your
original bitmap into a new, smaller one like this:

NSBitmapImageRep *newBitmap = [[NSBitmapImageRep alloc]
initWithBitmapDataPlanes:NULL pixelsWide:pixelsWide
pixelsHigh:pixelsHigh bitsPerSample:8 samplesPerPixel:4 hasAlpha:YES
isPlanar:NO colorSpaceName:NSCalibratedRGBColorSpace
bitmapFormat:NSAlphaFirstBitmapFormat bytesPerRow:0 bitsPerPixel:32];
[NSGraphicsContext saveGraphicsState];
[NSGraphicsContext setCurrentContext:[NSGraphicsContext
graphicsContextWithBitmapImageRep:newBitmap]];
[oldBitmap drawInRect:NSMakeRect(0,0,pixelsWide,pixelsHigh)];
[NSGraphicsContext restoreGraphicsState];

and write it to png data with -[NSBitmapImageRep
representationUsingType:properties:].

Also, the technote I referenced above doesn't mention that the
CoreGraphics framework is daemon safe, which it is.

-Ken
Cocoa Frameworks

On Tue, Aug 5, 2008 at 2:44 AM, Dimitri Bouniol [EMAIL PROTECTED]  
wrote:
I have been trying relentlessly to resize a NSImage and save it as  
a png
file in a command line tool (not a windowed app, but I included  
AppKit to
get NSImage support). I tried using setScalesWhenResized along with  
setSize
to no avail (image is not resized when saved), and I also tried  
locking

focus to another image and drawing at a smaller size, but that simply
crashes with the following:

2008-08-03 20:49:40.127 imagecompressor[16757:10b] _NXCreateWindow:  
error

setting window property (1002)
2008-08-03 20:49:40.132 imagecompressor[16757:10b] _NXPlaceWindow:  
error

setting window shape (1002)
2008-08-03 20:49:40.132 imagecompressor[16757:10b]  
_NSShapePlainWindow:

error setting window shape (1002)
2008-08-03 20:49:40.144 imagecompressor[16757:10b]  
PScurrentwindowbounds:

CGSGetWindowBounds returned error (1002)
Sun Aug  3 20:49:40 imagecompressor[16757] Error:  
CGSImageDataLockDevice:

Bad device image source
Sun Aug  3 20:49:40 imagecompressor[16757] Error:  
ripc_DrawWindowContents

- Cannot acquire window image
2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** - 
[NSCachedImageRep
representationUsingType:properties:]: unrecognized selector sent to  
instance

0x116c30
2008-08-03 20:49:40.146 imagecompressor[16757:10b] *** Terminating  
app due

to uncaught exception 'NSInvalidArgumentException', reason: '***
-[NSCachedImageRep representationUsingType:properties:]: unrecognized
selector sent to instance 0x116c30'
2008-08-03 20:49:40.146 imagecompressor[16757:10b] Stack: (
  2527650123,
  2500743419,
  2527679306,
  2527672652,
  2527672850,
  11646,
  10094
)
Trace/BPT trap

I hope someone could come to my aid!


--
定魅刀利
Dimitri Bouniol
[EMAIL PROTECTED]
http://www.appkainime.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 [EMAIL PROTECTED]

Re: Using performSelector: on super

2008-08-05 Thread [EMAIL PROTECTED]



On 5 Aug 2008, at 23:38, James Bucanek wrote:

[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote  
(Tuesday, August 5, 2008 2:19 PM +0100):



Sorry for the inaccuracy.


No problem.


I of course mean that the SuperSocket class responds to the -close
method but does not declare it in its interface file. -close is  
indeed

declared as a method on a SuperSocket category defined within
SuperSocket.m

I was using performSelector: merely to keep the compiler content.
Declaring a further accessible category on SuperSocket to announce  
the

existence of -close accomplished the same thing.


Then let me make two points and one suggestion.

In your original code, you had

   SEL closeSelector = @selector(close);
   if ([SuperSocket instancesRespondToSelector:closeSelector]) {
   ...

This does not, as I think you believe, test to see if an object of  
the class SuperSocket responds to the -close message. In fact, it  
tests to see if the class object for SuperSocket responds to the  
+close message. SuperSocket is a reference to the single Class  
object defined for SuperSocket, it it not a proxy for an instance of  
the SuperSocket class.



Are you sure about that James?

The NSObject class reference for  + instancesRespondToSelector: says:


Returns a Boolean value that indicates whether instances of the  
receiver are capable of responding to a given selector.

...
To ask the class whether it, rather than its instances, can respond to  
a particular message, send to the class instead the NSObject protocol  
instance method respondsToSelector:.



The NSObject Protocol Reference for respondsToSelector: also chips in  
upon the subject:



You cannot test whether an object inherits a method from its  
superclass by sending respondsToSelector: to the object using the  
super keyword. This method will still be testing the object as a  
whole, not just the superclass’s implementation. Therefore, sending  
respondsToSelector: to super is equivalent to sending it to self.  
Instead, you must invoke the NSObject class method  
instancesRespondToSelector: directly on the object’s superclass, as  
illustrated in the following code fragment.


if ([MySuperclass instancesRespondToSelector:@selector(aMethod)]) {

[super aMethod];

}



But I have been wrong before!

To determine if an instance of an object SuperSocket responds to a  
particular method, I believe that you'd have to use SuperSocket's  
Class object reference and use class_getInstanceMethod to determine  
if it actually implements a -close method. If you wanted to find out  
if any of its superclass' implemented it, you'd have to walk of the  
chain of parent Class objects until you hit NSObject.


As for the compiler warning, that could easily be suppressed with  
(believe it or not)


   [(id)super close];  // superclass assumed to implement close

Now that really would have saved everyone a lot of typing. I often  
cast to a specific object type, casting with id never occurred to me.


If you really want your code to dynamically alter execution  
depending on whether the close method is implemented by the  
superclass, I would suggest something like


try
{
   [(id)super close];  // call superclass' -close, if implemented
   ...
}
catch
{
   if (method not implemented exception)
   // code that gets called if superclass doesn't implement -close
   ...
}
--
Exception handling might be a bit excessive here I think. If I recall  
correctly It's quite a heavyweight object in Objective-C.


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 [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's

Roland,

Right, that's because you've defined a setter. See the search
algorithm documented for mutableArrayValueForKey: at
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html#//apple_ref/doc/uid/2471-BABJFEAE.
Try removing the setter.

-Jeff

Thanks. There's always just ONE more piece of documentation to read
isn't there. So here's my (possibly) last question. If you define
neither the accessor methods nor a getter/setter and make
mutableArrayValueByKey use direct access to the variables, will that
generate KVO notifications?

My thinking was this, if you define all the accessor methods,
mutableArrayValueByKey operations will use them, and their use alone
generates KVO just as if you had called them directly. If you define a
getter/setter only, the mutable proxy will use that and although
inefficient, just using a setter method will generate a KVO notification
for the whole array. In neither of those cases does the mutable proxy
have to do anything special, it just calls a method which is already KVO
compliant. So I'd started to see mutableArrayValueByKey as just a
convenient proxy which always calls the best KVO-compliant method in
your class to do the job.

If however mutableArrayValueByKey just passes down operations to the
actual instance variable, that won't automatically generate a KVO
notification. I need to test now whether the proxy, in that case, having
no 'automatic KVO notification generating method' to call, calls the
mutator method on the variable directly and and also sends out a
notification on your behalf. I'll do that test tonight to try to
complete my mental picture.

I'd say that with the advent of @property and @synthesize, it's very
easy to make an array property with a getter/setter, find it works just
fine with an array controller, not add the indexed accessors, but not
realize that behind the scenes you are creating and destroying whole
arrays every time. Worse still, if you have other things observing those
arrays, every time you add or remove something, the notification you get
is a whole-array change, which would lead to tearing down all the
observations on the contents of the old array, and adding new observers
on the contents of the new array.

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Localize App Title?

so i got it to work, but it still show's the original CFBundleDisplayName as
the Dock label, eventhough the finder lists the CFBundleDisplayName as the
new localized name, and the CFBundleName is also localized for the NIB
file... is there some other key like CFBundleDockName ???

On Tue, Aug 5, 2008 at 8:14 AM, Jean-Daniel Dupas [EMAIL PROTECTED]wrote:


 Le 5 août 08 à 13:25, Chunk 1978 a écrit :

  i've localized the info.plist file, and added these keys to the english
 subfile:

 keyLSHasLocalizedDisplayName/key

 true/

 keyCFBundleDisplayName/key

 stringNew App Title/string


 but it still shows my original app name...


 Please read the documentation.


 http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#/
 /apple_ref/doc/uid/20001431-110725


 CFBundleDisplayName:
 […]
 Before displaying a localized name for your bundle, the Finder compares the
 value of this key against the actual name of your bundle in the file system.
 If the two names match, the Finder proceeds to display the localized name
 from the appropriate InfoPlist.strings file of your bundle. If the names do
 not match, the Finder displays the file-system name.





___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Localize App Title?

oh... you're correct... i had to logout/restart... simply relaunching the
finder wasn't cutting it for the dock's label... works now...

On Tue, Aug 5, 2008 at 8:48 PM, Rua Haszard Morris
[EMAIL PROTECTED] wrote:

Possibly just need to reboot, killall dock, do a headstand, power off for 5
seconds etc to get the dock to notice...?

On Aug 6, 2008, at 12:43 PM, Chunk 1978 wrote:

so i got it to work, but it still show's the original CFBundleDisplayName
as
the Dock label, eventhough the finder lists the CFBundleDisplayName as the
new localized name, and the CFBundleName is also localized for the NIB
file... is there some other key like CFBundleDockName ???

On Tue, Aug 5, 2008 at 8:14 AM, Jean-Daniel Dupas [EMAIL PROTECTED]
wrote:

Le 5 août 08 à 13:25, Chunk 1978 a écrit :

i've localized the info.plist file, and added these keys to the english

subfile:

keyLSHasLocalizedDisplayName/key

true/

keyCFBundleDisplayName/key

stringNew App Title/string

but it still shows my original app name...

Please read the documentation.

http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#/
/apple_ref/doc/uid/20001431-110725

CFBundleDisplayName:
[…]
Before displaying a localized name for your bundle, the Finder compares
the
value of this key against the actual name of your bundle in the file
system.
If the two names match, the Finder proceeds to display the localized name
from the appropriate InfoPlist.strings file of your bundle. If the names
do
not match, the Finder displays the file-system name.

___

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/r.haszardmorris%40adinstruments.com

This email sent to [EMAIL PROTECTED]

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: indexed accessor properties and NSArray/NSMutableArray's


On Aug 5, 2008, at 7:27 PM, Roland King wrote:

Thanks. There's always just ONE more piece of documentation to read  
isn't there. So here's my (possibly) last question. If you define  
neither the accessor methods nor a getter/setter and make  
mutableArrayValueByKey use direct access to the variables, will  
that generate KVO notifications?


Yes, assuming that there is an observer for the keypath @myArray.  
For example, calling [[myObject mutableArrayValueForKey:@myArray]  
addObject:@test] will trigger -will/ 
didChange:valueAtIndexes:forKey: notifications. The observer's - 
observeValueForKeyPath:ofObject:change:context: method will be called  
with change type NSKeyValueChangeInsertion.


-Jeff

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Bindings to display an NSArray of NSStrings as a single NSString?

2008-08-05 Thread Dustin Robert Kick


yes, indeed, that does seem to be the simplest solution, thanks.


Dustin  
KC9MEL  


On Aug 5, 2008, at 8:14 AM, Hamish Allan wrote:

On Mon, Aug 4, 2008 at 6:32 PM, Dustin Robert Kick [EMAIL PROTECTED] 
 wrote:



This seems like it would be common enough, to me, that it would have
bindings for it.


You could add a category to NSArray...

@implementation NSArray (ArrayOfStringsAsSingleString)
- (NSString *)arrayOfStringsAsSingleString { return [self
componentsJoinedByString:@, ]; }
@end

...and then bind to values.arrayOfStringsAsSingleString.

Hamish




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 [EMAIL PROTECTED]

handling idle events

2008-08-05 Thread Jim Crafton

Is there a way to handle idle time in an NSApplication? In Win32 or
Carbon, since you manually write the actual while loop that processes
the events, this is pretty easy to do. Is there anything like this in
Cocoa? I've got some objects whose state (possibly) needs to be
updated, and I was planning on handling this in the idle handler.

My other idea, if this is not possible, would be to simply have a
timer that fires off every 0.5 seconds or so.

Thanks

Jim C
___

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

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

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

This email sent to [EMAIL PROTECTED]

post events to NSApplication

2008-08-05 Thread Jim Crafton

Is it possible to create a custom event for an apps internal usage and
have it posted to the NSApp, and then processed later on? If so, how
would one do this? I'm not sure how to
a) create the event
b) get notified when the event is recv'd and ready for processing

The event loop is whatever is being run by calling [NSApp run].

Thanks

Jim C
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Bindings to display an NSArray of NSStrings as a single NSString?

2008-08-05 Thread Erik Buck


 You could add a category to NSArray...

 @implementation NSArray (ArrayOfStringsAsSingleString)
 - (NSString *)arrayOfStringsAsSingleString { return [self
 componentsJoinedByString:@, ]; }
 @end

 ...and then bind to values.arrayOfStringsAsSingleString.

Um, why not just bind to values.description  the -description method  
of NSArray will return a string containing comma separated  
descriptions of the contained objects.  It will even work if the  
contained objects aren't all strings.

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: handling idle events

2008-08-05 Thread Jonathan Hess


Hey Jim -

The typical way that I like to handle this is with these methods from  
NSRunLoop.h:


@interface NSObject (NSDelayedPerforming)
- (void)performSelector:(SEL)aSelector withObject:(id)anArgument  
afterDelay:(NSTimeInterval)delay inModes:(NSArray *)modes;
- (void)performSelector:(SEL)aSelector withObject:(id)anArgument  
afterDelay:(NSTimeInterval)delay;
+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget selector: 
(SEL)aSelector object:(id)anArgument;

#if MAC_OS_X_VERSION_10_2 = MAC_OS_X_VERSION_MAX_ALLOWED
+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget;
#endif
@end

When something about your object changes that means it needs to  
recalculate its state in the future, I would note that the object has  
become invalid, and then schedule a callback in the future to validate  
the object. I would only schedule the call back if one wasn't already  
scheduled. If I needed to validate the object state immediately, I  
would cancel the callback and do immediate validation.


This is typically better than using a 0.5 second global timer because  
it won't fire when it isn't in use. Also, is the value 0.5 really  
special? You probably want to validate your objects at the end of the  
current event loop. You can easily do this by passing a value of 0.0  
into 'afterDelay:'. The semantics for a delay of 0.0 might mean at the  
beginning of the next event loop, I'm not sure.


These after delay style messages can be easily abused and cause  
confusion in your program logic, so use them wisely.


Jon Hess

On Aug 5, 2008, at 7:16 PM, Jim Crafton wrote:


Is there a way to handle idle time in an NSApplication? In Win32 or
Carbon, since you manually write the actual while loop that processes
the events, this is pretty easy to do. Is there anything like this in
Cocoa? I've got some objects whose state (possibly) needs to be
updated, and I was planning on handling this in the idle handler.

My other idea, if this is not possible, would be to simply have a
timer that fires off every 0.5 seconds or so.

Thanks

Jim C
___

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

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

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

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Bindings to display an NSArray of NSStrings as a single NSString?

2008-08-05 Thread Jonathan Hess



On Aug 5, 2008, at 7:27 PM, Erik Buck wrote:


 You could add a category to NSArray...

 @implementation NSArray (ArrayOfStringsAsSingleString)
 - (NSString *)arrayOfStringsAsSingleString { return [self
 componentsJoinedByString:@, ]; }
 @end

 ...and then bind to values.arrayOfStringsAsSingleString.

Um, why not just bind to values.description  the -description  
method of NSArray will return a string containing comma separated  
descriptions of the contained objects.  It will even work if the  
contained objects aren't all strings.


One reason would be that the description message is for debugging and  
is free to change its output at any point. It isn't intended to be  
displayed to the user. I wouldn't want my program to start including  
ClassName: PointerValue debug info at some point because some  
engineer at a lower level than me decided to modify the description  
method for better debugging.


Jon Hess




___

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

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

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

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

How to debug a corrupted stack

2008-08-05 Thread Gerriet M. Denkmann

I have a document based app which works perfectly with -O0 or -O1 but  
crashes with -O2 or higher.


When the crash occurs the debugger comes up and says: Previous frame  
identical to this frame (corrupt stack?)


When I try to step through the function (which is kind of difficult,  
as the optimization has shuffled the lines a lot) at some time the  
top frame of the stack gets duplicated.


The faulty method starts with:
	NSString *path = @/Users/gerriet/Desktop/some alias;	//	error with  
-O2


If it starts with:
NSString *path = @/Users/gerriet/Desktop/some file; //  ok with 
-O2
then everything works perfectly.

When I comment out the place where the error seems to occur, it will  
just occur at some earlier place.


So it is kind of difficult to see where and why the stack gets  
corrupted.


Any help would be most welcome. I am completely run out of ideas and  
spent already hours with this bug.


Tiger 10.4.11, C Language Dialect C99 or GNU99, powerpc-apple-darwin8- 
gcc-4.0.1



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 [EMAIL PROTECTED]

Re: Using performSelector: on super