Obtain the true name of the currently select file in the common file dialog?

Question

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).

Answer 1

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?

Answer 2

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