J
Joe Earnest
Hi Al,
|
| Sounds like you are using execute itself in a recursive loop - I would
| assume that to be a little inefficient. So far the only use I have made of
| it is:
|
| a) for a one-time call of an external script
| b) to define a function or a class
| c) to define a global variable from within a function
|
| Except for the last case, none of the execute statements is ever called
more
| than once; if any repetition results, it is only done by calling a
function
| defined by the execute statment.
|
| I would be very leary of getting any fancier with execute, such as passing
| calculated or iterated versions of code. That smacks too much of "self
| modifying code", which would be even harder to debug than an executed
| script, mainly because it is not static.
I agree...
The recursive use is very slow, but reliable. I had written a recursive
local function-within-function defined by Execute into a registry key
deletion function, where it rewrote itself at each level and followed each
subkey tree branch until it found one that had no subkeys. Worked fine, but
very slow. Since I've switched my library functions over to a WSC, there's
no problem with simply using a static function that can be called
recursively, and there's been no need for it.
Your limitations seem quite advisable, however ...
My use of Execute has increased, as I tend more towards a single
comprehensive WSC file for utility routines. Some utility routines require
user-defined script to be fed to the routine through an option
property-global variable, which is then executed by the script. Not used
heavily, but useful when needed.
For example, I have a series of WSC methods that automatically write IeApp
combo-box style dialogs (still under construction as I am converting my
prior routines into a WSC). One of the option properties accepts
user-defined script for an "operation button" (i.e., not an "exit button",
but one that triggers execution of script routines as opposed to embedded
HTML routines, while the dialog window is still displayed). After some
preliminary setup, keyword decoding and error trapping, the function-method
simply "executes" the user-defined script assigned to the property, when the
button is clicked.
Regards,
Joe Earnest
|
| Sounds like you are using execute itself in a recursive loop - I would
| assume that to be a little inefficient. So far the only use I have made of
| it is:
|
| a) for a one-time call of an external script
| b) to define a function or a class
| c) to define a global variable from within a function
|
| Except for the last case, none of the execute statements is ever called
more
| than once; if any repetition results, it is only done by calling a
function
| defined by the execute statment.
|
| I would be very leary of getting any fancier with execute, such as passing
| calculated or iterated versions of code. That smacks too much of "self
| modifying code", which would be even harder to debug than an executed
| script, mainly because it is not static.
I agree...
The recursive use is very slow, but reliable. I had written a recursive
local function-within-function defined by Execute into a registry key
deletion function, where it rewrote itself at each level and followed each
subkey tree branch until it found one that had no subkeys. Worked fine, but
very slow. Since I've switched my library functions over to a WSC, there's
no problem with simply using a static function that can be called
recursively, and there's been no need for it.
Your limitations seem quite advisable, however ...
My use of Execute has increased, as I tend more towards a single
comprehensive WSC file for utility routines. Some utility routines require
user-defined script to be fed to the routine through an option
property-global variable, which is then executed by the script. Not used
heavily, but useful when needed.
For example, I have a series of WSC methods that automatically write IeApp
combo-box style dialogs (still under construction as I am converting my
prior routines into a WSC). One of the option properties accepts
user-defined script for an "operation button" (i.e., not an "exit button",
but one that triggers execution of script routines as opposed to embedded
HTML routines, while the dialog window is still displayed). After some
preliminary setup, keyword decoding and error trapping, the function-method
simply "executes" the user-defined script assigned to the property, when the
button is clicked.
Regards,
Joe Earnest