Can a vbscript identify the program/process that called a vbscript

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

Perhaps the property wscript.FullName?

Perhaps the property wscript.FullName?

Here is some info on the HTA part of your problem:Take a look at the DHTML

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

MarceepooNu wrote:Basically, your query boils down to:How to determine if a

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"<!

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

onclick="Run('Hello')">


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

Dear Pegasus:First, thank you for replying."Msgbox wscript.

Dear Pegasus:

First, thank you for replying.

the script in which the "Msgbox wscript.fullname" line resides.

wscript.fullname will not 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 does not 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

Dear Paul:Before I posted the question, I spent a lot of time hunting around

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 did not occur to
me to focus on the onclick Event.  I bet that that will lead me to what I am
looking for.  I feel both grateful for the information, and stupid/lazy for
not having found it myself.  Thanks.  Much appreciated.

Marc



marc


--
MarceepooNu

Can a vbscript identify the program/process that called the script

Thank you.  Very very helpful.

Marc
--
MarceepooNu

MarceepooNu wrote:Correct.

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


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.

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

I tend to use srcElement, instead.

I tend to use srcElement, instead.  As I read it, fromElement is
activated when the thing that triggered the event is leaving the
element, where as srcElement occurs at the initiation of the event.
It may seem like a subtle difference, but it seems more intuitive to
me to work with the leading edge of an event than the trailing edge.
Though, I am sure there are reasons to use each approach.
_____________________
Tom Lavedas

Thank you. This too is a very helpful way to acquire the info.

Thank you.  This too is a very helpful way to acquire the info.
it is noteworthy (I think...) that the event info is an html dependent
functionality, instead of being directly accessable through vbscript and
Windows.  (I hope what I just said so confidently is not
stupid/ignorant/wrong, and the product of ignorance, i.e.,  the fact that I
have never coded any script to use an event object.  Apparently, now's the
time to learn...

It is so much fun to feel one's abilities blossom through the collaborative
help you guys provide in these newsgroups!  Today, I am going to start trying
to make a habit of trying to do a small part of what you guys do, i.e., by
posting answers to the ocassional really simple questions I can answer, to
help others who know less than I.

thanks again.             marc
--
MarceepooNu

thank you. Very helpful.marc--MarceepooNu"Tom Lavedas" wrote:

thank you.  Very helpful.
marc
--
MarceepooNu

I agree.

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 was not 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

But, in order for your many scripts to be able to use whatever technique

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


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

Thank you for your comment, your insight, and your humor.

Thank you for your comment, your insight, and your humor.
Your points are well taken.

marc

p.s.  I am constantly amazed (i.e., annoyed) at the number of sloppy errors I
make.


--
MarceepooNu