| Date: | November 24, 2004 / year-entry #402 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041124-00/?p=37213 |
| Comments: | 73 |
| Summary: | If you drag a object and drop it onto a taskbar button, you get an error message that says, You cannot drop an item onto a button on the taskbar. However, if you drag the item over a button without releasing the mouse button, the window will open after a moment, allowing you to drop... |
If you drag a object and drop it onto a taskbar button, you get an error message that says,
Why doesn't the taskbar let you drop directly onto a taskbar button? Ideally, if the taskbar receives a IDropTarget::Drop, it could do something like this:
// imaginary code
IDropTarget *pdt;
if (SUCCEEDED(GetDropTargetFromWindow(hwndButton, &pdt))) {
pdt->Drop(...);
pdt->Release();
}
(Warning: I said "something like" this. Forwarding a drop is actually more complicated than this.) The reason why the taskbar doesn't do this is that there is no such function GetDropTargetFromWindow function. The taskbar can't forward the drop operation even if it wanted to. Why is there no GetDropTargetFromWindow function? I have no idea. You'll have to ask the OLE folks. If I had to guess (and I know I have to because you folks will just keep badgering me until I come up with a guess), it's because that would create the problem of how to prevent somebody from screwing with a program by grabbing its drop target and never releasing it. Now of course people will criticize my explanation, so I'm going to say it again: I don't know the answer. I'm just guessing. My guess is probably wrong. |
Comments (73)
Comments are closed. |
Very interesting error message. It actually describes the right way to do it.
I believe the answer is that many applications have multiple drop targets inside their "main window". For example explorer has a folder tree on the left and file list on the right, both of which are drop targets. If I drop a file onto an explorer taskbar button, how would it know where exactly I was dropping the file?
Obviously I am smarter than Raymond Chen!
Remember guys, Microsoft engineers aren’t human! They should be able to answer any question on right off the top of their head!
Raymond,
I agree with your guess. I can already see an e-mail virus doing just what your guess describes.
James
I thought this came from the age of MDI, where you had a bunch of windows behind the one application icon and you had to have the window open to choose one to drop on.
For G’s usability reason… cool, but a program could define a default drop target or function (paste into a new image in photoshop for example).
For Raymond’s guess, sounds very plausible but this dates back quite far and would predate the last few years high awareness of security.
I would think it was definately a cost issue when it came down to it… that the cost of creating the framework necessary to allow drop targets and default behaviour was too great and it was considered an edge case scenario… so a clear error message was considered the better solution.
When you approach milestone 3 of a 3 milestone project and faced with the Adds and Cuts phase, you’d be surprised how many useful things get put into the Cuts if they’re not considered core to the project or cheap to implement.
As the error message shows that the solution is simply to pause and continue the drag… I would guess that this was simply considered to not be a high priority or core piece of functionality.
My 2c.
Getting an IDropTarget is probably akin to the problem of getting an IHTMLDocument2 from a browser window (see Q249232). I think it was originally assumed that you would only ever need to get an HWND from an ActiveX object (e.g. via IOleWindow::GetWindow) and not the other way around, since if you cared about ActiveX interfaces you would start with one and not let it go, and it need not be a one-to-one relationship anyway.
But why couldn’t the taskbar just forward a WM_DROPFILES message?
@biril ‘Very interesting error message. It actually describes the right way to do it.’
In some ways that made it even more infuriating: ‘Dammit Windows you know what I want to do – why don’t you just do it!?’ ;)
Anyway nice one to bring up Raymond – it’s one of those that always puzzled me. I’ve always hoped that the Explorer people weren’t trying to thwart my drop attempts on purpose and then taunt me with the error message.
I’m surprised that this functionality still is not implemented. It seems like something a computer novice would do and with all the usability testing Microsoft has done it is a bit puzzling why nobody has gotten around to implementing dropping on a taskbar button.
You can actually get a DropTarget from a Window, but this method will tick Raymond off when he has to debug your code in 15 years:
(IDropTarget *) GetProp((HWND)hWnd, "OleDropTargetInterface");
Yet another thing that they’ll have to maintain backwards compatibility with post-Win32. ;)
"But why couldn’t the taskbar just forward a WM_DROPFILES message?"
Um, OLE drag/drop is much more complicated than a WM_DROPFILES message. You can drag things that aren’t files, the drop target can give interactive feedback (remember the copy/move/shortcut article a few days ago?), the drop target can change behavior based on which button you’re dragging with. None of this can be done with WM_DROPFILES.
"… why nobody has gotten around to implementing dropping on a taskbar button." Um, I explained why. Because it can’t be done.
I think that dropping onto the taskbar would be a very ambiguous situation for any drop target. Imagine an application that needed to know exactly where you were dragging an item, for example between a "delete this file" icon and an "Load this file" icon. How would a user know, without being able to see the window, what the resultant or default action would be?
I agree with Tom M.
Drop Tagets I’ve done were very sensitive to location. For example a TreeView that allows files to be dropped on what it considers "folders" in it’s tree, but not other types of nodes ("files", "the magic root item").
If dropped on or dragged over a task bar button the drop target would have to be informed (or have a way to find out) during all those "feedback" calls and such of this special case.
About inability to obtain IDropTarget from HWND: the system clearly knows how to do that, even if the technique is not publicly documented. After all, DoDragDrop has to be able to do it.
About position sensitivity: many (most?) applications that support DnD allow dropping on the title bar. If I were to try and forward a drop from the taskbar button to the application, I’d pretend a drop occurred on the title bar, e.g. at (0, 0) or maybe immediately to the right of the icon.
There’s also the case when applications are grouped in the same button. To which application the object should be dropped to?
"After all, DoDragDrop has to be able to do it."
But that doesn’t mean that free and open access should be given to it. Consider the consequences of the "forgot to release it" scenario I described in my article.
After all, the operating system knows how to read raw data from the pagefile, but you don’t want anybody other than the OS itself to be able to do that.
There was a time in Disneyland when the maintenance people wanted to put up a fence around a particular flowerbed because people kept walking through it. Walt Disney said, "hell, no, if that many people are walking through the flowerbed, you can bet they’ve got a good reason to do it." He had them pave the path through the flowers instead.
I get error messages all the time in Windows telling me the right way to do something; well, why don’t you do it for me, then, computer? It’s 2004, hello!
The Mac follows the Disney way. There aren’t any of these sorts of error messages. If we’re telling the user how to do something, we know that we could just as easily do what they’re expecting.
biril: I think it’s a bad error message–I’ve seen it before, and I read it, and applied what it said (when trying to drag an mp3 onto the winamp button), but I really had to be patient! How about:
‘Hold the item on the button. The program window will open; drop it there.’
And you can have a ‘more info’ button on the dialog, which expands the box to explain that the current action can’t be done, what holding means, how to drop, etc.
Bah, I missed my calling.
"Disneyland" – What if the flowers were protected as an endangered species? The taskbar can’t break the laws of OLE, and Disneyland can’t break the laws the United States.
"Disneyland can’t break the laws of the United States"
Bad analogy there :)
Sure, there may be multiple drop targets in the destination window. But for most of the apps I use there is only one, or one I know of, or only one useful one: dragging a file into the window meaning "open this file please".
For example, Finale is stupid: if you double-click on a file when the app is open, it raises the app, but doesn’t open the new file. Dragging it in, however, works. Dragging the file anywhere in the UI opens the file. So, there’s only one target. If I could drag it onto the taskbar, then would mean the same thing.
This is unlike Wordpad, where dragging the file in to the menu/tool bar means "open this file", and into the document area means "embed the document" — the latter of which makes techincal sense, but serves no useful purpose to me.
I don’t know very much about Windows programming, but have done drag and drop for other UIs. If you define a drop area that covers the entire main window, then probably the task bar should accept that too. At least, it seems like a good default. Even better would be a way for the app to somehow define what a taskbar drop meant for special situtations.
Anyway, the metaphor to Disneyland is bit different – the laws of OLE and the taskbar are both owned by the same company. ;)
Or think of this this way: Disney has lobbyists, so they can simply buy new laws.
"The laws of OLE and the taskbar are both owned by the same company."
That’s like saying that the laws of Oregon and Californa are owned by the same country. Sure, they both belong to a single larger entity, but they have their own separate laws.
"Taskbar implementation is part of the OS."
Great. Go lobby the OLE team to give the taskbar a way to do this. It’s their API, they get to decide.
Chris T,
"The Mac follows the Disney way… we could just as easily do what they’re expecting"
OK Mr. Mac fanboy, if I drop a file onto Windows Explorer taskbar button, is it going to paste the file into the right pane or the left pane? What did I mean for it to do? Oh wait.. let me guess. the Mac Finder thing only has one pane.. Mac users cant handle multiple panes, just like they cant handle 2 mouse buttons!
What about GetProp(hWnd, "OleDropTargetInterface") mentioned earlier (assuming it indeed works)? You (as in "the shell team") have access to Windows source code – it should not be too difficult to see how RegisterDragDrop works. I wouldn’t be overly surprised if it’s as simple as SetProp.
Like I said, this wouldn’t be the first time Windows shell uses undocumented techniques or relies on implementation details of other parts of Windows.
In Windows 3.1 you could do the equivalent thing. For example, you could open Notepad, minimise it, open File Manager, drag a text file and drop it on the Notepad icon at the bottom of the screen. Notepad opened the file. Nowadays the user interface is different but only superficially and the functionality has gone.
With my developer hat on, I understand the problems re: different teams, drop location ambiguity, resource management, etc.
With my user hat on, I can only see Windows, and I don’t care about who owns what API, I just want it to do what I want it to do when I drop the thing on the button – some default action like open the file, or put up the "NO" cursor if there is no such thing.
Shawn,
In many ways, you’re right. But people would get ticked off if only the applications that shipped within Windows worked and those that didn’t ship within windows didn’t. Because Microsoft documented how OLE drag&drop worked, and set forward guidelines. Applications then wrote code to work with those guidelines, so any revisions of those guidelines will likely break applications (at a minimum, they’re not going to be able to take advantage of the new feature).
If the rules were changed, then this would work with some apps, and not with others. Leading to even MORE user confusion: "What do you mean that I can’t drag&drop an item to my word processor, but I can to my email program?What kind of a lame-o operating system are you idiots building anyway?"
And worse, Microsoft would undoubtedly be blamed for breaking applications.
Igor: Good luck being able to do anything with that thing you think is an IDropTarget (it’s in the wrong address space for one thing).
Note that many programs accept drops only on subwindows, not on the outer window. For example, you can drop a file into an email message, but you can’t drop it onto the outer window; you have to drop it into the message body. Therefore, it’s possible that GetDropTargetFromWindow returns NULL even though there are droppable sections of the window.
You might say, "Well, then that’s the app’s fault for not having a generic drop target". To the end user, this manifests as inconsistent and confusing behavior.
Your taskbar button is labelled "Today’s meeting agenda". It is an email message. What do you want to happen when you drop a word onto it that you dragged out of Wordpad? Add it to the "To" line? Add it to the "Cc" line? Change the message subject? Add the text to the message body?
Sure the "Foo" folder case is "obvious". But most cases aren’t as clear-cut. And computers have yet to develop intuition.
Raymond – search Windows sources for GetInterfaceFromWindowProp
"And computers have yet to develop intuition."
Well there’s your problem! You’ve got all these really smart guys over in MS research looking into better ways to render text or writing extensions to C#, when in fact they /should/ be coming up with computerized ESP!!
With the aid of hindsight we can probably see that with a bit of extra effort there may have been a solution to the problem (i.e. this hypothetical "default" drop target for a window could have been used when dropping on a taskbar button – though who knows? Maybe there’s problems with that that we haven’t thought about). But the problem is not whether it could have been done when the drag and drop interfaces were being conceived, but whether it can be retro-fitted onto them /now/. The answer is and unfortunate no.
"Search Windows sources for…" Just because the function exists doesn’t mean that OLE folks have given the shell team permission to call it. And it still doesn’t fix the "nested drop target" problem.
I think of taskbar buttons as title bars. It should open a file if possible. Whatever a titlebar drop does that’s what a taskbar button drop does.
Plus Drag Drop needs to be implemented on Installer Shortcuts. How was that missed.
"How was that missed." Beats me. Ask somebody on the Installer team.
Maybe it’s because it’s a bad idea. You drag something to the taskbar and it just gets swallowed up, without proper feedback and interaction. And without the feedback there’s no way to notice a mistake. If you accidentally dropped it on the wrong button, then what you dropped is now in the wrong place, but you don’t know it. So you continue on your merry way dragging and (mis)dropping. Then next week you notice all your files are "gone."
First when I tried to drag something on a taskbar button I found it quite strange.
But it’s a lot easier that the window pops up instead of having some ‘default drop target’. I guess a lot of people will have a different idea of what the default should be then.
For example the e-mail example Raymond wrote in an earlier comment. Most obvious would be to have the message body set as the ‘default drop target’, but a lot of times you’d wish it was the subject field instead… and then you wish the window would pop up instead ;)
I’m happy with how it works in XP today.
"The laws of OLE and the taskbar are both owned by the same company."
"That’s like saying that the laws of Oregon and Californa are owned by the same country. Sure, they both belong to a single larger entity, but they have their own separate laws."
Isn’t that synonymous to "Microsoft is too disorganized/unfocsed to make obvious improvements to their products in a timely manner?
It means that each group within Microsoft is given a high degree of autonomy to make their own decisions. (And there are many things that seem "obvious" but which have hidden gotchas that turn it into "a bad idea".)
G,
"OK Mr. Mac fanboy, if I drop a file onto Windows Explorer taskbar button, is it going to paste the file into the right pane or the left pane? What did I mean for it to do?"
Now you’re just inventing problems.
Let’s see.. my taskbar button is labeled ‘Foo’. Foo is a folder. What do *you* think I want to do?
on Mac OS X, dragging something onto an application in the Dock does nothing, unless the object is a file – in which case the icon will darken if the computer believes the application can open the file. dropping the file on an application that darkens will either open the file or do certain special actions dependent on the application in question (in Terminal, the absolute path to the file is copied to the command line, for instance).
Which is to say: Mac OS X doesn’t even bother telling you that it doesn’t do much, it just shows the drag-failure animationoid (the stuff being dragged speeds back to its original position)
Vorn
But surely the shell team gets consulted on things like SHORTCUTS.
And you can harras them today. I have to swim for a couple of years (and dodge the US coast guard) to harrass them.
Maybe cmd needs to be removed from MS employee’s computers so they need to eat their own cat food (sorry I believe in non speciesist language – if MS want to refer to computer people as HER (as if) then …)
Raymond,
why does Windows show the message in the first place? Why does the Taskbar give the cue that dropping is possible, to later tell "oops, sorry, you can’t do that"? There are plenty of places where you can’t drop stuff on, and where the mouse cursor just becomes a "prohibited" sign — BEFORE the user releases the drop button. Isn’t it strange that the Taskbar doesn’t follow this practice?
The intuition thing is actually possible. What you have to do is work out the action that is most likely most of the time and do it. Seperately you *must* have a way of always being able to do an undo, and it must be a complete undo so that state is exactly what it was beforehand.
And I’ll be the first to raise my hand to say my code doesn’t have *any* undo at the moment, but I am working on it :-)
Isn’t it obvious? Because you can do something, you just have to wait 5-10 seconds for it to happen. (I wish it was shorter, but oh well.) There’s no good solution to the problem; what it does now is as good as anything else. Dean’s answer is very true.
It does follow that practice – I get the "you can’t drop here" cursor while hovering over taskbar buttons.
My opinion is that there should be some "default" drop target for a window. Clearly it’s too late to do anything about that now, but at least it would lessen frustration when [i]some[/i] buttons could be dropped on to. For the ones that can’t, an equally helpful message could be displayed "this program requires you to drop items within its window as there are several drop targets" (only in a more user friendly way).
Obviously such behaviour cannot be added to OLE in retrospect (as least not easily). What a good thing you’re writing a completely new presentation framework for Longhorn and rewriting explorer in managed code to go along with it. I’m sure this behaviour will be implemented on this clean slate.
Right?
I like the way when Microsoft makes things work automagically, people complain. On the other hand when they say "Please do it this way instead" everyone is still complains. Oh, and when they have a default, everyone complains that they want to be able to alter it to the opposite. And when there isn’t a default because it’s too hard to choose which default to have, everyone complains that there should be a default.
Ingrates!
Actually once you know the rule about not releasing the mouse button, it seems to work ok.
Where’s Norman Diamond? I bet his bitching on this would be best so far :)
To be honest, given that none of the options available are particularly great, I think Microsoft have in this case chosen the lesser of many weevils.
Okay, it’s not ideal, but the message describes the problem and tells you what to do instead. I wish all error messages were as helpful!
(Before someone takes that the wrong way, I mean "all messages from all apps and operating systems", not "all Windows messages". Although there’s that too.)
Oh, come on, people! Do you really believe that completely disallowing a functionality just because some applications wouldn’t be able to use it is good? (Why is there anything like DnD? Some applications are not able to receive dropped files. "To the end user, this manifests as inconsistent and confusing behavior." So we should remove DnD from Windows altogether, shouldn’t we?)
The mere existence of the big message box that has to explain the situation to the user is an evidence that this is wrong.
Of course, there is probably nothing we can do about it now (backwards compatibility etc. etc.), but pretending that this behaviour is correct…? I don’t get it.
Speak for yourself, Raymond. On my OS (W2K) the application is restored and I can drop my file there. This is, IMO, the correct thing to do. A message box is…err…"sub-optimal".
Or are you talking about something else entirely? Or just checking whether we are awake or not? (BTW, on Win 98 I think the behaviour is as you describe, but I don’t have it here to check.)
Raymond – I’m not agruing that it must be done, or even that it’s a good idea. However, I’ve taken issue with your claim that it is technically impossible to do, that the only thing stopping the shell team from implementing this feature is lack of GetDropTargetFromWindow function or equivalent.
I believe I have shown that it is indeed possible, and not even particularly onerous, to retrieve an IDropTarget from the window the taskbar button represents, and to use it in such a way that dragging over and dropping onto a taskbar button is equivalent to dragging over and dropping onto the title bar of the corresponding window.
Now, there may well be other reasons not to do it this way, e.g. from usability standpoint, some of which have been advanced in this thread. I’m only stating that in my humble opinion the explanation you gave in the article, citing technical limitations, is meritless.
I don’t know what you mean by "nested drop target". I’m unfamiliar with the term, and so is MSDN.
@Igor ‘in my humble opinion the explanation you gave in the article, citing technical limitations, is meritless.’
To be fair to Raymond he did say that HE WAS JUST GUESSING – AND IN BOLD LETTERS!!!!
Moi, the application is only restored after a brief pause. If you drag something to the taskbar and release the mouse as soon as you are over a taskbar button, you get the error message.
Igor, Raymond’s already mentioned that the method you described above of obtaining an IDropTarget is in the wrong address space to start off with.
beuges – ok, ta. I think I’ve just got so used to the behaviour over the years I’d forgotten that!
Right. I’m not trying to insult Raymond or anything like that. I don’t see how my comment could be construed this way, but if it comes across as offensive, I’m truly sorry, this definitely was not my intention.
Raymond made a claim, however tentative. I challenged it, believing it to be incorrect. Raymond defended his position, I defended mine. I don’t see anything wrong with it. Now somebody reading this thread can have all the facts in front of them and make their own informed decision.
I guess I’m just pedantic – I find it difficult to pass by an undotted ‘i’ or an uncrossed ‘t’. Please feel free to disregard my rants.
beuges: "Raymond’s already mentioned that the method you described above of obtaining an IDropTarget is in the wrong address space to start off with".
… and I responded by showing a way to marshal the pointer to the right address space, which happens to be the same technique DoDragDrop API uses.
And I responded that the shell team was not given permission by the OLE team to use their internal interface.
Do different teams always ask permission before using an api or feature that isn’t well documented, or documented at all?
Tim: Duh, that’s just good engineering practice. If you’re writing a linux kernel module, do you just go call the memory manager’s internal functions without permission?
foxyshadis — d’oh! didn’t even know that something would happen after such a long time. Now the current policy makes a lot of sense to me.
11/25/2004 4:12 AM h.u.j
> Where’s Norman Diamond? I bet his bitching
> on this would be best so far :)
Sorry to disappoint you ^_^ I have no complaint about sometimes being unable to drop, and here’s why:
As mentioned a few days ago, with rare exceptions, I do not intentionally do drag-and-drop. Exceptions are rare things such as relocating items on the start menu (actually unrelocating them after they were automatically misrelocated during installation of new programs). Otherwise I do not intentionally do drags and drops. 90% of the time when my fingers do a drag-and-drop operation it was something I didn’t want to do. I would like to set an option to always bring up a menu so I can always cancel whatever was going to happen.
In Windows Explorer I often use Ctrl-C (or Ctrl-X) and then Ctrl-V. When a Ctrl-C keystroke didn’t reach Windows Explorer the results can be irritating, but at least I see what happens. When an unintended drag-and-drop occurs, I might or might not notice that something unexpected happened, then figure out what it was and undo it.
Raymond: Probably. I don’t know, that’s why I asked. There is no need to be insulting.
I reckon I should be made CEO of MS for 6 months to fix their organisational structures.
Raymond – You canb go write wordperfect convertors for the office team.
I want to drag onto the taskbar because the place I want to drop is hidden behind other windows. I don’t drag onto the taskbar any more, ever, because I know a trick that will spare you from it. That’s right, never again will I wait with the mouse button held down for a window to rise up from the taskbar:
http://www.gregcons.com/kateblog/CommentView.aspx?guid=b81c5b4e-f3df-4d54-9c3f-befd30157435
So let me get this straight, you actually want MS to start using more undocumented internal APIs that thus become known APIs and backwards compatibility problems so that when Windows makes a leap to, say, 64-bit, DnD slows down to quarter speed because they were forced to keep a 32-bit data structure that the API returns? (or, say, endianness.)
Maybe it’s already past that stage, and the API is psuedo-public at this point, but even if it is by what logic is making bad news worse a good idea?
The actual reason that you can’t do this is that Apple patented this behaviour.
Obviously it wouldn’t be hard to at least do the right thing in the (common) easy cases.
Yay for software patents!
"Yeah, it’s not like Microsoft to have, and/or use undocumented APIs now, is it? Especially for internal use."
APIs at MS come in 3 flavors: public, MS internal, and component internal. "Undocumented" APIs that are called across Windows components still require a contract (not in the legal sense) between teams, so that team A will continue supporting every MS-internal API that team B is using, or else will work with team B directly when making a breaking change to an API. This is just a common-sense reality in a large organization like Windows.
Think of it like this: my wife has the ability to remove the fourth stair from my staircase, but if she did it without telling me I would break my neck some night while walking down the stairs. Just because a team has the technical capability to call another team’s private APIs doesn’t mean it’s a good idea.
Though I remember being irritated by this behavior in the past, on my WinXP SP2 system here at home, it takes less than 1/2 second for the app to restore — usually before I drop. The only thing I have to remember is that I can’t drop it <strong>here</strong>, I have to move the mouse and drop it <strong>there</strong>, into the place in the application it belongs. It only took a few times to learn this when the behavior changed!
One way forward would be for applications to be notified when a file is dropped directly on the taskbar, so they can either perform their only option, or provide a menu to request a specific action/place to drop.
However, that would be complicated because the droppee both has to know <strong>where</strong> and <strong>how</strong> to drop it. How could these two selections be handled without a lot of extra DnD/OLE code?
My suggestion: Applications should be able to declare their <strong>task bar icons</strong> as DnD targets. It should be made clear to us developers that doing this implies a single drop target: applications with multiple windows that can receive objects (or trees/lists that can receive them at different locations) should be discouraged, since they don’t have ESP about their users’ intentions.
For my application, I would have no qualms providing the obvious <strong>non-destructive</strong> default: display the object if possible: exactly what happens when you drag to my title bar. For other apps, it might be more problematic.
Sorry about the tags; I will read before I post again. I’m too used to places that know what HTML is.