SEHException when CreatingGroup during Updater

[clwi]

We got a function that generates 2D symbols for Rebars in Revit. They Consist of FamilyInstances and DetailLines.

All Elements that is created for each Rebar is grouped and the GroupID is stored as a Parameter on the Rebar.

Each time the command is run, it deletes the Group stored on the Rebar Parameter and re-creates everything that's needed.

Running the function manually it works perfectly but when called from an Updater it crashes on the following line:

Group grp = view.Document.Create.NewGroup(collectionToGroup);

With the following Exception:

System.Runtime.InteropServices.SEHException occurred

  HResult=-2147467259

  Message=External component has thrown an exception.

  Source=RevitAPI

  ErrorCode=-2147467259

  StackTrace:

       at ElementGroupType.createBackup(ADocument* , ElementId , Boolean* , ElementId )

       at Autodesk.Revit.Creation.ItemFactoryBase.NewGroup(ICollection`1 elementIds)

       at AECAB.Structure.Rebar2D.RebarHelperFunctions.Add2DDetalingToRebar(Element el, View view, DetailCurve& MainRebarCurve, Settings settings) in C:\tfs\AECPlus\Revit\2017\Kod\AECABStructual\Rebar2D\HelperFunctions\RebarHelperFunctions.cs:line 658

  InnerException:

 Is this a bug in Revit or am I missing something?

[Anonymous]

The IUpdater documentation lists a host of methods that cannot be called (ones that "introduce cross references between elements").  NewGroup is not specifically listed and is apparently not throwing the ForbiddenForDynamicUpdateException so in order to figure it out, your best bet is to put together a minimally reproducible case: simple updater, app that registers it, simple file, and addin and post it here so that the Autodesk team can investigate the problem.  This type of exception sometimes suggests a potential bug on the Revit side but they need a reproducible case to make that determination.

strip out all unnecessary steps, just the newLine and the newGroup calls, see if you can reproduce it that way and then post the zipped reproducible case with addin file and specific instructions on how to reproduce. 

here is an example:

https://forums.autodesk.com/t5/revit-api-forum/sehexception-on-checkoutelements/m-p/6049533#M14462

[clwi]

Yes, I'll try to reproduce this issue in a more clean project and post it here as soon as I can.

Thanks for the information.

[clwi]

Got an Updater example with example project file attached below.

Video in zip: NewGroupUpdater_SEHException.swf

/Claes

[matthew_taylor]

Hi Claes,

I've had a quick run over your code.

There are some issues.

1. The subtransactions don't appear to be necessary at all, unless you have the need to roll something back.
2. I could create a group with an updater, but *not* with the elements created within the updater. This makes sense as they haven't been added to the database yet. This will be why your exception is throwing (the first time at least).
3. When creating a group within the updater, I'm pretty sure the updater fires again as the elements added to the group are modified as a consequence of the grouping.
4. I understand why you'd want to add lines and group/regroup them with a newly created rebar, but I don't understand why you'd want to do this when modifying a rebar each time.

While I understand what you are trying to do, I wonder if there is a better way of approaching it? Could you add the updater to the relevant group category? Is there a different workflow you could use?

Anyway, I hope this helps!

Cheers,

-Matt

[clwi]

Hi Matt, thanks for the reply.

The example code I got doesn't reflect our project to a full extent, to explain it a bit better what happens for us and why some things need to be changed/recreated.

Since we move or change the Rebar(in our case) it could reflect that the placement of the 2Dsymbols that we're creating showing lines and various symbols depending on the rebar. if the rebar is changed, the placement of the lines drawn should center once again depending on the change(that's why we're currently deleting everything(the whole group so to speak) and re-create them again, reding new FamilyInstances of the symbols we're using and drawing New DetailLines etc that's needed.

Perhaps like you say there's a better workflow(none that I can think of from the top of my head).

In our application we give the user an option to enable/disable the updater so it doesn't nessesary is active the whole time someone changes a rebar, but for thoose working with rebars and what them to show and reflect the corresponding 2D symbols, we more or less need to update the information regulary.

/Claes

[matthew_taylor]

Hi Claes,

Is it possible to repurpose the lines and familyinstances that you already have in the existing group? (Change the location curve, family symbol etc)

That would stop the need for creating a group at all. It would be just modifying an existing group, and the warning that that creates (modifying the only instance of group) can be suppressed.

I believe you can probably do what you want without the Group. Your updater would need to store the unique Ids of the associated symbols and lines (extensible storage?), so that modifying the rebar would trigger your updater to check the lines/symbols. You could allow/deny (manual) editing of the lines/symbols as required.

The method required would be as little like that shown in this blog post of Jeremy's:

http://thebuildingcoder.typepad.com/blog/2010/08/structural-dynamic-model-update-sample.html

Cheers,

-Matt