Try this demo:

by (Login burger2227)
R

 
Say this is one program:

CLS
PRINT "HELLO WORLD"
PRINT
LINE INPUT "TYPE 1 TO CONTINUE: "; A$
IF A$ = "1" THEN CLS: SLEEP 1: RUN
SYSTEM

To break it into two modules, you do this:

COMMON SHARED A$
CLS
PRINT "HELLO WORLD"
PRINT
CALL INPUT1
'_______REM THIS IS MAIN MODULE 1 "MODULE1.BAS"


DECLARE SUB INPUT1()
COMMON SHARED A$

SUB INPUT1
LINE INPUT "TYPE 1 TO CONTINUE: "; A$
IF A$ = "1" THEN CLS: SLEEP 1: RUN
END SUB

SYSTEM
'_______REM THIS IS MODULE 2 "MODULE2.BAS"

Compile them each with BC command from the QB dir:

SHELL "BC MODULE1.BAS /O/S/E/X;"
SHELL "BC MODULE2.BAS /O/S/E/X;"

Then, link them both together as "MYPROG.EXE"

SHELL "LINK /E MODULE1+MODULE2,MYPROG.EXE,,BCOM45.LIB+QB.LIB"

The main thing to remember is to use something like COMMON SHARED to pass the variables and
that both modules must contain the same exact COMMON SHARED variables in the same order. I
usually just copy and past from the main module to all others to insure that this is done
correctly. You can DIM in the modules independently, if the variables will not be shared.
You can duplicate labels and line numbers from one module to another.

You can trap errors in the Main Module or in each module. If you use the Main Module only to
trap errors, your only problem will be in tracing an error. If the error occurs in another
module, the closest a resume next statement after an error break will get is to the call line
in the Main Module to the other module routine. I like to put an ER1 as my error handler in
each module. Other than that, just call all subs from any module to any other module in the
same way. What you really end up with is just a larger program. I have written code up to 301K
in 6 modules this way.

I would recommend just taking one or two areas of your present program that are in:

1) A gosub.

2) A sub.

3) A separate function, like a print routine.

Cut that area of code out and save it as module2.bas or what ever you want to call it.
Save the cut-down program as the name it has now or call it module1.bas. Try and compile
what is left. If it is still too big, cut some more, etc.

You can continue to use the QB IDE this way:

1) OPEN your main program as usual (It is now the smaller, cut-down version.)

2) Use LOAD from the File tab to LOAD the module2.bas module on top of your main program.
Now, both programs are in the IDE and will run as usual.

You can experiment with the code I provided. Just save 1 as module1.bas and 2 as module2.bas.
OPEN module1.bas and then load module2.bas. Run the IDE and it will work. Then, try to compile
each and link it as myprog.exe.

It's a bit difficult; however, once you get used to it, you will enjoy 5 times the coding limits
you now have in QB.

Please respond with any further questions in this thread if you get stuck and also, I did give
you a shell example to compile and link, but you can just drop the shell part a use a DOS prompt
if you want.

Pete

Posted on Sep 30, 2011, 9:21 AM

Respond to this message   

Return to Index

Response TitleAuthor and Date
Definitions File [NUL.DEF]Docfxit on Sep 30
 Get a better download here: on Sep 30
  QB64 vs. QB71Docfxit on Sep 30
   It appears QB71 is a later versionDocfxit on Sep 30
    The naming/numbering would suggest that, but it isn't on Sep 30
     QB64 is 32 bit in Windows because it can still run 32 bit on Sep 30
     Great explanationDocfxit on Sep 30
      QB64 doesn't need a certain size file or memory on Sep 30
      Re: Great explanation on Oct 1

 Copyright © 1999-2014 Network54. All rights reserved.   Terms of Use   Privacy Statement