I'm using the RUN command to restart my program, but after the program is reset two or three times (in the same execution), Qbasic promptly 'freezes up', having no reaction to Ctrl+Break. When I try to compile the code, I get the following 'severe error':
1A80 4CCE END SUB
^ Subprogram error
Can anything be done to fix the freezeups and the compilation error? Thanks!
I don't know exactly what's happening, but you may have problems with stack. Maybe a RUN justs resets the PC (program counter), but doesn't clear the stack so your calls are still there. Using RUN to restart your program is a very bad practice, though (spaghetti!!!). You should restructure stuff in a manner that you have logic enough to restart without having to use RUN.
MYCO,
Nathan gave you some good advice. If your program isn't too large, why don't you post it so we can give you some tips on how to restructure it to avoid using RUN.
*****
I think posting a 30-kilobyte program would be kind of pointless.
Isn't there some kind of command that can be used to clear the stack or something? I really don't know very much about stack space.
I hope the problem isn't caused by nesting a lot of subs?
I could probably design a more complicated restart method that would involve several newbish techniques, but... that's just not how to do it!
Quote:...Isn't there some kind of command that can be used to clear the stack or something? I really don't know very much about stack space. ...
Yep,
Spaghetti, Spaghetti :evil:
Spaghetti code...
I would use that to describe code involving several GOTO and GOSUB commands. But would you say that nesting subs is spaghetti code? It is easier to program and read code that uses subs as valuable program size reduction and convenience (i.e. instead of seeing tons of x procedures, you see a call statement, or several scattered throughout) I also find subs useful to, more or less, simplify the main engine. It's easier to understand a CALL (sub) statement than it is to look at a bundle of several lines of code.
Correct me if I'm wrong, and show any better methods for doing this.
I'm not saying that nesting subs is spaghetti code, nor that using GOTO/GOSUB is spaghetti code.
What I say is that exitting some nested sub calls with a RUN just not to have logic to do this is spaghetti 'cause it kills your stack and can produce some weird lateral effects. I would not recommend using CLEAR 'cause in compiled code and several RUNs after the first you may corrupt your string space.
Spaghetti code is when you completely lose track on what your program is doing or in which state it is at any time.
Are you using RUN with no arguments inside a SUB? Doing that will give the subprogram error when compiling. And the IDE will fail to report it - instead it will give you a nice IDE hang-over.
Using RUN to restart a program using no arguments is not supported in a SUB/FUNCTION - only in the module-code level. You should give arguments to the RUN to use it there, or move it to the main module.
- Dav
MYCO,
Your program is 30K, and it seems that you don't have the inclination to do the following which Nathan said 10 days ago: "You should restructure stuff in a manner that you have logic enough to restart without having to use RUN".
Then I would look for an alternate solution. Why don't you write a little "parent" program which does a SHELL to your main program.
Instead of doing a RUN in the main program, just do END or SYSTEM to terminate the program, which will go back to the parent. The parent program could then ask the user if he really wants to get out or continue. If continue, it SHELLS to the main program again, giving the same effect as if the main program did a RUN.
If the "get out or continue" message bothers you, then the parent program could initially reset a little switch file. When the main program determines it really wants to get out, it sets a switch in the switch file before terminating. When the parent program sees the switch set, it exits, otherwise it SHELLS to the main program again.
What do you think? Much easier than reorganizing a 30k program.
*****