home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frostbyte's 1980s DOS Shareware Collection
/
floppyshareware.zip
/
floppyshareware
/
USCX
/
QBASICTL.ZIP
/
QB-TIPS.TXT
< prev
next >
Wrap
Text File
|
1987-02-08
|
21KB
|
492 lines
Microsoft QuickBASIC Tips
Last Update: February 1987
Copyright 1986 Ford Software
4845 Willowbend Blvd. Houston, TX 77035
(713) 721-5205
This compilation of information is protected by copyright law.
Community, non-profit computer user groups may copy and distribute
this file for local (non-mail-order) members. Any other copying
or distribution of this file is a violation of copyright law.
Ford Software offers this information as a guide to users of
Microsoft's QuickBASIC ver. 2. We do not guarantee this informa-
tion to be correct.
"QuickBASIC" is a trademark of Microsoft Corp.
Ford Software is not affiliated with Microsoft Corp.
_________________________________________________________________
The best way to use this file is to use Vern Buerg's LIST program.
(Available from the Public Software Library on disk 1-UT-274.)
LIST will let you page back and forth through the file, as well as
letting you quickly search the file for specific text.
The subjects are arranged in alphabetical order.
_________________________________________________________________
8087/80287 SUPPORT
The QuickBASIC Compiler does not internally support the 8087 or
80287 math co-processors. Several vendors which provide libraries
that can be linked with QuickBASIC to provide co-processor
support.
One company is Hauppauge Computer Works (516) 360-3827. For
version 1.X and possibly version 2.00 another company that provid-
ed 8087 support for QuickBASIC was Micro Way (617) 746-7341.
_________________________________________________________________
COMPATIBLES
Microsoft does not guarantee QB2 to run on anything but the IBM PC
and AT. This leaves out compatibles such as the PCjr, the Compaq
80386 and any other not-quite-compatibles. This applies to your
compiled programs, as well as to the QB2 editor.
Toshiba 1100 Plus
The QB2 editor's cut and paste function using the SHIFT Down Arrow
key does not work. You can delete a single line and paste a
single line but not multiple lines.
Tandy 1000
Pressing Function keys F11, F12 or Keypad keys 5,6,0 or period
cause the computer to hang when used in conjunction with the
INKEY$ statement.
Another problem is with INPUT$(1). Run the following program.
locate,,1
main:
a$=input$(1) : print asc(a$)
goto main
Press a letter key until the display is printing in the bottom row
of the screen. Now press the keyboard keys 5 and 6
simultaneously. Any keys pressed from this point on will be
displayed on the right-hand side of the screen. Using INPUT$(1)
in a program that does not print to the screen causes
unpredictable results. This is reproducible with Function keys
F11, F12 and keypad keys 0 and period.
The CAPS and NUM LOCK keys require one key stroke to turn on and
three key strokes to turn off.
It is perplexing that QuickBASIC 2.0 does not use the keys as they
are marked. The Arrow, Insert, Ctrl-Break and Home keys do not
work at all. However, Microsoft Word on the Tandy 1000 works
flawlessly.
Microsoft has said these problems may or may not be corrected.
QB2 does not work on the Tandy 2000, but does work on the 3000.
_________________________________________________________________
COMPILING
Switches
QB2 creates somewhat large EXE files than QB1 or IBM Bascom2.
The following switch settings will result in file sizes roughly
equivalent to QB1:
DEBUG OFF
MINIMIZE STRING DATA OFF
.OBJ BRUN20 (then link explicitly)
OPTIMIZE FOR SIZE
Creating a Batch File to Compile
If you have program that requires complicated switches when
compiling from DOS, put the compile command in a REMark statement
at the beginning of program. Then use a program that will read
that line and create a batch file to do the compile.
Linking
QuickBASIC can only be linked with other QuickBASIC subprograms
and assembly programs. QuickBASIC can not be linked with object
modules of other languages, such as Pascal or Fortran.
Disk Space
If you use QB2 to compile a program to disk and this disk is
filled up in the process, you are "hung". Within the environment,
the keyboard is active but nothing happens - QB2 appears to be in
a loop. When compiled externally, the message "Disk full" is
printed ad nauseum. Microsoft acknowledes this as a bug. (Infor-
mation provided by Mark Novisoff.)
_________________________________________________________________
EDITOR
ASCII Graphics
QB2 will not load a program if any of the first 64 bytes of the
program are upper ASCII codes (above ASCII 127). If you have upper
ASCII characters in your program, for such as drawing boxes on the
screen, make sure they are not in the first 64 characters.
Cut-and-Paste
The first time a line is selected with SHIFT-UP or SHIFT-DOWN, two
lines will be selected instead of one if the cursor is not in the
first column position of the screen.
Overtype Mode
QB2 does not officially have an overtype mode in the editor, but
Doug Hogarth discovered that you can force an overtype mode by
pressing the Alt-Ins keys at the same time. Be sure to experiment
with this mode before using it for real since it has some strange
side-effects.
Shelling to DOS
Some people are reporting erratic results shelling to DOS. You may
need to increase your DOS environment size and set environment
variables to indicate the location of COMMAND.COM
There is a very small default limit on environment size. Under
DOS 3.1 and 3.2, you can increase this limit by putting this
command in your CONFIG.SYS file:
SHELL=\COMMAND.COM /E:nnn
where nnn is the desired environment size. In DOS 3.2, this is
the number of bytes. In DOS 3.1, it is the number of paragraphs
(16 bytes). So, for an environment size of 512 bytes, in DOS 3.1
you would say:
SHELL=\COMMAND.COM /E:32
If your AUTOEXEC.BAT file loads in any stay-resident programs, you
should SET your environment variables *after* loading those
programs. The reason is that each stay-resident program gets its
own copy of all the environment data. It doesn't duplicate the
full possible environment size, just the amount you have actually
allocated with SET or PATH statements. So if you put those after
the stay-resident programs, you will save memory. (You can even
put the PATH statement after the programs, if you CD to the right
directory or call them up with an explicit path, e.g. \util\sk).
(Information provided by Michael Geary.)
Environment
Tom Clark, 70320,346 on CompuServe, reports:
I have encountered two serious (to me) bugs in QB2 when using
ENVIRON statements (see page 262 of QB2 manual).
1. The ENVIRON statement always returns an "Out of memory" error
when trying to add a new string to the environment table. For
example, the following 1 line program will not work unless CISE
already exists in the DOS environment table, contrary to the first
sentence in the 2nd paragraph under REMARKS on page 262: ENVIRON
"CISE=1"
2. Contrary to the second sentence in the same paragraph, the
ENVIRON statement will not change a parameter in the DOS
environment string table. From DOS, enter "SET CISE=9". Then
compile the following program to a .EXE file the following
program. Then return to DOS to run the compiled program. The
output will look like everything is ok. But then enter the DOS
SET command to display its environment table. Guess what? CISE
still equals 9.
... print environ$("CISE") ...
... ENVIRON "CISE=1" ...
... print environ$("CISE") ...
... ENVIRON "CISE=2" ...
... print environ$("CISE") ...
MICROSOFT replies:
The ENVIRON$ function only operates on a local copy of the
environment table which is used when you issue a SHELL statement
in a program. ENVIRON$ does not affect DOS's copy of the
environment table. The local environment table size is limited to
the size it is when QB or a QB program is initiated, rounded up to
the next multiple of 16 bytes. When a parameter is added or
lengthened, it is very easy to run out of memory.
Tom Clark says:
I guess that clears up the problem, except that the QB2 manual
says nothing about a "local" table. Under the subheading of
"ACTION," the manual says "Modifies a parameter in the DOS
environment-string table." MicroSoft should correct this error.
However, my suggestion would be to correct the software to be
consistent with the manual. There may still be an error in the
software. I have already expanded the DOS environment space to
its maximum in my CONFIG.SYS via the following: SHELL=\COMMAND.COM
/P/E:62.....I'm certain that I really don't even have to expand
it, unless the presence of 11 TSRs eat up the space. If not, it
seems to be that QB2 might not account for environment space that
exceeds the DOS default.
_________________________________________________________________
ERRORS
Subprogram Errors
In order for a subprogram that contains an error trap to compile
without errors using QB2, you must use "RESUME" or "RESUME NEXT"
only and compile the routine with the "/X" switch. A "RESUME
line#" causes QB2 to error (as did QB1) and not create the .OBJ
file (but QB1 would create an .OBJ file).
Move the error routines outside the SUB.....END SUB area but in
the same source module.
Out of Memory Errors
If you have less than 640k, you ought to beef up your machine.
Memory is cheap. If you have 640k, it may be that the generated
code segment is too large (bigger than 64K); and the program would
need to be split into subprograms which could be placed in a user
library or LINKed into one EXE file. In the QB2 manual, see App.D
The program could also be split into separate EXE files and
CHAINed. If you run out of memory at runtime, then too much data
is being used. You get about 58000 bytes for strings, variables,
static arrays, file buffers, and constants. In addition, each
dynamic numeric array gets its own segment of memory up to 64K.
"Bad File Number"
I have a program that runs fine if I compile in memory, or if I
compile from within QB into an .EXE file. I tried the separate
compilation method, because I wanted to be able to run from a
single .EXE file, without all the USERLIB and BRUN20 junk. When I
try to execute, I get an error, "Bad file number".
Now, the explanation of this error on p. 563 says it can
occur if a file number is "out of the range of file numbers
specified at initialization." Ted, I can't find any way to
specify a range of file numbers at initialization. I am familiar
with the /F switch in interpreter Basic, but I don't see any
similar facility in the QB manual.
Back to the program. If I compile from within QB with the
OBJ(BCOM20) option, then link the file separately, I get an
"Illegal function call' when I try to execute. Of course, I don't
have line numbers in my program, so the line number references in
the error messages just say 0.
Finding Errors
If you compile from within QB2 and there is an error, QB2 will
show you what line the error is on. If you compile from DOS, it
will not show you where the error is.
Total Errors
When QuickBASIC finds an error while compiling it stops code
generation and scans the remaining code for syntax errors, but no
other kinds of errors. So the number of errors shown as total
errors will not necessarily be correct.
_________________________________________________________________
FILES
Fielded Variables Zeroed Out
Unlike other versions of BASIC, QB2 "nulls" fielded variables when
a file is closed. For example,
10 OPEN "Testfile" AS 1 LEN=80: FIELD 1, 10 AS A$, 70 AS B$
20 GET 1,1 : PRINT A$ : PRINT B$
30 CLOSE 1 : PRINT A$ : PRINT B$
At line 20, the values of A$ and B$ will be displayed on the
screen. At line 30, Nothing will be printed because A$ and B$ are
set to null when the CLOSE is done. To retain the values, you can
use some un-FIELDed variables. Eg: add the line:
25 A1$=A$ : B1$=B$
_________________________________________________________________
MEMORY
Quick BASIC will set a 64K code segment and a 64K data segment.
So a 128K machine cannot run programs compiled with QB2, since the
operating system will take up some memory too and not leave enough
for QB2. Furthermore if you try to compile the programs on a 128K
machine most likely the compiler will run out of memory. The
recommended available RAM for Quick BASIC is 256K, which is enough
for a very small program. It is very easy to run out of memory on
a 256K machine.
The data segment limitation is for the programs and the user
libraries, the object modules as usual are limited to 64K.
Therefore, you can include several .obj files to the user library
and they are each limited to a 64K code segment.
Extended Memory
QuickBASIC does not support extended memory, but it does support
expanded memory if it follows the Lotus/Intel/Microsoft Extended
Memory Specification. There are no special procedures involved.
It will use expanded memory as it would regular RAM.
"Extended memory" is a term used by IBM to reference memory
at physical addresses above 1 Mb that can be accessed by an 80286
CPU. The Lotus/Intel/Microsoft Expanded Memory Specification is a
functional definition of a bank-switched memory-expansion
subsystem. It allows access of up to 8 Mb of memory. This should
be transparant to QuickBASIC.
_________________________________________________________________
OTHER BASICs
Advantages of Better BASIC
DATA: BYTE data type; POINTER variables; named constants; complex
data types, similar to C structures.
VERBS: a complete assortment of windowing commands; DEL$ and INS$,
for deleting and inserting strings in the middle of other strings;
direct calls to BIOS or DOS; DO UNTIL as well as WHILE; DO block
structures that cannot be improperly entered or exited with a
GOTO; EXIT and EXIT n LEVELS for getting out of a block structure
neatly.
FUNCTIONS: DRIVE$ and DIR$ that return the current drive and
directory, respectively; FREEDISK returns the number of free bytes
on a disk drive; UPPER$ and LOWER$ for case conversion; MIN, MAX,
MIN$, MAX$.
Disadvantages of Better BASIC
The company took 3 months to send an update, and 6 months,
(numerous phone calls, and downright nasty customer "service"
reps), to get a refund.
_________________________________________________________________
SCREEN
Apage and Vpage
Microsoft acknowledges a problem in the handling of Apage and
Vpage in that chaning the active page parameter does not result in
a change of the active page. A fix may be made in future versions.
Doug Hogarth (PowerSoft) 76703,374 offers this fix:
I'm not real familiar with such uses, but if someone has ways to
check functions of the SCREEN statement apage and vpage parameters
and wants to help, I have some information. I think that if you
use some utility to change the first occurance of 05 CD 10 in
QB.EXE to 05 90 90, and compile in memory, it might act more like
expected. Please let me know your results whether good or bad (my
VERY limited test was okay).
Hercules Compatibility
There ain't none!
Preventing the Screen from Clearing
It is not possible to keep QB-compiled programs from clearing the
screen when started. You can keep the screen from clearing in
compiled when chaining from one program to another by making sure
that you compile with the "/O" option in both programs.
Snow
QB2 seems to produce a lot of snow on the IBM color graphics card.
Scroll Lock Status
The Scroll Lock key and status indicator have no meaning in QB2.
_________________________________________________________________
SIDEKICK AND SUPERKEY
You must have a late version of Sidekick and Superkey to get them
to work with QB2. Call Borland Customer Support for more info
about upgrading.
_________________________________________________________________
USER LIBRARY
Using CALL ABSOLUTE
You have to do a couple of things before running QB. One is to
create a user library. To do this, at the DOS prompt enter
BUILDLIB USERLIB.OBJ
(these files are both on the QB2 distribution disk.)
The second thing is that when you run QB, you must use the /L
switch, which loads the user library into memory. The /L option
is only needed when compiling in memory, not if you are creating
an object file on disk.
Adding ASM Subroutines to a Library
If the ASM subroutines have been made into a library using a
library manager and the library has an extension .lib then when
using BUILDLIB you can do the following: BUILDLIB /l (the /L
switch will allow you to include all the library files and build
lib is going to prompt you for their names. If the assembler
routines are in .obj format you can also use the buildlib and make
it in to an .exe file which can be loaded as you invoke Quick
BASIC. If the library has been created with some other library
managers, problems can be expected when using /L switch.
Using a User Library
If you create a user library, all the routines in the library are
added to the program when you link. Earlier versions of QB didn't
have user libraries, you instead explicitly linked in any .OBJ
files that you wanted to CALL. This is still an option with QB
version 2.00.