Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11717 > unrolled thread

the "execute" command, arguments and returning a result. Possible ? If so, how ?

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 13:14 +0200
    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-22 13:41 +0200
      Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 14:16 +0200
    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Dave \"Crash\" Dummy" <invalid@invalid.invalid> - 2017-07-22 07:58 -0400
      Re: the "execute" command, arguments and returning a result.  Possible?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 14:29 +0200
    Re: the "execute" command, arguments and returning a result. Possible ? If so, how ? Ulrich Möller <knobbi38@arcor.de> - 2017-07-22 14:53 +0200
      Re: the "execute" command, arguments and returning a result. Possible? If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 16:28 +0200
        Re: the "execute" command, arguments and returning a result. Possible? If so, how ? Ulrich Möller <knobbi38@arcor.de> - 2017-07-23 13:49 +0200
          Re: the "execute" command, arguments and returning a result.Possible? If so, how ? "R.Wieser" <address@not.available> - 2017-07-24 08:29 +0200
    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? JJ <jj4public@vfemail.net> - 2017-07-22 19:58 +0700
      Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 16:52 +0200
    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Mayayana" <mayayana@invalid.nospam> - 2017-07-22 09:28 -0400
      Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-22 17:09 +0200
        Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Mayayana" <mayayana@invalid.nospam> - 2017-07-23 08:41 -0400
          Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-24 10:52 +0200
            Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Mayayana" <mayayana@invalid.nospam> - 2017-07-24 08:38 -0400
              Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-24 18:45 +0200
                Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-25 10:02 +0200
                  Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-25 14:18 +0200
                    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-25 23:42 +0200
                      Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-26 08:20 +0200
                        Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-26 10:21 +0200
                          Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-26 14:14 +0200
                            Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-26 19:34 +0200
                              Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-27 09:11 +0200
                                Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-07-27 09:18 +0200
                                  Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-07-27 12:44 +0200
                                    Re: the "execute" command, arguments and returning a result.  Possible ?  If so, how ? "R.Wieser" <address@not.available> - 2017-08-01 23:21 +0200

Page 1 of 2  [1] 2  Next page →

#11717 — the "execute" command, arguments and returning a result. Possible ? If so, how ?

I'm writing a script in which I want to execute some child scripts, and
return a result.  Like this:

result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)

Two things: I do not see any way to return such a result, nor do I see any
way to, if needed, provide arguments.

I'm aware that the executed script can just access and/or change some of its
parents data (scope permitting ofcourse), but I was wondering if I could
handle it more like an external function.

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#11718

"R.Wieser" <address@not.available> wrote on 22 Jul 2017 in
microsoft.public.scripting.vbscript: 

> I'm writing a script in which I want to execute some child scripts, and
> return a result.  Like this:
> 
> result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> 
> Two things: I do not see any way to return such a result, nor do I see
> any way to, if needed, provide arguments.
> 
> I'm aware that the executed script can just access and/or change some of
> its parents data (scope permitting ofcourse), but I was wondering if I
> could handle it more like an external function.


Methinks you need the second "Set" command,
so the execute does not receive the string in your code:

====== test.vbs =======

Set fso = CreateObject("Scripting.FileSystemObject")
Set theFile = fso.OpenTextFile("test.vbs")
MsgBox theFile.ReadAll
theFile.close

=======================


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11720

Evertjan,

> Methinks you need the second "Set" command,
> so the execute does not receive the string in your code:

Wel, I've already written and tested that part, and it works as posted
(inclusive displaying and modifying the parents data).   Also, if you whould
be right I'm rather certain I would have gotten some kind of (compile or
runtime) error thrown at me. :-)

The reason it works is because the "fso.OpenTextFile("test.vbs")" itself
returns an object, and even though its not (yet) copied into a users
variable its already available.  The ".readall" is just a method applied to
that object.

Though as the reference count for that object stays Zero it will be garbage
collected soon after the method terminates.

Regards,
Rudy Wieser


