Clicking on "MEP Connector info" causes Revit to crash

[chrishildebran]

When examining Fabrication Parts, specifically Fabrication piping, in the Revit Lookup tool a crash will occur when the Method "GetMEPConnectorInfo" for a Connector is clicked. This happens for me, our Fabrication Database manager as well as our BIM/VC Director.

[jeremytammik]

Hi Chris. Thank you for letting me know. That is probably quite easy to fix, by wrapping a line or two in an exception handler. What exact exception is thrown? Which exact line of code causes it? Can you fix this and submit a pull request for me to integrate? Thank you!

[chrishildebran]

I sure will Jeremy.

[StDistraxion]

I am completely floored!! May i message you two somehow? I've never collaborated here, why it never occurred to me i will never know... I've been dealing with the quirks between Revit and the FabricationAPI for 3 years now, and literally this is the first time I've seen a post directly dealing with it and its friends. I am more than willing to help work on this thing, im glad you posted this... it has been an interesting adventure. Matter of fact just the other day @jeremytammik helped me solve an issue i found back in 2018. Sorry, im just shocked, this tool is wonderful. If this is the first time you were made aware of this one, i may be able to point you into several places here and all throughout whatever touches the Fabrication namespace, as well as many external ones... as well as a a long list of dlls within the Revit folder itself. My copy was outdated, and it seemed so minor i thought it was just my machine - but this has actually been happening since 2018... on my machine, anyway, i thought it was just me...

While i am absolutely no expert, by any means, i am very familiar with the fabrication side of things, especially for Revit, if you ever get stuck or just want an opinion there is a very real chance i may have had to work around it or otherwise sorted it out, please feel free to ask - and now that ive caught up with the times I will be posting here as well...

There are a few spots this is happening elsewhere, too, so if i throw in what i have found for this tool who knows what it may become.... Anyway hi, thank you, caffeine is your friend. I'll leave now :)

[jeremytammik]

@StDistraxion thank you for your offer, and yes, absolutely, your help is more than welcome!

[StDistraxion]

Right, awesome - much better than the forums - though they serve a purpose, for sure... I literally have no clue why it never occurred to me...

Yes, the call to GetMEPConnectorInfo() causes it to crash - because FabricationParts do not have MEPConnector information, they have FabricationConnectorInfo() - the field right above it...

And, in light of that, the opposite is true as well - if you try to snoop FabricationConnectorInfo() on a FamilyInstance - or anything not fabrication - you get the same result... Just to give you a heads up there. FabricationPart.ConnectorManager.Connectors.ElementAt(i).GetMEPConnectorInfo() [image: image.png]

I had actually made several custom things for me and my team from this tool... To prove something to a team in Australia i made a PrintObjectsSnoop tool, to show them that yes, in fact, you can get the print object data, all of it, and it does have values, and the stuff their RestAPI was throwing back to my team was wrong... But then Covid hit, i got laid off cause contractors go first, and spent a year not being allowed to touch anything... so i have missed a lot.

Boy have i got some stuff to tell revit, especially about auto-connectivity and automatic updaters, and the list exists ill just leave it at that...

But this issue was the very, very first error i ever encountered while debugging revit back then... Honestly i have never been able to tell whether any of the people i have interacted with actually work for Autodesk... And we use this tool so much day to day while researching issues or deciding on how to do what we need, and it just shocked me no one had mentioned it to you... I thought it was just me lol

So yes, please, if you or anyone gets stumped on FabParts - while there are things i cannot do and sectors i cannot touch for other people, there is nothing stopping me from say hey, look here...

The biggest problems we just corrected in our tools were traversal problems dealing with connectivity when attempting to select a connected system - 0 and 1 are entirely dependent upon how the family is drawn AND how the user or auto-routing decides to draw - that was fun...

FabricationPart.AddPartCustomData() - although it is a boolean function that is supposed to return false if it fails, always throws an exception instead - which is fine, just a super hit on performance...

The updaters, for whatever reason, if you disable it before running your tool and enable it at the end in a finally (or any time) is supposed to fire once immediately when it is turned back on to catch all changes while it was off? Not a single fire when you are dealing with assemblies... Not only that, if you toggle it off first, it acts as expected firing after every transaction when in fact it is supposed to NOT fire - moreover, the AssemblyTypeName it contains does not have the new name if you renamed it, it keeps the default convention, and moreover it always skips the first assembly created...

