Re: setState has no effect on an NSButton
On May 9, 2011, at 9:55 PM, Graham Cox wrote: > Why bother? Because it's more readable than all those if/else constructions, > and hence, less prone to bugs. Also, if( st == YES)...else if(st == NO) is > redundant - a BOOL can only be YES or NO. The optimiser might optimise away > the second comparison anyway, but why be windy in the first place? A BOOL is just a typedef of an unsigned char, so technically it can hold any value from 0-255. It usually only holds 0 (NO) or 1 (YES) but this is not required and there is code out there that will happily return 2-255 expecting that you treat the value the same as YES. Basically, YES is only useful as an assigned value, not as a comparison value. Code that compares against YES is typically not defensive enough in the face of other semi-badly behaved code. From a performance point of view, the compiler actually cannot optimize away the comparison to NO after the comparison to YES, because it cannot guarantee that the value you are comparing against isn't a value other than YES or NO in most cases. -- David Duncan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. 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: setState has no effect on an NSButton
On 10/05/2011, at 11:19 AM, Martin Batholdy wrote:
> BOOL st = [prefs boolForKey:@"optionA"];
> if(st == YES){ [buttonA setState:NSOnState]; }
> else if(st == NO){ [buttonA setState:NSOffState]; }
Apart from the advice already received, you can reduce this code to:
[buttonA setState:[prefs boolForKey:@"foo"]? NSOnState : NSOffState];
or even
[buttonA setState:[prefs boolForKey:@"foo"]];
if you are prepared to accept that NSOnState and NSOffState are 1 and 0
respectively (which they are, in fact, and unlikely ever to change, but if
you're paranoid, the first line fixes that).
Why bother? Because it's more readable than all those if/else constructions,
and hence, less prone to bugs. Also, if( st == YES)...else if(st == NO) is
redundant - a BOOL can only be YES or NO. The optimiser might optimise away the
second comparison anyway, but why be windy in the first place?
--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: setState has no effect on an NSButton
On May 9, 2011, at 18:19, Martin Batholdy wrote:
> -(void)awakeFromNib {
>
> prefs = [NSUserDefaults standardUserDefaults];
>
> BOOL st = [prefs boolForKey:@"optionA"];
> if(st == YES){ [buttonA setState:NSOnState]; }
> else if(st == NO){ [buttonA setState:NSOffState]; }
>
> st = [prefs boolForKey:@"optionB"];
> if(st == YES){ [buttonB setState:NSOnState]; }
> else if(st == NO){ [buttonB setState:NSOffState]; }
>
> st = [prefs boolForKey:@"optionC"];
> if(st == YES){ [buttonC setState:NSOnState]; }
> else if(st == NO){ [buttonC setState:NSOffState]; }
>
> st = [prefs boolForKey:@"optionD"];
> if(st == YES){ [buttonD setState:NSOnState]; }
> else if(st == NO){ [buttonD setState:NSOffState]; }
> }
What is the class of the object containing this code, and how/when is this
object created? What class is the nib's File's Owner and how/when is that
object created, if different from the object containing the above code?
It could well be that your code is being invoked before all of the nib objects
are instantiated.
If the code's in a window controller, then you should do things like this in a
'windowDidLoad' override rather than 'awakeFromNib'.
If it's not in a window controller, then using a window controller is probably
your best strategy anyway. (There's almost no reason ever *not* to use a window
controller, and plenty of reasons to use one.)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
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: setState has no effect on an NSButton
>From those symptons, it certainly sounds like there is a missing/crossed connection in IB for those buttons or you are mising @property/@synthesize lines for those buttons. - h On Mon, May 9, 2011 at 18:19, Martin Batholdy wrote: > Hi, > > I have a preference window with four NSButtons that are all connected to a > method and an IBOutlet: > > IBOutlet NSButton *buttonA; > IBOutlet NSButton *buttonB; > IBOutlet NSButton *buttonC; > IBOutlet NSButton *buttonD; > NSUserDefaults *prefs; > > > > When I debug this code I see that buttonA and buttonB have an address. > But buttonC and buttonD seems to have no address (0x0) ... > > > what could possibly be the problem here ...? > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
setState has no effect on an NSButton
Hi,
I have a preference window with four NSButtons that are all connected to a
method and an IBOutlet:
IBOutlet NSButton *buttonA;
IBOutlet NSButton *buttonB;
IBOutlet NSButton *buttonC;
IBOutlet NSButton *buttonD;
NSUserDefaults *prefs;
Now I would like to set the state of these buttons according to some
UserDefaults:
-(void)awakeFromNib {
prefs = [NSUserDefaults standardUserDefaults];
BOOL st = [prefs boolForKey:@"optionA"];
if(st == YES){ [buttonA setState:NSOnState]; }
else if(st == NO){ [buttonA setState:NSOffState]; }
st = [prefs boolForKey:@"optionB"];
if(st == YES){ [buttonB setState:NSOnState]; }
else if(st == NO){ [buttonB setState:NSOffState]; }
st = [prefs boolForKey:@"optionC"];
if(st == YES){ [buttonC setState:NSOnState]; }
else if(st == NO){ [buttonC setState:NSOffState]; }
st = [prefs boolForKey:@"optionD"];
if(st == YES){ [buttonD setState:NSOnState]; }
else if(st == NO){ [buttonD setState:NSOffState]; }
}
The code is exactly the same. I checked the connections in the interface
builder twice.
There is no problem with getting the NSUserDefaults values.
But still, only the state of button A and B change according to the st-value.
On button B and C setState: seems to have no effect at all.
Whatever I send to buttonB and buttonC nothing changes the appearance of this
buttons in the window.
The code is identical.
There is nothing wrong with the plist and I don`t see any differences in the
connections in the IBuilder...
When I debug this code I see that buttonA and buttonB have an address.
But buttonC and buttonD seems to have no address (0x0) ...
what could possibly be the problem here ...?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
