Can a pipe have multiple pipe types assigned?

[Anonymous]

In the code, I change the pipe type for two pipes:

pipe.ChangeTypeId(newPipeType.Id);

After commiting the transaction, I change to the Revit UI (see Attachement). 

• When I select each pipe, the new pipe type is shown in the properties >> correct
• When I right click the new pipe type and select Select all Instances | In Entire Project, both pipes get selected >> correct
• When I right click the previous pipe type and select Select all Instances | In Entire Project, no pipes get selected >> correct
• When I delete the new pipe type, both pipes get deleted>> correct
• (after undoing the last step) When I delete the previous pipe type, one pipe gets deleted (!)>> wrong

Allthough I know that it's not possible, it seams that a pipe has assigned two pipe types, the new one and still the previous one.

[Anonymous]

Please can someone give me a hint? I'm really out of ideas in this case!

[jeremytammik]

Wow. That does sound weird indeed.

Can you please provide a minimal reproducible case to demonstrate this behaviour that I can share with the development team?

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

Thank you!

[Anonymous]

Hi Jeremy

Thanks for responding. 

I have attached a Revit project and added reproduction steps to the forum item. Can the development team work with the provided information? I hope so, otherwise, please advice me what information you need.

Thank you!

[jeremytammik]

Thank you for the reply. Unfortunately, I see no attachment. Could you try again, please? Alternatively, put it into Dropbox or somewhere and share a link. Thank you!

[Anonymous]

I thought I attached the Revit project to the forum item.

Now I uploaded it again here: https://nussbaum.sharefile.eu/d-s8b73470141247de8 

Thank you!

[jeremytammik]

Dear Dominic,

Oh, I see.

Yes, indeed, the Revit project is already attached to the first post in this thread.

That in itself is not a reproducible case.

The optimal reproducible case is a macro or an add-in that just needs to be launched to completely demonstrate the entire sequence of events, including the problematic behaviour. 

Does you Revit project include a macro that performs all the steps that you describe?

All that selection, delete, undo, etc.?

Or do those steps need to be executed manually in the user interface?

If so, does your sample project include the macro that performs the call to the ChangeTypeId method?

If not, can you please add it, and include the steps to launch the macro in your detailed step-by-step description to reproduce the problematic behaviour?

The description needs to be absolutely fool-proof.

Otherwise, the development team can simply say that the problem you describe is not reproducible.

Thank you!

Best regards,

Jeremy

“You must be a constructive schizophrenic. Be clear about the difference between your role as a programmer and as a tester. The tester in you must be suspicious, uncompromising, hostile, and compulsively obsessed with destroying, utterly destroying, the programmer’s software. The tester in you is your Mr. Hyde – your Incredible Hulk. He must exercise what Gruenberger calls ‘low cunning.” – Boris Beizer

[Anonymous]

Hi Jeremy

I created a macro to automate the reproduction steps (see attached file Source.zip). Is that what your developers need?

[jeremytammik]

Yup, looks fine to me.

Thank you very much for that!

I cleaned up the code a little bit for readability and got this:

  public void Test( Document doc )
  {
    const string previousPipeTypeName = "PreviousPipeType";
    const string newPipeTypeName = "NewPipeType";

    // Get all pipe types in the current project

    List<PipeType> pipeTypesInProject 
      = new FilteredElementCollector( doc )
        .OfClass( typeof( PipeType ) )
        .Cast<PipeType>()
        .ToList();

    ElementType previousPipeType = pipeTypesInProject.Single( 
      t => t.Name == previousPipeTypeName );

    ElementType newPipeType = pipeTypesInProject.Single( 
      t => t.Name == newPipeTypeName );

    // Deleting the 'NewPipeType' (containing 2 pipes)

    using( Transaction transaction = new Transaction( doc ) )
    {
      transaction.Start( "Delete 'NewPipeType'" );

      // Count the number of pipes of the 'NewPipeType'

      int numberOfInstances = new FilteredElementCollector( doc )
        .OfClass( typeof( Pipe ) )
        .Cast<Pipe>()
        .Count( i => i.GetTypeId() == newPipeType.Id );

      TaskDialog.Show( "Test the behavior", string.Format( 
        "{0} pipes of '{1}' in current document.{2}{2}>>Correct result.{2}{2}Delete '{1}' now.",
        numberOfInstances, "NewPipeType", Environment.NewLine ),
        TaskDialogCommonButtons.Ok );

      doc.Delete( newPipeType.Id );

      // Count the number of pipes of the 'NewPipeType'

      numberOfInstances = new FilteredElementCollector( doc )
        .OfClass( typeof( Pipe ) )
        .Count();

      TaskDialog.Show( "Test the behavior", string.Format( 
        "{0} pipes pipes in total after the '{1}' was deleted.{2}{2}>>Correct result.{2}{2}Rollback the transaction.",
        numberOfInstances, "NewPipeType", Environment.NewLine ),
        TaskDialogCommonButtons.Ok );

      // Undo the last step

      transaction.RollBack();
    }

    // Deleting the 'PreviousPipeType'

    using( Transaction transaction = new Transaction( doc ) )
    {
      transaction.Start( "Delete 'PreviousPipeType'" );

      // Count the number of pipes of the 'PreviousPipeType'

      int numberOfInstances = new FilteredElementCollector( doc )
        .OfClass( typeof( Pipe ) )
        .Cast<Pipe>()
        .Count( i => i.GetTypeId() == previousPipeType.Id );

      TaskDialog.Show( "Test the behavior", string.Format( 
        "{0} pipes of '{1}' in current document.{2}{2}>>Correct result.{2}{2}Delete '{1}' now.",
        numberOfInstances, "PreviousPipeType", Environment.NewLine ),
        TaskDialogCommonButtons.Ok );

      ElementId previousPipeTypeId = previousPipeType.Id;
      doc.Delete( previousPipeTypeId );

      // Count the number of pipes of the 'PreviousPipeType'

      numberOfInstances = new FilteredElementCollector( doc )
        .OfClass( typeof( Pipe ) )
        .Count();
      TaskDialog.Show( "Test the behavior", string.Format( 
        "{0} pipes pipes in total after the '{1}' was deleted.{2}{2}>> Wrong result!{2}{2}Commit the transaction.",
        numberOfInstances, "PreviousPipeType", Environment.NewLine ),
        TaskDialogCommonButtons.Ok );

      transaction.Commit();
    }
  }

