1) Yeh, and there was no problem with the compound conditions before 6.33, hence the error report.
2) I use the extra parenthesis to give my code clarity and readability, rather than the disgusting forms some people use that are:
if con1 || cont || con3 doing stuff
Which can get people lost if you start placing multiple if's on a line, or the doing stuff and condn look similar, etc etc... you get the idea. Either way I see that poor ethics in code a ton because mIRC allows it for some godforsaken reason. I know mIRC isn't something to be used in a real programming project; but it's still usable as a foundation for users to learn how to work with a simple language and mostly well documented coding language. Just would make more sense if it also enforced at least some proper coding practices such as enclosing your entire if conditionals in parens.
3) Mirc actually does give operator priorities correctly, but it seems to lose that once parens are invovled when it didn't used to have this problem. If you test the following two lines, which should be completely different.. they are as such.
if ($true || $false) && $false return $true
if $true || $false && $false return $true
The first will give the OR's priority since they're grouped, and then add in the AND. This allows for a false overall statement and so true is not returned.
The second one will perform the AND first, get a $false out of it resulting in "$true || $false" which is still true and thus means the operator priority is still maintained. As such $true is now returned.
When the entire line is grouped is when the funny things start to happen, and that is what I demonstrated in my first posting.
So to put it in these same terms now that you've seen how it works ungrouped..
if (($true || $false) && $false) return $true
Will happily sit by and return $true, despite the statement being false as the ungrouped version specified correctly. This means that somewhere along the parsing of the additional parens, which actually would not change any of the priorities and simply acts as an encapsulator of the entire if line, the internal paren parsing is gone and no longer applies (as I demonstarted in (3) above with the excessive parens.
Hope that makes it clearer!
