
2. Errors (Bug's)/Inconsistencies in PowerBASIC Versions 3.0, 3.1, 3.2 and 3.5 (Part 3)
Errors (Bug's)/Inconsistencies in PowerBASIC Versions 3.0, 3.1, 3.2 and 3.5 (Part 1)
Errors (Bug's)/Inconsistencies in PowerBASIC Versions 3.0, 3.1, 3.2 and 3.5 (Part 2)
2.25. The "File not found"-Error after using NAME
Versions: 3.0/3.1/3.2
Known : Error corrected in Version 3.50
There is a very strange Error in the internal PowerBASIC filehandle
management after using the command "NAME".
Example:
OPEN "B",1,"DATEI1.TMP" ' Open first file
OPEN "B",2,"DATEI2.$$$" ' Open
CLOSE 2 ' ... and close immediately
OPEN "B",3,"DATEI3.TMP" ' Open
CLOSE 3 ' ... and close immediately
KILL "DATEI2.$$$" ' Delete second file
NAME "DATEI3.TMP" AS "DATEI2.$$$"
' Rename third file to second file
CLOSE 1 ' ... Close first file
END
2.26. Calculationerror when using Constants
Versions: 3.0/3.1/3.2
Known : No
Sometimes PowerBASIC does not calculate correctly when using
constants. Of course there is the question why you don't insert the
answer right away, because it is just a matter of form.
Example:
i% = -20-4 : %k= -20-4
PRINT i% , %k
2.27. Wrong "Bit movement" with ROTATE
Versions: 3.0/3.1
Known : Error corrected in Version 3.20
The ROTATE-Command in PowerBASIC 3.0/3.1 has a Bug when using QUAD-
Type Varibles.
Example:
i&& = 1
ROTATE RIGHT i&&, 1
ROTATE LEFT i&&, 1
PRINT i&&
2.28. Overflow when using FOR/NEXT-Schleifen
Versions: 3.0/3.1/3.2
Known : No
PowerBASIC does not allow you to use the maximum value of a variable
in a FOR/NEXT-Loop. The maximum value is used internally by PowerBASIC,
because (AFAIK) first increases the variable and then checks it. As you
can see it then comes a an overflow, if the maximum value had already
been reached.
This bug occurs as far as I know on all variables.
Example:
FOR Demo? = 1 TO 255
PRINT Demo?
NEXT Demo?
Should you NOT use "$ERROR NUMERIC", this Loop will turn into an
endless loop.
This effect is caused by downward compatability to other BASIC
Compilers and the internal works of the Intel CPU.
2.29. Overflow when using STEP -1 in FOR/NEXT-Loops
Versions: 3.0/3.1/3.2/3.5
Known : Yes
In PowerBASIC all variable must be of the same type (signed/unsigned),
if they are used in a FOR/NEXT- Loop. For example, the following is
not valid:
Example:
FOR Demo?? = 10 TO 2 STEP -1
NEXT Demo??
or:
FOR Demo??? = 10 TO 2 STEP -1
PRINT Demo???
NEXT Demo???
Should you NOT use "$ERROR NUMERIC", this Loop will turn into an
endless loop.
2.30. The Bug in the VARPTR32-Command
Versions: from 3.2 on
Known : Error corrected in Version 3.5
Against the correct implementation of STRPTR32 and CODEPTR32 there is
a Bug in the VARPTR32-Command. It is not possible to do a mathematical
operation at the same time.
Example:
DIM Demo AS STRING * 10
Wert1??? = VARPTR32(Demo) + 1
Wert2??? = VARPTR32(Demo)
Wert2??? = Wert2??? + 1
PRINT Wert1???, Wert2???
2.31. The 'KEY ON' Bug
Versions: 3.0/3.1/3.2
Known : No
Listening to the PowerBASIC manual and the BASIC specifications of the
KEY- Command the 'KEY ON'- Command is supposed to show the current KEY-
Setup in line 25 similar to 'Norton Commander'. If this is the case
PowerBASIC is supposed to put out an 'Error 5: Illegal Function' if
the programmer wants to acces line 25 using LOCATE. Line 25 is also
supposed to be protected from scrolling.
This is not the case anymore since PowerBASIC V3.x (unlike PowerBASIC
V2.10)!
Example:
KEY OFF
FOR i% = 1 TO 10
READ A$
KEY i%, A$ + CHR$(13)
NEXT i%
KEY LIST
COLOR 3, 0
KEY ON
COLOR 7, 0
LOCATE 25, 1: PRINT " This text should be captured!! ";
WHILE NOT INSTAT
WEND
KEY OFF
END
DATA "Help", "Return"', "Edit", "Change", "Report"
DATA "PRINT", "Setup", "DOS", "Copy", "Quit"
The question here is wether this is a bug in the PowerBASIC manual or
in the Compiler. In any case you can fix this using:
2.32. Crash of the PowerBASIC IDE in the Pick- Menu
Versions: 3.0/3.1/3.2/3.5
Known : No
The PowerBASIC IDE crashes when you press DEL instead of RETURN the
first time you chose the menu "File\Pick". If you have opened "Pick"
before with the RETURN- Key in the same session, this error will not
occur. Personally I think this is a very serious error, because both
keys are very close on the keyboard.
2.33. Crash of the PowerBASIC IDE with faulty Syntax
Versions: 3.0/3.1/3.2
Known : Error corrected in Version 3.50
The PowerBASIC IDE crashes if you try to compile the following line:
PRINT Test1$ XOR Test2$ XOR Test3$
I'd rather not discuss the function of this line. {g}
2.34. Error when swapping variables using SWAP
Versions: 3.0/3.1/3.2
Known : No
When using the SWAP-Command in connection with TYPE-Structures and
indexing a fiels using a variable ("a(c%).x" for example) the fields
will not be swapped correctly. If the field is accessed with a
constant ("a(1).x" for example) this does not occur.
Example:
TYPE SwapTest ' Userdefined Datatype
x AS INTEGER
y AS INTEGER
END TYPE
DIM a(1 TO 2) AS SwapTest ' Create Array
c% = 1
d% = 2
a(1).x = 1 ' Init Fields
a(1).y = 2
a(2).x = 3
a(2).y = 4
CLS
PRINT "before SWAP: "; a(c%).y, a(d%).y
SWAP a(c%).y, a(d%).y
PRINT "after SWAP: " ; a(c%).y, a(d%).y
2.35. The Multiplexer Interrupt Error in the REG-Command
Versions: 2.x/3.0/3.1/3.2
Known : Error corrected in Version 3.50
Astonishingly there are even problems when you call the Multiplexer-
Interrupt &h2F using the REG-Command. Normally it seems that the call
was refused by the system. A test using the Inline-Assembler on the
other hand works fine. This was seen when programming MSCDEX, checking
for the Windows-Version and using Timeslice-Functions of the Multiplexer-
Interrupt.
The only way around this is to use the Inline-Assembler.
Example:
! mov ax, &h1680
! int &h2F
! mov Taskfreeing%, ax
Taskfreeing% = Taskfreeing% AND 255
SELECT CASE Taskfreeing%
CASE &h80 : PRINT "Taskfreeing not supported"
CASE &h0 : PRINT "Taskfreeing supported"
CASE ELSE : PRINT "Unknown value"
END SELECT
REG 1, &h1680
CALL INTERRUPT &h2F
Taskfreeing% = REG(1)
Taskfreeing% = Taskfreeing% AND 255
SELECT CASE Taskfreeing%
CASE &h80 : PRINT "Taskfreeing not supported"
CASE &h0 : PRINT "Taskfreeing supported"
CASE ELSE : PRINT "Unknown value"
END SELECT
The explanation of this lies within the working routines of the REG-
Command, although QuiBASIC does not have these problems. {g}
2.36. Contents of a Directory will be deleted with KILL
Versions: 3.0/3.1/3.2
Known : No
One can find a nice feature behind the KILL-Command of PowerBASIC.
Should the path end with a Backslash (without other Wildcards or file
names), the entire directory will be deleted.
Example:
KILL "C:\TEMP\" ' Deletes all files in the TEMP
' Directory
2.37. The thing with the "USR" string
Versions: 3.0/3.1/3.2
Known : Error corrected in Version 3.50
A completely strange behaviour can be noticed in the IDE or the
Command Line Interpreter if the string "USR" can be found in the
source code. Because the compiler crashes in the first example, this
can definetly be considered a Bug.
Example:
PRINT USR ' PB/PBC crashes
Test% = USR ' Error 477
2.38. The GOTO DWORD Bug
Versions: 3.2
Known : Error corrected in Version 3.50
PowerBASIC simply forgets the Segment part of the address, that's all.
Example:
Demo??? = CODEPTR32(TestLabel)
GOTO DWORD c???
$SEGMENT
TestLabel:
PRINT "Test"
END
2.39. The 'ON LOCAL ERROR' Bug
Versions: 3.0/3.1/3.2
Known : Error corrected in Version 3.50
Using 'ON LOCAL ERROR' in a PBU can cause a crash of the program.
Example:
'Main file
$COMPILE EXE
$LINK "TEST.PBU" 'or PBL
FileName$ = "TEST.DOC"
CALL ResumeDemo(Demo%)
PRINT "Error", Demo%
END
'Unit file
$COMPILE UNIT
SUB ResumeDemo (Demo%) PUBLIC
ON LOCAL ERROR RESUME NEXT
' To test create this File with WinWord and save once.
OPEN "TEST.DOC" FOR BINARY AS #1
Demo% = ERRTEST
END SUB
2.40. ... and again 'ON LOCAL ERROR'
Versions: 3.0/3.1/3.2/3.5
Known : No
PowerBASIC crashes when someone uses "ON ERROR" instead of "ON LOCAL
ERROR" in a SUB/FUNCTION. It can come to STACK or STRING memory
problems in this case, if the error occurs.
Of course this is definetly the error of the programmer, but the
Compiler should recognize this when compiling.
2.41. Runtimeerror in the PowerBASIC Helpcompiler
Versions: 3.0 (Helpcompiler)
Known : No
The Helpcompiler (Encoder) seems to have quitr a few Bugs. Mostly
beginners will have some problems with Runtimeerror 9 at address
10095. This is an internal Bug of the Helpcompile, which is caused by
the missing of the Command '/LOOKUP'.
2.42. The Error "Truncating" in the PowerBASIC Helpcompiler
Versions: 3.0 (Helpcompiler)
The Error 'Truncating ... to 76 characters' will be shown sometimes,
because the commandcharacters will not be taken into concern.
2.43. Crash of the PowerBASIC-IDE after calling its own Help
Versions: 3.0 (Helpcompiler)
When programming or actually the writting of the Help you will have to
watch out that the effective length of the shown textline are not
bigger than the actually existing number of characters available in
the PowerBASIC-Helpwindow, because the PowerBASIC-IDE will in that
case crash with a graphical error.
This Bug will only occur in the developmentphase of a self-written
Helpfile (*.PBH)!
Errors (Bug's)/Inconsistencies in PowerBASIC Versions 3.0, 3.1, 3.2 and 3.5 (Part 1)
Errors (Bug's)/Inconsistencies in PowerBASIC Versions 3.0, 3.1. 3.2 and 3.5 (Part 2)