Unofficial FAQ 2.0 2/

 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
Outer Court
Echo Basic Postings

Books at Amazon:

Back to BASIC: The History, Corruption, and Future of the Language

Hackers: Heroes of the Computer Revolution (including Tiny BASIC)

Go to: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Scientists and Iconoclasts who were the Hero Programmers of the Software Revolution

The Advent of the Algorithm: The Idea that Rules the World

Moths in the Machine: The Power and Perils of Programming

Mastering Visual Basic .NET