Topic: Handling ESC/Cancel gracefully

[Keith™]

Is there a simple method of wrapping exposed .net functions to prevent errors that arise from cancelling during a function?

It seems the try ... catch block doesn't catch everything that could go wrong when a user cancels a function, or perhaps the errors don't bubble up far enough to allow them to be handled gracefully.

Even if it isn't a quick fix (kinda can't be when your project is 100M)

Anyway, I'm trying to wrap up 4 years of development (it sucks and I'm ready to be done with it) and I've ran into this issue where sometimes an error is thrown and sometimes it isn't.

[MickD]

You would typically handle this by checking the PromptStatus enum value, check for OK to continue else exit. You can specifically check for cancel as well.

If you are not asking for user input and your function is long running then I'd provide a progress/wait dialog with a cancel button and use that to handle the cancel then wind back any operations if required.

[MickD]

After re-reading your post, if it is an error due to some API not getting the correct input then there are bigger issues (i.e. bugs/input checking/logic errors). If you wrap the entry point method in a try catch you will at least catch any exceptions that bubble up and you can handle them gracefully...sort of

[Keith™]

The biggest offender that I can readily reproduce is in my jig.
In one part of the program, the user selects data files with hundreds, sometimes thousands of data points. These points are read into a data class and are subsequently parsed, sorted and inserted as attributes. Each file may have as little as one node or hundreds of nodes. If the user cancels the action during the jig an error is produced 90% of the time and it is usually a null reference.


Stepping through the code provides some clues, but its a daunting task, especially considering that there are several breaks that occur in unmanaged code that I cannot debug (you know stuff like Autodesk libraries and some windows imports). For what its worth, I didn't have this problem when it was a straight up WinForm app, but now that it is running from a palette, this has happened. I suspect it has something to do with the fact that the top level control is only disposed when AutoCAD closes and as a result maybe its a memory leak or maybe there is a variable that the compiler is linking that I don't think it should? I dunno …


I'll find the culprit, because I'd rather not just put a bandaid on the problem. I prefer fixing the problem.

[MickD]

Ah, ok it's in a Jig. You should be able to handle the appropriate Status of move/drag etc of the jig and catch/handle the current status or exception.