Can't suppress Group change is allowed warning

[m.de.vriesTH5VM]

In my code I create a group from elements that were just added.

Within the same transaction I set the name of the group to make it recognisable and more easily selectable by the user.

When I Commit the changes (i.e. creating the group and renaming it) I get a warning message that a property of the group was changed but that it is allowed because there is only one instance.

Apart from the more general question of why that message is even there in the first place, this warning message is confusing to the end users.

This being a warning I should be able to suppress it with the following IFailuresPreprocessor (which is basically the same one everybody copies from the forums)

	public class GroupEditing : IFailuresPreprocessor
	{
		#region Public Methods
 
		public FailureProcessingResult PreprocessFailures(FailuresAccessor a)
		{
			IList<FailureMessageAccessor> failures = a.GetFailureMessages();
 
			foreach (FailureMessageAccessor f in failures)
			{
				// FailureDefinitionId id = f.GetFailureDefinitionId();
				FailureMessage fm = f.CloneFailureMessage();
 
				/*
				if (f.GetDescriptionText().Contains("Changes to groups are allowed only in group edit mode"))
				{
				   break;
				}
				*/
 
				FailureSeverity failureSeverity = a.GetSeverity();
				switch (failureSeverity)
				{
					case FailureSeverity.Warning:
						a.DeleteWarning(f);
						break;
					case FailureSeverity.Error:
						a.PostFailure(fm);
						break;
					default:
						return FailureProcessingResult.ProceedWithRollBack;
				}
			}
 
			return FailureProcessingResult.Continue;
		}
 
		#endregion
	}

When I run the code to create the group this preprocessor gets triggered with one MessageAccessor in it.

Single stepping through the function I can see that this is a warning, that the description of the warning matches the text from the popup and that the failure is removed from the FailuresAccessor.

The FailureDefinitionId has guid {c519d291-2e28-4075-b0d0-3cbc8c848bc2}

and DescriptionText "A group has been changed outside group edit mode. The change is being allowed because there is only one instance of the type."

After leaving the function Revit then still shows the popup with this warning, as if it was not deleted.

I am using this FailuresPreprocessor in other situations as well without problem (deleted warnings stay deleted)

I am at a bit of a loss what I could be doing wrong here, as other people reported that using this same preprocessor successfully prevented this exact popup from being shown.

[naveen.kumar.t]

Hi @m.de.vriesTH5VM ,

Please take a look at this below link

https://thebuildingcoder.typepad.com/blog/2010/08/editing-elements-inside-groups.html 

[m.de.vriesTH5VM]

Thank you for your reply but I am afraid this is not helpful to me.

The link points to an article that explains in detail how to use the FailuresPreprocessor and gives several VisualBasic examples. I actually used this exact article by Jeremey Tammick to create the C# version of the class to suppress failures that I included in my question. The only difference is that I am not filtering for specific warnings and just suppress all warning messages.

The class is working correctly as far as I can tell and the example I based it on is an answer to the exact warning message that I am trying to suppress.

Except that for some reason I cannot figure out it does not work for my application. As I said, I can single step through the code and see that the call to delete this specific warning is executed, only to have it displayed anyway.

The only thing I can think of is that returning Continue is somehow wrong, but everybody  who discusses using the FailuresPreprocessor  agrees that as long as you are only deleting warnings it does not matter if you return Continue or ProceedWithCommit (and that returning Continue has less risk of something going wrong)

[naveen.kumar.t]

Hi @m.de.vriesTH5VM ,

You mentioned that for some reason you could not figure out why it did not work for your application.

It looks like the issue is related to your particular application.

To analyze this issue, Could you please provide us the below details?

1)A short exact description of what you are trying to achieve.
2)The behavior you observe versus what you expect, and why this is a problem.
3)A complete yet minimal Revit sample model to run a test in.
4)A complete yet minimal Visual Studio solution that can be compiled, loaded, run, and debugged with a single click to analyze its behavior live in the sample model.
5)Detailed step-by-step instructions for reproducing the issue.
6)Details of the Revit version you are using.