September 2008 - Cocoa-dev - lists.apple.com

Re: Finding other apps' paths - deterministically!
by Charles Srstka 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com On Sep 30, 2008, at 12:00 PM, Jerry Krinock wrote: Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… Also, it seems to not find helper applications which are inside other applications' packages. Is there any reason why you couldn't just search for the main application which contains the helper application inside its bundle and then just go from there to find the helper? This email sent to site_archiver(a)lists.apple.com

1 0

Re: [Math] sin(), cos() not working? What special magic must I use to summon their powers?
by Michael Robinson 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=EiXmGzzASmYZNX2Wf/Whqr8ZMHsyTiF3DLZQ3te6A2w=; b=HkoUEixAmgr+Ima6nYqKiDMTYF9osniXL3ohYrYcu6c8AtMSIYg+W+491QTrDrH7Cb FB0raR9InSXLMx8zd0SM1k9AN7c1v7zSrk43Eb0JQmGl5jqtFplpW97RLEjdV/1mRqR6 F+iIvxUDweX7BZzustjjYu0SAyNrvTEo4UtA8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=LAx++0Nt9QxbYXs1DYt4xbS1gZePaU/2YwEn/OibnQ2yCtx+Nd12Pa3CEs3g+Ke5r6 8nIqLAfwXloLLH/mTwIe5GmDLtaDehMxa4AB+qUvtFHds+yvAc/9TQ58Sh29X26RTnF0 a8DLlSOFKY1Eg00I2Ryx5FyvT7tCVOsU4QCS4= On 1/10/2008, at 3:23 AM, Alastair Houghton wrote: On 30 Sep 2008, at 12:59, Michael Robinson wrote: Thanks for your incredibly swift replies! The code that outputs the divs is: } return (NSString*)cornerElements; With the code that generates the margin for the rounded corners: case 1: if(){ retVal = lround(size*(1-cos(asin((double)i/(double)size)))); if(retVal > 0 ) return retVal; } return 0; break; Thank you for your help, Mike Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… changing "float retVal" to "double retVal", using "return lround(retVal);" and casting ints as doubles in the formula gave me some real values, which is wonderful! I could have saved myself two hours by asking the list when I first ran into this problem! I've got it spitting out some (jagged but acceptable) corners now, which is wonderful. In case any of you were interested, I'm doing this to create an HTML "object" that can be placed over any background, be given rounded corners and have the background show through. It was being accomplished with Javascript, but I figured it'd be better if this was done one time, when the HTML is generated, instead of at client side. If you're rendering this in advance using Cocoa, why not use the - appendBezierPathWithArcFromPoint:toPoint:radius: method on NSBezierPath to construct a rounded path? int i; NSMutableString *cornerElements = [NSMutableString new]; for(i = cornerSize; i > 0; i--){ [cornerElements appendString:[NSString stringWithFormat:@"<div style= \"font-size:0em;margin-left:%ipx;margin-right:%ipx;height: 1px;overflow:hidden;background-color:%@;\"> </div>",[self getCornerStripWidth:i:[borderDDTL selectedTag]:sizeTL:cornerSize], [self getCornerStripWidth:i:[borderDDTR selectedTag]:sizeTR:cornerSize],[self hexColor:[portalBGColour color]]]]; I had a look at using NSBezierPath, but as I already had code that "works", I didn't know whether it would be worth changing methods - what would the advantage of using NSBezierPath be? This email sent to site_archiver(a)lists.apple.com

1 0

Cocoa and MySQL
by J. Todd Slack 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Hi All, Working with app that I use NSTask to execute some MySQL statements. -Jason _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… I want to deploy the client to start testing, but I am not sure to deploy to them in the MySQL Sense. I dont quite recall what I did for MySQL on my machine. I want to create a package installer that puts the mysql pieces where they need to go so my NSTasks will work. Can anyone tell me what to deploy and where? I dont want them to have to execute another installer to get this. This email sent to site_archiver(a)lists.apple.com

1 0

re: NSManagedObject custom class & for loop
by HAMILTON, Steven 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Thread-index: AckjUaLnRpNyVdgsSAWUk1BdPW6gig== Thread-topic: NSManagedObject custom class & for loop Great stuff. Thanks a lot, that works a treat. Feed: Cocoa mail archive Posted on: Monday, 29 September 2008 8:22 PM Author: Steven Hamilton Subject: NSManagedObject custom class & for loop > The problem is when the code hits the for (transaction in > transactions) loop it dumps to GDB with an obj_msgsend error and I > can't see why. Am I trying to do something that a custom class > shouldn't be able to do? If I comment out the loop it runs fine. In the first line of your loop you're sending the -amount message to the entity, not the transaction object. That line should probably read NSNumber *amount = [transaction amount] A few other things though, with more than a few transactions this will be really slow. You could request the sum of the transaction amounts directly from CoreData and it could handle them much quicker. Something like [account valueForKeyPath:@"transactions.(a)sum.amount"] assuming you've set up a "transactions" relationship. If you don't have a relationship you could still perform your fetch and issue a similar message to the transactions array you get here, [transactions valueForKeyPath:@"@sum.amount"] If, for some reason, you still need to iterate over all of the objects individually, I'd recommend that you don't convert your final balance to an NSNumber until you're finished with your loop. Ashley Clark ________________________________ This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its related entities "Suncorp". Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au. The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system. If this e-mail constitutes a commercial message of a type that you no longer wish to receive please reply to this e-mail by typing Unsubscribe in the subject line. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Release build wrong executable name, but debug build it correct
by David 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xvFhw8xH094Fx/D4KGmy/mAXuBrWBLrKK6toh7GeCJk=; b=axkoaidiOB4PSQv8VvDfUxR6o0HusZW1NFjkpPrOP7XPiHRfsNxvgiEJ6GvthtYFKc cJysAde8K3VhJbzi4pH/nCrfDjJCVee2HbCjZNM03SlgaOpbERAu7kAaxBVb5p71dedC bP0+7Bo0jVN6txOQNSo/V8Uy1eYDWMW6XF0/4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bflZkYJpOHVmT9dQtHhEeZX2uSYApxuLNJMbsJB5zA+/4aIYxB1xG1EqWCuY2dcfuK QKlrWAbZu0pvEp5gEFndXTR3eZuxaTr7Y1IC+BMbpJqXOgLpnlRuQQSl+hxrCJWMq72d C2yicEC/thaiZeAVUqO2nm09At+jb4PV/01pc= I was looking under the project properties not under target properties. Product name was set to the old value. Thanks! On Tue, Sep 30, 2008 at 5:16 PM, Mark Dawson <marc(a)mac.com> wrote: > > On Tuesday, September 30, 2008, at 01:09PM, "Nick Zitzmann" <nick(a)chronosnet.com> wrote: >> >>On Sep 30, 2008, at 2:02 PM, David wrote: >> >>> Except that it only does it for a debug build. For the release build >>> it reverted back to the old name. >>> >>> What gives? I can't figure out why its doing this. >> >> >>Are you sure you have your product name in sync across configurations? >>In the target's build tab, if you change the configuration to "all >>configurations", what happens to the product name? >> > I would check 3 places: > - Under Target Info: > (1) Check the "General" name > (2) Check the "Build", "Product" name > > - Under the Executables section (bottom, left of an Xcode project), check to make sure that it has the correct name. Usually the "General" name syncs to the "Executable" name, but not always. > > Mark > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/enki1711%40gmail.com > > This email sent to enki1711(a)gmail.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Release build wrong executable name, but debug build it correct
by Mark Dawson 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com On Tuesday, September 30, 2008, at 01:09PM, "Nick Zitzmann" <nick(a)chronosnet.com> wrote: > >On Sep 30, 2008, at 2:02 PM, David wrote: > >> Except that it only does it for a debug build. For the release build >> it reverted back to the old name. >> >> What gives? I can't figure out why its doing this. > > >Are you sure you have your product name in sync across configurations? >In the target's build tab, if you change the configuration to "all >configurations", what happens to the product name? > I would check 3 places: - Under Target Info: (1) Check the "General" name (2) Check the "Build", "Product" name - Under the Executables section (bottom, left of an Xcode project), check to make sure that it has the correct name. Usually the "General" name syncs to the "Executable" name, but not always. Mark _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSLevelIndicator - setEnabled not respected
by Ken Ferry 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uibSPbgaHOGHwUqL6zjLs/7G0YFjl/OPrUPbsTehyqs=; b=I0T6T7g0cFNtDBD0fHi12SU2uV4rf3NuU+8YVe2NkFOhIqRB0aj7eMiBEEsnhWtz9V 2PVvu1fTcV1anrZF7S3/yEh0jk5zUp3jHWX2lYZrjrTK1MBkQuXrsO4QM8liPAkf8mES xKuLquvu9JWkhzv+Fef+hUXlwoP3UFa2okL8k= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=AfQtwvi2VssYjpbm77w/aUwI6eofIyjM1fPYDgij1eDoRIiDvhoPLV5F0e3UHQmkLp F3BTROrn4HLZfJdKVRn9dVNZfDvHDx/1UfzBqWi5yB9RXjv+ff8y9xUG+pq0vs/kToxA nFy2H6o6REi8hY5aocIPQ8T5uFQFxYBQJlfU4= On Tue, Sep 30, 2008 at 1:16 PM, Ken Ferry <kenferry(a)gmail.com> wrote: > On Tue, Sep 30, 2008 at 8:57 AM, Benjamin Stiglitz <stig(a)apple.com> wrote: >>> I've googled for over a week, and I can't find out what I'm missing here. >> >> See the AppKit release notes for 10.5 at >> <http://developer.apple.com/releasenotes/Cocoa/AppKit.html> >> >> In short, the enabled property only works if you link your app against >> 10.5+. >> >> -Ben > > Actually, it's the editable property that changed for 10.5, and now > hopefully does what people expect. > > Disabling the level indicator should keep it from responding to mouse > events, so I don't know what's wrong in Michael's case. On second thought, Michael is only logging the enabled property at awakeFromNib time. It's probably being modified after that, perhaps due to a bindings interaction. Try binding the enabled property. > Works fine > for me. (Though, if we didn't have binary compatibility to worry > about, a disabled level indicator ought to be dimmed out, which is > probably not what Michael wants.) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSManagedObject subclass accessor pattern mystery?
by Ben Trumbull 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com On Sep 30, 2008, at 8:38 AM, Michael B Johnson wrote: Thanks for all the insight. A few questions: On Sep 30, 2008, at 3:08 AM, Ben Trumbull wrote: @property (retain) NSColor* color; but since we may need to calculate it, we also map it to an instance variable _color: - Ben _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… So I have a CoreData app (10.5.5, 64 bit only) that has a NSManagedObject that has an NSColor* that is part of its data model. Because this color is actually a computed value that we want to cache, it is declared as a property: ... this doesn't follow. That you need to calculate it doesn't mean it has to be in an ivar. Okay, here's my dilemma. I think I'm missing something fundamental. The behavior I want is: We want to calculate the "color" of the object lazily. The color is a computed property based on the thumbnail image of the object. The thumbnail is itself a computed property, based on the URL of the the thumbnail image. In other words, we only require a thumbnail URL - everything can be gotten from that. When we start up and have only a thumbnailURL, we're satisfied with that until we're asked for our color. At that point, we want to set the thumbnail property based on the thumbnailURL, and we then calculate the color based on thumbnail info. Once we've gone to the trouble of calculating the color, we want to save it out as part of our store, so we don't have to recache it at some later point. We do not want to save our thumbnail - it's too big, and we can easily get it from the URL. Sure. Nothing unusual about this. There's a chapter on it in the Core Data Programming Guide. "Non-Standard Persistent Attributes" The only way I could think of it to let me know at a glance whether the color property had been cached was to have an instance variable that I could check for nil. If it was nil, I hadn't cached it, and therefore would at that point. Otherwise, I knew it was already calculated, and didn't need to initialize the thumbnail for me to calculate it. Well, that's not the only way, but it's probably the easiest. The two most obvious possibilities are (a) call -primitiveColor and check its results for nil (after properly calling - willAccessValueForKey:@"color" of course) or (b) having an ivar bitfield and tracking the initialized state as a flag. So what's the right way to do this? Having ivars is fine. Unmodeled properties are useful for many things. But putting modeled persistent data in them in usually a mistake. While it's possible, and described in the documentation, I discourage it since it's nearly always a sign someone is driving in the wrong direction. Also, putting modeled properties in ivars is slower than just letting Core Data do its thing with the dynamic properties, so you ought to have an especially good reason before trying that. I'm obviously not aligned with the one true Core Data way yet :-) Probably the key concept here is the distinction between public v.s. primitive accessors, along with the abstraction of the actual memory allocations in NSManagedObjects behind the primitive accessors. This email sent to site_archiver(a)lists.apple.com

1 0

Adding a new menu programmatically
by Matthew Gertner 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=Q21ESeUmfE4JRf3YA3TERXia+ckGXpo/XAZVqtmZOZc=; b=bDg7UgYO6DWZCU3XVsc/6fo9b2gIr9g2CSEeQ2asajRUZdI/LMFJyPkxT1BGuaRkVQ ccp3qrtKFsXZ4O72PCyMmdCaqv8hCK7x5mLbiXCfrQblvurkeCj4M1Fq0tdYyRHvZVS9 YVCXODbif+S7w/BcEJqVlm9LufjV4qfpvfjhs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=ghpJ/yhQIV7BpXB+5+puxtRiH+OEw/fARrjpi0B09rQWV7WLd1T4d57Myj/SsJ+Izg 8D9dcQYEvWBcwVf2R/dnzTZqouz104N5AYdEqQizYzxwGgfHfLrIftchJmPaCokxGoBJ T0+gmWBOMVJguTLZLfNxjiV1GVNkrhiQxzFV4= Hi, I'm trying to add a new menu to the main menu of my application using Cocoa. I thought something like this would do the trick: NSMenu* menu = [[NSMenu alloc] initWithTitle:@"foo"]; NSMenuItem* item = [[NSApp mainMenu] addItemWithTitle:@"foo" action: nil keyEquivalent: @""]; [item setSubmenu:menu]; Unfortunately that doesn't seem to do anything at all. I thought that the top-level menus were actually menu items on the main menu, but perhaps I am misunderstanding? Matt _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NSLevelIndicator - setEnabled not respected
by Ken Ferry 30 Sep '08

30 Sep '08

site_archiver(a)lists.apple.com Delivered-To: cocoa-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dgBzF0HYQbIVAZ/g33Z3e8uxiX2obv2moGebKz5dDd0=; b=jMw7UcnrNWZEI3nlyuAd5u2DGWbvJFfAeRbR+jRur/0SS+M6wqy5zXWpUdmx7g9KBh D8hsIcNUoWUVS1KA0XZO98Fordxe3ThASGDhO8wIj6cRS9bqV9PUhyvSh+JCGc+ww0ns WRuOdaRdi7wgudRMNdUEI/Ew3Mx764ZBAexvo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OYKluDiFVTf39ytCK5nLXLBxP3I0Sr6UqFwj5DjzHT1LQHnixQuxXP0mndnH0vsWmn lmZHaHSRkZajGt3zOeoflk6xGnKi2ngTd9abhprxDDDVqjMWponk5Z3zvZXvs1RD2sC6 1Qek6PqC0OpL255yapqFGZghKW4u5iKH+F+9I= On Tue, Sep 30, 2008 at 8:57 AM, Benjamin Stiglitz <stig(a)apple.com> wrote: >> I've googled for over a week, and I can't find out what I'm missing here. > > See the AppKit release notes for 10.5 at > <http://developer.apple.com/releasenotes/Cocoa/AppKit.html> > > In short, the enabled property only works if you link your app against > 10.5+. > > -Ben Actually, it's the editable property that changed for 10.5, and now hopefully does what people expect. Disabling the level indicator should keep it from responding to mouse events, so I don't know what's wrong in Michael's case. Works fine for me. (Though, if we didn't have binary compatibility to worry about, a disabled level indicator ought to be dimmed out, which is probably not what Michael wants.) -Ken Cocoa Frameworks _______________________________________________ Cocoa-dev mailing list (Cocoa-dev(a)lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl… This email sent to site_archiver(a)lists.apple.com

1 0