Warning can't be dismissed

[BenoitE&A]

Hi all,

We have created a plug-in which creates views with a specific crop region which we compute.

Since we don't want the user to get the Warning messages concerning sketch angle inaccuracies we created a swallower to dismiss these automatically.

Still, in one project the warning can not be dismissed. It appears in the UI and the user can only use Cancel, the Ok button is not allowed. Of course cancelling is bad for our solution since the user does not get his job done.

When we check the model we were not able to find the angle inaccuracy showed by Revit and our crop region looks fine.

The question is: can you tell us why this happens? In which cases? 

Thanks !

[BenoitE&A]

Any news from Autodesk ?

[naveen.kumar.t]

Hi @BenoitE&A ,

I feel it is not a warning, but an error.

new-warning-with-only-cancel-button

[BenoitE&A]

Hey Naveen,

Thanks for the thread, I had not read it.

But no, it is a warning and not an error.

[naveen.kumar.t]

Hi @BenoitE&A ,

Now I understood. This type of warning cannot be ignored or suppressed by Revit API.

This leaves you the option to cancel and rethink your current task and in some cases, you have to use the action button and take Revit’s suggested remedy. Keep in mind that this is not always the preferred remedy.

What does Revit's Suggestion say?

Does the same problem occur when you try to crop via UI without using API?

 My suggestion is to adjust the crop region.

With the information you provided, I'm not able to recreate your issue. If possible can you please provide us a screenshot which will help us to understand your problem a bit more?

[BenoitE&A]

Hi Naveen,

Thanks to your answer, here are a few points:

- the warning does not offer suggestions and can not be dismissed. The only available choice is Cancel, which will in the end cancel the process.

- of course the problem does not occur when we do it manually. We suspect that the problem comes from a slight shift we introduced in one point of the crop region which makes one of the boundary segments slightly slopped. But the fact is, we need that shift to run our algo !! And I don't see how I would put the boundary "straight".

What we don't understand is: the shift is less than 1mm (about the size of Revit's ShortCurveTolerance) and Revit used to be able to deal with this warning rather than throwing back a Warning which it can not resolve. What has changed?

And finally: I am not sure of how Revit deals with Errors / Warnings. What makes it throw this one rather than swallowing it? Do you have documentation about this so we understand this issue?

[naveen.kumar.t]

Hi @BenoitE&A ,

I tried to edit the crop box boundary and the code is working fine for me.

How did you edit the crop box boundary (i.e)by using which method?

Have you tried using ViewCropRegionShapeManager 

The problem you mentioned occurs if the crop box boundary is not properly enclosed?

You said your crop box boundary looks fine and the shift is just 1mm. Are you sure crop box boundary is properly enclosed and there is no extra projection line ? (like this in the picture I attached)

I tried to recreate your issue but I failed. The problem may be with the specific file.

It is difficult for us to understand what is happening in your end.

If Possible Can you please explain the step by step process to recreate the file?

Thank you for your patience.

I hope this helps.

[BenoitE&A]

Hi Naveen,

Thanks for you time too.

I don't want to explain here the exact process we use, we can explain it to you in private. 

The idea is to create a new view with a specific crop region which we compute. Indeed we use  ViewCropRegionShapeManager  to apply this crop region.

The issue occurs when one of the points of the crop region is moved by a few tolerances from its original position and you try to apply the CropRegion again. I think you can try this (get the crop region of a file, not a rectangle, and move one or 2 points by 2 or 3 tolerances, and apply the new crop region to your view). 

We (and mostly our clients) made about 5 000 views using our tool, which used to work until recently. Now we fire very often this warning which used to be swallowed and we don't get why. 

[naveen.kumar.t]

Hi @BenoitE&A ,

I tried using the code in the resize-cropbox-of-view.

Here whatever maybe your previous cropbox shape, you can set new crop box shape using ViewCropRegionShapeManager.

I tried to change the crop box shape from rectangular to non-rectangular even pentagon shapes.

I even tried moving one or 2 points by 2 or 3 tolerances and it worked fine for me.

The shape of your new crop box depends upon the curves in the curve array you are passing so it doesn't matter what the shape your previous cropbox was.

(please do not share any confidential data)

[BenoitE&A]

Hi,

Yes I had tried that (moving some points from a few tolerances) and I know it does not raise any issue on our models. But we still have the Warning issue on our clients models and we need to understand why.

So I am back with my 2 questions:

1) Do you (Autodesk) have any idea why this warning shows and can not be dismissed? Could it be a change in 2019's version vs 2018's?

2) Do you have documentations on warnings and errors (I understand warnings and errors have a severity index) so that we can understand this?

