Why doesn’t the Print command appear when I select 20 files and right-click?


This is explained in the MSDN documentation:

When the number of items selected does not match the verb selection model or is greater than the default limits outlined in the following table, the verb fails to appear.

Type of verb implementation Document Player
Legacy 15 items 100 items
COM 15 items No limit

The problem here is that users will select a large number of files, then accidentally Print all of them. This fires up 100 copies of Notepad or Photoshop or whatever, and all of them start racing to the printer, and most of the time, the user is frantically trying to close 100 windows to stop the documents from printing, which is a problem because 100 new processes is putting a heavy load on the system, so it's slow to respond to all the frantic clicks, and even if the click manages to make it to the printing application, the application is running so slowly due to disk I/O contention that it takes a long time for it to respond to the click anyway.

In panic, the user pulls the plug to the computer.

The limit of 15 documents for legacy verbs tries to limit the scope of the damage. You will get at most 15 new processes starting at once, which is still a lot, but is significantly more manageable than 100 processes.

Player verbs and COM-based verbs have higher limits because they are typically all handled by a single program, so there's only one program that you need to close. (Although there is one popular player that still runs a separate process for each media file, so if you select 1000 music files, right-click, and select "Add to playlist", it runs 1000 copies of the program, which basically turns your computer into a space heater. An arbitrary limit of 100 was chosen to keep the damage under control.)

If you want to raise the 15-document limit, you can adjust the Multiple­Invoke­Prompt­Minimum setting. Note that this setting is not contractual, so don't get too attached to it.

