# Thanks, but...

...I ran a little experiment, and it seems like

"As for not using varptr, is test is not the first thing in the segment, then poke 1,5 will not set the value in test it will set whatever happens to be there."

and

"should set x (might only work if x was an array)
whereas will always set the 1th element in test"

Did not happen.

Here is what I did:

'sorry for the spaces :/ its my text editor
DIM x(10) AS INTEGER

DIM test(10) AS INTEGER

DEF SEG = VARSEG(test(0))
'the following puts 5 into test(0) but the second byte, since an integer is 2 bytes:

POKE 1, 5

CLS

DEF SEG = VARSEG(x(0))

PRINT "?peek varptr x(0) = "; PEEK(VARPTR(x(0)) + 1)

DEF SEG = VARSEG(test(0))

PRINT "?peek varptr test(0) = "; PEEK(VARPTR(test(0)) + 1)

DEF SEG

PRINT "?x(0) = "; x(0)

PRINT "?test(0) = "; test(0)

This program gave me this output:
?peek varptr x(0) = 0
?peek varptr test(0) = 5
?x(0) = 0
?test(0) = 1280

Which is correct, and x() was not set. This must mean that def seg = varseg... provides some type of offset for the POKE.

As you can see: if you peek into the second byte(varptr(test(0))+1) of test(0) you will get 5 (just what POKE 1,5 did). But peeking into x will get 0 because it seems that nothing was POKEd to x.

And if we print out test(0), we get 1280 which is 10100000000 in binary, where we can clearly see that 5 (101 in binary) was placed into the second byte. And x is still 0.

Thanks alot for clarifying the segments, though.
Ben

Posted on Dec 1, 2008, 8:20 PM

 Response Title Author and Date You discovered I was totally wrong, here's the right answer. The PhyloGenesis on Dec 2