QBasic commands that do not work in SUBsMay 25 2004 at 1:27 AM
|Earthborn (no login)|
FAQ025 = Why does (you name it) only work in Main and not SUBs?
I don't know why, but the fact is that the following can only appear in your main module:
This command would not be useful in SUBs as it declares SUBs to the main program.
An old command to define functions. Exists only to keep compatibility with GWBasic, Basica
ON ERROR GOTO label
Error handling. It does work in SUBs, but the label must exist in the main program. If it is in the SUB itself it will not even find it and give an LABEL NOT DEFINED error. Only QB7 has the ON LOCAL ERROR GOTO error handling that does work within a SUB, which is tremendously useful but makes a program incompatible with other versions of QB.
ON TIMER GOSUB/GOTO label
ON PEN GOSUB/GOTO label
ON STRIG GOSUB/GOTO label
ON PLAY GOSUB/GOTO label
ON KEY GOSUB/GOTO label
ON COM GOSUB/GOTO label
Event handling. It works in SUBs but the label must exist in the main program. If it is in the SUB itself it will not even find it and give an LABEL NOT DEFINED error. There is no ON LOCAL Event GOSUB/GOTO in QB7.
Defines what the first element of an array should be by default. You have the choice between 0 an 1. Fairly useless command. Instead define the first element of the array explicitly when you DIM it in the SUB: DIM Array(0 TO 10) or DIM Array(1 TO 10)
Sets a user defined data TYPE. Very useful for database applications and programs that use complex groups of related data. It is a pity that it doesn't work inside SUBs, because it might be very useful to make SUBs that have their own data types.
Used to define unchanging data in an 'internal file'. It doesn't work inside SUBs for no good reason, but can be substituted by strings. SUBs can however contain the READ command to read the data, as well as the RESTORE command to get start over at the beginning. Remember however that it always reads the data sequentially. If the SUB calls another SUB that also reads from DATA lines, it will might resume reading from where the other SUB left off.
The following program will make this clear
Similarly the other SUB can the RESTORE command to read from a different data block effecting where the original SUB reads its data from.
It might have been useful if different SUBs could read from DATA lines without affecting each other, but unfortunately this does not work.
I recommend using strings to store data in most cases and using string functions to extract from it. Numbers stored as hexadecimal values might save a bit of space also.
|This message has been edited by iorr5t on Jun 11, 2004 7:20 AM|