> 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.
ah yes.. i remember that you found this bug as well in my replicate 
function. So editing geometries become a bit funny

stefan

> 
> regards,
> Larry
> 
> On 9/27/07, *Sunburned Surveyor* <[EMAIL PROTECTED] 
> <mailto:[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
>     <mailto: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

-------------------------------------------------------------------------
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

Reply via email to