-- Origional message:
Evertjan. <exxjxw.hannivoort@inter.nl.net> schreef in berichtnieuws
XnsA7BA8B48B27C1eejj99@194.109.6.166...
> "R.Wieser" <address@not.available> wrote on 22 Jul 2017 in
> microsoft.public.scripting.vbscript:
>
> > I'm writing a script in which I want to execute some child scripts, and
> > return a result.  Like this:
> >
> > result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> >
> > Two things: I do not see any way to return such a result, nor do I see
> > any way to, if needed, provide arguments.
> >
> > I'm aware that the executed script can just access and/or change some of
> > its parents data (scope permitting ofcourse), but I was wondering if I
> > could handle it more like an external function.
>
>
> Methinks you need the second "Set" command,
> so the execute does not receive the string in your code:
>
> ====== test.vbs =======
>
> Set fso = CreateObject("Scripting.FileSystemObject")
> Set theFile = fso.OpenTextFile("test.vbs")
> MsgBox theFile.ReadAll
> theFile.close
>
> =======================
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11719

R.Wieser wrote:
> I'm writing a script in which I want to execute some child scripts, 
> and return a result.  Like this:
> 
> result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> 
> Two things: I do not see any way to return such a result, nor do I 
> see any way to, if needed, provide arguments.
> 
> I'm aware that the executed script can just access and/or change some
>  of its parents data (scope permitting ofcourse), but I was wondering
>  if I could handle it more like an external function.

I don't know if there is a more elegant way to do it, but I pass
arguments and results with text files. The parent and child scripts can
read and/or write the data files. The only tricky part is making sure the
data file is finished and closed before the receiving script tries to
access it. Here is a simple example of a parent script passing variables
to a child script which processes the data then passes it back to the
parent, which displays the processed data in a message box.

'=================== parent.vbs =========================
Set fso=WScript.CreateObject("Scripting.FileSystemObject")
Set datafile=fso.CreateTextFile("data.txt")
datafile.writeLine "Var1=10"
datafile.writeLine "Var2=20"
datafile.writeLine "Var3=30"
datafile.close

Set WshShell = WScript.CreateObject("WScript.Shell")
Return = WshShell.Run("childscript.vbs", 1, true)

Set datafile=fso.OpenTextFile("data.txt")
data=datafile.readAll
datafile.close
fso.deleteFile("data.txt")

  msgbox data

'=================childscript.vbs================
Set fso=WScript.CreateObject("Scripting.FileSystemObject")
Set datafile=fso.OpenTextFile("data.txt")
data=datafile.readAll
datafile.close
Set datafile=fso.CreateTextFile("data.txt")

lines=split(data,vbCRLF)
datafile.writeLine split(lines(0),"=")(0) & "=" & 
sqr(split(lines(0),"=")(1))
datafile.writeLine split(lines(1),"=")(0) & "=" & 
sqr(split(lines(1),"=")(1))
datafile.writeLine split(lines(2),"=")(0) & "=" & 
sqr(split(lines(2),"=")(1))
datafile.close

-- 
Crash

"Sometimes a cigar is just a cigar."
~ Sigmund Freud ~

[toc] | [prev] | [next] | [standalone]

#11721 — Re: the "execute" command, arguments and returning a result. Possible? If so, how ?

Dave,

>... but I pass arguments and results with text files.

That would be possible too

But than I would rather create a function which copies the needed arguments
to some function-local variables (possibly prefixed with "Loc" or something
like it), and have the child script access those.  No external files needed,
no problems in regard to possibly not being able to create the file, access
it or delete it after usage.

Hmmm ...   That makes realize that the above wrapping-in-a-function is
probably a good idea anyway, as than any DIMed variables by the child
process will be in the parent-functions scope, and not globally (and thus
get discarded after the fuction exists).

Regards,
Rudy Wieser


