Hi SS,
The undo/redo support is really a java thing that you can support in your
tool, but doesn't really make sense for the toolbar undo and redo buttons.
Those buttons are expected to undo and redo edits, not selections. It also
doesn't normally undo layer operations. For instance you can't undo
creating a new layer or removing one. These kind of operations are easily
reversed manually, and implementing them can lead to code that balloons into
a huge subsystem that most users don't want anyway. (Would anyone really
want to undo saving a file?)
So, in the example you gave:
[1] Copy selected features to the destination layer.
[2] Clear the current selection.
[3] Delete the copied features from the source layer.
I would say that undo should remove the copied features from the destination
layer, restore them to the source layer, but not attempt to restore the
selection or remove the destination layer. It should probably do this in
one click of the undo. There are other plugins that do this same sort of
thing, but I can't find one offhand that implements undo.
If you are concerned about losing the selection, what I have done in the
past is to implement a Save/Restore selection button. I guess this would be
based on FID in OJ.
Your concern about memory usage is a valid concern. It seems like you
should be able to simply move the features from one layer to the other
without deleting and creating, but they probably have different schemas, so
that won't work. You can do it for the geometry, of course, but I'm not
sure of the consequences of that. I still remember the first time I tried
to do a copy from one layer to another in code. I ended up with two
features sharing the same geometry. A potentially useful, but scary
concept.
regards,
Larry
On 9/27/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>
> I've been looking at the steps necessary to add undo/redo support to
> the Super Select Tool. I had a question or two about memory usage that
> someone who has worked with the undo/redo code may be able to help
> with.
>
> How is the memory usage of undo/redo handled in OpenJUMP. For example,
> will I be hogging all sorts of memory if I implement an UndoableEdit
> that stores information needed to perform the "undo/redo" operation in
> memory, and then create a process where the user could potentially
> create lots of instances of these UndoableEdits? Does OpenJUMP enforce
> some type of limit on the number of supported undo/redo operations or
> a memory limit to keep this from happening?
>
> If not, perhaps the smart thing to do is create an UndoableEdit that
> stores its data on-disk.
>
> Does anyone have experience combining multiple UndoableEdits into a
> single undo/redo operation? As an example, the "send to layer" button
> in my Super Select Tool could perform up to three (2) separate
> operations depending on how it is configured:
>
> [1] Copy selected features to the destination layer.
> [2] Clear the current selection.
> [3] Delete the copied features from the source layer.
>
> I don't really want the user to be required to click the undo button
> three (3) times to undo what they did with a single click, do I? This
> means I have to find a way to combine the three (3) separate actions
> into a single UndoableEdit, correct?
>
> Thanks,
>
> The Sunburned Surveyor
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
