Support Recent and Frequent lists

[GoogleCodeExporter]

http://www.codeproject.com/KB/vista/SevenGoodiesJumpLists.aspx?msg=3200754
http://windowsteamblog.com/windows/b/developers/archive/2009/06/25/developing-fo
r-the-windows-7-taskbar-jump-into-jump-lists-part-2.aspx

This will actually be easier than I thought.

http://dl.dropbox.com/u/6173284/AppIdRegistration.png

1. Get all of a program's associated filetypes (or the ones most impt for jump 
list?)

2. For each file type, add to ".ext/OpenWithProgids" the appId

3. Make a new appId key under HKCU.

4. Under the appId key, set the following:
** AppUserModelId - appId
** CurVer - appId
** (omit) DefaultIcon - Same icon as original filetype
** (omit) FriendlyTypeName - Same string as original filetype

5. (omit) Make a key appId/shell/Open/Command . Under (Default), set the 
command line to use when opening the file via jump list.

EFFECTS
------------

When opening or saving a file in a program window with the appId, then the MRU 
ONLY for that appId is updated! Unfortunately, the original MRU is not updated. 

If a file is open with the original settings (which won't happen, because files 
are now open with the new appId from explorer), then only the original MRU is 
updated.

IN SHORT:
1. If a jump list is newly created, it WON'T inherit existing recent list
2. If a file is opened with the new appId (from Explorer or appId-treated 
window, it's always opened with new appId), then the new MRU is updated 
independently of the old MRU
3. If a file is opened with old/no appId (from non-appId-treated window, which 
only happens when T7EBackground is shut down), then the old MRU is updated
4. If a jump list becomes deleted, the old MRU, mostly UNUPDATED from all this 
time, will take into effect.

Ideally, the two MRUs would be synchronized ... somehow. Either by reading the 
old MRU upon program add and then populating the new MRU, or by setting a 
filewatcher on %appdata%\Microsoft\Windows\Recent and watching for changes on 
relevant files. The first is better, the second produces most ideal behavior 
but is very bug-prone.

Original issue reported on code.google.com by mar.mar...@gmail.com on 27 Mar 2011 at 1:08

[GoogleCodeExporter]

Also look at 
http://stackoverflow.com/questions/4711676/can-i-set-the-appusermodelid-of-an-ar
bitrary-process-launched-through-a-jumplist

SHAddToRecentDocs
PKEY_AppUserModel_ID property on LNK file?

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 1:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

http://stackoverflow.com/questions/2945320/where-is-win7s-jump-list-system-data-
stored

%appdata%\Microsoft\Windows\Recent\AutomaticDestinations; 
automaticDestinations-ms files; are where the jump list MRUs are stored (but 
not the custom categories (UNLESS they're pinned) or the "tasks" category). 
Behaviors:

1. If you rename one MRU to another MRU, this successfully replaces the second 
jump list MRU
2. If you delete an MRU, this deletes the jump list MRU
3. No word on how the filenames are tied to the apps, but the "File Modify" 
times are pretty accurate to the modifications you're making.

SO, I figure I can,
0. Do the registry values first
1. Upon appId registration, make a copy of the old MRU and replace the new MRU
2. (?) Synchronize the two MRUs using a FileWatcher (is this too 
processor-intensive to be worth it? The ONLY place you see the old MRU is in 
the auto-generated Recent Programs list in the start menu. Also, on any window 
that is not treated by T7EBackground.)
3. When de-registering an appId, copy the new MRU back to the old MRU.

Boom: Proper MRUs! Now if only I knew where the rest of the jump list data was 
stored...

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 1:49

[GoogleCodeExporter]

30d5fb48289cb32c -- Taskbar
5d299991e2e67e6 -- Notepad-jLE
9b9cdc69c1c24e2b -- Regular Notepad   <-- this one is constant

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 2:06

[GoogleCodeExporter]

Possible solution:

1. User selects either a "Recent" or "Frequent" list
2. Button becomes visible, saying "Select Original Jump List"
3. Dialog similar to "Select Program Window" pops up. Asks user to,
   a. Open the program, if it's not already running
   b. Pin an associated file to the jump list ("You can unpin the file afterward.")

4. Detect change in AutomaticDestinations folder. 80-99% of the time, the most 
recently modified file is the original jump list. Store the filename in 
AppSettings.xml.

Thankfully, this process is optional. If it's not done, then the 
Recent/Frequent lists won't be copied back-and-forth between the JLE and 
non-JLE shortcuts, which is totally fine.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 2:13

[GoogleCodeExporter]

As far as detecting the NEW jump list is concerned, I can't think of a way to 
do this automatically. The most obvious solution is to just look for a "new 
file," but it won't actually be made until something is pinned to the jump 
list. Therefore, any intervening process can get in the way.

Maybe if I called SHAddToRecentDocs while JLE was masquerading as the new 
appId, then a new AutomaticDestinations file will be made! It's brilliant!

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 2:17

[GoogleCodeExporter]

Finally, the most obvious point: Set newList.KnownCategoryDisplay (or whatever) 
to Recent, Frequent, or None. And then newList.KnownCategoryOrdinalPosition = 
0-99, where a greater number means further down a list.

E.g. ordinal position 2 means it's the third category after custom categories

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 2:22

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 11:38

• Added labels: Milestone-Release0.5

[GoogleCodeExporter]

C:\Users\MarcoZ\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations

AutomaticDestinations is where MRUs are stored; CustomDestinations is where 
custom data is stored.

Original comment by mar.mar...@gmail.com on 27 Mar 2011 at 12:00

[GoogleCodeExporter]

Original comment by mar.mar...@gmail.com on 31 Mar 2011 at 9:06

• Added labels: Milestone-Release0.7
• Removed labels: Milestone-Release0.5