I would like to code a vbscript ("ActionScript.vbs") in such a way that it
would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but do
something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".

Is there some way by which ActionScript.vbs could identify the
program/process that called ActionScript.vbs?

If the answer is "yes", that would be useful in many contexts.

For example, it would be useful in the context of Hta programming, where (I
think) a button (that calls a vbscript inside the Hta file) cannot send
arguments to the vbscript sub that the button calls. Thus, each button has
to have its own sub. As my Hta files grow in size, the proliferation of subs
makes it more difficult to keep track of them, and I worry about ram or
resource usage being wasted.

By contrast, if a sub (that opens a shell and calls exe files) could "smell"
which button called the sub, I'd need only one sub (that opens a shell and
calls exe files) and it could have a nice alphabetically sorted set of Case
Selects, that would call the right exe files.

Identifying the process would be useful in other contexts too. I have a
growing library of backup scripts that backup files and folders at various
times. I would like the script to be able to know when it was called by
another script, as distinguished from being called by me double clicking on
the vbscript in Windows explorer.


Thanks,

Marc






--
MarceepooNu

"MarceepooNu" <mbh2010@newsgroup> wrote in message
news:743FF7A5-8729-411D-838D-B8808BA2A8CB@newsgroup

> I would like to code a vbscript ("ActionScript.vbs") in such a way that it
> would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but
> do
> something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".
>
> Is there some way by which ActionScript.vbs could identify the
> program/process that called ActionScript.vbs?
>
> If the answer is "yes", that would be useful in many contexts.
>
> For example, it would be useful in the context of Hta programming, where
> (I
> think) a button (that calls a vbscript inside the Hta file) cannot send
> arguments to the vbscript sub that the button calls. Thus, each button
> has
> to have its own sub. As my Hta files grow in size, the proliferation of
> subs
> makes it more difficult to keep track of them, and I worry about ram or
> resource usage being wasted.
>
> By contrast, if a sub (that opens a shell and calls exe files) could
> "smell"
> which button called the sub, I'd need only one sub (that opens a shell and
> calls exe files) and it could have a nice alphabetically sorted set of
> Case
> Selects, that would call the right exe files.
>
> Identifying the process would be useful in other contexts too. I have a
> growing library of backup scripts that backup files and folders at various
> times. I would like the script to be able to know when it was called by
> another script, as distinguished from being called by me double clicking
> on
> the vbscript in Windows explorer.
>
>
> Thanks,
>
> Marc

Perhaps the property wscript.FullName?

"MarceepooNu" <mbh2010@newsgroup> wrote in message
news:743FF7A5-8729-411D-838D-B8808BA2A8CB@newsgroup

>I would like to code a vbscript ("ActionScript.vbs") in such a way that it
> would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but
> do
> something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".
>
> Is there some way by which ActionScript.vbs could identify the
> program/process that called ActionScript.vbs?
>
> If the answer is "yes", that would be useful in many contexts.
>
> For example, it would be useful in the context of Hta programming, where
> (I
> think) a button (that calls a vbscript inside the Hta file) cannot send
> arguments to the vbscript sub that the button calls. Thus, each button
> has
> to have its own sub. As my Hta files grow in size, the proliferation of
> subs
> makes it more difficult to keep track of them, and I worry about ram or
> resource usage being wasted.
>
> By contrast, if a sub (that opens a shell and calls exe files) could
> "smell"
> which button called the sub, I'd need only one sub (that opens a shell and
> calls exe files) and it could have a nice alphabetically sorted set of
> Case
> Selects, that would call the right exe files.
>
> Identifying the process would be useful in other contexts too. I have a
> growing library of backup scripts that backup files and folders at various
> times. I would like the script to be able to know when it was called by
> another script, as distinguished from being called by me double clicking
> on
> the vbscript in Windows explorer.

Here is some info on the HTA part of your problem:
Take a look at the DHTML reference, most of which applies to HTAs.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
The code associated with a button is activated by the onclick event:
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

For a useful, non-trivial example of the kinds of things that can be done
with the onclick event in an HTA, download and play with and look at the
code of HTA Helpomatic:
http://www.microsoft.com/downloads/d...3-ae7b9152e6d9
Its a long URL, so watch out for wrap.

Going to msdn.microsoft.com and searching for the two words: hta vbscript,
returns 574 entries for articles, many of which may be helpful. Clicking on
the code search button on that search results page gives you links to 75
files that probably contain some HTA/VBScript code examples.

