Position of elbow for varying length rebar tags

[miguelmachadoecosta]

I'm creating tags for rebars:

newIndTag = IndependentTag.Create(doc, vista.Id, New Reference(rebar), True, TagMode.TM_ADDBY_CATEGORY, TagOrientation.Horizontal, New XYZ(0, 0, 0))

Then I'm defining the position of the elbow. It is working for every tag except those referencing rebars with variable length. For those I'm getting an error saying that "the reference is not currently tagged":

I tried all these options and I'm getting the same error for all of them:

option 1:

newIndTag.SetLeaderElbow(New Reference(rebar), position)

option 2:

newIndTag.SetLeaderElbow(newIndTag.GetTaggedReferences.First, position)

option 3:

Dim rebar As Rebar = DirectCast(doc.GetElement(newIndTag.GetTaggedElementIds().First.HostElementId), Rebar)
newIndTag.SetLeaderElbow(New Reference(rebar), position)

option 4:

Dim rebar As Rebar = DirectCast(doc.GetElement(newIndTag.GetTaggedLocalElementIds().First), Rebar)
newIndTag.SetLeaderElbow(New Reference(rebar), position)

option 5:

newIndTag.SetLeaderElbow(New Reference(newIndTag.GetTaggedLocalElements.First), position)

With Revit Lookup if I try to check the list of tagged references of a manually created tag for varying length rebar I also get an error saying "object reference not set to an instance of an object":

I suppose this behaviour isn't normal. Is there a way I can create tags for varying length rebars while also defining the elbow position? I suppose I have to find another way of getting the reference Revit is using for these tags.

Thanks in advance.

[jeremy_tammik]

Yup, doesn't sound normal.

Can you produce a minimal reproducible case for the development team to analyse?

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

I went ahead and asked them whether they have any advice, so maybe we can wait and see what they suggest first.

[jeremy_tammik]

They did indeed reply as I suspected they would:

Can you please provide a minimal reproducible case and a sample Revit file?

Also, it would be helpful to know which Revit version is the customer using, because the tag's API underwent some significant changes last year.

Thank you!

[miguelmachadoecosta]

Hi @jeremy_tammik,

Thank you for you reply.

Please find attached a project file with a wall, a beam and two rebars, with a macro called "test" embedded that should be run in the detail view.

One rebar has variable length, the other doesn't. You can see that only the variable one causes the error.

While making this minimal project I realised that if I purge the other type of the tag family the error doesn't occur, but the elbow isn't placed either.

I left two tags, for both rebars. You can check that if you select the upper one the "Select Host" but is greyed out, while for the other isn't:

You can also check that with Revit Lookup you get the error that I illustrated in my first post only for the upper tag.

I'm testing with Revit 2022.1.

[miguelmachadoecosta]

@jeremy_tammik, did you get any feedback from the development team?

Thank you

[jeremy_tammik · Accepted solution]

Yes, I did. They say:

I can confirm this behaviour with Revit 2022, due to the Multi-Leader tag implementation.

 
The only workaround I can think of is to continue to use the deprecated property LeaderElbow when dealing with varying rebar sets or free form rebar and to change it to SetLeaderElbow(Reference) when team Impaler will fix this:

LeaderElbow = new XYZ(5, 5, 0);
// Instead Of
//tag.SetLeaderElbow(new Reference(rebar), new XYZ(5,5, 0));

Revit 2022 introduced a new API method setLeaderElbow which inputs a Reference and validates that the reference is tagged ( isReferenceTagged ).

 
Rebar ( even varying one ) didn't have proper subelements at the time. So, the user correctly creates the tag by just passing new Reference(rebar) as a creation argument for the tag, so initially the rebar is stored as (rebarId, -1).

 
Once you start manipulating the tag TagSubelementKeyRegenStep::executeOrGetParents executes and asks the rebar's subelement helper for 'getNearestKeyToPoint' which returns a bar index and the information inside the tag becomes (rebarId, barIdx).

 
Now, when the API user asks for the rebar target, it basically asks for (rebarId, -1) which is no longer a target.

In the next major release of Revit, this won't be a problem, because rebar now has proper subelements.

Since the problem has been resolved in the current (internal) codebase, I hope the provided workaround is good enough for the moment.

Best regards,

Jeremy

[miguelmachadoecosta]

Thank you @jeremy_tammik. I already tested and I can confirm that it works for now.

I hadn't think of using the deprecated property. When the new major version is released I'll update for the new method.

I'll also be looking forward for the subelements implementation. It may at least simplify a few thing when obtaining geometries.

[jeremy_tammik]

I submitted a development ticket REVIT-183943 [Error setting elbow on tag of varying length rebar] for you reporting this problem.

[miguelmachadoecosta]

Thank you. I'll keep an eye on future release notes.