Error 5.

PowerBasic Inc. programming languages

Olav
Hi,

I have this PBCC 4.04 program, which trigger error "Illegal function call",
if the 3 conditions below is met.

1:Run from the commandline prompt.
2:A parameter contains a none english letter
3:And the CONSOLE SET VIRTUAL 26,81 statement is executed.

(No problem if the same commandline is entered into the commandline box,
and the program run from within the IDE).

I should add that the commandline is pretty short(33 characters)

Using WIN/XP SP3.

Anyone any view on this?                                            
Michael
If you know it's Error 5, you should know at which line that error occurs.

This is not a like a Windows' protection fault error, which can occur 
hundreds or thousands of lines after the "real" error; trappable runtime 
errors are detected in real time.

Bear in mind that if you try to keep running after such an error, it's 
pretty much "pot luck" where something else is going to fail.. and at that 
time the error number you get will not be valid.

Off the top of my head, though, I'd take a look for an untrapped file open 
error; an OPEN which may be failing because you are not in the same starting 
directory when running from the command-line as you are when starting from 
the IDE.

That, or failure to run the program from the command line using START.
                                            
Olav
Maybe I didn't make myself understandable, but I tried to say that the error 
occurs at the line which reads "CONSOLE SET VIRTUAL 26,81"
And only at the command prompt.And only if a parameter contains a none 
english letter.

In the code below the line which prints "Hello" is never executed. This 
because the line above triggers error 5, if  the "Test.Exe" is feeded with a 
none english letter, like in

                c:\test mjølk

%Debug = 1
#COMPILE EXE "C:\Test.Exe"
#DIM ALL
#IF %DEBUG
 #DEBUG ERROR ON
 #TOOLS ON
#ELSE
 #DEBUG ERROR OFF
 #TOOLS OFF
#ENDIF

FUNCTION PBMAIN()
  LOCAL sCmdLine AS STRING

 TRY
    CONSOLE SET VIRTUAL 26,81
    ? "Hello"
    sCmdLine = TRIM$(COMMAND$)
  CATCH
    ? ERROR$(ERRCLEAR)
  END TRY

  ? "Press a key..."
  WAITKEY$

END FUNCTION


No worry about that. The program ends.



Actually I tried the START command, have never given that command a thought 
before, and that solved the problem..

Thanks for the hint!
                                            
John
That's the line I was thinking was the error ;-)
    Chances are then your ms-dos prompt your trying to run the program
from either is full-screen 80x25, or has buffers set to 80,25 or
something else not allowing a virtual screen of 81x26.... Try changing
the line to 25,80 or open a new "windowed" dos prompt and run the
program there.
                                            
Michael
There is a documented bug in Windows/XP re this.

You can read the full article at : http://support.microsoft.com/kb/105305 
...

.. but the salient part is buried in the text:

"...In the case of starting the GUI application from the command line 
without the "start" command, the standard OS handles are NOT correctly 
zeroed out, but are incorrectly inherited from CMD.EXE. When the 
application's CRT initializes, the three low I/O handles 0, 1, and 2 are 
initialized to use the three handle numbers that the application inherits 
from CMD.EXE."

This suggests (to me anyway) that whenever you are playing with the standard 
handles (eg a console program) the failure to use START to actually , well, 
'start' the program from CMD.EXE is asking for trouble. (In article it tells 
you this is not an issue when the program is started with CreateProcess()).

FWIW, the PB/CC compiler had ... thru at least version 3x (I have not tested 
with my version 4x) .. a bug or very serious design problem... a PB/CC 
program it would not correctly inherit standard handles when run as a child 
process, and you have to explicitly redirect the handles in that program 
(SetStdHandle () function).  Further, redirecting the handles this way did 
NOT affect the operation of the STDIN or STDOUT functions which continued to 
use "stdin and stdout as they were at the start of the program, ignoring any 
redirection occurring within this program."

But that's not important here. What is important is that you use START from 
CMD.EXE (either the command line or in a CMD file), and that you use 
"Start CMD.EXE [/K or /C] programname parameters" if you want to execute a 
console  or console-like program from a shortcut if running on Windows/XP. 
At least I have had no problems since I started doing that.