From: MarceepooNu on
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(a)aol.com> wrote in message
> news:743FF7A5-8729-411D-838D-B8808BA2A8CB(a)microsoft.com...
> > 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?
>
> .
>
From: MarceepooNu on
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(a)aol.com> wrote in message
> news:743FF7A5-8729-411D-838D-B8808BA2A8CB(a)microsoft.com...
> >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/library/ms533050%28VS.85%29.aspx
> The code associated with a button is activated by the onclick event:
> http://msdn.microsoft.com/en-us/library/ms536913%28VS.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/details.aspx?displaylang=en&FamilyID=231d8143-f21b-4707-b583-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
>
>
> .
>
From: Todd Vargo on
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)

From: MarceepooNu on
I agree. One of the reasons for my inquiry is the fact that I developed many
scripts before it occurred to me that it might be useful to make a habit of
always including such an argument in the calling script.

The daunting prospect of having to revise every single script led to me
wonder if there wasn't some easier way of getting the info, and of verifying
the argument, in case somehow the calling script sends the wrong info
(presumably due to inadvertent sloppy coding on my part).

marc
--
MarceepooNu


"Todd Vargo" wrote:

> 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)
>
> .
>
From: Al Dunbar on


"MarceepooNu" <mbh2010(a)aol.com> wrote in message
news:624CCA11-C7CD-48D6-BBAD-1B58C90BC07D(a)microsoft.com...
> I agree. One of the reasons for my inquiry is the fact that I developed
> many
> scripts before it occurred to me that it might be useful to make a habit
> of
> always including such an argument in the calling script.
>
> The daunting prospect of having to revise every single script led to me
> wonder if there wasn't some easier way of getting the info,

But, in order for your many scripts to be able to use whatever technique you
were able to develop, wouldn't that be another daunting, script revising,
prospect itself?

> and of verifying
> the argument, in case somehow the calling script sends the wrong info
> (presumably due to inadvertent sloppy coding on my part).

If you could write script code that could detect logical errors on the part
of your code, then you are probably a sophisticated enough scripter to be
unlikely to make such sloppy errors. ;-)

/Al

>
> marc
> --
> MarceepooNu
>
>
> "Todd Vargo" wrote:
>
>> 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)
>>
>> .
>>