-- Origional message:
Dave "Crash" Dummy <invalid@invalid.invalid> schreef in berichtnieuws
okvedv$74f$1@dont-email.me...
> R.Wieser wrote:
> > I'm writing a script in which I want to execute some child scripts,
> > and return a result.  Like this:
> >
> > result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> >
> > Two things: I do not see any way to return such a result, nor do I
> > see any way to, if needed, provide arguments.
> >
> > I'm aware that the executed script can just access and/or change some
> >  of its parents data (scope permitting ofcourse), but I was wondering
> >  if I could handle it more like an external function.
>
> I don't know if there is a more elegant way to do it, but I pass
> arguments and results with text files. The parent and child scripts can
> read and/or write the data files. The only tricky part is making sure the
> data file is finished and closed before the receiving script tries to
> access it. Here is a simple example of a parent script passing variables
> to a child script which processes the data then passes it back to the
> parent, which displays the processed data in a message box.
>
> '=================== parent.vbs =========================
> Set fso=WScript.CreateObject("Scripting.FileSystemObject")
> Set datafile=fso.CreateTextFile("data.txt")
> datafile.writeLine "Var1=10"
> datafile.writeLine "Var2=20"
> datafile.writeLine "Var3=30"
> datafile.close
>
> Set WshShell = WScript.CreateObject("WScript.Shell")
> Return = WshShell.Run("childscript.vbs", 1, true)
>
> Set datafile=fso.OpenTextFile("data.txt")
> data=datafile.readAll
> datafile.close
> fso.deleteFile("data.txt")
>
>   msgbox data
>
> '=================childscript.vbs================
> Set fso=WScript.CreateObject("Scripting.FileSystemObject")
> Set datafile=fso.OpenTextFile("data.txt")
> data=datafile.readAll
> datafile.close
> Set datafile=fso.CreateTextFile("data.txt")
>
> lines=split(data,vbCRLF)
> datafile.writeLine split(lines(0),"=")(0) & "=" &
> sqr(split(lines(0),"=")(1))
> datafile.writeLine split(lines(1),"=")(0) & "=" &
> sqr(split(lines(1),"=")(1))
> datafile.writeLine split(lines(2),"=")(0) & "=" &
> sqr(split(lines(2),"=")(1))
> datafile.close
>
> --
> Crash
>
> "Sometimes a cigar is just a cigar."
> ~ Sigmund Freud ~

[toc] | [prev] | [next] | [standalone]

#11722 — Re: the "execute" command, arguments and returning a result. Possible ? If so, how ?

Hi Rudy,

Am 22.07.2017 um 13:14 schrieb R.Wieser:
> I'm writing a script in which I want to execute some child scripts, and
> return a result.  Like this:
>
> result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
>
> Two things: I do not see any way to return such a result, nor do I see any
> way to, if needed, provide arguments.
>
> I'm aware that the executed script can just access and/or change some of its
> parents data (scope permitting ofcourse), but I was wondering if I could
> handle it more like an external function.
Three possible ideas are explained here:
http://www.tek-tips.com/faqs.cfm?fid=5755

Ulrich

[toc] | [prev] | [next] | [standalone]

#11725 — Re: the "execute" command, arguments and returning a result. Possible? If so, how ?

Ulrich,

> Three possible ideas are explained here:

Thanks for the link (I just took a peek)..

IIRC I found that page too (did some googeling before posting the question
here :-) ), but discarded the suggestions because either they use external
means (environment variables, registry, files) which do not clean themselves
up, or are ment for usage within a special environment (webpage) (In my case
I run the script by simply double-clicking it).

Regards,
Rudy Wieser


-- Origional message:
Ulrich Möller <knobbi38@arcor.de> schreef in berichtnieuws
okvhl0$g8f$1@dont-email.me...
> Hi Rudy,
>
> Am 22.07.2017 um 13:14 schrieb R.Wieser:
> > I'm writing a script in which I want to execute some child scripts, and
> > return a result.  Like this:
> >
> > result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> >
> > Two things: I do not see any way to return such a result, nor do I see
any
> > way to, if needed, provide arguments.
> >
> > I'm aware that the executed script can just access and/or change some of
its
> > parents data (scope permitting ofcourse), but I was wondering if I could
> > handle it more like an external function.
> Three possible ideas are explained here:
> http://www.tek-tips.com/faqs.cfm?fid=5755
>
> Ulrich
>

[toc] | [prev] | [next] | [standalone]

#11728 — Re: the "execute" command, arguments and returning a result. Possible? If so, how ?

Hi Rudy,

Am 22.07.2017 um 16:28 schrieb R.Wieser:
> IIRC I found that page too (did some googeling before posting the question
> here:-)  ), but discarded the suggestions because either they use external
> means (environment variables, registry, files) which do not clean themselves
> up, or are ment for usage within a special environment (webpage) (In my case
> I run the script by simply double-clicking it).
but you will do need some kind of IPC Communication between the two 
independent scripts and therefor some external resources. You can wrap 
this things in a class which then automatically handles the cleanup of 
the used external resources.
Here is another idea, which uses e.x. named pipes or a html document 
object which is made available in an external ie process.
https://stackoverflow.com/questions/10943464/inter-process-communication-using-vbscript

I mean to remember that in some ibm scripting environments they uses 
specialized global com objects to accomplished this. They implemented 
something like a global session storage to hold data between several 
processes.

