Accessing Warning List

Accessing Warning List

Anonymous
Not applicable
3,169 Views
12 Replies
Message 1 of 13

Accessing Warning List

Anonymous
Not applicable

Is it possible to access this warning list using API?

 

 

2013-05-16_0905.png

0 Likes
Accepted solutions (1)
3,170 Views
12 Replies
Replies (12)
Message 2 of 13

Anonymous
Not applicable
Accepted solution

Unfortunately it's not.  I've searched for it in the API and at AU last year confirmed that it isn't possible at the Revit API Roundtable.  The best you can do it manually export the warnings list to html and create an add-in that reads that html file.

 

I also read through the What's New in the Revit 2014 API and didn't see anything mentioning it either.

 

If you can login to the AU site, I think it's mentioned in the class notes under 'Additional Class Materials'.

http://au.autodesk.com/?nd=class&session_id=10416

Message 3 of 13

arnostlobel
Alumni
Alumni

Please refer to the FailureProcessing event and related classes (FailuresAccessor, FailureResolution, etc.) in the API help.

For transactions own by your application, you can also pre-screen the list of failures using a FailuresPreprocessor. Please refer to the documentation for Transaction class, specifically to FailureHandlingOptions.SetFailuresPreprocessor

 

Thank you

 

Arnošt Löbel

Autodesk Revit R&D

Arnošt Löbel
0 Likes
Message 4 of 13

Anonymous
Not applicable

Thanks Arnost. 

 

Unfortunately we're trying to access warnings that occurred in the past and are stored in the document.  These warnings or failures could have fired weeks ago and while the FailureProcessing event and FailuresPreprocessor assist with warnings your add-in may generate, it doesn't provide access to a list of failures that occurred in the past.

0 Likes
Message 5 of 13

arnostlobel
Alumni
Alumni

Hello Josef,

 

Thank you for the clarification. Indeed it is something different than what I thought it was, and we do not currently have an API for accessing past warnings. However, there may be a viable workaround that is probably worth exploring. Now, I have not tried it yet, but there is a “Review warnings” command somewhere in Revit which, when invoked, shows all those old warnings if any. Actually, how it does it is interesting – it does not just grab and show the warnings; instead it takes the warnings, posts them again, and let the standard failure handling mechanism do the displaying. So, it seems you might be able to get them after all. You would need to a) Write an event handler for the failure processing event. The event should be raised after the failures are posted and before the command’s transaction is finished. And you would also need to b) Programmatically invoke the “Review Warnings” command. I do not actually know if that command is one of those that could be invoked via the API, but chances are it is (I am talking R2014, of course). You may give it a try and see if it works like I expect it to.

 

If that does not work at all, and if there is more interest in the future, we will consider creating a specific API for it. (It had been considered before, but did not get a lot of attention.)

 

Arnošt Löbel

Autodesk Revit R&D

Arnošt Löbel
0 Likes
Message 6 of 13

Anonymous
Not applicable

I am reading this: http://wikihelp.autodesk.com/Revit/enu/2014/Help/3665-Developers/0135-Advanced135/0153-Commands

 

It sounds like a command may be posted only after the API application execution is completed. So if this is the case, it will not be possible to embed it inside a transaction. Or am I missing something here?

0 Likes
Message 7 of 13

arnostlobel
Alumni
Alumni

A Revit command is posted during API execution, but, yes, it should be the last thing done and it is actuallyy executed only after the external command completes its execution.

You may not post a command from inside your transaction, but you should not need to, if I understand correctly what you try to achieve. You set up a failure handler, and you post the command. When the command gets executed, it'll start a transaction during which the old warnings are re-posted, upon which time your failure handler gets invoked. From the handler you can collect all failures using a failure accessor. Isn’t that what you wanted?

 

Arnošt Löbel

Autodesk Revit R&D

Arnošt Löbel
0 Likes
Message 8 of 13

Anonymous
Not applicable

Thanks for the explanation, I think I get it now. I'll give it a shot.

0 Likes
Message 9 of 13

Anonymous
Not applicable

Hi Patrick,

 

Were you able to use Arnost's suggestion to read out the current Revit warnings?

0 Likes
Message 10 of 13

Ning_Zhou
Advocate
Advocate

hi Arnošt, i tried your suggestion, and it's almost working except that i cannot make retrievd info (i.e. element ids) from failure accessor to do meaningful work, for instance, isolate or even delete some elements, i tried both in failure processing mode and in current command scope

1) in failure processing mode, document changes is prohibited

2) in current command scope, posted command is executed only after the external command completes its execution, so no way to use "future" retrievd info for "present" use, isn't it? any workaround?

see below code snippet for your info

public class Command : IExternalCommand
{
   List<ICollection<ElementId>> lst = new List<ICollection<ElementId>>();
   public Autodesk.Revit.UI.Result Execute(ExternalCommandData commandData, ref string message, Autodesk.Revit.DB.ElementSet elements)
   {
      ...
      app.Application.FailuresProcessing += new EventHandler<FailuresProcessingEventArgs>(FailuresProcessing);
      RevitCommandId id = RevitCommandId.LookupPostableCommandId(PostableCommand.ReviewWarnings);
      AddInCommandBinding binding = app.CreateAddInCommandBinding(id);
      app.PostCommand(id);
      TaskDialog.Show("testing", lst.Count.ToString()); // this will always return default value 0

      ... // do some document changes based on these element ids
      return Result.Succeeded;
   }

   private void FailuresProcessing(object sender, FailuresProcessingEventArgs e)

   {

      ...

   }

}

Message 11 of 13

arnostlobel
Alumni
Alumni
Ning_Zhou,

I am very sorry, but I have currently limited time to devote answering questions and analyzing problem in this API forum, or any forum for that matter. I am afraid I am backed up until Christmas, and I expect my presence will be spotty a couple of weeks after the holiday break, as we are going to move from one office to another in Boston.

However, I have notice something interesting in you recent post and I want to comment on it:

Posting a command is supposed to be the last think an application should do in a current context. For example, if posting happens in an External command, it is supposed to be on the last time just before the return statement. Ideally, the code should already be out of any transaction. There is no point of doing anything after a posting command, since posting is asynchronous and will be executed only after returning from the external command. Basically, the posted command is though as a continuation of your external command.

Thanks. Please keep this thread alive so it bubbles up in my queue and I do not lose a track it.

Arnošt
Arnošt Löbel
0 Likes
Message 12 of 13

Ning_Zhou
Advocate
Advocate
got it Arnošt, thanks and Merry Christmas in advance!
0 Likes
Message 13 of 13

Dale.Bartlett
Collaborator
Collaborator
Has anyone had any success with this technique?



______________
Yes, I'm Satoshi.
0 Likes