Microsoft KB Archive/94824

= COMPAT.TXT for Visual Basic for MS-DOS 1.0 =

PSS ID Number: 94824

Article Last Modified on 1/8/2003

-

The information in this article applies to:


 * Microsoft Visual Basic for MS-DOS 1.0

-



This article was previously published under Q94824



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, &quot;Building Portable Applications,&quot; in the &quot;Programmer's Guide&quot; for more comprehensive information on this subject.

Differences in Scope

In VB/MS-DOS, shared array declarations cannot be &quot;eclipsed&quot; 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 &quot;eclipses&quot; 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: &quot;;&quot;, &quot;:&quot;, or &quot;\&quot;. 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. &quot;=&quot;) 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 = &quot;&quot; and File1.Pattern =  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 &quot;Control array element does not exist&quot; 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 &quot;early bound.&quot;

Additional query words: VBmsdos 1.00

Keywords: KB94824

Technology: kbAudDeveloper kbVB100DOS kbVBSearch kbZNotKeyword3

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© 2004 Microsoft Corporation. All rights reserved.