Re: Simple question? NSButton/checkbox color
There's no supported way to do it and never has been; back in the day when Java's compatibility test had a set button color, the MacLookAndFeel got an exemption because it's just not possible. If you look in the Calendar app bundle it has grayscale checkbox images, which they probably colorize with code specific to Calendar - so even Apple is using images to mimic the UI - and since it's specific to the OS it ships with, it doesn't have to worry about mismatches if it runs on a different one. - Original Message - From: Alex Kac a...@webis.net To: SevenBits sevenbitst...@gmail.com Cc: Cocoa-Dev Cocoa-dev@lists.apple.com Sent: Thursday, June 5, 2014 10:42:48 PM Subject: Re: Simple question? NSButton/checkbox color OK maybe I’m not being clear. We need to have a checkbox that can be colored, exactly the same way that the Calendar app on both color their checkboxes for the calendar they are representing. Right now the only way I can think of doing that is to create a checkbox image, and color it, and use that. Obviously if we do that, we have to have different images for Mavericks and Yosemite. So we have to mimic Yosemite. I’d prefer NOT to have to create mimicked checkbox images. That’s what I’m trying to prevent. I’m asking all the AppKit gurus here if there is a better way, a more proper way, to color a checkbox control without having to use images to mimic the UI of the OS we’re running on. On Jun 5, 2014, at 6:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Alex Kac - President and Founder Web Information Solutions, Inc. “Don't forget until too late that the business of life is not business but living.” -- B.C. Forbes, ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0Am=DShi9mvJqH2rPq9TzcpBlepgV0kKVHzLB5ubcAwsMow%3D%0As=4b6656ae3389e22b2997323ad779cf16443c5361290c42a0ad26132f4ccd6b5f This email sent to lruc...@vmware.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
If I were colorizing such a button, I'd try overriding drawRect: and have the superclass draw in my own focused image, desaturate anything that's fully opaque (check boxes aren't necessarily rectangular nor completely contained), and then apply the desired color with a less-than-1.0 (25% maybe) alpha. After that I'd draw my focused image within the context that was given at the time my drawRect: was called. However, you would need to be careful to be sure whatever background color is present is preserved and also not tinted, and any shadows are correctly handled, and you'd need to handle any intermediate drawing states (including the actual check mark, whatever it may be) and retina issues that may come up. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
That was the way I was expecting to have to go. I just wanted to make sure I wasn’t missing a better way since right now my AppKit knowledge/experience is pretty thin. On Jun 6, 2014, at 2:05 AM, Lee Ann Rucker lruc...@vmware.com wrote: There's no supported way to do it and never has been; back in the day when Java's compatibility test had a set button color, the MacLookAndFeel got an exemption because it's just not possible. If you look in the Calendar app bundle it has grayscale checkbox images, which they probably colorize with code specific to Calendar - so even Apple is using images to mimic the UI - and since it's specific to the OS it ships with, it doesn't have to worry about mismatches if it runs on a different one. - Original Message - From: Alex Kac a...@webis.net To: SevenBits sevenbitst...@gmail.com Cc: Cocoa-Dev Cocoa-dev@lists.apple.com Sent: Thursday, June 5, 2014 10:42:48 PM Subject: Re: Simple question? NSButton/checkbox color OK maybe I’m not being clear. We need to have a checkbox that can be colored, exactly the same way that the Calendar app on both color their checkboxes for the calendar they are representing. Right now the only way I can think of doing that is to create a checkbox image, and color it, and use that. Obviously if we do that, we have to have different images for Mavericks and Yosemite. So we have to mimic Yosemite. I’d prefer NOT to have to create mimicked checkbox images. That’s what I’m trying to prevent. I’m asking all the AppKit gurus here if there is a better way, a more proper way, to color a checkbox control without having to use images to mimic the UI of the OS we’re running on. On Jun 5, 2014, at 6:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Alex Kac - President and Founder Web Information Solutions, Inc. “Don't forget until too late that the business of life is not business but living.” -- B.C. Forbes, ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.comk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0Am=DShi9mvJqH2rPq9TzcpBlepgV0kKVHzLB5ubcAwsMow%3D%0As=4b6656ae3389e22b2997323ad779cf16443c5361290c42a0ad26132f4ccd6b5f This email sent to lruc...@vmware.com Alex Kac - President and Founder Web Information Solutions, Inc. The person who is not hungry says that the coconut has a hard shell. -- African Tribal Saying ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
On Jun 6, 2014, at 01:05 , Lee Ann Rucker lruc...@vmware.com wrote: There's no supported way to do it and never has been I was able to do it — at least partially — in IB: — Select the checkbox — Display the “Core Animation Layer” tab of the inspector palette (the last icon on the right) — Check the box next to the checkbox’ entry in the list. — Add a filter to the “Content Filters” list. — Change the filter to “Hue Adjust”, and enter a parameter to get the color you want. This worked for me when the checkbox was checked, though it was still gray when unchecked — presumably because it’s desaturated so the hue change has no effect. You can probably make it work like Calendar by choose a different filter (Colorize?) or a combination of filters. OTOH, I can’t help saying that colorizing checkboxes doesn’t sound like a fruitful approach to UI design. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Something like this: is what I’m after. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/sevenbitstech%40gmail.com This email sent to sevenbitst...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
On Jun 5, 2014, at 5:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. The NDA has been significantly loosened this year, so I can tell you that there is no support for legacy UI on Yosemite. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question? NSButton/checkbox color
OK maybe I’m not being clear. We need to have a checkbox that can be colored, exactly the same way that the Calendar app on both color their checkboxes for the calendar they are representing. Right now the only way I can think of doing that is to create a checkbox image, and color it, and use that. Obviously if we do that, we have to have different images for Mavericks and Yosemite. So we have to mimic Yosemite. I’d prefer NOT to have to create mimicked checkbox images. That’s what I’m trying to prevent. I’m asking all the AppKit gurus here if there is a better way, a more proper way, to color a checkbox control without having to use images to mimic the UI of the OS we’re running on. On Jun 5, 2014, at 6:38 PM, SevenBits sevenbitst...@gmail.com wrote: On Jun 5, 2014, at 8:32 PM, Alex Kac a...@webis.net wrote: I’m still learning AppKit after many years on iOS :) Given an NSButton based checkbox…what’s the best way to get a colored check? I think we’re just going to have to use a custom image that we create - which is fine just annoying as we’ll also have to match Yosemite - but if there is a better way, I’m all for it. Why mimic Yosemite? Just use the pre-Yosemite look on 10.10, and the Yosemite theme on = 10.10. It’ll be great to have this new interface be implemented as an NSAppearance, so our apps that use custom drawing can fall back on a legacy appearance if the Yosemite look is not supported yet. Anyone know how this new-UI issue will be handled? Without breaking NDA, could someone indicate if this is like iOS 7, where the interface you get depends on the toolkit you link against. Alex Kac - President and Founder Web Information Solutions, Inc. “Don't forget until too late that the business of life is not business but living.” -- B.C. Forbes, ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question about storyboard
Storyboards are iOS 5+ only. On Dec 14, 2012, at 2:33 AM, Jingwei XU jingwei.xu@gmail.com wrote: Hi everyone, I am a newbie in iOS field. I have a question about storyboard. If I use storyboard in a project, is this project is not compatible for iOS 4.3.3? Jingwei Xu Alex Kac - President and Founder Web Information Solutions, Inc. It is useless for sheep to pass a resolution in favor of vegetarianism while wolves remain of a different opinion. -- William Randolph Inge ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question driving me CRAZY
From http://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW17: Which classes don’t support weak references? You cannot currently create weak references to instances of the following classes: NSATSTypesetter, NSColorSpace, NSFont, NSFontManager, NSFontPanel, NSImage, NSMenuView, NSParagraphStyle, NSSimpleHorizontalTypesetter, NSTableCellView,NSTextView, NSViewController, NSWindow, and NSWindowController. In addition, in OS X no classes in the AV Foundation framework support weak references. For declared properties, you should use assign instead of weak; for variables you should use __unsafe_unretained instead of __weak. In addition, you cannot create weak references from instances of NSHashTable, NSMapTable, or NSPointerArray under ARC. HTH, Dave On Jun 16, 2012, at 2:06 PM, Brad Stone wrote: I have a subclass of a NSViewController. In fact, I created on just as a test with no custom code. I then throw an NSTextView in the NSView that comes with it and then drag from the NSTextView to the .h file to create an outlet. Why why why is it making it unsafe_unretained? I'm using ARC. Why it's it weak like every other subview? The NSTextView is in a NSScrollView which is in the controllers NSView. The NSScrollView is coming in as weak. It's been diving me insane all day. Thanks ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com This email sent to davedel...@me.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question
On 23/04/2010, at 1:36 AM, Arnold Nefkens wrote:
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
if (fieldTwo 0) {
NSNumber *answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
If I debug the right values are being shown in the fieldOne, fieldTwo and
fieldThree. But the calculation answer is all the time out of scope.
What am I missing?
NSNumbers are objects that CONTAIN the value to be added, subtracted, etc. They
cannot be added or subtracted directly.
You need to extract the value in the form you want it using methods such as
-floatValue, -intValue and so on before doing calculations. Unfortunately
perhaps, Obj-C does not allow operator overloading to allow direct use of
objects in math expressions.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
Try this:
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
NSNumber *answer;
if (fieldTwo 0) {
answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
-koko
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
On 23/04/2010, at 1:59 AM, k...@highrolls.net wrote: Try this: Looks equally incorrect to me. The problem is that NSNumbers are not NUMBERS. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question
Ok. I was just putting answer in a broader scope as the OP indicated that was the problem. I see I must look into NSNumber ... Thx ! -koko On Apr 22, 2010, at 10:11 AM, Graham Cox wrote: On 23/04/2010, at 1:59 AM, k...@highrolls.net wrote: Try this: Looks equally incorrect to me. The problem is that NSNumbers are not NUMBERS. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question
Hi,
correct me if I'm wrong, but what you're doing is a calculation with
the pointers ( * of NSNumber) not the values. You have to calculate it
like this:
NSInteger fieldOne = [ [ managedObject valueForKey:@key1]
intValue]; // if it's an integer
NSInteger fieldTwo = [ [ managedObject valueForKey:@key2] intValue];
NSInteger fieldThree = [ [ managedObject valueForKey:@key3]
intValue];
if ( fieldTwo 0 )
{
NSNumber *answer = [ NSNumber numberWithInt:fieldTwo - fieldOne +
fieldThree];
[ self.managedObject setValue:answer forKey:@key4];
// maybe you need to this instead
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
}
Don't know if intValue in this context works, if not then use this
alternative, which must work in any way:
Your code and change the following lines:
NSNumber *answer = [ NSNumber numberWithInt: [fieldTwo intValue] -
[fieldOne intValue] + [fieldThree intValue] ];
[ self.managedObject setValue:answer forKey:@key4];
//or
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
//stringValue to present it in a textfield
Hope that helped... MacMeideln
Am 22.04.2010 um 17:36 schrieb Arnold Nefkens:
Hello list,
Im quite new, and probably missing something.
I want to do a calculation of three fields inside of a entity in
CoreData.
Below is the code, what is wrong?
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
if (fieldTwo 0) {
NSNumber *answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
If I debug the right values are being shown in the fieldOne,
fieldTwo and fieldThree. But the calculation answer is all the time
out of scope.
What am I missing?
hope someone can help...
Arnold Nefkens___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/macmeideln%40googlemail.com
This email sent to macmeid...@googlemail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
On 22 Apr 2010, at 17:09, Graham Cox wrote: On 23/04/2010, at 1:59 AM, k...@highrolls.net wrote: Try this: Looks equally incorrect to me. The problem is that NSNumbers are not NUMBERS. If the OP has prior experience with c++ and operator overloading then their confusion might be somewhat explained. NSDecimalNumber includes arithmetic methods but you get nothing like c++'s operator convenience. Regards Jonathan Mitchell Developer http://www.mugginsoft.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question
Hi Thanks
Yeah the keys are ints and this helps a lot.
Thanks again...
On 22 apr 2010, at 18:31, Reinhard Segeler wrote:
Hi,
correct me if I'm wrong, but what you're doing is a calculation with the
pointers ( * of NSNumber) not the values. You have to calculate it like this:
NSInteger fieldOne= [ [ managedObject valueForKey:@key1] intValue]; //
if it's an integer
NSInteger fieldTwo = [ [ managedObject valueForKey:@key2] intValue];
NSInteger fieldThree = [ [ managedObject valueForKey:@key3] intValue];
if ( fieldTwo 0 )
{
NSNumber *answer = [ NSNumber numberWithInt:fieldTwo - fieldOne +
fieldThree];
[ self.managedObject setValue:answer forKey:@key4];
// maybe you need to this instead
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
}
Don't know if intValue in this context works, if not then use this
alternative, which must work in any way:
Your code and change the following lines:
NSNumber *answer = [ NSNumber numberWithInt: [fieldTwo intValue] - [fieldOne
intValue] + [fieldThree intValue] ];
[ self.managedObject setValue:answer forKey:@key4];
//or
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
//stringValue to present it in a textfield
Hope that helped... MacMeideln
Am 22.04.2010 um 17:36 schrieb Arnold Nefkens:
Hello list,
Im quite new, and probably missing something.
I want to do a calculation of three fields inside of a entity in CoreData.
Below is the code, what is wrong?
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
if (fieldTwo 0) {
NSNumber *answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
If I debug the right values are being shown in the fieldOne, fieldTwo and
fieldThree. But the calculation answer is all the time out of scope.
What am I missing?
hope someone can help...
Arnold Nefkens___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/macmeideln%40googlemail.com
This email sent to macmeid...@googlemail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
This is an interesting exercise! I would extract the values of the fields, manipulate them, then assign the contents of Field4 with the answer: int val1 = [managedObject valueForKey:@key1] // etc. for each user entry field1-3 int val4 = val1 + etc. // equation with final assignment to value4 (not actual managed object) [managedObject valueForKey:@key4 setValue:[NSNumber numberWithInt:val4] // final assigning of val4 to managed Object field4 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question
You should really use 'integerValue' rather than 'intValue' if you're otherwise
using NSIntegers. 'integerValue' will return an NSInteger (which may be 32 or
64 bits wide depending on your platform), but 'intValue' will return a C 'int'
(which is always 32 bit on the Mac and iPhone, regardless of the 'natural' bit
width of the platform).
Jamie.
On 22 Apr 2010, at 18:21, Arnold Nefkens wrote:
Hi Thanks
Yeah the keys are ints and this helps a lot.
Thanks again...
On 22 apr 2010, at 18:31, Reinhard Segeler wrote:
Hi,
correct me if I'm wrong, but what you're doing is a calculation with the
pointers ( * of NSNumber) not the values. You have to calculate it like this:
NSInteger fieldOne= [ [ managedObject valueForKey:@key1] intValue]; //
if it's an integer
NSInteger fieldTwo = [ [ managedObject valueForKey:@key2] intValue];
NSInteger fieldThree = [ [ managedObject valueForKey:@key3] intValue];
if ( fieldTwo 0 )
{
NSNumber *answer = [ NSNumber numberWithInt:fieldTwo - fieldOne +
fieldThree];
[ self.managedObject setValue:answer forKey:@key4];
// maybe you need to this instead
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
}
Don't know if intValue in this context works, if not then use this
alternative, which must work in any way:
Your code and change the following lines:
NSNumber *answer = [ NSNumber numberWithInt: [fieldTwo intValue] - [fieldOne
intValue] + [fieldThree intValue] ];
[ self.managedObject setValue:answer forKey:@key4];
//or
[ self.managedObject setValue:[ answer stringValue] forKey:@key4];
//stringValue to present it in a textfield
Hope that helped... MacMeideln
Am 22.04.2010 um 17:36 schrieb Arnold Nefkens:
Hello list,
Im quite new, and probably missing something.
I want to do a calculation of three fields inside of a entity in CoreData.
Below is the code, what is wrong?
NSNumber *fieldOne = [managedObject valueForKey:@key1];
NSNumber *fieldTwo = [managedObject valueForKey:@key2];
NSNumber *fieldThree = [managedObject valueForKey:@key3];
if (fieldTwo 0) {
NSNumber *answer = ((fieldTwo - fieldOne) + fieldThree);
[self.managedObject setValue:[answer intValue] forKey:@key4];
}
If I debug the right values are being shown in the fieldOne, fieldTwo and
fieldThree. But the calculation answer is all the time out of scope.
What am I missing?
hope someone can help...
Arnold Nefkens___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/macmeideln%40googlemail.com
This email sent to macmeid...@googlemail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jamie%40montgomerie.net
This email sent to ja...@montgomerie.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Simple question
On Apr 22, 2010, at 10:21, Arnold Nefkens wrote: Yeah the keys are ints and this helps a lot. Thanks again... On 22 apr 2010, at 18:31, Reinhard Segeler wrote: Hi, correct me if I'm wrong, but what you're doing is a calculation with the pointers ( * of NSNumber) not the values. You have to calculate it like this: NSInteger fieldOne = [ [ managedObject valueForKey:@key1] intValue]; // if it's an integer A minor correction. This should either be: int fieldOne = [ [ managedObject valueForKey:@key1] intValue]; or: NSInteger fieldOne = [ [ managedObject valueForKey:@key1] integerValue]; Otherwise the code is not quite portable between 32- and 64-bit architectures. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Simple question on Menus and Document-based apps
2009/12/21 Henri Häkkinen hen...@henuxsoft.com: So I have a simple document-based application which has MyDocument with some other classes. The application has the default MainMenu.xib and MyDocument.xib interface files. I would like to add a menu item to the MainMenu, which would call an IBAction method on the MyDocument class. However, the document class and the main menu are on different xib files so I can't make the connection. What is the Right Way to handle these kinds of things in Cocoa? Connect the menu item to the First Responder in Interface Builder. At runtime, Cocoa's event-handling machinery will then look through the responder chain (which includes, among other things, the currently-active document) to find an object that has the required action method. For details, have a look at: http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/1060i-CH3-SW2 sherm-- -- Cocoa programming in Perl: http://www.camelbones.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: simple question about variable retain/release (NSDate)
On 21 Nov 08, at 18:17, Bob Sabiston wrote:
Hi,
I have a newbie question about retain/release stuff when using
NSDate. I am confused a little about what is necessary in this case.
I've got a local variable sTime (NSDate *). I use it to measure the
time and then compare it to the current time, so that I can space
out an
animation over one second.
The docs say that [NSDate date] creates and returns an NSDate. Does
that mean the memory's been allocated until I release it?
See the Cocoa memory management rules:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
As the selector name date doesn't start with alloc or new, and
doesn't contain copy, you don't own this object, making all the
releases on sTime incorrect. The crashes are occurring when the
enclosing NSAutoreleasePool gets purged (but that's an implementation
detail - the part that matters is that you're releasing objects that
you never owned).
Here's what I have. It works until the very end, where it crashes.
...
// now wait for 1/30th of a second
do {
elapsedTime = -[sTime timeIntervalSinceNow];
}
while (elapsedTime frameduration);
This is incredibly inefficient. Use
[NSThread sleepUntilDate:[NSDate
dateWithTimeIntervalSinceNow:frameduration]]
instead. (But realize that this'll run slightly under 30 FPS, as the
drawing takes some time.)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: simple question about passing around pointers to objects
On Jun 27, 2008, at 4:22 PM, Paul Archibald wrote: I am reading the Hillegass book, but I don't really see an example of what I am tryng to do, although it seems like a very basic question. [...] But, as I have been trying to make an exhaustive test of what works and what crashes, I realize that just experimenting with this is not enough, and I need a better theoretical understanding of this stuff. Programming by guesswork is a recipe for programs that don't work and are unmaintainable. And memory management is an especially bad topic to guess about. The Hillegass book is actually *full* of examples of what you're trying to do, which is create and use an object. Find the section that explains retain and release and study it again. In the latest edition it's around page 46. If you recognize this pattern and can tell me where to read more on it, that would be great, too. Start here: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/index.html --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 about passing around pointers to objects
The details of memory management take a long time to understand
fully, but there are some basic simple principles that will really
help you out.
1. When you get an object from a method that starts with alloc or
new, or contains the word copy in it, YOU own that object. The
retain count will be 1, (conceptually anyway), that is, no one else
knows about it unless you want to share that object with other code.
2. Any other method that creates a new object that does not use the
words described above (alloc, new, copy), returns to you an object
that basically no one owns, it's been added to the auto-release pool.
So if you do not claim ownership by issuing a retain, that object
will be deallocated during the next autorelease pool cleanup. If
you're just creating and using the object in a method and your object
has local scope and you don't care about holding on the the object
after the method ends, then you don't have to do anything, the object
will be automatically freed. However, if the object needs to survive
the local method, if other methods are going to be called later that
need to have access to that object, you need to claim ownership by
issuing a retain.
In your example you create an NSArray by calling arrayFromObjects.
There is no alloc, new, or copy in that method name, so this
new object now referenced by a is autoreleased. If that's what you
want, do nothing. If the abject referenced by a needs to live when
the method ends, you need to call retain. However, this *specific*
example of yours complicates things, because the method itself is an
object creation method. Your method name is makeObject, which does
not contain the magic words, so any Cocoa user calling your method is
going to expect the object they get back is autoreleased. In this
*specific* example of yours, calling retain on it actually would
break the convention.
As to what you should do in useObject, by convention you expect that
local references an autoreleased object. What happens next
regarding local totally depends on the contract of your MyObj
class' initWithArray method. Does it state it retains the array? If
so, you don't need to do anything if you don't care about local
after this method ends. If you do care, you must retain it. If for
some weird reason MyObj's documentation states that it does not
retain the argument array, I would say that is bad design, but if
that's what the documentation stated, then if you didn't retain it,
the MyObj instance in o might end up holding a reference to a
deallocated object after the next autorelease purge.
And since you've created your MyObj instance o with one the of the
magic words (alloc), YOU own it. You must manage its life-cycle, or
it will never be deallocated. Since this method as written is
returning void, no one else cares about this object. The method ends
without releasing or autoreleasing o, so as written you have a
memory leak, since o will never be deallocated.
Rob Ross, Lead Software Engineer
E! Networks
---
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
On Jun 27, 2008, at 1:22 PM, Paul Archibald wrote:
Comrades:
I have experimented a bit with this, and I think I have something
that works, but I would like to understand it better. I am reading
the Hillegass book, but I don't really see an example of what I am
tryng to do, although it seems like a very basic question.
The Question:
If I want to create an object and pass it to another method, where
I plan to use it briefly (as a local variable), what is the proper
way to allocate and deallocate the object in the various methods?
Here is a simple example:
-(NSArray*) makeObject {
NSArray *a = [NSArray arrayFromObjects];someObject, anotherObject,
nil];
// should I [a retain];
// or [a release];
// or [a autorelease];
// or do nothing
// before I
return a;
}
-(void) useObject {
NSArray *local = [self makeObject];
// should I [local retain];
// or [local release];
// or [local autorelease];
// or do nothing
// before I exit this method?
// I need to pass local as an argument to the creation of another
object before exiting
MyObj *o = [[MyObj alloc] initWithArray:local];
}
There are a lot of possible combinations here, and I have tried a
bunch of them. Some of them work, others crash the program with a
EXC_BAD_ADDRESS. But, as I have been trying to make an exhaustive
test of what works and what crashes, I realize that just
experimenting with this is not enough, and I need a better
theoretical understanding of this stuff. If you recognize this
pattern and can tell me where to read more on it, that would be
great, too.
Re: simple question about passing around pointers to objects
Here is a simple example:
-(NSArray*) makeObject {
NSArray *a = [NSArray arrayFromObjects];someObject, anotherObject,
nil];
This should be NSArray *a = [NSArray arrayFromObjects:someObject,
anotherObject];
// should I [a retain];
I would use [a retain];
// or [a release];
// or [a autorelease];
// or do nothing
// before I
return a;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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 about passing around pointers to objects
On Fri, Jun 27, 2008 at 5:19 PM, Daniel Richman
[EMAIL PROTECTED] wrote:
Here is a simple example:
-(NSArray*) makeObject {
NSArray *a = [NSArray arrayFromObjects];someObject, anotherObject,
nil];
This should be NSArray *a = [NSArray arrayFromObjects:someObject,
anotherObject];
Almost. It should be:
NSArray *a = [NSArray arrayFromObjects:someObject, anotherObject, nil];
(that nil is important)
// should I [a retain];
I would use [a retain];
If you retain a, then you're setting yourself up for a memory leak.
Please read the memory management documentation:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/index.html
--
Clark S. Cox III
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: simple question about passing around pointers to objects
Then you'd be wrong. You should use [a autorelease]; G. On 28 Jun 2008, at 10:19 am, Daniel Richman wrote: I would use [a retain]; ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 about passing around pointers to objects
Actually, in the context of this: NSArray *a = [NSArray arrayFromObjects:someObject, anotherObject, nil]; you would do nothing, since that method returns an autoreleased NSAarray already. But in a situation where you alloc/inited an object, you would autorelease before returning it. G. On 28 Jun 2008, at 2:21 pm, Graham Cox wrote: Then you'd be wrong. You should use [a autorelease]; G. On 28 Jun 2008, at 10:19 am, Daniel Richman wrote: I would use [a retain]; ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. 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: 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: 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: 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: 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: 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: Simple question
Yes, you got it. .h stands for header and is the place where you make your declarations, .m stands for module and is where the definitions take place. You can encounter also .mm exetension. In these file you can mix Objective-C an C++ language. Luca. From: [EMAIL PROTECTED] To: Cocoa-dev@lists.apple.com Date: Tue, 18 Mar 2008 00:45:17 +1300 CC: Subject: Simple question I have studying Cocoa - objective-C by myself for a few days ( im entirely new to programming). There's a question I wanna know about. When you create a project in XCode, and add a new class, does anyone know what .h file and .m respectively for? I mean if they have their own jobs in the coding, I wanna know like .h for declare the varibles and .m for implementing? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/luca_ciciriello%40hotmail.com This email sent to [EMAIL PROTECTED] _ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.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: Simple question
On Mar 17, 2008, at 7:53 AM, Luca Ciciriello wrote: Yes, you got it. .h stands for header and is the place where you make your declarations, .m stands for module and is where the definitions take place. You can encounter also .mm exetension. In these file you can mix Objective-C an C++ language. I would recommend that you find a nice book on C. I would recommend one, but it's been a while since I've surveyed the literature. The C derived languages (with those most relevant to Macintosh programming being, C, C++, Objective-C, and Objective-C++) tend to separate your code into two parts. The first is the active part of your program, that part which does things. This code is placed into a file whose extension depends on the language you are using. As Luca points out .c is for C source code. .m is for Objective-C source code. C++ source is usually found in a file ending either in .cp or .cpp. And Objective-C++ code uses .mm. The header, or .h file doesn't typically contain active code. Instead, it usually contains some kind of description of the code that is found in the corresponding source code file. The description lets other part of your program know what functionality can be found in the source code file. To sum up, the source code file defines what your program can do, and how it can do it. The header file declares what's available and you you invoke it. Scott ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
On 17/03/2008, at 11:33 PM, Scott Thompson wrote: I would recommend that you find a nice book on C. I would recommend one, but it's been a while since I've surveyed the literature. I highly recommend Programming in Objective-C by Stephen Kochan. IMO it is by far the best introduction to Objective-C out there, especially for those who have never used C before. -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
On Mon, Mar 17, 2008 at 9:33 AM, Scott Thompson [EMAIL PROTECTED] wrote: I would recommend that you find a nice book on C. I would recommend one, but it's been a while since I've surveyed the literature. Get The C Programming Language by Kernighan and Ritchie. It is the gold standard of language references. If you're gonna go used, make sure to get a white one (ANSI C), not a gray one (classic, or KR C, which is obsolete). --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
While KR is certainly the gold standard reference, I wouldn't recommend it as the book to learn the language. Kochan's Programming in Objective-C as noted by Rob Keniger is a much better introduction to what you'll need for programming on a Mac. After that one, I recommend Aaron Hillegass's Cocoa Programming for Mac OS X which was recently discussed on this list. It assumes a background in C or Objective-C, but is the best book for learning Cocoa. -Rob On Mon, Mar 17, 2008 at 9:57 AM, Kyle Sluder [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 9:33 AM, Scott Thompson [EMAIL PROTECTED] wrote: I would recommend that you find a nice book on C. I would recommend one, but it's been a while since I've surveyed the literature. Get The C Programming Language by Kernighan and Ritchie. It is the gold standard of language references. If you're gonna go used, make sure to get a white one (ANSI C), not a gray one (classic, or KR C, which is obsolete). --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/robnapier%40gmail.com This email sent to [EMAIL PROTECTED] -- Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. -- B. Franklin, Printer ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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]
