Your funciton definition is not having a RETURN statement, therefore it returns .T., as that always is the implicit RETURN, if you don't program one:
Code:
PARAMETERS total
spent = total
[COLOR=#888A85]RETURN .T.[/color]
I just added the RETURN .T. as "ghost line". If you don't have a return before it, that's what any function, procedure or also method and a whole prg file returns to a caller.
What this function does before returning .T. is setting a private variable spent, to whatever was passed in as parameter named total, and this spent variable is immediately released again, if it doesn't preexist before calling the function, so that is a prerequisite of using the function. Otherwise the function is very useless, though it doesn't error in that case. It then creates the private variable spent, as it doesn't exist, but immediately releases it, as it returns and at that stage all local variables and all private variables created at this stack level are released.
As a short test simply execute this:
Code:
? total(1)
? spent && will error!
spent=1
? total(2)
? spent
function total()
parameters total
spent=total
This will print .T. as the result of total(1), then error with Variable 'SPENT' is not found. Answer with IGNORE and it'll continue and print .T. once more for the second total() call and 2 for the spent variable. So you see what I said earlier, in the first call the spent variable shortly existed , but was released, before the test code printed it. In the second call it existed set to 1 and is set to 2, still exists and so was changed by the function.
This function does not total given values at all, it just echoes them in the specific variable spent, which must be predefined, though. I don't know who got this idea and how it should help you, but it's clear your usage fails, as it always returns .T. and you try to add .T.+"fulln:" and that errors, as you can't add a boolean/logical type value and a string. Even others failed to see this and said your erroring code line would add a numeric value to a string, no it doesn't. This just shows just reading code leads to wrong conclusions and even just executing code as it is doesn't give you a chance to see what is wrong. In case other code is called, you need to incorporate it and test it.
You can always see what some function does and returns by using it
out of the context of non functioning lines, simply call it itself via some simple
test code. As you do so you see this function returns .T. and you can most probably understand that a string can't be added to this, for example. Normally code is having much more lines and in that case it's best to even just execute it in "slow motion" line by line in the debugger. A break point or SET STEP ON will start the debugger and there you can use F8 to execute just one line or use some of the toolbar tools. In short: Learn how to use the debugger, it helps you understand code. It's most often some earlier code leading to an error and not just the line causing the error message.
Bye, Olaf.
