BBS: Inland Empire Archive
Date: 03-06-92 (23:59) Number: 173
From: MICHAEL MALLEY Refer#: NONE
To: RICHARD VANNOY Recvd: NO
Subj: Heeellpp! Conf: (11) Modula-2
RV>MM>Not true Drask,
RV>THWAPPP! Another direct hit! (Laughing and picturing the
RV>cartoon character shot full of holes, with water coming out
Aw come on, lay off of Drask! He's just had a few problems saying what
it was he was trying to. I think he knows what he's talking about, he
just has a problem verbalizing it.
RV>I think I follow. Can this new module have straight code?
RV>(As opposed to a requirement for all code to be SUBs with no
Before I start to explain, I think that a few definitions would help you
to understand a little better.
Module: A source code file consisting of error trapping on a module
level, event trapping, SUB and FUNCTION procedures, sub
routines, and DEF FN functions. Module level code may also
exist in a main module. This code is in addition to the
previously mentioned items.
SUB procedure: A section of self standing code with only one way in.
Variables are local by default.
FUNCTION procedure: A section of self standing code with only one way
in. Variables are local by default. Returns a
value to the calling code.
SUB routine: A section of code that is not self standing. Variables
are global with the body of code in which it is
contained (i.e. in a module, or a procedure).
DEF FN function: A section of code that is self standing, although
variables are global with variables in the module.
DEF FNs must be in the module code and are not
shared across modules.
Main Module: The source code file that is the entry point for your
program as a whole, and generally contains the high
level control structures for the program.
There may be more than one module per program, however there can be only
one main module. Variables may be shared amongst modules by including
their declarations in a COMMON statement. This declaration must exist
in all modules. Modules, other than the main module, may not have
module level code per se, although they may have error trapping code,
procedure declarations, DEF FN function declarations, and event trapping
code. All other code in the main module will be ignored. The rest of
the supplementary module(s) is made up of procedures. An excellent use
of this feature is to move all procedures requiring error trapping to a
secondary module to decrease the amount of code overhead associated with
RV>how do you access the code? Wouldn't
RV>the END statement in BESTBBS isolate it from BESTBBS2?
In order to access procedures that are in an external module, the
declarations for that procedure must also reside in the calling module.
Since program flow does not end with the main module, but rather jumps
to the secondary modules, the END statement has no effect. A convenient
way to maintain declarations of procedures amongst modules is to keep
these declarations in a header file, and include them with the INCLUDE
RV>Lost me here! OK... I have BESTBBS in the environment and
RV>BESTBBS2 out on disk. Right? I then (L)oad BESTBBS2, NOT
RV>(M)erge BESTBBS2, and then do a Save All? If true, OK. If
To create another module with one module already in the IDE, select
Create File under the File option, and select Module in the dialogue
Let's say we have a module that contains a lot of code that we include
in a variety of programs. This module contains code for checking to see
what video adapter is present, an input routine, and routines for
dialogue boxes. The name of this module is INTRFACE.BAS. We also have
a header file that includes the necessary declarations to use these
procedures. The name of the header file is INTRFACE.BI. We want to
include this module in a program called EDITOR.BAS. To use this file
you select Load under the File option in the menus. You would then put
this line at the beginning of your active code (code that is executed
during run-time) in the main module.
This would allow your main module access to the procedures in the
secondary module INTRFACE.BAS. To insure that whenever you open your
main module, INTERFACE.BAS is also loaded, select Save All under the
File option. This will create a file with the extension .MAK. The main
part of the filename will be the same as the main module, in this case
EDITOR. When EDITOR.BAS is opened, QB looks to see if there is a file
called EDITOR.MAK. If one is found, it opens it to see what modules
should be loaded into the IDE. EDITOR.MAK would contain first the name
of the main module (EDITOR.BAS), and then the name of any secondary
Note: If you try to load a module with a procedure that has the same
name as another procedure that is already loaded, QB will return
an error saying "Tried to load module with duplicate procedure"
and will give you the name of the procedure.