Question

我对FindNextFile有一个相当尴尬的问题。我已附上下面的相关代码块。

在99％的情况下，代码完美无缺。问题是文件夹名称以浮点值开头。我有一个包含"0.0W"，"1.0W"，"3.9W"，"4.1W"和"7.0W"的文件夹。这些是驱动器上文件夹的名称。当我尝试从返回的WIN32_FIND_DATA结构中获取字符串时。我抓取参数lcFindData.cFileName这是一个宽字符串，内容不正确。

即。

"0.0W"返回"0W"
"1.0W"返回"1W"
"3.9W"返回"3.9W"
"4.1W"返回"4.1W"
"7.0W"返回"7.0W"

据我所知，它将浮动转换为浮点数然后将它们转换回字符串使它们不准确。除7.0W之外，它似乎很高兴......

void nsDialogFunctions::cFileList::ListFolders(string lsPath,uint32 liMax)
{   
    //Empty List
    SetItems(0);
    lsPath+="/*";
    HANDLE hFind = INVALID_HANDLE_VALUE;
    WIN32_FIND_DATA lcFindData;
    //Find First Folder (".")
    hFind = FindFirstFile(nsConversionFunctions::ConvertToWString(lsPath).c_str(),&lcFindData);
    DWORD dwError=0;
    if (INVALID_HANDLE_VALUE == hFind) 
    {
       return;
    } 
    // Fins Second Folder ("..")
    FindNextFile(hFind, &lcFindData);
    //Find first valid folder
    FindNextFile(hFind, &lcFindData);
    // List all the files in the directory with some info about them.
    do
    {
        if ((lcFindData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
        {
            string *lcTemp=new string;
            //lcFindData.cFileName is sometimes wrong here. 
            //It is wrong before entering ConvertWString
            lcTemp[0]=nsConversionFunctions::ConvertWString(lcFindData.cFileName);
            Add(lcTemp);
        }
    }
    while (FindNextFile(hFind, &lcFindData) != 0 && (!liMax || Items()<liMax));
    FindClose(hFind);
    return;
};

我对hFind做错了吗？

我可以更改设置以删除此行为吗？

是否有另一个获取返回字符串的访问点？

Answer 1

FindFirstFile，FindNextFile返回文件系统对象的正确名称。然后，ConvertWString中的代码会将这些名称修改为您看到的值。

我不是你决定使用8位文本的忠实粉丝，除非文本是UTF-8编码的。如果您的文本是ANSI编码的，那么使用宽API无法获得任何好处。调用FindFirstFileA，FindNextFileA等并让系统执行文本转换会更好。肯定会说得对！

FindNextFile返回的文件夹名称问题

1 个答案: