File-Append, Call LoginUser

Hello,

RunBasic build 2.44

I have two problems with this test program and one observation and one general question.
First the observation - If there are one or more tabs between the comment apostrophe and a statement, the apostrophe is effectively ignored and the statement is compiled.

The first problem is - what is wrong with this statement:

OPEN "ShoppersDebugFile.txt" FOR APPEND AS #DebugFile

I get the error:
Compile Error
Syntax error - OPEN "ShoppersDebugFile.txt" FOR APPEND AS #DebugFile

The second problem is - what is wrong with this statement:

CALL LoginUser

I get the run time error message from Err$ displayed in my error handler:
Message not understood: #for:produce:parameters:

The error occurred when this call was executed. The first statement in the Subroutine LoginUser was not executed.
This test program was boiled down from a MUCH larger program. I have had no problems calling subroutines with no arguments. So, I assume is has to do with the SUB name LoginUser.

And finally, the general question - Can I use a variable in a DIM statement? And can I reissue a DIM for a variable in order to change its size? I notice that there is no REDIM statement. Such as:
a = 100
DIM a$(a)
b = 20
DIM a$(b)
c = 200
DIM a$(c)

Thanks for any help!

Vance

Here is the program:

'Run Basic program GenerateShoppingList

GLOBAL TRUE
TRUE = -1
GLOBAL FALSE
FALSE = 0

GLOBAL DebugOn
DebugOn = TRUE
GLOBAL AnErrorOccurred
AnErrorOccurred = FALSE
GLOBAL ErrorMessage$
ErrorMessage$ = ""
GLOBAL LocationMarker

GLOBAL DebugFileOpened
DebugFileOpened = FALSE
'OPEN "ShoppersDebugFile.txt" FOR APPEND AS #DebugFile
'DebugFileOpened = TRUE

ON ERROR GOTO [ErrorHandler]
CALL DebugMsg "Starting GenerateShoppingList program"



'CALL GetMajorCatagoryList

LocationMarker = 13

CALL LoginUser

LocationMarker = 1

[EndCurrentProcedure]
IF (AnErrorOccurred) THEN
CALL DebugMsg ErrorMessage$
END IF

CALL DebugMsg ""
CALL DebugMsg "Program Completed"
END

[ErrorHandler]
CALL DebugMsg ""
CALL DebugMsg "Error string is " + chr$(34) + Err$ + chr$(34)
CALL DebugMsg "Error number is ";Err;", after LocationMarker ";LocationMarker
[ErrorExit]
CALL DebugMsg ""
CALL DebugMsg ErrorMessage$
[EndProgram]
END

SUB DebugMsg DebugMsg$
IF (DebugOn) THEN
IF (DebugFileOpened) THEN
PRINT #DebugFile, DATE$("mm/dd/yyyy");" ";TIME$();" ";DebugMsg$
ELSE
PRINT DATE$("mm/dd/yyyy");" ";TIME$();" ";DebugMsg$
END IF
END IF
END SUB

SUB LoginUser
LocationMarker = 12
CustomerUserName$ = ""
[LoginUser]
[ShopperHasLoggedIn]
END SUB

Hi Vance,

You've found something very interesting. It seems to be related somehow to your having branch labels inside the LoginUser sub. I will definitely let you know what's up after I figure it out. ;-)

Yes, you can use a variable with DIM. As for REDIM, it is there but it does the same thing as DIM. Perhaps we should do something about that. The only way to resize an array at this time is to make a new one and copy into it.

Thanks,

-Carl

Carl,

I assume by your response about reissuing a DIM statement that the array is newly created as cleared (all 0s or ""s).

Vance

Yes.

-Carl

Vance,

as for the first statement:

OPEN "ShoppersDebugFile.txt" FOR APPEND AS #DebugFile

Looks fine however Mike has found a bug in APPEND. Seems like it only works in lower case.

runbasic.proboards82.com/index.cgi?board=bugs&action=display&thread=886&page=1



As for the second statement:

CALL LoginUser

Looks fine until you get to the subroutine:

SUB LoginUser
LocationMarker = 12
CustomerUserName$ = ""
[LoginUser]
[ShopperHasLoggedIn]
END SUB

You have a label with the same name as a subroutine. I personally would not do that... It seems like the interpreter is confused about where to branch to. That being said, the grand master has spoken and has not said otherwise so I guess it should be allowed. I would give the label it's own unique name see if that works. Let us know how it works out.

Jack

Jack,

I did try removing the [LoginUser] label with no improvements.
As far as I can tell, it seems as if you can get away with the same name for Functions/Subroutines, [Labels] and #handles. They must all be in separate tables.

Vance

Carl,

I changed the Subroutine to a Function and the error stopped occurring. So , I guess the work around is to not use Subroutines. Use Functions instead.

Oops, that does not seem to work either. I now get an error that a label can't be found. See the complete test program below.

The statement that is causing the error is:
BUTTON #LoginUser, "Log in", [Login]

and the error is:
Error string is "Branch label not found: [Login]"
Error number is 8, after LocationMarker 12


Vance

'Run Basic program GenerateShoppingList

GLOBAL TRUE
TRUE = -1
GLOBAL FALSE
FALSE = 0

GLOBAL DebugOn
DebugOn = TRUE
GLOBAL AnErrorOccurred
AnErrorOccurred = FALSE
GLOBAL ErrorMessage$
ErrorMessage$ = ""
GLOBAL LocationMarker

GLOBAL DebugFileOpened
DebugFileOpened = FALSE

ON ERROR GOTO [ErrorHandler]
CALL DebugMsg "Starting GenerateShoppingList program"



'CALL GetMajorCatagoryList

LocationMarker = 13

Dummy = LoginUser()

LocationMarker = 1

[EndCurrentProcedure]
IF (AnErrorOccurred) THEN
CALL DebugMsg ErrorMessage$
END IF

CALL DebugMsg ""
CALL DebugMsg "Program Completed"
END

[ErrorHandler]
CALL DebugMsg ""
CALL DebugMsg "Error string is " + chr$(34) + Err$ + chr$(34)
CALL DebugMsg "Error number is ";Err;", after LocationMarker ";LocationMarker
[ErrorExit]
CALL DebugMsg ""
CALL DebugMsg ErrorMessage$
[EndProgram]
END

SUB DebugMsg DebugMsg$
IF (DebugOn) THEN
IF (DebugFileOpened) THEN
OPEN "ShoppersDebugFile.txt" FOR append AS #DebugFile
PRINT #DebugFile, DATE$("mm/dd/yyyy");" ";TIME$();" ";DebugMsg$
CLOSE #DebugFile
ELSE
PRINT DATE$("mm/dd/yyyy");" ";TIME$();" ";DebugMsg$
END IF
END IF
END SUB

FUNCTION LoginUser()
LocationMarker = 12
CustomerUserName$ = ""
[LoginUser]
PRINT
BUTTON #LoginUser, "Log in", [Login]
PRINT
PRINT
WAIT
[Login]
[ShopperHasLoggedIn]
END FUNCTION

SUB DummySub
LocationMarker = 15
DummyValue$ = ""
[DummySub]
[ExitDummySub]
END SUB

WAIT will exit your procedure immediately, you will have to make [login] a separate sub or function.

Stefan,

Let me see if I understand this:
If a WAIT instruction occurs in a subroutine/function (a) and the continuing link is to a [Label], then that [Label] must be in the main line of the program and execution proceeds from that point and is there a way to return to the statement after the original subroutine/function (a) call?
If the continuing link is to a subroutine/function (b), then execution proceeds at the beginning of that subroutine/function (b) and the return causes execution to continue to the statement after the after the original call to subroutine/function (a).

Vance

WAIT is not meant to be used that way, inside of SUBs and FUNCTIONs I mean. For a clear demonstration of how to use Run BASIC's event driven coding style have a look at the blogCSS example project which doesn't use SUBs or FUNCTIONs.

As a counterpoint, look at the runWiki example which uses plenty of SUBs and FUNCTIONs.

-Carl

So, the bottom line is:
You can not use the WAIT statement inside a Function, Subroutine or a Gosub module.

Vance

You can, but it doesn't do the same thing as it does in Liberty BASIC or Just BASIC. Is this what is confusing?

Have you looked at the examples I pointed to?

-Carl

Carl,

It seems that if you use a wait statement in a subroutine, there is no way to return to the statement immediately following the call statement without using a GOTO or some other direct link and in fact any local variables or labels become unavailable.

I did check out the suggested programs and in both cases all the wait statements are in the main line portion of the program. Never in a subroutine. The subroutines are mostly used to create the pages or do other non page related stuff.

Vance

Consider storing the values you need in globals so that your event handlers have the information needed.

That's right. The examples are not there to show you how to use WAIT in a subroutine, but to show how to deal with events in a Run BASIC program.

Subroutines can be used to handle events, and they can be used to factor code in the standard way.

Most event driven systems do not allow you to do what you're trying to do with the WAIT statement. Perhaps in a future release Run BASIC will have this ability.

-Carl