drag and drop across microsoft OS's

[Novice]

Hi, I'm interested in how the various microsoft OS's implement drag
and drop onto executables.

Does the action of dragging a file onto an executable (or shortcut)
result in the executable being called with the file/folder name being
passed in as a command line argument?

I notice (on Windows 2000) some applications support dragging and
dropping files onto their executables, but others don't (Visio 2002
does not). Does this simply mean that those executables don't accept
command line arguments?

Also, if possible could someone direct me to where Microsoft documents
this behaviour - assuming Microsoft does.

Thanks,
Novice

 

[R.Wieser]

Novice <[email protected]> schreef in berichtnieuws
(e-mail address removed)...

Hello Novice,

Hi, I'm interested in how the various microsoft OS's implement drag
and drop onto executables.

Does the action of dragging a file onto an executable (or shortcut)
result in the executable being called with the file/folder name being
passed in as a command line argument?

No. The "drop" -action is actually converted to a "message", and posted
into the target-applications message-que (just like, for example,
mouse-movement/clicks are) . The command-line has got *nothing* to do with
that.

I notice (on Windows 2000) some applications support dragging and
dropping files onto their executables, but others don't (Visio 2002
does not). Does this simply mean that those executables don't accept
command line arguments?

Again, no. An application might *ignore* either the
command-line -arguments and/or the "drop" message, but those are two
different items altogether

Also, if possible could someone direct me to where Microsoft documents
this behaviour - assuming Microsoft does.

There is, as far as I know, no documentation about it. It's just the
programmers (or his boss'es choice to support (actually write support
for) either command-line arguments and/or "drop" messages.

Regards,
Rudy Wieser

P.s.
You're cross-posting to quite some groups here ....

 

[David H. Lipman]

If you have a handle on this -- as it appears you do.

How does programming for "Redirection of Input and Output" affect Drag 'n Drop ?

Dave


| Novice <[email protected]> schreef in berichtnieuws
| (e-mail address removed)...
|
| Hello Novice,
|
| > Hi, I'm interested in how the various microsoft OS's implement drag
| > and drop onto executables.
| >
| > Does the action of dragging a file onto an executable (or shortcut)
| > result in the executable being called with the file/folder name being
| > passed in as a command line argument?
|
| No. The "drop" -action is actually converted to a "message", and posted
| into the target-applications message-que (just like, for example,
| mouse-movement/clicks are) . The command-line has got *nothing* to do with
| that.
|
| > I notice (on Windows 2000) some applications support dragging and
| > dropping files onto their executables, but others don't (Visio 2002
| > does not). Does this simply mean that those executables don't accept
| > command line arguments?
|
| Again, no. An application might *ignore* either the
| command-line -arguments and/or the "drop" message, but those are two
| different items altogether
|
| > Also, if possible could someone direct me to where Microsoft documents
| > this behaviour - assuming Microsoft does.
|
| There is, as far as I know, no documentation about it. It's just the
| programmers (or his boss'es choice to support (actually write support
| for) either command-line arguments and/or "drop" messages.
|
| Regards,
| Rudy Wieser
|
| P.s.
| You're cross-posting to quite some groups here ....
|
|
|

 

[R.Wieser]

David H. Lipman <[email protected]> schreef in berichtnieuws
(e-mail address removed)...

Hello David,

If you have a handle on this -- as it appears you do.

How does programming for "Redirection of Input and Output" affect Drag 'n

Drop ?

In one word ? Nothing ... The "drop" message will either give you a
memory-pointer to the data that's dropped, or will supply you with the
filename(s) of the file(s) dropped. Neither of them are, at the moment of
the "drop", influenced by the above-mentioned re-direction of standard I/O.

Regards,
Rudy Wieser

 

[David H. Lipman]

Gratzi !

Dave

| David H. Lipman <[email protected]> schreef in berichtnieuws
| (e-mail address removed)...
|
| Hello David,
|
| > If you have a handle on this -- as it appears you do.
| >
| > How does programming for "Redirection of Input and Output" affect Drag 'n
| Drop ?
|
| In one word ? Nothing ... The "drop" message will either give you a
| memory-pointer to the data that's dropped, or will supply you with the
| filename(s) of the file(s) dropped. Neither of them are, at the moment of
| the "drop", influenced by the above-mentioned re-direction of standard I/O.
|
| Regards,
| Rudy Wieser
|
|
|

 

[R.Wieser]

Gratzi !

You're welcome.

Regards,
Rudy Wieser

 

[Tim Robinson]

There is, as far as I know, no documentation about it. It's just the
programmers (or his boss'es choice to support (actually write support
for) either command-line arguments and/or "drop" messages.

They do in fact document drag and drop.

In general, there are two drag and drop protocols in Windows: WM_DROPFILES
and IDropTarget.

WM_DROPFILES has been around since Windows 3.1, and was originally used to
allow the user to drag files from File Manager onto running applications,
just like you can drag files from Explorer windows now. If you use the
WS_EX_ACCEPTFILES style on your window, or call DragAcceptFiles, Explorer
will use the WM_DROPFILES method when the user drops a file onto your
application. Full details are available through MSDN.

IDropTarget is the COM interface through which your application can accept
items dropped from any OLE drop source. Explorer is one such source, as are
Word, Excel, etc. Hence IDropTarget can be used to accept not just files,
but any data type representable with IDataObject. Implementing IDropTarget
is a bit more complex, but it allows your app to be a bit more intelligent
about what kinds of shell object (not just files/directories) or OLE objects
it accepts. Again, full details are available through MSDN.

It's worth noting that the HDROP format (used with WM_DROPFILES and
previously undocumented) is documented as one of the data types that
Explorer gives your application when the user drops a physical file or
directory on your application.

Of course, dropping of files onto applications' icons is different. As you
say, Explorer starts the application with the name of a file as the
parameter.

 

[R.Wieser]

Tim Robinson <[email protected]> schreef in
berichtnieuws [email protected]...

Hello Tim, David,

[Snip]

Of course, dropping of files onto applications' icons is different. As you
say, Explorer starts the application with the name of a file as the
parameter.

Yikes. Although technically you're not dropping anything into the
application (which the icon is representing), it certainly looks like you're
doing just that.

What actually happens is that the OS see's that you want to use some app as
the one the "dropped" file should be opened with. As the App is not open,
the OS will start it and give it the "dropped" -file's name & path *by the
command-line* ,just like it would when you would have double-clicked the
"dropped" file.

To be short : there *is* a point where the command-line is used to transfer
the name (of the "dropped" file) to the (just started) app.

Sorry 'bout that dave.

Regards,
Rudy Wieser

 

[Novice]

[snip]

They do in fact document drag and drop.

In general, there are two drag and drop protocols in Windows: WM_DROPFILES
and IDropTarget.

WM_DROPFILES has been around since Windows 3.1, and was originally used to
allow the user to drag files from File Manager onto running applications,
just like you can drag files from Explorer windows now. If you use the
WS_EX_ACCEPTFILES style on your window, or call DragAcceptFiles, Explorer
will use the WM_DROPFILES method when the user drops a file onto your
application. Full details are available through MSDN.

Excellent - So this documentation is available on the microsoft
website? Or is it for internal developers only or only available if
you pay for it?

Also, when you say "when the user drops a file onto your application"
- do you mean when the user drags a file/directory from the filesystem
using another application (like windows explorer) and then drops that
file/directory onto an already running application - like Word, Excel,
etc?

IDropTarget is the COM interface through which your application can accept
items dropped from any OLE drop source. Explorer is one such source, as are
Word, Excel, etc. Hence IDropTarget can be used to accept not just files,
but any data type representable with IDataObject. Implementing IDropTarget
is a bit more complex, but it allows your app to be a bit more intelligent
about what kinds of shell object (not just files/directories) or OLE objects
it accepts. Again, full details are available through MSDN.

It's worth noting that the HDROP format (used with WM_DROPFILES and
previously undocumented) is documented as one of the data types that
Explorer gives your application when the user drops a physical file or
directory on your application.

Of course, dropping of files onto applications' icons is different. As you
say, Explorer starts the application with the name of a file as the
parameter.

Is this behaviour consistent across window's platforms (i.e. from win
3.1 to XP)? That is to say, unless your executable (Word, my own
programs, Corel Draw, etc) accepts command line arguments then
dropping the file/directory onto the executable will have no affect
(other than perhaps starting the application)?

There were three behaviours I observed when testing this (i.e.
dragging a file/directory from one application (exp windows explorer)
and then dropping that file/directory onto the executable or shortcut)
on Win 2000:

