Custom button to mimic favourites button

I have an MS Access db that I use to manage all my work projects and contacts. One feature of this app is an option to flag a project as a favorite which then creates a shortcut (.lnk) file in a folder location I have specially set up which gives me a quick list of all my favorite projects. I then put a link to this folder in the windows favorite and its available in all the standard file open dialog boxes.

I'd therefore like to put a custom button on my DO toolbar which give me a dropdown list of all my favorite projects like the favorites button.

Any suggestions how to do this?

Thanks

Grant

A command like this will give you a menu replicating the Favorites folder from your Windows profile (change the path if you have the shortcuts stored in another folder):

Go PATH /favorites FOLDERCONTENT=nomenusel

More detail about a similar button can be found here: Start Menu button.

Hi @Leo,

Go PATH /favorites FOLDERCONTENT with .lnk files in /favorites works for me, however, as soon as I add move to FOLDERCONTENT (e.g. FOLDERCONTENT=move), then the .lnk files are not shown (and not resolved) anymore. Why is that?

In the next update we've added the resolvedirlinks keyword which will cause folder shortcuts to be resolved and treated exactly the same as real folders.

Great, thanks @Jon. :+1:

Please note that there is already a noparselinks keyword for FOLDERCONTENT.
In the docs Go [Directory Opus Manual] it says it

Prevents shortcuts from being resolved. Without this, a shortcut to a folder will be expandable just like a normal sub-folder.

Current behavior: without noparselinks set, .lnk files to folders are already resolved and that works. It just stops working when move is added to FOLDERCONTENT.

Thus, a separate resolvedirlinks keyword might not be needed here? (Also note the different wording resolve vs. parse in new vs. old keyword.)

@Jon, just a quick reminder that changed might be a good idea here to avoid ambiguous naming/keywords; before releasing it to a stable version. :slight_smile:

The two options are slightly different; resolvedirlinks specifically relates to links to folders, and the resolving is done earlier so they're actually treated as folders all along, meaning any filters the command uses will be compared against the link target rather than the link itself.

The noparselinks option relates to links to both files and folders and is done later, and any filters will be compared against the link itself.

We'll try to make this clear in the manual when it's updated :slight_smile: