how to create an Array with parametrized name?

[Joe Earnest]

Re: how to create an Array with parametrized name?

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]

Re: how to create an Array with parametrized name?

nobody wrote:
[color=blue]
> 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.[/color]

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]

Re: how to create an Array with parametrized name?

hello Gerry
[color=blue]
> 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.
>[/color]

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]]

Re: how to create an Array with parametrized name?


"Joe Earnest" <joeearnestNO@S PAMqwest.netPLE ASE> wrote in message
news:%23x69kY$v DHA.2316@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> 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.[/color]

This probably explains away much of our disagreement...

<snip>
[color=blue]
> | > (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.[/color]

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.
[color=blue]
> 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[/color]
development,[color=blue]
> however, all the undocumented effects may be fair game - execute, omitted
> user-defined procedure arguments, error scoping, etc. ;-)[/color]

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_lo calVariable"
if ( isempty( functionName_lo calVariable ) ) then
' code to initialize variable "functionName_l ocalVariable"
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.
[color=blue]
> | > 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[/color]
was[color=blue]
> | 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.[/color]

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]

Re: how to create an Array with parametrized name?

Hi Al,

Fully agree ...

[snipped]

"Al Dunbar [MS-MVP]" <Alan-no-Drub-spam@hotmail.co m> wrote in message
news:OrJUsjRwDH A.2080@TK2MSFTN GP10.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]]

Re: how to create an Array with parametrized name?


"Joe Earnest" <joeearnestNO@S PAMqwest.netPLE ASE> wrote in message
news:%23X9WKbZw DHA.2464@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> Hi Al,
>
> Fully agree ...
>
> [snipped][/color]
[color=blue]
> | 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[/color]
it[color=blue]
> | 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[/color]
to[color=blue]
> be *very* slow when used for recursive functions. (I presume that all[/color]
that[color=blue]
> additional parsing finally adds up).[/color]

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]

Re: how to create an Array with parametrized name?

Hi Al,

"Al Dunbar [MS-MVP]" <Alan-no-Drub-spam@hotmail.co m> wrote in message
news:#1cVPBawDH A.1424@tk2msftn gp13.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]]

Re: how to create an Array with parametrized name?


"Joe Earnest" <joeearnestNO@S PAMqwest.netPLE ASE> wrote in message
news:OnZnj4awDH A.3536@tk2msftn gp13.phx.gbl...[color=blue]
> Hi Al,
>
> "Al Dunbar [MS-MVP]" <Alan-no-Drub-spam@hotmail.co m> wrote in message
> news:#1cVPBawDH A.1424@tk2msftn gp13.phx.gbl...[/color]

<snip>
[color=blue]
> 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[/color]
require[color=blue]
> 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[/color]
function-method[color=blue]
> simply "executes" the user-defined script assigned to the property, when[/color]
the[color=blue]
> button is clicked.[/color]

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

/Al