how to create an Array with parametrized name?

[nobody]

hello everybody,

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:

str = "tableA";

fDoArray(str);
fDoArray("tableB");

tableA[10] = 10;
tableB[11] = 11;

I would appreciate any suggestions and help,
regards,
mirek

[lallous]

Hello,

<script>
function fDoArray(arrayName)
{
window[arrayName] = new Array();
}

str = "tableA";

fDoArray(str);
fDoArray("tableB");

tableA[10] = 10;
tableB[11] = 11;

alert(tableB);
alert(tableA);
</script>

--
Elias
http://lgwm.org/

"nobody" <no****@non.existe.nt> wrote in message
news:b2*********************@news.chello.at...

hello everybody,

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:

str = "tableA";

fDoArray(str);
fDoArray("tableB");

tableA[10] = 10;
tableB[11] = 11;

I would appreciate any suggestions and help,
regards,
mirek

[Vjekoslav Begovic]

"nobody" <no****@non.existe.nt> wrote:

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:

str = "tableA";

fDoArray(str);
fDoArray("tableB");

tableA[10] = 10;
tableB[11] = 11;

function fDoArray(str){
window[str]=new Array();
return window[str];
}

[nobody]

hello,

thanks Vjekoslav and Elias. do you know any solution, that would also
work under Windows Scripting Host?

cheers,
mirek

[Martin Honnen]

nobody wrote:

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:

str = "tableA";

fDoArray(str);
fDoArray("tableB");

tableA[10] = 10;
tableB[11] = 11;

I think using this works as follows:
function output (text) {
if (typeof document != 'undefined' && typeof document.write !=
'undefined') {
document.write(text + '<br>\n');
}
else if (typeof WScript != 'undefined') {
WScript.Echo(text);
}
}

function createArray (variableName) {
this[variableName] = [];
}

createArray('arrayName');
arrayName[0] = 'Kibo';
arrayName[1] = 'Maho';

output(arrayName);
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Douglas Crockford]

> thanks Vjekoslav and Elias. do you know any solution, that would also

work under Windows Scripting Host?

The global object does not have a standard name, which is sort of surprising. In
browsers, it can be referred to as 'window'. In other environments it might have
no name at all.

The 'this' variable, when used outside of any function, refers to the global
object. So, at the top of your program, write

var global = this;

and then use 'global' in place of 'window'.

http://www.crockford.com/javascript/survey.html

[nobody]

Martin and Douglas -- thank you both for help and WSH solution

cheers :)
mirek

[Joe Earnest]

Hi,

"nobody" <no****@non.existe.nt> wrote in message
news:XB*********************@news.chello.at...
| hello,
|
| thanks Vjekoslav and Elias. do you know any solution, that would also
| work under Windows Scripting Host?

original message:

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:
---

While you're looking for a JS solution, you may want to consider ...

This is easy in VBS - not sure about JS. Although undocumented, the VBS
Execute statement will create a new global variable (despite any Option
Explicit statement), if it does not find the variable name referenced in
either its immediate local variable list or the global variable list. So
the following should work (air code):

sub NewArray (rsArrayName)
execute "dim " & rsArrayName & "()"
end sub

Just Redim after the call, as needed, or you could incorporate the
dimensions and bounds through an additional string parameter, if you wish.
You can wrap the code in On Error ... statements, if you're worried about
potentially Dimming an existing array. You can mix JS and VBS in HTML or
WSC wrappers.

Joe Earnest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03

[Bogdan Blaszczak]

Uzytkownik "Douglas Crockford" <no****@covad.net> napisal w wiadomosci
news:73***************************@msgid.meganewss ervers.com...
....

The 'this' variable, when used outside of any function, refers to the global object. So, at the top of your program, write

var global = this;

using try...catch may cause the same code work both in browser and wsh.

var wsh
try{window=this;wsh=1}catch(e){}

function fDoArray(x){return window[x]=[]}

fDoArray("tableA")
tableA[0]=0
tableA[1]=1
tableA[2]=2

if(wsh){
Shell=WScript.CreateObject("WScript.Shell")
Shell.Popup(tableA)
}
else alert(tableA)

greets
BlaTek
http://blatek.25.pl/christmaspuzzle/puzzle.html

[Gerry Hickman]

Bogdan Blaszczak wrote:

