Ok, it's official: I'm lousy at coming up with catchy, fitting titles.
This default clickbait title seemed just as bad as:
"A script to create a dialog box to load / view / edit (user) settings that be will used for the current session with an option to save these settings in the script itself for future use.
Includes an option to revert these settings to factory default."
Although the latter one describes the functionality a little better.
Picture:
Not exactly spectacular.
The interesting part lies in the way these settings are saved: in the script itself.
There are the@FILE* and @FILE*B functions to do so, but these seemed overly complicated (to me, that is).
Then I remembered that the INI functions on Windows are very straightforward.
For example, if you want to find the value of MouseWheel under [4NT] in a file:
[anything]
...
[4NT]
...
MouseWheel=Yes
, It just reads the file until if hits [4NT] and then reads until it finds MouseWheel. (or hits **EOF** or another [header] ).
You could even put the contents of an INI file in a DLL and it still would find it! (*)
So I just put the settings in the .btm The script "jumps over" the part where the settings are, but @INIREAD and @INIWRITE still know to find it.
Seems a little chaotic, but only while coding. In the "GUI" this is no problem.
A few other scripting techniques were used that might be useful. For example: it was not trivial to load all the settings from the "INI" part of the script as environment variables (there is no function to read all of the settings under a specific [header] ). Check out the script if you are interested.
Some remarks
(*) Not recomended, of course. The DLL will lose it's integrity and there could also be multiple **EOF**'s in this DLL, which might cause the @INI.... functions to quit to soon.
This default clickbait title seemed just as bad as:
"A script to create a dialog box to load / view / edit (user) settings that be will used for the current session with an option to save these settings in the script itself for future use.
Includes an option to revert these settings to factory default."
Although the latter one describes the functionality a little better.
Picture:
Not exactly spectacular.
The interesting part lies in the way these settings are saved: in the script itself.
There are the@FILE* and @FILE*B functions to do so, but these seemed overly complicated (to me, that is).
Then I remembered that the INI functions on Windows are very straightforward.
For example, if you want to find the value of MouseWheel under [4NT] in a file:
[anything]
...
[4NT]
...
MouseWheel=Yes
, It just reads the file until if hits [4NT] and then reads until it finds MouseWheel. (or hits **EOF** or another [header] ).
You could even put the contents of an INI file in a DLL and it still would find it! (*)
So I just put the settings in the .btm The script "jumps over" the part where the settings are, but @INIREAD and @INIWRITE still know to find it.
Code:
TEXT |! %SETTINGS_COMMAND
[usersettings]
MOVESTEP=11
TEXT_MOVESTEP= Delta position (in pixels) for moving window^r^n Accepted values: 0-100
DELTA_X=22
TEXT_DELTA_X=Delta columns for resize^r^nand some more text
DELTA_Y=33
TEXT_DELTA_Y=Delta rows for resize
LOGFILE=c:\test\logfile.txt
TEXT_LOGFILE=Location of logfile
TYPE_LOGFILE=FILE
[endusersettings]
ENDTEXTSeems a little chaotic, but only while coding. In the "GUI" this is no problem.
A few other scripting techniques were used that might be useful. For example: it was not trivial to load all the settings from the "INI" part of the script as environment variables (there is no function to read all of the settings under a specific [header] ). Check out the script if you are interested.
Some remarks
- This is build as a "ready to run" standalone script. The only thing it does, is loading/viewing/changing the settings in the script. If you want to use the routines for your own script, you have to embed them in your code.
- The settings are saved in the script itself. Could also be used to save these in the profile of the user (like %appdata%\MyScript.ini" or in an alternate datastream (on NTFS filesystems) if the settings are different from the default settings.
- The used QUERYBOX command supports more than 2 lines for the "prompt", but displays only 2 (and a bit).
- Will not work on TCC/LE, although I think that after a few adjustments it can be made to work on LE ("|" instead of "|!", "%" instead of "%%") .
- Now I think of it: it is sort of the way the OPTION command works. Ah well, too late.
(*) Not recomended, of course. The DLL will lose it's integrity and there could also be multiple **EOF**'s in this DLL, which might cause the @INI.... functions to quit to soon.
Last edited:
