> >In order make it more useable I have had to change the source code of
> >SpreadSheet.java, as it does not lend itself to being easily extended.
>
> As I mentioned to Peter Cao, if you have any specific suggestions about
> how to make the SpreadSheet easier to use or more extensible, feel free
> to mention them. I am interested in any ideas you might have to make
> the Spread Sheet a friendlier piece of software.
>
OK - I do have a few issues, and when I get the chance, I can write them
up coherently and send them to you.
> >I am also extending FancySSCell - as such, i also needed to change the
> >source code of the SpreadSheet to allow a SSCell other than FancySSCell
> >to be used. I had to make one other change to the VisAD source. The
> >FormulaManager used by BasicSSCell, as it is written, must be the one
> >created by the createStandardManager() method of FormulaUtil. The
> >FormulaManager created by this method is not suitable for my needs.
>
> 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.
> >making "Save SpreadSheet" really save the SpreadSheet
>
> Do you mean that this feature was broken and you fixed it, or that you
> modified it to save serialized data from each cell? If the feature isn't
> working for you, I'd of course like to determine why and provide a bug
> fix to anyone else who may be affected by the bug. If you modified it,
> then I'll consider adding a menu item to the Setup menu called "Save
> entire spreadsheet," or something like that, since you are not the first
> person to express interest in such a feature.
>
oops - sorry for being vague there. save is working for me. what i
really mean sort of amounts to serializing everything, but really, i
mean serializing the display state of everything - mappings and
associated ranges, color tables, orientation of views, etc...
> >One signifigant step that needs to be made is to make cell
> >resizing work correctly. maybe this problem does not come up on
> >Solaris, but on NT the relationship between the locations yellow resize
> >tabs and the actual size of the cells quickly breaks down. eventually,
> >cell resizing stops working altogether, especially if you try to use
> >many cells. also, the cells do not redraw themselves when a resize
> >occurs, meaning the user has to go around and click in every cell in
> >order to force a resize.
>
> I developed the Spread Sheet on NT, and have seen the redraw problems
> with the cells after a resize, but I haven't experienced the resizing
> mechanism actually breaking down. I admit that the layout manager for
> the Spread Sheet is a bit flaky, and I am going to overhaul it in the
> next month or so. Maybe I'll eliminate the problem you describe in the
> process of fixing the other bugs I've noticed in the resizing logic.
>
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.
> >There is another problem, and, again, maybe this is just on NT: I can't
> >seem to get the cursor to "pan." It should pan when you drag with the
> >middle mouse button, but instead, it rotates the scene with the cursor
> >on, as is supposed to happen when you hold down control when you are
> >draggin with the middle mouse button.
>
> Actually, panning the scene is accomplished by holding Shift and dragging
> with the left mouse button. The middle mouse button turns the cursor on,
> letting you examine data values.
>
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.
john
--
John Brecht
SRI International
Center for Technology in Learning
333 Ravenswood Avenue
Menlo Park, CA 94025
650-859-2325 (voice)
650-859-3673 (fax)
john.brecht@xxxxxxx
