When using NSEvent flagsChanged and ANDing the flags with various KeyMasks, how can you test themin an exclusive way?
Currently, using a series of if else conditions whit the pattern:
if ((flags & someKeyMask) && (flags someOtherKeyMask))
This will match even if a third modifier key is down.
Putting longer series of key masks earlier in the if else conditionals makes the behavior work as desired, but feels incomplete somehow. Is the a good way to say "only these modifier keys, not any others"?
Here is a more specific example where the first one matches before the others. I'm wondering if there is a way to add some logic to each one that says "only these modifier keys".
if ((flags & (NSCommandKeyMask|NSControlKeyMask))) {
NSLog(#"one");
}else if (((flags & NSCommandKeyMask) && (flags & NSAlternateKeyMask)) && (flags & NSControlKeyMask)) {
NSLog(#"Command+Option+Control ");
} else if ((flags & NSCommandKeyMask) && (flags & NSShiftKeyMask)) {
NSLog(#"Command+Shift ");
} else if ((flags & NSCommandKeyMask) && (flags & NSControlKeyMask)) {
NSLog(#"Command+Control");
} else if ((flags & NSCommandKeyMask) && (flags & NSAlternateKeyMask)) {
NSLog(#"Command+Option ");
}
So the correct pattern I was looking for, as provided by Ken Thomases is:
flags &= (<one or more masks bitwise OR'd together);
if (flags == (<one or more masks bitwise OR'd together)) { // do something }
This gives exclusive matching.
First, you need to be aware that the value returned from -modifierFlags includes some flags which do not exactly correspond to keys. You should construct a mask which includes all of the flags that you care about (whether you care that they are pressed or not pressed). Pass the flags value through that mask and then compare the result with exactly the combination you want.
For example, if you care about Command, Option, Shift, and Control, and you want to know if exactly Command and Shift are down but the others are not, you could use:
if ((flags & (NSShiftKeyMask|NSControlKeyMask|NSAlternateKeyMask|NSCommandKeyMask)) == (NSShiftKeyMask|NSCommandKeyMask))
// do something
Update: Here's how to check a variety of combinations:
flags &= NSShiftKeyMask|NSControlKeyMask|NSAlternateKeyMask|NSCommandKeyMask;
if (flags == (NSControlKeyMask|NSAlternateKeyMask|NSCommandKeyMask))
NSLogs(#"Command+Option+Control");
else if (flags == (NSShiftKeyMask|NSCommandKeyMask))
NSLog(#"Command+Shift ");
else if (flags == (NSControlKeyMask|NSCommandKeyMask))
NSLog(#"Command+Control");
else if (flags == (NSAlternateKeyMask|NSCommandKeyMask))
NSLog(#"Command+Option ");
In order to catch just the combination pressed, you need to use the switch/break construction:
switch (flags) {
case (NSControlKeyMask|NSAlternateKeyMask|NSCommandKeyMask):
[keystrokes appendString:#"cmd-alt-ctrl-"];
break;
case (NSShiftKeyMask|NSCommandKeyMask):
[keystrokes appendString:#"cmd-shift-"];
break;
case (NSControlKeyMask|NSCommandKeyMask):
[keystrokes appendString:#"cmd-ctrl-"];
break;
case (NSAlternateKeyMask|NSCommandKeyMask):
[keystrokes appendString:#"cmd-alt-"];
break;
default:
break;
}
Related
I'm trying to use a variable as the case match, however I get "Expression is not an integer in Objective-C.
Is it possible to use variable in switches in this manner?
int count = [array count];
switch ([number to check]) {
case 0:
//first statement
break;
case 1 ... (count -1):
//somewhere between 1 and the next to last statement
//Basically the middle
break;
case count:
//Last statement
default:
break;
}
Objective-C (and C) switch only supports a single primitive constant value for each case statement (or a range as pointed out in the answer by TwoStraws). You would be much better off writing your code using if/else:
if ([number to check] == 0) {
} else if ([number to check] >= 1 && [number to check] < count) {
} else if ([number to check] == count) {
} else {
}
Objective-C's switch statement does support ranges of values as you've seen, but doesn't support variable matches I'm afraid.
So, the below code is valid because I've used exact integers:
int numberOfKittens = 12;
NSString *kittenDescription;
switch (numberOfKittens) {
case 0 ... 5:
kittenDescription = #"Need more kittens";
break;
case 6 ... 10:
kittenDescription = #"That's a good number of kittens.";
break;
case 11 ... 20:
kittenDescription = #"Are you sure you can handle that many kittens?";
break;
default:
kittenDescription = #"You must really love kittens!";
}
…but trying to put a variable in place of any of those will fail.
If this is something you desperately want, consider using Swift because it has a much more expressive switch matching system. Here's that same code in Swift, now with a variable being used to match a case:
let upperLimit = 20
let numberOfKittens = 19
var kittenDescription = ""
switch (numberOfKittens) {
case 0 ... 5:
kittenDescription = "Need more kittens"
case 6 ... 10:
kittenDescription = "That's a good number of kittens."
case 11 ... upperLimit:
kittenDescription = "Are you sure you can handle that many kittens?"
default:
kittenDescription = "You must really love kittens!"
}
If I use this:
if(value & 4) to check if the bit is set, then how do I check if the bit isn't set?
I tried with
if(!value & 4) or if(~value & 4) and if(value ^ 4) but none of them works.
When you write if(value & 4), C checks the result to be non-zero. Essentially, it means
if((value & 4) != 0) {
...
}
Therefore, if you would like to check that the bit is not set, compare the result for equality to zero:
if((value & 4) == 0) {
...
}
You could do it many ways, but the easiest (easiest as in requires the least amount of thought) would be just negate the entire expression you already have:
if (!(value & 4))
Simply:
if ((value & 4) == 0)
Why?
If value is 01110011
Then
01110011
&
00000100
--------
Will return 0 because 4th bit is off.
the line from hastebin is poorly written, has unreachable code and depends heavily on the Precedence of the C operators. And doesn't work as expected.
The line from hastebin:
if( cur_w > source.xpos + source.width
&&
!(source.attributes & DBOX_HAS_SHADOW) )
{
break;
return;
}
it should be written as:
if( (cur_w > (source.xpos + source.width)) // has curr_w exceeded sum of two other fields?
&&
((source.attributes & DBOX_HAS_SHADOW) != DBOX_HAS_SHADOW ) //is bit == 0?
{
break;
}
Wondering if there is a way to shorthand these conditionals. I am working with data packets and the conditionals get a bit unwieldy at times. Here's a basic example:
I write:
if (message->messageType != kMessageTypeCutCardsArray && message->messageType != kMessageTypeQuit) {
MessageInt message;
message.message.messageType = kMessageTypeReceivedData;
NSData *packet = [NSData dataWithBytes:&message length:sizeof(message)];
[_game sendData:packet];
}
I would rather write:
if (message->messageType != (kMessageTypeCutCardsArray || kMessageTypeQuit)) {
MessageInt message;
message.message.messageType = kMessageTypeReceivedData;
NSData *packet = [NSData dataWithBytes:&message length:sizeof(message)];
[_game sendData:packet];
}
As a general matter, no. That's just the way that C (and hence Objective-C) works.
In this specific case, you could use a switch statement:
switch (message->messageType)
{
case kMessageTypeCutCardsArray:
case kMessageTypeQuit:
break;
default:
MessageInt message;
message.message.messageType = kMessageTypeReceivedData;
NSData *packet = [NSData dataWithBytes:&message length:sizeof(message)];
[_game sendData:packet];
break;
}
Whether that syntax is an improvement is up to you.
If you define your enum such that the values have mutually-exclusive bit patterns, like so:
typedef enum : NSUInteger {
kMessageTypeLoveLetter = 1 << 0,
kMessageTypeBirthdayCard = 1 << 1,
kMessageTypeVacationPostcard = 1 << 2,
kMessageTypeCreditApplication = 1 << 3,
kMessageTypeCharitySolicitation = 1 << 4
} MessageType;
You can then test for multiple values at once, using binary OR | and binary AND &:
MessageType msgType = kMessageTypeCreditApplication;
if( !(msgType & (kMessageTypeLoveLetter | kMessageTypeBirthdayCard)) ){
// Nobody loves you.
}
if( (msgType & (kMessageTypeCreditApplication | kMessageTypeCharitySolicitation) ){
// Someone wants your money.
}
This won't work, however, if you use the compiler-generated consecutive values for the enum, because the values will overlap as flags -- e.g., both 2 and 3 have the lowest bit set -- and ORing them together will often end up testing only one of the flags.
You could box the values and use a temporary array. This achieves the goal of removing the duplication in the conditional, but is unlikely to be as optimizable for the compiler.
if (message->messageType != kMessageTypeCutCardsArray &&
message->messageType != kMessageTypeQuit) {
should be equivalent to:
if(![#[#(kMessageTypeCutCardsArray),#(kMessageTypeQuit)]
contains:#(message->messageType)]) {
int side1test;
NSLog(#"Is your triangle setup as in an Angle-Side-Angle? (Use 1 for Yes and 0 for No.)");
scanf(" %i", &side1test);
Returns "0" when the user enters a "y." However,
if (side1test != 1 && side1test != 0){
NSLog(#"Please use a '1' for YES and '0' for NO.");
}
Then does not catch.
The program drops into my else clause, and outputs all the NSLogs, skipping the scanf() commands, taking each of them as "0." What is wrong here?
I'm not a c++ dev but from googling that function returns the number of valid matches. If it returns 0 you should assume invalid input. side1test has not been set which is why it's 0.
Your code should probably be:--
int side1test;
NSLog(#"Is your triangle setup as in an Angle-Side-Angle? (Use 1 for Yes and 0 for No.)");
int result = 0;
while (result==0)
{
result =scanf(" %i", &side1test);
}
if (side1test != 1 && side1test != 0){
NSLog(#"Please use a '1' for YES and '0' for NO.");
}
I've responded to threads here (or at least commented) with answers containing code like this, but I'm wondering if it's good or bad form to write a series of if branches with one (or more) of the branches doing nothing in them, generally to eliminate checking for null in every branch.
An example (C# code):
if (str == null) { /* Do nothing */ }
else if (str == "SomeSpecialValue")
{
// ...
}
else if (str.Length > 1)
{
// ...
}
instead of:
if (str != null && str == "SomeSpecialValue")
{
// ...
}
else if (str != null && str.Length > 1)
{
// ...
}
And, of course, this is just an example, as I tend to use these with larger and more complex classes. And in most of these cases, a null value would indicate to do nothing.
For me, this reduces the complication of my code and makes sense when I see it. So, is this good or bad form (a code smell, even)?
I prefer doing it like this-
if (str != null)
{
if (str == "[NULL]")
{
// ...
}
else if (str.Length > 1)
{
// ...
}
}
I think you can always "reword" an if with an empty body into it's negation with a body, and that it looks better and makes more sense.
I would normally put a return or something like that in the first if:
void Foo()
{
if (str == null) { return; }
if (str == "SomeSpecialValue")
{
// ...
}
else if (str.Length > 1)
{
// ...
}
}
If you can't do this, because the function does something else after the if/else, I'd say it's time to refactor, and split the if/else part out into a separate function, from which you can return early.
It is indeed good to avoid the following, because it needlessly re-checks one of the conditions (the fact that the compiler will optimize this away is beside the point--it potentially makes more work for folks trying to read your code):
if (str != null && str == "SomeSpecialValue")
{
// ...
}
else if (str != null && str.Length > 1)
{
// ...
}
But it's also rather bizarre to do what you suggested, below:
if (str == null) { /* Do nothing */ }
else if (str == "SomeSpecialValue")
{
// ...
}
else if (str.Length > 1)
{
// ...
}
I say this is bizarre because it obfuscates your intent and defies the reader's expectations. If you check for a condition, people expect you to do something if it is satisfied--but you're not. This is because your intent is not to actually process the null condition, but rather to avoid a null pointer when you check the two conditions you're actually interested in. In effect, rather than having two conceptual states to handle, with a sanity provision (non-null input), it reads instead like you have three conceptual states to handle. The fact that, computationally, you could say there are three such states is beside the point--it's less clear.
The usual case approach in this sort of situation is as Oren A suggested--check for the null, and then check the other conditions within the result block:
if (str != null)
{
if (str == "SomeSpecialValue")
{
// ...
}
else if (str.Length > 1)
{
// ...
}
}
This is little more than a matter of readability-enhancing style, as opposed to an issue of code smell.
EDIT: However, if you're set on the do-nothing condition, I do very much like that you included a "do nothing" comment. Otherwise, folks might think you simply forgot to complete the code.
In this particular case I will return early and it makes code easier to read
if (string.IsNullOrEmpty(str)) { return; }
I like to put an explicit return statement.
Yes it is a code smell.
One indication is that you thought to ask this question.
Another indication is that the code looks incomplete- as if something should belong there. It may be readable sure, but it feels off.
When reading that code, an outsider has to stop for a second and use brainpower to determine if the code is valid/complete/correct/as intended/adjective.
user359996 hit the nail on the head:
I say this is bizarre because it obfuscates your intent and defies the reader's expectations.
Your first example is perfectly readable to me -- doesn't smell at all.
It all depends on context. If putting an empty if statement makes the code more readable, then go for that.
It's readable, whether it is good or bad depends upon what you are trying to achieve - generally long nested "goes-on-forever" type if statements are bad. Don't forget about static string methods baked into the framework: string.IsNullOrEmpty() and string.IsNullOrWhiteSpace().
Your if (str == null) { /* Do nothing */ } line is unusual, but does have one positive point: it is letting other developers know up front that you are deliberately doing nothing for that case, with your long if/else if structure your intentions could become unclear if you changed it to
if (str != null)
{
/* carry on with the rest of the tests */
}