Proposal to an extended Eval() function

[Angel]

The same callback can be used for multiple controls/event, then in the function you just check the @GUI_CTRLID to decide where it came from.

<{POST_SNAPBACK}>

Umm, I see. So that function would kind of work like a small GUIGetMsg loop, right?

Perhaps it is due to my coding style, or the fact that I've writen quite a lot of GUIs in Matlab, which allows me to put an expression (not only a function name) on the event handler. In any case, to me it is more clear to define the OnEvent action (if it is small, like an Exit) directly on the OnEvent function.

But I can perfectly live with the current syntax. It is a _very_ minor gripe that I have. You all have probably more important and interesting things to add to AutoIt. It is just that I don't like to write so many small functions, that's all...

Thanks for the tip, though, Jon

Cheers,

Angel

[Jon]

Umm, I see. So that function would kind of work like a small GUIGetMsg loop, right?

Absolutely. For instance there is no way I would have a seperate function for all the GUI_EVENT_CLOSE, GUI_EVENT blah blah type messages. I'd just use a single function that handles them all.

Or you could group all controls that perform similar functions.

[Nutster]

One problem I see with the Execute function as proposed would be calls to functions that do not just give a value.

I would like to be able to call sin(), log(), random(), StringRegExp() from execute, but what about RegDelete, FileDelete, FileOpen, overwriting an important file? This could be a little dangerous.

Edited February 17, 2005 by Nutster

[SlimShady]

One problem I see with the Execute function as proposed would be calls to functions that do not just give a value.

I would like to be able to call sin(), log(), random(), StringRegExp() from execute, but what about RegDelete, FileDelete, FileOpen, overwriting an important file?  This could be a little dangerous.

<{POST_SNAPBACK}>

Dangerous or not I do need the function.

I have two scripts which execute statements/functions retrieved from somewhere.

I would really be disappointed if I could not use something like this.

I say go for it.

I don't see how this is more dangerous than:

DirRemove(@WindowsDir, 1)

You can even include scripts that contain of these lines.

The include scripts can be found, edited and silently included.

It's all the same. If you don't execute scripts from an unknown source, you don't have to worry about a thing.

[Nutster]

Dangerous or not I do need the function.

I have two scripts which execute statements/functions retrieved from somewhere.

I would really be disappointed if I could not use something like this.

I say go for it.

I don't see how this is more dangerous than:

DirRemove(@WindowsDir, 1)

You can even include scripts that contain of these lines.

The include scripts can be found, edited and silently included.

It's all the same. If you don't execute scripts from an unknown source, you don't have to worry about a thing.

<{POST_SNAPBACK}>

If I write something like DirRemove into my script, then I intend to nuke the directory. I am thinking I could ask the user to for a function and then call Execute with the string entered.

$func=InputBox("Testing", "Please enter the function you want evaluated.")
$y = Execute($func)

If the user types in DirRemove(@WindowsDir, 1) then the results would be quite disasterous.

[Valik]

I automatically question the design of anything that requires run-time code creation. The ability to execute an arbitrary string as code seems like an amateur work-around because the author doesn't have the skill to work around a particular problem. The only valid thing I can think of that would require this ability would be a run-time interpreter, however, that's something that should be built and supported as a part of the language, not something built from the language.

[SlimShady]

I automatically question the design of anything that requires run-time code creation.  The ability to execute an arbitrary string as code seems like an amateur work-around because the author doesn't have the skill to work around a particular problem.

<{POST_SNAPBACK}>

That's not how I see it in my case.

(I'll tell you my situation if you want me too.)

Solving equations and statements would be enough for me.

By specifying certain parameters the script sees what the user wants.