On 23 Mar, 2005, at 3:35 PM, Jay Reeve wrote:

>
> Okay, here's a breakdown that may make it clearer. I'm rather fond of 
> the shorthand, but it can look like gibberish if you don't know it.
>
> @myCtnr$$ 				gives the address of the variable myCtnr$$
>
> [@myCtnr$$]				returns the handle stored there
>
> [[@myCtnr$$]]				dereferences the handle to get the current data 
> location
>
> [[@myCtnr$$]] + x			adds the offset to the char you're looking for
> 						(should actually be + x - 1 to correspond to myStr$[x])
>
> |[[@myCtnr$$]] + x|			peeks 1 byte from that location

After the initial shock at the sight of it, it's not that 
impenetrable...
>
> CHR$(|[[@myCtnr$$]] + x|)	converts the byte to an ASCII char.
> 						This step is unneeded to correspond to myStr$[x], which just 
> gives the byte.
>
> All  of which, of course, is why we have the MID$$(myCtnr, x, 1) 
> thing. :-)

 From my in-depth research here (and completely missing a reference 
point), MID$$ appears to suffer from the same problem as MID$ compared 
with string$[x]: it's slow.

Not, however, as slow as I... I'm stuffing reams of data into an edit 
field that can't hold it all anyway, so dealing with it as a byte array 
scoots right along, and then it's turned into characters in small 
chunks just for the benefit of the edit field.

Just the same, I think you should add the string$$[x] capability to the 
compiler. In your spare time.
--
Ted Spencer
--
What the eye does not see, the heart cannot grieve...