Win32 API中的GetOpenFileName()会导致PhysFS问题吗?

时间:2018-11-02 10:58:35

标签: winapi

我有一个烦人的问题,我正在Win32中用C语言编写一个推箱子游戏,并且正在使用Code :: Blocks IDE。我使用PhysFS将程序使用的媒体文件(当前的bmp和wav)存储在7-zip文件中,并且可以正常工作-直到程序到达调用GetOpenFileName()的位置才能打开文件(包含级别,以便用户可以玩实际的游戏…)。我使用它从普通文件系统中打开.txt或.slc文件(一种xml格式),因为用户应该能够根据需要添加和删除级别文件。调用GetOpenFileName()之后,PhysFS报告它不再找到7-zip文件,实际错误消息为“未找到”,错误代码为0。

我认为GetOpenFileName()是罪魁祸首的原因是这样可以奏效(即播放声音):

PlayWavFromRes("/wav/test.wav");
if(GetOpenFileName(&ofn)){
    GetLevel(hwnd, szFileName, TRUE);
}

…但是不会(例如,声音不播放并且我收到错误消息):

if(GetOpenFileName(&ofn)){
    PlayWavFromRes("/wav/test.wav");
    GetLevel(hwnd, szFileName, TRUE);
}

我是否尝试在GetOpenFileName()之后打开WAV或BMP都没关系–都无法正常工作,因为7压缩文件“找不到”。

我的OPENFILENAME结构是这样初始化的,我认为应该没问题:

ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFilter = "Sokoban level files (.txt, .slc)\0*.txt;*.slc\0All Files (*.*)\0*.*\0";
ofn.lpstrFile = szFileName;
ofn.nMaxFile = MAX_PATH;
ofn.Flags = OFN_FILEMUSTEXIST;
ofn.FlagsEx = 1;

和szFileName字符串像这样初始化:

char szFileName[MAX_PATH] = {'\0'};

我知道GetOpenFileName()已被取代,我已经看过“公共项目”对话框,但是我用C语言在代码块中编写代码,因此要做的工作太多了。如果我不能使用GetOpenFileName(),我想我将使用列表框创建自己的打开文件对话框,但是在此之前,我想我会检查是否有人遇到相同的问题。

我还要提到GetOpenFileName()确实确实打开了一个文件,并且我可以从文件中读取推箱子的水平而没有问题。唯一的“副作用”是PhysFS的问题。

我不认为PhysFS是个问题,因为它在调用GetOpenFileName()之前就可以工作,而且我还在另一个项目中使用了它,该项目可以完美地从7-zip存档中检索bmp和midi文件。上一次构建它时,我只支持7-zip和zip文件,因为我不需要其他文件格式。我对两个项目使用相同的版本。

请让我知道是否需要更多代码,但是我认为这应该是相关代码。

任何意见或建议,无论被赞赏多少;我习惯于自己寻找东西(毕竟这只是我的第三个问题),如果我能暗示什么是错的话,那的确会让我非常高兴!

0 个答案:

没有答案