Executing Variable As Function

[themax90]

I need to execute a variable as a function. For example:

$Variable = 'MsgBox(0, "Title", "Message")'
Execute($Variable)

I originally wrote a remote server that called received data from an ini that was broken down, but would like to have complete autoit functionality without the needed to add each function. Also, It would be nice to have a macro or function thats tests weither a function is a native function, user-defined, or not in the script.

Thanks for any help.

AutoIt Smith

[erebus]

You were very close:

$Variable = MsgBox(0, "Title", "Message")
Execute($Variable)

[SmOke_N]

This:

$Variable = MsgBox(0, "Title", "Message")

Is going to accomplish the same as:

$Variable = MsgBox(0, "Title", "Message")
Execute($Variable)

[Valuater]

maybe like this idea???

expandcollapse popup

#include "GUIConstants.au3"

$ITS_win = GUICreate(" Variable command test", 280, 180, -1, -1, $WS_SYSMENU)

;Create 2 buttons
$button_1 = GUICtrlCreateButton("A&ccept", 30, 100, 80, 25)
GUICtrlSetState(-1, $GUI_DEFBUTTON)
$button_2 = GUICtrlCreateButton("C&ancel", 150, 100, 80, 25)

;create labels
$label_1 = GUICtrlCreateLabel("    Please type in the command", 20, 15, 250, 20)
GUICtrlSetFont(-1, 9, 650)
$label_2 = GUICtrlCreateLabel(  "  message_1, message_2, etc.. etc.. " , 20, 35, 250, 20)
$label_3 = GUICtrlCreateinput( "", 20, 60, 220, 20)
$ITS = GUICtrlCreateLabel("Autoit-ITS.com", 200, 135, 80, 15)
GUICtrlSetFont(-1, 6, 500)

;Show the GUI
GUISetState(@SW_SHOW)

While 1
    $msg = GUIGetMsg()
    Select
        Case $msg = $button_2 Or $msg = $GUI_EVENT_CLOSE
            Exit
        Case $msg = $button_1
            $Variable = GUICtrlRead($label_3)
        ; If User acepted then
            Call($Variable)
        ; endif
    EndSelect
WEnd

Func message_1()
    MsgBox(0,"test", $Variable)
EndFunc

Func message_2()
    MsgBox(0,"test", $Variable)
EndFunc

Func message_3()
    MsgBox(0,"test", $Variable)
EndFunc

Func message_4()
    MsgBox(0,"test", $Variable)
EndFunc

if the $variable is incorrect... then nothing happens and no errors occur

8)

[themax90]

I will work up a small sample.

[LxP]

Execute

···

Remarks

Environment, Files, Dir, Disk, GUI, InputBox, MsgBox, Misc, Network, Obj/COM, Process, Registry, Tray, WinKill functions implying deletion or modification will not be executed. They will set @error to 9999 and return "".

[Ndru]

Was this restriction introduced to reduce possible security risks or is it there because of some limitation of the Autoit script engine itself?

[LxP]

Welcome to the forums!

These restrictions are imposed only for security.

[themax90]

MyExecute("MsgBox(0, 'Title', 'Text')")
Func MyExecute($Cmd)
    RunWait(@AutoItExe & ' /AutoIt3ExecuteLine "' & $Cmd & '"')
EndFunc  ;==>MyExecute

Edited December 27, 2005 by AutoIt Smith

[Ndru]

Welcome to the forums!

These restrictions are imposed only for security.

Perhaps implementing a special directive might help to eliminate such risks and restore this command to it's full potential.

A #safe_exec_off directive for example, which, if used on the very first line of a given script, would remove the limiations on exec().

This would enable users to immediately see if a script is able to execute dynamic commands and can either decide not to trust the code, or simply deprive the script of this ability by deleting the directive.

Any opinions about an option like this?

[Arilvv]

Perhaps implementing a special directive might help to eliminate such risks and restore this command to it's full potential.

A #safe_exec_off directive for example, which, if used on the very first line of a given script, would remove the limiations on exec().

This would enable users to immediately see if a script is able to execute dynamic commands and can either decide not to trust the code, or simply deprive the script of this ability by deleting the directive.

Any opinions about an option like this?

It's a very good idea!

I think the restrictions is not really necessary.

Add an option to remove the restrictions or just add a new commnad, please...

[Ndru]

It's a very good idea!

I think the restrictions is not really necessary.

Add an option to remove the restrictions or just add a new commnad, please...

I guess the concerns are valid since such functions can be used to obfuscate malicous code.

I know that many programmers think exec-like funtions are evil. (Corrupting the soul and curving the spine of those who use it! ) Some of them worry too much about security risks i guess. It doesn't really take an exec function to cause harm to users who run scripts blindly without checking their content first or executing exes from an untrusted source. For an inexperienced user exec is no more security risk than any other function.

I proposed this idea because i thought it'd help users who do check scripts beforehand to immediately notice the presence of exec without the need to actively search for such script fragments.

