Open dialogs malfunction if .exe invoked with module in command line

[nyanpasu64]

noticed Dn isn't a fan of opening the downloads folder if you opened the program with a module file (i.e: double clicked an associated FTM/0cc file to open)

I used to see this, no longer see it.

I've noticed FamiTracker versions in general change how the filesystem browses depending on whether you opened FamiTracker from a module or if you open it from the executable itself

Certain directories just kinda become inaccessible if you open from module

On my machine, if you call the dn-ft .exe and pass in a .0cc or .ftm file, then the Open dialog is missing "This PC".

This occurs regardless if you call it by a 8.3 .exe name or a long path, through either a file association or in a console. (Dn-FT sets itself as a file handler for .0cc files, using a 8.3 path for the EXE, but the module is passed in as a long path. This is not the bug.) It does not occur if you call Dn-FamiTracker.exe -console (a command line argument that's not a file to open).

[nyanpasu64]

[nyanpasu64]

AfxResolveShortcut is sufficient to reproduce the bug even with no file being opened.

[nyanpasu64]

ProcessShellCommand indirectly calls SHGetFileInfo.

turns out calling SHGetFileInfo (SHGetFileInfoA) on existing .0cc files within your user directory (didn't test non-.0cc files) causes the file dialog to break.

no breakage when calling it on existing .0cc files in C:\ (didn't test other users), or non-existent .0cc files within your user profile.

also this bug dates back to ft 0.4.6, but not mspaint or wordpad (first party microsoft mfc apps).

i ran procmon on this single function call. i did notice SHGetFileInfoA accessed a lot of registry HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions{guid}...

procmon records the call stack, it's SHGetFileInfoA -> SHGetFileInfoW -> SHParseDisplayName.

what happens when i function-breakpoint that name in visual studio?

• first break is SHGetFileInfoA -> SHGetFileInfoW -> SHParseDisplayName.
• subsequent breaks are shell32.dll!SHGetFileInfoW -> shell32.dll!_SHParseDisplayName -> windows.storage.dll -> windows.storage.dll!SHParseDisplayName.

---

are you supposed to call ProcessShellCommand within InitInstance? i assume so, microsoft says to.

[nyanpasu64]

RegOverridePredefKey is called because, uhh... something about windows vista.

if the first call to SHGetFileInfo occurs after the call to RegOverridePredefKey, but before the app finishes loading and the user opens a file dialog, then all file dialogs are fucked up.

a shitty workaround is to call SHGetFileInfo (or SHParseDisplayName?) before calling RegOverridePredefKey.