Connector.IsConnectedTo(Connector) throws an exception if the connector is not a Physical type. Same goes for any function related to testing if it is connected. This applies to any connector.

Hmm.... FabricationPart.ConnectAndCouple() is the only function that manually triggers AutoConnectivity in Revit, ConnectTo does not nor does any other of the function calls. It will place a joint or coupling if the rule exists...

ConnectorIds > 1 on straights WILL disappear when you disconnect, and ConnectorManager.Connectors and UnusedConnectors do not return connectors in the same order each call, so be careful though im sure you knew this one...

Inerference Check under Collaboration comlpletely ignores FabricationParts, they are not eligible for ANY Element or GeometryIntersectsFilters excepting only BoundingBoxFilter, and the InterferenceCheck tool uses code from and old old CAD library, and the team responsible for maintaining it has apparently been gone for over a decade... So there's that. We just wrote our own clash tool that works just as fast but can work on fab parts. I intend to hit it with the FailureAPI and see if it is faster, as the Show function in that thing apparently has way more access than the UiDocument one.

I am only listing these out because honestly we are so swamped i dont know when we will get to it, and i dont know what you know or dont know specific to these namespaces, if you knew 90% of these im sorry it was so long winded... I could never find anyone to reach out to, so i always waited until it was something i could simplify or explain in terms of Revit elements before i could ask anyone a question...

Oh there is so much to tell... Ah, right - Groups and Assemblies, as i am certain you must know the difference in behavior - if you change a parameter in one group, it sets that parameter for every instance of that group in the project... Makes automatic updaters lose their minds... especially if you are touching custom data at the same time... Assemblies, however, can contain both Revit and Fabrication elements, except each is an individual only the naming convention is shared pretty much...

Ill stop, just babbling i am so brain dead after last week...

If any of this leads you somewhere, have at it. I'm so used to all of it i forget a lot of it right this moment... But those were the big ones.

On Thu, Feb 25, 2021 at 3:50 PM Jeremy Tammik notifications@github.com wrote:

@StDistraxion https://github.com/StDistraxion thank you for your offer, and yes, absolutely, your help is more than welcome!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-786251463, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP3ITGRBFNOUKDTJGIDTA3A2FANCNFSM4YE3GCMQ .

-- Matthew Anderson Distraxion Consulting Silent.Rain.127@gmail.com email (281) 432-7325 phone

[jeremytammik]

Thank you for your input.

No, this is not better than the forum.

The forum is read and commented on by many. You will only reach me and a few other maintainers of RevitLookup here.

I can happily edit your thoughts for a blog post on The Building Coder, if you would like to share your useful experience with a larger audience. In that case as well, though, the discussion forum is a more suitable platform to talk about them.

Yes, Revit API methods throwing exceptions on expected errors are a pain and a flaw.

Please submit a pull request for any and all errors that you discover and fix in RevitLookup.

Thank you!

[StDistraxion]

I apologize if i made too broad of statements - yes, the audience for the forum is way, way wider - just people are a little vicious in there lol.

I've no problem reworking all that for a post, when ive been coding for too long or when i get tired i babble quite a bit :) I would never expect or ask you to do that, at least not on the first draft... I have Snagit, i would send screen snippets and the whole nine yards... I just didn't how much of it you were already aware of or not, so more or less i was thinking you might have eliminated some of them from the pool - no biggie, i had to take a nap. Overhauling code that had been in our tools from the beginning over the past two days was pretty rough...

When i said this is better than the forum, i was referring specifically to two things - first, direct access to the developer of RevitLookup (you), insomuch as relating to this tool only... I forget sometimes you have the blog and some other posts/sites ive stumbled upon. My brain pretty much treats you like three different people because of it.

Second, it was about Git in general - it pains me to say as a programmer for some reason my brain never clicked to the idea that there is a near unmeasurable amount of collaborative opportunity on Github - i know it must have sounded like i was talking specifically about the RevitAPI Forum - that's my fault... Thus why i exited and went to bed for a minute.

I fully intend to make some forum posts regarding these and other things - because while yes it does in fact break RevitLookup to call the GetMEPConnectorInfo() from a fab part - in truth it causes Revit to crash too... We had just avoided it so much i basically forgot the function call existed at all until i saw that other developer's post on your repository. Literally the only two developers whom i have ever been able to ask anything about Fabrication in Revit were my previous team lead who abandoned them for Australia and the current one i work with/report to for tasks. While i highly doubt any of the plugins/routines i've written would impress you, considering what i know you are capable of for certain, I had just wanted to say there is a chance i may already have a workaround for just about anything Revit can throw at you with parts.

