easier way to adress varibles with eval?

Allow2010 · August 29, 2015

GUICtrlSetData($field1, "")
    GUICtrlSetData($field2, "")
    GUICtrlSetData($field3, "")
    GUICtrlSetData($field4, "")
    GUICtrlSetData($field5, "")
    GUICtrlSetData($field6, "")
    GUICtrlSetData($field7, "")
    GUICtrlSetData($field8, "")
    GUICtrlSetData($field9, "")
    GUICtrlSetData($field10, "")
    GUICtrlSetData($field11, "")
    GUICtrlSetData($field12, "")
    GUICtrlSetData($field13, "")
    GUICtrlSetData($field14, "")
    GUICtrlSetData($field15, "")
    GUICtrlSetData($field16, "")
    GUICtrlSetData($field17, "")
    GUICtrlSetData($field18, "")
    GUICtrlSetData($field19, "")
    GUICtrlSetData($field20, "")

I would like to do this with a loop and i thing it should be possible using eval(), but i could not manage this...can someone show me an example please?

Thanks!

guinness · August 29, 2015

Er...heard of an array?

Edit: Read the Eval doc, because it clearly states that Eval should be used with variables created with Assign. As you don't use Assign you SHOULDN'T be using Eval.

Edited August 29, 2015 by guinness

Allow2010 · August 29, 2015

ok, i will just rework the gui and use an array...i was just to lazy and hoped eval could do the trick .-)

guinness · August 29, 2015

Don't favour bad practices because of laziness. In time you will regret it.

kylomas · August 29, 2015

Allow2010,

These vars are already declared previously in the script and you just want to blank them out? If so, this might help..

#include <GUIConstantsEx.au3>
#include <array.au3>

#AutoIt3Wrapper_Add_Constants=n

local $gui010 = guicreate('',100,130)

local $field1 = guictrlcreatelabel('1', 10,10,20,20)
local $field2 = guictrlcreatelabel('2', 10,30,20,20)
local $field3 = guictrlcreatelabel('3', 10,50,20,20)
local $field4 = guictrlcreatelabel('4', 10,70,20,20)
local $field5 = guictrlcreatelabel('5', 10,90,20,20)

local $button = guictrlcreatebutton('Blank labels',10,110,80,20)

guisetstate()

while 1
    switch guigetmsg()
        case $gui_event_close
            Exit
        case $button
            for $i = 1 to 5
                guictrlsetdata( eval("field" & $i),'')
            next
    EndSwitch

WEnd

However, if the controls are not created yet, this is a much better technique (as Guinness pointed out)...

#include <GUIConstantsEx.au3>
#include <array.au3>

#AutoIt3Wrapper_Add_Constants=n

local $gui010 = guicreate('',100,130)

local $aCTLDS[5]

for $i = 0 to 4
    $aCTLDS[$i] = guictrlcreatelabel($i, 10,$i * 15,20,20)
next

local $button = guictrlcreatebutton('Blank labels',10,110,80,20)

guisetstate()

while 1
    switch guigetmsg()
        case $gui_event_close
            Exit
        case $button
            for $i = 0 to 4
                guictrlsetdata($aCTLDS[$i],'')
            next
    EndSwitch

WEnd

kylomas

Edited August 29, 2015 by kylomas

iamtheky · August 30, 2015

Why would it matter if Assign created the variable? I would certainly still take the advice of using isdeclared prior to eval if there was any potential for explosions.

guinness · August 30, 2015

Why would it matter if Assign created the variable? I would certainly still take the advice of using isdeclared prior to eval if there was any potential for explosions.

I would prefer myself to listen to the help file instead of second guessing the internal workings of AutoIt.

A good example => for a long time you could use Assign() to create a variable with characters that weren't a-zA-Z0-9. Now just because it could be done, didn't mean it was right and though people contested this, sure enough it was declared (pardon the pun) as a bug and fixed. So just because using Eval() with variables works 80% of the time, doesn't mean you should rely on this, especially when the help file clearly states not to..

Source: https://www.autoitscript.com/trac/autoit/ticket/2478

Edited August 30, 2015 by guinness

Allow2010 · August 30, 2015

Thanks to all ...learned something new today, so is is a success :-)

iamtheky · August 30, 2015

especially when the help file clearly states not to..

it says in most situations, with no further explanation of why, or limitations with variables declared otherwise. Not really my idea of 'clearly'. It also does not help that in practice, I have seen it used without Assign in most situations, as with Kylomas example.

guinness · August 30, 2015

it says in most situations, with no further explanation of why, or limitations with variables declared otherwise. Not really my idea of 'clearly'. It also does not help that in practice, I have seen it used without Assign in most situations, as with Kylomas example.

