Currently, I am trying to improve my script code for toolbar buttons and file type context menus. For instance, I'd like to get rid of hardcoded file and folder paths and replace them with aliases or app paths (as listed in the App Paths key in the registry) so my Directory Opus configuration can be backed up and restored more reliably in the future (or in a different system) as long as I have installed the same applications.
I have noticed that aliases also work on icon paths for the toolbar buttons, as I can use them in the Select Icon dialog box. They can also be used on file type — or file type group— context menu icon paths, but the problem here is that they are not stored that way. Directory Opus reverts the path string to the literal file path in this particular case whenever I come back to check it. This doesn't happen with icon paths for toolbar buttons.
Example: /programfiles\Sigil\Sigil.exe is kept as the icon path for my Edit ePub toolbar button, but it is saved as C:\Program Files\Sigil\Sigil.exe in my Edit context menu icon path for .epub files, even though I saved the very same path as before.
If it's one that also shows up in File Explorer and other apps, not just Opus, then Opus aliases can't be used for the icon paths as they would not work anywhere else.
No, I'm not referring to the ones that are also shown in Windows File Explorer (because they are entries in the file association keys in the Registry), but context menus that I've created specifically for Directory Opus.
The weird thing is that I can use something like {apppath|ebook-edit.exe}ebook-edit.exe for the icon path and it sticks, but it's the other way around whenever I use aliases instead.
I’ve inspected the XML code in .oxr files stored in /dopusdata\FileTypes and I’ve found that actually every icon path is stored using aliases, even the ones I didn’t explicitly save that way.
It seems that Directory Opus just expands these icon paths containing aliases in the Select image from a file text field displayed within the Select Icon dialog box. The fact that this behavior differs from that shown in the same dialog box for toolbar buttons confused me.
Ultimately, this is more useful for my purposes, since configuration backups will not have hardcoded icon paths.
) bug?