using try...catch may cause the same code work both in browser and wsh.

var wsh
try{window=this;wsh=1}catch(e){}

This may fail to give the right results if running under some other host
such as ASP. I'm trying to imagine the purpose of the original posters
request?

--
Gerry Hickman (London UK)

[nobody]

Gerry Hickman wrote:

This may fail to give the right results if running under some other host
such as ASP. I'm trying to imagine the purpose of the original posters
request?

hello Gerry,

the purpose is as follows. I have a program that provides its own
scripting language. the scripting language is very powerful but lacks
sort of constructions which are natural in JS or VBS.
this program also allows cooperation with other applications through
Windows Automation Model (I'm not sure if it is that called). it also
provides the ability of using scripting languages via WSH, sharing,
importing, exporting their variables, using their functions etc.

the idea was to create array with parametrized name using JS. created
array with that special name would be returned to program's own
scripting language. here's a sketch of JS function that would do this.
LFA is the program's own function that do the trick. it puts
*prefix..postfix* array into program's own script space like putting
book on a shelf.

function fDoArray( strArrayName, intNumber ) {
var str = "prefix" + strArrayName + intNumber + "postfix";
LFA(str) = new Array();
}

thanks for all responses,
cheers,
mirek

[Lasse Reichstein Nielsen]

nobody <no****@non.existe.nt> writes:

thanks Vjekoslav and Elias. do you know any solution, that would also
work under Windows Scripting Host?

This should work in any ECMAScript compliant language:

function doArray(x) {
this[x]=[];
}

As long as you call the function directly, and not as a method of some
object, "this" refers to the global object.

I haven't tested it in the WSH, though, but if JScript is ECMAScript
compliant, it should work.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Al Dunbar [MS-MVP]]

"Joe Earnest" <jo**********@SPAMqwest.netPLEASE> wrote in message
news:uv**************@TK2MSFTNGP09.phx.gbl...

Hi,

"nobody" <no****@non.existe.nt> wrote in message
news:XB*********************@news.chello.at...
| hello,
|
| thanks Vjekoslav and Elias. do you know any solution, that would also
| work under Windows Scripting Host?

original message:

is there a way of creating an array with help of a function that would
accept the name of this array as a parameter and then create global
Array type variable of that name?
so that for example the following code would work as well in browsers as
under Windows Scripting Host:
---

While you're looking for a JS solution, you may want to consider ...

This is easy in VBS - not sure about JS. Although undocumented, the VBS
Execute statement
Time to download more up to date docs, Joe. Mine has the following:
Execute Statement
See Also
Eval Function | ExecuteGlobal Statement

Requirements
Version 1

Executes one or more specified statements.

Execute statementThe required statement argument is a string expression
containing one or more statements for execution. Include multiple statements
in the statement argument, using colons or embedded line breaks to separate
them.
will create a new global variable (despite any Option
Explicit statement), if it does not find the variable name referenced in
either its immediate local variable list or the global variable list. So
the following should work (air code):

sub NewArray (rsArrayName)
execute "dim " & rsArrayName & "()"
end sub

Just Redim after the call, as needed, or you could incorporate the
dimensions and bounds through an additional string parameter, if you wish.
You can wrap the code in On Error ... statements, if you're worried about
potentially Dimming an existing array. You can mix JS and VBS in HTML or
WSC wrappers.

A similar approach can be used to define global constants in a similar
manner from within a routine.

/Al

[Joe Earnest]

Hi Al,

[snipped]

"Al Dunbar [MS-MVP]" <Al***************@hotmail.com> wrote in message
news:Oi**************@tk2msftngp13.phx.gbl...
| Time to download more up to date docs, Joe. Mine has the following:

The function is documented, but it's the fact that it circumvents Option
Explicit and creates a new variable instead of erroring out that's
undocumented and unintended. That's the only reason that it would work for
the OP in this situation and in the example that I gave. When I first
stumbled on this behavior over a year ago, Michael Harris verified the
operation and verified with Eric Lippert (who apparently wrote the execute
code) that the behavior is both unintended and unlikely to change.

http://www.google.com/groups?hl=en&l...961d93f&rnum=1

(from MH post)

"I checked with Eric Lippert (who wrote the Execute and ExecuteGlobal
implementation code)...

