Notify When IUpdater Is Disabled By Revit Error & Re-Enable

[rvtquestions]

I have a several IUpdaters in my add-in of which a user can disable or enable by clicking an associated button. For example, there is a pushbutton A for IUpdaterA, which the Push Button image shows the status of the IUpdater.

On PushButton Click:

                    if (UpdaterRegistry.IsUpdaterRegistered(updater.GetUpdaterId()))
                    {
                        UpdaterRegistry.UnregisterUpdater(updater.GetUpdaterId());
                        pushButtonA.LargeImage = Off;
                    }
                    else
                    {
                        UpdaterRegistry.RegisterUpdater(updater);
                        UpdaterRegistry.EnableUpdater(updater.GetUpdaterId());
//Add Triggers, etc. (omitted here for conciseness)
                        pushButtonA.LargeImage = On;
                    }

This works fine when the user manually clicks and turns on or off the IUpdater. However, when something during the session or project environment causes the IUpdater execution to fail throwing an error, the button does not respond to re-enabling the IUpdater after it has been disabled:

So (2) questions:

1) When this error is thrown and disable Updater is clicked, is there a way to tie this back to change the pushButtonA img to OFF?

2) As seen in the code, UpdaterRegistry.EnableUpdater() is used but it doesn't seem to enable the IUpdater back up after it has been disabled through the error dialog. How can one re-enable it?

*This is not to say one should always want to re-enable a disabled IUpdater as there was a reason it was disabled, but in some cases under discretion it may be due to something resolvable like loading in a missing family that was needed, etc. In those situations it would be ideal to resolve the missing item, and re-enable the IUpdater back up.

Thank you.

[jeremy_tammik]

Thank you for the interesting question.

If all else fails, have you tried to unregister the updater and reinitialise it completely from scratch?

Or, even more extremely, maybe even change its GUID, so that every failed updater GUID is discarded, and a new one issued on every failure?

Anyway, I have asked the development team whether they have any constructive suggestions for you.

[jeremy_tammik · Accepted solution]

The devteam respond: this is asking the question in the wrong way.

If it's critical to keep the Updater functional, it's on the implementer to ensure that exceptions are not passed back to Revit.

Of course, there are runtime things (System exceptions) that they may not want to catch and deal with, but if the exceptions are thrown from Revit API calls when the updater tries to do it's work, I'd suggest the updater catch and deal with them.

It may be that once a callback or interface class starts throwing exceptions, it goes put on the "naughty list".

There may be no way to recover from that in the current session.

[RPTHOMAS108]

The only possible approach perhaps since that is a failure would be to deal with the failure:

Autodesk.Revit.DB.BuiltInFailures.DocumentFailures.DUMisbehavingUpdater 

If you are able to cancel rather than user doing it (not sure) you are then able to the disable your updater yourself and know about it. 

I've long found this approach to 'suspending' rather than disabling DMU's very problematic. For example people have asked me 'why can't you make it so pile coordinates are updated automatically when they are moved?' In theory I know I could use a DMU for this but what happens if it gets disabled halfway through an alteration and the user assumes something is being updated when it is not? I then potentially have a pile schedule with incorrect coordinates being sent out and the distinct possibility of very expensive work being done in the wrong place (I hope some sanity check would prevent that but you never know). These are the users that say "I'm just the guy pressing the button (your button)!"

You need some fail to safe approach really. So prefer press a button at a certain point to do a task then check the results against previous before issue. Even for the most simplistic code DMU's have the potential to be disabled due to complex interactions i.e. you can account for your own code but not that of other DMU's by others and the timings of such (the impacts for the states of elements these have between your interactions).

[jeremy_tammik]

Dear Richard,

Thank you as ever for your words of wisdom from experience. I find them very convincing and passed them on to the development team.

Cheers,

Jeremy

[RPTHOMAS108]

Thanks Jeremy

These issue go beyond the code we produce so I think that it is always good to have those caveats regarding what we expect from IUpdaters and what users should expect. I'm not against them, they are great and 99% they work fine.

It is more the need for verification between issues really, things everyone should be doing anyway.

[rvtquestions]

Thank you @jeremy_tammik & @RPTHOMAS108 for your contributions. I will have to agree as well, the ideal action would be to deal with the error and prevent it from happening in the first place, such is the game of programming. I just wanted to make sure I wasn't missing anything obvious to bring the updater back to life but it seems after its been disabled by an ERROR, the user will have to restart the session (with of course ideally addressing the issue to not happen again).