Can a vbscript identify the program/process that called a vbscript
MarceepooNu
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
Pegasus [MVP]
"MarceepooNu" <mbh...@aol.com> wrote in message
news:743FF7A5-8729-411D...@microsoft.com...
Perhaps the property wscript.FullName?
Paul Randall
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
Todd Vargo
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)
LikeToCode
<!--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
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
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
Marc
--
MarceepooNu
Todd Vargo
> 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.
Alex Blekhman
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
Tom Lavedas
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'm sure there are reasons to use each approach.
_____________________
Tom Lavedas
MarceepooNu
It's 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 isn't
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'm 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
"Alex Blekhman" wrote:
> .
>
MarceepooNu
marc
--
MarceepooNu
"Tom Lavedas" wrote:
> .
>
MarceepooNu
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:
> .
>
Al Dunbar
"MarceepooNu" <mbh...@aol.com> wrote in message
news:624CCA11-C7CD-48D6...@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
MarceepooNu
Your points are well taken.
marc
p.s. I'm constantly amazed (i.e., annoyed) at the number of sloppy errors I
make.
--
MarceepooNu