What you observe is actually a bug and unintended behavior. Execute within
a procedure is *not* supposed to create a variable with global scope. He
also noted that this is probably something that will never get fixed ;-)..."
Regards,
Joe Earnest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03

[Al Dunbar [MS-MVP]]

"Joe Earnest" <jo**********@SPAMqwest.netPLEASE> wrote in message
news:Ol**************@tk2msftngp13.phx.gbl...

Hi Al,

[snipped]

"Al Dunbar [MS-MVP]" <Al***************@hotmail.com> wrote in message
news:Oi**************@tk2msftngp13.phx.gbl...
| Time to download more up to date docs, Joe. Mine has the following:

The function is documented,
Ah, you didn't mean "undocumented", but "not FULLY documented".
but it's the fact that it circumvents Option
Explicit
Not really - see way below...
and creates a new variable
.... as I would expect a DIM statement to do ...
instead of erroring out
.... now *that* would be unexpected...
that's
undocumented
.... granted. By the same token the "function" and "sub" statements are not
fully documented because they do not define all of the behaviours and side
effects that could result from their use. But I digress...
and unintended.
That's *their* problem. A more important question is: "Is it *expected*" to
which my answer is "Yes". A secondary question is: "will this departure from
a <fixed source> model be completely straightforward", to which my answer is
"obviously not".
That's the only reason that it would work for
the OP in this situation and in the example that I gave.
.... the reason it works is, well, that is how it works. It doesn't work
because it is a bug, but because the underlying code does what it does. The
fact that this was unintended by the developers is really beside the point.
When I first
stumbled on this behavior over a year ago, Michael Harris verified the
operation and verified with Eric Lippert (who apparently wrote the execute
code) that the behavior is both unintended and unlikely to change.
Unintended: their mistake; unlikely to change: score one for platform
stability.
http://www.google.com/groups?hl=en&l...961d93f&rnum=1
(from MH post)

"I checked with Eric Lippert (who wrote the Execute and ExecuteGlobal
implementation code)...

What you observe is actually a bug and unintended behavior.
I disagree :-) It is only a bug if the behaviour was intended NOT to
happen. Just because they missed a side effect of their own code (especially
one that has some specific uses), they should not go dissing themselves over
their oversight ;-)
Execute within
a procedure is *not* supposed to create a variable with global scope. He
also noted that this is probably something that will never get fixed

;-)..."

I consider the related documentation to be in error (or at least misleading)
in this respect, probably because it was written before executeglobal was
implemented. One specific error in the definition of executeglobal is shown
in the extract below, highlighted in ALL CAPS.

I believe the paragraph and disbelieve the endline comments, both because
that makes sense based on what EXECUTEGLOBAL means, and because, well, that
is actually how it works. This also indicates that the writers of the
documentation were, like me, of the opinion that it was *expected* to create
a variable with global scope.

Nevertheless, the Option Explicit documentation states: "When you use the
Option Explicit statement, you must explicitly declare all variables using
the Dim, Private, Public, or ReDim statements. If you attempt to use an
undeclared variable name, an error occurs.". If you execute a DIM statement
with an EXECUTEGLOBAL statement, are you not explicitly declaring the
variable? It is true that this may appear less *explicit* a declaration when
reading through the code, as it could be obfuscated in many ways.

If, as implied, the executeglobal statement was never intended to modify the
global namespace, then what on earth was it supposed to do that execute by
itself could not?

The way I see it is that the developers implemented the Executeglobal
statement to do what it implies (to me at least): execute code as if it was
being executed in the global scope of the script. The fact that it does this
to such a great extent even when that was not their conscious intent speaks
to the quality of their work.

/Al

<extract>

Adding procedures and classes at runtime can be useful, but also introduces
the possibility of OVERWRITING EXISTING GLOBAL VARIABLEs and functions at
runtime. Because this can cause significant programming problems, CARE
SHOULD BE EXERCISED when using the ExecuteGlobal statement. If you DON'T
need access to a variable or function outside of a procedure, USE THE
EXECUTE STATEMENT that will ONLY AFFECT THE NAMESPACE of the calling
function.

The following example illustrates the use of the ExecuteGlobal statement:

