943.0.1
(WINDOWS) You may now specify an overlay file in the calling arguments to SPOOL (EZSPL). This has the same function as setting OVERLAY= in the printer init file, but any overlay specified in the XCALL statement will override an overlay in the printer init file.
You may also specify the total number of pages in the printout. If specified, any occurrence of "%#" in the printfile will be replaced with the total number of pages. For example, a string in the printfile of the form "Page 1 of %#" would be converted to "Page 1 of 100", assuming that the total pages had been set to 100. Obviously you could have done this directly in your application, but it is often difficult to know in advance how many pages you are going to generate, whereas it is easy to count them as you generate them and then pass the total to SPOOL/EZSPL.
The calling syntax for SPOOL/EZSPL is now:
Old format:
xcall SPOOL, file {,printer {,switches {,copies {,form {,lpp {,width {,prefix {,suffix {,overlay {,totpages}}}}}}}}}}
New format:
xcall EZSPL, file, table
This format hasn't changed, but two new fields have been added to the end of the TABLE structure:
MAP1 TABLE
MAP2 PRINTER,S,64
...
MAP2 HOSTROWS,F,6
MAP2 EZCOLORS
MAP3 EZFG'TXT,B,1
...
MAP3 EZBG'BRF,B,1
MAP2 OVERLAY,S,28 ! (new) overlay file
MAP2 TOTPAGES,F,6 ! (new) total pages
943.0.2
The AUI_EVENTWAIT OP flag EVW_EDIT (aka EVW_INFLD) now applies to all editable fields. Currently this means INFLD and XTREE; previously it was just INFLD. The concept is that when the focus would have been set on an editable field, AUI_EVENTWAIT will trigger the click sequence for the field, which will cause it to exit with the EXITCODE for that field. (Otherwise EVW_EVENTWAIT ignores editable fields.)
943.0.3
A new OP flag has been added to AUI_EVENTWAIT:
EVW_EXCDFOCUS (65536 or &h10000 as defined in ashell.def)
When set, AUI_EVENTWAIT gives preference to the incoming EXITCODE value in deciding which control to initially set the focus on, using the following rules:
• | If EXITCODE < 0 and not -35 thru -42 (often used for SHIFT-TAB and SHIFT arrows) then it is interpreted as if the CTLID parameter had been set to the control whose click-string generates the specified EXITCODE. Provided that the control is of a type that is normally allowed to retain the focus by EVENTWAIT. If, for example, you define both a static text label and an INFLD field with the same EXITCODE click string, EVENTWAIT will skip over the label and activate the INFLD field. |
• | Else if EXITCODE is 2, 3, -35, -36, -37, -40 or -42 (left arrow, up arrow, shift-left, shift-up, shift-tab and shifted XTREE up/left) then the EVW_PREV flag is automatically set. |
• | Else if EXITCODE is 5, 7, 12, -38, -39 or -41 (down arrow, tab, right arrow, shift-right, shift-down, shift-right in XTREE) then the EVW_NEXT flag is automatically set. |
• | Else it acts as if the EVW_EXCDFOCUS flag had not been set. |
An example will make it clear why this is handy. Imagine a dialog containing some buttons and also several INFLD fields, where you are going to use AUI_EVENTWAIT. Previously, to start you might have set CTLID to the ID of a particular button. You can still do that, but since the logic of your application is probably built on the EXITCODE values rather than the control IDs, it will be easier to just set EXITCODE to the value corresponding to the desired control and use EVW_EXCDFOCUS. That's a minor improvement. But consider if you wanted to start on one of the INFLD fields. You wouldn't call AUI_EVENTWAIT at all, rather you'd call INFLD. But this complicates your logic. If you just set EXITCODE to the value corresponding to the desired field (and specify EVW_EDIT) then AUI_EVENTWAIT will immediately return to you with the desired exitcode—which accomplishes nothing but simplifies your code since you don't have to have special logic for handling the initial focus.
The main improvement comes as you return to the AUI_EVENTWAIT after calling INFLD (or XTREE). If the user exits from the INFLD operation by hitting up arrow (returning EXITCODE 3), previously you would have had to figure out what the control ID was for the control prior to that INFLD control (or at the very least, have logic to set the EVW_NEXT or EVW_PREV flags). Now, with the EVW_EXCDFOCUS flag, you can just go right back to the AUI_EVENTWAIT operation and let it decide what the next control to get the focus should be.
In other words, your dialog loop can probably now be simplified down to something like:
do
xcall AUI,AUI_EVENTWAIT,CTLID,PARENTID,EXITCODE,OPFLAGS
if <exitcode to exit dialog>
exit
else
call <field handler based on exitcode>
loop
943.0.4
(Windows/ATE) INFLD and EVENTWAIT now support the use of ALT+? (where ? is the designated accelerator key for a control which has a click string associated with it) as another equivalent to clicking on the control with the mouse. To specify an accelerator key for a control, preceded the desired letter with & in the text field. For example, a button whose text is "E&xit" will fire when ALT+x is input (and will display with the "x" underlined).
943.0.5
(Windows/ATE) MIAMEX, MX_GETOFD (95, or Get Open File Dialog) now supports ATE.
943.0.6
(Windows/ATE) Fix a bug with querying controls whose text contains CRLF.