


Changes Affecting Version 4.2
The following paragraphs describe changes that can affect programs originally
written with ACUCOBOL-GT Version 4.2.
Compiler Changes
Version 4.3 contains two compilation switches for compatibility with Version
4.2:
-C42 Causes the compiler to generate code according to the rules used by
Version 4.2.
-Z42 Creates object code that can be run with a Version 4.2 runtime.
The following paragraphs describe changes that can affect programs originally
written with ACUCOBOL-GT Version 4.2.
- The default ACCEPT size for a numeric-edited field now includes a space for
the sign only if the field is signed. You can set the program to include a space
for an implied sign by compiling for semantic compatibility with an earlier
version of ACUCOBOL-GT using a compilation switch in the command line.
- One of the general rules for screen control entry has been modified: Prior to
version 4.3, an ACCEPT statement used to set ACCEPT-CONTROL to "1" if the event
was a "message" ("MSG-...") event. Starting with version 4.3, if the reason for
entry is a "notify" ("NTF-...") event, ACCEPT-CONTROL is set to "1"; otherwise
it defaults to "0").
- The "-Fo" option has replaced the "-Zo" option. Both compiler options produce
the same results, but the "-Zo" option should be considered obsolete.
- The compiler option "- Rw" has been expanded to allow, in addition to reserved
words, the suppression of some non-reserved words, such as control names
(e.g., "entry-field", "label") or property names (e.g., "max-text",
"bitmap-number"). If you tell the compiler to suppress a non-reserved word, however, it will
do so with the following warning: "Unknown reserved word: non-reserved word."
Runtime Changes
The following paragraphs describe changes that can affect programs originally
written with ACUCOBOL-GT Version 4.2.
- If a program is in the event procedure for an active control, and the control
activates and subsequently destroys another control, the control whose event
procedure is executing is reactivated. In previous versions, the "active"
control was left in an undefined state.
- When using the library routine WIN$PRINTER with the 32-bit runtime, the newer
Windows PageSetup dialog box will appear by default. If you wish to use the old
16-bit PrintSetup dialog box, you must use the operation code
WINPRINT-SETUP-OLD.
- In all releases up to and including the ACUCOBOL-GT 4.2 release, anytime you
created an Entry-Field control with a LINES value of "2" or greater, it was
treated as a multiline entry field. In version 4.3, this rule is modified so that
a LINES value of "2" or greater implies MULTILINE only if the "CELLS" phrase is
not also used or implied.
Note: When programming entry fields with Version 4.3, keep in mind that starting
with ACUCOBOL-GT 5.0 release, the program will no longer automatically assign
the "MULTILINE" style to an entry field with LINES value of "2" or greater.
Although Version 5.0 will correctly handle cases compiled with 4.x versions, in
order to do so you will need to specify an appropriate source-compatibility flag
(such as "-Z43"). This means that you are not yet required to explicitly set
the "MULTILINE" style, but doing so now will save you from having to use a
compatibility flag in the future.
Calling COBOL from other languages
Windows 95/98 and NT sites that are calling COBOL routines from C with the
"cobol" routine need to be aware of a change to the calling convention. The
calling convention has changed from "__cdecl" (the C calling convention) to
"__stdcall" (the Pascal calling convention, used by Windows API routines). This was
done to make integration with Visual Basic and Delphi more straightforward.
Programs that call the "cobol" routine must be sure to include "sub.h"
(included with ACUCOBOL-GT in the "lib" directory). This includes a declaration of
the "cobol" routine for all platforms. This ensures that you use the correct
calling convention when calling the "cobol" routine. If you have established
routines that call "cobol", these must be recompiled in order to use the new
calling convention.