Larry, Thank you for your excellent explanation of undo/redo. This makes a lot more sense to me now. Basically we only want to support undo/redo for "edit" operations that change features and their geometries.
Larry wrote: " 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." Actually, I stole some code from the PasteItemsPlugIn that deals with this very issue. In summary, my tool will clone selected features when the "Send to Destination Layer" button is clicked and will send these clones to the destination layer. The clones will not contain references to the original feature geometry. The cloned features will also contain "copies" of whatever attributes have matching names and datatypes between the FeatureSchema objects of the layers involved. This logic comes from the "conform" method of the PasteSelectedItems tool. The user will have the option to send only Feature geometries and also whether or not to remove the selected Feature being sent from the source layers. Thanks for the help. Landon On 9/28/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > > 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 > ------------------------------------------------------------------------- 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