Dim X ' Declare X in global scope.
X = "Global" ' Assign global X a value.
Sub Proc1 ' Declare procedure.
Dim X ' Declare X in local scope.
X = "Local" ' Assign local X a value.
' The Execute statement here creates a
' procedure that, when invoked, prints X.
' It print the global X because Proc2
' inherits everything in global scope.
ExecuteGlobal "Sub Proc2: Print X: End Sub"
Print Eval("X") ' Print local X.
Proc2 ' Invoke Proc2 in Global scope resulting
' in "Global" being printed.
End Sub
PROC2 ' THIS LINE CAUSES AN ERROR SINCE
' PROC2 IS UNAVAILABLE OUTSIDE PROC1.

[THIS IS EXACTLY THE OPPOSITE OF WHAT THE FIRST PARAGRAPH SAID. THAT COMMENT
WOULD APPLY HAD THE PROCEDURE USE EXECUTE INSTEAD OF EXECUTEGLOBAL]

Proc1 ' Invoke Proc1.
Execute "Sub Proc2: Print X: End Sub"
Proc2 ' This invocation succeeds because Proc2
' is now available globally.

</extract>

[Joe Earnest]

Hi Al,

A few responses interspersed below. I messed this up at the outset,
however, by an error in the air code that I posted.

I posted:

sub ...
execute "dim " & sVarName & "()"

The above works within Execute's intended parameters and just creates a
*local* array that goes out of scope when the Sub is exited, and so does the
OP no good. My bad. Should have been:

sub ...
execute "redim " & sVarName & "(0)"

This would take advantage of the undocumented operation and, because the
variable doesn't exist, would be create a new *global* array that could then
be legitimately Redimmed as necessary in the main script. This is what the
OP needed. What's worse is that I already use a correct version of this in
a routine in my library version of MH's IEPipe method (a non-visible IeApp
window used to pass data between multiple running scripts). Just screwed up
the posted air code.

| > and unintended.
|
| That's *their* problem. A more important question is: "Is it *expected*"
to
| which my answer is "Yes". A secondary question is: "will this departure
from
| a <fixed source> model be completely straightforward", to which my answer
is
| "obviously not".

The fact that it doesn't error out on an uninitiated variable under Option
Explicit is unexpected. It also reduces the usefulness of the Execute
function for articulate error-trapping routines, for which it otherwise
ideally suited.

| > That's the only reason that it would work for
| > the OP in this situation and in the example that I gave.
|
| ... the reason it works is, well, that is how it works. It doesn't work
| because it is a bug, but because the underlying code does what it does.
The
| fact that this was unintended by the developers is really beside the
point.

Correct - see my correction to my air code above. This was my initial error
in using "dim" instead or "redim". The original code did not make use of
the unintended capabilities.

| > When I first
| > stumbled on this behavior over a year ago, Michael Harris verified the
| > operation and verified with Eric Lippert (who apparently wrote the
execute
| > code) that the behavior is both unintended and unlikely to change.
|
| Unintended: their mistake; unlikely to change: score one for platform
| stability.

Well, I think this is just because WSH 5.6 is unlikely to change, with no
further development (at least on the VBS side).

| > (from MH post)
| >
| > "I checked with Eric Lippert (who wrote the Execute and ExecuteGlobal
| > implementation code)...
| >
| > What you observe is actually a bug and unintended behavior.
|
| I disagree :-) It is only a bug if the behaviour was intended NOT to
| happen. Just because they missed a side effect of their own code
(especially
| one that has some specific uses), they should not go dissing themselves
over
| their oversight ;-)

Well, it does create anomalies. For example, if you were to call an
undefined function or sub without arguments, it does not error out, but
creates them as global variables.

In a different thread with MH, he pointed out that unintended and
undocumented effects may get changed in later versions, making previously
good script error-prone. Now that WSH seems to have no further development,
however, all the undocumented effects may be fair game - execute, omitted
user-defined procedure arguments, error scoping, etc. ;-)

| > Execute within
| > a procedure is *not* supposed to create a variable with global scope.
He
| > also noted that this is probably something that will never get fixed
| ;-)..."

| I consider the related documentation to be in error (or at least
misleading)
| in this respect, probably because it was written before executeglobal was
| implemented. One specific error in the definition of executeglobal is
shown
| in the extract below, highlighted in ALL CAPS.

Per MH, Eric Lippert wrote the code for both functions. As we all know,
however, documentation tends to get written in the beta stages and never
changed.

