SFGAO_NONENUMERATED?
Matthew Ellis
IShellFolder::GetAttributesOf? The docs only say "The items are
nonenumerated items" which isn't a great deal of help...
Raymond Chen
<m.t....@swansea.ac.uk> wrote:
>Can anyone explain what the SFGAO_NONENUMERATED flag is for in
>IShellFolder::GetAttributesOf? The docs only say "The items are
>nonenumerated items" which isn't a great deal of help...
It means that IShellFolder::EnumObjects won't return them.
(hence "not enumerated")
--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.
Personal requests for assistance will be ignored.)
Matthew Ellis
news:sUAsOEUUjwWOJ5...@4ax.com...
> On Fri, 12 Nov 1999 12:37:05 -0000, "Matthew Ellis"
> <m.t....@swansea.ac.uk> wrote:
> >Can anyone explain what the SFGAO_NONENUMERATED flag is for in
> >IShellFolder::GetAttributesOf? The docs only say "The items are
> >nonenumerated items" which isn't a great deal of help...
>
> It means that IShellFolder::EnumObjects won't return them.
> (hence "not enumerated")
Hokay, that explains that, but it opens up a whole load of new questions:
1) Does this mean that the IShellFolder doesn't have sub items? In which
case, what's the point in having an IShellFolder, and if not, how do you get
the sub items?
2) Or is it that the items can't be enumerated, but will be added by the
shell view by calling SHChangeNotify?
3) Or is it to do with async creation of an IShellView?
4) Or is it how the standard namespace extensions do their asynchronous
enumeration? (Such as listing network files and displaying that flashlight
anim)
Sorry for all the questions!
matt
m.t....@swansea.ac.uk
Chris Becke
"Matthew Ellis" wrote:
> > It means that IShellFolder::EnumObjects won't return them.
> > (hence "not enumerated")
>
> Hokay, that explains that, but it opens up a whole load of new questions:
>
> 1) Does this mean that the IShellFolder doesn't have sub items? In which
> case, what's the point in having an IShellFolder, and if not, how do you
get
> the sub items?
From my reading of the documentation and Raymonds reply the attribute is
returned on objects that are not enumerated by their parent. That is to say
that the IShellFolder does have subitems - the sub items are what get this
attribute.
> 2) Or is it that the items can't be enumerated, but will be added by the
> shell view by calling SHChangeNotify?
Zug? Why bring SHChangeNotify into this? I image that this flag will be
usefull when you have non-enumerable namespaces, or a namepsace where
objects are created on they fly as accessed.
That is, imagine a namepsace where ISF::ParseDisplayName() would create a
new item for any string passed in. It is doubtfull that you would want to
enumerate items created on the fly like this.
Chris
--
Raymond Chen
<m.t....@swansea.ac.uk> wrote:
>> It means that IShellFolder::EnumObjects won't return them.
>> (hence "not enumerated")
>
No, it means that IShellFolder::EnumObjects won't return objects
that are marked as SFGAO_NONENUMERATED. Objects that are not so
marked will be enumerated.
Think of SFGAO_NONENUMERATED as the namespace equivalent of a
"hidden file/directory". A subobject enumeration ("directory
listing") does not list the object.
> how do you get the sub items?
You can't. They're not enumerated. As far as anybody browsing
the namespace is concerned, they aren't there.
Questions 2 3 and 4 are completely irrelevant; I don't know why
you brought them up.
SFGAO_NONENUMERATED is the shell namespace version of
FILE_ATTRIBUTE_HIDDEN.
Matthew Ellis
news:eap6jYGM$GA.203@cppssbbsa04...
>
> "Matthew Ellis" wrote:
> > 2) Or is it that the items can't be enumerated, but will be added by the
> > shell view by calling SHChangeNotify?
>
> Zug? Why bring SHChangeNotify into this? I image that this flag will be
> usefull when you have non-enumerable namespaces, or a namepsace where
> objects are created on they fly as accessed.
>
> That is, imagine a namepsace where ISF::ParseDisplayName() would create a
> new item for any string passed in. It is doubtfull that you would want to
> enumerate items created on the fly like this.
That's why I brought SHChangeNotify into it. If something is created on the
fly, you should at least tell the shell that it's there. And if you're
creating items on the fly, then they don't exist when enumerating them
anyway, so there's no need for the flag!
Matthew Ellis
> On Tue, 16 Nov 1999 17:45:30 -0000, "Matthew Ellis"
> <m.t....@swansea.ac.uk> wrote:
> > how do you get the sub items?
>
> You can't. They're not enumerated. As far as anybody browsing
> the namespace is concerned, they aren't there.
But if you know they are there, can you get straight to them with a
BindToObject?
> Questions 2 3 and 4 are completely irrelevant; I don't know why
> you brought them up.
Because I'm having a bit of a job understanding the need behind the flag,
and when you would want to use it (I was trying to list the possible uses I
could think of for this flag) I don't see why you need to have an object
that isn't enumeratable. Is there an example in use in Windows (any
version)?
Chris Becke
> That's why I brought SHChangeNotify into it. If something is created on
the
> fly, you should at least tell the shell that it's there. And if you're
> creating items on the fly, then they don't exist when enumerating them
> anyway, so there's no need for the flag!
The only thing SHChangeNotify would do is try display it as an enumerated
item which is what we don't want. The purpose of the flag is to tell you, if
you do get this pidl via some means such as ParseDisplayName, or passed into
any one of a number of shell externsion based interfaces (or even in a
clipboard CF_CIDA dataobject) that your UI should (as much as it makes
sense) indicate to the user that this item will NOT appear if its folder is
browsed(ie enumerated).
Chris
--
Raymond Chen
<m.t....@swansea.ac.uk> wrote:
>> > how do you get the sub items?
>> You can't. They're not enumerated. As far as anybody browsing
>> the namespace is concerned, they aren't there.
>But if you know they are there, can you get straight to them with a
>BindToObject?
Right. Like hidden files, you will never see them, but if you
know their names (have their pidls), you can access them by all
the standard means.
>I don't see why you need to have an object
>that isn't enumeratable. Is there an example in use in Windows (any
>version)?
In Windows 2000, the new "Find Files" web page is not enumerated
(because it would be kinda ugly if there was a Find Files item on
your desktop all the time). But if you switch to Explorer View
from the Find Files window, you'll see that it's a child of the
desktop.
Matthew Ellis
That makes sense. I think I see what it's all about now.
Thanks Chris!
Matt
m.t....@swansea.ac.uk
Matthew Ellis
> On Wed, 17 Nov 1999 14:46:54 -0000, "Matthew Ellis"
> <m.t....@swansea.ac.uk> wrote:
> >I don't see why you need to have an object
> >that isn't enumeratable. Is there an example in use in Windows (any
> >version)?
>
> In Windows 2000, the new "Find Files" web page is not enumerated
> (because it would be kinda ugly if there was a Find Files item on
> your desktop all the time). But if you switch to Explorer View
> from the Find Files window, you'll see that it's a child of the
> desktop.
Bingo! Right, I understand now. Except, from what you've been saying, I'm
surprised that it appears at all in the explorer tree. Presumably, it's up
to the caller of the IShellFolder how it displays a non-enumerated item? And
how does the shell's tree know that the item is there to display? Dare I
mention SHChangeNotify again? :-)
Thanks for your help Raymond!
Matt
m.t....@swansea.ac.uk
Raymond Chen
<m.t....@swansea.ac.uk> wrote:
>I'm surprised that it appears at all in the explorer tree.
Would you prefer that when you switched to Explorer view, that
*nothing* was highlighted? How would you like it if you walked
up to a map in a mall and found that the place you were standing
didn't exist?
>And how does the shell's tree know that the item is there to display?
If somebody says, "Psst, the file C:\MSDOS.SYS is a hidden file",
how do you know that C:\MSDOS.SYS is there to display? Because
somebody told you.
Remember, this is just like a hidden file. Try it. Go to a
command prompt, create a directory, and mark it hidden with
attrib. Now open Explorer. Assuming you have Explorer set up to
hide hidden files, the directory won't show up. Now type "start
c:\hidden". You get a window on your hidden directory. Now turn
on the explorer treeview. Wow look, the hidden folder suddenly
appeared in the treeview.
Matthew Ellis
> On Thu, 18 Nov 1999 10:31:14 -0000, "Matthew Ellis"
> <m.t....@swansea.ac.uk> wrote:
> >I'm surprised that it appears at all in the explorer tree.
>
> Would you prefer that when you switched to Explorer view, that
> *nothing* was highlighted? How would you like it if you walked
> up to a map in a mall and found that the place you were standing
> didn't exist?
Putting it like that makes sense :-)
> Remember, this is just like a hidden file. Try it. Go to a
> command prompt, create a directory, and mark it hidden with
> attrib. Now open Explorer. Assuming you have Explorer set up to
> hide hidden files, the directory won't show up. Now type "start
> c:\hidden". You get a window on your hidden directory. Now turn
> on the explorer treeview. Wow look, the hidden folder suddenly
> appeared in the treeview.
Thanks for the help Raymond. I think I've finally got it sussed
(hallelujah!)