INTERMEDIATE PROGRAMMING TIPS (PART 1), by Alex Warren · alexwarren@writeme.com
I hope this will become a fairly regular feature of the fanzine, designed to help those programmers who have only been programming in BASIC for a little while to improve their programs.
The trouble with the term "intermediate" is that it is rather vague - in this series I'll classify an "intermediate" programmer as one who can make a program and knows the really basic things such as file I/O, simple graphics, etc., and would like to make their programs better (faster, more user-friendly, easier-to-read, or whatever else a "better" program is)
I'm not sure how many parts this series will have, nor what it exactly it will cover - if anyone has any ideas or would like to donate a tip or two, please feel free to send some in.
Anyway, are you sitting comfortably? Then I'll begin.
TIP 1: VARIABLES AND USER-DEFINED VARIABLE TYPES
This is two tips in one really...
We all know what a variable is (I hope) and we all know that they come in several delicious flavours - strings, integers, long integers, and floating-point variables, for example, which each have their own uses. As a programmer, you should know the best circumstances in which to use each variable type as there are differences between them in terms of speed and in what they can store.
Obviously, a string is pretty much self-explanatory, and you would never (I hope) use it to store a number (other than a phone number etc. which would need formatting). It is up to you to decide when to use the other types of variable. By default, BASIC will choose a floating-point variable if you don't specify which type the variable is going to be, and this will really slow your program down if it is doing a lot of calculations that don't require that kind of precision. If your variable is never going to store anything with a decimal point, declare it to be an integer and it will work more quickly.
If you're lazy, the easiest way to make BASIC use integers by default instead of floating-point variables is to stick
DEFINT A-Z
at the beginning of your program. Better though, would be to explicitly state the variable type, and you can do this in two ways:
integ% = 3
would set an integer variable called "integ%" to 3, as you should know. Or, you could use:
DIM integ AS INTEGER
integ = 3
This would set an integer variable "integ", without a percent sign, to 3.
Which method you choose is up to you - if you have a large program it may be better to use the second method as then you will be able to change the variable's type by changing one word, without having to go all through the program changing the % signs to # signs, or whatever.
Integers are the fastest variable types but they have disavantages. Apart from the obvious fact that they can't contain anything with decimal places, they also cannot store numbers greater than 32767 or less than -32768. (if you try to set integ% to 40000 you get an "Overflow" error). If you need bigger integer numbers, use a long integer. This can hold values from -2,147,483,648 to +2,147,483,647 and takes up twice as many bytes of memory as a short integer, and therefore will be a bit slower.
The various variable types, their limits and their memory requirements should be discussed in more detail in the help file or manual for your particular flavour of BASIC.
Visual Basic for Windows adds a few more flavours such as a Boolean one, which can be either True or False, and a Variant, which can be just about anything. If you have a BASIC compiler that is more modern than QuickBasic, you should have a few more too, such as a currency type for example - have a look through the types which are available, and see which types will suit your data best.
"User-defined" variable types are very useful. These are basically blocks of other variables all stuck together. The following code shows an example of their use:
TYPE persontype
thename AS STRING * 50
phonenumber AS STRING * 20
numberofhouses AS INTEGER
salary AS LONG
height AS SINGLE
END TYPE
DIM people(5) AS persontype
people(1).thename = "Bill Gates"
people(1).phonenumber = "1234-567-890"
people(1).numberofhouses = 353
people(1).salary = 500000000
people(1).height = 1.96
(All figures made up, in case you hadn't guessed... though maybe they aren't all that far from the truth <g>)
As can be seen, a variable called "people" of type "persontype" is created, with five elements. This only needs to be done once - so you don't need to DIM arrays for thename, phonenumber, numberofhouses, etc., and it can be clearly seen from the code that the phonenumber and salary are related to the same thing (in this case, our old mate Bill). This is more readable than setting phonenumber(1)="1234-567-890" and height(1)=1.96, etc., for example.
It also has the advantage that we can quickly, easily and efficiently copy all the data to another person or record. If you add the line
people(2) = people(1)
and then read the value of people(2).salary, you will see that all five pieces of data have been copied with this single statment. This is ever so much easier than having five statements such as numhouses(2)=numhouses(1) which would have been necessary had we not used user-defined types. So, as you can see, user-defined types can make life a lot, lot easier, especially if you are dealing with large amounts of data. They're also useful because you can pass them to functions - much easier than passing each element to a function. In VB5 you can also declare functions to return user-defined data types, though I don't think this is possible in QB. Anyway, as you can see, user-defined TYPEs are a powerful tool which will make your code cleaner, easier to code and easier to understand. Use them!
TIP 2: SCREEN PAGE SWAPPING
Ever tried making some graphics animation in your BASIC code only to find that it flickered so much it gave you a migraine? No? Then you were one of the lucky ones...
Seriously though, flickering doesn't look nice and it happens when you clear the screen, draw a graphic, clear it again, draw it again, etc. - all that clearing becomes really obvious and looks terrible. However, there is a way round it, which is screen page swapping, as 12-pswap.bas will show you.
What this code does is draw seven pages of spectacular graphics action (well, lines and dots) into seven pages of video memory, completely hidden from view. It then instantly switches between them - no flicker, no waiting for the screen to draw - the page just pops into view.
If you examine the code you'll see the secret behind this trickery is some extra numbers given to the SCREEN statement. The first number is the mode number which you usually use with the screen statement. The third and fourth numbers control the "apage" and the "vpage" respectively. The "apage" is the one that LINE statements, PRINT statements and in fact any statements that draw to the screen will be sent to. The "vpage" is the one the user will see while all this is going on. (The second number in the SCREEN statement can be safely ignored - just stick a space there instead). So, if you draw all the stuff to the apages and then flick through the vpages, the pages that were drawn pop up instantly.
This technique is very useful for animation. The easiest way to use it for animation is to use something like:
cpage% = 0
DO
SCREEN 7, , cpage%, 1 - cpage%
' insert code here to draw screen
cpage% = 1 - cpage%
LOOP
This will alternate between the pages; whenever page 0 is displayed, page 1 is being drawn to, and then vice versa. The 1-cpage% bits are a useful shortcut - because 1-0=1 and 1-1=0 - so they return whatever cpage% "isn't", without the need for writing IF statements such as IF cpage% = 1 THEN cpage% = 0, etc.
Look in the help file for more information on screen pages. Screen 7, as used in the demonstration program, can use up to 7 on a VGA or better monitor. Screen 13, unfortunately, only has room for one, so page swapping is not possible directly from QB code, even though a modern SVGA monitor has several times the 256K memory that one screen 13 page will use. There are probably interrupts that will let you do it... perhaps this could be the subject of a future article.
That's all for part 1 of my "Intermediate Programming Tips" series - if anybody can think of anything they'd like me to cover in future parts, please let me know - address at the top of the page.