#220 Start menu slow when away from home network

[Andy Goth]

My Classic Start Menu contains submenus showing directory contents. This is a very helpful feature, and I use it constantly. However, one of my submenus is for a network share. This works fine at home, but when I take my laptop on the road, this causes Classic Start Menu to hang for roughly thirty seconds every time I click on the Start button.

There are multiple sub-issues and design questions here.

One, how can Classic Start Menu know in advance that a menu item may take a long time to initialize? For now let's assume network shares are the only problem. Is there a way to detect whether a drive letter is not mapped to a local device? Maybe just require that network share menus be mapped via UNC paths, which are easy to identify as remote. Or maybe add a checkbox to the menu configuration so the user can declare an item as a potential hangup.

Two, what part of initialization is slow? Is it autodetecting the icon? Is it determining whether or not to draw a triangular submenu indicator? Is it actually trying to preload the submenu contents?

Three, how can the slow task be made nonblocking? This depends on the available APIs, of course. Given the typical mindset of Windows APIs, it's quite likely that a separate thread is needed.

Four, what should be done until the potentially slow initialization is complete? A "loading, please wait" icon could be displayed, I guess, with no submenu indicator until ready. After a timeout, the icon could change to some kind of failure indicator.

An alternate approach could be to hide or gray out the menu item if Classic Start Menu somehow knows ahead of time that it will take a long time to initialize. This is problematic too, though... merely detecting connectivity is another common source of blocking!

[Ivo Beltchev]

The start menu is supposed to be immediate. It is not like and Explorer window that stays open indefinitely and can refresh parts of it asynchronously.

There are multiple parts that contribute to the slowdown. The menu needs to know immediately if an item is a folder or a file (so it should show the arrow or not). The menu needs to know immediately the location of the icon. I am planning to change that in the future to happen in the background. And of couse when you click on the item the menu needs to enumerate all of the folder's contents and their icons (at least the location of the icons)

I don't see how marking an item as "potentially slow" can solve anything. I can either ignore it always or show it always. If "potentially slow" items are to be ignored, well, just don't put them in the start menu to begin with :)

How is the network location added to the start menu? A mapped drive, a network path, junction of some sort?

[Ivo Beltchev]

There is this API: http://msdn.microsoft.com/en-us/library/windows/desktop/bb776475(v=vs.85).aspx
If you have a way, try it and see if it works in your case. Basically if it returns the correct state of your connection and if it returns it quickly.

[Andy Goth]

The icon can be specified in advance. An option could be added to forcibly declare something to be a directory so as to avoid the potentially expensive lookup. And I'm okay with the menu blocking if I actually go ahead and click the menu item, though somewhere down the road I'd like to see some kind of cancelable "loading, please wait" throbber.

The "potentially slow" option avoids the need to stick everything in background threads, if that's what it is required to avoid blocking, so that most stuff can continue to follow the existing synchronous code path. The option might instead be labeled, "load in background."

The network location is done via a menu item having a Link value set to a UNC path. I specified the icon directly so that Classic Start Menu doesn't have to guess. None of the checkbox options are selected.

[Ivo Beltchev]

OK, then the icon loading is not the problem. Basically in your case the only thing I'm calling is IShellFolder::ParseDisplayName to get the name and the SFGAO_FOLDER, SFGAO_STREAM and SFGAO_LINK flags. It is all required information to create the menu item.

[Andy Goth]

The flags can be asserted in advance with a "network folder" checkbox option, avoiding the need to call ParseDisplayName() when creating the toplevel menu. As for name... I assume by "name" you mean the PIDL, which is needed in order to enumerate the directory contents to create the submenu. This can wait until the first time the submenu is actually requested by clicking on it.

The goal of a "network folder" (or "deferred network folder" or "slow network folder") option would be to not call ParseDisplayName() when the Start menu is opened, instead putting it off until the child menu is clicked. This isn't quite as nice as a "load menu in background" option (or overall archictecture change), but it would give me what I need with minimal fuss. I'd still have to wait it out if I actually made the mistake of clicking on the menu while the network was unavailable, but that's preferable to waiting every time I bring up the Start menu.

For now I just have to remove the item from the menu when I'm not at home.

[Ivo Beltchev]

If you are able to, please try PathIsSlow in your environment. If it returns the correct result quickly because the system knows more about the current network status, then it would be the ideal solution.

[Andy Goth]

I'm sorry, I don't have a development environment set up on my Windows laptop. My at-home programming is generally restricted to Linux and scripting languages.

Here's the test case:

1. Add a Custom Command to your Classic Start Menu.
2. Set its Link to some UNC path (I use \toaster\andy).
3. Set an icon.
4. Confirm the submenu expands.
5. Pull the network cable.
6. Try to bring up the Classic Start Menu.
7. Note the long delay.

Can I test PastIsSlow() using MinGW, or do I need the Microsoft development tools? I don't have MinGW on this laptop, but it's on a Windows XP laptop I have.

[Ivo Beltchev]

My tests show that PathIsSlow return TRUE for a network path that doesn't really exit. And it takes 5 seconds to do so. ParseDisplayName takes 15 seconds just to get the PIDL.

The only possible solution is for paths that start with \ to not get a PIDL and if the path has an extension to treat it as a path and otherwise as a folder. The downside is that the flags may not be correct (what if I have a folder with an extension?) and any customizations to the display name or the icon done through desktop.ini will be lost.

However the current architecture requires the PIDL to be always available. It would require some serious redesign to delay the PIDL.