>>  XREF@ CLDES%(7,_CPMAX)

>I believe it's usually safer to do this the other way around:
>    XREF@ CLDES%(_CPMAX,7)
>The compiler doesn't care what the first parameter is, only the later 
>ones. The way you had it, the compiler set up your array to look at an 
>indeterminate number of (_CPMAX+1)-element arrays. The other way, it 
>looks at an indeterminate number of 8-element arrays. Even if it really 
>doesn't matter, conceptually I'd rather deal with that. It also allows 
>you to see all 8 values together in MacsBug, rather than scattered over 
>vast distances.

   THAT was the problem I was looking for.  I had the dimensions of the array
in the wrong order.  I asked about that a few weeks ago, but was assured by
somebody that I had done it properly...  I needed the array to be a long
series of 8-byte blocks, not 8 very-large blocks.  I was indeed overflowing
the handle I assigned for the array.


>>The array appears to work properly, but perhaps the compiler gets
>>confused with it under some circumstances and reads/writes data to the wrong
>>location? 
>Sorry, but the compiler will do only what you tell it to. You may be able 
>to confuse you or me, but not it.

   IT IS possible to confuse the compiler.  I have done it many times.  As
much as we hate to admit it, FB does have a few bugs and quirks.  When
segments get large (almost 32k), or have almost too many segment-jumps (not
sure how many), then strange things start to happen.  The code still compiles
and runs, but IT DOES NOT RUN CORRECTLY.  Adding a few more lines of code, or
a few more segment jumps, causes the compiler to notice and complain about the
problem.  Once the compiler actually complains, then the problem can be fixed
and goes away.  Before the compiler complains, you just have lots of
mysterious crashes.
   No large or complex program is perfect, they all have an obscure bug or two
somewhere.  FutureBASIC is MUCH less buggy than the average program, but it
does have a few problems here and there.  It is never good form (or very
productive) to continually point to FB as the source of your programming woes
(and bugs).  However, it is also wrong to assume that FB has no bugs and
cannot get confused.  Almost all of my programming problems, crashes, bugs,
and whatnot, have resulted from my making typos or subtle logic errors.  Even
so, some of my problems in the past HAVE resulted from bugs in FB.  I don't
blame FB Andy or Staz for these.  They have done an excellent job.
   FB does not ALWAYS do what I tell it to, and all program bugs are NOT the
result of my own mistakes.  Only about 99.9% of them are my mistakes.


>>If I use the debugger to show the contents
>>of the 2nd array, it shows only bogus (and unchanging) values. 
>The debugger, I believe, shows only addresses for XREF@ data, no values. 

   The debugger WILL SHOW the contents of an XREF@ array.  It will display the
array contents (values) just like any other array.  They are just not the
correct values.

>I suspect you may have either passed XREF a handle, or passed 
>XREF@ a pointer. Another thing to look for is an XREF or XREF@ statement 
>where you've accidentally put a "&" instead of a "%" after the var name. 
>That will instantly double the size of your array and probably overwrite 
>other data, but could seem to work fine while doing so.

  Thanks for these wonderful suggestions.  However I have tediously checked
all of these several times already.  Everything you mention here is as it
should be.


>  XREF@ CLDES%(999,7)   'I use 999 to remind me FB doesn't care

   FB does care!  The value you specify (such as 999) is used by FB to
determine if you are overflowing the array bounds.  If you specify 999, then
you cannot access element 1000 without generating an array bounds error
(assuming that error checking isn't turned off).


>One other idea: I notice you have local and global vars of the same name 
>(except for the g). Is there a possibility there could be an extra or 
>missing g anywhere? Are you using _DimmedVarsOnly?

  I always use _DimmedVarsOnly, as it saves me lots of time debugging later
on.  Unfortunately using XREF or XREF@ prevents me from using _NoRedimVars.
Dimming a local variable and then XREF'ing it always produces a Re-Dimmed-Var
compiler error.  I would like to use this compiler option, but cannot because
of the XREF's.  Perhaps this is an example of FB getting confused?


> =J= a  y

   A thousand thanks Jay.  Your response pointed out my mistake.

David Herron
CaverDave@...