I'm new to this forum, but have used the last version of microsoft Basic for many years (the compiler boots with "QBX" as the command, whatever version that is). programs and subroutines have grown to the point where it is essentially impossible to run from the editor without getting an Out of Memory error. I like to run from the editor because it's far easier to debug than waiting to compile first and then executing. I have discovered that simply breaking large subroutine modules into more and smaller modules has helped, but there is essentially no insight into a method that is more direct and predictable. Is there any way to break up the modules that makes sense out of the process? is there a way to tell is the excess size is in the mainline program or in one of the subroutine modules? I just now tried to move some of the mainline code into an "Include" file, but it doesn't help. Any thoughts on how I can improve this situation? Thanks for your time.
JJ
Out of memory errors running from editor
Moderators:Administrator, Global Moderator
-
JackLJohnson
- Newbie
- Posts:1
- Joined:Mon Jul 10, 2017 6:16 pm
Re: Out of memory errors running from editor
I do not know exactly what your difficulty is, but I understand that you have problems with extremely long programs, and therefore there are errors of lack of memory.
Whenever I develop long programs (programs) I fragment into smaller programs specific to each function and provide a menu so that the user can choose each specific activity as needed. When a particular activity requires many operator-independent operations, I make the program fragments navigate from one to the other via the "RUN" command line (example: IF X < 0 THEN RUN "DEBIT.EXE" ELSE RUN "CREDIT.EXE "), Or through the" CHAIN "command line, or through the" SHELL "command line. In the case of the SHELL command, the called program can contain the command "COMMAND$", where we can pass information parameters to the next called program.
Example:
The PROG-A.EXE program is created
CLS: PRINT "My name is"; : SHELL "PROG-B.EXE John"
Then the program PROG-B.EXE is created
A$ = COMMAND$: PRINT A$
When executing the program PROG-A.EXE, it will print the first part of the sentence, and will call the PROG-B that will print the passed parameter: My name is JOHN
In the case of calling programs with the RUN command, the information exchange should be through files, preferably random, where each program leaves the file updated and closed before calling the next program.
If the files are not closed with each call from another program, it will cause a buffet overload.
Calls with "SHELL" leave the previous program on hold until the called program finishes. In this case the common files must be opened in shared mode.
Example:
BUF1% = FREEFILE
OPEN "GEIC.RND" FOR RANDOM SHARED AS BUF1% LEN = 4
FIELD BUF1%, 4 AS CNTRL$
Whenever I develop long programs (programs) I fragment into smaller programs specific to each function and provide a menu so that the user can choose each specific activity as needed. When a particular activity requires many operator-independent operations, I make the program fragments navigate from one to the other via the "RUN" command line (example: IF X < 0 THEN RUN "DEBIT.EXE" ELSE RUN "CREDIT.EXE "), Or through the" CHAIN "command line, or through the" SHELL "command line. In the case of the SHELL command, the called program can contain the command "COMMAND$", where we can pass information parameters to the next called program.
Example:
The PROG-A.EXE program is created
CLS: PRINT "My name is"; : SHELL "PROG-B.EXE John"
Then the program PROG-B.EXE is created
A$ = COMMAND$: PRINT A$
When executing the program PROG-A.EXE, it will print the first part of the sentence, and will call the PROG-B that will print the passed parameter: My name is JOHN
In the case of calling programs with the RUN command, the information exchange should be through files, preferably random, where each program leaves the file updated and closed before calling the next program.
If the files are not closed with each call from another program, it will cause a buffet overload.
Calls with "SHELL" leave the previous program on hold until the called program finishes. In this case the common files must be opened in shared mode.
Example:
BUF1% = FREEFILE
OPEN "GEIC.RND" FOR RANDOM SHARED AS BUF1% LEN = 4
FIELD BUF1%, 4 AS CNTRL$