Jump to content
Sign in to follow this  
iagman

numbers are really strings?

Recommended Posts

iagman

I am confused as to how AutoIt handles numbers entered into input controls.

My GUI accepts two numeric values. One control accepts dollars, sometimes with a decimal, sometimes maybe just a whole number. The second control is always a dollar amount with a decimal since it will be less that $1.00.

These two values are then used to calculate many other values. All this has gone well and all computations are performing error free.

But today, I began adding code to intercept entered values that are outside certain limits. This is when the confusion began.

It was caused when I discovered my entered numbers are not numbers at all, but are actually strings. I confirmed this by IsString. And, because of this, my entered values are not being tested properly to see if they are within limits.

For example, I can enter values such as 100, 100.0, or 100.00. These are accepted and used for computation. However, if I enter 100. (decimal after last zero) then my code fails the <10 test below.

While 1
     $msg = GUIGetMsg()
     
     $GI = GUICtrlRead (22)

     Select             
Case $msg = $CalculateButton ;Button: Calculate
If $GI < 10 Then
    MsgBox(32, "Check Entry", "Invalid Entry" & @LF & "Enter new number", 5)
    .more code.
;

Any number entered that ends in a decimal will trigger the message box because AutoIt thinks the value is less than 10. It thinks 100.00 is more than 10, but not 100. (decimal after the last zero). This seems screwy to me.

I thought I had been testing my code using actual numbers, not strings.

Also, if this is AutoIt way of doing thing, why would it do calculation with strings in some cases but not in others.

Will someone please set me on the right path so I can complete this project?

Heres a pic (some blanked out names). I was getting really proud of my first dialog box and up until today, thought progress was slow but steady. Now, I realize I must be missing something fundamental with this language.

iagman

post-47614-1238786791_thumb.jpg

Share this post


Link to post
Share on other sites
martin

I am confused as to how AutoIt handles numbers entered into input controls.

My GUI accepts two numeric values. One control accepts dollars, sometimes with a decimal, sometimes maybe just a whole number. The second control is always a dollar amount with a decimal since it will be less that $1.00.

These two values are then used to calculate many other values. All this has gone well and all computations are performing error free.

But today, I began adding code to intercept entered values that are outside certain limits. This is when the confusion began.

It was caused when I discovered my entered "numbers" are not numbers at all, but are actually strings. I confirmed this by IsString. And, because of this, my entered values are not being tested properly to see if they are within limits.

For example, I can enter values such as 100, 100.0, or 100.00. These are accepted and used for computation. However, if I enter 100. (decimal after last zero) then my code fails the <10 test below.

While 1
      $msg = GUIGetMsg()
      
      $GI = GUICtrlRead (22)
 
      Select                
 Case $msg = $CalculateButton;Button: Calculate
 If $GI < 10 Then
     MsgBox(32, "Check Entry", "Invalid Entry" & @LF & "Enter new number", 5)
     .more code.
;

Any number entered that ends in a decimal will trigger the message box because AutoIt thinks the value is less than 10. It thinks 100.00 is more than 10, but not 100. (decimal after the last zero). This seems screwy to me.

I thought I had been testing my code using actual numbers, not strings.

Also, if this is AutoIt way of doing thing, why would it do calculation with strings in some cases but not in others.

Will someone please set me on the right path so I can complete this project?

Here's a pic (some blanked out names). I was getting really proud of my first dialog box and up until today, thought progress was slow but steady. Now, I realize I must be missing something fundamental with this language.

iagman

post-47614-1238786791_thumb.jpg

Maybe this helps.

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.

Share this post


Link to post
Share on other sites
iagman

Yes, I think you are right. This is likely the problem. This is a quote from your link: "A variant can contain numeric or string data and decides how to use the data depending on the situation it is being used in." Well, obviously in my case it has decided incorrectly. This mean this language has a fault at its core; the reliable use of variables.

So, what is the solution? Is there a way to force AutoIt to read an input as a number only instead of falsely deciding what my intentions are? Looking through the Help, I don't readily find a simple solution.

Might I be forced to do string manipulations that check for a decimal in the last position of an entered value, then removing it or perhaps adding a zero? Seems a bit clunky for something that should not be a problem in the first place.

I can see how this variant idea can be good and bad. Good when it works; bad when it doesn't. Overall, I think it's generally undesirable when software thinks it knows what you want to do better than yourself. Software hasn't gotten that smart yet.

iagman

Share this post


Link to post
Share on other sites
SmOke_N

Yes, I think you are right. This is likely the problem. This is a quote from your link: "A variant can contain numeric or string data and decides how to use the data depending on the situation it is being used in." Well, obviously in my case it has decided incorrectly. This mean this language has a fault at its core; the reliable use of variables.

So, what is the solution? Is there a way to force AutoIt to read an input as a number only instead of falsely deciding what my intentions are? Looking through the Help, I don't readily find a simple solution.

Might I be forced to do string manipulations that check for a decimal in the last position of an entered value, then removing it or perhaps adding a zero? Seems a bit clunky for something that should not be a problem in the first place.

I can see how this variant idea can be good and bad. Good when it works; bad when it doesn't. Overall, I think it's generally undesirable when software thinks it knows what you want to do better than yourself. Software hasn't gotten that smart yet.

iagman

I think saying has a fault at its core is rather presumptuous.

It's up to the coder to decide on how to data type their own variables, especially since AutoIt is a variant/typless language. There may be underlying code that helps the novice coder overcome the simplest of issues, but it's still that coders responsibility.

There are functions such as Number()/Int()/String() to force type your variables.

Edit:

Oh, and software is typically smarter than the person using it :D ...

Edited by SmOke_N

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites
iagman

Yes, I discovered the Number() after my last post and that solved my problem. I just love making discoveries like that when the light bulb goes off over your head.

<Oh, and software is typically smarter than the person using it >

That's certainly true for someone new to this scripting like me.

Now that I see how I can control my variable types, I'm a happy camper.

iagman

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  

×