| Date: | December 3, 2004 / year-entry #409 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041203-00/?p=37143 |
| Comments: | 26 |
| Summary: | If you select say five files and then right-click them and choose "Print", they tend to print in a random order. Why is that? The shell invokes the Print verb on each file in turn, and depending on how the program responsible for printing the document is registered, one of several things can happen. Most... |
If you select say five files and then right-click them and choose "Print", they tend to print in a random order. Why is that? The shell invokes the Print verb on each file in turn, and depending on how the program responsible for printing the document is registered, one of several things can happen.
These three ways of registering print actions are described in the MSDN documentation on verbs and file associations. [Update: 7:30am, fixed title.] |
Comments (26)
Comments are closed. |
There’s also a slight oddity in the order that multiple selections are returned from file dialogs; clicking on a file in an Open dialog, then holding Shift and clicking a second file usually results in the file you selected first moving to the END of the list…
I would bet that 95 out of 100 users don’t know you right-click, print.
I actually just had to explain a semi-sort-of-similar thing to a friend who was getting very annoyed with WMP. He was selecting an album’s worth of tracks in Explorer, all nicely numbered and ordered, and dragging them over to WMP, which would start playing at some random point halfway down the list.
But hey, this is almost a feature, in a way, once you figure it out. The list of files in the drag starts with whichever one the mouse is over when you start the drag.
I can’t imagine trying to justify this to somebody non-technical… but at least it’s consistent.
What about Amiga? Does it print sequentially when you drop files on printer icon?
Mat: yes, that always disturbed me that the first file selected becomes the last, either when opening or when copying (copying you only notice on huge files).
I heard a description once about why this happened, but it did not make sense, and eludes me currently. Raymond?
Fat Agnus and Denise: No, it doesn’t even have printer icons. Printing support really, really sucked.
On the other hand not many OSes do printing right anyway; Windows was very fortunate in this respect, because it made drawing to the printer exactly like drawing to the screen. (isn’t that nice of them?) Using CUPS (Common Unix Printing System) is a pain because often you have to manually turn your document into a PostScript file before sending it to the printer queue.
Vorn
I’m constantly encountering that last-file-first issue with selecting files. Usually it’s in file selection dialogs like when trying to view slideshow images.
I’ve started the practice of selecting from the bottom to the top to ensure I get things in order.
The reason for the weird selection is that the currently selected item is always first. This is one of those cases where Windows doesn’t "do what I mean" even if it’s somewhat logical.
Merle: That’s a good question. I tried looking for an answer in the ‘The Windows User Experience’ book, but couldn’t find much information about activating multiple objects.
Selection of multiple objects is explained in good details :)
Yes, the shell’s notion of the "active object" in a multiple selection leads to some surprising behavior. Much of what the shell does with multiple selections doesn’t make much sense, and I quickly lost interest in trying to emulate it exactly when writing runmenu, for which I had to go to some lengths to conjure up a context menu for a list of files residing in different directories. Here are some things I noticed about the "active object" and decided not to emulate in my MultiContextMenu class:
1. The shell’s context menu for a multiple selection typically includes "Open with", but it applies only to the item within the selection that was right-clicked. So the shell adds items to the context menu for a multiple selection that don’t apply to the entire selection.
2. The items which appear on the menu for a multiple selection depend on which file was right-clicked. Select a .url and .lnk file as a multiple selection and alternate the one you right-click on to see what I mean.
3. If two .lnk files are selected, the shell may resolve the name of the one right-clicked on and send it alone to the item you choose from the context menu. I observe this with WinRAR, Panda AntiVirus, and my own Eluent Tools stuff. (However, the "Send To Any Folder" powertoy gets both the .lnk files. Anyone know how to get the "Send To" behavior?)
It seems like whoever wrote the shell code felt that shortcuttedness should override multiple selectioness, and the file right-clicked upon in a multiple selection should cause some menu items to act as if it were the only file selected. The result is a whole lot of inconsistency and surprising behavior. I think the context menu for a multiple selection should not resolve shortcuts, nor should it give special status to the item which had the focus when the context menu was invoked. That’s the approach I ended up taking in MultiContextMenu.
So what exactly is MultiContextMenu? Google knows nothing…
MultiContextMenu is a C++ class I wrote several years ago, originally for Eluent Dir (a file finder), which I later used in runmenu. It supports creating a context menu for a list of files which reside in different directories. While IShellFolder::GetUIObjectOf can create a context menu for a list of objects all in the same folder, the shell provides no way to create a context menu for a list of objects residing in different folders. Note that Explorer does implement such functionality in its search results pane, but I guess it’s an Explorer-only thing; Windows doesn’t expose it to shell programmers.
Doug, was CDefFolderMenu_Create2 what were you looking for? because it was only documented recently, as part of an out-of-court settlement for the antitrust case (it’s one of the infamous "ordinal-only" shell32.dll exports). Have a look at it
When you drag files into an Outlook Express maiol mesaage, Shell puts the file you dragged from first, and then the rest of the files – in the order they appear. So if you selected files 1 2 3 4 5, and dragged the selection grabbing file 3, in the email you’d get 3 1 2 4 5.
Except that OE actually reverses the order shell sends it, so you’d actually get 5 4 2 1 3.
I enevtually figured it out, and I now sort backwards (5 4 3 2 1), and drag by grabbing the last one (5) – that gives me the 1 2 3 4 5 that I want. Took me a while to figure out.
I can’t tell from the docs if CDefFolderMenu_Create2 can handle objects in multiple directories.
Provided it can cope with objects in multiple directories, messages I found on Usenet say the function will add Cut/Copy/Delete/Properties/etc items to the context menu, which is indeed useful. My MultiContextMenu has to provide those menu items itself, because they aren’t implemented as IContextMenu extensions, that one can discover through the registry. In addition, determining when to enable Cut/Copy/Delete is a pain, and perhaps CDefFolderMenu_Create2 would do that for you.
I think using CDefFolderMenu_Create2 would require a lot of experimentation to fill out the sparse documentation, but if someone feels like trying it out on a selection such as C:temp1a.txt C:temp2b.exe, I’d be happy to hear their results. :)
I always had the impression (though I didn’t look very carefully) when dragging files into the Winamp playlist, that I’d get, with 1 2 3 4 5 selected, 5 2 3 4 1 as a result.
Even doing a multiselection and Ctrl-C, then Ctrl-V into another folder, copies the files out of order. Some of the replies have stated what seems to be the reason for this. Regardless of the reason, this makes it fun (not) when trying to use Windows Explorer to copy a bunch of files, then trying to narrow down a problem by doing a larger number of copy operations on smaller bunches of the files. When a copy operation aborted, the list of files copied so far was not the list of files up to that point in Windows Explorer’s display of them.
(By the way, the Windows Explorer copy operation is one of those that offers a "yes to all" but doesn’t offer a "no to all". Sometimes really convenient would be a "yes to copy new ones on top of old ones but no to old ones on top of new ones", which is obviously beyond the capabilities of Windows Explorer, but why is there no "no to all"?)
Norman, shift+No == "no to all".
‘shift+No == "no to all"’
That’s quite possibly the most useful thing I’ve ever heard!
Vorn: Yes, printing is one of the few things I felt Windows was doing very well even in version 3. However I think the remote printing architecture is a bit of a botch and a security nightmare: the client must trust the binaries provided by the server and the server must trust the client not to send a print job that will break the printer. I wonder why Windows doesn’t support generic remote printing using print jobs based on metafiles?
Ben,
I think the whole driver per printer thing is a pain. There should be some kind of generic printer driver that takes an image file jpeg’d or losslessly compressed (or even a tiling of the two) and prints it. I can see this being good for things like USB On the Go where your camera uses the printer as a device, and it’s not really feasible to have more than one driver.
For mono text, zlib/bzip2 lossless compression is probably OK, and JPEG does fine for images. The printer driver could either know which one to use (e.g. in a Camera, where everything is JPEG’d), or it could devise an optimum combination of both (on a PC, where you have lots of info about how the image was constructed not to mention memory+CPU power to burn). This would be in addition to whatever proprietary page description language the printer supports, because these are much more flexible. The USB printer would have a special descriptor to tell the host that it supports this generic mode.
Then you’d have a generic printer driver on Windows a bit like the generic video driver, but you could replace it with a device specific one if you had one. Cheap printers could only implement the generic protocol, perhaps in an ASIC. For black and white, you could even skip the JPEG support completely.
Oh, and there were "GDI printers", based on what looks like generating a bitmap on the PC, run length compressing it and sending it down to the printer where hardware (or very simple software) could decompress it, but it never really caught on.
What is the DPI of the generic printer? If the actual printer has a different DPI, then all documents will come out looking blocky.
I guess the printer would need to tell the host, especially for text or lineart. You could put this information (and much else, like colour and compression support) into a USB Descriptor, and the generic driver could use it from there.
12/6/2004 6:28 AM Tom
> Norman, shift+No == "no to all".
Thank you! Out of curiosity, how did you discover that?
http://www.google.de/search?hl=en&q=explorer+%22no+to+all%22
Raymond had a big fight with nearly everyone in the world (not me though) who wanted dialogs that duplicated XCopy’s switches during XP’s beta. Then this No To All poped up in the gold version. If you go through the tips in Tweakui you’ll find it.