Temporary labels / colours etc?

Hi all,

Is there any way to assign statuses/labels temporarily? I.e. if the lister closes, forget any 'temporarily-set' values?

I'm adding some checksum-checking stuff, and I'd like to have a 'validate checksums' button that will take a list of checksums, e.g. checksums.md5, and validate all the files listed in the file, and show the results with a colour or status that shows if the file is valid or not. But only while the I'm looking at those results.

Showing all the results can be done easily by putting all the files in a collection, but I'm stuck on the 'temporarily highlighting issues' part.

Thanks!
T

I guess a script column could be a good fit here.

I agree, but I'm not quite sure how I'd do that efficiently.

For example, I'd have to look up each file in the checksums.md5 file (or might be a different file, the user has to choose which list he wants to use). The file itself may contain 1000+ files, so I'd be concerned about speed here.

You can use a global variable to cache the checksums.md5 file to avoid re-parsing it for every file/folder the script is asked about.

As in a normal variable within the script (not an Opus "Var" object) which is at the top of the script and not inside any functions.

When Opus needs to populate some columns, it will create the script, which runs the global section once, then it will call the function to get the column data once for each file, always on the same instance of the script, so the global data will still exist. A short time after it is finished asking the script for columns, it will destroy the script which will also destroy the global data.

So you can use global variables as a cache that is created and destroyed for you.

For example:

Have a global variable containing Map. That Map would be from Paths (or maybe just normal strings) to another Map. The second Map would be from filenames/strings to MD5s/strings.

When the script is asked to make data for a column, it checks in the global variable to see if it has already loaded checksums.md5 for the appropriate path. If it's already in the map, you can use the data without having to load it; otherwise, it has to be loaded and is then put into the map for the next time the column is requested. Later on it will be destroyed automatically.

You could also insert an empty entry into the map for paths which don't have a checksums.md5 atg all, to avoid trying to load it over and over again in folders that don't have one. i.e. Cache the fact the lookup failed; or effectively treat it as a success that loaded an empty file.

One complication is that the checksums.md5 file may point to files in child folders, so your script will also need to look in parent folders if you want to support that. You could either have the caching code handle that in some way, or not bother and potentially have the same checksums.md5 cached more than once for different paths.

Keeping it simple may actually make sense, since the cache will often be destroyed before you change folders anyway, so there's often no benefit to one folder keeping around data that another folder may use, but things like Find Results and Flat View, where you might be refreshing a column for lots of different folders at once, may benefit there. I would keep it simple at first, at least.

If you are aiming to use this as a label, not just a column that you turn on and off, then you might also want to have an Opus Var (probably with Tab scope) which toggles all of this one and off. You could toggle the Var with a toolbar button or hotkey, and if the script was asked for a column when the Var was "off" then it would not do anything at all. That way you can choose when all this extra processing happens. The button that toggles the Var would probably have to refresh the lister as well.

I'm not sure how all of this would interact with the folder tree, but I guess the whole script will probably ignore folders anyway. (If you wanted to have a label that says everything inside a folder matches the checksum, that would complicate things as far as the tree is concerned, since it's harder to control when it refreshes and it shows thousands of folders at once.)

Leo - that's exactly it, thanks for the lengthy discussion. Very much appreciated.

Caching via a global variable in the script is perfect for now. I'm already handling files in subfolders (at the moment it just looks at each parent folder until it finds a checksums.md5).

I'd also like to add some kind of indicator against the checksums.md5 file itself regarding the files it's keeping track of, but that can come later.

Added the caching - works really well. Thanks for the suggestions!