Jump to content
Sign in to follow this  
JasonDW

Use of Default

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. ;]

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 by Skruge

[font="Tahoma"]"Tougher than the toughies and smarter than the smarties"[/font]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Valik

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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 by TerarinK

0x576520616C6C206469652C206C697665206C69666520617320696620796F75207765726520696E20746865206C617374207365636F6E642E

Share this post


Link to post
Share on other sites
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 by Valik
Typo.

Share this post


Link to post
Share on other sites
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. :D

Share this post


Link to post
Share on other sites
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?


Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]

Share this post


Link to post
Share on other sites
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 by Spiff59

Share this post


Link to post
Share on other sites
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.

:D

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


Post your code because code says more then your words can. SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y. Use Opt("MustDeclareVars", 1)[topic="84960"]Brett F's Learning To Script with AutoIt V3[/topic][topic="21048"]Valuater's AutoIt 1-2-3, Class... is now in Session[/topic]Contribution: [topic="87994"]Get SVN Rev Number[/topic], [topic="93527"]Control Handle under mouse[/topic], [topic="91966"]A Presentation using AutoIt[/topic], [topic="112756"]Log ConsoleWrite output in Scite[/topic]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.