I can easily change it to read "all situations".

iamtheky · August 30, 2015

All words though, i have seen it function just fine without (and haven't yet fully explored the special character explanation, so that may be the fog). And I'm skeptical that it is necessary until I see an example where a variable otherwise declared: passes isdeclared and blows up on eval, And using assign would have avoided that situation.

Edited August 30, 2015 by boththose

guinness · August 30, 2015

When it does blow up, you know where I am!

czardas · August 30, 2015

A good example => for a long time you could use Assign() to create a variable with characters that weren't a-zA-Z0-9. Now just because it could be done, didn't mean it was right and though people contested this, sure enough it was declared (pardon the pun) as a bug and fixed. So just because using Eval() with variables works 80% of the time, doesn't mean you should rely on this, especially when the help file clearly states not to..
Source: https://www.autoitscript.com/trac/autoit/ticket/2478

That seems a shame really. I think Jon might have considered fixing it to always work as a feature - although I don't recall a time when it ever exploded. It seems most logical to call my variable ~~'2^64-1'~~ '2^63-1': instead of calling it '9223372036854775807'. It would be nice to have comma delimiters in a variable name too: so you could split the name and perhaps create composite variable names. I think it's rather interesting to contemplate the possibilities - especially the natural language aspects of such a feature. I suppose there's always binary representation, but conversion adds a time penalty. I used the conversion method in my own code because I didn't know it could be done differently.

Has greater stability been gained by this change? - I wonder. Perhaps it was difficult to implement properly because it was actually an awesome bug which people were exploiting. I can imagine it being quite a headache for Jon though.

Edited August 30, 2015 by czardas

Danyfirex · August 30, 2015

I used to do this:

#include <GUIConstantsEx.au3>
#include <array.au3>

#AutoIt3Wrapper_Add_Constants=n

local $gui010 = guicreate('',100,130)

local $field1 = guictrlcreatelabel('1', 10,10,20,20)
local $field2 = guictrlcreatelabel('2', 10,30,20,20)
local $field3 = guictrlcreatelabel('3', 10,50,20,20)
local $field4 = guictrlcreatelabel('4', 10,70,20,20)
local $field5 = guictrlcreatelabel('5', 10,90,20,20)

local $button = guictrlcreatebutton('Blank labels',10,110,80,20)

guisetstate()

while 1
    switch guigetmsg()
        case $gui_event_close
            Exit
        case $button
            for $i = $field1 to $field5
                guictrlsetdata( $i,'')
            next
    EndSwitch

WEnd

Saludos

czardas · August 30, 2015

Hmm, seems risky! I always use an array for controls like that.

Edited August 30, 2015 by czardas

jchd · August 30, 2015

It seems most logical to call my variable '2^64-1': instead of calling it '9223372036854775807'

That would be '2^63-1' actually.

czardas · August 30, 2015

That would be '2^63-1' actually.

:whistle:

iamtheky · August 31, 2015

for a long time you could use Assign() to create a variable with characters that weren't a-zA-Z0-9. Now just because it could be done, didn't mean it was right and though people contested this, sure enough it was declared (pardon the pun) as a bug and fixed.

I must be misunderstanding, creating variables with special characters seems to work fine. *my mistake was doing this with 3.3.10.2

assign("2^3" , execute(2^3))
assign("2*3" , execute(2*3) & " : SIX")
assign("2+3" , "FIVE")
assign("2-3" , execute(2-3))


msgbox(0, "2^3" , eval("2^3"))
msgbox(0, "2*3" , eval("2*3"))
msgbox(0, "2+3" , eval("2+3"))
msgbox(0, "2-3" , eval("2-3"))

and further playing

assign(".-" , "A")
assign("-..." , "B")
assign("-.-." , "C")

local $sOut = ""
local $sString = ".- -... -.-."

$aString = stringsplit($sString , " " , 2)

for $i = 0 to ubound($aString) - 1
    $sOut &= eval($aString[$i])
Next

msgbox(0, $sString , $sOut)

Edited August 31, 2015 by boththose
the first example had unnecessary lines

Danyfirex · August 31, 2015

For me it does not work @boththose

Saludos

iamtheky · August 31, 2015

apologies, i was doing that on my 3.3.10.2. I can see it fail on my 3.3.11.2, so the change was somewhere between those two.

Sign In

easier way to adress varibles with eval?

Recommended Posts

Allow2010

guinness

Allow2010

guinness

kylomas

iamtheky

guinness

Allow2010

iamtheky

guinness

iamtheky

guinness

czardas

Danyfirex

czardas

jchd

czardas

iamtheky

Danyfirex

iamtheky

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Browse

AutoIt Resources

Release

Beta