Use of Default

[JasonDW]

Am I doing something wrong or is this a bug?

I am trying to use the Default keyword when calling a UDF. Obviously I want to test each input to see if it is equal to "Default" and if so process accordingly.

If an input is set to false the "IF $VAR = DEFAULT" still comes out true.... that doesn't seem right.

In the example below I would have expected to see only 1 msgbox....instead I get 2.

CODE

Dim $f

$f = Default

If $f = Default Then MsgBox(0,"",$f)

$f = False

If $f = Default Then MsgBox(0,"",$f)

$f = True

If $f = Default Then MsgBox(0,"",$f)

The obvious work around is

CODE

Dim $f

$f = Default

If $f = Default Then MsgBox(0,"",$f)

$f = False

If $f = Default And $f <> False Then MsgBox(0,"",$f)

$f = True

If $f = Default Then MsgBox(0,"",$f)

I just wanted to check if I was doing something stupid or if I just need to use the workaround?

Thanks in advance

Jason

[BrettF]

Check this out. Hope it explains itself.

_Func ("Number 1", Default, Default)
_Func ("Number 2", 3, Default)
_Func ("Number 3", Default, 4)
_Func ("Number 4", 6, 5)

Func _Func ($name, $var = 1, $var2 = 2)
    If IsKeyword ($var) Then MsgBox (0, $name, "Var is = 1")
    If IsKeyword ($var2) Then MsgBox (0, $name, "Var2 is = 2")
EndFunc

Cheers,

Brett

[Authenticity]

I don't think this is the case here. The case is that he wants to write a function that checks if the argument passed with the Default keyword but False trigger it too, this may be problem because of flag arguments. I guess that it's required to check also - If $Var1 = Default And $Var1 <> False Then ... but i doesn't solve the flag variables issue. In my opinion at least. ;]

[Ascend4nt]

CODE

Dim $f

$f = Default

If $f = Default Then MsgBox(0,"",$f)

$f = False

If $f = Default Then MsgBox(0,"",$f)

$f = True

If $f = Default Then MsgBox(0,"",$f)

Very interesting. I'd say that's a bug, as logical tests in AutoIt are supposed to be different than assignments. My practice has always been to use '==' for logical tests, and when I applied it to your code, I got the appropriate response - only one MsgBox showed up:

CODE

Dim $f

$f = Default

If $f == Default Then MsgBox(0,"",$f)

$f = False

If $f == Default Then MsgBox(0,"",$f)

$f = True

If $f == Default Then MsgBox(0,"",$f)

[JasonDW]

Thanks ascendant... I will use the '=='.

Interestingly enough it doesn't actually assign 'Default' to the variable (proven since the second msgbox still shows False)....it just seems to think the Default = False.

Should I list this as a bug? If so, how do I do that?

[Skruge]

Interestingly enough it doesn't actually assign 'Default' to the variable (proven since the second msgbox still shows False)....it just seems to think the Default = False.

Should I list this as a bug? If so, how do I do that?

This is not a bug. Please read the help file.

This keyword should not be used in computation expression. AutoIt will not detect such situation because it's too much performance penalty.

When used as a parameter passing the behavior is specify in the corresponding AutoIt doc function.

For UDF it is the scripter responsabitly to check is the parameter has been set to Default keyword and to do the behavior he wants.

The passed parameter will be set to Default keyword not to and optional parameter value if defined.

The help file also lists IsKeyword() as a related function... Use that to detect Default and assign whatever value you want it to represent, as Brett showed.

Note that Default behaves differently than simply omitting a value.

Expanding on Brett's example, if you add the call:

_Func ("Number 5", 6)

No messageboxes will be displayed because $var2 will equal 2, not Default.

