CFileDialog with OFN_ALLOWMULTISELECT incorrect results for shortcuts

Question

Can someone let me know what am I doing wrong here?

MFC project, I'm using CFileDialog to let user pick multiple files, as such:

CFileDialog fd(TRUE, NULL, NULL,
    OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_EXPLORER | OFN_ALLOWMULTISELECT, 
    NULL, this);

if(fd.DoModal() == IDOK)
{
    //Multi-selection
    CString strPaths;
    POSITION fileNamesPosition = fd.GetStartPosition();

    while(fileNamesPosition != NULL)
    {
        if(!strPaths.IsEmpty())
            strPaths += L"\n";

        strPaths += fd.GetNextPathName(fileNamesPosition);
    }  

    AfxMessageBox(strPaths);
}

So if say, there're two shortcut files:

shortcut_1.lnk file that refers to: "D:\Folder\Project_B\Release\Name of Project B.exe"

and shortcut_2.lnk that refers to "D:\Folder\Project_A\Release\Name of Project A.exe"

If I pick both of them from the "File Open" dialog generated by the code above, my resulting strPaths becomes the following, which is incorrect:

D:\Folder\Project_A\Release\Name of Project A.exe
D:\Folder\Project_A\Release\Name of Project B.exe

The second path is wrong!

Answer 1

Using the GetStartPosition() and GetNextPathName() functions is a mess. For one, they use the old-style API which depends on a correct return buffer size defined via OPENFILENAME struct. MFC does not take care of this! As your question shows, it also has problems with links, even if the buffer size is big enough.

Save yourself a headache and use the Vista+ API, which is available through CFileDialog::GetIFileOpenDialog().

Here is a working code sample:

CFileDialog fd( TRUE, NULL, NULL,
    OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_EXPLORER | OFN_ALLOWMULTISELECT,
    NULL, nullptr );

if (fd.DoModal() == IDOK)
{
    //Multi-selection
    CString strPaths;

    CComPtr<IFileOpenDialog> piod = fd.GetIFileOpenDialog();
    ASSERT( piod );

    CComPtr<IShellItemArray> pResults;
    if( SUCCEEDED( piod->GetResults( &pResults ) ) )
    {
        DWORD count = 0; pResults->GetCount( &count );
        for( DWORD i = 0; i < count; ++i )
        {
            CComPtr<IShellItem> pItem;
            if( SUCCEEDED( pResults->GetItemAt( i, &pItem ) ) )
            {
                CComHeapPtr<wchar_t> pPath;
                if( SUCCEEDED( pItem->GetDisplayName( SIGDN_FILESYSPATH, &pPath ) ) )
                {
                    if( !strPaths.IsEmpty() )
                        strPaths += L"\n";
                    strPaths += pPath;
                }
            }
        }
    }

    AfxMessageBox( strPaths );
}

Answer 2

Sounds like a bug in CFileDialog.

Typically, the returned paths are a concatenation of the currently displayed directory path and the selected filenames. In the case of a lnk file, perhaps CFileDialog is extracting just the target filename and concatenating it to the path of the parent folder of the lnk file, rather than just returning the full target path that is inside the lnk file. Hard to say for sure without seeing the actual source code for CFileDialog.

To avoid this behavior, you can include the OFN_NODEREFERENCELINKS flag when invoking the dialog, so you get the full paths to the actual lnk files, and then you can manually resolve their targets using IShellLink after the dialog has been dismissed.