Detecting startup as the result of a drop action
Csaba Gabor
attempt to run.
Is there any way to detect that it is starting to run as a result of a
drop operation (as opposed to an accelerator key operation, or a
command line invocation, or perhaps someone has even set up other file
types to be operated on by that script (by means of
...\otherFileType\Shell\Open\Command in the registry))?
An insufficient test is that such a drag operation ensures that the
script gets at least one argument (whereas an accelerator key start
ensures none). However, this won't discriminate between the other two
methods above.
A WinAPI solution is also acceptable.
Thanks for any tips,
Csaba Gabor from Vienna
PS. JW, Thanks for your response a few months ago to my cookie
question - I am still chewing on that one.
Michael Harris (MVP)
> If you drag any Explorer selection over a .vbs file, the .vbs file
> will attempt to run.
>
> Is there any way to detect that it is starting to run as a result of a
> drop operation (as opposed to an accelerator key operation, or a
> command line invocation, or perhaps someone has even set up other file
> types to be operated on by that script (by means of
> ...\otherFileType\Shell\Open\Command in the registry))?
>
None that I know of. The d&d handler just passes script arguments with no
indication to the host or script engine as to their origin.
> An insufficient test is that such a drag operation ensures that the
> script gets at least one argument (whereas an accelerator key start
> ensures none). However, this won't discriminate between the other two
> methods above.
>
> A WinAPI solution is also acceptable.
>
> Thanks for any tips,
> Csaba Gabor from Vienna
>
> PS. JW, Thanks for your response a few months ago to my cookie
> question - I am still chewing on that one.
--
Michael Harris
Microsoft.MVP.Scripting
E C H (He of too much code)
that actually runs a script.
Michael Harris (MVP) wrote:
> Csaba Gabor wrote:
>> If you drag any Explorer selection over a .vbs file, the .vbs file
>> will attempt to run.
>>
>> Is there any way to detect that it is starting to run as a result of a
>> drop operation (as opposed to an accelerator key operation, or a
>> command line invocation, or perhaps someone has even set up other file
>> types to be operated on by that script (by means of
>> ...\otherFileType\Shell\Open\Command in the registry))?
>>
>
<SNIP>
Csaba Gabor
question is: Is possible to detect whether the (WSH) drop handler has
been invoked to start off a script (Win API may be used)?
ECH: how would that look? Aren't you effectively proposing to replace
the original script, S, with yet another script, R. Won't R now be in
the same position as S was before? I was hoping there might be some
environment variable tracks, but that seems not to be the case on my
system.
On Jan 25, 3:11 pm, "E C H (He of too much code)"
E C H (He of too much code)
reverse (as it were) notifying the called app. But I know their are apps that do this, it seems
very rare. I believe this would require some sort of hard coding (VB, C, etc).
Csaba Gabor wrote:
> (I've added microsoft.public.vb.winapi just in case). The original
> question is: Is possible to detect whether the (WSH) drop handler has
> been invoked to start off a script (Win API may be used)?
>
> ECH: how would that look? Aren't you effectively proposing to replace
> the original script, S, with yet another script, R. Won't R now be in
> the same position as S was before? I was hoping there might be some
> environment variable tracks, but that seems not to be the case on my
> system.
>
<SNIP>
mr_unreliable
Your questions are always interesting (and challenging).
As mikHar has said, the "drop handler" is embedded in wscript,
and you are not going to get at it without some very serious
"reverse engineering" and then modifing wscript to provide
the info you want (IsArgumentDropped?).
Another approach might be to write a "wrapper" for wscript.
It would work like this. Change your registry entry for vbs
to call csabaWrapper. Then csabaWrapper would have its own
drop handler code, where you would be able to take note of some
filename drop event. Your csabaWrapper would then leave some
"breadcrumbs" (about file drop) and call wscript with the file
name. The "breadcrumb" could be as simple as adding a
"/D&D=True" command line parameter, along with the file name.
There is source code around explaining how to write drop
handlers for yourself. One example may be found in J.P.
Hamilton's book: "Visual Basic Shell Programming", published
by O'Reilly. See Chapter 7 (Drop Handlers), and more
specifically page 122 "Creating a Drop Handler". You will
find the code on the enclosed CD.
cheers, jw
____________________________________________________________
You got questions? WE GOT ANSWERS!!! ..(but,
no guarantee the answers will be applicable to the questions)
Csaba Gabor
thanks). However, can you tell me if that drop handler can be a .OCX
file or must it be a .DLL as advertised elsewhere on the web? (In
other words, can I create it with VB5CCE?). I have read on the web
that this drop handler must be able to respond to certain events, but
what I did not pick out from that was how to cast the .DLL (or .OCX, if
possible) into this form. Presumably your reference answers this.
As an explanation for where this question is coming from, consider you
have a different scripting language than vbscript. Actually, this
consideration is not necessary, but it makes everything more exciting.
Now suppose that you wanted your type of script files (say .min - read:
dot mine) to act as drop handler, but that you were somewhat pecuniary
in the amount of work you wanted to expend to hook things up
(Disclaimer: further remarks are derived from experimentation and not
documentation). Turns out that this is one of the areas where WSH is
made nicely. Specifically, WSH's drop handler will happily run almost
anything that is thrown at it by looking up
\HKCR\minFile\shell\open\command and running that! Pretty nifty - it
does not have to be a .vbs file.
But let's face it, most scripts (including .vbs) are not meant to be
given path names as arguments, probably only a few. So to avoid
accidents, it would be best if only scripts that were supposed to be
drop targets acted like them. In other words, after enabling all .min
scripts as drop targets, I'd like to restrict them to only those that
were reallly meant to be drop targets. Specifically, if we postulate
that there is a set of code that all .min scripts executed at the
beginning and that we could detect whether the script had been dropped
upon, then we could code this in.
Hmmmm, I didn't get the below straight (I hope) till just now. There
just might be a simple solution to my problem after all - perhaps I was
too quick in my initial analysis... keep reading. Let's consider how
to start up a script (and feel free to chime in with ways I've left
out):
1. From the command line
2. Accelerator key
3. Target files of a different type (.els - read: dot else) being
selected in Explorer and which have a registry entry specifying the
script as a target in: HKCR\elsFile\shell\open\command
4. Being double clicked (or Enter pressed when selected) from
Explorer.
5. Being the target of a drop action.
1. The exe for scripts invoked from the command line frequently
differs from that of scripts invoked from windows (e.g. WScript vs.
CScript. emacs also has this and so does PHP). Furthermore, this is
detectable via WinAPI, in case the scripting language does not offer
direct detection. In short, this case is a non issue.
2. The script to be executed is specified in a link file that must be
in a specific (hopefully out of sight) directory. In the first place
that command could include an extra argument to indicate an accelerator
key start, but note that it also has no implicit arguments. In short,
this case is a non issue.
3. As noted, the command line here is in
HKCR\elsFile\shell\open\command and not in
HKCR\minFile\shell\open\command (this is what I mixed up in my original
post). This method of opening takes a single argument (if you have
multiple files selected, the script is started that many times).
4. The script executed is specified in
HKCR\minFile\shell\open\command. Note that there are no arguments.
5. Finally, this script is started via
HKCR\minFile\shell\open\command, same as in case 4, but there will
always be at least one argument (ie. whatever is dropped, which is
evidently limited to 2048 bytes).
Therefore, it seems that a simple way to achieve what I want is to have
my HKCR\minFile\shell\open\command call include a fixed argument of
/ImADropTarget (the breadcrumb you were talking about - only without a
Drop target handler wrapper). This allows an easy distinction from
case 3. Case 1 and 2 were already easily detectable. At this point
/ImADropTarget is stripped out. If there are no other arguments, we
know it was lieing and came from case 4. With at least one argument,
it must really be a drop target from case 5.
I haven't tested this, as I just hit upon my earlier boo boo as I was
writing this up, but if I haven't missed something big again, this
looks like it will do the trick. If I adopt a uniform policy of
requiring all drop targets to end with ...DT.min then I don't even have
to hard code anything in the common startup code (which will allow me
to move files at will into different directories).
Csaba Gabor from Vienna
On Jan 25, 7:18 pm, mr_unreliable <kindlyReplyToNewsgr...@notmail.com>
wrote:
mr_unreliable
mr_unreliable
er, um, there was no CD. The code for the drop handler (and
all the other code too) may be downloaded here.
http://examples.oreilly.com/vbshell/
The vb shell programming book also states that the drop handler
must have the IDropTarget and IPersistData interfaces, and the
example provided _does_ have those interfaces. But, I did spend
some time going through the registry looking at drop handlers,
and I didn't see those interfaces presented -- either as an
ole interface or a standard (stdcall) interface. Maybe those
are "hidden" interfaces, and detecting "hidden" interfaces is
a skill which I haven't quite acquired as yet.
More specifically, I looked at the vbscript (vbs) drop handler,
i.e., wshext.dll. (As best I can tell, this is also the drop
handler for winXP too). wshext.dll has a lot of interesting
stuff, _both_ ole interfaces and stdcall interfaces, _but_ no
apparent IDropTarget or IPersistData interfaces.
As to whether one can compile a dll (i.e., an actX dll) with
vb5cce, the answer is yes. As you probably know, an "ocx" is
a "special case" dll, with a graphic interface that can be
displayed when hosted by a "proper site" (for example an html
page or a vb form). However, you may also compile an ocx
_without_ a graphic interface, and it will just behave like
an "ordinary" dll -- in fact, you could just change the
extension to "dll" and it will work just fine.
As most of you know, microsoft no longer offers the free vb5cce
compiler for downloading, which is too bad. It can still be
useful for compiling COM objects for augmenting the vbscript
language. The last time I googled for "vb5ccein.exe" (the
vb5cce installer) the ONLY reference I could find was one in
Italy. I have since found one other download site:
http://www.vbcodesource.org/downloads/software/vb5cce.zip
Get it while you can -- unless, that is, you are one of those
sysadmins who are adamantly opposed to 3rd-party controls,
even a control that you write yourself (which is really a
FIRST-PARTY control).
cheers, jw
E C H (He of too much code)
Considering the source, this must be incorrect.
mr_unreliable wrote:
> Regarding the "enclosed CD" to the vb shell programming book,
> er, um, there was no CD. The code for the drop handler (and
> all the other code too) may be downloaded here.
>
> http://examples.oreilly.com/vbshell/
>
<SNIP>
Mark Yudkin
conventional to use OCX to indicate that a DLL is a control, this is just a
convention.
"Csaba Gabor" <dan...@gmail.com> wrote in message
news:1169753851....@v45g2000cwv.googlegroups.com...
mr_unreliable
The code itself was posted ca. 2001, probably long before
IGetNet adware was ever invented. As best I can tell
Symantec works on "binary signatures", and any similar
bit-configuration will get the warning.
I have been irritated by Symantec ever since they began
referring to my scripts with: "MALICIOUS SCRIPT DETECTED!".
Ugh. And I thought all my scripts were harmless. Oh well.
cheers, jw
Csaba Gabor
things have worked out according to the methods I outlined previously
(below). Also, at some point I'd like to get back to the 'an OCX is
equivalent to a DLL' in a separate thread. Two comments are
interspersed below.
I'm chiming in.
6. As the result of a web request
7. As the result of being included/called from another script file
Both of these are easily detectable
Indeed, I have now adopted the convention that myScript.DH.min
(where .min is the extension corresponding to the scripting language
of choice such as .vbs or .js or .php) indicates a script intended as
a Drop Hander. Obviously not as elegant has having an actual drop
handler DLL, but it was simple to put in.
The most significant problem in implementation what not in the drop
handler portion, which worked just fine, but in the following. If I
have this script associated with a particular file type (say .jpg)
then if I select a bunch of .jpg files and fire off the script through
the context menu (right mouse click), then the script is started up
once for each selected file (case 3, above). This is very well in
some situations, but in others one may wish to consolidate all the
files onto a single script invocation (i.e. what you get when the
files are dropped onto a drop handler). Think of starting up multiple
excel files - you only get one instance of Excel. Synchronization
proved to be a real issue when starting up several instances.