I'm getting the following error whenever I compile my code: "Error 029: Invalid expression, assumed zero"
The error is thrown on the following line:
if ((PlayerInfo[playerid][ADMINLevel])) || (IsPlayerAdmin(playerid))
I want the if-statement to check if "ADMINLevel" is above zero or if the player is logged in as an RCON admin.
You're constructing your if-statement wrong. The correct way to do it is
if(PlayerInfo[playerid][ADMINLevel] > 0 || IsPlayerAdmin(playerid))
{
/* Put your desired script here */
}
Your code was nearly correct (although it did have some unnecessary brackets), you just need to actually add a comparison to the ADMINLevel check. An if-statement should be like a question ("is admin level more than 0", rather than just "is admin level"). You can find more information about if-statements in Pawn here, and I think it will be useful for you to read.
PlayerInfo[..][..] does not return a boolean. Add > 0 to fix it
Related
this is my first post in this site.
As the title says, I encountered a bug in an If - else if - else block of codes.
What the problem is that, I am pretty confident that I have covered all 9 possible outcomes that there should be.
It is quite hard to explain more, so if you guys could take a look at my .cpp file and run it ( hopefully it runs because I used c++ on a mac), you may find an easier understanding of my problem.
source code cpp file
If you browse through my action();, in the else statement, I purposely displayed that you encountered a bug so just in case there were bugs, I'd be informed.
What I am trying to do is like this:
userinput | randomAImove | outcome
A 1 statement
A 2 statement
A 3 statement
D 1 statement
D 2 statement
D 3 statement
W 1 statement
W 2 statement
W 3 statement
else 1||2||3 statement
There are corresponding statements to each conditions met.
'A', 'W', 'D' are user input. I used a toupper command to force the compiler to just check on 'A' 'W' 'D'. However, the main problem I find is that, even if the toupper works(which I confirmed), the program displays the correct statement often but still somehow manages to bug even if the user(I tried it) input from A, W, D (not-case sensitive cuz of toupper).
Please just try it and after a few tries you may encounter it also. I wrote "you encountered a bug" if you ever do encounter it.
Please help me because I can't really see any other way to find the mistake. Maybe its in my plain sight but I can't seem to notice which one is it.
Thank you!
Change the AImove function to
void AImove()
{
turn = rand () % 3 + 1;
}
(add + 1), or you may get 0 in turn and it will lead you "encounter a bug".
I want to create statement such as
=IIf(IsNothing(Fields!Amount.Value)),0,(Sum(Fields!Amount.Value)/1)
but from some reason it does not work. It should check value if it is null. If it's null, just enter 0, if it is not null, just make the calculation.
What am I doing wrong here? I am getting error for the first part of "IsNothing" code which says "Wrong number of arguments" but I do not see the error.
Found it.
=IIf((IsNothing(Fields!Amount.Value)),0,(Sum(Fields!Amount.Value)/1))
Just missed brackets.
I have the following method in C++:
In case the folder already exists, the correct message is displayed on the screen. However, if the folder does NOT exist, nothing is displayed on the screen, that is, the part identified by case NULL is not executed. How can I solve this problem?
In other words, how can I get the code after the case NULL to run if the folder does not exist?
First, if the folder does not exist, CreateDirectory() will probably succeed and return a non-zero value, so the if condition will return false and you will never get to the switch statement.
Second, GetLastError() does as advertised: it returns the last error. If CreateDirectory() does not raise an error, it will return whatever was the last error set by any other function. Checking for NULL is not very useful.
The spec say that as long as CreateDirectory succeeds, the return value is nonzero.
CreateDirectory
So why don't you use an else to the if clause to print that
At max you can use a default in your switch to print
"There was some error".
Since the switch only executes in case of an error
So I have this simple code snippet:
CString str;
..................
if ( str.IsEmpty() )
str = spRelease->GetID();
I want to put a conditional breakpoint on the last line to test if str is empty.
I tried this first:
str == ""
But I get this:
Error overloaded operator not found
Then this:
str.isEmpty() == 0
And get this:
Symbol isEMpty() not found
Any idee how this could be done ? Any workaround ?
Thanks.
Why don't you just put a normal breakpoint on the last line? You already know str is empty. If you want to double check whether your string is empty, I would use an ASSERT instead.
If you really have to check your string, you have to check m_pszData in your CString, so your condition looks like this:
str.m_pszData[0] == '\0'
In Visual Studio 6 you have the operation IsEmpty(), note that the first 'I' is uppercase. You also have the Compare() operation. Which version of VS are you using?
One pattern that I've seen for things like this is to add a bit of code like this:
if (some_condition) {
int breakpoint=rand();
}
This generates a warning about breakpoint being initialized but not used so it is easy to remember to take it back out. This also allows you test any condition you want, including invoking functions or anything else, without having to worry about restructions of the debugger. This also avoids the limit on the number of conditional breakpoints you can have that some debuggers have.
The obvious downsides are that you can't add one during a debug session, recompiling, remembering to take them out, etc.
linux gcc 4.4.1 C99
I am just wondering is there any advantage using the following techniques. I noticed with some code I was reading the exit number went up in value, as displayed in this code snippet.
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
exit(1);
}
if(test condition 2)
{
/* something went wrong with another condition*/
exit(2);
}
or doing the following and just returning:
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
return;
}
if(test condition 2)
{
/* something went wrong with another condition*/
return;
}
exit() exits your entire program, and reports back the argument you pass it. This allows any programs that are running your program to figure out why it exited incorrectly. (1 could mean failure to connect to a database, 2 could mean unexpected arguments, etc).
Return only returns out of the current function you're in, not the entire program.
return will basically return from the function and adjust the stack pointers appropriately to execute the next instructions, where as exit will cause the program itself to terminate.
using exit() in a function indicates the fatal error and program cannot recover and continue and hence, it has to be terminated.
exit will not return from a function. It will exit from the entire program
I don't think you want to exit the entire program, right?
So just returning from the function would be fine.
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
return; /*return type must be void in this case */
}
if(test condition 2)
{
/* something went wrong with another condition*/
return; /*return type must be void in this case */
}
You can also explicitly specify the return type of the function and use the return value to judge whether everything went fine or not.
You're asking us whether you should return error codes from your functions?
Well that depends upon how informative you want to be to your users. If you want to act like software usually acts and pop up a modal dialog that says
Something bad happened!
Then there's no need for return codes.
If, however, you want to your software to be useful to your users and let them know what happened, then you better provide some kind of diagnostic information (error codes in the least). Then you can pop up a message that says:
I can't open "foo.bar".
Does this file exist? Do you have read access to it? Is it on a network share? Maybe I should try again?
Usually this is so that the program running your program can take some intelligent decisions.
For example if there is a wrapper script around your program foo, then it could check the
exit argument using variable $$ and change the execution path:
exec foo
if $$ eq '0':
echo "Success"
elif $$ eq '2':
exec error-recovery-script
Alternatively, you yourself can execute echo $$ to see what was the exit code from the program.
If the idea is to return the value based on the test condition, prefer using return instead of exit.
To return 1, instead of exit(1), use return 1.
Not posting the reasons, as there was a detailed discussion for the same in this link.