I have a folder full of reference documents. New versions are released from time to time so I might have...
Quick QA v1.doc
Quick QA v2.doc
Quick QA v3.doc
I want to define a button that always opens the most recent version. My attempt at this follows.
@nofilenamequoting
// Specify the base name of the document(s)
@set doc=Quick QA*.doc
// Specify the folder where various versions of the document are
@set dir={alias|mydocuments}\Test Folder\
// Open the folder in a new lister
Go "{$dir}" NEW
// Isolate the relevant document(s)
Select "{$doc}" DESELECTNOMATCH
// Hide all other files
Select NOPATTERN HIDEUNSEL
// Make sure the newest version is first in the remaining list
Set SORTBY=modified
Set SORTREVERSE=on
// Select it
Select FIRST
// Unhide the files that were hidden earlier
Select NOPATTERN SHOWHIDDEN
// Execute the selected document (i.e. fire up MS Word)
{filepath$}
After the Go {$dir} NEW statement, subsequent Opus commands continue to operate on the original folder in the original lister, so my button does not work as intended unless my starting point happens to be the original folder. Is there a way around this?
I think you'd be better off doing that in VBScript. Anything that changes directories, uses the select command, then tries to do things with the results is not going to be reliable. Those things are designed for interactive use, not scripting which is better handled by stuff like VBScript.
(Using a source control / version management / asset management tool to save the different versions may be worth looking into as well. They will handle things even better and let you always use the same name for the latest file while tracking history of older versions and information on what changed behind the scenes. They are well worth setting up if you are working with multiple versions of files, and definitely not just for source code.)
Thanks Leo. I understand the problem. In an attempt to solve it by other means I dusted off my DOS batch skills and have managed to get tantalisingly close to the finish line. I'm hoping that one of the clever people on this forum can help me over the final hurdle. Here is what I have done.
[ol][li]Created an internal Opus command that takes two parameters - (1) folder, (2) filespec[/li][li]Created a test button that calls the internal command[/li][li]Executed the test button leaving the DOS window open to see what went on[/li][/ol]
The internal Opus command correctly establishes the most recent version of a supplied filespec. As you can see from the following screen grabs it uses an environment variable %doc% to save the result, display with an echo command, and attempt to execute (by association). The echo command displays the correct fully qualified path/filename but attempting to execute from within the internal Opus command fails with an error as shown. However, if I then manually execute the filespec (by association) from within the DOS command window it works perfectly. I am stumped!
I'll attach the internal Opus command and the test button code in case anyone wants to have a hack. My test folder is - c:\test folder - and my test documents are based on a wildcard stem - risk assessment checklist*.doc - but either or both of these can easily be changed in the test button.
It's probably something to do with needing extra % characters in the for-loop or batches it's being run via a .bat file (that Opus auto generates to run MS-DOS batch commands). I am not certain, though. What you have there looks okay to me on the face of it, but DOS Batch stuff is never as simple as it looks.
The main thing I have learned about trying to do anything complex using DOS Batch over the years is not to use it. I spend hours trying to fix some siple DOS Batch quirk and then give up and do the same thing in 5 minutes using VBScript. VBScript isn't perfect but it makes life a lot easier.
It's been my experience that when using batch files in Opus, which I do quite often, I get the best results by making the batch file a standalone script where I'll use Opus to send the parameters to that batch file. Then the batch file just does its thing without Opus being involved unless I need to select the final output of the batch file.
But what I'm really wondering is why make a script of any kind to do this? I have a few styles configured that go to a specific folder, filter it, and sort the resulting files in reverse order based on the last modified attribute. That puts the latest file at the top of the lister so all I have to do is to double click on that file and it opens in the associated program. It's a simple approach that works for all file types.
Thanks for your comments and suggestions. From further testing it seems to me that there is an anomaly in the way Opus interprets a stand-alone variable, such as %doc% or "%doc%" in an internal MS DOS command. To make this as simple as possible, I created a 3 line BAT file that opens a TXT file, by association, with Notepad.
I took the same code and created an internal Opus command.
The BAT file works perfectly whereas the internal command fails on the last statement as reported earlier. I have tried "%doc%" with and without quotes, and also with double %%s instead of single %s. Makes no difference. The variable does not appear to be interpreted when it is stand-alone. However, it is interpreted correctly in the preceding echo statement.
As an afterthought, I wondered if Opus would treat a built-in variable any differently to a user generated one. It turns out that it does. I modified the internal command as follows..
..and the result shows that the built-in variable %windir% is correctly interpreted.
That will probably be closer to what you want anyway, since it will be like double-clicking the file.
There's special handling of quotes in the program/command name on each line (i.e. the first thing on each line before any arguments to that thing) to work around other problems with DOS batch files and the way they treat % characters.
Good grief! How on earth did you ever work that unlikely syntax out? It certainly does not fit into the "why didn't I think of that" category. I did get around to trying Start "%doc%", but the "" (null) prefix???
start "" "%doc%"
Any idea why standard - e.g. %windir% - and user-defined - e.g. %doc% - are interpreted differently?
The start "" thing is because the Windows start command interprets the first argument as a window title if it is in quotes, and as a command if it isn't. So if you need to quote the command you have to put an empty quoted string before it. It's ridiculous, but once you trip over it a few times you remember it.
Just another reason not to use DOS batch files for anything, TBH, along with the various % shenanigans, the strange handling of quotes and backslashes, poor handling of Unicode, and a million other things.
I spend hours trying to fix some siple DOS Batch quirk and then give up and do the same thing in 5 minutes using VBScript. VBScript isn't perfect but it makes life a lot easier.
