'>>> Page 3 of CODE0398.FAQ begins here.
   CALL NewSub(Name$, Text$, File$)
   NewSub Name$, Text$, File$
   However, the SUB statement you made at the very beginning
   must match *exactly* the TYPEs and number of variables in
   the calling statement:
   SUB NewSub(Name$, Text$, File$)
      PRINT Name$
      PRINT Text$
      PRINT File$
   END SUB
   Notice that if you had SUB NewSub(Name$, Text$, File%), QB
   would not be able to run your program, since the TYPE of the
   third variable wouldn't be the same in both places.  The SUB
   would be expecting an integer, but it would get a string.
   That isn't good.
   Those are the basics of SUBroutines.  FUNCTIONs are *exactly*
   the same as SUBs, with one major difference.  A FUNCTION
   returns a value to the calling procedure, and therefore must
   be used differently.  For instance:
   a! = GetANumber!
   PRINT GetANumber! * 4
   FUNCTION GetANumber!
      INPUT "Enter any number"; GetANumber!
   END FUNCTION
   This will ask for a number, ask for another number, and print
   the value of four times the second number.  Parameters (the
   variables which are passed to a SUB or FUNCTION inside the
   parentheses) work the same way here, too:
   PRINT NewName$("David")
   FUNCTION NewName$(OldName$)
      PRINT "The old name was "; OldName$; "."
      INPUT "Enter the new name:  ", NewName$
   END FUNCTION
   Notice that there is only one legal way to call a FUNCTION, and
   to use parameters when calling a FUNCTION.
   One more note:  once you save a file after creating one of
   the above examples, QB will put a DELCARE statement at the
   beginning of the program.  For instance:
   DECLARE SUB NewSub (Name$, Text$, File$)
   If you change the parameter list after this statement is
   created, you will have to edit this statement manually to match
   the new parameter list.
3) HOW CAN I PRODUCE A DELAY IN MY PROGRAM INDEPENDENT OF THE
   CPU SPEED?
   Bill White answers this question very well (edited for format):
[quote]
   In the past there has been extensive discussion in this echo of
   this subject, which brought out some problems.  A summary of
   this discussion follows:
   The old BASIC statement we used for years:
   FOR i=1 to 1000: NEXT i
   is not independent of the CPU speed.
   You could use SLEEP 2.  This, however, has problems: integer
   numbers only, user can hit _ANY_ key to jump out of it, and
   that key will be held in the buffer waiting to bite the next
   INPUT command unless dumped with DO: LOOP UNTIL INKEY$ = ""
   TIMER can be used - it ticks off 1/18.2 of a second:
   delay = 2
   finish = TIMER + delay
   DO
   LOOP UNTIL TIMER => finish
'>>> Page 3 of CODE0398.FAQ ends here. Continued on next page.
___
 * SLMR 2.0 * Windows Error #6523: Not Enough Windows Errors
--- Maximus/2 3.01
---------------