Announcement

**Michael Mattias** · 25 Aug 2005, 07:34 PM

1. No STOP. No SYSTEM. (SYSTEM = end program) (SYSTEM also makes no sense in QUickBASIC, because that's compiled code.. when the program ends it does a 'SYSTEM'. "SYSTEM" only makes sense in an interpreter, like QBasic). (Come to think of it the same is true of STOP, isn't it?).

2. Others will disagree, but IMO trying to do verb-for-verb, function-for-function conversions from MS-DOS code to Windows code is a stone loser. Appendix B of the PB/CC (3x) help file is "Upgrading from DOS". I'd start there.

**Greg Lyon** · 25 Aug 2005, 07:38 PM

John,

1) EXIT FUNCTION in the PBMAIN function.

2) The converters I have seen are for converting files with line
numbers to files without line numbers ie. GWBASIC to QuickBASIC
or later. I think the best way to convert QuickBASIC to PBCC
is to try and compile the QB program and deal with any problems
manually.

------------------
Greg

**Richard Angell** · 25 Aug 2005, 07:40 PM

Some converters ... http://www.powerbasic.com/files/pub/pbwin/tools/
If you need to strip line numbers and convert GOTO XXXX to a GOTO LabelXXXX format I might post a utility for that, but was planning on putting in the Source forum later after some more testing.

See ON ERROR and the many error handling features im PB/CC for how to branch on a failure and make some sense of it ... hopefully. Probably a better way to go than STOP was.

I don't recall the STOP and SYSTEM commands, tooooo long ago for me, and my nephew has the program and manuals so some one else will need to comment on those specifically. However from the help file, Appendix B:

SYSTEM

The SYSTEM statement is no longer supported. To prematurely end your application, you must call the EXIT FUNCTION statement from within your PBMAIN or WINMAIN function, or jump to a label which is located before the END FUNCTION in PBMAIN or WINMAIN.

------------------
Rick Angell

[This message has been edited by Richard Angell (edited August 25, 2005).]

**Michael Mattias** · 25 Aug 2005, 08:04 PM

STOP was (and still is, in QBasic) the "stepping debugger" for interpreted BASIC.

Instead of "set breakpoint" you inserted a STOP statement. When STOP gave you control, you could inspect or modify variables with "PRINT X" or "LET X=20." Then you resume your program from where you STOPped with "CONT" ("Continue")

It's all coming back to me, nooooowww....

**William Johns** · 26 Aug 2005, 10:51 PM

When I was a new user of PBCC I wrote a conversion
program from QBasic to PBCC. Maybe it would be of use
to you as well. It translates most of the commands.
PBCC doesn't have equivalent commands in some cases
(such as computed GOTO, computed GOSUB, POP returns).
The program flags these so you can hand-translate them.

From the PowerBASIC website main screen:

click on DOWNLOADS

PB/WINDOWS

TOOLS&UTILITIES

The program is CONVERT.ZIP 31 Dec 2003 11kb

You re-name your Qbasic program with the extension .TXT
When you run CONVERT.EXE the result is your program name.BAS

If you run it, tell me if it worked for you or what
went wrong. I will help you with it. [email protected]

------------------

**John Braden** · 3 Sep 2005, 10:04 AM

Thanks to the replies. Yes, there is a difference of opinion.

STOP Command
Without speaking for PowerBasic (at which I am new), the STOP command in the original Basic language carried a line identity response so that the user could see where in the program the stop occurred.
When teaching programming with Basic, the STOP command was extra-ordinarily useful in
quickly locating the break point in a program (for teaching, this is vital because of time constraints) and was and is equally applicable to
interpretive basic as it is to compiled basic. EXIT Function does not operate the same way
and in this case, function has been lost. However, it appears that if we adopt PB/CC for teaching,
it may be the only choice we have, unfortunately.

SYSTEM command