Ulrich

[toc] | [prev] | [next] | [standalone]

#11730 — Re: the "execute" command, arguments and returning a result.Possible? If so, how ?

Ulrich,

> but you will do need some kind of IPC Communication
> between the two independent scripts and therefor some
> external resources.

Nope and nope

As it turns out "execute" runs the code in the scope of the script/procedure
its called by, giving the executed code full acces to its "parents"
variables, as well as to any defined procedure in the script itself.

In other words, the contents provided to "execute" are run as if its part of
the script/procedure the command is run in.

Try it yourself. :-)

Regards,
Rudy Wieser





Ulrich Möller <knobbi38@arcor.de> schreef in berichtnieuws
ol228t$fjl$1@dont-email.me...
> Hi Rudy,
>
> Am 22.07.2017 um 16:28 schrieb R.Wieser:
> > IIRC I found that page too (did some googeling before posting the
question
> > here:-)  ), but discarded the suggestions because either they use
external
> > means (environment variables, registry, files) which do not clean
themselves
> > up, or are ment for usage within a special environment (webpage) (In my
case
> > I run the script by simply double-clicking it).
>
> but you will do need some kind of IPC Communication between the two
> independent scripts and therefor some external resources. You can wrap
> this things in a class which then automatically handles the cleanup of
> the used external resources.
> Here is another idea, which uses e.x. named pipes or a html document
> object which is made available in an external ie process.
>
https://stackoverflow.com/questions/10943464/inter-process-communication-usi
ng-vbscript
>
> I mean to remember that in some ibm scripting environments they uses
> specialized global com objects to accomplished this. They implemented
> something like a global session storage to hold data between several
> processes.
>
> Ulrich

[toc] | [prev] | [next] | [standalone]

#11723

On Sat, 22 Jul 2017 13:14:29 +0200, R.Wieser wrote:
> I'm writing a script in which I want to execute some child scripts, and
> return a result.  Like this:
> 
> result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> 
> Two things: I do not see any way to return such a result, nor do I see any
> way to, if needed, provide arguments.
> 
> I'm aware that the executed script can just access and/or change some of its
> parents data (scope permitting ofcourse), but I was wondering if I could
> handle it more like an external function.
> 
> Regards,
> Rudy Wieser

WHSRemote.Execute() doesn't return any value. Also, it expects a command
line, not a script code.

To execute a script code, use the Eval() function.

[toc] | [prev] | [next] | [standalone]

#11726

JJ,

> WHSRemote.Execute() doesn't return any value.

I am using (the local) "execute" (no object prefix) method, an must have
misread myself in regard to a returned result (thought I read it, can't find
it back anymore ...).

> Also, it expects a command line, not a script code.

I'm not sure at all what the difference is between what you refer to as "a
command line", or "a script code".

If you mean it needs to be a single line than thats not the case.   It
happily accepts more than one line, as long as they are, as in a standard
script, seperated by line terminators (vbCRLF).  In fact, the
'ChildScript.vbs' file from my test contains a copy-paste of the contents of
a 'Sub' from the main script, which has worked rather well.

> To execute a script code, use the Eval() function.

Not so.   "Eval" is ment for (simple, one-line?) *comparisions* (returning a
True or False).   "Execute" can do a bit more than that (its just not
returning anything). :-)

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1k885nicv1e2d.ybdaa311qp1o$.dlg@40tude.net...
> On Sat, 22 Jul 2017 13:14:29 +0200, R.Wieser wrote:
> > I'm writing a script in which I want to execute some child scripts, and
> > return a result.  Like this:
> >
> > result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> >
> > Two things: I do not see any way to return such a result, nor do I see
any
> > way to, if needed, provide arguments.
> >
> > I'm aware that the executed script can just access and/or change some of
its
> > parents data (scope permitting ofcourse), but I was wondering if I could
> > handle it more like an external function.
> >
> > Regards,
> > Rudy Wieser
>
> WHSRemote.Execute() doesn't return any value. Also, it expects a command
> line, not a script code.
>
> To execute a script code, use the Eval() function.

[toc] | [prev] | [next] | [standalone]

#11724

"R.Wieser" <address@not.available> wrote

| I'm writing a script in which I want to execute some child scripts, and
| return a result.  Like this:
|
| result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
|
| Two things: I do not see any way to return such a result, nor do I see any
| way to, if needed, provide arguments.
|

  I don't know if this will be useful, but I use external
