3

One can get the text of the selected item in the list-view of a common dialog. But one can NOT get its PIDL, and if the user has chosen to hide known extensions (the default), then one cannot really tell what file was selected without either its extension or its PIDL.

So possible ways to solve this might be:

  1. Obtain an IShellView from the standard open file dialog. The underlying IShellView can tell what the PIDL is for the current selection. So if I could simply get ahold of the IShellView, I'd be golden. Unfortunately, I see no CDM_xxx that would do it. And I can't think off the top of my head of anything that might achieve it!!! :(
  2. Some other idea?!

We used to rely upon the fact that the Windows 9x, 2000, and XP version of the common file dialog stored each item's PIDL in the LVITEM data (original credit to Paul DiLascia):

LPCITEMIDLIST pidlItem = (LPCITEMIDLIST)pListCtrl->GetItemData(nItem);

However, starting with Vista's common controls and above, that technique fails :(

Any thoughts?

EDIT: I need to be able to obtain this information not only for the currently selected item in the list view, but for all items in the list view.

EDIT2: The reason I need to dig so deep:

In prior versions of our app we provide the ability to: (1) Press a custom button "Preview" that closes the dialog, but transfers to the app the list of items currently displayed in the view, in their visible order, along with the index of the one currently highlighted. This list must be fully specified - seeing 3 files that are all "J1329192" (when there are really 3 files "J1329192.xyz" "J1329192.xzy" and "J1329192.zyx" [in that order) is not useful.

Users are allowed to type a partial filename filter into the "file name:" field, and the common dialog will show only files that match the given partial filter, in the sort-order that the user has chosen. So to report back to the app exactly what the user wanted to preview requires that we be able to query that information from the list view control (or the common dialog itself).

We do other enhancements to the file dialog as well - including an in-place preview pane that shows the user's current selection as a thumbnail, as well as have a custom recent-places interface, etc. All of this was possible (with a lot of work) prior to Vista. Post Vista, I have run into wall upon wall. For the time being, we use a standard file dialog with only a very few features of our own, which doesn't sit well with customers (what happened to feature X?!)

There are other enhancements, but that's a good rough overview. And they all boil down to requiring the knowledge of "really, honestly, what file specifically is in the view at index X?" And for unknown reasons - Microsoft doesn't seem to feel the need to provide such an interface. In fact they never did. Only through some hacking and reverse engineering were we able to figure out how things worked under the hood and get the needed info. And yes, that's unsupported, and yes, MS inevitably broke our code. I don't really blame them for that - what I do find obnoxious is that their newer, spiffier interface is far more closed than their older one - and they did not provide more up-front interfaces - supported interfaces - for doing these dialog enhancements. Its like they took a big couple of steps backwards - and none forwards (in the name of progress).

Mordachai
  • 9,412
  • 6
  • 60
  • 112
  • What's wrong with CDM_GETFILEPATH? – MSN Nov 18 '09 at 17:14
  • That tells you what the common dialog believes is going to be the returned filename from the dialog - including the default extension, whatever the user has typed, etc. It is not simply "the thing selected in the list view" – Mordachai Nov 18 '09 at 17:18
  • What if instead GetItemData you first call GetItem and the cast lParam? The same? – BostonLogan Nov 18 '09 at 17:19
  • That's the implementation of GetItemData, verbatim - so no dice :( – Mordachai Nov 18 '09 at 17:24
  • I thought so :-(. Can you afford separate build for Vista and use its new Common Item Dialog ? – BostonLogan Nov 18 '09 at 17:29
  • I currently have a crazy complicated set of classes that build on the pre-Vista and post-Vista versions of the common file dialog. It abstracts the differences, for the most part, and gives a common interface for the app. Unfortunately, this functionality is required - the ability to know what list of files is in the view, and what their real and true names are. And so far I am totally stumped as to how to achieve that. I am trying to implement my own dialog using IShellBrowser and instanciating IShellView. But sadly, IShellView is very limited in its abilities... and I'm back to here... – Mordachai Nov 18 '09 at 17:38

3 Answers3

3

Send WM_USER+7 to get the browser, and then get its active shell view's IShellView interface.

You know the usual consequence of using undocumented behavior right?

Sheng Jiang 蒋晟
  • 15,125
  • 2
  • 28
  • 46
1

I know this is an old thread but, in Vista+, the old-style dialogs are still supported. You can turn off Vista-style and retain all your custom controls as before. That's what we do: we have a custom preview window in a template hooked into CFileDialog, which appears to be impossible to reproduce in IFileDialog.

I believe you need to pass FALSE in a BOOL parameter in the constructor to turn off the Vista-style dialogs.

David
  • 11
  • 1
1

Ah, I found it. You'll want to use IFileOpenDialog for Vista, which should explicilty support all those operations you mentioned.

MSN
  • 53,214
  • 7
  • 75
  • 105
  • I was aware of this interface, but vague on the details. That looks like an excellent article! I will try this approach as well. Thank you! – Mordachai Nov 18 '09 at 22:54
  • Unfortunately IFileOpenDialog fails to give you direct access to the shell view object - at least in any documented way. I did find that someone suggested you can query the IShellBrowser interface from IFileOpenDialog, which you can use to get to the IShellView. So that's pretty good - and no worse than the answer I selected for this question. – Mordachai Nov 20 '09 at 15:49
  • But ultimately, I need to be able to also add some other custom controls to our version of the Open Dialog - and the IFileDialog interface fails to give you carte blanche access to adding your own controls (just the one's they've decided are allowed, such as checkboxes, pushbuttons, and radiobuttons - but no custom controls). So for our ultimate goals, IFileDialog is an ultimate dead end (well, technically, if we spend the resources figuring out how to extend the shell to previewing our custom files, we could make this scheme work). – Mordachai Nov 20 '09 at 15:52
  • Yes, if you want better control over file picking you may want to write your own dialog that has a file list box. MFC feature pack has some pretty nice shell controls but it is not that difficult to write your own. – Sheng Jiang 蒋晟 Nov 20 '09 at 17:51