The Old New Thing

There's been like 5 opportunitis to fix it. How many new OSes and service packs were released? Many new interfaces were created, and nobody would create a '2' version of this particular interface? That's so lame. Oh, and "Safe removal" functionality is broken in Windows 2008. I suspect it's partially because of UAC, but why the tooltip was replaced back with a dialog?

The enumerator could return one item that said "there is nothing here", but you would have to be able to visually distinguish this from an actual item whose name is "there is nothing here".  Although I think Raymond's post says that this is not possible due to the structure of enumerators and so on.

If you did what the commenter asked, though, other people would ask why it wasn't done the other way.  You could add yet another user-configurable option, although MY view is "who cares which was this is done?".

We need a new interface then. The shell loves to do this (just look at IContextMenu and all it's descendents).

The interface of course would be named IShellFolder3, and as usual of new interfaces, would have only one method more, GetExtendedError(LPWSTR errText, DWORD dwCb), that returns S_OK if errText was set, or S_FALSE if there is no error.

As for how to display that text in the explorer tree-view, I suggest you look at Visual Studio's resource editor pane. When there is an error, there is a single child item with an MB_ICONSTOP lookalike icon and the error text. Unexpanding and re-expanding the tree will try to reload the resource file.

I may not have understood everything... (despite frequent reading of this blog, I lack the hands-on experience to memorize these things)

Who shows the modal dialog? Because of your focus on return values of EnumObjects, it seems that it is EnumObjects... If so, aren't these methods callable by non interactive programs? Does it make sense then  to display a dialog? Shouldn't this case be handled with a dedicated error code (EMPTY_DRIVE or something) in EnumObjects and a UI in the caller?

If it is CreateViewWindow that displays the dialog, then why doesn't display the message in the created view? I understand that in this case, the view isn't created, but what if it was? What would explorer do that it shouldn't?

All in all, I'm sure it is quite clear in your mind why it is not easily possible, but for someone like me, the dots are too far apart...

The commenter was not Anonymous, but rather "AndrewSeven".

I think you meant IShellFolder::CreateViewObject as opposed to IShellFolder::CreateViewWindow and IShellFolder::CreateShellView (which do not exist).

You can do what Koro says; as for how IShellFolder::CreateViewObject decides what to do, you could add a new interface (IShellView4, IID_IShellView4) and use the new behavior only for IShellView4 and later.  Or add IShellFolder3 and use the behavior only for views created from IShellFolder3 objects.  IShellFolder3 could have a method to control what behavior to display.  It's not impossible to do.  Granted I don't know the intricacies involved, but it doesn't sound all that difficult.  However, I don't even see it as a problem worth "fixing"; I think it's fine how it is.

The Shell interface already support returning special logical objects with no correspondence with any actual file (like the trashcan, the control panel, etc). So the "no media" could simply be a logical file with the proper information and PIDL.

For the tree view, simply skip the dialog and sub-tree. If it's empty (no media) then there is nothing to show. I think an error is superfluous: not showing anything is the "error" for the tree view. If end-user testing show this to be confusing, simply put that logical file under the leaf.

Obviously Microsoft needs to fix this by adding a dreaded "hidden API," for which the slashdot crowd can then flog it mercilessly.

Why not just use the returned error code from IShellFolder::EnumObjects to tell Explorer to output an error string in the view? An entire string doesn't need to be returned, as it is evident from its current behavior that if an error code is enough to display a dialog with a string error, that the same can be applied to the view.

'The view window calls IShellFolder::EnumObjects to figure out what to show in the view—and here is where the error dialog appears asking you to insert a disc into the drive.'

The IShellFolder object doesn't seem to follow good OOP principles.Since its written in C++ there really aren't any good excuses for this.If IShellFolder were implemented as a abstract class with all pure virtual methods then the behavior could be flexible enough for all objects that need to use it (including Explorer) provided that they provide a implementation for the methods that must be overridden.

Data stuctures for error handling would have to be redesigned to have a error code and a message but it could be done and the code would be much more flexible. A lot of the design issues here come from using error codes instead of structured exception handling and not leveraging Inversion Of Control techniques but the original designers were likely unaware.

'[Redesign of external behavior = incompatibility. Oh, and IShellFolder implementations were not originally written in C++. -Raymond]'

For the first point,when I write of Inversion Of Control techniques, I'm actually speaking of a redesign of internal behavior. The external behavior or interface remains constant and allows more flexibility if the callers only depend on the external interface or behavior.

As for the second point now that IShellFolder is written in C++ since the scope resolution operator is not present in C then it follows that the refactoring that I describe is possible.

P.S. For those who are unfamiliar with IoC:

http://en.wikipedia.org/wiki/Inversion_of_control

I think the way to resolve this issue is to post an uninformed rant on your blog!

"why navigating to a drive with no media displays a dialog instead of showing the error message in the view"

BTW, what if a user (not programmer) asked about this? Because the explanation is quite technical.

I'll bite :)

In enduser speak:

"why does navigating to a drive with no media display a dialog instead of showing the error message in the view?"

In order to show something in the view, there has to be something there in the first place.

An empty folder is still a something.

When there's no media, there is no something.

I'm afraid that I share Nawak's confusion. Who owns the modal dialog? Is IShellFolder::EnumObjects itself throwing up modal UI? That doesn't seem right. Explorer.exe is the actual UI app that's calling these interfaces--why doesn't it notice that there are no objects to enumerate and then lay out a nice error screen?

What about the answer "it depends"?

If the error number is returned when expanding the tree, display the dialog but if it is during the binding of the details pane, place the message in that panel.

This would leave the interface as is and thus not break any existing applications.

Raymond, I fail to see how this is different from any other special shell folders and shell items. If an application break due to this, then it will break when it sees other special shell items, like trashcans and the control panel. When queried, the item won't have much functionality, but it is a valid item.

The only times this would matter is if an application is trying operations like deleting the folder, moving the folder contents, etc, which will fail anyway since there is no media, so no real harm done.

[And how does IShellFolder::CreateShellView decide whether to do things the old way or the new way? And what is the priority for fixing this problem, anyway? It's not like this is a data loss bug. -Raymond]

QueryInterface does wonders for discovering any new functionality for the code that wants it...

No object to enumerate != No media

They're two different conditions (no objects to enumerate is just an empty folder)

"Who owns the modal dialog? Is IShellFolder::EnumObjects itself throwing up modal UI?"

Yes, notice the first parameter to IShellFolder::EnumObjects is the HWND of the parent window. That's used for any modal dialogs that need to be displayed.

Seems like a case where it might be worth versioning the interface and adding something like EnumObjectsEx that lets Explorer decide what to do in this case. Presumably the new version could return an appropriate error code to indicate that the drive was empty.

Even though it's not a data loss issue, that's no excuse for not finding an answer to these little annoyances that add up to worsened user experience.

Modal dialogs, and particularly message boxes, rarely seem like appropriate UI to me, since they require a click that imparts no information, they break the users train of thought, and they frequently don't match the interface style of the UI.

[ok, now I'm stepping off my soapbox]

[Nice rant, but you didn't answer the question: "If you expand a node [in the tree view] for an empty floppy drive, where is the "Sorry" message supposed to appear?" If only time were the only resource necessary for solving problems. -Raymond]

The little triangle (or plus) goes away, and a red x is overlayed on the drive icon.

[And how is the enumerator supposed to know whether it's being called by the tree control or the details pane? -Raymond]

As other people have said, IShellFolder3. New interface can have  EnumObjectsEx which takes a new parameter- dwFlags, and when called with ISF_FLAG_FAIL_ON_NO_MEDIA, it returns 80070458 (ERROR_NO_MEDIA_IN_DRIVE).

(It can have CreateViewObjectEx too)

Existing code wont call these methods, so they wont get the new behaviour, and the default with the Ex functions is to keep the old behaviour anyway.

I agree that you cannot change what IShellFolder::EnumObjects does. Nor can you make view creation fail when there's no disc in the drive. Things depend on that.

But I don't see why there couldn't be a new interface derived from IShellFolder with an EnumObjects2 method that has the required flags and out values to do what's needed. Old code would continue to call the old EnumObjects and get the old behaviour.

Showing a "No disc in drive" message in the tree under the drive (or indicating it as part of the drive label or as an infotip on the drive) seems like a good solution as well.

<< but designing in a special case to a general interface just for one program tends to create resentment for others: "How come Explorer can do this but my program can't?" >>

I don't understand why other programs couldn't use the interface as well, i.e. call EnumObjects2 and take action accordingly.

"And what is the priority for fixing this problem, anyway?"

-1, clearly. This week anyway.

I think what people want to see here is a different icon on the tree and a message in the view side (a bit like the empty list text added to the ListViewCtrl recently). Rather than a message box.

I don't see the need to add or change interfaces or behaviour of those that exist. Why not just create a different view in IShellFolder::CreateViewWindow. One that says "hey, there's no media in the drive" instead of showing the files. Then you won't need to change the enumerator (which seems like a bad idea). This shouldn't break exisiting apps (except those that depend on the type or implementation detail of the usual view). You might even be able to do it in the original view. It has a pointer to the IShellFolder right? Why not check if the object is a removable media drive and if it has media before calling EnumObjects and then put up the message.

I'd agree that this is only a minor issue, but it is irritating when navigating down the tree view with the keyboard over a removable drive.

I don't have a problem with Explorer displaying a message box if it wants to.  What bothers me is that an enumeration function is displaying the messagebox itself instead of returning a failure code and letting the caller figure out how they want to show the error.

Still, at least it's documented that way.

That would be consistent with my impression of how many COM interfaces have been born over the years.

Essentially, once upon a time there was code in Windows or Office that needed to be reused, so Microsoft cut around it with a jigsaw, made the cut an interface, and left the existing code untouched to avoid breakage.

Microsoft wouldn't be the only company to develop a platform this way, although it might have kept going longer than anyone else. The downside is that parts of Windows look like jigsaw puzzles.

Follow-up question: Does the enumerator also eject the CD tray if you click on an empty CD drive in Explorer?

Mike: It does for me on Vista.

Or are you asking whether the EnumObjects implementation itself does it, or some other component? It should be easy enough to write a test application to find out...

[Okay, but that's adding a flag for one specific implementation to a general-purpose interface. Some people might call that poor engineering. -Raymond]

Perhaps, but it didn't stop you guys from adding <a href="http://msdn.microsoft.com/en-us/library/bb774820(VS.85).aspx">IShellView3</a>.

I'd be very interested to know whether anyone ever inserts a disk when prompted. (can CEIP data track this?) I know I personally haven't, over the years. So most of the time, it's a nag.

And if there's no disk, just return a damn error, forget the dialog.

If someone can't work out that they couldn't enumerate the files on a disk because there was no disk, they have more fundamental problems than the "correctness" of an enumerator making assumptions about intended behavior.

Maybe I'm the only one to see it this way, but the way it is now makes it a lot easier for someone to make his own view of the filesystem doesn't it? No need to take into account all those marginal behaviours like what to do if there's no disk, it's all take care of for you!

Here is a way to have the special case in the view implementation instead of in the IShellFolder interface.

1. Explorer calls IShellFolder::CreateViewWindow

2. The view calls IShellFolder::EnumObjects with a NULL HWND. If the call succeeds, great. If the call fails with an HRESULT indicating a drive with no media, show the error in the view and don't proceed any further.

3. If the previous call failed with an error code that we don't specifially handle in step 2, call IShellFolder::EnumObjects again, this time with a valid HWND.

4. If we got a valid IEnumIDList interface in step 2 or 3, display its objects in the view.

The upshot of this is that we get the behaviour we want without changing the interface, and it's also fairly backwards compatible: if the EnumObjects implementation doesn't return the error codes we're specifically looking for when the call fails with a NULL HWND, we revert to the previous behaviour.

The downshot is that in some failure cases, two calls are made to EnumObjects instead of one.

"No need to take into account all those marginal behaviours like what to do if there's no disk, it's all take care of for you!"

A floppy disk not being in the drive is not marginal these days is it?? A card reader that sets itself up as 4 different drive letters; you're not going to have a memory card in each of them at all times are you?

It might be all taken care of for me, but not in a very nice way if I have my own skinned app and no way to make this dialog 'fit in'...

I just find it bad practice that a method with a name EnumObjects can raise a dialog rather than just returning an error code.

And why can't the view handle the error by displaying a message?

Why is there a drive icon to click on in the first place ?

I don't get Windows shows icons for *drives* if it's a removable drive (CD/floppy), and for *filesystems* if it's a fixed drive (harddisk). This doesn't seem very logical or consistent.

I prefer the way Apple does it, I insert a memory stick/CD/etc. it shows up on the desktop, I remove it, it's gone. If there is not disc/stick/memorycard/floppy in the drive there is simply no icon. So the whole problem goes away.

@Dean Harding:

[No object to enumerate != No media

They're two different conditions (no objects to enumerate is just an empty folder)]

No, an empty folder is an object itself.

@Aaaargh!:

That would be much cleaner, perhaps levering the already present GPO flags for hiding driveletters could be used?

Really, people, Microsoft's programmers have better things to do than "fix" this!

To fix something, it has to be broken in the first place.

"[QueryInterface works great if you have an IUnknown you can invoke it on. Too bad there isn't one. -Raymond]

Are you kidding me? IShellFolder::CreateViewObject  returns an interface to a new object with a requested GUID. EACH OF THOSE INTERFACES IS DERIVED FROM IUnknown. YOU CAN CALL QueryInterface on any of those.

You could add an interface to Explorer to allow an enumerator to set some error message on the explorer window.  All old interfaces will continue to behave the same.  Only the enumerators that are aware of the enhanced Explorer can set an error message before returning an error code from IShellFolder::EnumObjects.  The old enumerators will continue to just show a message box.

[Huh? That was not a special-case fix for a specific implementation. -Raymond]

I don't follow you; how is IShellView3::CreateViewWindow3 any different from (the hypothetical) IShellFolder3::EnumObjectsEx?  The situations look identical to me.

[And you pass that new interface to the enumerator how? -Raymond]

HRESULT EnumObjects(

   HWND hwndOwner,

   SHCONTF grfFlags,

   IEnumIDList **ppenumIDList

);

Can't the enumerator call some GetNewExplorerInterface(hwndOwner) to get it?  Checking first that hwndOwner isn't null of course.

"Only the enumerators that are aware of the enhanced Explorer can set an error message before returning an error code from IShellFolder::EnumObjects."

[And you pass that new interface to the enumerator how? -Raymond]

I don't know, Raymond, if Seattle weather makes you thick, or you're in "try to figure out how it CAN'T be done" mood, but here is the deal:

The _enumerator_ provides an interface for the folder view and tree view. A _view_ object queries the enumerator object for an extended interface. Extended interface function sets the enumerator instance to "no UI" mode (or privides EnumWithoutUI function). View object calls the enumerator, and if enumeration fails, no dialog shall be shown, but only an appropriate error code will be returned. I can't believe I have to explain it all to you.

[Poking into HWNDs to get interface pointers is not very COM-like. (What if the window belongs to another process?) -Raymond]

Reading more documentation, I just noticed the IShellFolder::BindToObject function.  Maybe Explorer can pass that interface in the IBindCtx *pbc parameter.  The IBindCtx::RegisterObjectParam function seems to be designed for things like this.

I don't think I understand the problem to well..

Surely Explorer could just _not_ create the pop up box and instead of that action put the message in the folder view area?

[CreateViewWindow3 added a dwViewFlags parameter which applies to all views; it's not a special-case flag just for file systems. -Raymond]

Ok.  Then replace IShellFolder3 with IShellFileSystemFolder.  Now instead of a special-case flag on a general-purpose interface you have a special-case interface.

Gee whiz people, just create a window that handles WM_PARENTNOTIFY[WM_CREATE] and pass it as the parent window. The handler can close the new window and signal the view that EnumObjects failed. Was that so hard?

*waits for this to show up on thedailywtf*

Explorer never calls IShellFolder::BindToObject?  Does it only call IShellFolder::CreateViewObject then IShellView::CreateViewWindow?  Then I guess you have to bypass COM entirely and create some "int SetExplorerError(HWND hWnd, LPCTSTR lpText);" function to be called from IShellFolder::EnumObjects.  The function would use some internal WM_EXPLORER_XXX message to send the error text to the window.

I think there's a pretty simple solution:

Add a new flag called SHCONTF_RETURN_ERROR_MESSAGE

If there's an error and the flag is set, have EnumObjects return an error HRESULT and use ::SetErrorInfo with an IErrorInfo implementation that contains the text message.

If the flag isn't set, revert to the old behavior.

APIs that pop up error message windows are kind of obnoxious.

[Well, that just punts the problem to the hsot application. How many special-case interfaces should Explorer need to know about? -Raymond]

As many as the Shell team adds.

[There is no enumerator. IShellFolder::EnumObjects displays an error message and returns NULL. Even if it returned an enumerator (say an empty enumerator), it's too late. You're setting the parameters to suppress an error message that has already been displayed. -Raymond]

IShellFolder * pShellFolder;

// assume we got pShellFolder

IEnumFolderSuperAdvanced * pEnumInterface = NULL; // hypothetical new interface

if (SUCCEEDED(pShellFolder->QueryInterface(__uuidof(pEnumInterface), (void**) & pEnumInterface)))

  {

     pEnumInterface->EnumObjectsNoUi(Whatever)

     pEnumInterface->Release();

  }

else

  {

  pShellFolder->EnumObjects(Whatever);

  }

I can't believe I have to write it down for you. And about hypothetical new interface: There were like 8 years of opportunity to add it.

Raymond,

We all understand why it was done this way back then, but PLEASE, don't BS us that it's not feasible, can't be done at all, bla bla bla.

'[The original point of the article wasn't that it can't be done. It's that it didn't fit in with the design of the view model. People seem to be saying, "Well the view model sucks. I should be allowed to create views on things that don't exist." -Raymond]'

This first sentence in this reply is exactly what I was trying to point out. It's possible now it just wasn't in the original design back then.

<<Recycle Bin and Control Panel follow the rule that "if the view object can be created, then you have a valid view." -Raymond>>

Obviously, both in the original poster and my suggestion, the view gets created successfully and is valid in the same sense that any special item view is valid. It's just that it contains a single item showing the error.

I don't know enough about the low-level implementation of CreateViewWindow to determine if doing this violate some part of its contract, but it would seem to me that it is allowed to create whatever view it want or need based on the content of the folder, even if the folder or its contents are virtual files.

"Not sure if people would actually like that."

It could probably go both ways. IE displays the error in a page rather than a dialog box, so people are at least somewhat used to it.

I think the real problem, though, is when that "insert a CD" dialog box pops up, you can insert a CD and it goes away automatically. I'm not sure how that would work if explorer navigated to some "error" view instead... would you expect it to automatically navigate to the "real" view when you insert a CD? Would there be a "refresh" or "try again" button on the error page to make it try again? etc

Yes, you could change the behaviour using a new interface, as described in the comments above, and let applications that want that behaviour use that new interface. But as an end-user I'm happy with the current situation: if there's no disk in the drive, I don't want a fake view, I want an error message. And as a developer, I am kind of glad that I don't have to code special logic for everything that could go wrong; keep it simple and reliable. So from my point of view this isn't a bug, and therefore there's nothing that needs fixing.

> [And how does IShellFolder::CreateShellView decide whether to do things the old way or the new way?

Obviously, the program could check if the new interface is offered, and if not, use the old interface.

> And what is the priority for fixing this problem, anyway? It's not like this is a data loss bug. -Raymond]

No, it's not like any customer is going to be surprised when Windows is acting all retarded once again.

Useful programs are written to be used. Not because it should be easy to develop them.

Raymond said: >>Okay, but that's adding a flag for one specific implementation to a general-purpose interface. Some people might call that poor engineering.<<

As opposed to current solution being what? Good engineering?!? [From an end-user perspective of course.]

>>I guess this also means that if you type a path to a nonexistent directory into the Address bar, instead of getting an error message popup, you should navigate to an empty folder with the message "The folder name is invalid." Not sure if people would actually like that.<<

The message "The folder name is invalid. Click here if you wanted to create it." would be cool.