Edited December 27, 2005 by Ndru

[MHz]

Was security the issue. I thought it was safety ? A function that can execute anything literallly could be regarded as a danger, not just to others, but maybe to oneself ?

I have not used this function for it's restriction as normally ways are available to do operations without the need of it. Please, show me a small good script that would make a sensible use of this function.

[Ndru]

Don't get me wrong i'm not a die-hard fan of such programming solutions, i'm just saying that it's simply a tool for the programmer. No necessarily better or worse than any other solution for the same problem.

I don't think there's a need to prove wether or not a function can be of any use, because its only there to open other ways and add more options to the programmer to choose from. The more option one has the better. After that, it's completely up to the person's stlye of coding to either use or ignore the function.

About the dangers of such function: I think it's up the documentation and other sefety measures (such as another setting) to prevent users from using *any* function (and not just exec) that might cause damage if used without care.

But most importantly it's up to us, the other users, to make people aware of such dangers.

[Arilvv]

Was security the issue. I thought it was safety ? A function that can execute anything literallly could be regarded as a danger, not just to others, but maybe to oneself ?

I have not used this function for it's restriction as normally ways are available to do operations without the need of it. Please, show me a small good script that would make a sensible use of this function.

Recently, I use kixforms as a GUI framwork :"> . In most cases, autoit work perfectly with kixforms. But think of the example: (kix source, and kixforms.dll is here)

expandcollapse popup

#NoTrayIcon
Global $System = ObjCreate("Kixtart.System")
Global $Form = $System.Form
With $Form
    .FontName = "Tahoma"
    .FontSize = 10
EndWith

Global $SmallIcon = $Form.ToolButton
With $SmallIcon
    .Location = $System.Point(10, 10)
    .Width = 23
    .Icon = 40
    .onclick = "$ListView.View = 1"
    .FlatStyle = 1
EndWith

Global $LargeIcon = $Form.ToolButton
With $LargeIcon
    .Location = $System.Point($SmallIcon.Right + 5, 10)
    .Width = 23
    .Icon = 38
    .onclick = "$ListView.View = 0"
    .FlatStyle = 1
EndWith

Global $ListIcon = $Form.ToolButton
With $ListIcon
    .Location = $System.Point($LargeIcon.Right + 5, 10)
    .Width = 23
    .Icon = 39
    .onclick = "$ListView.View = 2"
    .FlatStyle = 1
EndWith

Global $DetailsIcon = $Form.ToolButton
With $DetailsIcon
    .Location = $System.Point($ListIcon.Right + 5, 10)
    .Width = 23
    .Icon = 41
    .onclick = "$ListView.View = 3"
    .FlatStyle = 1
EndWith

Global $ListView = $Form.ListView
With $ListView
    .Location = $System.Point(10, $SmallIcon.Bottom + 10)
    .Right = $Form.ClientWidth - 10
    .Bottom = $Form.ClientHeight - 50
    .Columns.Count = 1
    .SmallImageList = $Form.SmallImageList
    .onclick = "ListView_Click()"
    .View = 0
EndWith

$LargeImageList = $Form.ImageList
With $LargeImageList
    .ImageSize = $System.Size(32, 32)
    For $i = 0 To $Form.SmallImageList.Images.Count
        .Images.Add($Form.SmallImageList.Images($i))
    Next
EndWith

$ListView.largeImageList = $LargeImageList

Func ListView_Click()
    $Exit.Icon = $ListView.SmallImageList.Images($ListView.FocusedItem.Text)
EndFunc

For $i = 0 To $ListView.SmallImageList.Images.Count
    $Item = $ListView.Items.Add($i,$i)
Next

Global $Exit = $Form.ToolButton
With $Exit
    .Center()
    .Top = $ListView.Bottom + 10
    .Text = "Exit"
    .Icon = 37
    .onclick = "Quit()"
EndWith

$Form.Center()
$Form.Show()
While $Form.Visible
    Execute($Form.DoEvents)
Wend

Exit 1

In this case, toolbutton can't work because Execute("$ListView.View = 3") is restricted.

Maybe the only solution is to write additional functions just like:

.onclick = "ListView_View_0"

...

Func ListView_View_0()
    $ListView.View = 0
EndFunc

...

While $Form.Visible
    Call($Form.DoEvents)
Wend

But I don't think this is a good idea

[LxP]

You also have the option of doing this:

Func SetVar(ByRef $Var, $Val)
    $Var = $Val
EndFunc
···
Execute('SetVar($ListView.View, 3)')

Edit: Typo.

Edited December 28, 2005 by LxP

[Arilvv]

You also have the option of doing this:

Func SetVar(ByRef $Var, $Val)
    $Var = $Val
EndFunc
···
Execute('SetVal($ListView.View, 3)')

What if I want to use some reg functions or run/runwat functions in the eventhandle? So I can't use Execute(). However, Call("SetVal") can't transfer the value.