All last year i probably could have kept my wits about me by working with people on Git. I just default to only working for my team, and when covid hit and their boss said i had to stop until further notice - i kinda went stir crazy.

Anyway, yessir - it may be a couple days yet, but i will make some changes i wrote down way back when, if they are still an issue, as well as possibly some questions whose answers will tell me if i have more after that... In addition, for the breaking issues, i will post to ADN. That dock pane thing, i cant begin to tell you the relief of finally making those tools work. Having to fire a pick operation and a show in order for the editor to become active seems a bit silly to me, but hey - the damn thing fired properly it was one of the most huzzah! moments in a long while.

I talk a lot, sorry. Some day ill learn how to chop it down - living out in BFE southeast texas i dont get to talk very much :)

Have a good night, i hope my notes along the way proof useful to this tool, we use it extensively for research and troubleshooting.

On Thu, Feb 25, 2021 at 11:56 PM Jeremy Tammik notifications@github.com wrote:

Thank you for your input.

No, this is not better than the forum.

The forum is read and commented on by many. You will only reach me and a few other maintainers of RevitLookup here.

I can happily edit your thoughts for a blog post on The Building Coder, if you would like to share your useful experience with a larger audience. In that case as well, though, the discussion forum is a more suitable platform to talk about them.

Yes, Revit API methods throwing exceptions on expected errors are a pain and a flaw.

Please submit a pull request for any and all errors that you discover and fix in RevitLookup.

Thank you!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-786430599, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP4ZCQHGNXXWFBDJOPTTA4ZYZANCNFSM4YE3GCMQ .

-- Matthew Anderson Distraxion Consulting Silent.Rain.127@gmail.com email (281) 432-7325 phone

[jeremytammik]

I am not aware of any of the issues you mention, since i never work with fabrication parts.

in fact, i never work with revit at all. i just answer api questions.

also, i am not the developer of revitlookup, just the maintainer.

you are the developer (or can be).

looking forward very much to seeing what you cook up for us. :-)

thank you!

[StDistraxion]

Fair :)

But maintainer is as good as current developer in my book, but yes i do understand the distinction...

Alrighty, well, you will see it when it's there, should be later this afternoon, thanks again

On Fri, Feb 26, 2021 at 8:40 AM Jeremy Tammik notifications@github.com wrote:

I am not aware of any of the issues you mention, since i never work with fabrication parts.

in fact, i never work with revit at all. i just answer api questions.

also, i am not the developer of revitlookup, just the maintainer.

you are the developer (or can be).

looking forward very much to seeing what you cook up for us. :-)

thank you!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-786687345, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP422LSNF7ZAXKY4PXLTA6XGLANCNFSM4YE3GCMQ .

-- Matthew Anderson Distraxion Consulting Silent.Rain.127@gmail.com email (281) 432-7325 phone

[chrishildebran]

TLDR - @StDistraxion , which issue(s) are you going to focus on?

[StDistraxion]

The breaking ones... I know you are going to correct RevitLookup, but the break also affects Revit itself... If you have the time and gumption and mr. dude has submitted the pull request already, by all means have at it if you wish...

I think the traversal issue may be what i start with, i am swamped pretty much until 5pm CST over here, so i cannot guarantee a specific time.

The connectivity, and the issues with Updaters for sure i intend to post to the forum today.

On Fri, Feb 26, 2021 at 9:52 AM Chris Hildebran notifications@github.com wrote:

TLDR - @StDistraxion https://github.com/StDistraxion , which issue(s) are you going to focus on?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-786729622, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDPYYSLYXA4644BCQV6LTA67SNANCNFSM4YE3GCMQ .

-- Matthew Anderson Distraxion Consulting Silent.Rain.127@gmail.com email (281) 432-7325 phone

[RevitArkitek]

This appears to be a bug in Revit API, not Revit Lookup. I created the following macro:

    public void GetFabricationPartInfo()
    {
        UIDocument uidoc = this.ActiveUIDocument;
        Document doc = uidoc.Document;

        var selectedIds = uidoc.Selection.GetElementIds().ToList();
        var fabPart = doc.GetElement(selectedIds.First()) as FabricationPart;
        var connectionMgr = fabPart.ConnectorManager;
        var connectors = connectionMgr.Connectors;
        foreach (var obj in connectors)
        {
            var connector = obj as Connector;
            var mepConnectInfo = connector.GetMEPConnectorInfo();
            var linkedConnector = mepConnectInfo.LinkedConnector;
            if (linkedConnector != null)
            {
                Element owner = linkedConnector.Owner;
            }
        }
    }