-Paul Randall

MarceepooNu wrote:

>I would like to code a vbscript ("ActionScript.vbs") in such a way that it
> would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but
> do
> something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".
>
> Is there some way by which ActionScript.vbs could identify the
> program/process that called ActionScript.vbs?
>
> If the answer is "yes", that would be useful in many contexts.
>
> For example, it would be useful in the context of Hta programming, where
> (I
> think) a button (that calls a vbscript inside the Hta file) cannot send
> arguments to the vbscript sub that the button calls. Thus, each button
> has
> to have its own sub. As my Hta files grow in size, the proliferation of
> subs
> makes it more difficult to keep track of them, and I worry about ram or
> resource usage being wasted.
>
> By contrast, if a sub (that opens a shell and calls exe files) could
> "smell"
> which button called the sub, I'd need only one sub (that opens a shell and
> calls exe files) and it could have a nice alphabetically sorted set of
> Case
> Selects, that would call the right exe files.
>
> Identifying the process would be useful in other contexts too. I have a
> growing library of backup scripts that backup files and folders at various
> times. I would like the script to be able to know when it was called by
> another script, as distinguished from being called by me double clicking
> on
> the vbscript in Windows explorer.

Basically, your query boils down to:
How to determine if a script was double clicked or run by another script?

The author of a script has the option to provide an argument when calling
another script. Double clicking runs a script without arguments, so if you
have the Trigger scripts provide their name as an argument when calling the
ActionScript, the ActionScript could use the Wscript.Arguments object to see
which TriggerScript, if any, was used.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

This passes the value of - Hello - to the "Sub Run"

<!--Button-->
<input type="button" name="btnRun" id="btnRun" value="Run"
onclick="Run('Hello')">


Sub Run(strArg)
MsgBox Chr(34) & strArg & Chr(34)
End Sub

Dear Pegasus:

First, thank you for replying.

"Msgbox wscript.fullname" will return the fullname (path + name + ext) of
the script in which the "Msgbox wscript.fullname" line resides.

wscript.fullname won't port the fullname info from TriggerScriptA.vbs to
ActionScript.vbs, unless an "argument methodology" (to coin a term) is
employed by both scripts (one script sending the argument via command line,
and the other script using the usual code for harvesting arguments [For Each
strArgument in Wscript.Arguments; a = strArgument; Next]).

I bet that there is some memory register/registry/location/thingamajig,
where the calling program temporarily records its name and the name of the
target program, but I speak so confidently only because I speak from abject
ignorance.

My guess is that vbscript doesn't readily provide access to such info, even
if such info exists, and is available thru some other program (e.g., vb.net,
powershell etc).

Marc
--
MarceepooNu


"Pegasus [MVP]" wrote:

>
>
> "MarceepooNu" <mbh2010@newsgroup> wrote in message
> news:743FF7A5-8729-411D-838D-B8808BA2A8CB@newsgroup

> > I would like to code a vbscript ("ActionScript.vbs") in such a way that it
> > would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but
> > do
> > something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".
> >
> > Is there some way by which ActionScript.vbs could identify the
> > program/process that called ActionScript.vbs?
> >
> > If the answer is "yes", that would be useful in many contexts.
> >
> > For example, it would be useful in the context of Hta programming, where
> > (I
> > think) a button (that calls a vbscript inside the Hta file) cannot send
> > arguments to the vbscript sub that the button calls. Thus, each button
> > has
> > to have its own sub. As my Hta files grow in size, the proliferation of
> > subs
> > makes it more difficult to keep track of them, and I worry about ram or
> > resource usage being wasted.
> >
> > By contrast, if a sub (that opens a shell and calls exe files) could
> > "smell"
> > which button called the sub, I'd need only one sub (that opens a shell and
> > calls exe files) and it could have a nice alphabetically sorted set of
> > Case
> > Selects, that would call the right exe files.
> >
> > Identifying the process would be useful in other contexts too. I have a
> > growing library of backup scripts that backup files and folders at various
> > times. I would like the script to be able to know when it was called by
> > another script, as distinguished from being called by me double clicking
> > on
> > the vbscript in Windows explorer.
> >
> >
> > Thanks,
> >
> > Marc

>
> Perhaps the property wscript.FullName?
>
> .
>

Dear Paul:

