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 Mr enhzflep and Mr DavidCrow, First of all, thank you so much about your clearly explanation. I just still have a consideration, why the small expression (& 0xFFFF) has been still used in the expression ((l) >> 16) & 0xFFFF) here . And this expression origins from window library, hix. Why they still have used this expression if it was not necessary in here ? Once again, thanks for your help, Mr enhzflep and Mr DavidCrow. Best regards, Duong Quoc Thang

Dear everybody, I have a question about the meaning of & operator in the following expression: ((WORD)(((DWORD)(l) >> 16) & 0xFFFF)) 1) What role does the & operator do here ? 2) Why do programmers often use & with hexadecimal, not integer or long integer or double ? I'm looking forward to seeing your reply soon. Best regards, Jetflower