scripts for a few things. One example:

Private Sub SleepX(MSecs)
  Dim Ret1
    On Error Resume Next
    Ret1 = SHcc.Run("sleeper.vbs " & MSecs, , True)
End Sub

SHcc is WScript.Shell. I call it like SleepX "500"
It runs a VBS file that reads wscript.argument(0)
and does a Sleep for that period of time. Since I'm
waiting for return it becomes a way to call Sleep
in an HTA, which provides no other such option.

  I do similar with 7-Zip, after finding that 7-Zip
run from an HTA or script wouldn't quit until the
HTA closed. So I run it from an external script and
wait for the return.

  I also use ExecuteGlobal to add classes into a
script. But I can't think of any simple way to return
values from a script that's running in a different
process. That probably requires an ugly hack.

| I'm aware that the executed script can just access and/or change some of 
its
| parents data (scope permitting ofcourse), but I was wondering if I could
| handle it more like an external function.
|
    I wonder why you need it to be external. Typically
such a thing would be needed to wrap complex
functionality, as with a DLL, in order to keep the
main process simpler. But you could do that
just as easily by using ExecuteGlobal on a class
script. 

[toc] | [prev] | [next] | [standalone]

#11727

Mayayana,

>   I don't know if this will be useful, but I use external
> scripts for a few things.

I do too, and would normally have used it.   But in this case I wanted to
run an "external" script, while still allowing it access to procedures and
functions in the main script.

>   I also use ExecuteGlobal to add classes into a
> script. But I can't think of any simple way to return
> values from a script that's running in a different
> process.

I also found that (tried to see if I could add the "external" code as a
seperate procedure in the main script -- but still call it by its string
name), and ran into the same problem. :-\

>     I wonder why you need it to be external. Typically
> such a thing would be needed to wrap complex
> functionality,

Pretty-much exactly that.   The main script reads several webpages, and
depending on the accessed webpage I need to parse it differently (to extract
the sought-for data).

Yes, I *could* put everything in the main script (using a 'select case'),
but this time I wanted to see if I could do it differently.   If only so I
can easily add-and-remove specific parsing, without having to touch the main
script.

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
okvjnr$muc$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | I'm writing a script in which I want to execute some child scripts, and
> | return a result.  Like this:
> |
> | result = execute(oFS.OpenTextFile("childscript.vbs").ReadAll)
> |
> | Two things: I do not see any way to return such a result, nor do I see
any
> | way to, if needed, provide arguments.
> |
>
>   I don't know if this will be useful, but I use external
> scripts for a few things. One example:
>
> Private Sub SleepX(MSecs)
>   Dim Ret1
>     On Error Resume Next
>     Ret1 = SHcc.Run("sleeper.vbs " & MSecs, , True)
> End Sub
>
> SHcc is WScript.Shell. I call it like SleepX "500"
> It runs a VBS file that reads wscript.argument(0)
> and does a Sleep for that period of time. Since I'm
> waiting for return it becomes a way to call Sleep
> in an HTA, which provides no other such option.
>
>   I do similar with 7-Zip, after finding that 7-Zip
> run from an HTA or script wouldn't quit until the
> HTA closed. So I run it from an external script and
> wait for the return.
>
>   I also use ExecuteGlobal to add classes into a
> script. But I can't think of any simple way to return
> values from a script that's running in a different
> process. That probably requires an ugly hack.
>
> | I'm aware that the executed script can just access and/or change some of
> its
> | parents data (scope permitting ofcourse), but I was wondering if I could
> | handle it more like an external function.
> |
>     I wonder why you need it to be external. Typically
> such a thing would be needed to wrap complex
> functionality, as with a DLL, in order to keep the
> main process simpler. But you could do that
> just as easily by using ExecuteGlobal on a class
> script.
>
>

[toc] | [prev] | [next] | [standalone]

#11729

"R.Wieser" <address@not.available> wrote

| >   I don't know if this will be useful, but I use external
| > scripts for a few things.
|
| I do too, and would normally have used it.   But in this case I wanted to
| run an "external" script, while still allowing it access to procedures and
| functions in the main script.
|

   It would help if you'd explain what you're actually
to do with these questions. Since you're always
secretive people can only offer wild guesses.

[toc] | [prev] | [next] | [standalone]

#11731

Mayayana,

