Detecting startup as the result of a drop action

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))?

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
Wed Jan 24 18:46:20 CST 2007

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))?
>

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
Thu Jan 25 08:11:25 CST 2007

You could create a script to drop your script on, that could do what you want. Create a new IE icon
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
Thu Jan 25 09:51:25 CST 2007

(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.


On Jan 25, 3:11 pm, "E C H (He of too much code)"
<glasswalkertheu...@juno.com> wrote:
> You could create a script to drop your script on, that could do what you want. Create a new IE icon
> 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))?

E
Thu Jan 25 10:37:25 CST 2007

I was just offering a suggestion. :-). My understanding of drops is that they don't work in
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
Thu Jan 25 12:18:36 CST 2007

hi Csaba,

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 wrote:
> Is there any way to detect that it is starting to run as a result of a
> drop operation

Csaba
Thu Jan 25 13:37:31 CST 2007

Thanks jw. I expected this conclusion (sans your nice reference,
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:
> hi Csaba,
>
> 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 wrote:
> > Is there any way to detect that it is starting to run as a result of a
> > drop operation

mr_unreliable
Thu Jan 25 15:07:44 CST 2007

Congratulations. Sounds like you solved your problem. jw

mr_unreliable
Fri Jan 26 17:27:56 CST 2007

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/

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
Fri Jan 26 18:11:16 CST 2007

BTW, I checked this after downloading it, Symantec says it is infected with IGetNet adware.
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
Sun Jan 28 09:46:11 CST 2007

An OCX is a DLL, it just has a different suffix spelling. Although it is
conventional to use OCX to indicate that a DLL is a control, this is just a
convention.

"Csaba Gabor" <danswer@gmail.com> wrote in message
news:1169753851.556673.59370@v45g2000cwv.googlegroups.com...
> Thanks jw. I expected this conclusion (sans your nice reference,
> 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:
>> hi Csaba,
>>
>> 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 wrote:
>> > Is there any way to detect that it is starting to run as a result of a
>> > drop operation
>

mr_unreliable
Tue Jan 30 16:46:27 CST 2007

Yes, I doubt that O'Reilly is distributing malware.

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



E C H (He of too much code) wrote:
> BTW, I checked this after downloading it, Symantec says it is infected
> with IGetNet adware. Considering the source, this must be incorrect.
>

Csaba
Sat Feb 10 08:11:10 CST 2007

Thanks for the comments on this thread. Just following up to say that
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.

On Jan 25, 8:37 pm, "Csaba Gabor" <dans...@gmail.com> wrote:
> Thanks jw. I expected this conclusion (sans your nice reference,
> 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.

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

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

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.


> On Jan 25, 7:18 pm, mr_unreliable <kindlyReplyToNewsgr...@notmail.com>
> wrote:
>
> > hi Csaba,
>
> > 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 wrote:
> > > Is there any way to detect that it is starting to run as a result of a
> > > drop operation