Prevent user terminating add-in command prematurely with escape key, right mouse

[Anonymous]

The add-in finishes the operation without a fatal error if the user simply finishes the command by selecting another element than a wall, however If they press esc and revit can't resolve walls contorted back onto themselves by deleting or unjoing geometry the revit application crashes. This shouldn't occur in normal operation however if a user were to be silly and use the tool inappropriately it is a real danger. Is there any way of preventing the user from pressing the escape key?

I currently handle the user ending the command with esc or right mouse with the below code...

}//end execute method

//If the user right-clicks or presses Esc, handle the exception
catch (Autodesk.Revit.Exceptions.OperationCanceledException)
{
return Result.Cancelled;
}
//Catch other errors
catch (Exception ex)
{
message = ex.Message;
return Result.Failed;
}

[arnostlobel]

The answer is No, there ins't a way to prevent the end user from hitting the Esc key. However, that is exactly how selecting was designed to behave and what you do in your application (catching the OperationCancelled exception) is exactly what you are expected to do,

[Anonymous]

Thank you Arnost,
The problem is when the user cancels the operation the cancel and delete the inverted(walls turned back onto themselves ) dialogs don't appear so that the user can agree that they shouldn't have used the command to pull walls back onto themselves. How can i use the catcjing of the exception assist in preventing the file crashing with a fatal error? Thanx again.
Frank

[Anonymous]

I just checked then a number of errors can be incurred such as 3xconstraints can't be maintained, 4xelements need to be unjoined and 2xelements are reversed. The errors can accumulate and if the user doesn't handle them and instead chooses to use the "Interrupt" key a fatal error occurs. 

[arnostlobel]

spammasterblaster:

It looks like you are not giving us enough information to work with. In your originally posted snippet there was nothing about walls or deleting them. There was not even a transaction used to modify the model. The question was about cancelling a selection and that, I believe was answered - you catch the specific OperationCanceled exception and continue on with your commmand's execution. Now, regarding of model changes, wall deleting, etc., we need to see your actual code and what you do there to be of any help. The problems you were describing do not look like having anything to do with selecting elements.

Thanks

[Anonymous]

Hi Arnod,

Thanx for investing the time to assist someone who is starting to code in a new area, that being aad-in geometry. I have written some complex add-ins to do with view creation, parameters and models, however I have never come across "fatal errors," when a user presses the interupt key. To summarize I am selecting walls, moving them, locking a constraint, joining geometry and modifying the wall orientation and properties. I make the calls to the methods from within the execute method however much of the code calling the api classes is outside this catch block. To aasist your understanding I copied the entire class and added it to a zip, see attached below. 

cheers,

fabs

[arnostlobel · Accepted solution]

Dear fabs:

I am sorry but I do not have time to examine your application. If you think you may need a help with code-proofing your application I suggest you become a member of the AND. There are really great with helping external programmers.

I can only provide a quick comment and notes. Since you mentioned that in your application you let the exceptions escape from some of the method on deeper levels, I assume you need to refactor your application to avoid cases like that. Even with an exception escaping from your external command, Revit should not crash though. Because that is what you report, however, I can only guess you may not be scoping your transaction properly. Please make sure that all your transaction are always properly scoped in using block (assuming you use C#). It is very important. Otherwise a transaction could be left unfinished when an exception accurse and cause some problem when the garbage collector tries to collect it, eventually.

[Anonymous]

Thanx Arnost,
I have the transaction attribute set to automatic. I started doing this as it is more convenient and the code complexity is reduced. Do you think I need manual Transaction in my C# to scope the api class calls? I will try AND out thanx for your time I appreciate it.

[arnostlobel · Accepted solution]

I definitely do not recommend using Automatic transaction mode in any situation. It is kept for backward compatibility only. It has virtually no advantage beside the "convenience" and even that is questionable, for automatic transaction cannot be named. On the other hand, automatic transaction has many disadvantages. We have been strongly recommending the Manual Transaction mode since about Revit 2012 or so. It is also a safer approach, because Automatic transaction mode will be eventually removed; hopefully.

Ideally, you put your transaction only there where you actually make modifications to the model. An ideal transaction is as short-lived as possible, and is always scoped - that is, it lives inside a using block. That way you never leave a transaction open, because any started transaction gets closed (rolled back) automatically when leaving the scope in a case of exception. 

[Anonymous]

Arnost, I thought you might like some feedback on what was causing the issue.
After doing a little refactoring which amounted to no benefit except my code was less clear and less modular, I changed the transaction attribute to manual and placed all the changes to the database within blocks as per below. now the element is reversed and unjoining , deleting of the wall geometry occurs immediately after the button click occurs. and revit handles this first, then if the user presses the interupt key it's after the issues have been resolved and no crash occurs. Many thanx i am quite happy about the support i received from you despite my alias. 😉
using (Transaction trans = new Transaction(doc, "Flip Wall"))
{
trans.Start();
getWall(doc, E1Id).Flip();
trans.Commit();
}

[arnostlobel]

Excellent! Welcome to a new phase of your Revit API programming.

Soon you may even want to learn about the benefit of transaction groups, which do allow you to merge all your transaction that have been committed in you external command into just one transaction, which will e the only one item the end-user will see on the undo menu. This merging is actually necessary if your individual transaction aren't supposed to be freely undone/redone individually - that is, the whole command is to be seen as one atomic operation. I'll leave it up to you about the TransactionGroup class and its Assimilate method in the RevitAPI help file and SDK samples.

Cheers