864.4.1
FORCE.LIT 2.0A(105) supports the AMOS-style multi-line syntax:, i.e.
.FORCE TSKAAB
LOG BAS:
RUN MYPROG
15
~
TIME
The above would force TSKAAB to execute "LOG BAS:", then "RUN MYPROG", then "15", and finally a blank line (Tilde by itself is treated as a blank line.) The blank line terminates the force operation. (The TIME command would then be executed back in the current job.)
Note that under A-Shell/Windows, the response time for receiving forced commands may be several seconds. To avoid overrunning the target job, the sender will be forced to wait for each command to be acknowledged by the receiver.
It also supports forcing commands to yourself. This is useful for forcing input to a program that does not normally accept input from a command file. It is usually used with the $NJ system variable in DO files to specify the current jobname, e.g.:
;MYPROG.DO
:R
LOG BAS:
FORCE $NJ
RUN MYPROG
15
~
TIME
Note that the TIME command here will execute before the forced commands, since CMD and DO input is processed first, then typeahead. Also note that there isn't much point in this exercise unless MYPROG (in this case) doesn't accept command file input. Otherwise we could just omit the FORCE command and MYPROG would run the same from the DO file as it would with the forced input.
A-Shell still supports the non-AMOS standard single-line FORCE, in which the command is passed on the command line, e.g.:
.FORCE TSKAAB LOG SYS:^M
Note that in this mode, you have to explicitly add a ^M to the end of the line to force a carriage return.
Finally, note that the LITMSG.xxx message files have been updated for some new messages in FORCE.
864.3.1
SUBMIT.LIT 3.0A(134) now protects against two jobs simultaneously expanding a CTL file into the same temp file. Previously this was possible if the CTL file was quite large.
864.3.2
DO.LIT 2.1(117) and MDO.LIT 2.1(117) increase the maximum expanded do file from about 62K to about 122K. This is about the maximum size for a 430K partition, which is about the minimum partition needed for some other large LIT commands, such as SUBMIT. It will now complain explicitly if the partition size is not sufficient.
864.3.3
A loophole in the string expression handler has been closed, which previously allowed a GPF or core dump to occur if a large string (larger than 4K) was also larger than the amount of available stack space. The most likely example of this was in the DO file handler, which works with very large stings. Now a stack overflow is reported in this condition.
864.3.4
INFLD now checks that the SETDEF parameter is a string, helping to clearly identify bad argument lists which otherwise may have appeared to work.
864.3.5
(Windows) A further PCKLST GUI bug fixed, in which minimizing and restoring the window while the listbox was up would cause it to exit from the listbox.
864.2
1.(Windows) PCKLST GUI bug fix: Toggling to another application while in a listbox caused the listbox to disappear when you returned (as if you had exited with ESC.)
2.(Windows) PCKLST GUI bug fix: Titles which did not contain CHR(13) (to start the bottom title) were being ignored. (Bottom titles are still being ignored, but this is by decision.)
864.3
EZSPL configuration files now support a new statement:
EXTOPT=###
Where ## can be a combination of the following:
4 Disable screen save/restore
32 Allow exit from EZVUE with left arrow
64 Allow exit from EZVUE with TAB
128 Allow exit from EZVUE with F1-F16
These can also be set directly in the EXTOPT field of the "new" EZSPL calling format.
864.4
(Windows) PCKLST GUI bug fixes and improvements:
| • | A stray ESC or RETURN character was being left in the keyboard buffer (causing problems for the next thing after the PCKLST). |
| • | Array mode now formats better even if entries do not all have trailing nulls. |
| • | If the PROMPT is not blank, it is now used to create a simulation of the old title bar above the pick list. The color of the prompt will use the BFCLR parameter of the MMOCLR structure passed to PCKLST (or white if not specified) on a background matching the Windows title bar color. The bottom prompt is still ignored. (The problem here is that the height of the listbox is adjusted based on the actual font resolution to hold and integral number of items, so that it doesn't necessarily line up with the row units used by other controls, making it difficult to align the bottom prompt without a gap. Even without that problem, such bottom prompts don't look right in Windows.) |
| • | You can now use TABs within items. The tab stops are not (yet?) adjustable, but are approximately 3/4 of an inch apart, which might work out if you have a two column list where the first column contains variable width characters (i.e. letters, not just numbers.) |
| • | (Windows) A new flag has been added for use with MIAMEX,119 when creating buttons and checkboxes: MBF'UNPROTECTED (134217728). This causes buttons and checkboxes to act like static controls with respect to whether they can be deleted via TAB(-1,9), TAB(-1,10), and TAB(X,Y). (By default, static text controls act like text and can be deleted by TCRTS 9 and 10, as well as a mere TAB(X,Y) to the upper left corner, unless you set the dim attribute and then use TAB(-1,13) to set protected mode before the TAB(-1,9) or TAB(-1,10). But buttons and checkboxes, by default, can only be deleted by TAB(-1,0) or by calling MIAMEX,119 with opcode 3. You can override that behaviour and make them act like static text by specifying the MBF'UNPROTECTED (defined in ASHELL.BSI) flag when you create them. |
| • | (Windows) A new "Miscellaneous Settings" dialog has been added to the Settings menu. Currently it contains only one parameter, "External Leading". This is expressed in the number of pixels of extra space to allow between rows. By increasing the leading, you space effectively decrease the normal text font height (for a particular window size) and increase the space between the rows. This might help some crowded applications move towards the more spacious look of typical Windows applications. In large window sizes (paticularly full screen), it may also help trim the size of normal text down closer to the size of the proportional text used in buttons and static text controls. The effect of changing the leading is immediate, so it is easy to experiment with. It is saved along with other settings by the File..Save or File..Save As menu options, and loaded automatically when A-Shell is launched. |
Note that when lines of text are output to the screen, if the leading is non-zero, there will be space between the lines that is not filled in by the background color associated with that PRINT statement. The only way to fill in that space is by using a multi-line clearing command, such as TAB(-1,10) or TAB(-1,0). Consequently, leading is not recommended unless you tend to stick with a single background color (such as Windows gray) for your application.