Select a Fabrication Part and then run the macro. Theoretically nothing should happen, but Revit will crash (at the mepConnectInfo.LinkedConnector property). @jeremytammik If you could confirm this, and if so, please create an issue for development team.
The best we could do, if this is true, is to prevent the property from showing in Lookup until it is resolved. I can post a fix for Lookup to ignore the property if desired.

[StDistraxion]

Hello, Jeremy :)

I apologize for the disappearance - i fell ill shortly after we last spoke, and it's been one thing after another for a bit.

That being said, yes i will certainly confirm this when i get back to my desk at home here in a couple hours.

I notice right off the bat something looks slightly off on line 5, i will get back with you shortly :)

Matthew Anderson Distraxion Consulting @.** email (281) 432-7325 phone*

On Thu, May 6, 2021 at 12:13 PM RevitArkitek @.***> wrote:

This appears to be a bug in Revit API, not Revit Lookup. I created the following macro:

public void GetFabricationPartInfo() { UIDocument uidoc = this.ActiveUIDocument; Document doc = uidoc.Document;

  var selectedIds = uidoc.Selection.GetElementIds().ToList();
  var fabPart = doc.GetElement(selectedIds.First()) as FabricationPart;
  var connectionMgr = fabPart.ConnectorManager;
  var connectors = connectionMgr.Connectors;
  foreach (var obj in connectors)
  {
      var connector = obj as Connector;
      var mepConnectInfo = connector.GetMEPConnectorInfo();
      var linkedConnector = mepConnectInfo.LinkedConnector;
      if (linkedConnector != null)
      {
          Element owner = linkedConnector.Owner;
      }
  }

}

Select a Fabrication Part and then run the macro. Theoretically nothing should happen, but Revit will crash. @jeremytammik https://github.com/jeremytammik If you could confirm this, and if so, please create an issue for development team. The best we could do, if this is true, is to prevent the property from showing in Lookup until it is resolved. I can post a fix for Lookup to ignore the property if desired.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-833696958, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP6NLOV3LG2YFGVWNJLTMLE2XANCNFSM4YE3GCMQ .

[StDistraxion]

I am going to test what you sent, it should crash the same way but see if you get any different result with this (you shouldn't):

First, typically we have been using the Autodesk.Revit.DB.Document, not Creation.Document - im curious if there is any difference to you?

This is a complete class file, you can test this extension method on any UIApplication object i.e. uiApp.GetFabricationConnectorInfo().

And i was wrong about line 5, i just can't read anymore today ;)

I will test again and post as requested, and hiding MEPConnectorInfo for FabParts and FabricationConnectorInfo for MEP Elements for the time being would indeed bandage lookup until they fix this at least 3 year old issue (i found it in RevitLookLookup, but yes i found at the time it was the API itself).

using System.Linq;

using Autodesk.Revit.DB; using Autodesk.Revit.UI; using Autodesk.Revit.UI.Selection;

using OperationCanceledException = Autodesk.Revit.Exceptions.OperationCanceledException;

namespace FabUtils { public class FabricationPartSelectionFilter : ISelectionFilter { /// public bool AllowElement(Element elem) { return elem is FabricationPart; }

    /// <inheritdoc />
    public bool AllowReference(Reference reference, XYZ position)
    {
        return false;
    }
}

public static class FabPartInfo
{
    public static void GetFabricationConnectorInfo(this UIApplication

uiApp) { var uiDoc = uiApp.ActiveUIDocument; var doc = uiDoc.Document; var selectedIds = uiDoc.Selection.GetElementIds().ToList();

        FabricationPart fabPart = null;

        if (selectedIds.FirstOrDefault() is not { } selectedId
            || doc.GetElement(selectedId) is not FabricationPart

selectedPart) { try { var selectedElemRef = uiDoc.Selection.PickObject(ObjectType.Element, new FabricationPartSelectionFilter(), "Select a fabrication part... (Esc) to cancel.");

                fabPart = (FabricationPart)

doc.GetElement(selectedElemRef); } catch (OperationCanceledException) { return; } } else fabPart = selectedPart;

        var fabConns = fabPart
            .ConnectorManager
            .Connectors
            .OfType<Connector>()
            .ToList();

        fabConns.ForEach(conn =>
        {
            //It should break here on fab parts, but work on

FamilyInstances... var mepConnectInfo = conn.GetMEPConnectorInfo();

            //This will work for fab parts, but break on break on

FamilyInstances var fabConnInfo = conn.GetFabricationConnectorInfo();

            //Connector.IsConnected and .IsConnectedTo() can fail if

ConnectorType is not Physical or All //if (conn.IsConnected)

            var linkedConnector = conn
                .AllRefs
                .OfType<Connector>()
                .FirstOrDefault();

            var owner = linkedConnector?.Owner;
        });
    }
}

}

Matthew Anderson Distraxion Consulting @.** email (281) 432-7325 phone*

On Thu, May 6, 2021 at 4:24 PM Matthew Anderson @.***> wrote:

Hello, Jeremy :)

