John,
I have made some improvements to the Spreadsheet, and more are coming.
You should see the changes on the FTP site within a few days.
>> An easy solution to this problem would be for me to add constructors to
>> BasicSSCell and SpreadSheet that take a FormulaManager object. Then,
>> you could easily write a short method to create your desired
>> FormulaManager and spawn a Spread Sheet UI.
>
>The would be perfect.
I have added constructors to BasicSSCell, FancySSCell, and SpreadSheet to
allow for a custom FormulaManager to be passed in. Let me know if these
new constructors aren't sufficient to meet your needs.
>TO be more specific here, I never get a redraw of a cell when I resize
>its row or column unless I "force" a redraw by cliking cells or resizing
>the spreadsheet. The resize tab-cell border mismatch starts to occur
>after you add a few row or columns. Once there are more than 3 or 4
>rows, resizing stops working. This is likely because you run into the
>minimum allowed cell size and resizing a cell does not cause the entire
>ScrollablePanel containing the SpreadSheet Cells to resize. Thus, if
>the only way a cell can get more real estate is to take it from it's
>neighbor, and all the cells are at their minimum size, resizing is
>locked down.
I have fixed the problems with cells not redrawing when the sheet is
resized, or rows/columns are added/deleted. About the resizing logic,
you are exactly right. Actually, the logic is not "broken" exactly;
it behaves as intended, but you make an excellent point that cells
should be able to resized even in many-celled sheets. Over the next
week I will be overhauling the Spread Sheet's layout manager, and I
will improve the cell resizing logic to be more effective.
>save is working for me. what i really mean sort of amounts to
>serializing everything, but really, i mean SAVing the display state of
>everything - mappings and associated ranges, color tables, orientation
>of views, etc...
>
>I don't want to serialize everything, but just to save as much as
>possible extending the string-based desription that is already in place.
I've been waiting on this issue for a bit, since Dave Glowacki has been
working on remote collaboration of Displays (it involves sending display
state information across the network, and is thus somewhat related).
I'll talk to Dave, and see how complicated it will be to implement a
more complete save of a Display's state.
>I'm not talking about panning the scene, I'm talking about panning the
>cursor. At present, the cursor is only moveable along the user's line
>of sight, not perpendicular to it. Specifically, the breakdown occurs
>around lines 400-500 or so of the MouseHelper code, where you are in the
>Mouse.DRAGGED case. The if-else-if logic that handles the mouse button
>2 events does not ever reach it's final else statement, which would
>presumably cause the cursor to pan. It always acts as though shift or
>control is being pressed, resulting in, respectively, the cursor moving
>along the line of sight (drag_depth) or a rotation of the scene with the
>cursor visible. Somehow the boolean t2pressed gets set to true,
>preventing the logic from reaching the last else statement, but I
>haven't traced back to exactly where this happens.
I tested this on my NT box, and it works fine. However, I only have two
mouse buttons, and simulate the middle button by pressing both buttons at
once. Try pressing both the left and right buttons on your mouse and see
if you can get cursor panning to work that way. Perhaps this logic only
breaks on certain machine configurations. Please let me know if you
figure out what is causing the problem on your machine.
-Curtis
