Re: RecentManager and win32

[Emmanuele Bassi <ebassi gmail com>]

Hi Tor,

On 9/26/05, Tor Lillqvist <tml iki fi> wrote:

Emmanuele Bassi writes:
> Win32[1] has its own Most Recently Used list. It is stored inside the
> registry, in a per-application sub-tree; that is: each application
> directory has its own MRU list.

The docs for SHAddToRecentDocs() doesn't mention that? Or is there
some other API to maintain this per-app MRU list?

Searching on the MSDN[1], I found that, starting from win2k (so, I suppose that windows xp has this system too), there is a MRUINFO[2] structure, initialized by CreateMRUListW() and freed by FreeMRUList(); the first function should create the correct keys under HKEY_CURRENT_USER/HKEY_LOCAL_MACHINE (I believe for system-wide MRU list) or a custom registry handle.
 
Items in the list are accessed positionally using EnumMRUListW(), which roughly maps the RecentManager::lookup_item method.

Oh, and by the way: no more than 24 items are stored inside the list.

Reading between the lines (see [1]), I believe that this approach is not used to store files, but strings; applications use this approach to create a per-application "most recently used $something", be this $something a path, an object id, a string used for auto-completion, etc.

Anyway, all these functions aren't exported by default, and - as stated in MSDN - are in comctl32.dll, accessed using their "ordinal", whatever this means in the win32 world.

So, it seems that the common way of storing a MRU item inside the global "My Recent Documents" list is to use ShAddToRecentDocs(), and everything else is wrapped by high level classes, like on OS X.

Have you BTW found any API to query what SHAddToRecentDocs() stores?
Or should one just call SHGetSpecialFolderPath(CSIDL_RECENT) and then
scan that folder?

Apart from the low-level EnumMRUListW, which handles a per-application MRU list, I think the common approach is what you outline: scan the folder for its content.

I think the rationale behind it is that applications are supposed to create their MRU and, also, add every item inside the global MRU list itself; the Recent Documents contents should only be accessed using the widget the shell itself expose to the user.
 
The MFC offers a wrapper class, called CRecentFileList[5], which is similar to the RecentManager class (uhm, I should probably add a "size" property, now that I think of it).

> 2. plus, protected by arch-dependent #ifdefs, when we register every new
> item inside *ours* recently used resources list, we also register it
> inside windows' MRU list, using the win32 shell API.

Although not documented, googling indicates that SHAddToRecentDocs()
only adds files that have an extension that is registered.

It lets you add everything you want, but the shell does some basic filtering when displaying it (e.g. you could add an executable to the Recent Documents list, but it won't show inside the Start Menu item).

So if you
use some GTK+ application to save some document with a random foo.bar
name, this won't get saved in the Recent Documents list. Oh well, this
is understandable, since Windows would have no way of knowing what to
open the foo.bar with.

Exactely.

This brings up the idea, if the RecentManager API is given meta-data
that tells what app should be used to open a document that is being
saved in the MRU list, and that document has an extension that is not
registered, should it then go ahead and register that extension
automatically associating it with the given application? Probably not,
that might be a bit too automatic.

I think so myself. If an application does not register its own supported MIME types/extensions, then it should be considered broken; and if a user selects an invalid extension on win32, then he knows (or he should know) what is he doing.

(But should there be a
platform-independent API to wrap this kind of functionality, querying
registered types (extensions) and registering new ones? Or is there
already?)

Installers should offer a standard way to register MIME types/extensions; at least, many install SDK do.

Regards,
 Emmanuele.

+++

[1] Which means that what I found is buried under the truckload of salt with which anyone should take what I write.
[2] 
http://msdn.microsoft.com/library/default.asp?url="">
[3]
http://msdn.microsoft.com/library/default.asp?url=""
[4] http://msdn.microsoft.com/library/default.asp?url=""
[5] http://msdn.microsoft.com/library/default.asp?url=""

-- 
It is against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
                -- Alan Perlis