EXIT Function is not equivalent to the SYSTEM command. The SYSTEM command carried two
characteristics that have apparently been lost in using the EXIT Function structure.
The first is that SYSTEM did a direct exit to the operating system environment regardless of where you were in your program.
EXIT Function, however, exits only the current function. To put it another way, it is a reverse tree walker, and will only exit to the operating system environment
if it is located in PB/WIN Main. Secondly, SYSTEM also was a memory release and a full file closing command. Base on the PB/CC documentation, neither of
these functions are operative in PB/CC, so again, I am faced with diminished capability.

CONVERTER Program.

I did download the converter program and ran it with some interesting results. Initially the program kept blowing out XP with an offer to send Microsoft a message.
After experimenting with the settings, the problem occurred because the matrix for variables was too small. (some programs we use are rather significant in size with
equivalently large numbers of variables. Most of the variable definitions were handled but a couple are causing problems with the PB/CC compiler (not a fault of the converter).
The converter changed the majority of variables to DIM statements whereas I had been hand changing them to STATIC statements. Not sure what the difference is,
but thank you, William Johns, for the program. Saved a lot of time.

------------------

**Richard Angell** · 3 Sep 2005, 10:21 AM

John,

Please look at the END command in PB_CC help file. END [nErrorLevel&]

As you are noting there are differences in Windows vs. interpreted DOS progams. PB_CC, the more you learn of it, has sufficient functionality to consitute moste of the functionality you want. The STOP command only makes sense in interpreted situations. Also PB's optimizing compilers do not allow tracking individual source lines for errors. Instead, you will need to add ON ERROR, and related error trapping code to your program in order to trap errors in particular sections of your code.

------------------
Rick Angell

[This message has been edited by Richard Angell (edited September 03, 2005).]

**Barry Erick** · 3 Sep 2005, 10:27 AM

You are working in Windows. When a PB/CC / Win program ends, it
releases memory. All you have to do is exit the main function.
And you can set some variable in a function to exit that function
and to know the main function has to end.

First, STOP converting to LEARN windows programming. Look at stuff
in the SAMPLES folder. Know how to move around in the program. The
commands you are trying to use are OLD and not supported and there
was many ways around the stop. System is not anything you need in
a compiler.

Once comfortable with PB and Windows programming, you can convert your programs.
Don't just change keywords here and there. Re do the entire programs
and get rid of line numbers and massive goto's to jump around code.

------------------

**John Braden** · 3 Sep 2005, 10:57 AM

OK, now the CLEAR command. It used to be that a CLEAR with no parameters set all numeric variables to zero and all string variables to null.
It was used as a 'best practices' to assure that nothing was hanging around in memory that might affect the program (that is, the variables are at a known state).

Any idea what the equivalent function in PB/CC that assures null strings and variables might be?

Also, I converted a small program using the converter and cannot get the compiler to handle it.
The snippet is here:

#DIM ALL
FUNCTION PBMAIN () AS LONG

DIM VR$()
DIM VR() AS LONG

VR(3)=0 ' set date TO ok TO start

END FUNCTION

The compiler stops on the DIM VR() definition and states
"Duplicate name Definition VR". The same problem occurs when
I attempt to use STATIC.

I cannot find any keyword in PB/CC that would cause the conflict.
Any ideas?

Thanks in advance.

John Braden

------------------

**Michael Mattias** · 3 Sep 2005, 11:14 AM

There is no "CLEAR everything" function.

RESET may be used to set variables and arrays to their default values.

If you want, you can restart a program fairly simply...

Code:

FUNCTION WinMain

   Yadda, yadda, Yadda

   Z = SHELL ("thisprogram.exe")  'launch new instance
END FUNCTION  ' and end this one

**Richard Angell** · 3 Sep 2005, 11:16 AM

CLEAR does not have a direct equivalent, as Barry points out memory is usually released at program terminations. Additionaly LOCAL variables in a Function are release when the function is completed. That said, you should look at the RESET and ERASE statments for discrete usage in your program.

As to the snip. An array must be dimensioned before use with the subscrips ranges.

The statments:

DIM VR$()
DIM VR() AS LONG

are not complete. Personally, I'd avoid using VR for both. even though you are using a type specifier. You are unlikely to overload PB with too many variable names.

DIM VR(10) AS LONG will set aside loactions 0 to 10 for storage of string
DIM VR(1 TO 10) AS LONG will set aside loactions 1 to 10 for storage of string

However there are other permutations of the DIM comand, so reviewing the help on that is needed. FOr example,
DIM arry(1 TO 10, 1 TO 10) AS STATIC LONG

Then most beneficial to look into REDIM, REDIM PRESERVE, LBOUND, UBOUND, ERASE as they apply to arrays.

Then look at the ARRAY commands, like ARRAY SORT / SCAN/ DELETE / INSERT and ARRAYATTR. A good understaning of PB's column major ording of arrays is indispensible to grasping the power of these comands. Also may fine the MAT command of use for number crunch and special tasks.

Later as you review the use of TYPES and UNIONS in PB, you may also find use for DIM ..... AT address useful.

------------------
Rick Angell

[This message has been edited by Richard Angell (edited September 03, 2005).]

**Michael Mattias** · 3 Sep 2005, 11:28 AM

Also on CLEAR: Not necessary when program starts; nothing will be 'hanging around' as the compiler automatically intializes variables when program starts (documented).

**Michael Mattias** · 3 Sep 2005, 11:31 AM

>Also PB's optimizing compilers do not allow tracking individual source lines for errors.

TRACE will show all labels as encountered (line numbers=labels)

CALLSTK will show the "procedure (function or sub) path which got me where I am"

**Richard Angell** · 3 Sep 2005, 11:51 AM

Michael,

line numers <> lables for TRACE use.

Code:

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
   TRACE NEW "test.txt"
   TRACE ON
THESTART:
   100 LOCAL A$
   200 LOCAL B$
   300 A$ = "HELLO"
   400 B$ = A$
   500 TRACE PRINT "B$ = "+B$
THEEND:
   TRACE OFF
   TRACE CLOSE

END FUNCTION

The result is:

Code:

  Trace Begins...
  THESTART
  B$ = HELLO
  THEEND

In the help file seciton on Writing Progams in PB/CC, see the Line numbers and Labels topic. Since a label must begin with a letter character, it is recognized by TRACE. Line numbers, are not, in its "relaxed" sense PB just ignores them.

------------------
Rick Angell

**Richard Angell** · 3 Sep 2005, 12:06 PM

john,

i was going to wait on some other activities, but seems like will not be adding to a line number stripper/jump label making program i recently wrote. if you can use it, here is the link:
http://www.powerbasic.com/support/pb...ad.php?t=24688

------------------
rick angell

**Michael Mattias** · 3 Sep 2005, 12:07 PM

I never read that section of the help file that carefully.

After a bunch of explanation of the differences between labels and line numbers, why then are we treated to this summary sentence?

Line numbers are essentially labels.

Perhaps someone sent a boy (er, make that a "programmer") to do a man's (er, make that a "writer's") job.

But back on point.. my error re line numbers appearing in TRACE.

**Richard Angell** · 3 Sep 2005, 12:32 PM

Yah, I saw that too ... but the same interpretation did not make it into the TRACE command, nor its' help listing. My surmize would be that the compiler can hook a defined line number, but not so for a plain old line number. That said, I suppose that someone could revise all the line numbers to lablels by inserting "A" before the line number and ":" plus a line feed carriage return after to put them on their own lines ... that would be a bit ridiculous ...but might do the trick for TRACE ... the compiler might not be too efficient though since it might tend to defeat optimization.

------------------
Rick Angell

**Greg Lyon** · 3 Sep 2005, 05:48 PM

There's always the RemLine program that came with QuickBASIC. It
strips line numbers that are not needed and leaves the ones that
are required. I was able to modify it to compile with PBCC. It's
real handy for converting old GWBASIC programs.

RemLine

------------------
Greg

[This message has been edited by Greg Lyon (edited September 03, 2005).]

**Donald Darden** · 4 Sep 2005, 07:28 PM

I think a real problem for people who have used GWBASIC, QBASIC,
and QUICKBASIC is the frustration in thinking, "Hey! this worked
for me before! What's wrong with PowerBASIC that it doesn't
understand a simple BASIC command?". The idea that you have to
relearn old skills just to write simple programs is frustrating.
But saying that it is "Unfortunate" that you have to switch to
PB/CC is probably not true, as the Windows environment and the
added capabilities of both PB/CC and PB/WIN will put power at
your fingertips unlike anything you've used before.

I remember, coming from GWBASIC, that I once thought that line
numbers were an essential part of programming, else how was I to
know where I was in the program? But a full scrollable, always
on-screen view of the program showed me that you could follow the
sequence of entered instruction now, and you had a color shift to
show you where the execution point was in the program sequence.
Suddenly, line numbers were just excessive, because they were not
necessary.

Line numbers have been superceeded by lables, but can be still
considered as a form of lable, intended for much the same use.
However, lables can be named, making them more meaningful and
understandable. They let you name SUBs, FUNCTIONs, jump points,
ans Subroutines for easy recognition, using whatever naming
convention you want, and can be placed in any order that is
convenient for you. SLine numbers were limited to identifying
the order and replacement of entered lines of text.

The ability to use STOP and STEP were primitive efforts at
givning you a debugging mode for checking program execution.
Now you have a full feature Debugger mode, so you can watch
variables and registers, track program execution, set breakpoints,
step into lower level code, over lower level code, or directly
out of lower level code, reassign values to variables on the fly,
animate (slow execute) a program sequence, identify where an
error occurred, identify what the error code means directly, and
so on.

PowerBASIC wants to enforce better type control over the use of
variables. If you insist on writing in the old format, then it
wants you to at least include a type symbol to identify which
variable form is being referenced. So if you want a VD$, VD%,
VD#, VD##, VD&, [email protected], [email protected]@, or [email protected]@@ you can, but what's the point?
All it does is obscure the meaning or use of the variable. It's
not like you can't choose variable names like Address, City,
State, ZipCode, Phone, Rent, Mortgage, Interest, Tax, SubTotal
and Total to use. These should convey a whole lot more meaning.

But if you use #DIM ALL, then you force yourself into the new
mode, where you then declare the variable with a GLOBAL, LOCAL,
DIM, or THREAD statement. Then you are free to use it without
the attached type symbol. The supposed downside is that a
given variable name will thereafter be associated with that
type, so you no longer are allowed to have a VD$ and a VD& at
the same level in a program. However, an exception exists with
LOCAL variables, which in this case might allow you to have a
VD$ at the GLOBAL level and a VD& at the LOCAL level, but note
that you cannot reference VD$ at the level where VD& has scope.

In this matter and in other ways, PowerBASIC is much richer a
development environment over what you had with QuickBASIC.

The only thing I found in QBASIC and QuickBASIC that is not found
in PowerBASIC is the ability to create statements on the fly that
used program variables and functions as though you were in
command mode, but it is easy enough to incorporate new statements
into PowerBASIC source code and rerun to the point where the
added statements are executed and see the results.

You also now have the ability to call up $INCLUDE files directly,
work with dynamic link libraries (and make your own with PB/WIN),
examine and call COM components, use inline Assembler code without
having to create it separately and load it with BLOAD or via
included DATA statements, program into virtually unlimited memory
(so you don't have to worry about subdividing a large program
into a number of overlapping modules that each need to be loaded
and run separately), and have a great many data types and file
formats to choose from in planning your projects.

So if you are thinking, "Gee, this move to PB/CC was a bad
choice", then I think with a bit of time and effort, you will
find those thoughts to be a bit premature. For most of us, the
compilers provided by PowerBASIC are our premier development tools,

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

Announcement

Equivalent keywords and converters

Equivalent keywords and converters

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment