Why did ParseDisplayName fail ?
-
Dear gurus, I'm having a problem in using ParseDisplayName. 1) I have a path of USB drive, such as: G:\ 2) I pass this driver path into my function, which will call ParseDisplayName to get PIDL item, as below: LPITEMIDLIST CTemp::getItemIDList( CString p_strPath ) { USES_CONVERSION; if( p_strPath.IsEmpty() ) { return NULL; } LPITEMIDLIST l_pIDL; LPSHELLFOLDER pDesktopFolder; if( ::SHGetDesktopFolder( &pDesktopFolder ) != NOERROR ) { return NULL; } OLECHAR ochPath[MAX_PATH]; ULONG chEaten; ULONG dwAttributes; HRESULT hRes; ::MultiByteToWideChar( CP_ACP, MB_PRECOMPOSED, W2A(p_strPath), -1, ochPath, MAX_PATH ); hRes = pDesktopFolder->ParseDisplayName( NULL, NULL, ochPath, &chEaten, &l_pIDL, &dwAttributes); pDesktopFolder->Release(); return l_pIDL; } 3) The hRes result is 0x80070003 指定されたパスが見つかりません. I don't know why it was failed. I also try another way to solve this bug and I realize that, if i access to this USB drive before calling ParseDisplayName, this method ParseDisplayName always return good result, S_OK, such as: a) Call the function ParseDisplayName at the first time, right after calling ParseDisplayName again, the hRes result will be S_OK. b) Declare a file path variable to one file in USB drive. Call ParseDisplayName with this file path, then call ParseDisplayName with the USB drive path, the hRes result will be S_OK. c) Use while loop to browse each drive after using CSIDL_DRIVES, then calling ParseDisplayName, the hRes result will be S_OK. So can you help me to explain two issues: 1) Why does the ParseDisplayName method fail in this case ? 2) Why does the ParseDisplayName method success after accessing the USB drive at first time? If anybody here had the same situation like mine, please help me to clarify the mystery surrounding this phenomenon. I'm looking forward to seeing your replies. Best regards, Jetflower
-
Dear gurus, I'm having a problem in using ParseDisplayName. 1) I have a path of USB drive, such as: G:\ 2) I pass this driver path into my function, which will call ParseDisplayName to get PIDL item, as below: LPITEMIDLIST CTemp::getItemIDList( CString p_strPath ) { USES_CONVERSION; if( p_strPath.IsEmpty() ) { return NULL; } LPITEMIDLIST l_pIDL; LPSHELLFOLDER pDesktopFolder; if( ::SHGetDesktopFolder( &pDesktopFolder ) != NOERROR ) { return NULL; } OLECHAR ochPath[MAX_PATH]; ULONG chEaten; ULONG dwAttributes; HRESULT hRes; ::MultiByteToWideChar( CP_ACP, MB_PRECOMPOSED, W2A(p_strPath), -1, ochPath, MAX_PATH ); hRes = pDesktopFolder->ParseDisplayName( NULL, NULL, ochPath, &chEaten, &l_pIDL, &dwAttributes); pDesktopFolder->Release(); return l_pIDL; } 3) The hRes result is 0x80070003 指定されたパスが見つかりません. I don't know why it was failed. I also try another way to solve this bug and I realize that, if i access to this USB drive before calling ParseDisplayName, this method ParseDisplayName always return good result, S_OK, such as: a) Call the function ParseDisplayName at the first time, right after calling ParseDisplayName again, the hRes result will be S_OK. b) Declare a file path variable to one file in USB drive. Call ParseDisplayName with this file path, then call ParseDisplayName with the USB drive path, the hRes result will be S_OK. c) Use while loop to browse each drive after using CSIDL_DRIVES, then calling ParseDisplayName, the hRes result will be S_OK. So can you help me to explain two issues: 1) Why does the ParseDisplayName method fail in this case ? 2) Why does the ParseDisplayName method success after accessing the USB drive at first time? If anybody here had the same situation like mine, please help me to clarify the mystery surrounding this phenomenon. I'm looking forward to seeing your replies. Best regards, Jetflower
-
Dear gurus, I'm having a problem in using ParseDisplayName. 1) I have a path of USB drive, such as: G:\ 2) I pass this driver path into my function, which will call ParseDisplayName to get PIDL item, as below: LPITEMIDLIST CTemp::getItemIDList( CString p_strPath ) { USES_CONVERSION; if( p_strPath.IsEmpty() ) { return NULL; } LPITEMIDLIST l_pIDL; LPSHELLFOLDER pDesktopFolder; if( ::SHGetDesktopFolder( &pDesktopFolder ) != NOERROR ) { return NULL; } OLECHAR ochPath[MAX_PATH]; ULONG chEaten; ULONG dwAttributes; HRESULT hRes; ::MultiByteToWideChar( CP_ACP, MB_PRECOMPOSED, W2A(p_strPath), -1, ochPath, MAX_PATH ); hRes = pDesktopFolder->ParseDisplayName( NULL, NULL, ochPath, &chEaten, &l_pIDL, &dwAttributes); pDesktopFolder->Release(); return l_pIDL; } 3) The hRes result is 0x80070003 指定されたパスが見つかりません. I don't know why it was failed. I also try another way to solve this bug and I realize that, if i access to this USB drive before calling ParseDisplayName, this method ParseDisplayName always return good result, S_OK, such as: a) Call the function ParseDisplayName at the first time, right after calling ParseDisplayName again, the hRes result will be S_OK. b) Declare a file path variable to one file in USB drive. Call ParseDisplayName with this file path, then call ParseDisplayName with the USB drive path, the hRes result will be S_OK. c) Use while loop to browse each drive after using CSIDL_DRIVES, then calling ParseDisplayName, the hRes result will be S_OK. So can you help me to explain two issues: 1) Why does the ParseDisplayName method fail in this case ? 2) Why does the ParseDisplayName method success after accessing the USB drive at first time? If anybody here had the same situation like mine, please help me to clarify the mystery surrounding this phenomenon. I'm looking forward to seeing your replies. Best regards, Jetflower
Your HRESULT indicates WIN32/PATH_NOT_FOUND. The only thing I can imagine is that the shell has not 'seen' your USB drive yet (i.e. it hasn't handled the mount on the G: reparse point and updated it's data structures). Calling into the shell once (through ::SHGetDesktopFolder) causes it to execute some code, and probably notice the mount event. Subsequent calls will the succeed.
-
I not sure but, but I think had faced the same problem some moths ago and at that time when I changed the CoInitializeEx to CoInitialize( or reverse ) the problem go fixed. Could you please try changing it?
nave [My Articles] [My Blog]
Yes, that could be it. If your threading model is wrong, the shell won't be able to execute except when you call in to it, which explains that it does not see your drive before you allow it execute. See my other answer on this thread.
-
Dear gurus, I'm having a problem in using ParseDisplayName. 1) I have a path of USB drive, such as: G:\ 2) I pass this driver path into my function, which will call ParseDisplayName to get PIDL item, as below: LPITEMIDLIST CTemp::getItemIDList( CString p_strPath ) { USES_CONVERSION; if( p_strPath.IsEmpty() ) { return NULL; } LPITEMIDLIST l_pIDL; LPSHELLFOLDER pDesktopFolder; if( ::SHGetDesktopFolder( &pDesktopFolder ) != NOERROR ) { return NULL; } OLECHAR ochPath[MAX_PATH]; ULONG chEaten; ULONG dwAttributes; HRESULT hRes; ::MultiByteToWideChar( CP_ACP, MB_PRECOMPOSED, W2A(p_strPath), -1, ochPath, MAX_PATH ); hRes = pDesktopFolder->ParseDisplayName( NULL, NULL, ochPath, &chEaten, &l_pIDL, &dwAttributes); pDesktopFolder->Release(); return l_pIDL; } 3) The hRes result is 0x80070003 指定されたパスが見つかりません. I don't know why it was failed. I also try another way to solve this bug and I realize that, if i access to this USB drive before calling ParseDisplayName, this method ParseDisplayName always return good result, S_OK, such as: a) Call the function ParseDisplayName at the first time, right after calling ParseDisplayName again, the hRes result will be S_OK. b) Declare a file path variable to one file in USB drive. Call ParseDisplayName with this file path, then call ParseDisplayName with the USB drive path, the hRes result will be S_OK. c) Use while loop to browse each drive after using CSIDL_DRIVES, then calling ParseDisplayName, the hRes result will be S_OK. So can you help me to explain two issues: 1) Why does the ParseDisplayName method fail in this case ? 2) Why does the ParseDisplayName method success after accessing the USB drive at first time? If anybody here had the same situation like mine, please help me to clarify the mystery surrounding this phenomenon. I'm looking forward to seeing your replies. Best regards, Jetflower