David,
>>
>>I had another idea that might interest you. I don't know whether it would
>>work, and it might be difficult to implement--or it might be very easy!
>>
>>It occurs to me that moving rows and columns is something the OS does all
>>the time. There is amazingly fast, highly optimized code for doing it.
>>
>>What if your spreadsheet were set up as an offscreen gWorld? Each "pixel"
>>would hold a pointer to a cell handle. You could assign and retrieve
>>individual cells with SETCPIXEL and GETCPIXEL. Relocate rows and columns
>>with SCROLLRECT and BITCOPY. Filling a row or column with pointers to the
>>same formula or value could be as easy as drawing a line.
>>
>>You would have to figure out what bit depth would give you the most
>>efficient memory usage, but I suspect it could be done. What do you think?
>>
>> 0"0
>> =J= a  y
>>  "
>
>Very clever Jay - but I think way too clever for me. I guess its speed 
>depends on just how optimised the code is - for example if it uses the 
>same code to move memory as the toolbox memory functions would it really 
>be faster? Cut and paste wouldbe fun :)
I'm not sure to which memory functions you're referring. The only one I 
can think of is BLOCKMOVE. It may access that same code, but I suspect 
with far less overhead than would end up in your FB code.
>
>My linked list idea for the non array dimension (say columns) minimise 
>memory movement for many operations so it would be faster on that 
>dimension (and slower on the other).
>
>Care to try a demo? I'll have mine working in a day or two.
Ooh, it is so tempting! Unfortunately I'm into a very busy time, and 
having run myself thin on the word thing, I'm going to have to give in 
and get some sleep one of these days.

On the other hand, if you get a demo working that I might be able to try 
to adapt to my idea, I probably couldn't resist at least having a shot. 
First I would have to figure out how 6-byte RGB values are stored in 32 
bits. Do you have a simple explanation handy, Robert?

 0"0
 =J= a  y
  "