如何防止 GetOpenFileName 在显示对话框时更改当前目录？

Question

GetOpenFileName（出于可疑原因）在显示对话框时更改应用程序的当前目录。这可以通过将OFN_NOCHANGEDIR 指定为对话框初始化标志来在对话框关闭时重置：

OFN_NOCHANGEDIR 如果用户在搜索文件时更改了目录，则将当前目录恢复为其原始值。

然而，设置此标志并不会阻止函数在显示资源管理器对话框时更改当前目录。

这是多线程环境中的一个问题，其中其他线程依赖当前目录作为可执行文件的路径。

有没有办法防止GetOpenFileName 在显示资源管理器对话框和用户浏览文件夹时更改应用程序的当前目录？

Answer 1

你有几个选择：

1. 使用 detours 或 MinHook 挂钩 SetCurrentDirectory 并使其对您的进程无能为力（丑陋）
2. 使用不会更改当前目录的custom file chooser。 （更好）
3. 删除代码中当前目录的依赖项，因为您可能会遇到其他相关的错误，尤其是在多线程环境中。 （最佳）

Answer 2

我决定发布一个可行的解决方案。它涉及“正确”修复代码以使用绝对路径，但请耐心等待。这并不难。 OP发布的答案太危险了。它一点也不“便宜”。相反，从长远来看，它可能会非常昂贵。

现在我假设在代码中散布着函数/方法调用，这些调用通过相对路径名（很可能是不合格的文件名）访问文件或文件夹。可能有很多这些，但它们可能都归结为：

do_something_with_this_file ("somefile.foo");

现在，如果do_something_with_this_file 是应用程序中定义的函数，则解决方案很明显：更改该函数的实现，将传入的参数转换为绝对路径名（如有必要），然后再对其进行任何操作。

但是，如果do_something_with_this_file 类似于对CreateFile 或fopen 的调用，那么生活就没那么容易了。然后我们就被该函数的现有行为所困扰。还是我们？实际上，没有。有一个简单的解决方案，只涉及一个宏和少量的实现工作。

是时候举个例子了。我将使用fopen，因为它有一个很好的简单API，但它同样适用于CreateFile 或其他任何东西。

首先，创建一个头文件，我们将其命名为AbsolutePathHelpers.h，它重新定义了fopen，以及您需要的任何其他内容，如下所示：

// AbsolutePathHelpers.h

FILE *APHfopen (const char *filename, const char *mode);
#define fopen APHfopen
// ...

确保此头文件包含在您的所有编译单元中，可能是通过#include将其包含在他们都使用的一些通用头文件中。

现在将APHfopen 的实现写入一个新的.cpp 文件（我们称之为AbsolutePathHelpers.cpp），您需要将其与您的项目链接：

// AbsolutePathHelpers.cpp
#include <stdio.h>

#undef fopen
FILE *APHfopen (const char *filename, const char *mode)
{
    printf ("Opening %s\n", filename);      // diagnostic message for testing
    // Convert filename to absolute path here (if necessary) before calling the 'real' fopen
    return fopen (filename, mode);
}

// ...

最后是一个简单的测试程序：

// Test program
#include <stdio.h>

int main ()
{
    FILE *f = fopen ("myfile", "r");
    if (f)
        fclose (f);

    printf ("Finished.  Press any key...");
    getchar ();
    return 0;
}

输出：

Opening myfile
Finished.  Press any key...

在Wandbox 运行它。

我将把相对路径转换为绝对路径的细节留给 OP。您所需要的只是一个包含程序启动时生效的当前目录的全局变量。或者，我强烈怀疑，这实际上应该是包含可执行文件的目录。

Answer 3

正如 cmets 中的其他人所提到的，依赖当前目录始终保持不变并不理想。如果不需要重写资源加载工厂（不是我的代码），我会更改它。

然而，一个公认的廉价和混乱的解决方案是挂钩 OpenFileDialog 的窗口过程并对文件夹更改通知做出反应。从那里，以前备份的目录路径可以“强制”作为当前目录。这就是我所做的：

备份：

// Well outside of the OpenFileDialog logic
static TCHAR g_BackupDir[MAX_PATH];
...
GetCurrentDirectory(ARRAYSIZE(g_BackupDir), g_BackupDir);

钩子：

// Hooking procedure specified as lpfnHook parameter to the GetOpenFileName function
// Requires the flags OFN_EXPLORER and OFN_ENABLEHOOK to be set as well
UINT_PTR CALLBACK OFNHookProc(_In_ HWND hdlg, _In_ UINT uiMsg, _In_ WPARAM wParam, _In_ LPARAM lParam)
{
    switch (uiMsg)
    {
        case WM_NOTIFY:
        {
            LPNMHDR pNotify = reinterpret_cast<LPNMHDR>(lParam);
            switch (pNotify->code)
            {
                case CDN_FOLDERCHANGE:
                    // Force back initial current dir
                    SetCurrentDirectory(g_BackupDir);

                    // No further processing on dialog
                    return 1;
            }
        }
        break;
    }

    // Default processing
    return 0;
}

对话逻辑本身似乎不以任何方式、形状或形式依赖于当前目录。即使当前目录被强制返回文件夹更改，它也能完美运行。

进入“有效”类别，不如使用绝对路径。