Comments (20)
  1. anonymouscommenter says:

    The nice thing about legacy verbs is coding a process loop to do one at a time is trivial. But if you write that and it was a COM verb–lockup.

  2. Antonio 'Grijan' says:

    One more case of "if you have to ask what the limits are, you are doing something wrong".

  3. Antonio 'Grijan' says:

    BTW: the link in the last paragraph does not work. Maybe the article number is wrong? Deleting one of the 2s in the number makes it a valid link, but for an article on Exchange Server (which I doubt would be related to shell verbs).

  4. anonymouscommenter says:

    The link in the last paragraph works for me (it is possible Raymond updated it since this morning…)

  5. anonymouscommenter says:

    Hmm, interesting. Now I know why you have to click "Show more details…" to get the total size when you select more than 15 items in the Explorer.

    Though in this case it would probably be safe to raise the limit! ;)

  6. Antonio 'Grijan' says:

    The broken link has something to do with the automatic translation feature of Microsoft's support site. When I click on it, I get redirected to https://support.microsoft.com/ es-es/kb/2022295 (space inserted so the URL doesn't get truncated in the comment), probably because my default locale is ES-es. That URL gives an "article not found" error. Replacing "es-es" with either "en-en" or "en-us" gives the correct article. This problem should affect only overseas readers with non-English locales, and would be corrected by inserting "en-us/" in the URL of the link.

  7. @Antonio: Sounds like support.microsoft.com needs to implement a smarter locale fallback mechanism.

  8. anonymouscommenter says:

    That's patently stupid behavior on MSDN's part. I would want to read the original documentation even if a translation to my local language is available. Redirecting to a non-existing version just makes things work.

  9. xpclient says:

    Ever since Vista, the "Open" verb also doesn't appear/work if you select just 2 different file extensions and press Enter e.g. 1 DOC and 1 DOCX. Thankfully Send To works so a simple VBScript placed in the Send To folder to open each file with its associated default program works on any number of files and the script can also be modified to not open all files at once but sleep for a few seconds.

  10. Scott Brickey says:

    @Niklas: the impact of querying file data can also cause performance issues… while perhaps not as severe, you never known whether the "more than 15 files" are on a local SSD, a local magnetic disk, a remote network share, a CD/DVD, or even on a floppy disk… additionally, I've worked with some *very* large folders (200k+)… the impact of "clicking the button to show more details" is minimal to the user, and can have a HUGE impact to system(s).

  11. anonymouscommenter says:

    @Scott Brickey: I guess I can see how that could be a problem, but would still prefer a few hundred as the limit at least. As an aside, I tried to modify the setting per the link Raymond provided, but it did not seem to take even though I did re-login after adding the registry value. Well, maybe the contract already expired :)

  12. Kirby FC says:

    >>Niklas

    >>

    >>Hmm, interesting. Now I know why you have to click "Show more details…" to get the total size >>when you select more than 15 items in the Explorer.

    That seems to be something that changed starting with Vista.  In Windows XP I could select a large number of files in Explorer and it would show me the total size.  When I switched to Vista in 2007 I found the new behavior a bit annoying.  And I still do.

  13. anonymouscommenter says:

    @Niklas

    The first thing I did after reading this article was try the setting and see if it would also work to raise the "show more details" limit. But I wasn't surprised when it didn't work after restarting Explorer and checking I created/spelled everything right, since the two things – what the blog article is talking about and that Explorer UI feature – are not the same (or at least so I think). And I've also made the mistake of right-clicking print after selecting a bunch of files, so I probably would have reverted the setting even if it did also work for that unrelated thing.

  14. cheong00 says:

    @Kirby FC: They changed it for performance reason. And some people apparently agrees with you, that's why they created "Folder size" project when Vista is released.

    foldersize.sourceforge.net (have to include link because there are a number of other commercial software shares similar name)

  15. alegr1 says:

    No, it does NOT explain why you have to click show more data for >15 or 100 files. This is not because of some inherent complexity, this is just bad design which could have fixed long time ago, but didn't.

    Keep in mind, that when you're reading the directory with FindNextFile, you also get the file size and timestamps. There is no added cost to get the total size.

  16. anonymouscommenter says:

    Hiding / disabling elements is a confusing UI paradigm — just put yourself in the user's position: sometimes it shows up, sometimes it doesn't, with no apparent rhyme or reason.  Better would be to keep it, and if they invoke the command, then pop up that you can't print more than 15 items at a time — at least this way they have a hope of understanding what's going on.  Oh, I'm sure there are technical hurdles, but still (how about hiding the original verb and replacing it with a stub that shows the information?)

  17. anonymouscommenter says:

    @Ray "Note that this setting is not contractual, so don't get too attached to it." Well, you do like job security, right? I mean you just let the cat out of the bag and this will become a future compatibility issue to support :D

  18. anonymouscommenter says:

    Mark S: Having a bunch of UI elements that are just sitting there, only to give you an error message, isn't a good experience for the user either. If I want to know what functions I'm allowed to perform for the current state, do I just have to click on everything to see what works? I'd much rather see it visually.

    If the user needs to know why the option isn't available, a tooltip on the disabled feature ought to be sufficient. In some cases, perhaps trying to use the disabled feature could bring up a dialog box to get the program into the state that enables it (e.g. "You need to be an administrator to edit this. Enter admin credentials here:").

  19. anonymouscommenter says:

    Why can't windows remember if it took "long time" last time a user selected "many" files and did some "action", and then decide if it should allow the "action" on "many" files? This isn't rocket science, a five year old can figure this stuff out.

    [What's the definition of "a long time"? Is this remember for each file type, for each collection, for each action? E.g. "The last time the user selected A.DOC, B.DOC, and C.DOC, and selected 'print', it took 5 minutes. I should warn them the next time they select A.DOC, B.DOC, and C.DOC and select 'print'. But if they select A.DOC, B.DOC, and D.DOC, then no warning, because maybe the problem was that C.DOC was too big."? (And if C.DOC is smaller now than it was last time, maybe I don't warn.) -Raymond]
  20. anonymouscommenter says:

    @Raymond: The 15-file limit does not currently take file names or size in consideration. Do you think is should?

    [What's the difference between 200 copies of winword.exe each printing a 1-page document and 200 copies of winword.exe each printing a 200-page document? Both of them will make your life miserable. -Raymond]

Comments are closed.

Skip to main content