That should be self explanatory enough.

[jeremytammik]

Dear Dominic,

Thank you again for the reproducible case.

I logged the issue REVIT-160989 [Pipe belongs to two pipe types after delete and undo] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[Anonymous]

Hi Jeremy 

I discovered this bug while programming a workaround for the missing API functionality of changing the pipe type. When I import a pipe type

ElementTransformUtils.CopyElements(...)

that pipe type should replace an existing one But unfortunately Revit creates duplicate pipe type with a suffix "2" in the name. My workaround does the following:

1) Get all pipe instances in the current project

2) Change the pipe type of pipe instances to the corresponding new pipe type (ends with 2)

3) Delete the "old" pipe types (the once without the 2)

4) Rename the new pipe types (remove the 2 in the name)

At step 3 I discovered the bug reported in this post. Revit deleted pipes, although no pipe with the old pipe type should be present in the project anymore.

Is there a better workaround than the one I use?

Thank you!

[jeremytammik]

Dear Dominic,

Thank you for your update.

The development team analysed the issue REVIT-160989 [Pipe belongs to two pipe types after delete and undo] and say:

The API is actually fine. I attached an example ManagePipeTypes.rvt with macro to change the pipe type and repeat the same steps as the described code. It works fine.

However, the attached file DuplicatePipeType.rvt has stored a routing reference id, which was incorrectly used to delete the pipe. I can repeat the steps in UI to see wrong pipes are deleted. That requires a code fix.

The issue is now closed as 'Code Fix Needed'.

Please study the attached example model ManagePipeTypes.rvt with its macro to see how to resolve your issue properly.

Looking forward to hearing how that works for you.

Thank you!

Best regards,

Jeremy

[Anonymous]

Hi Jeremy

I cannot open your project file. It was saved in Autodesk Revit 2022!

Can you please downgrade it to version 2018, 2020 or 2021?

[jeremytammik]

Dear Dominic,

Thank you for your update and sorry for the model from the future.

The development team have perfected time travel.

They now provided a Revit 2021 model PipeType2021.rvt, attached below, and added three macros to it.

You may run them in sequence A_CheckPipeType, B_ChangePipeType, and C_DeletePipeType.

The last one C_DeletPipeType, is copied from the original steps.

In that dataset, no pipe is removed after PreviousPipeType is removed.

Having said that, we discovered an issue in Revit causing the problem in the original dataset, unrelated to any API and will address that soon.

Looking forward to hearing how that works for you.

Thank you!

Best regards,

Jeremy

[Anonymous]

Hi Jeremy.

Your provided macro works for me as expected. But as you wrote, there is still a problem in the original dataset. Under certain circumstances Revit works as reported. I'm looking forward to hear what issue is causing the problem in the original dataset and what I can do to prevent it.

Thank you in advance!

[adam.krug]

have you tried firing

Doc.Regenerate();

 after changing type?

I noticed it's often useful to regenerate document when working with pipes via API. Otherwise strange things happen.

[Anonymous]

Hi Adam

Unfortunately, that didn't help me eighter. I still have the same strange behavior.

[jeremytammik]

Dear Dominic,

Thank you for your update and sorry to hear that problem remains.

I reopened the ticket REVIT-160989 [Pipe belongs to two pipe types after delete and undo] for you and asked them for further advice on how to resolve that.

Best regards,

Jeremy

[jeremytammik]

Dear Dominic,

Thank you for your patience.

The development team responded to my new questions on the ticket REVIT-160989 [Pipe belongs to two pipe types after delete and undo] and clarify:

This problem has been analysed and identified. It is being tracked in the new change request REVIT-161421. As a result, REVIT-160989 is closed. I don't know any easy workaround for the attached dataset without any code change. Meanwhile, REVIT-161421 has been fixed in the dev branch and is currently nominated for integration in an upcoming update release.

I hope this helps.

Best regards,

Jeremy

[Anonymous]

Hi Jeremy

I'm really looking forward for the fix REVIT-161421 being published. Otherwise, we wont be able to publish our new feature to our customers.