Two related basic questions about message boxes, probably arising from my misreading of the Help file.
The command {dlgstring} has a textbox. How do I make DOpus display a purely informational message box, without any textbox, and with only an "OK" button to dismiss it? Using {dlgstring} for this purpose is clumsy because the user may enter text, which DOpus will then try to execute. Also, it seems wrong to use the command @confirm: here because that command involves the sequencing of other commands, and also because it seems not to take parameters properly. Perhaps I should use MsgBox, but and I would rather stay within DOpus (and I don't know VBScript, although the code does seem pretty straightforward).
Suppose that the text of {dlgstring} is, for argument's sake, "The file &myfilename& is required", and that &myfilename& is D:\stories\newstory.docx, which contains the sequence "\n" within it. Then "\n" is omitted from the path and replaced by a line break. The new command "escbackslash" seems to promise a solution, but I can't work out how to implement it.
Hopefully:
The solution to question 2 can be used in the solution to question 1, meaning that it should be possible to pass parameters of the form &myfilename&, and at the same time avoid confusion over "\n".
When "Function" has been set to "MS-DOS Batch Function", the solutions will also work when preceeded by
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd
I've now solved all my own questions using MsgBox. Marvellous what lunch and a bushwalk can achieve. For the record:
MsgBox has a purely informational message box dismissed by "OK". This is what I wanted. Its syntax is very easy, and as noted in other posts, is well described in msdn.microsoft.com/en-us/library ... 84%29.aspx
MsgBox uses "..." & chr(13) & "..." rather than /n for line breaks, so Problem 2 does not arise. I can pass filenames, including filepaths, with no problem,
Because the MsgBox command uses VBScript, and the rest of the function is an "MS-DOS Batch Function", I wrote a separate VBScript function for the MsgBox command. This function is then called by the first function. I had to build the line breaks into this VBScript command because I couldn't work out how to pass parameters that contained the symbols & and ".
The call to the VBScript function works properly when preceded by "C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd
Apologies for asking basic questions, and also for saying above that @confirm: "does not pass parameters properly". I had typed the parameters into the wrong box.
The first reason for not using @confirm: is that I don't have a workaround for my Problem 2, concerning situations such as D:\stories\newstory.docx when the parameter is a filepath that contains the sequence \n within it.
The second reason is that the sequence "|OK" at the end of the @confirm: command seems to get misinterpreted somehow in the MS-DOS situation, although I am probably misunderstanding the codes. For example, the command
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd @Confirm: Everying seems correct|OK
works as expected when "Function" is set to "Standard Function (Opus of External)". When "Function" is set to "MS-DOS Batch Function", however, DOS delivers the following error message:
'OK' is not recognized as an internal or external command, operable program or batch file.
(There is also the issue that @confirm: affects of the sequencing of other commands.)
(Leo, this is now academic as far as I am concerned, because as I reported in my second post above, I have solved my original problem using MsgBox.)
I'm still not understanding the codes correctly. For the sake of the argument, I have written a very simple button called "Story" with "Function" set to "Standard Function". It contains the single line:
TestConfirm D:@TeX\newstory.tex
where "TestConfirm" is a "User-defined command" with TheFile entered into the "Template" box as a parameter, and "Function" set to "MS-DOS Batch Function". It contains the following two lines. (Note that dopusrt.exe /cmd has been omitted from the second line as you recommended above --- the "|OK" at the end now works).
"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Go "D:@TeX" DualPath "D:" New @confirm: The required file is &TheFile&|OK
Problem 1: \n is interpreted as a line break. I tried silly things like replacing &TheFile& by {&TheFile&|escbackslash}, but of course this didn't work, nor did replacing C:@TeX\newstory.tex by {C:@TeX\newstory.tex|escbackslash}, and I couldn't think of any other sensible or silly way to add escbackslash.
Problem 2: @confirm runs first, being a DOpus command. Then the first line runs only when the message box is dismissed, because @confirm is not really an informational message box, but is more a device to control the flow of the other commands. This can be solved by omitting dopusrt.exe /cmd from the first line as well, but the Help files say always to use dopusrt.exe commands in MS-DOS Batch Files. More generally, using DOpus commands in an "MS-DOS Batch File" function can mess things up badly.
@confirm: The required file is D:\@TeX\\newstory.tex|OK
Go "D:\@TeX" DualPath "D:\" New
...directly in the "button". No user commands, no MS-DOS batch function types, etc. This is in the case where you have a static file name and path that you're manually specifying in the message - such as you used in your example. In the case where you know the filename, and it contains a \n sequence, just manually add an extra \ char to the \n sequence as above. If you've got a good reason to still want to break the code that does the confirmation and Go commands into a separate user command, just apply the same extra \ char to the file path in your call to the user command (TestConfirm D:@TeX\newstory.tex) and then modify the code above to run:
@confirm: The required file is &TheFile&|OK
Go "D:\@TeX" DualPath "D:\" New
...but this time in the user command instead of directly in the button, again - without any dopusrt or MS-DOS batch stuff.
Leo's suggestion of using the escbackslash control code only applies if you're trying to pass a SELECTED file to another Opus function like @confirm. The {filepath} code sends the SELECTED file names full path, and the escbackslash code ({filepath|escbackslash}) does the job of fixing up the \n sequence. But again, since you seem to be MANUALLY passing the name of some file, you can just fix up the \n sequence yourself. I don't "think" there's any way to arbitrarily use escbackslash with a manually specified string.
Side note: the reason the manual says to always use dopusrt.exe in MS-DOS Batch Files is that IF you have a good reason to be running an MS-DOS type function in the first place (or an actual batch file outside of Opus), it's the Windows shell that is executing the commands. As you might imagine, Windows has no idea about internal Dopus commands/functions... so if you ran a batch file with the Dopus command "Go D:@TeX", Windows would just complain "'Go' is not recognized as an internal or external command"... etc. In this case, dopusrt.exe is just an executable that Windows can run like any other executable, and can be used as a way to access internal Dopus commands/functions from external applications (and when you run an Opus "MS-DOS" function type, Opus is basically just resolving any Opus specific variables you might be using, and then sticking all the resolved commands in an actual batch file that is executed from the %TEMP% folder in the background - functionally running like an external application).
Where does the manual say that? It's not true; you can run Opus commands from MS-DOS Batch Mode buttons without using dopusrt (unless you've used @externalonly to disable internal commands).
Wow, guess I made all of that crap up... don't think I've ever been as off-base as that.
FWIW: I didn't know the manual said anything of the sort. I was taking the OP's comment at face value because I "did" think that at one point Windows would puke on internal Opus functions when run in MS-DOS batch function type buttons. Woops... sorry for the misinformation. Now I'm wracking my brain about why I genuinely THOUGHT internal commands threw that error from batch type buttons.
I'm the cause of this confusion, so I should clarify. What I was half-remembering was not in the Help file at all, it was a dictum of Leo's at the very end of this thread in the Forum:
To quote: "You can't mix DOS batch flow control and Opus commands as any Opus command causes the batch to be split in two.
You can either run the Opus commands via dopusrt.exe /acmd or use the equivalent DOS command instead, e.g. del."
Mixing DOS commands and DOpus commands seems to muck up the order and flow of the commands when "Function" is set to "MS-DOS" and the batch file contains "If" or "Goto" commands. I haven't pinned down the situation any more precisely than that, and I could be completely off the track.
...