CONFIG Level 2 ============== We felt that a number of things were missing in the definition of level 1 of the QJUMP Standard configuration definition. Therefore, after a number of discussions, the following suggestions were made to be implemented on level 2. This will take a while, and we are happy to receive comments and/or suggestions. Please leave any messages in message area 10 (German) or, preferably, in area 11 (QDOS English). First of all, re-configuring software you already had in previous versions is a very boring thing. Most of the time, all you do is set the old settings in the new file. This has to be made automatic. Therefore, the item structure is expanded to make room for an config-item-ID, i.e. The configuration level 2 consists of the following information: Configuration ID Configuration level Software name Software version List of Item ID (long) <---- NEW!!! Type of item (string, integer etc.) (byte) Item Selection keystroke (byte) Pointer to item Pointer to item pre-processing routine Pointer to item post-processing routine Pointer to description of item Pointer to attributes of item (item type dependent) End word (value -1) The ID should be unique for every item. There may be global ID names, which could be used by many programs (like the colourway setting), there can be unique "registered" ID names (which are preferred) and there may be "unregistered" local ID names. Global ID names should start with an underscore, unique ID names should start with a letter. For unregistered local IDs, the top byte of the ID has to be 0. For all ID names, a list which is maintained by Jochen Merz Software is created, to avoid multiple name conflicts. If you wish to register for one or more ID names, please write to Jochen Merz Software and enclose an I.R.C. You may suggest one or more name, otherwise JMS will try to find a sensible abbreviation for you. ID names consist of a longword (i.e. four characters). The first three characters have to be reserved by JMS, the fourth character can freely be assigned by the software house for the various items. The function of the CONFIG program ================================== When the CONFIG program starts up, the user selects the file to configure (which should contain one or more level 1 or level 2 config blocks). Level 1 blocks are treated as before (i.e. they can be printed or configured), but for level 2, there is an additional UPDATE facility. CONFIG "learns" level 2 configurations and stores the settings of the item for any ID in a separate file, giving a "global" default configuration file. When the user selects UPDATE, the config block is scanned for IDs, and every ID is checked in the global default configuration file. If it is found, the preferred setting is automatically copied in the file which is to be configured. This way, updating programs is MUCH easier and nearly automatic. In fact, in could be made completely automatic (via parameter string). Another advantage is, that the configuration can be made language-independent. The "learned" configuration of an English file could be used to configure a German or French file, for example, provided that the sasme items have got the same ID's. Care should be taken for items, which are language-dependent filenames (i.e. help-files, auto-save filenames etc.), which SHOULD have different ID's, otherwise the German program would save to an English file or vice versa. Local IDs are not stored by MenuConfig. When a user wants to update a file containing local IDs, then MenuConfig has to "learn" the old settings from the old (already configured) version of the file, and these settings are then updated to the new version of the file. The local IDs are not stored anywhere else, as this could lead to ID clashes between different files containing the same local ID for different purposes. MenuConfig V2 stores the learned settings in a file called MenuConfig_INF on your current PROGram default device. It will try to read it from there the next time to execute MenuConfig. You can, of course, tell MenuConfig to load a different _INF file containing other configuration information, for example if you prefer having different configurations for colour and monochrome versions (!). When you terminate MenuConfig and you changed or learned new settings, MenuConfig asks you whether you want to update the _INF file, so that the settings are preserved for the next update. An additional item type ======================= It became obvious in MenuConfig, that a new item type "nothing" or "all" is required, which does not do anything automatic but calling the pre/post- processing routines. This is useful for proving own menus without having to mess around with unwanted texts. In addition, more information is required to be passed to these pre/postprocessing routines. We think, at the moment, of the following scheme: A3, which points to a 4kBytes space, is negative indexed and provides the following information: $0000 4k base of workspace passed to pre/postprocessing routine -$0004 long MenuConfig's version -$0008 long primary channel ID -$000c long pointer to working definition -$0010 2 word primary window x/y size -$0014 2 word primary window x/y origin -$0018 2 word work area x/y size -$001c 2 word work area x/y origin -$001d byte text info window number in working def -$001e byte work info window number in working def -$0022 long window manager vector -$0026 long pointer to filename of the file being configured -$002a long pointer to buffer containing file being configured -$002e long pointer to buffer of default directory -$0032 long pointer to buffer of output device -$0040 long colourway WORKING COPY ============ If the configured file contains a flag "<>" BEFORE the "<>" flag (which can be generated with the new Macro MKCFCUT) then MenuConfig offers the user the choice to save a configured version without the config texts, to reduce the required file size to the minimum (as the configuration texts are not required anymore after configuration). Of course, a file treated this way cannot be configured afterwards anymore. Programmers should take care that the configuration items come BEFORE the configuration texts, otherwise they will be cut away too. So make sure that the configuration texts are always the last section in your file!!! LIST OF GLOBAL ID'S =================== _COL Main Colourway Byte range -1, 0 to 3. _COS Sub-Window Colourway Byte range -1, 0 to 3. _COB Button Colourway Byte range -1, 0 to 3. LIST OF RESERVED ID'S ===================== ATA. ATARI-Rext DRN. Disk Rename EMU. ATARI-Emulator EPM. EPROM-Manager FiF. FiFi HLP. HyperHelp MBT. MultiButton MCF. MenuConfig MEN. Menu Extension MPK. MultiPick OSP. Operating System Preferences (SMSQ) PAD. Notepad PDF. Page Designer 3 Fonts 1 PDf. Page Designer 3 Fonts 2 PDG. Page Designer 3 General PDP. Page Designer 3 Page PDp. Page Designer 3 Pattern PRP. PrinterPanel PRM. QPrommer QBS. QBASIC QDA. QD (Tab Options) QDE. QD (Editor) QDF. QD (Files) QDG. QD (General) QDS. QDesign QMK. QMake QSN. QSnap SST. Systat SYP. System Passwort SYS. System TAB. QSpread TAb. QSpread TaB. QSpread Tab. QSpread TRA. TRA Extension WED. WIN Ed WSL. WIN Select