1. (WINDOWS) Several improvements to the XCALL MIAMEX,71 function which allows you to add/delete/change Windows menu bar items. For convenience, the old (and still supported) syntax is:
xcall MIAMEX, 71, OPCODE, MENUID, MNUTXT, STATE, TYPE, LIB, FUNC, STATUS
The first improvement is that the MENUID parameter (which used to be numeric only, with 0=top, 1=File, 2=Edit, 3=Settings, 4=Help, and 5+ = your custom added menus) can now contain the text of the menu (e.g. "FILE", "EDIT", "&Custom", etc). This is particularly useful when you are adding and deleting top-level menu items, as it is a lot easier to reference a particular top-level menu item by its name than its position. Note that "TOP" may be used to refer to the top level menu as a whole (equivalent to 0). Also, when referencing top-level menus that you have added, you should use the same string format (including the & if applicable) that you used to add the menu item.
The second improvement is that the STATE parameter now applies when adding menus. This was the intent all along, but in the past, it was ignored and any added menus always started out enabled. Now you can add menus that start out disabled.
The third improvement is that for "normal" (command line) menus (TYPE=0), you may use the string "$ASHELL" to refer to A-Shell (or AshLite) and the current ini file. This can simplify the creation of menu items that launch new windows to perform an A-Shell task. For example, if LIB = "$ASHELL -e run armenu $", this would launch a new session on top of the current one (with the trailing $ suspending the current session until the new one exits) and have it run armenu (starting from the current login location) The -e switch causes A-Shell to exit when it would otherwise return to the dot prompt, which would have the effect of closing the new session and reactivating the original one. You could have done all of this before, but it was not convenient to have to hard code the MIAME.INI path.
The fourth and biggest improvement is the addition of a new simplified technique for adding, deleting, or enabling/disabling a entire batch of menu items at one time:
xcall MIAMEX, 71, OPCODE, MDFSPEC, STATE, STATUS
OPCODE, STATE and STATUS have the same meaning as before. MDFSPEC specifies the filespec (native or AMOS) of a "menu definition file", which consist of lines of the following format:
;(Blank lines and lines starting with semicolon are ignored)
;
MENUID, MNUTXT, TYPE, LIB
MENUID, MNUTXT, TYPE, LIB
etc.
If the MDFSPEC parameter is "", then it is assumed to refer to A-Shell's new help menu definition file, $MIAME\doc\ashelp.mdf (discussed in the next entry below.)
The file can specify any number of menu items (subject to the maximum of 125 custom menu items at any one time), all of which will be added, deleted, or enabled/disabled in one operation.
By convention, the normal extension for such a file is MDF (Menu Definition File).
Each of fields MENUID, MNUTXT, TYPE and LIB have the same meaning as in the old MIAMEX,71 calling format, but to further clarify:
MENUID is the top level menu number, or its name (e.g. "FILE", "TOP", 1, 0, "&Custom", etc.)
MNUTXT is the menu text string that will appear in the menu. You may include "&" to identify the accelerator key. For separator bars, specify a unique dummy string (needed to identify the item for later delete operations.)
TYPE specifies the menu item type. In addition to the numbers previously documented (in the A-Shell User Guide), you can also use the following mnemonics:
Mnemonic |
Value |
Meaning |
|---|---|---|
CMD |
0 |
LIB is a Windows command line |
SUB |
16 |
Item is actually a submenu |
SEP |
2048 |
Separator bar |
KBD |
65536 |
LIB contains keystrokes |
REG |
131072 |
LIB contains fspec/URL to open using the Registry-associated application |
LIB contains the command line (CMD) or keystrokes (KBD) or fspec or URL (REG). For menu item types SUB and SEP, you can specify a null string or just omit the LIB parameter.
Note that any of the fields can be enclosed in "quotes". This is mandatory if the field contains a comma.
Also note that only one level of submenu is currently allowed. That is, you can add an item to the top level menu and make it a submenu, but such a submenu cannot then support further submenus.
As with the old, one-item-at-a-time syntax, a return STATUS of 0 indicates success; otherwise error. (The old syntax might also return 1 for the change opcode to indicate the initial status of the item being changed, but that doesn't really apply here where many items are changed at once.)
If an error occurs, the operation will abort at that point, which should help you identify the line with the problem.
The sample program, ASMENU.BAS, has been updated to demonstrate both versions of MIAMEX,71, and a sample menu definition file (ASMENU.MNX) is now included in the release (or may be downloaded from the downloadable utilities page of the www.a-shell.net site).
2. (Windows) The documentation links on the Help menu are no longer hard coded. Instead, they are added dynamically using the technique just described above, using the MDF file:
<$MIAME dir>\doc\ashelp.mdf
The file is processed the first time you click on the menu bar or use MIAMEX,71.
If you don't like the documentation links we provide, or want to add your own, you can just modify the ashelp.mdf file. However, your changes may be overwritten by a subsequent release. Another technique which eliminates that possibility is that you add a program to your startup command file which uses the simplified MIAMEX,71 function described above to delete our documentation links and then add your own.
3. GETJOB.SBR and JOBNUM.SBR now support more than 255 jobs.
4. Fix bug in AMOSRUNSBR mode with XCALL AMOS,"<spec>" where <spec> is complete ersatz spec of a CMD or DOC file (e.g. "CMD:XYZ.CMD"). It was misinterpreting the file as a RUN file, which would then give and invalid RUN format error.
5. Fix intermittent runtime fault following Invalid RUN format error.
6. When the /S compiler switch is used (to eliminate the ++include "Copying from xxx.bsi" messages), error messages will now be output in a slightly different format which includes the filename. Also, when both /S and /N are used, all "Phase 1" and "Phase 2" messages are eliminated, leaving just the compile version message, any errors, and the "End of Compilation" message.
