884.1.1
XCALL MIAMEX,130,STARTCMD$ {,ASHFILE$} returns the startup command (i.e. the initial command that is executed on startup when A-Shell gets to the dot prompt) into STARTCMD$. If the ASHFILE$ argument is specified, it returns the name of the settings (.ash) file that was specified on the ashw32 command line (-o parameter). (The settings file only applies to A-Shell/Windows; it will always be null for UNIX.)
884.017
(Windows & ATE) A new control type has been added to MIAMEX,119 and TAB(-10,20) to implement progress bars. The control is similar to a static text control, except that you must specify the MBF'PROGRESS flag instead of MBF'STATIC, and currently the colors are ignored.
The control must be created using XCALL MIAMEX,119 in order to retrieve the ID, so that it can be subsequently updated. For example:
xcall MIAMEX, MX'WINBTN, 1, ID, TXT, STATE, MBF'PROGRESS, "", "", STATUS, SROW, SCOL, EROW, ECOL
Initially the progress bar will be empty. To update it, you can use MIAMEX,119 or TAB(-10,20) with OPCODE 2 (change), and specifying the ID returned from the above call, placing a string representation of the percent complete in the TXT parameter, and specifying the MBST'CHANGE flag in the STATE parameter, e.g.:
PCT = 15 ! percentage complete (round to integer)
xcall MIAMEX,MX'WINBTN,2,ID,STR(PCT),MBST'CHANGE,MBF'PROGRESS, &
"","",STATUS,SROW,SCOL,EROW,ECOL
The above call would move the progress bar over to the position representing 15% completion. If you are running from a UNIX server with ATE on the client and want to optimize the call, you can use TAB(-10,20) as follows:
?tab(-10,20);"2,";ID;",";str(PCT);",";MBST'CHANGE;",";MBF'PROGRESS; &
",,,0,0,0,0";chr(27);
Note that the coordinates are not needed as long as the ID is correct. This method is faster than the MIAMEX call over ATE connections since it doesn't have to wait for the return of any parameters from the client. (But in any case you probably don't want to update the progress bar more often than necessary to convey the sense of action. For example, in a report of 100,000 recods, it probably wouldn't make that much sense to update the progress bar for every single record.)
When the process is complete, you can delete the progress bar using OPCODE 3 like any other control.
884.0.2
A sample SBX routine, PROGRS.SBX (within source) has been released as both a sample to illustrate the use of the progress bar, and also as a starting point for creating more complex progress "dialogs". As it is, the subroutine provides the option to embed the progress bar within a dialog panel, with a caption and optional cancel button. See the notes in the PROGRS.BAS and TSTPRG.BAS programs for more information on the subroutine's parameters. NOTE that if you modify the subroutine, you should rename it to avoid having it accidentally overwritten by an update. Also, if anyone cares to make some general purpose enhancements to the routine and donate them back to the A-Shell community, please feel free to do so.
884.0.3
PCKLST.SBR now supports another new flag, 2048, which causes the text version to use INMEMO's "fast menu" mode. In this mode, it is not necessary to hit ENTER to complete a selection; instead, you just need to enter a sufficient number of characters to uniquely identify a selection.
884.0.4
The operation of the MSBOXX opcode BOX'WIN (to create a GUI-style raised panel box) has been improved to no longer require that the border option be selected, and more importantly, to work over ATE. If selected in a non-GUI environment, the option is just ignored (so you should combine it with whatever other box options you would otherwise use, including BOX'SVA, BOX'RSA, BOX'ERA, etc.)
Note that one of the advantages of BOX'WIN for pop-up boxes is that being a true control, it can overlay other controls, and other controls can overlay it, without the complications that arise when trying to save and restore text boxes in a mixed GUI environment. However, if you do use BOX'WIN, you should only use GUI-style static text and other controls to write within the box.
The PROGRS.SBX routine described above uses BOX'WIN. See the notes under edit 863 for more information on MSBOXX and BOX'WIN.
884.0.5
TAB(-10,20) no longer rejects controls that have empty text fields. This was thought to be to a useful optimization, but turns out to be more of a pain than anything else, due to the number of controls now that may not need any text to still be valid (like the progress bar.) Also, when updating a control, the coordinates can now all be zero (provided the ID is correct).
