Why is it not possible to cancel a non-executable action?
This point has come up many times of the years and deserves a technical explanation.
In my experience all CAD systems do this to some degree.
@jeff_strater may be able to explain in more detail what's going on under the hood.
The answer, as it is with so many of these kinds of "It's 2023, why is this not implemented?" issues, it all comes down to the same thing: Priorities. There is no technical limitation. It's all just programming. In your opinion, this may be "one of the most important things in Fusion", but there are hundreds of these type of issues that someone thinks is "one of the most important things". We can only do so much, and therefore have to prioritize which issues to address. And, that is a balance between fixing bugs, adding small enhancements to existing functionality, adding new functionality, strategic initiatives that the division or company is pushing, etc. Of course, Fusion would be better if this were fixed. Or the focus-stealing on invoke. Or the floating browser, or being able to add to timeline groups, or dimension tolerances, or being able to navigate through a dialog with the Tab key, or parameterized text, or setting focus to the component name for New Component, or better touchpad functionality on the Mac, or better custom thread support, or modeled tapered threads (I could go on...), all of which have been mentioned with this same kind of "I can't believe that this is not there already" outrage.
All of these issues will eventually get addressed. But, we are neither magic nor are our teams infinite in size. So, just like cases in an ER in a hospital, we have to triage what gets addressed in what order. This one, to be honest, is somewhere in the middle. It comes up occasionally, but not as often as you might think. I actually have heard that this particular issue is on the list in the relatively near term. But, it is not a small project. Stopping a complex kernel calculation in the middle, then unwinding all the kernel and UI command logic to get the system into a stable and known state, without causing problems later in the session is not trivial. Then, we have to make sure to support all operations which can fall into this category of long compute times with bad input (it might be more frustrating if only some operations were supported and not others). And, of course, lots of testing has to be done to make sure that nothing that used to work gets broken in the process. Anyway, hope you get the idea - it's big.
Is that what you were looking for, @TrippyLighting ?
Jeff Strater
Engineering Director
@jeff_strater wrote:Is that what you were looking for, @TrippyLighting ?
He he, no, not really. My range of questions would not revolve around "why is this still not implemented".
You've answered that many times 😉
I am interested in how Fusion 360 and the kernel work under the hood and what are the difficulties in implementing functionality like this. For example, often software has to dynamically allocate memory in a potentially fragmented scheme. Hitting the escape button might trigger an event but if there is no mechanism provided, say by the kernel, to keep track of where it is with allocating memory, it is very difficult to clean up.
This is pure speculation 😉
@TrippyLighting - slow follow-up (day job getting in the way...). Yes, untangling memory allocation is certainly part of the problem, in addition to untangling the command UI state, and the modeling state. All doable, just not simple
Jeff Strater
Engineering Director