I apologize for the disappearance - i fell ill shortly after we last spoke, and it's been one thing after another for a bit.

That being said, yes i will certainly confirm this when i get back to my desk at home here in a couple hours.

I notice right off the bat something looks slightly off on line 5, i will get back with you shortly :)

Matthew Anderson Distraxion Consulting @.** email (281) 432-7325 phone*

On Thu, May 6, 2021 at 12:13 PM RevitArkitek @.***> wrote:

This appears to be a bug in Revit API, not Revit Lookup. I created the following macro:

public void GetFabricationPartInfo() { UIDocument uidoc = this.ActiveUIDocument; Document doc = uidoc.Document;

 var selectedIds = uidoc.Selection.GetElementIds().ToList();
 var fabPart = doc.GetElement(selectedIds.First()) as FabricationPart;
 var connectionMgr = fabPart.ConnectorManager;
 var connectors = connectionMgr.Connectors;
 foreach (var obj in connectors)
 {
     var connector = obj as Connector;
     var mepConnectInfo = connector.GetMEPConnectorInfo();
     var linkedConnector = mepConnectInfo.LinkedConnector;
     if (linkedConnector != null)
     {
         Element owner = linkedConnector.Owner;
     }
 }

}

Select a Fabrication Part and then run the macro. Theoretically nothing should happen, but Revit will crash. @jeremytammik https://github.com/jeremytammik If you could confirm this, and if so, please create an issue for development team. The best we could do, if this is true, is to prevent the property from showing in Lookup until it is resolved. I can post a fix for Lookup to ignore the property if desired.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-833696958, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP6NLOV3LG2YFGVWNJLTMLE2XANCNFSM4YE3GCMQ .

[jeremytammik]

Thank you guys for your research. So, apparently, we need the following steps:

• A minimal reproducible case demonstrating that Revit will crash when the mepConnectInfo.LinkedConnector property is referenced
• A report to the development team letting them know
• A fix to RevitLookup to skip this property for now

Can you attach a minimal sample model to test in? I have no fabrication part handy to test with. Thank you!

[RevitArkitek]

@jeremytammik I've attached a project with a fabrication part. I think my macro is a minimal example to cause the crash. @StDistraxion Your code doesn't crash for me because you don't access the LinkedConnector property. Project1-FabPart.zip

[StDistraxion]

Hello again,

I am surprised at that, honestly - it should have crashed for GetMEPConnectorInfo() on a FabPart and GetFabricationConnectorInfo() on a FamilyInstance().

Perhaps i missed part of the conversation, those were the two functions that originally caused an issue for me. LinkedConnector i will try right now, as i happen to have my hands in the Revit tools at this moment. I will post the result here shortly, and check the functions i mentioned again as well.

I took for granted that LinkedConnector was just trying to get the connected connector, my fault. Double checking now, perhaps there are multiple issues going on.

Thanks!

Matthew Anderson Distraxion Consulting @.** email (281) 432-7325 phone*

On Fri, May 7, 2021 at 8:51 AM RevitArkitek @.***> wrote:

@jeremytammik https://github.com/jeremytammik I've attached a project with a fabrication part. I think my macro is a minimal example to cause the crash. @StDistraxion https://github.com/StDistraxion Your code doesn't crash for me because you don't access the LinkedConnector property. Project1-FabPart.zip https://github.com/jeremytammik/RevitLookup/files/6441994/Project1-FabPart.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-834414323, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP4JW5BPHVQQSHHWFXTTMPV53ANCNFSM4YE3GCMQ .