- application loaded document to the best of its ability - i.e.
notepad would open a zip file with all the byte code in there - i.e.
it should the characters that make up the zip file
- application started up, but it was as if it had ignored the fact
that I had dropped a file/directory onto the executable file or
shortcut to the exectuable file.
- application did not start up - I observed this behaviour with visio
- no matter what file type I dragged onto the visio shortcut - the
application would not start up.

Thanks,
Novice

 

[Tim Robinson]

Excellent - So this documentation is available on the microsoft
website? Or is it for internal developers only or only available if
you pay for it?

I read all of this on MSDN. If you don't have some sort of MSDN subscription
available (Visual C++ comes with an MSDN CD), you can search at
http://msdn.microsoft.com/library/.

Also, when you say "when the user drops a file onto your application"
- do you mean when the user drags a file/directory from the filesystem
using another application (like windows explorer) and then drops that
file/directory onto an already running application - like Word, Excel,
etc?
Yes.


Is this behaviour consistent across window's platforms (i.e. from win
3.1 to XP)? That is to say, unless your executable (Word, my own
programs, Corel Draw, etc) accepts command line arguments then
dropping the file/directory onto the executable will have no affect
(other than perhaps starting the application)?

Well, except that Explorer is Windows 95 onwards, yes. File Manager behaved
the same way.

There were three behaviours I observed when testing this (i.e.
dragging a file/directory from one application (exp windows explorer)
and then dropping that file/directory onto the executable or shortcut)
on Win 2000:

- application loaded document to the best of its ability - i.e.
notepad would open a zip file with all the byte code in there - i.e.
it should the characters that make up the zip file

OK, expected.

- application started up, but it was as if it had ignored the fact
that I had dropped a file/directory onto the executable file or
shortcut to the exectuable file.

Odd. What application was this?

- application did not start up - I observed this behaviour with visio
- no matter what file type I dragged onto the visio shortcut - the
application would not start up.

Even odder. What happens if you drag a file onto VISIO.EXE (or whatever the
Visio executable is)?

 

[Alex Nichol]

Hi, I'm interested in how the various microsoft OS's implement drag
and drop onto executables.

Does the action of dragging a file onto an executable (or shortcut)
result in the executable being called with the file/folder name being
passed in as a command line argument?
Yes

I notice (on Windows 2000) some applications support dragging and
dropping files onto their executables, but others don't (Visio 2002
does not). Does this simply mean that those executables don't accept
command line arguments?

Presumably. Try invoking such a one in a command prompt, and typing in
a file name to see

 

[Ian Abbott]

Odd. What application was this?

Any application that ignored the command line would behave like this.

Even odder. What happens if you drag a file onto VISIO.EXE (or whatever the
Visio executable is)?

And what does the "Target" line look like in the shortcut's properties?

 

[Novice]

[snip]

Odd. What application was this?

It is called alcohol 120% - it allows you to create virtual CD drives
with CD images. I dragged and dropped a CD .cue file onto the
application and it just started the application - but did not load the
CD image - however once the application was started I was able to drag
the image onto the windows explorer type interface of this program and
it loaded the CD image.

Even odder. What happens if you drag a file onto VISIO.EXE (or whatever the
Visio executable is)?

If I take a valid Visio data file and drag it onto the executable then
it will open visio with that file opened. Then if I drag another type
of file that is not a Visio file onto the Visio executable file -
Visio opens and gives a message indicating that the file is not a type
that Visio recognizes and suggests that the file might be corrupted.

Thanks,
Novice

 

[Tim Robinson]

It is called alcohol 120% - it allows you to create virtual CD drives
with CD images. I dragged and dropped a CD .cue file onto the
application and it just started the application - but did not load the
CD image - however once the application was started I was able to drag
the image onto the windows explorer type interface of this program and
it loaded the CD image.

Hmm. Sounds like that was what the developer was drinking when he wrote it
.

Applications that let you open documents should accept the name of a file on
the command line, with or without quotes.

If I take a valid Visio data file and drag it onto the executable then
it will open visio with that file opened. Then if I drag another type
of file that is not a Visio file onto the Visio executable file -
Visio opens and gives a message indicating that the file is not a type
that Visio recognizes and suggests that the file might be corrupted.

OK, that's what I'd expect. And a fresh shortcut to VISIO.EXE should work
the same way.