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
Filler AS STRING * 43
END TYPE
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
data...
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)
