Using RUN with No Argument Inside SUB Should Cause Error (48398)

MORE INFORMATION

Normally, the RUN statement with no argument restarts the current program. However, using RUN with no argument to restart a program is allowed only in the module-level code of a program, not in a SUBprogram or FUNCTION procedure. In a SUBprogram or FUNCTION procedure, you must use RUN <filename>, since RUN <linenumber> and RUN with no argument are not allowed in SUBprograms. However, you can use RUN <filename> to have a program run itself from within a SUBprogram or FUNCTION.

The appropriate use of RUN is correctly documented on Page 367 of the "Microsoft QuickBasic 4.0: Basic Language Reference" manual:

Because a line number in a RUN statement must refer to a line in the module-level code, only the RUN "filespec" form of the statement is allowed in a SUB or FUNCTION.

The above correct statement should replace the incorrect statements described further below.

Documentation Error

The RUN <linenumber> option is incorrectly documented on Page 317 of the "Microsoft QuickBasic 4.5: Basic Language Reference" manual for version 4.50 and on Page 303 of the "Microsoft Basic 7.0: Language Reference" manual for Basic PDS versions 7.00 and 7.10. These pages give the following incorrect statements:

Therefore, a RUN statement in a SUB or FUNCTION procedure must point to labels at module level. If no line label is given, execution always starts with the first executable line of the main module.

This same documentation error occurs in the QB Advisor online Help system for QuickBasic 4.50 and in the Microsoft Advisor online Help system for Basic PDS 7.00 and 7.10 and can be found as follows from within the QB.EXE environment or QBX.EXE environment:

Press SHIFT+F1.
Select Index.
Type R.
Double-click the left mouse button on "RUN statement" or position the cursor on "RUN" and press ENTER.
Select Details.

Program #1

Program #1 below correctly causes a "Subprogram Error" during compilation with BC.EXE 4.00, 4.00b, and 4.50, but the QB.EXE or QBX.EXE editor fails to give you an error message, and the RUN executes:

   ' **** PROGRAM #1: Test.Bas
   ' Main level (module level):
   PRINT "Inside Main Level"
   CALL Test
   ' Subprogram level:
   SUB Test
   PRINT "Inside Test"
   RUN
   END SUB

Program #2

Program #2 below is the correct method for using RUN (with a <filename> argument) in a SUBprogram, and it works when the program is either compiled with BC.EXE or run in the QB.EXE or QBX.EXE editor:

   ' **** Program #2: Test.Bas
   ' Main level (module level):
   PRINT "Inside Main Level"
   CALL Test
   ' Subprogram level:
   SUB Test
   PRINT "Inside Test"
   RUN "Test"   ' This is legal for both QB.EXE/QBX.EXE and BC.EXE
   END SUB

Program #3

In QB.EXE or QBX.EXE, your program may hang if the RUN statement is invoked with no parameters (or with a line number) in a non-STATIC SUB or FUNCTION procedure, and the SUB or FUNCTION procedure uses DIM or REDIM to dimension a dynamic array local to that procedure:

   'Warning!!!!! This program is going to hang your machine.
   DECLARE SUB sub1 ()
   sub1
   END
   SUB sub1
      DIM y(1)
      y(1) = 1
      PRINT y(1);
      ' Note: Invoking ERASE Y before the RUN will prevent the hang.
      ' Must then press CTRL+BREAK to stop the program, since it keeps
      ' running itself.
      RUN

   END SUB

You can change Program #3 to run successfully without hanging in QB.EXE/QBX.EXE if you do one of the following:

ERASE the local dynamic array(s) before the RUN.
Make the SUB STATIC.
Make the array global by dimensioning it with DIM SHARED or COMMON SHARED at the module level of the program.
Pass the array as a parameter to the SUBprogram.