>    It would help if you'd explain what you're actually
> to do with these questions.

Nothing.   Its the answers I need.  :-)

> Since you're always secretive people can only offer wild guesses.

Bullshit.

#1: I've asked if the "execute" command can return a result, as wel as
accept arguments.   Whats "secretive" about that, and how would that force
you to do "wild guesses" ?

 If you do not know than say so.  If you have (MSDN) documentation stating
pro or con even better.   If you need question-specific info than specify
and I will try to provide it (even if I have to create-and-post some example
code).

#2: I do not (initially) mention what I'm using it for as I find that rather
irrelevant.  I have the need to know *what the command does* so I can use it
whenever I please (now, but also in the future in other circumstances), not
what I can plug into my current script to get it to run (as I already
mentioned, I could use a more mundane "select case" instead.  In other
words, getting a script of mine to run is NOT any of my problems).

#3: I've asked questions her long enough to become aware that most people
get rather confused when being provided with too much information, leading
to all kinds of "answers" which have got nothing to do with the question and
are infact just interference.

In short: the question I'm posting is exactly what what I want/need to have
answered.   No more, no less.   Simple, no ?

In this case a simple "no" accompanied by a short explanation why ("you do
not need them because ...") would most likely have sufficed.

Just outof curiositry, what did you *think* I asked (if you can put that
into words) ?


And to be honest about it, I assumed that "execute" would run the provided
script in its own scope. Which either forces the need for arguments and data
returnal, or needs some kind of (awkward) IPC mechanism (as Ulrich is
suggesting).

But as I was wrong in that and it runs in the scope of the script/procedure
its called by (meaning it can read, write and alter its "parents" variables)
arguments and return values are not needed.

.... which I already mentioned in the last paragraph of my third post in
this thread.    In other words, the problem I thought I had (needing
arguments and returned data) wasn't actually there.   I just didn't quite
realize it at that moment -- and neither did you. :-\

Bottom line: The problem has been solved.   By yours truly.  Again.

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
ol25bi$p45$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | >   I don't know if this will be useful, but I use external
> | > scripts for a few things.
> |
> | I do too, and would normally have used it.   But in this case I wanted
to
> | run an "external" script, while still allowing it access to procedures
and
> | functions in the main script.
> |
>
>    It would help if you'd explain what you're actually
> to do with these questions. Since you're always
> secretive people can only offer wild guesses.

[toc] | [prev] | [next] | [standalone]

#11732

"R.Wieser" <address@not.available> wrote

| I do not (initially) mention what I'm using it for as I find that rather
| irrelevant.

   It's customary in programming groups to explain
what the project is, to help avoid misunderstandings
and wrong assumptions -- on both sides.

| I have the need to know *what the command does* so I can use it
| whenever I please

 You could have figured that out with a simple test.
You could have also figured out the scope with a
simple test. So here we are again: If you'd explained
your purpose then someone probably would have
caught your oversight.

| Bottom line: The problem has been solved.   By yours truly.  Again.
|

   Imagine my surprise. You're undoubtedly
the smartest guy you know. 

[toc] | [prev] | [next] | [standalone]

#11733

Mayayana,

>    It's customary in programming groups to explain
> what the project is, to help avoid misunderstandings
> and wrong assumptions -- on both sides.

From my experience its also customary for programming groups to go off in
tangents that have *nothing* to do with the question -- which is why I, as
I've explained and you now ignored, stopped providing it.

Take Evertjan for example.  Good intentions, but he focussed on something
not even remotely related to the question, assuming that what I posted as an
example c/would not work.

Dave, nonwithstanding his good intentions, focussed on presenting a series
of absolute horrible DOS-era IPC solutions where none was needed (I
mentioned in my OP that I could access the "parents" data) -- though he
caused me to realize I could simly wrap the command in a function, thereby
giving its variables a local scope, which helped me further.

Ulrich, with the same good intentions, suggested to use the "run" command,
which was definitily not what I asked for.

And you ?  You suggested the same ...  Why ?


As for the misunderstandings and wrong assumptions ?   Which ones did *you*
make ?   And for gods sake, how ?   Was my question not clear ?    If not,
what do you think I *should* have asked ?

And if you know what I *should* have asked, why didn't you let me know ?

> | I have the need to know *what the command does* so I can use
> | it whenever I please
>
> You could have figured that out with a simple test.

Figure *what* out please ?    You seem to know, I have no idea what you are
hinting at there.

> You could have also figured out the scope with a simple test.

As my old teacher always said "measuring is knowing".  Which he always
followed up with "if you know what you're measuring ...".   In other words:
to be able to test something you must first be aware that there is something
to test and how.

As for testing that scope ?   What has that got to do with the question ?
Or with the top-half of my previous post ?

Or are you just trying to find something to complain about, trying to
cover-up your own flaws ?   And a nice one: I acknowledged that I'm not a
know-it-all, and you're bashing me for it.   Good show kid. Not.

> If you'd explained your purpose then someone probably
> would have caught your oversight.

Which oversight please ?    And if you do not know exactly which one, care
to mention which ones I *could* have made ? -- You seem to be the expert
here.

You can't ?   Than (again) don't bullshit me please.

> | Bottom line: The problem has been solved.   By yours truly.  Again.
>
>    Imagine my surprise.
> You're undoubtedly the smartest guy you know.

Not by a long shot.   I regard myself as mediocre at best (even though my
friends do not believe I'm serious in that).

But it *is* (a bit of) remarkable that even though I had to figure out
everything myself (and probably have stumbled into every pitfall there is
along the way) I was able to reach the answer before you could.


And odd.   You (obviously) consider yourself knowledgable enough to respond
to a "I have never used this command an could use some help understanding
it" -level question like mine, but than are unable to use all that expertise
to figure out what the question is actually all about (but at the same have
not bothered to ask clarification of it) ...

And no, no need to reply to this.   I will read it if you do, but thats most
likely all.

Regards,
Rudy Wieser


-- Origional message
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
ol4pgv$2eu$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | I do not (initially) mention what I'm using it for as I find that rather
> | irrelevant.
>
>    It's customary in programming groups to explain
> what the project is, to help avoid misunderstandings
> and wrong assumptions -- on both sides.
>
> | I have the need to know *what the command does* so I can use it
> | whenever I please
>
>  You could have figured that out with a simple test.
> You could have also figured out the scope with a
> simple test. So here we are again: If you'd explained
> your purpose then someone probably would have
> caught your oversight.
>
> | Bottom line: The problem has been solved.   By yours truly.  Again.
> |
>
>    Imagine my surprise. You're undoubtedly
> the smartest guy you know.
>
>

[toc] | [prev] | [next] | [standalone]

#11734

"R.Wieser" <address@not.available> wrote on 24 Jul 2017 in
microsoft.public.scripting.vbscript: 

> Take Evertjan for example.  Good intentions, but he focussed on
> something not even remotely related to the question, assuming that what
> I posted as an example c/would not work.

No, don't take me as an example, take Netiquette, because this in Usenet.

[And please don't engage in the ad-hominem falacy of taking me in stead of 
my posting as an example, because that is false, impolite and not even a 
valid pars pro toto.]

I don't care about your idea of intentions, because you seem to think this 
NG is an helpdesk, where one should respond with an answer and more so 
within the confines the OP posed.

This NG is a discussion group, and the confines are the bounderies of being 
on topic. And the audience is the group, not the OP. If one wants to respond 
to the person sepecifically, use email or what[sapp]ever, not the NG.

On topic is VBS [specific to this group] and the Netiquete [specific to the 
whole of usenet].

So if I think it is proper to focus on something else than your intentions, 
whether I misunderstood your intentions or not [I am not your date], or 
whether I misassumed your example or not, that is also not a matter of your 
right of getting a response to your liking, because such a right does not 
exist on usenet. This NG is not a paid or unpaid helpdesk.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11735

Evertjan,

> No, don't take me as an example

Too late, I just did.
Or rather, I took something you posted as an example.

> [And please don't engage in the ad-hominem falacy of taking me
> in stead of my posting as an example

Ah, I'm sorry.  I was not aware that when you make an example of what
someone wrote that to mention that someones name with it automatically makes
it an at-hominem attack.   <said with a light sauce of sarcasm>

But no, it isn't, and was not even ment as such.  The only reason I
mentioned your name with that example was to give Mayayana (or anyone else)
a chance to easily find the context (read: the specific post) back.

So don't make it sound as if it was all about *you*.  It wasn't.

> I don't care about your idea of intentions, because you seem to think
> this NG is an helpdesk, where one should respond with an answer and
> more so within the confines the OP posed.

You already *know* that what you say there is (far) besides the truth.   If
it would have been than I could/would possibly have chewed your head off for
it, and *certainly not* have responded to you trying to explain why it
actually does work.

> So if I think it is proper to focus on something else than your
intentions,
> whether I misunderstood your intentions or not [I am not your date],
> or whether I misassumed your example or not, that is also not a matter
> of your right of getting a response to your liking,

I make you a deal: Show me where I tried to chew you out (directly or
indirectly) for not having responded "in the confines of my intention"**,
and I will donate a E 100,- to a charity of your choice.    *Thats* how
certain I am I never did so.

**and no, mentioning your response together with your name to someone else
in this thread does not constitute any such thing.

Yes, you made a mistake (if it can even be called that).  Big deal, everyone
does, especially me included.  But although you *could* have checked
yourself before posting about it**, you did so with the best of intentions:
to help me.   And I accepted, and replied to it in that vein.  To in turn
try to help (educate) you.

**though that actually did ruffle my feathers a bit ...

And that makes me wonder what it is you got all riled up about ...   Care to
explain ?

Regards,
Rudy Wieser


-- Origional message:
Evertjan. <exxjxw.hannivoort@inter.nl.net> schreef in berichtnieuws
XnsA7BD661B4424Deejj99@194.109.6.166...
> "R.Wieser" <address@not.available> wrote on 24 Jul 2017 in
> microsoft.public.scripting.vbscript:
>
> > Take Evertjan for example.  Good intentions, but he focussed on
> > something not even remotely related to the question, assuming that what
> > I posted as an example c/would not work.
>
> No, don't take me as an example, take Netiquette, because this in Usenet.
>
> [And please don't engage in the ad-hominem falacy of taking me in stead of
> my posting as an example, because that is false, impolite and not even a
> valid pars pro toto.]
>
> I don't care about your idea of intentions, because you seem to think this
> NG is an helpdesk, where one should respond with an answer and more so
> within the confines the OP posed.
>
> This NG is a discussion group, and the confines are the bounderies of
being
> on topic. And the audience is the group, not the OP. If one wants to
respond
> to the person sepecifically, use email or what[sapp]ever, not the NG.
>
> On topic is VBS [specific to this group] and the Netiquete [specific to
the
> whole of usenet].
>
> So if I think it is proper to focus on something else than your
intentions,
> whether I misunderstood your intentions or not [I am not your date], or
> whether I misassumed your example or not, that is also not a matter of
your
> right of getting a response to your liking, because such a right does not
> exist on usenet. This NG is not a paid or unpaid helpdesk.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#11736

"R.Wieser" <address@not.available> wrote on 25 Jul 2017 in
microsoft.public.scripting.vbscript: 

> Evertjan,
> 
>> No, don't take me as an example
> 
> Too late, I just did.

Why too late? It's never too late to repend.

> Or rather, I took something you posted as an example.

The latter is okay. But you did not, you took me as an example.

>> [And please don't engage in the ad-hominem falacy of taking me
>> in stead of my posting as an example
> 
> Ah, I'm sorry.  I was not aware that when you make an example of what
> someone wrote that to mention that someones name with it automatically
> makes it an at-hominem attack.  

That you were not aware of it is not an argument against it,
you could have missed something and/or just be wrong.

> <said with a light sauce of sarcasm>

Are you a cook?

> But no, it isn't,

I contest that. 

> and was not even ment as such. 

That's fine, but the 'even' is illogical 
as could very weel be ment as such while you think it is not.

> The only reason I
> mentioned your name with that example was to give Mayayana (or anyone
> else) a chance to easily find the context (read: the specific post)
> back. 

You could have mentioned my name by saying that you disagraad with me on a 
subject, inferring the ad-hominem falacy was unnecessary and impolite.

> So don't make it sound as if it was all about *you*.  It wasn't.

I don't, but you just were impolite and should appologise.

>> I don't care about your idea of intentions, because you seem to think
>> this NG is an helpdesk,

Strange conclusion, as I stated it is not.

>> where one should respond with an answer and
>> more so within the confines the OP posed.

> You already *know* that what you say there is (far) besides the truth. 

So now you pretant to klow hat I know,how strange.
 
> If it would have been than I could/would possibly have chewed your head
> off for it, and *certainly not* have responded to you trying to explain
> why it actually does work.

This sentence sounds like you are just babbling around.

[> ...]

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web