My initial construct for the new Input95.bat was pretty simple. But, I decided it was better to have most of the required setup code built in and to have the name of the variable that receives the input data as a command line option. This means the input routine is significantly more complex, but that the calling routine is greatly simplified.
An important requirement of this approach is that the Input.bat routine be invoked via a shortcut (Input.pif) rather than by calling it directly. The shortcut is constructed with two special features. First, the literal string '%Title%' (without the quotes) must be entered as the first line on the 'Program' tab of the shortcut 'Properties' dialog. Second, a question mark is added to the end of the 'Cmd line'. (See Figure 1.)
Figure 1. Construction of the Input Shortcut.
Assuming the Input95.bat routine is located in a folder named in the PATH statement, the calling batch procedure simply invokes the new and improved input routine something like this:
set Title=A test of batch file input
call input95.bat
This will pop-up a dialog box, because of the question mark in the shortcut. The dialog will have the contents of 'Title' as its prompt string and store the result in the default variable 'Input'. Unfortunately, the run time title becomes permanent once Input.pif is run. Also, if the prompt string exceeds 29 characters the name of the environment variable will be displayed instead of its contents. The solution to the title replacement is to run a copy of Input.pif that is deleted after each execution. This is done automatically within Input.bat, but is restricted to a hard coded designation for the storage of the original copy of the PIF file. I can't think of a good solution to the 29 character limit beyond care in constructing the Title string.
The following procedure demonstrates some of the versatility afforded by this approach.
This demonstration procedure requests two sets of user input, something that cannot be done with a shortcut alone. In addition, the first request will not accept an empty string. An error message is displayed and the title of the input dialog is changed for the retry. I believe this approach significantly extends the versatility of a batch procedure under Windows 95.
One other feature of TInput95.bat that is worthy of note is the construct in the last line. The PROMPT/CLS combination insures the DOS session will close, regardless of the method used to invoke TInput95.bat. Normally, batch files started from an Explorer window or from a shortcut that does not have its 'Close window on exit' feature selected will remain open even after the procedure has ended. I suppose this is to allow the user to see the output or error messages before the window is closed. In some cases this may be a useful feature, but most of the time I find the behavior annoying.