 |
|
 |
With my test in XP sp2, getting infotips can't return any info. Anybody know that?
|
|
|
|
 |
|
 |
i have the same problem.. any help???
|
|
|
|
 |
|
 |
I used it for dumping lists. void IDListDump( LPITEMIDLIST inList, LPCTSTR lpszName ) { TCHAR szName[MAX_PATH]; CItemIDList item( inList ); CItemIDList item2; TRACE( "\nItemIDList: %s\n", lpszName ); for( unsigned int i= 0; i < item.GetCount( ); ++i ) { item2= item.Duplicate( i + 1 ); item2.GetDisplayName( szName ); TRACE( " At: %d ~ %s\n", i, szName ); } TRACE( "\n" ); } Best, Dan.
-- modified at 20:28 Thursday 24th May, 2007
|
|
|
|
 |
|
 |
This class is a great time saver.
Do you think there are any more "known" memory leaks or bugs?
Regards,
Gautam Jain
|
|
|
|
 |
|
 |
Should be no.
|
|
|
|
 |
|
 |
As I can see there are some errors. Although I didn't tested it and may be wrong.
1. GetAt method does excess copying of pidl. CreateOnePidl have allocated memory already.
2. GetPath works for pidls pointing to filesystem objects. Not virtual ones.
3. operator= should check for self-assignment before Empty(). Example:
CItemIDList pidl("something");
pidl = pidl; // pidl becomes empty. Not good.
4. operator+= should return const CItemIDList&
5. operator== should be friend. To allow comparing raw LPITEMIDLISTs.
6. Where're operators <, <= etc ?
7. operator[] identical to GetAt.
Hope it will help to improve CItemIDList functionality.
Roman Varenik
|
|
|
|
 |
|
 |
Thanks for your comments.
1,3,4,5,7 already corrected.
3th point: I think the benifits of using 'friend' exactly is you can write like this:
LPITEIDLIST pidl;
CItemIDList iidl;
//DoSomething to pidl and iidl
if(pidl==iidl){
}
Say hello to my little friend.
|
|
|
|
 |
|
 |
Without having tested it, I think this class is a good addition for everyone who is forced to work with those messy pIDL stuff.
On a quick glance, I like your clean formatting of the interface of your class very much.
You could add a paragraph about the "Why?" of this class though. Especially beginners (for which your article seems to be intended) would profit a lot, I think.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
 |
|
 |
Thanks for your advice.
I'll consider that later.
The new version is coming.
Say hello to my little friend.
|
|
|
|
 |
|
 |
Hi
your GetDisplayName method leaks for STRRET_WSTR; the docs aren't very clear about it but the returned wide pOleStr should be freed with shell's allocator after use. See the docs for StrRetToBuf
nice class to get people started though!
nikos
|
|
|
|
 |
|
 |
Thanks for your advice.
I've noticed that before...but when I added free code to the new version,my application which used this class crashed...
This class will be update soon...
Say hello to my little friend.
|
|
|
|
 |
|
 |
i think the reason for your crash is, that you make a call to WideCharToMultiByte with the assumption that pszText has the length MAX_PATH.
WideCharToMultiByte(CP_ACP,0,str.pOleStr,-1,pszText,MAX_PATH,NULL,NULL);
the GetDispName should have one more parameter: length of buffer
bool GetDispName(LPSHELLFOLDER lpsf, LPITEMIDLIST lpi, DWORD dwFlags, LPTSTR lpFriendlyName, DWORD dwBufferLength)
...
bool GetDispName(STRRET& str, LPCITEMIDLIST pidl, LPTSTR pszText, DWORD dwBufferLength)
{
...
WideCharToMultiByte(CP_ACP,0,str.pOleStr,-1,pszText,dwBufferLength,NULL,NULL);
...
}
|
|
|
|
 |
|
 |
Thanks.This make the code stronger.
But this is not the point which cause crash,I've always passing the buffer with MAX_PATH length.
________________________________________
Say hello to my little friend.
|
|
|
|
 |