FileSelectFile & Shortcuts & Windows 10

[lmstearn]

[Moderator's note: Topic moved from Bug Reports.]

Hi there,
Not a bug report, but more of an observation on the way the Shell handles the file dialogs in the latest editions of Windows:
Create a shortcut to Notepad: as per attached:

Notepad_Lnk.7z

(760 Bytes) Downloaded 129 times

Code: Select all

FileSelectFile, OutputVar, 3,, Open a file`, Shortcuts resolved, (*.exe; *.bat; *.com; *.cmd; *.pif; *.msc; *.lnk; *.scr)

Open the dialog and select the lnk file, and there is no more navigation into the folder via the folder shortcut.

Worth noting, that in removing *.lnk from the filter, the link still shows in the dialog for :

Code: Select all

FileSelectFile, OutputVar, nOptions,, Open a file`, Shortcuts resolved, (*.exe; *.bat; *.com; *.cmd; *.pif; *.msc; *.scr)

... regardless of what is in nOptions or whether the *.exe filter is present or not.
It used to work, but unable to recollect from what epoch.
No big deal, as what V2 is offering will be an improvement.
Thanks for reading!
Edit: The CLSIDS (e.g. Start Menu Folder, My Computer) don't seem to work either in FileSelectFile as they do in the Run command.
Built-ins like A_StartMenu and A_ProgramsCommon still work with FileSelectFile.
The online documentation is marking a change in parameters for the next release:

FileSelectFolder, OutputVar , StartingFolder, Options, Prompt

[lexikos]

I don't get the point of this topic, or why it was in the Bug Reports forum. The behaviour is intuitive, standard to all Windows file dialogs, and has probably never changed in the history of Windows (at least since this type of file dialog was introduced).

File dialogs behave as follows:

• If the filter includes *.lnk, selecting a shortcut file returns the path of the shortcut file itself.
  Otherwise...
• If the shortcut's target is a folder, selecting the shortcut is the same as selecting the shortcut's target.
• If the shortcut's target is a file which matches the current filter, selecting the shortcut is the same as selecting the shortcut's target.
• Otherwise, the shortcut is not shown, nor would its target be shown.

So in other words, a shortcut file is treated the same as its target, except in the case where the filter includes *.lnk, since the user presumably wants to select the shortcut file itself. If the filter is only *.lnk, the target of a shortcut is never a valid selection since it can't be a lnk file. If the dialog didn't allow selection of lnk files when only lnk files are shown, it would be mostly useless.

Changing the filter to *.* causes all shortcut files to be shown, and selecting a shortcut will return the path of the target, not the shortcut itself. Shortcuts to folders are also shown, but cause navigation into the folder.

One can change the current filter to something not in the list by typing it into the filename box and pressing Enter. Changing the filter affects which shortcut files are shown and what effect they have.

This was all confirmed with Notepad's Open dialog on Windows XP.

Oddly enough, .url files (such as shortcuts to Steam games) are shown on Windows 10 but cause a warning dialog that just says "Catastrophic failure".

[lmstearn]

Hey, thanks for the response. These episodic fetch & carry brain agents have gone AWOL again.
Thus one might even have to hearken to before the lnk structure was introduced, apparent in the old style dialogs, or someone's custom version of one. There existed provision, or at least an option in the filedialog to handle a .lnk file as if it were a folder shortcut. When the link was double-clicked, the dialog would stay open and display the target path of the file, with the target file itself selected in the dialog. Opening this resolved target will close the dialog as in the other cases.

It looks as if this (not completely useless) feature was ditched with the newer versions of Common Controls. (Bookmark to self: This replacement.)

Edit: It's possible COMCTL32.dll version 5.82 had the feature, although that would have been around the time AHK was first installed here.

[lmstearn]

Many apologies for bringing this up again- the good news is we have had plenty of time to collate more info on the issue.
It relates to the following quote from FileSelectFile:

32 [v1.0.43.09+]: Shortcuts (.lnk files) are selected as-is rather than being resolved to their targets. This option also prevents navigation into a folder via a folder shortcut.

It's all to do with OFN_NODEREFERENCELINKS- which has, for some time not been included as default, in the code there is:

// v1.0.43.09: OFN_NODEREFERENCELINKS is now omitted by default because most people probably want a click
// on a shortcut to navigate to the shortcut's target rather than select the shortcut and end the dialog.

Not happening, as any navigable links aren't being dereferenced with the flag not set. There doesn't appear to be anything wrong in the AHK code, so there may in fact, be a bug in the common controls library.
Good thing if someone comes along and either confirms or denies this behaviour before further research is undertaken.
Thanks.