Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
I was attempting to review some steps in my timeline and accidentally clicked the PLAY button. Now I can't halt the process without "FORCE QUIT" on the entire app. Shouldn't there be a PAUSE or STOP button? Painful UX to have to sit and wait several minutes for it to finish.
Sometime you will do an operation, pushing a cut too far or something else, where you get the wait cursor and you *know* it will just take a long time before it will just return with a failed attempt. And the whole UI will just freeze during this period.
It should be possible to abort any such processing immediately by pressing ESC key. A dialog could show up, asking Abort - Yes / No, to make sure one did press ESC on purpose.
The best thing would ofcourse to detect these scenarios quickly
An option would also be to return to the previous working state... if I'm doing a push / pull on a surface, and it first works, then at some point it freezes (because it will fail), when I press ESC key it could return to the previous working value.
with 19 Kudos I think many here agree that we need a task breaker. Rhino uses it for long calculations. Often in Fusion you can either wait or well force quite it.
The beachball is very nice and all but some indication on what is going on, like "this will take a while" or "this is an impossible calculation" and "a way out" without having to force quit.
I think being to stop a long running operation is required, but I'm not sure if using the ESC key would be ideal.
Consider this simplified situation: you start a new sketch in modeling mode. Select a center diameter circle. Moving the mouse to adjust the size shows the diameter input changing the diameter value. If you press ESC at this point, you lose the circle. If you enter a value using the keyboard and press ESC, you'll lose the circle.
A more likely situation might be when creating a web from a sketch. You select all the sketch lines you want to use for the web, then enter a value for the thickness of the web. If you press ESC at this point, you'll unselect all those sketch lines. It puts you back to where you were when you first clicked on the Web icon. I know from experience that this is not fun and is known to cause Bad Feelings.
That said, if Fusion 360 was smart enough to know what to do when I press ESC during a long running task, I'd be all for it. But I don't trust Fusion 360 to be that smart at this point. Keyboard input is glitchy most of the time (dialogs/inputs get the wrong focus, or don't respond, etc).
Might I suggest that the time-consuming "play" button shouldn't even exist? At least until you get it to play nicely.
I suspect that if you poll a360 users then you'll find that nobody in the real design world (no offense) would ever need to use it, and if someone felt the need to step through the creation they can just as simply use the step button, which allows them to do a better narration anyway.
If a360 must have the thing then please bury it in a menu somewhere, or prepend the action with a dialog box that says "FYI ... until we modify this function it will take over your drawing for the next 5 minutes", as that is what happens to me whenever I accidentally hit it.
I was trying to revolve a simple sketch about 80 times.....I went to edit it, and change from 80 to 81....but I screwed up and instead of removing the 80 and replace with 81, the number became 8081!!!!!....Now I am waiting to see if it will actuallt revolve 8081 sketches, lol. My Ram usage has climed and is still climbing, a fun test I guess.
It would be nice if the esc key would just drop out and cancel this operation though.
Agree. This has been a long standing thing with millions of programs that are windows based (can't speak or other systems) since the inception of this thing people like to call "object orientated code". When a task is invoked, the programmers almost always forget to look at the user for interface - "oh, I'm sorry, you can't hit that key at the moment as I am busy doing the thing you asked me to do before".
The user is most important and should always come first. Every program should be constantly polling the users input to see if there needs to be a change to the current "object oriented or invoked task" but probably less than 1% of programmers do this.
Imagine if a machine worked that way. "oh, I'm sorry, you can't press the emergency stop right now because I am in the process or cutting your hand off". There is no such thing as object orientated code. It is just a phrase used to describe how a user invokes a task or block of consecutive instructions (code). The CPU on my laptop never stops running - it is not object orientated regardless of what program I might be running and the power button always works!
I just experienced another thing a few moments ago so thought I would add a bit to this. Again, relative to use of the escape key or some other user interaction with a task in process. I read a post also about the mouse becoming inactive during some task - and believe based on the post, we are talking about the same sort of thing as this original poster.
I Inserted a part and the move interface comes up straight away (great - no issue here). Went to rotate and picked the wrong rotation handle. Pressed escape to terminate that mistake and my "inserted" part disappears.
This brings up a point to decide on - should esc cancel the current process or the task (which it did) or should sub functions of tasks like the move dialogue box rotate interaction - the one that was in process at the time - be the "first" to be acknowledged and terminate there and then rely on ctrl/cmd Z to undo the insert part process, or should the process have terminated totally as it did.
Once again, the user comes first in your programmig (please?). Terminate the current action, not the whole task?