[futurebasic] Re: [FB] More XREF Questions

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : November 1998 : Group Archive : Group : All Groups

From: Jay Reeve <jktr@...>
Date: Sun, 22 Nov 98 03:01:46 -0600
Hi Dave,

>Can I use an XREF'ed
>array to hold Handle Addresses for other XREF'ed Arrays?
What the XREF statement does is tell the compiler, "I'm going to give you 
the address where an array starts. Now you set it up so I can look at it 
_as_ an array." It doesn't care what's in that memory space; it will just 
spit it out in whatever size chunks your XREF statement tells it.

>  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.

>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.

>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. 
You have to go into MacsBug to see what the values are. If that's what 
you're doing, and you're still seeing different things from what you 
expect, 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.

One thing you might try is making a record of the start and end (max) 
addresses for each XREF array as you step through, to see if you can find 
any overlap. Since handles can move around, this wouldn't be proof, but 
it sure might be a starting place. You can also compare these with the 
address and size of the block to see if they correspond.

As a matter of form, I always put my XREF statements directly under the 
corresponding DIM statements, before I put a handle (or ptr) in the var. 
I don't think this will make a difference, but it couldn't hurt to try. 
e.g.,
  DIM  CLDES&
  XREF@ CLDES%(999,7)   'I use 999 to remind me FB doesn't care
  CLDES&=gCLDES&
  LINK%=CLDES%(N%,LINKNUM%)

I'm a little leery of your terminology, "the address of a handle." If 
this means the handle itself (what I call the address of a pointer), they 
you're okay. If you're talking about the address where that handle is 
stored, then you may have a problem.

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?

>Even so, I've poured over the code for days now and
>there's nothing left to grasp at but straws like these.  
We've all been there. This one should be solvable. If you can extract 
some code where you have made recent changes or where you are most 
suspicious of trouble, I (and perhaps others, too) would be happy to look 
at it. Just send it privately. (If the whole proj. is under 1mb, you can 
send me the whole thing and just tell me where _you_ think I need to 
look.)

Good luck,
 0"0
 =J= a  y
  "