I need to debug a skills assessment program which I have
written in Quick Basic so it functions properly once compiled.  So
far, I have run the program without problems from within the Quick
Basic interpreter but when I compile it and try to run the
executable file -- it fails completely.

Background

     The program works by asking the user to respond to three
different questions presented in random order times about twenty-
five types of skills, ca. 75 questions in all.  Each of the user
responses is given a numerical value which is stored in an array
called the response tabulation array.  Upon answering the final
question, the program does some calculations and then presents the
final analysis on the screen.  The glitch resides somewhere in the
module that reads the data for each question from an ASCII file and
presents it on the screen.  The questions are stored in an ASCII
text file from which they are read one-by-one into a special user
defined type.  The text for each question contains the question
number, the skill number and the question itself.  The skill number
is never seen by the user.  It is used to direct the user response
to the proper element of the response tabulation array.

The Problem

     As I have stated above, the program work perfectly so long as
I run it in Quick Basic interpret mode but when I compile the
source code and try to runt the executable file the questions will
not come up properly on the screen.  Most of the time the first
line or so is missing from the question but just as often, I just
get a screen full of gibberish.

My Attempts At Trouble-Shooting

     1.   I checked the source code for any typos.  This seems
          unlikely because the program does run in interpreter
          mode.

     2.   I checked that the ASCII data file and the executable
          files were in the proper directory.  They were.

     3.   I filtered the ASCII data files in case some rogue but
          unseen character made its way into the files.  This
          produced no change.

     4.   I tried compiling it to run with and without the BRUN
          file.  Still no improvement.

     5.   I thought  it might then have something to do with my
          computer's operating system.  My current computer is a
          P2/400 running under Window 98/E2.  I ported all the
          files to my old computer -- a 386/25 running under DOS
          5.0.  Again, my program works perfectly when I run it in
          Quick Basic interpreter mode but when I compile and
          attempt to run the executable file, I have the exact same
          problem.

     6.   In short, I am getting nowhere fast on hyperdrive.

Conclusions

     The only conclusions I cam come up with are:

     1.   My copy of Quick Basic is somehow corrupted.  However,
          this should not be because I obtained my copy legally
          from Microsoft and I am not running a pirated copy, or,

     2.   There is some, possibly undocumented, special
          modification of the source code that needs to be done
          before my program will run in compiled mode.

     It is my fervent hope that the problems rests with the second
conclusion and that perhaps someone here can offer a solution where
I have failed.

     I am aware that one solution would be to use DATA statements.
My hope, however, is to be able to re-use the same engine to assess
different sets of data without needing to return to the source
code, re-write all the DATA statements and re-compile for each set
of data.

     Below, you will find what I believe to be the pertinent parts
of the Basic source code.

     I thank you all in advance for your time and help with this
problem.

David Solly

TYPE TSkill
  SkillName AS STRING * 25
  SkillNumber AS INTEGER
  D1 AS STRING * MaxString
  D2 AS STRING * MaxString
  D3 AS STRING * MaxString
  D4 AS STRING * MaxString
  D5 AS STRING * MaxString
  D6 AS STRING * MaxString
  D7 AS STRING * MaxString
  D8 AS STRING * MaxString
END TYPE

TYPE TQuestion
   QuestionNumber AS INTEGER
   Q1 AS STRING * MaxString
   Q2 AS STRING * MaxString
   Q3 AS STRING * MaxString
   Q4 AS STRING * MaxString
END TYPE

' An array to hold the 27 skill descriptions

DIM SHARED SkillInventory(1 TO MaxSkills)  AS TSkill

' An array to hold the survey questions

DIM SHARED questions(1 TO MaxQuestions) AS TQuestion

' An array to hold the scores for each skill

DIM SHARED Scores(MaxSkills, 2)

[.....]

SUB PrintSkill (A)

  Centre (SkillInventory(A).SkillName)
  PRINT
  'PRINT SkillInventory(a).SkillNumber
  PRINT TAB(Ind); SkillInventory(A).D1
  PRINT TAB(Ind); SkillInventory(A).D2
  PRINT TAB(Ind); SkillInventory(A).D3
  PRINT TAB(Ind); SkillInventory(A).D4
  PRINT TAB(Ind); SkillInventory(A).D5
  PRINT TAB(Ind); SkillInventory(A).D6
  PRINT TAB(Ind); SkillInventory(A).D7
  PRINT TAB(Ind); SkillInventory(A).D8

END SUB

SUB PrintQuestions (A)
  IF A <= 57 THEN
     PRINT TAB(30); USING "Question Number ###";
questions(A).QuestionNumber
  ELSE
     PRINT TAB(30); USING "Question Number ###";
questions(A).QuestionNumber - 2
  END IF
  PRINT
  PRINT TAB(Ind); questions(A).Q1
  PRINT TAB(Ind); questions(A).Q2
  PRINT TAB(Ind); questions(A).Q3
  PRINT TAB(Ind); questions(A).Q4

END SUB

Try reducing the size of some of the arrays to reduce the amount of memory
the program requires.  Then compile and run.

This may be the problem, but I suspect what I will suggest in a moment.
Arrays are limited to 64K per array unless you use /AH; and even then, if
the array is >128K, the array element size must be a power of two, which
your UDTs may not be.

The IDE does some "helpful" things for you with arrays when running there.

But what I really suspect is: there is a KNOWN bug using the TAB statement
in a procedure (SUB of FUNCTION) : it destroys the passed parameter.

You use:
SUB PrintSkill (A)

   Statements with TAB referring to A
END SUB

In this sub, A may be getting corrupted.

You can check it with some PRINT print statements . If this is the problem,
the solution is simple:

SUB PrintSkill(B)
 DIM A AS INTEGER
  Let  A = B
 (Rest of code as it is now).

..
END SUB

--
Michael Mattias
Tal Systems
Racine WI USA

    Thank you for your reply

    MaxString is 66.  That is quite small and there should be ample of room for
it.  As far as I know, I am not using the /AH option.  What is the advantage of
using it?

    Believe it or not, I was able to get the program to compile a operate
properly after I put the two sub routines into the mainline program.

    What is the bug with TAB?  Is there a patch to fix the compiler or is it
something that one has to live with?

    Thank you for your time and trouble.

David Solly

ftp://ftp.microsoft.com/developr/basic/kb/index.txt

(Yes, "developr" not "developer")

Under kb, the articles are calatoged as subdirectories; e.g.:
Q103680 BUG: BC Defaults to /Lp in Windows NT So Use /Lr as Workaround
  ..is at ftp.microsoft.com/developr/basic/kb/103/6/80.txt

The one you are interested in is:

Q41536 PRINT TAB Can Change Value of Parameter in Subprogram

Microsoft has not published QuickBASIC since 1990; there are no updates.

--
Michael Mattias
Tal Systems
Racine WI USA