Common Dialog: Navigable Links?

[lmstearn]

Hi,
Regarding the open file dialog, this goes back to the old common dialogs (COMDLG32.DLL) before Vista where in opening a shortcut, one could provide the programmatic option of either opening the link file as is or navigating to the directory to where the resolved file link resides. Does anyone recall this behaviour?
If so, read on:
The newer system (v6) provides the option of an Open dialog where OFN_NODEREFERENCELINKS can be switched off. The resolved file name can be retrieved as long as *lnk is not included in the filter. This ends the dialog, so there never is any navigation to the folder where the resolved shortcut lies.
In that scenario, any visible pidls or symbolic links can also be navigated to, but file selection may not be possible.
The newer system works fine for most, the folder navigation is more for geeks who might wish to quickly browse through a folder of quick access shortcuts where the targets and their contents might want to be inspected for housekeeping or other reasons. There is a bit more of a ramble about it at AHK, is there a way of customizing the new dialogs to implement the described effect?
Thanks.

[wqweto]

IMO .lnk files are traversed i.e. are not selected by default so linked folders are open.

I cannot comment on if it is OFN_NODEREFERENCELINKS or including *.lnk mask in the filter that switches this default behavior off.

Btw, junctions are always traversed as these are not files at all and are implemented at lower FS level. A geek would create a folder full of junctions to common directories so that OFN would always traverse.

Is the question about customizing the *behavior* of OFN or (generally) customizing the UI of it?

cheers,
</wqw>

[lmstearn]

@wqweto: thanks for the response. Yep, more about the behaviour of it- MS Docs only appear to document customization- that link was included just in case it lights up a trail travelled by a reader here.
Essentially the open file dialog has to act as an open folder dialog when a lnk shortcut is activated, once activated it reverts to the open file dialog.

[fafalone]

Ok, so I'm having trouble following exactly what you want to do here. You want to double click a .lnk that points to a file, and instead open the folder where that file resides?

I believe you can do that with IFileDialog.

You should be able swap the vtable in IFileDialogEvents_OnFileOK to a Function where you can return a non-zero value that will block the dialog from closing (you'd obviously want to examine the file chosen to see if it's a link before that), identify the target folder yourself, then initiate a navigation action with .SetFolder. You can use IFileDialogCustomize to add a checkbox to toggle it too.

It's a lot of work just to avoid right-click the shortcut and selecting 'Open file location', which opens it in the current dialog, but I'm no stranger to going through extraordinary lengths just on principle over something like this. Old thread so I don't know if you're still interested, but if you are... let me know I'll give it a shot.

[lmstearn]

@fafalone: Thanks for the reply.
It turned out to be one of those feaping creatures that had crept out of the libraries, with the fanfare turned all of a hush, and followed by a similar reaction in the community. Have moved on since opening this thread, very happy to know it could be done, but as you indicated, not easy. Thanks for the offer too- guessing it falls into the category of those projects considered worth doing only if there is wider call for it. After all, it was MSFT that first came up with the idea.