BillSoo

[Editors Note: The following article was graciously submitted by AIO - Bill]
Quick Basic to Visual Basic Conversion
By AIO

I spent a few years in QuickBASIC (QB) before jumping to VB1 (aka VBDOS), VB3, VB4, and now VB6. In the past 2 months of being a member of this great community, I have seen questions concerning conversion of QB to VB (particularly version 6). I felt motivated to write this handy guide on QB conversion to VB not only by the stimulating suggestion of BillSoo but also by the thought of sharing this unique but fading knowledge. I also find it compelling to have this reference to which I can return before the knowledge is completely gone. It has started to fade just over a year ago when I retired the last QB program I created and maintained.

Converting QuickBASIC programs to Visual Basic (QB45 & VB6)

Keywords

The first step perhaps is to check QB codes for keywords that have been lost or incompatible with VB. The following are QB keywords that are either not supported by VB or are being used in different context, or, have become properties/methods of some VB objects (and therefore could not stand as an independent statement).

$DYNAMIC, $INCLUDE, $STATIC, ABSOLUTE, ALIAS, AUTO, BLOAD, BSAVE, CHAIN, CIRCLE, CLS, COM, COMMON, CONT, CSRLIN, CVD, CVDMBF, CVI, CVL, CVS, CVSMBF, DATA, DEF, EDIT, ERDEV, EVENT, FIELD, FILS, FRE, INKEY, INP, IOCTL, KEY, LIST, LLIST, LOAD, LOCATE, LPOS, MERGE, MKD, MKDMBF, MKI, MKL, MKS, MKSMBF, OFF, OUT, PAINT, PALETTE, PCOPY, PEEK, PEN, PLAY, PMAP, POINT, POKE, , PRESET, PSET
READ, RENUM, RESTORE, RUN, SADD, SAVE, SCREEN, SEG, SETMEM, SHARED, SIGNAL, SOUND, STICK, STRIG, SWAP, TROFF, TRON, UEVENT, USING, USR, VARPTR, VARSEG, VIEW, WAIT, WINDOW.

Examples of defunct keywords are DATA, DEF SEG, SWAP, etc. One example of keywords now used in different context is CLS -- use on screen by QB, now applies to forms and picture boxes. PSET and CIRCLE are examples of QB keywords that became members of VB objects (picture box)

Code Sequence/Flow

In QB, program codes should proceed from default settings, through declarations/prototyping section, then, the program entry and the main program (that will include procedure calls) and finally, the "END". Following the termination procedure are codes for Subs and Functions.

In VB, it's either starts with a form or a "sub main" in one of the modules. It will depend which one will be specified in the Startup Object of Project Properties. There is no single specific location or sequence where a VB program should start.

Copying, at least a large portion of, QB codes to VB will require dropping the Sub/Function prototyping. Prototyping (required in QB) is only used in VB when making external calls like those to the Windows API. The main program will most likely be located in either the "sub main", the MDI form, or in a startup form (unless the startup form is a flash screen). Most Subs will likely end up in different forms or standard modules. All Subs and Functions are global in QB. When converted to VB, careful attention must be taken to identify Public and Private subs/functions that will reside in standard modules or in forms.

Program Chain

"Chaining" is usually used for large QB programs to overcome the very limited memory available in MS-DOS. This has become obsolete in VB. Consider putting all chained programs into one project (single and bigger program)

Mouse/Keyboard Input

The biggest difference between QB and VB is that the former is procedural and the latter, event driven. This will cause major changes in QB to VB codes.

QB doesn't directly support Mouse functions. It uses DOS services through Interrupt calls to support the Mouse. In VB, while you cannot directly call Interrupts, the Mouse is not something to worry about most of the time. All that is needed is to simply watch out for events such as click, double-click, move, etc, which are very easy to do. In some instances, we don't even have to code it.

Intercepting keystrokes also requires rewriting of codes. QB's Inkey$ function will not work and was replaced by KeyPress, KeyDown, and KeyUp events. VB's keyboard handling is far easier than QB's.

Screen Handling

All screen handling codes in QB will not apply in VB. QB's primary keywords in screen handling are SCREEN (mode), CLS, LOCATE, & PRINT. In VB, LOCATE is lost and CLS and PRINT are used in different context. Screen modes became obsolete in VB because, being a Windows app, it is always in graphics mode. The screen resolution is controlled by the operating system (Windows) rather than by the application program.

In addition, we seldom use codes for screen handling in VB. Instead, we usually "draw" controls and manipulate their properties. This is what makes Visual Basic a "Visual" programming language.

For graphics and graphic arrays, screen pages (active page, visual page) are now obsolete, thanks to picture boxes and perhaps, overlapping image boxes for some animation.

Error Handling

Error handling is the same, but since LineID is always local to Sub in VB, possible conflict in names is now easy to track down. In QB, LineIDs are global, therefore we must always be careful with names or we might end up handling the correct error at the wrong place.

Direct Memory Access

VB can not access memory directly. So if we have DEF SEG, PEEK, POKE, VARPTR, and similar memory access functions in QB code, better look for an alternative. Consider putting everything in regular variables.

Arrays

QB array size is limited to 64k per array. If more than 64k is needed, the usual approach is to create several blocks of arrays and write a function that handles the correct block and index pointers. In VB, the limit is the size of available memory. We need only to deal with one array if we need one.

The good news is, we can, most likely, copy this code (or "approach") from QB to VB without much change. But be sure no one else will see the code because they may just laugh at the way we "complicate" array handling.

Printing

VB uses the Printer object to communicate with the system printer for printing.

This is a tip. The information is not documented by Microsoft so let's just test it: QB's way of communicating to printer through LPT1 opened for output is still being supported by VB.

File Access

QB relies heavily on Random Access, Binary Access, and Sequential Access methods of maintaining database/files. All these are still supported by VB. Therefore, almost all QB codes ported to VB on file access should work well without re-writing and without much problem.

Objects/Classes

During my initial stint with VB4 (when objects were introduced) I did not easily jump into this "craze". I thought, why should I bother myself with objects when I was able to create programs without it?

Two years later, I was forced to learn classes/objects because I inherited a program that used it. When I learned it, I realized my folly of not learning it earlier. Objects make my projects a lot easier to maintain and understand. Later, I ended up re-writing lots of code to make use of Objects/Classes.

I suggest therefore, before converting QB codes to VB, learn OOP first. You won't regret the time you'll spend on it. I'm sure you will end up much wiser deciding which codes from QB you just copy to VB and which codes should be re-written.

__________________
"^!|=AIO=|!^"