[RevitArkitek]

@StDistraxion I haven't tested GetFabricationConnectorInfo, but the problem I identified isn't the GetMEPConnectorInfo method itself, its when Lookup reads the MEPConnectorInfo class that is pulled from that method. When it gets to the LinkedConnector property, there is a StackOverflow exception.

[StDistraxion]

I see, noted.

They are probably related, then. GetFabricationConnectorInfo() will not fail for a FabricationPart, btw. GetMEPConnectorInfo() will. And the opposite is true for a family instance.

Im certain the reproducible case is enough, these two functions and all connector related stuff likely intertwines. We recently split our libraries apart, this is the first time im compiling the new version and (naturally) there are some issue. For me, it has always crashed on the function itself, but no matter it is all in the same area and im confident your findings are how it is.

Matthew Anderson Distraxion Consulting @.** email (281) 432-7325 phone*

On Fri, May 7, 2021 at 2:00 PM RevitArkitek @.***> wrote:

@StDistraxion https://github.com/StDistraxion I haven't tested GetFabricationConnectorInfo, but the problem I identified isn't the GetMEPConnectorInfo method itself, its when Lookup reads the MEPConnectorInfo class that is pulled from that method. When it gets to the LinkedConnector property, there is a StackOverflow exception.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-834695737, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP7RVWORVUVY6DDUJDTTMQ2EBANCNFSM4YE3GCMQ .

[RevitArkitek]

@jeremytammik Was this issue ever sent into the development team? My company may have a use case for getting this information. Thanks.

[jeremytammik]

@RevitArkitek the Revit development team has nothing to do with RevitLookup. it is 100% community maintained. if you need this fixed, please either do it yourself and submity a pull request, or try to gget me or somebody else to do it for you. as far as i understand, it is very simple. so, if you attach a sample model and exact step by step instructions for reproducing the problem, we will probably be able to et it fixed: repro case: https://thebuildingcoder.typepad.com/blog/about-the-author.html#1b ... correction: i see that a reproducible test case was already attached above. correction 2: @chrishildebran i see that you closed this issue. why? is it already fixed?

[RevitArkitek]

@jeremytammik I never said this was a RevitLookup issue. On May 6 I wrote that this is an API bug. I gave you a simple macro and the following day I had uploaded a file to this issue to test with. Then for 5 months no one said anything.

[jeremytammik]

@RevitArkitek oh dear, sorry that i missed that. please note that this platform is purely dedicated to RevitLookup issues. i'll take a closer look at it anyway and escalate it to the development team as soon as i can.

[jeremytammik]

oh, and i assume that explains why chris closed it...

[jeremytammik]

@RevitArkitek I submitted a development ticket REVIT-183942 [GetMEPConnectorInfo LinkedConnector crashes on fabrication part] for this for you. Thank you for raising the issue. Could you share some information on who you are and how you can be contacted? If you prefer, you can do so by direct email to jeremy dot tammik at autodesk dot com. Thank you!

[jeremytammik]

@RevitArkitek the development team have addressed this now in a second follow-up development ticket REVIT-184364 [GetMEPConnectorInfo LinkedConnector crashes on fabrication part] and say:

There were some issues that were potentially causing problems when accessed from the API. One case a Boolean was returned for a condition check then the non-const version for getLinked was calling the const version then using a const_cast to return the non-const linked connector pointer. This code has been untouched for a very long time; I’m surprised this has not come up before. This was fixed by commit 12791d3.

Thank you for reporting it!

[StDistraxion]

Neat!!

Matthew Anderson BIM Programmer Analyst Distraxion Consulting (281) 432-7325 @.***

On Thu, Nov 4, 2021, 6:23 AM Jeremy Tammik @.***> wrote:

@RevitArkitek https://github.com/RevitArkitek the development team have addressed this now in a second follow-up development ticket REVIT-184364 [GetMEPConnectorInfo LinkedConnector crashes on fabrication part] and say:

There were some issues that were potentially causing problems when accessed from the API. One case a Boolean was returned for a condition check then the non-const version for getLinked was calling the const version then using a const_cast to return the non-const linked connector pointer. This code has been untouched for a very long time; I’m surprised this has not come up before. This was fixed by commit 12791d3.

Thank you for reporting it!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeremytammik/RevitLookup/issues/72#issuecomment-960666960, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZNDP2YLM52S6PQ6FMU4ALUKJUKBANCNFSM4YE3GCMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.