COMMON statement

 BBS: Inland Empire Archive
Date: 05-30-92 (21:45)             Number: 154
From: STEVE GARTRELL               Refer#: 151
  To: MATT HART                     Recvd: NO  
Subj: COMMON statement               Conf: (2) Quik_Bas
* In a message originally to Steve Craver, Matt Hart said:
MH-> SC> Why can't I get this to pass the variables to another module? It
MH-> SC> works fine with the SUBS, but!
MH-> >>       TYPE colorset
MH-> >>     COMMON SHARED clr AS colorset
MH-> SC> What must the other modules contain? The full TYPE?  Thanks!

MH->In order to preserve CLR across .EXE files and
MH->SUB/FUNCTIONs, then all .BAS programs must include both the
MH->TYPE definition AND the COMMON SHARED statement.  NOTE also
   In other words, the best possible solution is to put the
TYPE and COMMON statements into a $INCLUDE file and them
include it where applicable in each module...This also
makes for less pain when you realize that, dammit, you are
going to need one more TYPE variable to pass around.
   Anecdote:  While writing a stock tracking program, (like everything I do,
it's not my "job" so it's never going to be done...) I
repeatedly found that there was just one more INTEGER or
LONG or whatever that had to be included.  This meant, for
a while, I constantly had to re-enter all of the data into
the new record format.
   Being aware that TYPE lengths used in HUGE arrays needed to be powers of
two, I usually had "extra" variables floating around
taking up the room to the next power of two.  One day I
finally woke up and realized that there is a hard and fast
rule about TYPE variables used in arrays.  Simply put,
ALWAYS put the "filler" variable at the end of the TYPE
definition.  Since the data is stored sequentially both in
memory and when written to disk, this means that you can
"steal" bytes for new variables from the "filler" variable
without re-entering the earlier data...Such as:
TYPE StkInfo
   StkOpen AS SINGLE
   StkCls  AS SINGLE
   Volume  AS LONG
   NumShares  AS LONG
   TipSrc  AS STRING * 32
   VolPerChg  AS SINGLE
   PrcPerChg  AS SINGLE
   JulianDat  AS LONG
   StkName    AS STRING * 25       '85 bytes at this point
   Filler     AS STRING * 43      '+43 = 128 bytes = 2 ^ 7
   Now, if I decide I want to include BrkrComm AS SINGLE to account for the
wack the stock brokers going to take from earnings, I would
put it immediately after StkName, but _before_ Filler.
Since a SINGLE variable is 4 bytes, that means the new
TYPE would decrease Filler by 4 bytes, i.e. Filler AS
STRING * 39...And I didn't screw up all of that other
  For a minute there my brain said "That's too easy!", but
really that's all there is to it.  Due to the wonders of
sequential memory storage, the earlier 128 byte TYPE is
identical in memory storage requirement to the new TYPE.
The only thing that changes is how QB/PDS accesses it; the
TYPE definition is simply a map that QB/PDS uses to locate
data within the TYPE...|-}
   (Of course, if you have initialized Filler to some string value at some
point, why I wouldn't know, then your new BrkrComm variable
is going to have unpredictable values...Otherwise, a fixed-
length string is basically all zeroes.  And, before you
try to confirm this, it would behoove you to back up your
data file.)
--- DB B1067/071082
 * Origin: RadioLink! Columbus, OH (614)766-2162 HST/DS (1:226/140)
Outer Court
Echo Basic Postings

Books at Amazon:

Back to BASIC: The History, Corruption, and Future of the Language

Hackers: Heroes of the Computer Revolution (including Tiny BASIC)

Go to: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Scientists and Iconoclasts who were the Hero Programmers of the Software Revolution

The Advent of the Algorithm: The Idea that Rules the World

Moths in the Machine: The Power and Perils of Programming

Mastering Visual Basic .NET