Opus cannot retrieve icon from filepath containing a GlobalVariable

Opus does find the file to retrieve an icon from,
when the path contains an alias,
e.g. /localappdata\gitkraken\app-7.2.0\gitkraken.exe

but when part of the path is supplied using a global variable,
then it does find the file to execute it
but can't find it to retrieve the icon from
e.g. {$glob:Utilities_DriveLetterColonSlash}_cfgPortable\devt\vbal\Adersoft\Vbsedit\x64\vbsedit.exe

Could this please be remedied ?

Is there a reason you're using variables for instead of aliases? You can set aliases via commands/scripts, if that's the reason.

Hi Leo,
the reason is that I find it easier to use the ManageDopusVariables script you've kindly provided here, to manage that sort of config.

I regularly use Opus from a USB-stick,
and at client sites, I can't always change its drive letter to something consistent.

While here, kindly let me make an observation.

What you've offered is a workaround, and that's fine, and thank you.

However, it seems from this and other occurrences, that when GP adds
a feature, GP doesn't go through and systematically analyse all the places
it might be used, and ensure (i.e. test) the correct operation of the feature.

Now I'd like to see Opus gain the market traction it deserves,
as it is out of sight extraordinarily capable and ahead of its competitors.

Part of fulfilling that value proposition, would be, being systematic in the
design, impact-analysis and testing, of features like these.

E.g. Opus has global variables, and other types
....... the help file
............. Reference > Scripting Reference > Scripting Objects > Vars
....... section mentions :
.................. global, lister, tab, script, dialog & command variables
........ but the ManageDopusVariables does not make it clear which one of those
........ it manages (i.e. global), one has to read examples to gain that clarity.

Also, in terms of variable use,
and in particular making Opus on USB easily configured to re-use local configuration,
I think that a manual section listing use of different techniques
to flexibly reference especially programs , cf :
... aliases ..... e.g. ... /localappdata\gitkraken\app-3.6.6\gitkraken.exe
... vars ......... e.g. ... {$glob:Utilities_DriveLetterColonSlash}_cfgPortable\Program Files (x86)\FSCapture_vCurrent\FSCapture.exe
... appath .... e.g. ... {apppath|winword.exe}winword.exe /n
would be extraordinarily useful.

As another example, some years ago, I suggested that collections would benefit from being able to be displayed in flat view.

The response I got was "why would anyone want to do that".

I appreciate that Opus is thus far relatively small,
but it would be nice if GP were to keep track of a future feature map
that leverages its unique capabilities, in the form of

  • OK , flat view, in the file system
    ... so where else do we find files but not in the file system
    1. Obvious, FTP / SFTP
    2. Ahhh, add value unique to Opus - in Collections

GP did this for file descriptions, using the descript.ion system for non-NTFS
file systems.

In this way, value opportunities for both GP and customers might be
identified, and put on a product roadmap, that customers could then vote on
as to how much value that would create for them.

Side note 1 :
... Collections are absolutely fabulous , as they allow anyone to create their own
... grouping of files by relevance, subject, tag, etc

  • flat view would enhance the value of that
  • the tag system at the moment seems a bit clunky
    • a really good one would be of enormous benefit
      • especially if filtering could be introduced on those, like
        Excel Autofilter, i.e. another header/selection row above the file grid

Side note 2 :
... GP does does not yet seem to appreciate that Opus' main value proposition can
... actually be, as a workflow organizer
... - in that space, many new features could be added, including
... - creating information sets (listers, formats, collections)
...... that could be shared, delegated, exported / imported, monitored,
...... especially with
......... - common collections & views
......... - synthetic columns , e.g.
........... - team lead, assigned to, estimated completed, actual completed,
............. history of these fields

.... I've spent over a decade now tailoring Opus to support workflow.
.... I'd be happy to have a chat in this space.

Opus could in fact become a tool that others can put their own 
packages / capabilities into,
   like Atlassian, Slack, etc
       e.g. Altap Salamander file manager does this by creation of an interface engine
              Excel / Office are highly configurable via COM component object model
              Opus already publishes its object model
                ... although it doesn't surface it in the editor, mnnn, pity, feature request ?

Opus can be integrated with many other tools to open files with.
Why not expand its scope to assist with workflow management, possibly even by allowing querying of the file data and metadata to collate up into dashboard views into an internal or external progress / dashboarding facility, and workflow assignment and monitoring via shared or import/export-able collections ?
1 Like

Wow, you guy are a genuine Directory Opus lover! :+1:

1 Like

This script: Global Variable Management Dialog ? (That's by another user, not from us, FWIW.)

That's a UI for editing variables. Not much different to the UI for editing aliases.

In fact, at the bottom of that thread I suggested you use aliases instead of variables for what you are doing: :slight_smile:

There is a built-in /homeroot alias which will get you the root (drive letter) of the drive which dopus.exe is on. You don't need to create any aliases (or variables) if that is all you need.

You can also use the User Data folder within your Opus config directory. If you put your icons into there and reference them via /dopusdata/User Data then they will always be available via that alias, whether on a SSD/HDD or USB install, and they will also be included in config backups as a bonus.

Aliases can be used almost everywhere.

Variables are a lot more specialised and esoteric. There is no reason to be using variables for what you're doing.

We didn't write ManageDopusVariables. It's nothing to do with us. :slight_smile:

The /home, /homeroot and /dopusdata aliases all take care of that. Everything you need should be handled by built-in aliases.

I'm not sure what relevance that has to this discussion? But Collections are already a flat view of things from multiple folders so the idea needs some explanation if you want us to implement it. If you want to advocate for that, please start a separate thread.

I am not sure what this means, sorry.

The descript.ion system dates back to the MS-DOS days, and predates NTFS description support in Opus. We didn't invent it. (Not sure how this is relevant to getting icon paths either.)

I once created a dialog similar to the Global Variable Management for managing aliases.
Surprisingly I called it folder aliases management :).

I quickly abandoned it when I realised Dopus already had such a UI that was arguably better.

If all that is holding you back from using aliases as @Leo suggested, perhaps this might help?

@leo, whats with all the us and them language :wink: . /s

@brianm if you have a suggestion for ManageDopusVariables, feel free to make it back in the main thread, I can try take a look.