@Edit: Hit submit prematurely. =(

Edited March 31, 2009 by Skruge

[Ascend4nt]

hmm, I think I understand now. Don't quite understand why assigning it to a variable gives the results it does, but as the Help file says, it's for calling functions. oops.

[JasonDW]

Thanks Skruge and Brett.... Will use IsKeyword instead...

Incidentally I read the help file but couldn't quite understand it. Thanks for the explanation.

[Valik]

You should not be using == for equality tests unless you really want to compare strings. You're incurring unnecessary performance penalties for doing so.

Now then, this does seem like a bug to me. Default should never compare true to a boolean, neither true nor false. Default should only compare true to -1, "" and Default itself.

[Valik]

I've created #885 for this issue.

[Valik]

Sigh, it appears Default doesn't work at all how I wanted it to.

[JasonDW]

I've created #885 for this issue.

Thanks Valik...I'm just glad it wasn't something I was doing wrong...at least I have a couple of workarounds for now.

[Ascend4nt]

You should not be using == for equality tests unless you really want to compare strings. You're incurring unnecessary performance penalties for doing so.

Is there really a performance penalty for using == ? I didn't see any notes about this in the Help file, but I was surprised that it affects the case sensitivity of string compares. That's an unusual feature.

The reason I've coded with '==' in my logic tests is because I'm used to using that from past experience with other languages. It also makes it clear that you want to test something as opposed to assign it to another variable, plus it helps sometimes in initial debugging stages.

So what kind of performance penalty are we talking here? I guess I could write a test example up, but I just wanted to know what it is that chews up the additional time.

Thanks!

[TerarinK]

Default = Default regardless to if it is Default|default. However the help in operations never refers to only strings which this clearly does. Which is why I think he put it onto the BUG topic, either your should put in a Boolean and a Int for the == else put it in the help file that == should only be for a String. Yes, I know I said String and not String|Int because it is convert the numbers to string so basically like == is equal to String() == String().

I would say to put in the help file because = should be what everyone except for case sensation script

Re-edited

As I got into thinking about this I just looked up the Default keyword, I think that will say where your performance penalty are

Edited March 31, 2009 by TerarinK

[Valik]

I thought it was more clearly documented that the operator == forces a string comparison. In fact, the documentation was so vague I actually had to look at the source to make sure it really was a forced string comparison - and it is. Tomorrow I'll fix the documentation to better explain that the operator == is a forced case sensitive string comparison. I've created #886 for that.

Edited March 31, 2009 by Valik
Typo.

[Ascend4nt]

Doh. Well that would explain the performance penalty. Dang, two tickets from one thread. Let's not mention anything else for fear that something else will creep up.

[bo8ster]

You should not be using == for equality tests unless you really want to compare strings. You're incurring unnecessary performance penalties for doing so.

Now then, this does seem like a bug to me. Default should never compare true to a boolean, neither true nor false. Default should only compare true to -1, "" and Default itself.

Thanks for the information this is good to know.

Quick question, if performance is not a factor, can "==" be used with other data types to correctly test equality?

[Spiff59]

Hurrah!

I'd argued that the =/== operators documentation needed clarification twice already this year:

Feature request (documentation)? (I started this thread)

Value of 0 = "" ? (I only replied to this thread)

The difference between = and == when dealing with empty strings, strings containing NUL characters, and 'numeric' 0 is very useful. Having the "Operators" page of the help file stating that the only difference between them is case-sensitivity, is a huge omission. This help file update will probably cut the number of times in the future this question is asked in a forum in half.

Edit: The fact that compares between $x = "", $y = Chr(0), and $z = 0 all test as equal with =, and all test as false with ==, should be explained.

Edited April 9, 2009 by Spiff59

[bo8ster]

Thankyou for the feedback and the links. I am more of a technical programmer so I can understand where you are coming from but reviewing a number of threads I believe PsaltyDS puts it the best when giving the intent of AutoIt.

Before you make bloody forehead prints on the wall, think about where this comes from.

AutoIt is meant to be an easy to use scripting language for people (like me) who are not "real" programmers. So the Devs have spent much effort keeping you from having to worry about one of the central headaches of "real" programming: strict variable typing.

In many (most!) languages, what you did will actually fail to compile or run at all or crash the executable because you compared an integer type to a string type without converting to matching types first. AutoIt tries to keep you from worrying too much about variable types by performing automated type conversions. You are seeing a (documented, if you look for it) side effect of that automatic type conversion in AutoIt.

I see that Valik has updated the documentation here so it is getting done.

I thought it was more clearly documented that the operator == forces a string comparison. In fact, the documentation was so vague I actually had to look at the source to make sure it really was a forced string comparison - and it is. Tomorrow I'll fix the documentation to better explain that the operator == is a forced case sensitive string comparison. I've created #886 for that.

I have found you can spend 6 months on documentation and it still require work. I look forward to the next version of the help file.

Thanks

Bo8ster