Scroll SUB Action Scrolls the defined area. Syntax Scroll row1%, col1%, row2%, col 2%, lines%, attr% Remarks Scroll is used in WINDOW.BAS to scroll an area within a defined window. The Scroll procedure uses the following arguments. row1%, col1% ------------ An integer pair that specifies absolute screen row and column coordinates. row2%, col2% ------------ An integer pair that specifies the lower-right corner coordinates of an area. lines% ------ An integer that defines the scrolling behavior that occurs within the defined area. If lines% is less than 0, the area scrolls down by that number of lines. If lines% is greater than 0, the area scrolls up by that number of lines. If lines% is 0, the defined area is cleared. attr% ----- An integer in the range 0 - 7 that defines the color to fill any newly created blank lines. See Also. WindowScroll Compatibility with Microsoft QuickBASIC for the Macintosh Every effort has been made to retain a high degree of compatibility between the functionality in the User Interface toolbox and that which exists in QuickBASIC for the Apple Macintosh. Many programs from the Macintosh platform can be readily converted for use with the PC. However, there are some limitations that you should be aware of. Programs that use graphics windows on the Macintosh cannot be converted because this user interface package is text (character) based. Programs that use event trapping on the Macintosh must be converted to polling before conversion can be effected. Each Macintosh QuickBASIC window command has a functional counterpart in the User Interface toolbox. Often a Macintosh QuickBASIC command has more than one function. Where this is true, there may be more than one corresponding procedure for QuickBASIC on the PC. The following table can be used as a general guideline for converting programs from one platform to the other. Macintosh QuickBASIC PC BASIC ALERT Alert BUTTON function ButtonInquire BUTTON statement ButtonOpen, ButtonSetState, ButtonToggle BUTTON CLOSE ButtonClose CLS WindowCls COMMAND ShortCutKeyDelete, ShortCutKeyEvent, ShortCutKeySet DIALOG Dialog, WindowDo EDIT$ EditFieldInquire EDIT FIELD EditFieldOpen EDIT FIELD CLOSE, EditFieldClose LOCATE WindowLocate PRINT WindowPrint MENU function MenuCheck, MenuEvent, MenuInkey$ MENU statement MenuColor, MenuItemToggle, MenuPreProcess, MenuSet, MenuSetState, MenuShow MENU RESET MenuInit MENU ON MenuOn MENU OFF MenuOff MOUSE MouseHide, MouseInit, MousePoll, MouseShow SCROLL WindowScroll WINDOW function WindowCols, WindowCurrent, WindowRows WINDOW statement WindowColor, WindowInit, WindowOpen, WindowSetCurrent WINDOW CLOSE WindowClose Miscellaneous WindowBox, WindowLine A number of features are similar, but not exactly the same in both environments. Some of the differences are outlined below. * Buttons cannot be disabled on the PC, only opened or closed. * On the Macintosh, the active window may differ from the current output window. On the PC, the active window and the current window are the same. * On the PC, the Dialog(0) procedure returns 2 whenever an edit field is selected, not just when there is more than one edit field, as occurs on the Macintosh. * On the PC, edit fields cannot be centered or right justified. They are always left justified. * Macintosh MOUSE functions 3 through 6 are not implemented on the PC. * Macintosh WINDOW type 7 is not implemented in any manner on the PC. Window types are somewhat different on the PC than they are on the Macintosh. Each of the windows on the Macintosh - numbered 1 through 7 - has a slightly different functionality. The PC window types allow you to specify any combination of available features with WindowOpen, so that you have full control over the features of your PC windows. Custom window configurations, beyond the 24 basic types provided, can be created by modifying the WindowBorder procedure. A number of new or extended features have been implemented to enhance the usability of this package. These features are described as follows. * The Dialog procedure has been greatly extended to cover the full range of menu and keyboard events. * All menus are keyboard accessible by two means. Access keys (standard) are provided and shortcut keys (optional) can be user defined. * Print formatting (word wrap, centering, and so on) can be specified. * Window contents are automatically saved when windows overlap, so windows do not need to be refreshed. An exception is that a window must be refreshed when a window is resized. The programmer must ensure that refreshing occurs when a window is resized. * Buttons and menus can be toggled. * Scroll bars are implemented as button types 6 (vertical) and 7 (horizontal). * List boxes are implemented. * Field buttons (invisible buttons that occupy an area of the screen) are implemented as button type 4. One very important difference between the PC and the Macintosh lies in the use of the keyboard. On the Macintosh, the assumption is made that every computer has a mouse pointing device. This assumption cannot be made for the PC. During the evolution of text window environments on the PC, a standard has emerged that is adhered to by the procedures in this toolbox. This creates a significant problem when converting programs from the Macintosh to the PC. Keys with well defined purposes, like the Spacebar and the Tab key, actually get trapped by the routines that process keyboard input. This means that Macintosh applications that are particularly keyboard intensive will not work well in the PC Windows environment. A word processor, for example, would be abysmally slow and therefore would not be practical within a window. There are three choices available for the programmer who wants to convert such an application. * Do all the keyboard-intensive operations outside of the WindowDo procedure. The vast majority of PC window-based applications do this anyway. Then you can use windows for dialog and list boxes. This is the preferred method. * Learn how WindowDo works and customize it, or write your own WindowDo procedure to suit your needs. * Learn how edit fields and buttons operate, and create your own object type. The edit field can be extended to support multiple lines. Generally, these routines are quite flexible and can certainly add functionality to your programs, as well as conversion capability from one platform to the other.