Before I posted the question, I spent a lot of time hunting around on the
web in general, and in Microsoft.com in particular. But it didn't occur to
me to focus on the onclick Event. I bet that that will lead me to what I'm
looking for. I feel both grateful for the information, and stupid/lazy for
not having found it myself. Thanks. Much appreciated.

Marc



marc


--
MarceepooNu


"Paul Randall" wrote:

>
> "MarceepooNu" <mbh2010@newsgroup> wrote in message
> news:743FF7A5-8729-411D-838D-B8808BA2A8CB@newsgroup

> >I would like to code a vbscript ("ActionScript.vbs") in such a way that it
> > would do X, if ActionScript.vbs were called by "TriggerScriptA.vbs", but
> > do
> > something else if ActionScript.vbs were called by "TriggerScriptAB.vbs".
> >
> > Is there some way by which ActionScript.vbs could identify the
> > program/process that called ActionScript.vbs?
> >
> > If the answer is "yes", that would be useful in many contexts.
> >
> > For example, it would be useful in the context of Hta programming, where
> > (I
> > think) a button (that calls a vbscript inside the Hta file) cannot send
> > arguments to the vbscript sub that the button calls. Thus, each button
> > has
> > to have its own sub. As my Hta files grow in size, the proliferation of
> > subs
> > makes it more difficult to keep track of them, and I worry about ram or
> > resource usage being wasted.
> >
> > By contrast, if a sub (that opens a shell and calls exe files) could
> > "smell"
> > which button called the sub, I'd need only one sub (that opens a shell and
> > calls exe files) and it could have a nice alphabetically sorted set of
> > Case
> > Selects, that would call the right exe files.
> >
> > Identifying the process would be useful in other contexts too. I have a
> > growing library of backup scripts that backup files and folders at various
> > times. I would like the script to be able to know when it was called by
> > another script, as distinguished from being called by me double clicking
> > on
> > the vbscript in Windows explorer.

>
>
> Here is some info on the HTA part of your problem:
> Take a look at the DHTML reference, most of which applies to HTAs.
> http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
> The code associated with a button is activated by the onclick event:
> http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
>
> For a useful, non-trivial example of the kinds of things that can be done
> with the onclick event in an HTA, download and play with and look at the
> code of HTA Helpomatic:
> http://www.microsoft.com/downloads/d...3-ae7b9152e6d9
> Its a long URL, so watch out for wrap.
>
> Going to msdn.microsoft.com and searching for the two words: hta vbscript,
> returns 574 entries for articles, many of which may be helpful. Clicking on
> the code search button on that search results page gives you links to 75
> files that probably contain some HTA/VBScript code examples.
>
> -Paul Randall
>
>
> .
>

Thank you. Very very helpful.

Marc
--
MarceepooNu


"LikeToCode" wrote:

> This passes the value of - Hello - to the "Sub Run"
>
> <!--Button-->
> <input type="button" name="btnRun" id="btnRun" value="Run"
> onclick="Run('Hello')">
>
>
> Sub Run(strArg)
> MsgBox Chr(34) & strArg & Chr(34)
> End Sub
>
>
>

MarceepooNu wrote:

> Dear Pegasus:
>
> First, thank you for replying.
>
> "Msgbox wscript.fullname" will return the fullname (path + name + ext) of
> the script in which the "Msgbox wscript.fullname" line resides.
>
> wscript.fullname won't port the fullname info from TriggerScriptA.vbs to
> ActionScript.vbs, unless an "argument methodology" (to coin a term) is
> employed by both scripts (one script sending the argument via command
> line,
> and the other script using the usual code for harvesting arguments [For
> Each
> strArgument in Wscript.Arguments; a = strArgument; Next]).

Correct. As the programmer, it it up to you to provide the means necessary
to acomplish your task.

>
> I bet that there is some memory register/registry/location/thingamajig,
> where the calling program temporarily records its name and the name of the
> target program, but I speak so confidently only because I speak from
> abject
> ignorance.
>
> My guess is that vbscript doesn't readily provide access to such info,
> even
> if such info exists, and is available thru some other program (e.g.,
> vb.net,
> powershell etc).

AFAIK, there is no such register that vbscript can poll.
If you come to the same conclusion, try using Wscript.Arguments to complete
this task.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

In addition to the previous answer.

You can always examine the `event' object within you event handler
function. `event' object has fromElement attribute, which is the
reference to an element that activated the event.

Alex