Q: UNDO in EstlCAM v12 or v11? Ans: Nope. Workaround: Use EstlCameo & Autohotkey

I don’t think there necessarily needs to be a cap on it if it’s done right.

My Blender files are sometimes 500MB+ and the auto save is fine

image
image

2 Likes

Neat, looks like Ctrl + S key shortcut does save… Couldn’t find doc with list of keyboard shortcuts, so, just tried and observed that works.

I appreciate EstlCam is written and supported by just one person, that probably has other job(s)/responsibilities to balance too.

Found it…

1 Like

Sorry, I don’t mean to be rude but this won’t help at all.

It would be so nice if 334 lines of code is all there is to do :wink:
But this is just the interface declaration specifying function names and formalities for the WPF frameworks undo service.
This is what developers of custom addons need to observe if they want to make them compatible with the WPF Designers undo function.

99.9% of the work lies in each and every objects “Do” and “Undo” function that will be called by this interface and needs to be coded by hand taking into account all its dependencies to other objects.
Estlcam has hundreds of objects, most of them referencing and depending on several others.

It actually would help quite a bit if you look beyond “that file”… it was just a hint to the repository where the implementation was.

Nowhere did I say “just take this 300 lines of code and it magically will work for you”

No, there is an entire Undo/Redo implementation in there for the WPF Designer that existed in SharpDevelop.

I am very aware what it takes to implement it. I manage a very large piece of software that is many times larger than what EstlCAM is, and have been doing this professionally for 20 years, 15 of those in .NET.

As I said, I did it, for a designer suite with more than 50 custom control pieces that need undo/redo functionality

Now, if you don’t care or are not willing to look into it even though your customers are asking, that is different.

I was trying to be helpful because I know a thing or two about it.

I will gladly refrain from doing that in the future.

3 Likes

It’s still a large effort by a single person, not a whole development and QA team. Even if implemented, this just touched a ton of code making the testing effort quite large as well. For the cost and capabilities, I’m not complaining about a lack of undo.

2 Likes

I didn’t have a large development team or QA team for that product either at the time. This entire application was written and released by 2 people… me and 1 other guy.

That’s not the point though.

No one said “just look here and you can have it done by tomorrow”

I happen to know it sounds daunting, but it isn’t as hard as it seems. It was merely an offering of some help.

I can point you to numerous applications that are free, that have the ability to undo things.

As a customer of a piece of software that cost money, the number of people developing it is not the customers concern.

As I said, if he’s not willing or whatever, that’s fine. I’m not the one that asked for the feature. I was merely offering some information.

I happen to know that his application is a WinForms .Net application, so the code there fits.

1 Like

Hello,

I appreciate the effort but it unfortuntately won’t help in my instance.

Thing is: I’m a “one man show” and actually have 0 professional nor educational background in IT, CAD, CAM, electronics, or control software. Estlcams roots go back to the hobby of a 12 year old kid inspired by a very good teacher who showed me how to make stepper motors work on a computer with 80286 processor and a green monochrome screen. This thing just got way bigger than I ever imagined.

I can now start spending months of work trying to implement a proper undo function with a very good chance of total failure as Estlcams whole architecture (or lack of it as it started as a hobby project to save money on CAM software) has never been designed with any thoughts on how to make transactions reversible. Or I keep spending this time on other things I know I can do properly.

But I still got a very useful clue out of this thread:
There will be a save hotkey in the near future - and most likely also a “save with timestamp” hotkey so you can create “respawn” points with a simple key stroke.

Christian

7 Likes

I am pretty sure that some around here would gladly sign an NDA to help make the software that so many of us use better in ways you aren’t able to if you wanted them to. :slight_smile:

1 Like

Hi,

sharing the code - even with NDA - is an abolute no-go for me - sorry.

Christian

3 Likes

Yeah. Those are basically the two options I was thinking of. The “transactional” one you described seems more plausible, but you really need to write the code from the beginning as a bunch of transactions. You don’t necessarily need every keystroke or mouse click as a separate transaction.

You could, for example, have a transaction for the “Move” action. When the user chooses move, then toolpath, then changes X and Y around a bit to get something they like, then they go only to adding a “Part”, you save that move as one transaction. Your project ends up as a list of transactions.

Inside the Move transaction, you may want a couple of forced “Memory dump” style undo positions. When someone changes X or Y, save the offsets to a vector and then you could undo those to undo until there is only one left and then undo the entire transaction.

The main two problems with this I see are:

  1. If one of the transactions takes some time, then undo is now a slow action. If Estlcam took 3seconds to compute some toolpath and then the user moved it, the undo would take at least 3 seconds. You could solve that most of the time with a cache after each transacrion, probably. But that’s more work.
  2. Your software isn’t designed like that from the start. It is pretty hard to shoehorn that kind of thing into existing software. Maybe you could consider making everything a transaction in the next version. But I am guessing there will be little tentacles the operations have on each other that will need to be severed and the main state machine could need a complete rewrite.

Accidentally deleting an object could be the biggest reason. But the one I’m afraid of is accidentally clicking something or typing in the wrong box and not knowing where that input went. It would be hard to manually undo it if an ‘8’ was added to a depth of cut parameter but you didn’t realize your cursor was in the DoC box.

Save with timestamp shortcut would be awesome!

Especially awesome if you pair the change with Ctrl + Z to rehydrate most recent timestamp snapshot older than current, and Ctrl + Y (or Shift. + Z) to rehydrate newer snapshot.

Saving timestamped files to /.snapshots or some other subfolder to avoid cluttering main project folder would be helpful. Am anticipating using snapshot key shortcut like crazy.

Again, Ctrl + S already saves today. What’s a separate intuitive key shortcut for persisting timestamped checkpoint snapshot Shift + S ?

Fair enough. If trusting random people on the internet is a factor here, I’m https://www.linkedin.com/in/aaron-sethi, sharing incase things change, and you’re open to help in the future.

Very risky to pair the shortcut that everyone will expect to “undo last edit” to accidentally “go back to 3 hours ago”

1 Like

Ctrl + Z has no effect unless someone used the snapshot feature, in which case they likely know what they’re doing. That said… a modal popup “are you sure you want to go back to snapshot hh:mm:ss ?” could help avoid footgun moment though

Or how about an option to choose to “Auto-Save” with a electable time interval (0-999 seconds)?

You generally don’t want to inject non-standard functionality into UI paradigms that have become de-facto standard, especially on Windows.

It adds friction to the user experience.

What happens if he decides later to add regular undo functionality? Now you have to deal with changing the user experience.

I’ve never seen that turn out well

Agree that a shortcut to make it happen is nice, just maybe a slightly different one

3 Likes

Bet you a beer that’s not happening

2 Likes

Maybe not, but doesn’t change my perspective on it.

I’ve heard a lot of "never"s in my time that turned into “pretty soon”

4 Likes

Rhino’s autosave implementation is nice. You can select from a list of actions that trigger an autosave. It puts it in the users’ hands whether they want to endure any performance hits, minimal or not.

Implementation to call the autosave code would be minimal and can be done incrementally, a feature/action at a time.

1 Like