Quoting Steve Legg to All:
SL> As you can see, I had omitted the returned type of the function
SL> in the function definitions, and they should have read as follows:
SL> FUNCTION Trim$(BYVAL StringContents AS STRING) LOCAL AS STRING
SL> FUNCTION GetNCWord(BYVAL NCBlock AS STRING, BYVAL Letter AS STRING) LOCAL
SL> AS STRING
SL> This raises a couple of other questions though.  Other than the obvious
SL> Trim$ name and the AS STRING type declaration of one of the functions,
SL> what redundancies exist in what I've done?
None. The PB function declaration, which requires the type of return
value, is very much like C and Pascal.  This is precisely what you
would want and expect from forcing declarations on in your program.
SL> What precisely does the LOCAL keyword do in a function definition?
It declares that any variables contained in the function are local
to that function; they are not recognized by the main program or
any other function.  Of course, you can then set any variables
within the function as SHARED on a case by case basis.
SL> How many of you actually leave the full array/variable declaration
SL> requirement on _ALL_ the time?  Under what conditions might you turn it
SL> off?  It seems to be a bit of a pain to keep all that stuff in line for
SL> what many of you will consider to be a trivial program.
I normally don't do it, but I'm normally writing programs for myself.
It has tremendous value, however, when debugging a function or when others
have to maintain your code because it =forces= structured programming
techniques.
SL> And on a slightly different PowerBASIC topic ...
SL> What does PowerBASIC do with constants when they're declared?  I know
SL> that it's possible, though undesirable, to have two *variables* of two
SL> different types called (for example) Nuts$ and Nuts#.  This seems to be
SL> impossible if you've turned on the full variable checking, because you
SL> can't declare them this way.  Please correct me if I'm wrong.
SL> Now, as I understand it, PowerBASIC declares named constants by
SL> preceding the "variable name" with the type, something called an
SL> "equate."  If I declared a constant called %TRUE, which I obviously might
SL> use as the integer representation of a boolean flag, must I also
SL> use %TRUE throughout the body of the program when evaluating some
SL> expression relationship to %TRUE, or can just TRUE be made to suffice?
The "%" preceeding the name of the variable creates a named constant.
but the constant has to reduce to a numeric. It won't work with a
STRING variable.
 * WCE 2.1G1/2081 * 
--- WILDMAIL!/WC v4.12 
---------------