| I believe the paragraph and disbelieve the endline comments, both because
| that makes sense based on what EXECUTEGLOBAL means, and because, well,
that
| is actually how it works. This also indicates that the writers of the
| documentation were, like me, of the opinion that it was *expected* to
create
| a variable with global scope.

Except that it doesn't foresee the variable *error* situation. (I.e.,
creating an unintended new variable instead of erroring out.)

Regards,
Joe Earnest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03

[Gerry Hickman]

nobody wrote:

the purpose is as follows. I have a program that provides its own
scripting language. the scripting language is very powerful but lacks
sort of constructions which are natural in JS or VBS.

I see, there's obviously much more to it than I realized. Without seeing
this "program" and it's super new scripting language, it would be
impossible to comment on the idea. I do have to wonder, however, if it's
possible (or advantageous) to create "yet another scripting language".
If I was writing a new app with it's own scripting language, I'd choose
JScript (or JavaScript - what ever you want to call it) or PERL. That
way you get near standards compliance, worldwide open documentation,
good pool of skills, and Windows already supplies COM script interfaces.

Think of all the different proprietary scripting languages that have
come and gone over the last 10 years...I'd rather have something with a
future.

--
Gerry Hickman (London UK)

[nobody]

hello Gerry

I see, there's obviously much more to it than I realized. Without seeing
this "program" and it's super new scripting language, it would be
impossible to comment on the idea. I do have to wonder, however, if it's
possible (or advantageous) to create "yet another scripting language".
If I was writing a new app with it's own scripting language, I'd choose
JScript (or JavaScript - what ever you want to call it) or PERL. That
way you get near standards compliance, worldwide open documentation,
good pool of skills, and Windows already supplies COM script interfaces.

Think of all the different proprietary scripting languages that have
come and gone over the last 10 years...I'd rather have something with a
future.

perhaps I used wrong words. I didn't create this program. Its scripting
language isn't anything comparable to JS or VBS. its purpose is
completely different, but it can cooperate with these scripting
languages. perhaps I should have used the term: internal programming
language. like Labtalk + Origin (program for scientific evaluations)

cheers,
mirek

[Al Dunbar [MS-MVP]]

"Joe Earnest" <jo**********@SPAMqwest.netPLEASE> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi Al,

A few responses interspersed below. I messed this up at the outset,
however, by an error in the air code that I posted.
This probably explains away much of our disagreement...

<snip>
| > (from MH post)
| >
| > "I checked with Eric Lippert (who wrote the Execute and ExecuteGlobal
| > implementation code)...
| >
| > What you observe is actually a bug and unintended behavior.
|
| I disagree :-) It is only a bug if the behaviour was intended NOT to
| happen. Just because they missed a side effect of their own code
(especially
| one that has some specific uses), they should not go dissing themselves
over
| their oversight ;-)

Well, it does create anomalies. For example, if you were to call an
undefined function or sub without arguments, it does not error out, but
creates them as global variables.
Ah, now that truly is an anomaly, assuming that option explicit is in
effect. But is it in effect if it exists only in the code that executes the
execute or executeglobal statement? I have found, for example, that each one
of the *.vbs included in my .wsf files needs to have its own option
explicit. Same goes for *.vbs files that our logon script reads in and
executes. The way I see it, the option explicit has a scope that depends on
the structure of the code itself.
In a different thread with MH, he pointed out that unintended and
undocumented effects may get changed in later versions, making previously
good script error-prone. Now that WSH seems to have no further development, however, all the undocumented effects may be fair game - execute, omitted
user-defined procedure arguments, error scoping, etc. ;-)
Whether or not execute and executeglobal have unintended or undocumented
effects is probably secondary to the fact that code using them can be
difficult to debug. When our logon scripts read in a *.vbs file and run it
with executeglobal, if there is an error in that code, the error message
does not give the line number.

We therefore use the technique only when it seems the only way to accomplish
something, but we avoid doing anything really fancy with it for the reasons
you give above. Here's an example...

In order to create persistent variables local to a routine, I initially
would include code like this within the function:

executeglobal "dim functionName_localVariable"
if ( isempty( functionName_localVariable ) ) then
' code to initialize variable "functionName_localVariable"
end if

The variable was, of course, actually global. It is only by coding
convention that it would not be accessed by any other routine.

