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 recreate 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 = 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 VB/MS-DOS, but not in VB/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."