Thanks !

[BenoitE&A]

Any news ?

[naveen.kumar.t]

Hi @BenoitE&A ,

You can learn about Revit warnings in understanding-Revit-warnings.

As I already mentioned you have to provide us simple non-confidential case which will help us to recreate your problem.

If you go through the link then you will come to know that the warning you are receiving cannot be ignored and you have to take some actions in your project to get rid of that warning.

[BenoitE&A]

Hi Naveen,

Thanks for the link.

Still my question remains: how are the warnings/errors adressed by Revit? What makes a Warning a warning rather than an error? Severity?

And why is that that we have warning messages (it says that it can be ignored) while in fact they can't?

[BenoitE&A]

Hi,

Any news? 

I read what I found on that topic (https://archi-lab.net/digging-through-revit-warnings-to-find-meaning/ or https://gist.github.com/ksobon/dbfdbede392760312afccc7fb99cb0d6#file-allrevitwarnings-py) and least I can say is: there is not much (and fewer even from Autodesk).

So I'm back with my 2 previous questions... with a third one: could Autodesk open the Warnings in the API so we can adress them?

[jeremytammik]

Dear Benoit,

Thank you for your query, patience and perseverance with this, many thanks to Naveen for all his work on it, and sorry that this seems to be such a hard nut to crack. Also, sorry that the documentation is not better.

Do I understand correctly that your technical issues have been resolved and you are just waiting for answers from Autodesk on your remaining questions?

Here are attempts at a couple of partial answers for you:

> Does Autodesk have any idea why this warning shows and cannot be dismissed?

I suspect probably not.

> Could it be a change in Revit 2019 vs Revit 2018?

Yes, of course it could. A reproducible test case would be useful to nail this down.

> Do you have documentations on warnings and errors?

Not that I am aware of. The resources pointed out above seem to hint that the kind of documentation you are searching for is meagre.

> How are the warnings/errors addressed by Revit? What makes a Warning a warning rather than an error? Severity? Why is that that we have warning messages that cannot be ignored?

I can pass this one on to the development team for you and see what they have to say.

> Could you provide a screen snapshot of the warning you mean?

In order for the development team to analyse it in any depth, they will need a reproducible case:

https://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

> Could Autodesk open the Warnings in the API so we can address them?

Yes, of course. That is a question of priorities decided by the product managers and their teams.

In order to bring such a wish into discussion, please submit it in the Revit Idea Station and ensure that it gets many votes.

I hope this helps.

Best regards,

Jeremy

[BenoitE&A · Accepted solution]

Hi,

Digging into the code we found out the following : 

We have a major difference between this : 

if (failure.GetFailureDefinitionId() == BuiltInFailures.InaccurateFailures.InaccurateSketchLine && !failureDeleted)
                {
                    failuresAccessor.DeleteWarning(failure);
                    failureDeleted = true;
                }
                
                if (failure.GetFailureDefinitionId()== BuiltInFailures.RoomFailures.RoomNotEnclosed && !failureDeleted)
                {
                    failuresAccessor.DeleteWarning(failure);
                    failureDeleted = true;
                }

and this :

FailureDefinitionId fdi = failure.GetFailureDefinitionId();
               if (fdi == BuiltInFailures.InaccurateFailures.InaccurateSketchLine && !failureDeleted)
                {
                    failuresAccessor.DeleteWarning(failure);
                    failureDeleted = true;
                }
                
                if (fdi == BuiltInFailures.RoomFailures.RoomNotEnclosed && !failureDeleted)
                {
                    failuresAccessor.DeleteWarning(failure);
                    failureDeleted = true;
                }

Do you have any idea why ?

[cwaluga]

I suspect that deleting the failure warning causes side-effects in the second conditional statement. I would use a different control flow anyway. Use switch/case or if/else if instead of the failureDeleted flag.

[BenoitE&A]

Of course we agree with your advice, but we have already found that out.

Bottom line, I am unsure you are right on the explanation though. We suspect that in the case of multiple warnings the

GetFailureDefinitionId()

 modifies the order of the warnings. 

But it is exactly what we are asking Autodesk here...

[cwaluga]

It simply makes no sense that a reordering occurs when you ask an object for its Id. Then again, if seen worse in the API.

Anyway, you can what you want with my hint. I’m just saying that querying an object that you just deleted screams undefined behavior. No wonder these two codes deliver something different, they are in fact semantically different.

What you suspect can be easily investigated by doing subsequent calls to the method without deleting in between.

[BenoitE&A]

You are absolutely right and sorry if my previous message meant you were not. 

It's just that we tested adding else if and nothing changes...