COMPAT.TXT for Visual Basic for MS-DOS 1.0

• Microsoft Visual Basic Standard and Professional Editions for MS-DOS, version 1.0

MORE INFORMATION

                                   COMPAT.TXT

          Compatibility Notes for Visual Basic for MS-DOS and Windows

                   (C) Copyright Microsoft Corporation, 1992

This document contains miscellaneous programming differences between
Visual Basic for MS-DOS (VB/MS-DOS) and Visual Basic for Windows
(VB/Windows) that were too late-breaking to include in the printed
documentation. See Appendix I, "Building Portable Applications," in
the "Programmer's Guide" for more comprehensive information on this
subject.

Differences in Scope
--------------------
In VB/MS-DOS, shared array declarations cannot be "eclipsed" at the
procedure level. This means that the following code behaves
differently in VB/MS-DOS and VB/Windows:

DIM SHARED Array%()
CALL Initialize

SUB Initialize ( )
  DIM Array%(100)  ' In VB/Windows, creates a new Array%() that "eclipses"
END SUB            ' the shared variable. In VB/MS-DOS, dimensions Array%.

Menus and Timer Events
----------------------
In VB/MS-DOS, timer events are suspended while a menu control has
focus. When the menu control loses focus, timer events resume. Timer
events are not suspended in this way in VB/Windows.

ERR Statement
-------------
In VB/MS-DOS, you cannot use the ERR statement to set error codes
>255. To work around this, use ERROR to re-create the error and
indirectly set the error code.

Forms
-----
Setting BorderStyle to None (0) in VB/MS-DOS results in MinButton,
MaxButton, and ControlBox being set to FALSE (0) at run-time. In
VB/Windows, these properties are not set to FALSE but retain the same
values that are set at design-time.

Clicking on disabled controls in VB/Windows results in a click event
being sent to the form. This does not occur in VB/MS-DOS. The click is
ignored.

VB/MS-DOS allows a form to be unloaded from within its RESIZE event
procedure. VB/Windows does not allow this (generates an error).

File List Boxes
---------------
VB/Windows will return error 380 when setting the Pattern property of
File List boxes to any of the following: ";", ":", or "\". VB/MS-DOS
will not return an error but will assign this value to the Pattern
property and generate a PatternChange event. Both VB/Windows and
VB/MS-DOS handle other invalid pattern assignments (i.e. "=") in a
similar manner (assign the value to Pattern property and generate
PatternChange event.

VB/Windows will generate error 53 (File not found) when assigning a
non-existent file name to the FileName property of File List boxes.
VB/MS-DOS will not generate an error, but rather will parse the value
assigned to the FileName property as a value for the Pattern property,
a value for which no match will be found. To determine if a file
exists, either the DIR$ function or check that File1.FileName = "" and
File1.Pattern = <non-existent file> after the assignment.

VB/Windows returns file names (FileName property) in lower case.
VB/MS-DOS returns file names in upper case.

List Boxes
----------
In VB/MS-DOS, the selected item must always be visible within the list
box. In VB/Windows, the selected item can be scrolled out of sight
with the mouse. Thus in VB/MS-DOS, as you scroll the listbox with the
mouse, the selected item will change to remain visible. This functions
exactly like scrolling the list box with the keyboard cursor keys in
either VB/MS-DOS or VB/Windows.

Text Boxes
----------
In VB/Windows, text boxes with horizontal scrollbars (no word wrap)
will still wrap text longer than 1023 characters. In VB/MS-DOS, text
boxes with horizontal scrollbars will not wrap text regardless of
length.

VB/MS-DOS text boxes (including text portion of combo box) do not
support word highlight with double mouse click. VB/Windows text boxes
do support this feature.

Keywords
--------
VB/MS-DOS and VB/Windows support some different reserved words.
Conflicts may occur if a reserved word in VB/MS-DOS or VB/Windows is
used as a variable name in the other product (where it is not a
reserved word). Replace all occurances of these type of variable names
with new names. A common example of this is LIST (reserved in Visual Basic
for MS-DOS, but not in Visual Basic for Windows).

COMMAND$
--------
The case of the text returned by the COMMAND$ function is different in
VB/Windows and VB/MS-DOS. VB/MS-DOS returns an all upper case string
while VB/Windows returns the string in the same case the user provide
it.

Form/Control Allocation
-----------------------
In VB/MS-DOS, window structures for forms and controls remain
allocated after an unload (form or control array element) until the
last procedure in the current calling sequence ends and control
returns to the top-most DOEVENTS loop (either implicit or explicit).
Form and control data space is freed immediately after an unload
however.

In VB/Windows, window structures are deallocated after the unload.
This may cause differences in the number of forms and controls that
can be loaded and unloaded within the current calling sequence
depending on available memory.

ActiveControl and Disabled Controls
-----------------------------------
If you disable all of the controls on a form in code,
SCREEN.ActiveControl returns the last enabled control in VB/MS-DOS.
The same action returns an error in VB/Windows. For example, if a form
has one control named cmdExit, this code produces different results in
VB/MS-DOS and VB/Windows:

cmdExit.Enabled = FALSE
x% = SCREEN.ActiveControl.Enabled ' In VB/MS-DOS, x% = 0. In
VB/Windows,
' causes error.

In VB/Windows, Screen.ActiveControl returns an error if all the
controls on a form are disabled. In VB/MS-DOS, SCREEN.ActiveControl
returns the most recently enabled control if all the controls on a
form are disabled.

Loading Controls Passed to Procedures
-------------------------------------
VB/MS-DOS compiled programs, you cannot pass a control array element
into a procedure, then load it from that procedure. For example, the
following code generates the error "Control array element does not
exist" if executed in a compiled program:

LoadIt cmdButton(1)

SUB LoadIt (X as CONTROL)
  LOAD X
END SUB

Note that the preceding code will run in the VB/MS-DOS programming
environment without an error. This difference occurs because compiled
applications are "early bound." 

Additional query words: VBmsdos 1.00

Keywords :
Version : MS-DOS:1.0
Platform : MS-DOS
Issue type :