BBS: Inland Empire Archive
Date: 03-21-93 (12:53) Number: 203
From: QUINN TYLER JACKSON Refer#: NONE
To: ALL Recvd: NO
Subj: Unofficial FAQ 2.0 2/ Conf: (2) Quik_Bas
>>> Continued from previous message
A1.2 As a GW-BASIC programmer, you HAVE heard of definable functions,
so this is a good place to port your previous experience. Sort of
a starting point where you can advance from. A GW-BASIC programmer
probably has used a structure similar to this in his programming
career:
100 DEF FNArea (radius) = 3.14 * radius ^ 2
Then, rather than putting the whole calculation in the code
every time the programmer wants the area, he just puts:
200 Circle = FNArea(10)
A more advanced GW-BASIC type might have even done this:
100 DEF FNFactorial (number%)
105 Temp& = 1
110 FOR i% = 1 TO number%
115 Temp& = Temp& * i%
120 NEXT i%
125 FNFactorial = Temp&
130 END DEF
This second approach is the kernal that the more advanced FUNCTION
starts with. The trouble with DEF type functions, sometimes called
in-line functions, is that their variables belong to the whole
program. Temp& and i% end up with unpredictable values that may
alter other sections of the program. For this reason, the FUNCTION
was introduced. The syntax is quite similar:
FUNCTION Factorial& (number%)
Temp& = 1
FOR i% = 1 TO number%
Temp& = Temp& * i%
NEXT i%
Factorial& = Temp&
END FUNCTION
Notice the similarities in the declarations, and also the subtle
differences. First, Factorial& is not prefixed with the cumbersome
FN of GW-BASIC style functions. Second, the data type declarator at
the end of Function& tells us that the FUNCTION returns a long
integer. Third, and more subtle than these, is the scope of the
variables Temp& and i%. Once the line END FUNCTION is encountered,
it is as if those variables never existed in the program. Being
local to the FUNCTION, they cannot interfere later with any other
case of Temp& or i%. That is the beauty of the FUNCTION over the
in-line GW-BASIC type function.
The SUB, or subprogram, is identical to the FUNCTION in every way,
except that it does NOT return a value in the way a FUNCTION does.
Whenever the SUB is invoked, all of its parts are executed, and then
the next line after the invocation are executed. Sort of a detour,
and sometimes likened to the standard BASIC GOSUB. Therefore,
FUNCTIONS are used to calculate values and return the results,
and SUBs are used to do something that is fairly standard to
the program. For example:
SUB testprint (Text$)
PRINT Text$
END SUB
This SUB doesn't return a value, but it does PRINT out Text$.
Some C programmers who have converted to BASIC, being used to
C's function-only structure, might do this:
FUNCTION testprint (Text$)
PRINT Text$
testprint = LEN(Text$)
END FUNCTION
There are times when such an approach is helpful, for example,
when there is the possibility of an error occuring, and the
programmer wants to detect it before advancing to the next segment
of the program:
FUNCTION testprint (Text$)
IF LEN(Text$) = 0 THEN
ErrorCode = -1
ELSE
PRINT Text$
END IF
testprint = ErrorCode
END FUNCTION
This example could be used to determine whether or not a null had
been passed to it, since it might be undesirable to go any further
had a null been printed, or whatever.
A quick rule of thumb to follow for GW-BASIC programmers:
FUNCTIONs are like DEF FN....
SUBs are like GOSUB....
Q1.3 So, I've cleared that up in my head pretty well. I've even taken
the time to read the docs and have a pretty good idea of the new
things QuickBASIC and its cousins can do for me. But, what is this
LINKING with .OBJ files, and LIBRARIES, and things like that? I've
no idea, even after reading the docs what this is all about.
A1.3 You are not alone. Probably the biggest jump you'll ever hurdle
when you advance from the older BASICs is the .OBJ file and the
wonder of libraries. Think of a these as a collection of
SUBs and FUNCTIONS that have been precompiled and are first
converted into .OBJ files, and then stored together in packages
called libraries. Rather than recompiling the routines every time
you need them, you store them and use them when a program calls for
them. That is another beauty of local variables: these .OBJ
routines do not interfere with your variables, and so are what is
known as protected in some programmers' jargon. As isolated
entities, they live their own life without getting in the way of
your code. Always there in the library for you to look up and
use when you need them, but never overbearing.
Q2.0 Commonly Requested Routines:
Q2.1 I'm writing a data entry program for my boss, and I am feeling
VERY limited by the INPUT and even the LINE INPUT statements.
First of all, they just plain don't look nice. Secondly, and
most importantly: if I only need 30 bytes for the employee name
field of my variable, so why should I allow the user to enter in
90, and screw up the pretty data entry screen I've built? I need
an INPUT replacement that allows me to have an inverse entry
field, while allowing all the standard editing keys, and limiting
the length, and even the types of characters the user can enter.
A2.1 Every BASIC programmer ends up having to deal with this issue.
Some third party add-on libraries come with prebuilt INPUT
replacements. VBDOS and family have forms, which eliminates this
problem altogether when the forms are being used. However, if
you want to think the issue through, here is a guideline:
1. FUNCTION or SUB?
Well, you want it to return a value, right? That's
what FUNCTIONs do best. Let's write a FUNCTION, then.
2. Parameters to pass the FUNCTION:
Well, you want to be able to specify:
a. length and location of entry field,
b. fore and back color of entry field,
c. characters accepted by entry field.
3. Other considerations:
>>> Continued to next message
