MRU

[czerny]

I have to implement a most recently used files list.

But I don't want to reinvent the wheel!

I know that some MRUs are saved in the registry, others are saved as .lnk-files in a certain folder, under Windows 7 it is:
%APPDATA%\Microsoft\Windows\Recent, and I could of course use a own solution.

What do you think? What are the pros and cons using the one or the other way? Is there a api I can use? I have only found something working with MFC. :-(

[jj2007]

Simple text file in the same folder as the executable. By far the most flexible solution.
For example, this is my editors recentfiles.ini (it's actually 26 lines long...):

Code: [Select]

?:\Masm32\MasmBasic\AscUser\WhileLoopSmallBasic.asc
?:\Masm32\JTools\Ps2Pdf.asc
?:\Masm32\Gfa2Masm\testjj\RichMasm.asc
?:\masm32\MasmBasic\MbHistory.ascIt puts a question mark if the file is on the same drive as the exe. Thus, when working on two machines (e.g. home/office), I zip the recentfiles.ini together with recent documents, and even if machine B has a different document drive, the editor finds the docs.

[Bitbeisser]

I have to implement a most recently used files list.

But I don't want to reinvent the wheel!

I know that some MRUs are saved in the registry, others are saved as .lnk-files in a certain folder, under Windows 7 it is:
%APPDATA%\Microsoft\Windows\Recent, and I could of course use a own solution.

Well, that depends on what exactly your intention and need is.

The "recent" folder makes those files accessible through the start menu's "Recent items"list and this feature makes only sense when you are linking to files that have a distinct file extension that has a specific file association.

If they are application specific, then the "recent" folder would be IMHO a bad place and what you are doing is up to your preferences.
You can do your own .txt file like jj2007 suggested or use the registry. I some cases where I included such a feature, I used an .INI file, as for this exist standardized APIs to read and write, with some of them having the option to toggle a property and have them going by choice either to registry or .ini file...

Ralf

[jj2007]

You can do your own .txt file like jj2007 suggested or use the registry.

One good reason to not use the registry is that you cannot carry your registry on a USB stick with you (or at least, not so easily). When going to another machine, I update the files in a "recently used docs" archive that contains also the recentfiles.ini; on the other machine, I unzip all files and can continue working as if I was on the main machine. It's a feature that has saved me a lot of trouble over time.

[czerny]

You can do your own .txt file like jj2007 suggested or use the registry.

One good reason to not use the registry is that you cannot carry your registry on a USB stick with you ...

Yes, that is a very strong argument to me too.

But what about an api to manage MRUs? Does there anything exist or not? If not, I have to roll my own and will use something based of good old ini files.

[frankie]

You can keep Registry config by simply saving them in a reg file and restoring it. But if your program is intended to be carried on a removable media (installationless) using registry is not the correct solution.
Using registry you can detect first installation or similiar things looking at you entries, you can create them if not exist, etc...
The real side effect is that the key you creates will remain there forever bloating registries unless you happlication have an efficient remove and the user use it to remove application.
When used in installationless programs you will leave rubbish around ...
In this my old post (looking in the code) you'll is an example on how to set, read and create registry entries.

[jj2007]

But what about an api to manage MRUs?

CreateMRUListW

But: I gave up and am just writing my own parser ;-)

[czerny]

CreateMRUListW

Thanks! That was a good starting point for a registry version.

[jj2007]

Thanks! That was a good starting point for a registry version.

And here is pseudo code for checking the logic, as a starting point for the ini version (exe attached, source is in RTF format).

include \masm32\MasmBasic\MasmBasic.inc      ; download
  ct equ ecx
  curfile equ esi
  Init
  Dim rf$()                                  ; create recent files array
  .While 1
      .if Exist("MyMRU.ini")
            Recall "MyMRU.ini", rf$()
      .endif
      Clr ct
      .While 1
            .Break .if !Len(rf$(ct))
            Print Str$("\n#%i\t", ct), rf$(ct)
            inc ct
      .Endw
      ; for testing: get current file from the console
      Let curfile=Input$("\n\nType a filename and hit Enter (Esc to quit): ", rf$(0))
      .Break .if !Len(curfile)
      Clr ct
      .Repeat
            .if !StringsDiffer(curfile, rf$(ct), 1)  ; 1 = case-insensitive comparison (for Windows)
                Delete rf$(ct)                       ; if current file was already there, remove it
            .endif
            inc ct
      .Until ct>=rf$(?)                              ; index ? means #elements in array
      Insert rf$(0)
      Let rf$(0)=curfile
      Store "MyMRU.ini", rf$(), Min(3, rf$(?))       ; write max 3 strings to file
      Print CrLf$, String$(50, "-"), CrLf$
  .Endw
  Exit
end start

[Bitbeisser]

You can do your own .txt file like jj2007 suggested or use the registry.

One good reason to not use the registry is that you cannot carry your registry on a USB stick with you (or at least, not so easily). When going to another machine, I update the files in a "recently used docs" archive that contains also the recentfiles.ini; on the other machine, I unzip all files and can continue working as if I was on the main machine. It's a feature that has saved me a lot of trouble over time.

Just in case you missed it:

Well, that depends on what exactly your intention and need is.

Ralf 

[TimoVJL]

As we need something to play with, here is lousy example of MRU with ini-file.

EDIT: avoid duplicates.

[czerny]

As we need something to play with, here is lousy example of MRU with ini-file.

I am not yet ready with my module. But I have some design differences.

If a file is selected multiple times, it is saved only once.
I have a own data structure to hold the mru. So it is not necessary to have a menu entry to store the list, though a menu entry can be build.
I save two strings per list entry. One is the menu entry, the other is the data (file with path for example).

[TimoVJL]

I have a own data structure to hold the mru. So it is not necessary to have a menu entry to store the list, though a menu entry can be build.
I save two strings per list entry. One is the menu entry, the other is the data (file with path for example).

That is good way to do that.
My idea was just making something very simple just with menu.

[jj2007]

But I have some design differences.
...
I save two strings per list entry. One is the menu entry, the other is the data (file with path for example).

I use the full file path, with a question mark if the drive is the same as the executable's drive:
?:\Masm32\MasmBasic\BugTests\DotOneC.asc      <<< on drive J:, like the executable
C:\Masm32\MasmBasic\AscUser\SimpleMRU.asc     <<< this one on drive C:
?:\Masm32\MasmBasic\BugTests\DotOneB.asc      <<< on drive J:, like the executable

This makes sure that when you move to the other machine where all your docs are on J: instead of D:, you can still see your files.

The ini text file is loaded into an array (see Recall above), and its elements are directly used to open files. For the menu display, however, only the last folder and the file name are being displayed. For example, your project's ini file would be displayed as
WSDIMenu4\WSDIMenu4.ini
Over time, this has proven to be a very reliable feature. For PellesC project, you might include the last two folders, if you often open files in subfolders and debug\foo.x is not descriptive enough.