You will never guess what happens next! .... ;-)

#1
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:
2017-02-10 12_31_19-TCC - find _=_.png


Not exactly spectacular.
The interesting part lies in the way these settings are saved: in the script itself.

There are [email protected]* 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]
   ENDTEXT
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

  • 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.
 

Attachments

Last edited:
#3
Hello Joe :-) (your script works fine :-)
You mean by placing the ini-settings at the end of the script? That will work. And also take care of the skipping part. And thus make the code "cleaner". Good idea!
It was just out of habit that I placed this in the beginning of the script (my usual order: settings, initialization, main, subroutines,syntax).

BTW: In this specific case, the INI-settings are placed inside a textblock inside a subroutine:

:SUBROUTINE
TEXT |! %SETTINGS_COMMAND
ini-settings
ENDTEXT
RETURN


This subroutine is called several times, each with a different %SETTINGS_COMMAND to do different things with the data inside the TEXT block.
So, in this case the subroutines "block" would be the sweetspot.
Thanks!