Hi, I'm thinking about redesigning my shell browsing programs to use the IShellItem interface instead of pIDLs and am evaluating the possible drawbacks of such a step. Long time ago I stored each item's relative pIDL and its parent item's IShellFolder interface pointer with the item in the treeview/listview. A side effect was that I often couldn't delete items in Windows Explorer anymore if they were displayed in my program - Explorer complained about open references to the item. The reason seemed to be the IShellFolder pointer I stored with the item (I called AddRef on it - maybe I should have used weak interface pointers instead), so I changed the implementation to store absolute pIDLs only and split those absolute pIDLs to a IShellFolder pointer and a relative pIDL whenever needed. The problems vanished and all was fine - until Vista. Vista introduced many new/heavily reworked shell features, e. g. the property system and the new thumbnail engine. The IShellItem and IShellItem2 interfaces seem to be the new backbone of Vista shell, at least the new/reworked things seem to be built around these interfaces. Therefore I'm thinking about redesigning my apps to use and store each item's IShellItem interface pointer instead of its' absolute pIDL. But I'm a bit afraid that this would bring back the old problems of open references to files that shall be deleted. Are those worries legitimate? Of course I could continue storing the absolute pIDL only and create an IShellItem object from it whenever needed, but this would be slower than storing the interface pointer directly. Timo -- www.TimoSoft-Software.de - Unicode controls for VB6 "Those who sacrifice freedom for safety deserve neither."
Hi, Do you know that IShellItem has been introduced at WinXP? Or you already don't support older OS versions? About your problem: I can't understand how delete shell item is concerned to stored IShellFolder? > Explorer complained about open references to the item What is this message? Thanks, SeraTJ
Sera schrieb: > Do you know that IShellItem has been introduced at WinXP? Yes. > About your problem: I can't understand how delete shell item is > concerned to stored IShellFolder? I don't know. It didn't happen always, only sometimes. Since I no longer store an item's IShellFolder (for which I also called AddRef()), the problems are gone. >> Explorer complained about open references to the item > What is this message? Free translation from German: "XYZ cannot be deleted: The file is in use by another person or program. Close all programs that may be using this file and try again." Timo -- www.TimoSoft-Software.de - Unicode controls for VB6 "Those who sacrifice freedom for safety deserve neither."
I think you store handle to opened file in CShellFolder class. The question is how your IShellFolder implementation is organized. When do you open system handles and when do you free them? The implementation of IShellFolder must not operate real data in constructor. It must defer operations with real data to queries like EnumObjects or CreateViewObject(IShellView).
I do not implement IShellFolder, I use it. I'm talking about a shell browser, not a namespace extension. So if a namespace extension stores an open file handle in its implementation of IShellFolder, there's nothing I can do except not store the IShellFolder pointer. Hmm, this somehow answers my own question: I should not store interface pointers for later use because there may be misbehaving namespaces. Timo -- www.TimoSoft-Software.de - Unicode controls for VB6 "Those who sacrifice freedom for safety deserve neither."
Sorry, I've understood now. You are working on browsing application like Windows Explorer. In such case you must not store any objects - pointers to IShellFolders or IShellItems. I have stupid example. If we must store list of files, we can: a) store array of full names (or relative names if they are in the same folder); b) store array of handle to these opened files. The case b is very bad design & programmer will get many problems. It is concerned not only to shell, but for any program design. So, I think store full or relative PIDLs will be good choice. Thanks, SeraTJ
"Timo Kunze" wrote in message news:u$GOw3qbIHA.1132@TK2MSFTNGP06.phx.gbl... > > I'm thinking about redesigning my shell browsing programs to use the > IShellItem interface instead of pIDLs and am evaluating the possible > drawbacks of such a step. > clearly you lose backward compatibility! pre-vista, holding an IShellFolder* didn't lock the folder in any way (only if you SetCurDirectory on it) but in vista, it _does_ so you can't delete it if they did it historically, then these IShellItems must be relying on folders and pidls, so they should be more resource-intensive. But only an experiment will settle this question, time a folder reading with traditional enumeration or with the "new" shell items have you seen any functionality that is _only_ available through IShellItem? I haven't noticed any, even with the property system -- although I didn't investigate the new thumbnail infrastructure hth nikos --- www.zabkat.com
Hi, nikos bozinis schrieb: > have you seen any functionality that is _only_ available through IShellItem? That's right, but IShellItem sometimes makes things a bit easier. Because I can't be sure that the namespace I'm browsing doesn't lock any directories or files as long as I hold a reference to it's IShellItem or IShellFolder, I will continue storing pIDLs only and create IShellItem objects only when needed. BTW, you should have a look at IPropertyDescription. I have not yet used it, only read the docs, and have not yet understood the entire property system. But it seems a bit like the grouping stuff is done through the property system now. E. g. IPropertyDescription::GetTypeFlags() can check for a flag PDTF_ISGROUP which specifies whether a property is a group heading. Maybe the property system allows us shell browser authors to implement grouping right at least on Vista after this poorly implemented ICategoryProvider thing of XP. But don't put too much hope in it. You know, Microsoft doesn't really care whether the shell API is usable from anything else but MS software. So I wouldn't be surprised if the property system is as poorly implemented as so many parts of the shell API in XP and Vista. Best regards Timo -- www.TimoSoft-Software.de - Unicode controls for VB6 "Those who sacrifice freedom for safety deserve neither."
