I am using IFileOpenDialog and the older explorer style file open dialogs to allow the user to select and open multiple files.
In both cases, when multiple files are selected from camera or video camera media and the Open button is clicked this error is displayed:
"Cannot open multiple items from this location. Try selecting a single item instead"
Why is this error being generated?
Also I find that it is impossible to drag-and-drop files from the camera media - the cursor changes to a circle with a diagonal line when you drag over the target window.
I'm assuming that Windows has some sort of limitation when trying to "open" multiple files or dragging them from some media, but I can't find any information about why this limitation exists or whether it is possible to work around it so that multiple files can be opened.
Is there any Microsoft documentation that describes the reason for this problem?
Are you opening the files by mounting SD card or Camera wizard. If you are using wizard then when you open the file is copied to a temp location in system and opens it. So if you are opening it using Open File Dialog, it may fail. See below link for your reference
Thanks, Renjith V R
Thanks for the link but I am doing all that.
> Are you opening the files by mounting SD card or Camera wizard.
Neither. Just connecting the device makes it appear in Windows Explorer, so the support is built into Windows.
After a lot more hunting around I found that Windows uses "Media Transport Protocol" (MTP) which makes the camera appear as a separate device in Windows Explorer's left-hand pane as soon as it is connected. MTP connection mode seems to be more favored than the other alternative "USB Mas Storage" (UMS) mode which makes the camera's storage appear as a new drive letter.
Apparently some cameras only support MTP, while others have an option to tell it to connect in MTP or UMS mode.
I managed to set my camera to UMS and the storage appeared as a new drive letter - from here I was able to multi-select and drag-and-drop multiple files as normal.
So it seems the multi-select in the File Open dialog, and the drag-and-drop problem only appears in MTP mode (although you can drag-and-drop WITHIN Windows Explorer in MTP mode).
In multi-select mode, all the File Open dialog is doing is passing a list of pathnames back to the program, so it seems a pointless limitation written into the File Open dialog to prevent this just because a device is connected by MTP! In my program I just accept the list of pathnames and then later-on process each file one-at-a-time - it's therefore a great inconvenience for users to have to open the dialog repeatedly to add 1 pathname at a time just because of this artificial limitation written into the File Open Dialog.
Is there some way to force the dialog to return multiple pathnames for MTP mode?
Could this be considered a "bug" in the File Open dialog?
The same applies for drag-and-drop. I simply get a list of pathnames of the files dropped onto my program window, but in MTP mode Windows will not allow anything to be dropped onto my window. Seems crazy!
Actually it is PTP(Picture Transfer Protocol).Refer below link
Thanks, Renjith V R
Thanks Elegentin. I look forward to the results of your investigation.
For the time being I will have to tell users to select UMS on their camera - but not all have this option so this is not just an inconvenience, as some users will not be able to do this at all.
I don't know much about MTP, but I can imagine that it might have some sort of restriction where only 1 file can be opened at a time on the media - maybe this is why the limitation was designed into the file open dialog. If so then this is incorrect design. Even though the dialog is called "file open" it does not actually open files; it just passes a list of pathnames back to the program - the program may not actually try to open these files at all, or may open/close them one at a time. In either case it is a wrong limitation to prevent multiple files from being passed back to the program.
The problem of "drop" not being allowed at all for MTP seems even more without justification.P.S. the link you gave to paid Microsoft support just gives "Server Error in '/' Application.
- Edited by roeville Monday, November 19, 2012 12:29 PM
MTP exposes the camera as a virtual object, not as a file. And IFileOpenDialog cannot return multiple virtual objects. so we cannot force the IFileOpenDialog to return multiple pathnames for MTP mode.
UMS expose the camera in the file system. IFileOpenDialog can return multiple physical files.
Thanks Jenny. Although MTP exposes the camera as a virtual object, the main use of IFileOpenDialog is to get pathnames as STRINGS. The dialog seems to have no problem listing ALL of the file names in its main windows pane, so I can't understand why there should be a problem with returning multiple file names or pathnames.
Whatever the problems of working with virtual objects, surely this should all be done within the dialog code - destroying and creating objects or whatever else is necessary to allow IFileOpenDialog::GetResults() to return a complete array of information for each selected "file".
It seems crazy that the dialog can DISPLAY multiple file names but can not return them.
The current behaviour is confusing to the end-user who blames the software developer for the restriction, and the developer is similarly confused by this. Explaining to an end user the distinction between UMS and MTP and the technical reasons why this is happening is likely to make their eyes glaze over - they don't want a technical justification, they just want the dialog to work as they expect it to. They will think it is crazy to be told they have to repeatedly open the dialog to add 1 filename at a time to a batch processing list when they can see ALL of the files at once in the dialog's own window pane. And they CAN select multiple files and drag them in Windows Explorer, so why not the file dialog box?
Can you please feed this back to the Microsoft development team, as it really makes no sense from the user's perspective - which in the end is what really matters.
- Edited by roeville Thursday, January 17, 2013 11:41 PM