Re: Table View/Array Troubles
On 12-Jun-08, at 2:16 AM, Gabriel Shahbazian wrote:
Hi,
I've posted the source to an app I'm working on. If someone can take
a look and tell my why my tableview is not working with my array, it
would be of great help.
Source:
http://novisdesign.net/Labs/Alien%20Notes.zip
-Gabe
I found a couple problems in a quick look through your source:
Your NoteController init method looks like this:
- (id) init
{
[super init];
myNotes = [NSMutableArray array];
return self;
}
Calling the NSMutableArray convenience method array will return an
autoreleased object. You should do this instead:
- (id) init
{
[super init];
myNotes = [[NSMutableArray alloc] init];
return self;
}
Also, you populate your tableview by calling the title method of a
given note. Your title method looks like this:
- (NSString *) title
{
return [self title];
}
You're looking to access the title variable of the note instance, but
instead you just call the title method again. This creates a big ol'
neverending recursive call. You're wanting to do this:
- (NSString *) title
{
return title;
}
I'm also not too confident about how you're handling setting the title
and content of a note. Personally I'd use an NSMutableString for both
of those and set the content of the string when setTitle: or
setContent: is called.
-Bob Warwick
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: argument checks
#include assert.h /* ... */ NSNumber *myNum = nil; // Lots of code where you've forgotten to actually do anything with myNum assert( myNum != nil ); results = [myClass someCalculationUsing: myNum]; // lots more code to remove the assertion in the release build, compile with -DNDEBUG HTH, /jason On Jun 12, 2008, at 01:50 , Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jason.coco %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: argument checks
Yeah, variables you declare in a method (not as instance variables) are not automatically initialized to 0/NULL/nil for you. If you try to use an uninitialized variable, it might point to some left over object in memory, or it might map to nothing at all. It is totally random. What is the problem with just doing NSNumber *myNum = nil; ? You can reassign it to a usable NSNumber object later, and if you don't, checking for equality with nil (or just doing if(!myNum) ) will let you catch that error. Or am I missing something in your question Adam Leonard On Jun 11, 2008, at 10:50 PM, Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.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: Issue with displaying URI prefixes on child elements using NSXML
On 11/06/2008, at 3:19 PM, Lawrence Johnston wrote:
Hey everybody, I've got an issue that I can't figure out.
If I'm using this code:
NSString *XMLForDisplay {
NSXMLElement *root = [NSXMLNode elementWithName:@root];
[root addNamespace:[NSXMLNode namespaceWithName:@a stringValue:@http://www.tempurl.com
]];
NSXMLElement *child = [NSXMLNode elementWithName:@child URI:@http://www.tempurl.com
];
[child addChild:[NSXMLNode textWithStringValue:@myText]];
[root addChild:child];
return [root XMLStringWithOptions:NSXMLNodePrettyPrint];
}
I believe it should be outputting this text:
root xmlns:a=http://www.tempurl.com;
a:childmyText/a:child
/root
However, instead it outputs this text (note the lack of prefix on
the child):
root xmlns:a=http://www.tempurl.com;
childmyText/child
/root
This is an issue, because I need that a: prefix.
The documentation for elementWithName:URI: states it's equivalent to
URI:name/URI:name, which is exactly what I want, except that I
can't get it to display that way.
Thanks for your time.
The documentation says that you need to pass the qualified name in. So
you need to do:
NSXMLElement *child = [NSXMLNode elementWithName:@a:child URI:@http://www.tempurl.com
];
You can look-up the prefix using NSXMLElement’s
resolvePrefixForNamespaceURI: method although you probably don’t need
to do that.
- Chris
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: argument checks
NSNumber* myNum = nil; /* stuff */ NSAssert( myNum != nil, @some error message); [myClass calc:myNum]; Messages to nil are safe - it will treat your number as having a value of 0. Thus as long as you initialise it to nil, your code will run without crashing though of course may give incorrect results. If you don't initialise it to anything, it will almost certainly crash. The compiler should be warning you about this - if not, make it do so. G. On 12 Jun 2008, at 3:50 pm, Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [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: argument checks
Just a note, the NSAssert() Foundation function should only be called from inside an Objective-C method... if your code is somewhere in an Object-C class, this is fine, but if you're calling from inside a C- callback function or another C helper function (since you're creating a Library, this may be the case), and you want to use the Foundation method instead of the libc method (that I described earlier), make sure you use NSCAssert(myNum != nil, @blah blah blah); Also, to disable assertions in these cases, compile with - DNS_BLOCK_ASSERTIONS /jason On Jun 12, 2008, at 02:51 , Graham Cox wrote: NSNumber* myNum = nil; /* stuff */ NSAssert( myNum != nil, @some error message); [myClass calc:myNum]; Messages to nil are safe - it will treat your number as having a value of 0. Thus as long as you initialise it to nil, your code will run without crashing though of course may give incorrect results. If you don't initialise it to anything, it will almost certainly crash. The compiler should be warning you about this - if not, make it do so. G. On 12 Jun 2008, at 3:50 pm, Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com This email sent to [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/jason.coco %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: argument checks
On 12/06/2008, at 4:51 PM, Graham Cox wrote: NSNumber* myNum = nil; /* stuff */ NSAssert( myNum != nil, @some error message); [myClass calc:myNum]; Messages to nil are safe - it will treat your number as having a value of 0. Thus as long as you initialise it to nil, your code will run without crashing though of course may give incorrect results. If you don't initialise it to anything, it will almost certainly crash. The compiler should be warning you about this - if not, make it do so. In the original example, myNum was being passed as a argument rather than having a message to sent to it and it’s often not safe to pass nil objects as arguments. Another semi-related point is that the return value for messages to nil is something to watch out for. For example, -[NSNumber intValue] will reliably return 0 for nil objects whereas -[NSNumber longlongValue] won’t (on some architectures at least). - Chris 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]
toggleToolbarShown: How do I localize the menu item strings for non-supported languages?
When I add the recommended menu items Hide Toolbar Customize Toolbar... to my app's View menu, I can give them any text I like, but the Hide Toolbar string will be replaced by the system when the app is launched and a document window has been opened. The Action toggleToolbarShown: in NSWindow does all this automatically. This works fine for all Languages which are currently supported by Mac OS X (and installed on my Mac). But is there any simple way to provide both strings Hide Toolbar and Show Toolbar for languages which are not supported already, like Czech or Latvian? Thank you - Ulf ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Troubles with CollectionView and IKImageBrowserView
On Jun 12, 2008, at 00:25, Jens Alfke wrote:
On 11 Jun '08, at 1:14 PM, Manuel wrote:
But the IKImageBrowserView doesn't call these methods. I setup a
testmethod in the MYNSCollectionViewItem like the following code,
to verify that the imagebrowser outlet is set and to set again the
datasource:
Hm, I don't have any exact ideas, but I wonder if something's going
wrong because CollectionViewItems get copied. (The one you wire up
in the nib is a prototype, and the view makes a copy of it for every
item it needs.) Perhaps the item is getting set as the image-
browser's data source before the copy, so the instance being
displayed isn't actually the one that's the data source?
Jens is right in that copying the collection view is often a problem,
as NSView does not support the NSCopying protocol. There's some more
information on the way that NSCollectionView copies the view here:http://www.cocoadev.com/index.pl?NSCollectionView
(near the bottom).
I got it working like this:
- put your custom view initialisation in initWithCoder: (as that is
the one used to copy the original instance / unarchive your nib)
- in your view, have an IBOutlet that's connected to the
NSCollectionViewItem instance (called cvItem in my case)
- in awakeFromNib bind the properties you're interested in (as these
get restored / set correctly in the cloning process), e.g.
- (void)awakeFromNib
{
[self bind:@plotRoot toObject:cvItem
withKeyPath:@representedObject options:nil];
[self bind:@isSelected toObject:cvItem withKeyPath:@selected
options:nil];
}
This setup works fine for me (ignoring the other known bugs and
documentation deficiencies of NSCollectionView — it's slightly
disheartening when you file a bug on it, get a dup back and realise
it's been known long enough for 1094954 other bugs to be filled..).
HTH,
Daniel.___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: argument checks
On 12 Jun 2008, at 5:03 pm, Chris Suter wrote: In the original example, myNum was being passed as a argument rather than having a message to sent to it and it’s often not safe to pass nil objects as arguments. Hmmm... well, what's the function it's passed to going to do with it, other than call a method on it? If it's doing anything else, it's breaking other (much stronger) rules. If it tries to access its ivars directly, that's breaking encapsulation. If it tried to release it, that breaks memory management rules... etc. So I think in general it's quite safe to pass nil arguments where an object is expected - I certainly do it all the time, and haven't found any real problem with that so far. Contractually, nil is defined as type id, and type id can be passed for any object type, so this is not even a hack - it's entirely permitted by design. NULL on the other hand, is another story. Code that does not allow a nil argument should assert that. If it doesn't it is implicitly allowing nil, unless it is specifically documented otherwise. Can you give me a counter-example? G.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Issue with displaying URI prefixes on child elements using NSXML
It all makes sense now. Thanks.
On Jun 11, 2008, at 11:48 PM, Chris Suter wrote:
On 11/06/2008, at 3:19 PM, Lawrence Johnston wrote:
Hey everybody, I've got an issue that I can't figure out.
If I'm using this code:
NSString *XMLForDisplay {
NSXMLElement *root = [NSXMLNode elementWithName:@root];
[root addNamespace:[NSXMLNode namespaceWithName:@a stringValue:@http://www.tempurl.com
]];
NSXMLElement *child = [NSXMLNode elementWithName:@child URI:@http://www.tempurl.com
];
[child addChild:[NSXMLNode textWithStringValue:@myText]];
[root addChild:child];
return [root XMLStringWithOptions:NSXMLNodePrettyPrint];
}
I believe it should be outputting this text:
root xmlns:a=http://www.tempurl.com;
a:childmyText/a:child
/root
However, instead it outputs this text (note the lack of prefix on
the child):
root xmlns:a=http://www.tempurl.com;
childmyText/child
/root
This is an issue, because I need that a: prefix.
The documentation for elementWithName:URI: states it's equivalent
to URI:name/URI:name, which is exactly what I want, except that
I can't get it to display that way.
Thanks for your time.
The documentation says that you need to pass the qualified name in.
So you need to do:
NSXMLElement *child = [NSXMLNode elementWithName:@a:child URI:@http://www.tempurl.com
];
You can look-up the prefix using NSXMLElement’s
resolvePrefixForNamespaceURI: method although you probably don’t
need to do that.
- 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: argument checks
On 12/06/2008, at 5:29 PM, Graham Cox wrote: On 12 Jun 2008, at 5:03 pm, Chris Suter wrote: In the original example, myNum was being passed as a argument rather than having a message to sent to it and it’s often not safe to pass nil objects as arguments. Hmmm... well, what's the function it's passed to going to do with it, other than call a method on it? If it's doing anything else, it's breaking other (much stronger) rules. If it tries to access its ivars directly, that's breaking encapsulation. If it tried to release it, that breaks memory management rules... etc. So I think in general it's quite safe to pass nil arguments where an object is expected - I certainly do it all the time, and haven't found any real problem with that so far. Contractually, nil is defined as type id, and type id can be passed for any object type, so this is not even a hack - it's entirely permitted by design. NULL on the other hand, is another story. Code that does not allow a nil argument should assert that. If it doesn't it is implicitly allowing nil, unless it is specifically documented otherwise. Can you give me a counter-example? Let’s say the function your calling uses one of the following: -[NSDictionary setObject:forKey:] -[NSMutableArray addObject:] +[NSDictionary dictionaryWithObjectsAndKeys:Object1, Key1, ObjectThatIsNil, Key2, Object3, Key3, nil] The first two raise exceptions if you pass in nil. The last example probably doesn't do what you expected. I'm sure there are more examples; that’s just three and I’ve encountered all three of them. - Chris 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: launchd daemon Throttling respawn log messages
Thank you, the process needs to be running permanently, the script was just for testing. It works on both, 10.4 and 10.5 without throttling now. I had used Lingon but that doesn't create the plist the way it needed to be. Alexander On Jun 11, 2008, at 16:58 , Jens Alfke wrote: On 11 Jun '08, at 12:05 AM, Alexander Reichstadt wrote: launchd gives me a hard time with a daemon I need to keep running. It prints Throttling respawn to my console forever. Because of that I wrote a script that does nothing but print test and sleep before exiting to somehow understand why launchd does that. It looks like launchctl submit expects that the task will never quit; the man page says A simple way of submitting a program to run without a configuration file. This mechanism also tells launchd to keep the program alive in the event of failure. So if your program exits it will relaunch it; and if that happens too often, it'll start to throttle the rate at which it does that and print those warnings. If you want to use a program that runs and quits, and presumably schedule it to run at certain times, you'll need to create a property list that defines its behavior (see man 5 launch.plist). —Jens 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: Issue with displaying URI prefixes on child elements using NSXML
On Jun 12, 2008, at 12:48 AM, Chris Suter wrote: The documentation says that you need to pass the qualified name in. So you need to do: NSXMLElement *child = [NSXMLNode elementWithName:@a:child URI:@http://www.tempurl.com ]; You can look-up the prefix using NSXMLElement’s resolvePrefixForNamespaceURI: method although you probably don’t need to do that. - Chris I'm curious about what using elementWithName:URI: is supposed to do when you don't pass a qualified name in, or rather, why have it at all? The URI seems to be redundant if you are already passing the qualified name in. Just as a test (from the OP's code) NSXMLElement *root = [NSXMLNode elementWithName:@root]; [root addNamespace:[NSXMLNode namespaceWithName:@a stringValue:@http://www.tempurl.com ]]; NSXMLElement *child = [NSXMLNode elementWithName:@child URI:@http://www.tempurl.com ]; [child addChild:[NSXMLNode textWithStringValue:@myText]]; [root addChild:child]; NSXMLElement *child2 = [NSXMLNode elementWithName:@child]; [child2 addChild:[NSXMLNode textWithStringValue:@myOtherText]]; [root addChild:child2]; NSXMLElement *child3 = [NSXMLNode elementWithName:@a:child]; [child3 addChild:[NSXMLNode textWithStringValue:@something completely different]]; [root addChild:child3]; NSLog(@a:child = %@, [root elementsForName:@a:child]); gives the result: a:child = ( childmyText/child, a:childsomething completely different/a:child ) So the NSXMLElement has an internal state (that the first child is in the a namespace) that is not in it's XML representation? If you were to save it and then read it back in you would lose that information. From the few bits of XML I've dealt with I never needed to deal with namespaces, I'm just curious about this. --Nathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTextView and changing the selected text's color
On Wed, Jun 11, 2008 at 6:15 PM, Mattias Arrelid [EMAIL PROTECTED] wrote: Hi Douglas, On Wed, Jun 11, 2008 at 5:30 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 3:24 AM, Mattias Arrelid wrote: Haven't anyone stumbled upon something similar, or a solution to this? I believe it was answered. You don't want to use setMarkedTextAttributes:, because marked text is the uncommitted text you see while using an input method. You can use setSelectedTextAttributes: instead. It seems that I forgot to mention that I've tried that without success. I can successfully set the background color of the selection using this (in the initWithFrame: method of my custom text view): NSMutableDictionary *dict = [[[self selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSBackgroundColorAttributeName]; [self setSelectedTextAttributes:dict]; Now, any selected text will have a red background selection. Changing the NSBackgroundColorAttributeName attribute to NSForegroundColorAttributeName makes the selection background color the system's default again, but doesn't affect the color of the selected text. Am I missing something here? Just to test things; I did setup a simple test project, and in there it works just fine setting the foreground color. Back to the debugger to see where that call to setSelectedTextAttributes: is going. Thanks again. / Mattias ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTextView and changing the selected text's color
On Thu, Jun 12, 2008 at 11:14 AM, Mattias Arrelid [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 6:15 PM, Mattias Arrelid [EMAIL PROTECTED] wrote: Hi Douglas, On Wed, Jun 11, 2008 at 5:30 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 3:24 AM, Mattias Arrelid wrote: Haven't anyone stumbled upon something similar, or a solution to this? I believe it was answered. You don't want to use setMarkedTextAttributes:, because marked text is the uncommitted text you see while using an input method. You can use setSelectedTextAttributes: instead. It seems that I forgot to mention that I've tried that without success. I can successfully set the background color of the selection using this (in the initWithFrame: method of my custom text view): NSMutableDictionary *dict = [[[self selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSBackgroundColorAttributeName]; [self setSelectedTextAttributes:dict]; Now, any selected text will have a red background selection. Changing the NSBackgroundColorAttributeName attribute to NSForegroundColorAttributeName makes the selection background color the system's default again, but doesn't affect the color of the selected text. Am I missing something here? Just to test things; I did setup a simple test project, and in there it works just fine setting the foreground color. Back to the debugger to see where that call to setSelectedTextAttributes: is going. Sorry for my many replies... It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: NSMutableDictionary *dict = [[[textView selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSForegroundColorAttributeName]; [textView setSelectedTextAttributes:dict]; Setting the background color works fine though. I cannot see anything regarding this limitation in the documentation - is it by design or is it a bug? Best regards Mattias ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Memory not freed with CIImage
From the archives, originally posted by Rob Keniger:
I had problems with this too, and I use a workaround I found somewhere
where you render to a CGImageRef in the context of the current window.
Here's a dump of the code:
//theImage is an existing NSImage
CIImage *outputImage = [CIImage imageWithData:[theImage TIFFRepresentation]];
//to draw the image processed by Core Image, we need to draw into an
on-screen graphics context
//this works around a bug in CIImage where drawing in off-screen
graphics contexts causes a huge memory leak
//get the current window's graphics context so that we have an on-screen context
//usually we would use any view's window but generically you can just
ask for the main window
CIContext *ciContext = [[[NSApp mainWindow] graphicsContext] CIContext];
if(ciContext == nil)
{
NSLog(@The CIContext of the main window could not be accessed.
Bailing out of the image creation process.);
return;
}
CGAffineTransform transform;
transform = CGAffineTransformMakeTranslation(0.0,[outputImage
extent].size.height);
transform = CGAffineTransformScale(transform, 1.0, -1.0);
outputImage = [outputImage imageByApplyingTransform:transform];
//render the CIIimage into a CGImageRef in the on-screen context
CGImageRef cgImage = [ciContext createCGImage:outputImage
fromRect:[outputImage extent]];
// Draw the CGImageRef into the current context
if (cgImage != NULL)
{
CGContextDrawImage ([[NSGraphicsContext currentContext]
graphicsPort], [outputImage extent], cgImage);
CGImageRelease (cgImage);
}
HTH
On Thu, Jun 12, 2008 at 7:48 AM, Stefano Falda [EMAIL PROTECTED] wrote:
On 12/giu/08, at 00:34, Nick Zitzmann wrote:
It's normal for physical memory sizes to go up, and not come down until
either the program is quit or the physical memory is needed elsewhere.
Activity Monitor is not a memory leak detector. If you want to know where
the memory is going, then use Instruments instead.
Nick Zitzmann
http://www.chronosnet.com/
I've tried, but I must admit that Instruments confused me... :-(
Anyway, why the memory is marked as Active under Activity Monitor, and the
iMac performance become sluggish, while this doesn't happen when using
NSImage?
Thank you
Stefano
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/slasktrattenator%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: Memory not freed with CIImage
On 12.6.2008, at 7:48, Stefano Falda wrote: On 12/giu/08, at 00:34, Nick Zitzmann wrote: It's normal for physical memory sizes to go up, and not come down until either the program is quit or the physical memory is needed elsewhere. Activity Monitor is not a memory leak detector. If you want to know where the memory is going, then use Instruments instead. Nick Zitzmann http://www.chronosnet.com/ I've tried, but I must admit that Instruments confused me... :-( Anyway, why the memory is marked as Active under Activity Monitor, and the iMac performance become sluggish, while this doesn't happen when using NSImage? Thank you Stefano Hi, I find Instruments weird too, but there is a lot of power there. Do you know you can simply build your application and choose from menu: Run - Start with Performace Tool - Leaks? HTH Robert ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: argument checks
On 12 Jun 2008, at 5:47 pm, Chris Suter wrote: Can you give me a counter-example? Let’s say the function your calling uses one of the following: -[NSDictionary setObject:forKey:] -[NSMutableArray addObject:] Raising an exception is a good response when a nil argument isn't appropriate, but that only shows those methods are correctly dealing with that anticipated situation. Plenty of other code uses nil to mean use the default, or is harmless. +[NSDictionary dictionaryWithObjectsAndKeys:Object1, Key1, ObjectThatIsNil, Key2, Object3, Key3, nil] Actually that effect can be extremely handy. For example the userInfo dict to a notification can often be set up in order such that optional info can be nil - that terminates the list early and perfectly safely - it can save a lot of checking and other conditional code for passing different arguments via a dictionary. Of course you have to deliberately make use of this feature and I can see it could catch out the unwary. But then again, if I pass a nil object to a method that internally puts that into a dictionary like this, and a) the method didn't assert that it didn't accept nil and b) used it in such a fashion blindly and c) didn't document that nil was unacceptable, I'd call that a bug in the method, not a fault of principle. But maybe the original point is getting lost? You asserted (pardon the pun) that passing a nil argument was never acceptable - I say that it's often acceptable, provided that has been anticipated correctly in the design of the method that receives the argument, therefore one should design methods with this possibility in mind - either by rejecting nil, documenting that it's not OK, or working correctly anyway. Theory and practice don't always coincide though, I'll be the first to admit that. G.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: argument checks
On 2008 Jun, 12, at 0:47, Chris Suter wrote: On 12/06/2008, at 5:29 PM, Graham Cox wrote: ... implicitly allowing nil, unless it is specifically documented otherwise. Can you give me a counter-example? -[NSDictionary setObject:forKey:] -[NSMutableArray addObject:] [These] raise exceptions if you pass in nil. However, these results are now documented! I believe they were not documented a couple years ago. I and probably many others filed bugs on this. But I've noticed must not be nil comments appearing in Apple documentation over the last couple years. So, I would say that Graham is correct about the requirement for documentation, although probably there still may be omissions (bugs) in older Apple docs. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
FSEvent- FSEventStreamEventFlags
Hi All,
I want to know how we can get the file close event using
FSEventStreamEventFlags.
I have written the code for get the event when user write, open and
close the file. But we are not able to distinguish between which event
is for which purpose.
Shown below is the out put of function call --
FSEventStreamShow(streamRef);
FSEventStreamRef @ 0x101f10:
allocator = 0xa01ea1a0
callback = 0x1c20
context = {0, 0x2034, 0x0, 0x0, 0x0}
numPathsToWatch = 1
pathsToWatch = 0xa01ea1a0
pathsToWatch[0] = '/private/tmp'
latestEventId = 49124
latency = 100 (microseconds)
flags = 0x
in this always flags is NULL for all event in that directory specified,
only the latestEventId changes for every event.
So how can i find out whether file was opened, closed or write
operation was performed on the file.
Here is the code snippet for creating stream.
FSEventStreamCreate(kCFAllocatorDefault,
mycallback,
context,
pathsToWatch,
kFSEventStreamEventIdSinceNow,
latency,
kFSEventStreamCreateFlagNone /* Flags explained in reference */
);
where as pathsToWatch=/tmp/,
latency=3.0,
mycallback=is the callback function.
Is something i am missing
Please suggest.
Thanks,
Santosh
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Prevent Asynchronous operation of beginSheetModalForWindow
Hi John, I hope you don't mind me cc'ing this to the list - I think it might be helpful to others (if not, my apologies for the noise). On 12 Jun 2008, at 9:43 pm, John Love wrote: Hi, Graham ... Graham, this is a condensed summary of my initial communication: Call it my fetish or whatever, but I strongly believe in compartmentalization, i.e., having a separate SheetController to do sheet stuff. I'd say that was entirely reasonable. For this purpose I have made SheetController*theSheet an outlet of a FileController*theFile and theFile is an outlet of my main nib's File's Owner. Another outlet of File's Owner is my mainWindow. In MyDocument.m -awakeFromNib, I pass mainWindow to one of FileController's methods to initialize some stuff pertaining to mainWindow, including the most important setting of FileController's NSWindow *itsWindow, an instance variable. Well, without being aware of the details, I can't be sure this is wrong or right - but I have to say, it smells. One strong principle of OOP design is that objects are responsible as far as possible for themselves and themselves alone. If you need to pass one object to another to put the first object into a useful state, that seems to be violating this principle. However, there are always exceptions and this may be one of them, hence my reluctance to say that it's definitely wrong. Normally to control a window you use NSWindowController (or subclass of it) which already has a 'window' outlet, so there's no reason to have an 'itsWindow' outlet of your own. If another object needs the window (why?) then it should ask the window controller for it rather than keeping its own reference: [controller window]; Sometimes, I kinda have the feeling that the MVC implies one controller controls everything is the ideal. Hmmm, not really. As many controllers as needed to make the design elegant and straightforward, but no more, would be my view. As simple as possible but no simpler. Even though I am far from the end of my program's development, right now I have a total of 7 controllers, including the two already mentioned. I also have a StatusController*theStatus which writes to a NSTextField of my main window. The remaining 4 don't do very much right now. Down the road I could conceivably shrink the 7 to 5 or whatever, but not much beyond that. Before I continue, I would appreciate some feedback on this philosophy. Considering my previous AppleScript Studio experience, I never had this philosophical problem; but now I do. My approach has fallen into a common pattern, which I've grown comfortable with, and which I believe to be correct. Basically, one interface = one controller. This is strongly suggested by NSWindowController, which has an outlet for exactly one window. By interface I mean a single complete window or dialog box, where that is self-contained. If the dialog is complex and has multiple switchable views I might consider a separate controller for each one, though in practice I don't think I've ever done that - I've just put all the code for the entire dialog in one controller. Let's suppose I have a document that owns a single main window controller - this is very typical in the document-based interface - but also has a number of additional dialog boxes that are needed to get certain operations done. The document is the nib's File's Owner, so it has outlets to each controller for each dialog box. Each controller in turn has outlets (and actions) for each individual widget/control in the dialog interface. What is a dialog for? It's to get information from the user in order to complete some task. The document is not interested in how that information is obtained specifically, it only knows it needs it. So the document asks the relevant controller go get me this information I need from the user. The dialog's controller in turn puts up the dialog, handles all the interaction with the user, removes the window when the user is done, packages up the information in a form useful to its client, and returns it. Everyone's happy - the document got its info, the dialog controller didn't have to care about who wanted the info or what was done with it, and the connections between the objects were kept to a minimum, with few dependencies. Now whether the dialog is modal, modeless, a sheet, or whatever, is irrelevant. The controller for that dialog can probably make that decision (it may need to be given supplementary information, such as the parent window, but that can be designed into its interface with its client code - and it is also free to ignore it, so typically my dialog controllers take a parent window argument regardless, even if I end up ignoring it and displaying the dialog modally - the client (document) doesn't care either way). However, because the dialog may be modeless (or asynchronous, if you
Re: NSTextView and changing the selected text's color
Definitely sounds like a bug - file it anyway, they can only say behaves as expected (and probably will... ;-) I would expect that if I set my foreground text to some pale colour, I could set a different colour for selected text so it has contrast with the background selection colour, not just work for black text. G. On 12 Jun 2008, at 7:47 pm, Mattias Arrelid wrote: Sorry for my many replies... It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: NSMutableDictionary *dict = [[[textView selectedTextAttributes] mutableCopy] autorelease]; [dict setObject:[NSColor redColor] forKey:NSForegroundColorAttributeName]; [textView setSelectedTextAttributes:dict]; Setting the background color works fine though. I cannot see anything regarding this limitation in the documentation - is it by design or is it a bug? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: argument checks
On Thu, Jun 12, 2008 at 6:50 AM, Ashley Perrien [EMAIL PROTECTED] wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; I'd recommend not declaring myNum until you are ready to define it. Making all your declarations upfront is a hangover from when compilers weren't so clever; thankfully, GCC facilitates a more useful locality of reference. Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: FSEvent- FSEventStreamEventFlags
On 12 Jun '08, at 5:57 AM, santoshb wrote: I want to know how we can get the file close event using FSEventStreamEventFlags. I have written the code for get the event when user write, open and close the file. But we are not able to distinguish between which event is for which purpose. You can't. The FSEvents API only tells you what _directories_ have been changed, and only sometime after the changes happen. It doesn't tell you about individual changes, or even what files changed, much less individual open/write/close calls. (The reason is that doing so doesn't scale — the system would choke under the burden of delivering so many notifications.) Did you read the File System Events Programming Guide? Its overview section says: When your application registers for notification, the file system events daemon will post a notification every time that any file in the monitored directory hierarchy changes. It will also post a notification if the directory itself is modified (for example, if its permissions change or a new file is added). The important point to take away is that the granularity of notifications is at a directory level. It tells you only that something in the directory has changed, but does not tell you what changed. —Jens 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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
In general, you should not treat NSController-derived classes as holders of data. They are specifically for binding to. Since the shapeTreeController gets its content by binding to something else, why don't you just directly access that something instead of trying to go through the controller? In other words, access your model, not your controller. The controller's content is an NSMutableArray in the document and the nodes are CD entities with parent and children relationships. However I also need the selection (which persists per-document) and the only place I can get that from is the controller. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
I'm not sure what you mean by shadow-object problem. I'm referring to the 'brick' object returned by the tree controller in 10.4 which required hacks via a category and the private 'observedObject' function. In Leopard, [treeController arrangedObjects] returns a proxy object (the same way that NSArrayController does for its arrangedObjects method). The proxy object currently isn't a subclass of NSTreeNode. Feel free to pile on bugs for that one too. BUT, the treeController's arrangedObjects proxy DOES respond to two NSTreeNode methods - - childNodes - descendantNodeForIndexPath (I'm typing these from memory, so please check these with the .h) Incidentally, I believe the documentation is wrong about this. The header is right. NOW, you can iterate over the tree yourself, going from childNode to childNode getting valueForKeyPath@:representedObject.name. I tried that, as described (in IB with a keypath) and got the same error. I'm not sure I understand what you want to end up with. You have a treecontroller in each document and want only the frontmost document's treecontroller to drive an app global outline view? You should be able to rebind the outlineview when the frontmost document changes. Yes that's exactly what I'm trying to do :) Why can't you put the view and the controller in the same nib? Because that's what Cocoa is forcing me to do (and the reason I suspect that single-window apps are increasingly common) but that's no good for the design of my application. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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]
Authentication and NSURLConnection sendSynchronousRequest
I¹m writing a simple demo application showing how to use some Exchange Web
Services (EWS) features in Cocoa. I am a total Cocoa n00b but have most of
the app and UI working, thanks to a lot of google-fu and my now-worn copy of
Hillegas' 3rd ed. I¹m having trouble authenticating to the actual EWS
server, though.
For simplicity¹s sake, I want to use sendSynchronousRequest. The docs say
that it has OEminimal support¹ for authentication. I¹m letting the user
provide their credentials, then storing them in an NSURLCredential. I then
add the NSURLCredential to the shared credential storage and define an
NSURLProtectionSpace with the FQDN of the EWS server.
When I actually call sendSynchronousRequest, I get an error if the EWS
server is using a self-signed certificate (as most probably will be). I did
some digging and it looks like one way to fix this is to override
allowsAnyHTTPSCertificateForHost so that it allows any certificate. I know
this is a bad idea from a security standpoint, but I'm OK with it in demo
code, suitably flagged. However, I'm doing something wrong when I override.
If I just stick this code
@implementation NSURLRequest(NSHTTPURLRequest)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
@end
At the end of one of my .m files, the code builds, though I get warnings
that some other methods aren't implemented. The program then gives me an
NSURLDomainError -1203, the description for which doesn't tell me anything
useful.
So, the actual questions:
1. Is there a safer or better-supported way for me to get a look at the
returned certificate besides overriding allowsAnyHTTPSCertificateForHost?
2. What am I doing wrong in my override attempt?
3. What does -1203 really *mean*?
Cheers,
-Paul
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
That's what I used to think, too, until someone on this list pointed out to me that this snippet is in the header for NSTreeController: // proxy for the root tree node responds to -childNodes and -descendantNodeAtIndexPath:(NSIndexPath *)indexPath - (id)arrangedObjects; So whereas prior to 10.5 this method returned an opaque root node, in Leopard you at least are promised that it will respond to -childNodes and -descendantNodeAtIndexPath:. So the object is single-level tree where each leaf is the actual item selected? What I don't understand is why the same binding returns a different object in two cases? Why don't get this proxy object when I bind the view directly to the controller? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTextView and changing the selected text's color
On Jun 12, 2008, at 2:47 AM, Mattias Arrelid wrote: It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: File a bug and we'll look into it. Douglas Davidson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 prevent sleep mode when app is running
Hi, When the computer goes into sleep mode my app also seems to be taking forever in doing the current task. So how can I prevent the computer from going into sleep mode when my app is running? Wishes, Nick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
On Thu, Jun 12, 2008 at 4:35 PM, Danny Price [EMAIL PROTECTED] wrote: What I don't understand is why the same binding returns a different object in two cases? Why don't get this proxy object when I bind the view directly to the controller? Good question. I would guess that not everything in the key path is KVC-compliant. For example, when the main window changes, do you receive KVO notifications to that effect from NSApp? Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSTextView and changing the selected text's color
On Thu, Jun 12, 2008 at 5:40 PM, Douglas Davidson [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:47 AM, Mattias Arrelid wrote: It turns out that if you set the NSForegroundColorAttributeName of the attributed string in NSTextView's text storage, the call to setSelectedTextAttributes: doesn't have any effect when called as described below: File a bug and we'll look into it. A bug has been filed: rdar://problem/6003324 Regards Mattias ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: how to prevent sleep mode when app is running
Look into UpdateSystemActivity(). It's in the CoreServices framework. If you call it with UsrActivity every 25 seconds or so, the display won't dim and the computer won't go to sleep (unless it's forced to. You can't prevent that). What is your app doing that you want to resort to something as drastic as preventing sleep? Someone might be able to suggest a better solution to your problem if you give more details. Hank On Jun 12, 2008, at 8:27 AM, Nick Rogers wrote: Hi, When the computer goes into sleep mode my app also seems to be taking forever in doing the current task. So how can I prevent the computer from going into sleep mode when my app is running? Wishes, Nick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hank.list %40runbox.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: Authentication and NSURLConnection sendSynchronousRequest
On 12 Jun '08, at 8:35 AM, Paul E. Robichaux wrote:
@implementation NSURLRequest(NSHTTPURLRequest)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
@end
At the end of one of my .m files, the code builds, though I get
warnings
that some other methods aren't implemented. The program then gives
me an
NSURLDomainError -1203
I'm suspicious of that technique, since category methods really aren't
allowed to override existing methods; I think the effects are
undefined. It's the kind of thing that I could imagine breaking
under the rewritten Obj-C runtime in 10.5.
1. Is there a safer or better-supported way for me to get a look at
the
returned certificate besides overriding
allowsAnyHTTPSCertificateForHost?
Well, this message from Marcel Borsten
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/4/200382
mentions another method:
+ (void)setAllowsAnyHTTPSCertificate:(BOOL)fp8 forHost:(id)fp12;
So it looks as though you could just call
[NSURLConnection setAllowsAnyHTTPSCertificate: YES forHost: myHost];
You would just have to paste the @interface block (but NOT the
@implementation) from that email into your code, so the compiler
recognizes the existence of that method.
A better solution is to insert the cert into the keychain and mark it
as trusted; but that isn't easy. If the user can get a .cer file of
the server's cert, s/he can double-click it to add it to the keychain,
then locate it in Keychain Access and mark it as trusted.
Programmatically, it involves some twisty little APIs; I'd recommend
using the higher-level wrappers in the open-source Keychain.framework
(it's on sourceforge.)
3. What does -1203 really *mean*?
From NSURLError.h:
NSURLErrorServerCertificateHasUnknownRoot = -1203,
—Jens
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: Cocoa-dev Digest, Vol 5, Issue 1040
In the original example, myNum was being passed as a argument rather than having a message to sent to it and its often not safe to pass nil objects as arguments. Hmmm... well, what's the function it's passed to going to do with it, other than call a method on it? If it's doing anything else, it's breaking other (much stronger) rules. Okay, so question 2: what else could be done other than calling methods on it? I'm using NSNumbers in place of ints, floats and so on partly as a learning exercise and partly to make it easier to convert the number types rather than casting them. The library I had put together (which was just an object with no instance variables) originally used all floats (it's a math heavy library). Ashley___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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]
Accessors Question
Lately, I've started to see accessors of the following sort:
- (NSString *)foo
{
return [[foo retain] autorelease];
}
rather than just
- (NSString *)foo
{
return foo;
}
What is the purpose or benefit of doing this? It seems to me that this
would add things unnecessarily to the autorelease pool, and I can't
see a benefit to be had. I've seen it in places that make me think
there must be a reason (e.g. sample code from Apple), so I'm guessing
I'm missing something. Is there some benefit due to GC? If so, should
this construct be used without GC or only with?
Thanks,
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]
Simple question - Subclassing NSView
Hi,
I have recently started programming on Mac using Objective-C and Cocoa. I am
coming from C++/C# world. So, its a fairly basic question. Please help me
understand the following code:
@implementation MyView /*MyView inherits from NSView */
-(void)drawRect: (NSRect)aRect {
[[NSColor blackColor] set];
NSRectFill( [self bounds] );
}
In first line, I was expecting something like [self setColor:[NSColor
blackColor]]; (similar to this.color = NSColor.blackColor; in C#/C++)
how NSColor object knows about where to set the color?
In second line, NSRectFill(), I was expecting it to be called using square
bracket [] notation. Again how this function knows where to fill the rectangle?
There is no reference of NSView passed into the function?
Lastly what are the rules of using () verses []?
Thanks in advance for your time!
-Vks
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Accessors Question
Le 12 juin 08 à 19:21, Jeff LaMarche a écrit :
Lately, I've started to see accessors of the following sort:
- (NSString *)foo
{
return [[foo retain] autorelease];
}
rather than just
- (NSString *)foo
{
return foo;
}
What is the purpose or benefit of doing this? It seems to me that
this would add things unnecessarily to the autorelease pool, and I
can't see a benefit to be had. I've seen it in places that make me
think there must be a reason (e.g. sample code from Apple), so I'm
guessing I'm missing something. Is there some benefit due to GC? If
so, should this construct be used without GC or only with?
Thanks,
Jeff
I think the purpose is describe in the writing accessor guide :
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAccessorMethods.html
As with values manufactured by class convenience methods, the
returned object is autoreleased in the current scope and thus remains
valid if the property value is changed.”
This is mainly to prevent this kind of issue:
NSString *foo = [myObject foo];
[myObject setFoo:nil]; // setter release the foo ivar = foo is no
longer pointing on a valid memory location.
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: Simple question - Subclassing NSView
On Jun 12, 2008, at 10:26 AM, Vikas wrote:
I have recently started programming on Mac using Objective-C and
Cocoa. I am coming from C++/C# world. So, its a fairly basic
question. Please help me understand the following code:
@implementation MyView /*MyView inherits from NSView */
-(void)drawRect: (NSRect)aRect {
[[NSColor blackColor] set];
NSRectFill( [self bounds] );
}
In first line, I was expecting something like [self setColor:
[NSColor blackColor]]; (similar to this.color =
NSColor.blackColor; in C#/C++)
how NSColor object knows about where to set the color?
In second line, NSRectFill(), I was expecting it to be called using
square bracket [] notation. Again how this function knows where to
fill the rectangle? There is no reference of NSView passed into the
function?
Well, as the docs state, Sets the color of subsequent drawing to the
color that the receiver represents. So, it sets that as the current
drawing color in the current graphics context, and whatever gets
subsequently drawn in that context will be done in that color.
Lastly what are the rules of using () verses []?
() follows same rules as C; you use [] when sending messages to
Objective-C objects and classes.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Accessors Question
On Jun 12, 2008, at 1:21 PM, Jeff LaMarche wrote:
Lately, I've started to see accessors of the following sort:
- (NSString *)foo
{
return [[foo retain] autorelease];
}
I believe this is in case of something like this:
NSString *myFoo = [myObject foo];
// ... stuff that causes myObject to be deallocated ...
NSLog(@%@, myFoo); // --- myFoo might be invalid
I definitely saw this pattern mentioned before GC, so it doesn't have
to do with that.
--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: Simple question - Subclassing NSView
Hi Vikas,
On Thu, Jun 12, 2008 at 6:26 PM, Vikas [EMAIL PROTECTED] wrote:
I have recently started programming on Mac using Objective-C and Cocoa. I am
coming from C++/C# world. So, its a fairly basic question. Please help me
understand the following code:
@implementation MyView /*MyView inherits from NSView */
-(void)drawRect: (NSRect)aRect {
[[NSColor blackColor] set];
NSRectFill( [self bounds] );
}
In first line, I was expecting something like [self setColor:[NSColor
blackColor]]; (similar to this.color = NSColor.blackColor; in C#/C++)
how NSColor object knows about where to set the color?
It's not setting the color of the NSView, it's setting the color of
the pen used by subsequent drawing operations such as NSRectFill().
In second line, NSRectFill(), I was expecting it to be called using square
bracket [] notation. Again how this function knows where to fill the
rectangle? There is no reference of NSView passed into the function?
The NSView reference is self, as the code is implementing a method
of an NSView subclass. NSRectFill is a C function, not an Objective-C
method; you can mix C and Objective-C freely in a .m file.
Lastly what are the rules of using () verses []?
If you want to call a plain C function, use the function name plus
parentheses just as you would in a plain C program. If you want to
call a method on an object, use the square bracket notation [objName
methodSelector].
Hamish
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Authentication and NSURLConnection sendSynchronousRequest
On 6/12/08 12:44 PM, Jens Alfke [EMAIL PROTECTED] wrote:
On 12 Jun '08, at 8:35 AM, Paul E. Robichaux wrote:
@implementation NSURLRequest(NSHTTPURLRequest)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
@end
At the end of one of my .m files, the code builds, though I get
warnings
that some other methods aren't implemented. The program then gives
me an
NSURLDomainError -1203
I'm suspicious of that technique, since category methods really aren't
allowed to override existing methods; I think the effects are
undefined. It's the kind of thing that I could imagine breaking
under the rewritten Obj-C runtime in 10.5.
Calling it a technique is being very generous :) I was suspicious of it as
well. I'm still at the try-things-without-knowing-what-they-actually-do
stage of my Cocoa career, so I decided to give it a whirl.
1. Is there a safer or better-supported way for me to get a look at
the
returned certificate besides overriding
allowsAnyHTTPSCertificateForHost?
Well, this message from Marcel Borsten
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/4/200382
mentions another method:
+ (void)setAllowsAnyHTTPSCertificate:(BOOL)fp8 forHost:(id)fp12;
So it looks as though you could just call
[NSURLConnection setAllowsAnyHTTPSCertificate: YES forHost: myHost];
After doing that, I now get a compiler warning that there's a duplicate
interface defined for NSURLRequest(NSHTTPURLRequest), and at runtime when I
call the routine I get errors in my log:
+[NSURLConnection setAllowsAnyHTTPSCertificate:forHost:]: unrecognized
selector sent to class 0xa02645a0
A better solution is to insert the cert into the keychain and mark it
as trusted; but that isn't easy. If the user can get a .cer file of
the server's cert, s/he can double-click it to add it to the keychain,
then locate it in Keychain Access and mark it as trusted.
Programmatically, it involves some twisty little APIs; I'd recommend
using the higher-level wrappers in the open-source Keychain.framework
(it's on sourceforge.)
For the purpose of this sample, this approach is overkill. You're right,
though, that this would be a much better solution.
3. What does -1203 really *mean*?
From NSURLError.h:
NSURLErrorServerCertificateHasUnknownRoot = -1203,
Aha! Thanks for the pointer.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Accessors Question
On Jun 12, 2008, at 10:21 AM, Jeff LaMarche wrote:
Lately, I've started to see accessors of the following sort:
- (NSString *)foo
{
return [[foo retain] autorelease];
}
rather than just
- (NSString *)foo
{
return foo;
}
What is the purpose or benefit of doing this? It seems to me that
this would add things unnecessarily to the autorelease pool, and I
can't see a benefit to be had. I've seen it in places that make me
think there must be a reason (e.g. sample code from Apple), so I'm
guessing I'm missing something. Is there some benefit due to GC? If
so, should this construct be used without GC or only with?
Assuming there is a -setFoo: that is implemented as retain-new /
release-old, as is typical...
Consider:
id b = [something foo];
[something setFoo: @bar];
[b length];
The above will crash in the non retain/autorelease case, but not
otherwise.
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: Simple question - Subclassing NSView
I have recently started programming on Mac using Objective-C and Cocoa. I am coming from C++/C# world. Recant, heretic! ;-) In first line, I was expecting something like [self setColor:[NSColor blackColor]]; (similar to this.color = NSColor.blackColor; in C#/C++) how NSColor object knows about where to set the color? In all seriousness, you'll need to read the Cocoa Drawing Guide. The answer to this quesiton is found there. NSColor's -set method tells the current drawing context to use that color as the current drawing color. All drawing actions will happen with that color because it's set as the current color. In second line, NSRectFill(), I was expecting it to be called using square bracket [] notation. Again how this function knows where to fill the rectangle? There is no reference of NSView passed into the function? Using brackets means you're sending an object a message: [someObject message]; As you might guess, NSRectFill() is a standard c function. Obviously, the signature gives you a good clue. Again, this applies to the current graphics context (which knows what view currently has focus, and therefore its bounds). -- 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: Accessors Question
On Jun 12, 2008, at 1:31 PM, Jean-Daniel Dupas wrote: This is mainly to prevent this kind of issue: NSString *foo = [myObject foo]; [myObject setFoo:nil]; // setter release the foo ivar = foo is no longer pointing on a valid memory location. I hadn't thought of this case. Thanks for the pointer to the docs -- I now see there is a vulnerability in the accessors I've been writing. --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: Simple question - Subclassing NSView
O'kay, that was helpful.
I still have one doubt. The declaration of NSRectFill is as below:
void NSRectFill (
NSRect aRect
);
NSRectFill() is a C function, not part of any class e.g. NSView. aRect is
simply a struct which specify location points (doesnt contain reference of any
window). How the function knows about the drawing surface, in which
window/surface to paint? Does it implicitly make use of some self pointer? If
so, then, what if this function is not called from inside a simple C function
then there will not be any self pointer?
Thank You,
-Vks
Hamish Allan [EMAIL PROTECTED] wrote:
Hi Vikas,
On Thu, Jun 12, 2008 at 6:26 PM, Vikas wrote:
I have recently started programming on Mac using Objective-C and Cocoa. I am
coming from C++/C# world. So, its a fairly basic question. Please help me
understand the following code:
@implementation MyView /*MyView inherits from NSView */
-(void)drawRect: (NSRect)aRect {
[[NSColor blackColor] set];
NSRectFill( [self bounds] );
}
In first line, I was expecting something like [self setColor:[NSColor
blackColor]]; (similar to this.color = NSColor.blackColor; in C#/C++)
how NSColor object knows about where to set the color?
It's not setting the color of the NSView, it's setting the color of
the pen used by subsequent drawing operations such as NSRectFill().
In second line, NSRectFill(), I was expecting it to be called using square
bracket [] notation. Again how this function knows where to fill the
rectangle? There is no reference of NSView passed into the function?
The NSView reference is self, as the code is implementing a method
of an NSView subclass. NSRectFill is a C function, not an Objective-C
method; you can mix C and Objective-C freely in a .m file.
Lastly what are the rules of using () verses []?
If you want to call a plain C function, use the function name plus
parentheses just as you would in a plain C program. If you want to
call a method on an object, use the square bracket notation [objName
methodSelector].
Hamish
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Simple question - Subclassing NSView
On Thu, Jun 12, 2008 at 6:54 PM, Vikas [EMAIL PROTECTED] wrote: NSRectFill() is a C function, not part of any class e.g. NSView. aRect is simply a struct which specify location points (doesnt contain reference of any window). How the function knows about the drawing surface, in which window/surface to paint? Does it implicitly make use of some self pointer? If so, then, what if this function is not called from inside a simple C function then there will not be any self pointer? This question is answered in some of the other posts answering your original question, so hopefully it will now be clear. Essentially, by the time your overridden version of -[NSView drawRect:] is called, the drawing subsystem which NSRectFill() uses already knows that your NSView is the target of the drawing operation. Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Authentication and NSURLConnection sendSynchronousRequest
On 12 Jun '08, at 10:35 AM, Paul E. Robichaux wrote: After doing that, I now get a compiler warning that there's a duplicate interface defined for NSURLRequest(NSHTTPURLRequest), You can get around that by changing the category name (the part in parentheses) to anything different. and at runtime when I call the routine I get errors in my log: +[NSURLConnection setAllowsAnyHTTPSCertificate:forHost:]: unrecognized selector sent to class 0xa02645a0 Hm, that means that method isn't actually implemented in NSURLConnection. I guess it's left for subclasses to implement. In that case, try creating a subclass of NSURLConnection, containing nothing but the +allowsAny... method you used to have, and then call +sendSynchronousRequest:... on the subclass. —Jens 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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
On Jun 12, 2008, at 08:35, Danny Price wrote: So the object is single-level tree where each leaf is the actual item selected? What I don't understand is why the same binding returns a different object in two cases? Why don't get this proxy object when I bind the view directly to the controller? It looks like you're assuming that a binding involves two objects and a keypath. In fact, a binding involves two objects and *two* keypaths. The documentation for the NSKeyValueBindingCreation protocol says: bind:toObject:withKeyPath:options: Establishes a binding between a given property of the receiver and the property of a given object specified by a given key path. - (void)bind:(NSString *)binding toObject:(id)observableController withKeyPath:(NSString *)keyPath options:(NSDictionary*)options Parameters binding The key path for a property of the receiver previously exposed using the exposeBinding: method. observableController The bound-to object. keyPath A key path to a property reachable from observableController. In your case, the two keypaths are arrangedObjects and name. It is not correct (in general) to expect to be able to jam them together into a single keypath and get the same result (or any result, as you saw). That's why there are two keypath fields to fill in when you set up the binding in IB. Confusingly, IB's display of the binding (e.g. controller.arrangedObjects.name) is a shorthand description meaningful for display purposes only. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Simple question - Subclassing NSView
NSRectFill() is a C function, not part of any class e.g. NSView. aRect is simply a struct which specify location points (doesnt contain reference of any window). How the function knows about the drawing surface, in which window/surface to paint? Does it implicitly make use of some self pointer? If so, then, what if this function is not called from inside a simple C function then there will not be any self pointer? Did you read my previous message? 1) Read the Cocoa Drawing Guide. 2) The current graphics context knows which view currently has 'focus' (see the drawing guide) so it knows what view and rectangle you're describing. -- 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: Simple question - Subclassing NSView
On Thu, Jun 12, 2008 at 1:54 PM, Vikas [EMAIL PROTECTED] wrote: NSRectFill() is a C function, not part of any class e.g. NSView. aRect is simply a struct which specify location points (doesnt contain reference of any window). How the function knows about the drawing surface, in which window/surface to paint? Does it implicitly make use of some self pointer? If so, then, what if this function is not called from inside a simple C function then there will not be any self pointer? Please read the Cocoa Drawing Guide and think about +[NSGraphicsContext currentContext]. --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: Simple question - Subclassing NSView
On 12 Jun 2008, at 10:54, Vikas wrote: O'kay, that was helpful. I still have one doubt. The declaration of NSRectFill is as below: void NSRectFill ( NSRect aRect ); NSRectFill() is a C function, not part of any class e.g. NSView. aRect is simply a struct which specify location points (doesnt contain reference of any window). How the function knows about the drawing surface, in which window/surface to paint? Does it implicitly make use of some self pointer? If so, then, what if this function is not called from inside a simple C function then there will not be any self pointer? Thank You, -Vks As with all Cocoa-based drawing, code knows where it is being drawn from [NSGraphicsContext currentGraphicsContext]. self is not involved in any way at all. The point is that you as a developer do not have to worry about this, all the built-in functions etc. handle it for you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Simple question - Subclassing NSView
On 12 Jun '08, at 10:54 AM, Vikas wrote: How the function knows about the drawing surface, in which window/ surface to paint? There's always a current graphics context; it's global to each thread. (See NSGraphicsContext if you want to look at its API; but if you're looking for the low-level drawing primitives, they're defined in the CoreGraphics framework as CGContext functions. AppKit's drawing code is all wrappers around those.) So basically, any code that wants to draw or alter the drawing state calls [NSGraphicsContext currentContext] to get the current context. This is different than, say, Java, where the graphics context is associated with each view/component. Graphics contexts turn out to be expensive objects, and AppKit just uses one, and adjusts its state depending on what needs to be drawn. Mostly you don't need to worry about this. When a view's -drawReect: method is called, the graphics context has already been set up for drawing into that view. —Jens 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: Authentication and NSURLConnection sendSynchronousRequest
On 6/12/08 2:18 PM, Jens Alfke [EMAIL PROTECTED] wrote: On 12 Jun '08, at 10:35 AM, Paul E. Robichaux wrote: After doing that, I now get a compiler warning that there's a duplicate interface defined for NSURLRequest(NSHTTPURLRequest), You can get around that by changing the category name (the part in parentheses) to anything different. So *that's* what that's for. Thanks! and at runtime when I call the routine I get errors in my log: +[NSURLConnection setAllowsAnyHTTPSCertificate:forHost:]: unrecognized selector sent to class 0xa02645a0 Hm, that means that method isn't actually implemented in NSURLConnection. A little further digging revealed http://www.cocoabuilder.com/archive/message/cocoa/2007/5/19/183405, which claims that the method's implemented on NSURLRequest. Sure enough, when I define it there, my app is now failing with NSURLErrorUserCancelledAuthentication, which is a step in the right direction :) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Accessors Question
Hello,
Although I prefer the safer accessors, there has been one case where I
had no choice but to return the main object pointer:
- (NSString *)foo
{
return foo;
}
In my app I had a method that was populating a custom cell with a few
elements. Depending on the data source, I had to construct the strings
in different ways. Since this string had to be constructed with up to
5 elements, when the table view had many rows, performance suffered
greatly during sort and memory consumption spiked tremendously due to
a barrage of newly allocated objects.
I ended up writing something like:
// Private version used only for performance
- (NSString *)_foo
{
return foo;
}
// Safer version used in all other cases
- (NSString *)foo
{
return [[foo retain] autorelease];
}
By using '_foo' during sorting I increased speed noticeably, while
reducing the memory footprint.
-- Tito
On 12 Jun 2008, at 11:27 AM, Jens Alfke wrote:
On 12 Jun '08, at 10:41 AM, Andy Lee wrote:
I hadn't thought of this case.
Thanks for the pointer to the docs -- I now see there is a
vulnerability in the accessors I've been writing.
This is kind of a religious issue. Some people like the safer
accessors. Some people see them as a very expensive* workaround for
a problem that rarely occurs.
I'm firmly in the latter camp. I've never used this 'safe' form of
accessor, and have only rarely run into the kind of crash it
prevents; and it was always pretty easy to track down and fix. (The
fix is just for the caller to retain the value it got from the
accessor, then release it when it's done using it.)
Another alternative is to leave the getters simple, but change the
_setter_ methods to autorelease the old value instead of releasing
it; that prevents this same crash, but is less expensive because
setters are much more rarely called than getters (and -autorelease
isn't much more expensive than -release.)
—Jens
* A basic accessor requires one or two machine instructions to do
the actual work; whereas -retain and -autorelease involve extra
method dispatches that each acquire a global lock and do a hashtable
lookup. Obviously any one call isn't going to take a noticeable
amount of time, but accessor calls are so damn ubiquitous that this
can have an overall impact on app performance in some cases. Not to
mention memory usage, since autoreleased objects have a longer
lifespan and can build up during
loops.___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.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: Accessors Question
Out of curiosity, does anyone know what the synthesized accessors look
like when you specify retain? Are they
The safe or unsafe ones?
Sent from my iPhone
On Jun 12, 2008, at 12:02 PM, Tito Ciuro [EMAIL PROTECTED] wrote:
Hello,
Although I prefer the safer accessors, there has been one case where
I had no choice but to return the main object pointer:
- (NSString *)foo
{
return foo;
}
In my app I had a method that was populating a custom cell with a
few elements. Depending on the data source, I had to construct the
strings in different ways. Since this string had to be constructed
with up to 5 elements, when the table view had many rows,
performance suffered greatly during sort and memory consumption
spiked tremendously due to a barrage of newly allocated objects.
I ended up writing something like:
// Private version used only for performance
- (NSString *)_foo
{
return foo;
}
// Safer version used in all other cases
- (NSString *)foo
{
return [[foo retain] autorelease];
}
By using '_foo' during sorting I increased speed noticeably, while
reducing the memory footprint.
-- Tito
On 12 Jun 2008, at 11:27 AM, Jens Alfke wrote:
On 12 Jun '08, at 10:41 AM, Andy Lee wrote:
I hadn't thought of this case.
Thanks for the pointer to the docs -- I now see there is a
vulnerability in the accessors I've been writing.
This is kind of a religious issue. Some people like the safer
accessors. Some people see them as a very expensive* workaround for
a problem that rarely occurs.
I'm firmly in the latter camp. I've never used this 'safe' form of
accessor, and have only rarely run into the kind of crash it
prevents; and it was always pretty easy to track down and fix. (The
fix is just for the caller to retain the value it got from the
accessor, then release it when it's done using it.)
Another alternative is to leave the getters simple, but change the
_setter_ methods to autorelease the old value instead of releasing
it; that prevents this same crash, but is less expensive because
setters are much more rarely called than getters (and -autorelease
isn't much more expensive than -release.)
―Jens
* A basic accessor requires one or two machine instructions to do
the actual work; whereas -retain and -autorelease involve extra
method dispatches that each acquire a global lock and do a
hashtable lookup. Obviously any one call isn't going to take a
noticeable amount of time, but accessor calls are so damn
ubiquitous that this can have an overall impact on app performance
in some cases. Not to mention memory usage, since autoreleased
objects have a longer lifespan and can build up during
loops.___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.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/jeff_lamarche%40mac.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: Identical events on multiple calendars
On Jun 12, 2008, at 1:30 PM, Larry Hendricks wrote: I'd consider this a bug although it seems like it may be by design. Should I file it, or is there a workaround? Technically that's not a bug, but I'd suggest filing an enhacement request asking that calendars become identity properties of events and tasks. We've run into this too... 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: Accessors Question
On Jun 12, 2008, at 12:20 PM, Jeff LaMarche wrote: Out of curiosity, does anyone know what the synthesized accessors look like when you specify retain? Are they ' The retain/autorelease policy is dictated by the atomicity of the property. By default, object properties are returned with retain/autorelease; if you specify 'nonatomic' then they're simply returned. http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_3.html#//apple_ref/doc/uid/TP30001163-CH17-SW2 For a discussion of other aspects of accessor methods, see http://www.stepwise.com/Articles/Technical/2002-06-11.01.html (although some of that is now out-of-date). 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: argument checks
On Jun 12, 2008, at 2:29 AM, Graham Cox wrote: On 12 Jun 2008, at 5:03 pm, Chris Suter wrote: In the original example, myNum was being passed as a argument rather than having a message to sent to it and it’s often not safe to pass nil objects as arguments. Hmmm... well, what's the function it's passed to going to do with it, other than call a method on it? If it's doing anything else, it's breaking other (much stronger) rules. If it tries to access its ivars directly, that's breaking encapsulation. Not if you're passing an object to a method of its own class. Then, it's permitted to access its own implementation details. So, for example, -[NSDictionary initWithDictionary:] may very well operate by accessing the internal details of the passed-in dictionary. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: removeFrameUsingName: doesn't?
Am 28.02.2008 um 23:17 schrieb Quincey Morris
[EMAIL PROTECTED]:
On Feb 28, 2008, at 12:25, Mike Fischer wrote:
OK, nobody answered so I did a further test:
...
Then I relaunched the app, used the IBAction to remove the Auto Save
Name and quit the app again. The key was still there! So it's a bug
in AppKit/Cocoa it seems. NSWindow -removeFrameUsingName: does
nothing at all AFAICT.
Well this time I got interested enough to go read the NSWindow class
reference for removeFrameUsingName. It doesn't say that this method is
supposed to remove the key from the preferences. It *seems* to say
that it leaves the key but removes the frame data (in the sense of
setObject: @ forKey: windowAutosaveName, it looks like, but I'm
guessing).
You didn't say whether you saw any non-blank saved frame data
associated with the key after using removeFrameUsingName.
Sorry, somehow I seem to have missed your answer in Febuary and
happend to find it today. (I read this list as digests which may have
contributed to my missing your post.)
No, the content of the key in the preferenes file does not change at
all and the window will use the saved data the next time the app is
launched. As I wrote in Febuary, the method does not seem to do
anything at all. It does not even work if I close the window before
calling removeFrameUsingName: like this:
- (IBAction)handleDeleteAutosaveFrame:(id)sender
{
NSString*s = [fWindow frameAutosaveName];
// At this point s contains the string w1 which is the Auto
Save Name I set for the window in IB.
if ([s length] 0) {
[fWindow setFrameAutosaveName:@];
[fWindow close]; // The window has its Release when
closed attribute set in IB so it should release at this point.
[NSWindow removeFrameUsingName:s];
}
}
I just verified these results on Mac OS X 10.4.11 (PPC) as well as on
10.5.3 (Intel).
My Bug came back as a duplicate of rdar://4785592
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: http://homepage.mac.com/mike_fischer/index.html
Note: I read this list in digest mode!
Send me a private copy for faster responses.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Memory not freed with CIImage
WOW it worked! Thank you very much... Anyone filed a bug notice of this to Apple? Thanks to everybody for the suggestions Stefano On 12/giu/08, at 11:51, Fabian wrote: From the archives, originally posted by Rob Keniger: I had problems with this too, and I use a workaround I found somewhere where you render to a CGImageRef in the context of the current window. Here's a dump of the code: ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
how do you make NIB connections for class with multiple categories (and their headers)?
my head is hurting I am trying to understand the NIB/code connection. I have a couple of windows in this project, one of which I am working on, the other I have been leaving alone. For MyWindow, I have been adding methods in my category.h file, and dragging that header to the nib, and linking up the controls. That seems to be working okay. The problem is that there don't seem to be any connections for the OldWindow. How can that be? a bit later Oh dang. It looks like I broke the OldWindow while working on MyWindow. I am going to have to roll back to a working version. one of my many questions This project consists of a AppController class with a bunch of added categories, one of which I am trying to implement. So, there are a bunch of AppController+ExtraCategory header/source files. I think I understand how we synchronize the code and the nib, by dragging the header file from the Xcode project to the nib-instance window. But what about a project like this, with a bunch of different header files, all of which are part of the same controller? Do I select all the header files in the Xcode project and drag all of them into the nib-instance window? And, when I do that should I merge the contents, or replace? I don't wnat to break an existing connection by dragging my AppController(MyCategory) header onto the nib-instance winodw only to break all the established connections for the other categories! (I see I can lock the connections, which I will do, but I still want to know how to add the connections of MyCategory without stepping on the other ones. cocoa + objc + ibuilder = lots of questions ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: how do you make NIB connections for class with multiple categories (and their headers)?
On 12 Jun '08, at 4:43 PM, Paul Archibald wrote: But what about a project like this, with a bunch of different header files, all of which are part of the same controller? Do I select all the header files in the Xcode project and drag all of them into the nib-instance window? And, when I do that should I merge the contents, or replace? Just drag the header(s) that changed. In this case it's probably safer to do a merge than a replace, since I'm not sure how clever IB was about header parsing in Tiger. FYI, this is all a lot more convenient on Leopard. IB 3 now automatically notices changes to header files as soon as you save them, so the outlets/actions in your nib are always up-to-date. —Jens 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: argument checks
I thought ObjC used #import, not #include, so that multiple copies of a header wouldn't appear, but maybe that's just for Cocoa stuff, and not for ordinary C? On Jun 12, 2008, at 1:05 AM, Jason Coco wrote: #include assert.h /* ... */ NSNumber *myNum = nil; // Lots of code where you've forgotten to actually do anything with myNum assert( myNum != nil ); results = [myClass someCalculationUsing: myNum]; // lots more code to remove the assertion in the release build, compile with -DNDEBUG HTH, /jason On Jun 12, 2008, at 01:50 , Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jason.coco% 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/wsquires% 40satx.rr.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: argument checks
You can use #import in straight C applications from within Xcode, if you like. There's also nothing stopping you from using the #include directive in Objective-C. It's just more work than #import, which handles include cycles for you. -- m-s On 12 Jun, 2008, at 21:37, William Squires wrote: I thought ObjC used #import, not #include, so that multiple copies of a header wouldn't appear, but maybe that's just for Cocoa stuff, and not for ordinary C? On Jun 12, 2008, at 1:05 AM, Jason Coco wrote: #include assert.h /* ... */ NSNumber *myNum = nil; // Lots of code where you've forgotten to actually do anything with myNum assert( myNum != nil ); results = [myClass someCalculationUsing: myNum]; // lots more code to remove the assertion in the release build, compile with -DNDEBUG HTH, /jason On Jun 12, 2008, at 01:50 , Ashley Perrien wrote: Noob question: I'm putting together a small code library and I'm trying to include some error checking in the methods; what I want to protect against is the following: NSNumber *myNum; // Lots of code where I've forgotten to actually do anything with myNum results = [myClass someCalculationUsing: myNum]; myNum in this case is an object and does exist but it's not a valid, usable argument. So in the implementation I'd like to have something along the lines of: if (myNum == nil) NSLog(@some error message); but can't figure out what to check for that would get me into the error message condition. Any suggestions? Ashley Perrien ___ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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]
Attack My Code! Part 1
I'm new at programming in Cocoa, and if it is not rude to post a big
block of code to this list, I'd like to show you all a class I
developed and ask you to tell me about all the ways I've screwed it up!
BACKGROUND INFO
I'm trying to learn Chinese and I have a bunch of comic books to (try
to) read. Because writing is done with ideograms instead of an
alphabet, it's a bit of a pain to look words up in a dictionary, so
you wanna make notes to avoid having to look up the same character
again when you find it on the next page. Making notes on paper is not
ideal because it's hard to make them into a good reference; but making
notes on the Mac is hugely annoying because it's annoying to start
typing and find you haven't selected the right keyboard layout.
So what I want is an app that lets me enter word, pronunciation, and
definition in separate fields that REMEMBER the proper keyboard layout
and switch automatically when you enter and exit the fields.
I want to somehow connect my app to another app's text editor window
and tell it to transfer in a given format (hopefully HTML or RTF so
that the pronunciation and definition can be hidden until I need to
refer to them) so that I can do most of the typing in my little app
window and each time I've finished typing the word, pronunciation, and
definition, I can smack a button that will copy the finished product
to the pasteboard and send a signal to the other app to paste it.
The class I have to show to you today is the formatter that holds the
word, pronunciation, and definition as the user types them in, and is
ready at any time to provide them properly formatted in a variety of
ways. The best of these so far is HTML format, which hides the
pronunciation and definition in a tooltip!
Actually, the class seems to work pretty well, but the copyAsHtml and
copyAsRtf methods seem to put garbage on the clipboard. I have pored
over Apple's documentation regarding the pasteboard and converting an
attributed string to RTF, but there must be some crucial point I am
missing.
So I am looking for advice about how to get copyAsHtml and copyAsRtf
to work correctly, but also advice about anything else that I may be
doing wrong in the class.
Um, I guess I should ask: If this is not the proper place to be
sharing code like this, I would be happy to learn the better
alternative. I'm hoping to occasionally post classes as the app
develops and get feedback.
Here's my class:
// Formatter.h
#import Cocoa/Cocoa.h
@interface Formatter : NSObject {
NSString* word;
NSString* pronounciation;
NSString* definition;
NSPasteboard* thePasteboard;
}
-(id)init;
-(NSString*)pronounciationSurroundedBy:(NSString*)surroundChars;
-(NSString*)pronounciationSurroundedBy:(NSString*)surroundChars
withDefinitionSeparatedBy:(NSString*)sep;
-(NSString*)asText;
-(NSString*)asCsv;
-(NSString*)asHtml;
-(NSAttributedString*)asAttributedString;
-(void)copyAsText;
-(void)copyAsCsv;
-(void)copyAsHtml;
-(void)copyAsRtf;
@property(readwrite, copy) NSString* word;
@property(readwrite, copy) NSString* pronounciation;
@property(readwrite, copy) NSString* definition;
@end
// Formatter.m
#import Formatter.h
#define DOUBLE_QUOTE @\
@implementation Formatter
//-
+(NSString*)trimmedString:(NSString*)s
{
if ( s == NULL ) {
return @;
} else {
return [ s stringByTrimmingCharactersInSet:[ NSCharacterSet
whitespaceAndNewlineCharacterSet ] ];
}
}
//-
+(NSString*)surroundNonEmptyString:(NSString*)text with:
(NSString*)surroundChars
{
if ( [ text length ] 0 surroundChars != NULL ) {
int numChars = [ surroundChars length ];
if ( numChars 0 ) {
unichar l = [ surroundChars characterAtIndex:0 ];
unichar r = ( numChars == 1 )? l : [ surroundChars
characterAtIndex:1 ];
return [ NSString stringWithFormat:@[EMAIL PROTECTED], l, text, r ];
}
}
return text;
}
//-
+(NSString*)concatString:(NSString*)a withString:(NSString*)b
separatedBy:(NSString*)sep
{
int aLen = ( a != NULL ) ? [ a length ] : 0;
int bLen = ( b != NULL ) ? [ b length ] : 0;
if ( aLen 0 bLen 0 ) {
return [ NSString stringWithFormat:@[EMAIL PROTECTED]@%@, a, sep, b ];
} else if ( aLen 0 ) {
return a;
} else if ( bLen 0 ) {
return b;
} else {
return @;
}
}
//-
-(id)init
{
// Ensure all our data member variables have legal values
word = @;
pronounciation = @;
definition = @;
// Prepare the pasteboard (clipboard) to recieve our clippings
thePasteboard = [ NSPasteboard generalPasteboard ];
NSArray* clippingTypes = [ NSArray arrayWithObjects:
NSStringPboardType, NSRTFPboardType, NSHTMLPboardType, nil ];
[ thePasteboard declareTypes:clippingTypes owner:self ];
return self;
}
//-
Attack My Code! Part 1 (postscript)
Oops, I forgot to mention, I'm using garbage collection so that I won't have to struggle with retention! I wish I had edited my previous post a bit more for clarity, but it's late and I gotta get to bed. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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]
Have questions...
Am I aloud to ask where I can submit my iPhone programming questions to? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Have questions...
On 12 Jun 08, at 21:09, Rick Langschultz wrote: Am I aloud to ask where I can submit my iPhone programming questions to You're certainly allowed to ask. However, the answer is nobody, for now - sorry. Hopefully this'll change in a month or so... ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Have questions...
On Fri, Jun 13, 2008 at 12:43 AM, Andrew Farmer [EMAIL PROTECTED] wrote: You're certainly allowed to ask. However, the answer is nobody, for now - sorry. Hopefully this'll change in a month or so... I thought the official answer was to e-mail DTS directly. Then again I'm not an iPhone dev... --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: Table View/Array Troubles
On Thu, Jun 12, 2008 at 2:00 AM, Bob Warwick [EMAIL PROTECTED] wrote:
Calling the NSMutableArray convenience method array will return an
autoreleased object. You should do this instead:
- (id) init
{
[super init];
myNotes = [[NSMutableArray alloc] init];
return self;
}
Actually, it should really be like this (I've been pedantically explicit):
- (id)init
{
self = [super init];
if(self != nil)
{
myNotes = [[NSMutableArray alloc] init];
}
return self;
}
Note that -init is NOT required to return the same object that self
refers to. Therefore it is always required that you re-assign self in
your overridden initializer if you need to access it, and you must
return that modified self*.
--Kyle Sluder
* Please note that this is the common case. If you're implementing
the singleton pattern, for example, you would override -init
differently. And there are other cases like class clusters where you
will instead be returning different objects from -init that super's
implementation returns. But these are Very Advanced Topics(TM).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Have questions...
On 12 Jun 08, at 22:16, Kyle Sluder wrote: On Fri, Jun 13, 2008 at 12:43 AM, Andrew Farmer [EMAIL PROTECTED] wrote: You're certainly allowed to ask. However, the answer is nobody, for now - sorry. Hopefully this'll change in a month or so... I thought the official answer was to e-mail DTS directly. Then again I'm not an iPhone dev... Yeah, I suppose there is that, if you're really stuck. -- Andrew not an iPhone developer, just plays one on the internet Farmer ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 USB Power
Hey, I have a Cocoa application that controls an external USB device. I want to be able to turn the device off when the user performs some action, like click a button. Is there a way in Cocoa or IOKit to disable power to a USB Socket? The application runs on Leopard. Thanks in advance, Omar Qazi Hello, Galaxy! 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]
