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 "