Because the code was ultimately going to be maintained by others, I decided
that this was a bit too tricky, so I deleted the executeglobal statement and
placed the equivalent dim statement just before the function statement. Of
course, this only works if the code defining the function and its
"persistent local variables" is parsed by the scripting host before the
function is called.
| > Execute within
| > a procedure is *not* supposed to create a variable with global scope.
He
| > also noted that this is probably something that will never get fixed
| ;-)..."

| I consider the related documentation to be in error (or at least
misleading)
| in this respect, probably because it was written before executeglobal was | implemented. One specific error in the definition of executeglobal is
shown
| in the extract below, highlighted in ALL CAPS.

Per MH, Eric Lippert wrote the code for both functions. As we all know,
however, documentation tends to get written in the beta stages and never
changed.

Hey, at least it was *written*! And it is certainly not the only part of the
doc that could be improved on ;-)

/Al

[Joe Earnest]

Hi Al,

Fully agree ...

[snipped]

"Al Dunbar [MS-MVP]" <Al***************@hotmail.com> wrote in message
news:Or**************@TK2MSFTNGP10.phx.gbl...

| Ah, now that truly is an anomaly, assuming that option explicit is in
| effect. But is it in effect if it exists only in the code that executes
the
| execute or executeglobal statement? I have found, for example, that each
one
| of the *.vbs included in my .wsf files needs to have its own option
| explicit. Same goes for *.vbs files that our logon script reads in and
| executes. The way I see it, the option explicit has a scope that depends
on
| the structure of the code itself.

I think you're correct. I work with WSC's instead of WSF's, but each
<component> seems to require its own global scope. For that reason, I only
define one component in my library WSC, but that then requires some user
structuring. Each of my method-functions has to call a utility function to
reset all the global variables used for return properties at the outset of
the method, and another one to reset the option properties at the conclusion
of the method. Using one component has other advantages, however -- one set
of declared global utility objects, utility functions that can cross-call
each other, one initiation script, etc.

| Whether or not execute and executeglobal have unintended or undocumented
| effects is probably secondary to the fact that code using them can be
| difficult to debug. When our logon scripts read in a *.vbs file and run it
| with executeglobal, if there is an error in that code, the error message
| does not give the line number.
|
| We therefore use the technique only when it seems the only way to
accomplish
| something, but we avoid doing anything really fancy with it for the
reasons
| you give above. Here's an example...

Yeah, the line 0 error return really bites. So does immediate error exit,
limited exit options, etc. I usually run the script separately in a
test.vbs file, when possible, before rewriting it as an execute string.
Those multiple "s can get to be a real pain. Besides, I've found execute to
be *very* slow when used for recursive functions. (I presume that all that
additional parsing finally adds up).

Regards,
Joe Earnest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03

[Al Dunbar [MS-MVP]]

"Joe Earnest" <jo**********@SPAMqwest.netPLEASE> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi Al,

Fully agree ...

[snipped] | Whether or not execute and executeglobal have unintended or undocumented
| effects is probably secondary to the fact that code using them can be
| difficult to debug. When our logon scripts read in a *.vbs file and run it | with executeglobal, if there is an error in that code, the error message
| does not give the line number.
|
| We therefore use the technique only when it seems the only way to
accomplish
| something, but we avoid doing anything really fancy with it for the
reasons
| you give above. Here's an example...

Yeah, the line 0 error return really bites. So does immediate error exit,
limited exit options, etc. I usually run the script separately in a
test.vbs file, when possible, before rewriting it as an execute string.
Those multiple "s can get to be a real pain. Besides, I've found execute to be *very* slow when used for recursive functions. (I presume that all that additional parsing finally adds up).

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.

/Al

[Joe Earnest]

Hi Al,

"Al Dunbar [MS-MVP]" <Al***************@hotmail.com> wrote in message
news:#1**************@tk2msftngp13.phx.gbl...
|
| 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

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 09-23-03

[Al Dunbar [MS-MVP]]

"Joe Earnest" <jo**********@SPAMqwest.netPLEASE> wrote in message
news:On**************@tk2msftngp13.phx.gbl...

Hi Al,

"Al Dunbar [MS-MVP]" <Al***************@hotmail.com> wrote in message
news:#1**************@tk2msftngp13.phx.gbl...
<snip>
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.

Cool, but certainly not for the faint-hearted! ;-)

/Al