Rooms not placed in non-UI-document after RollBack()

[johannes.pilarskiCR6JN]

Hello!

I want to modify an existing revit project without making the document visible to the user.

In this concrete case, I want to place a room into an existing house. This works fine until I use the Transaction.RollBack() method of another transaction before placing the room. In this case, the room is not placed and can also not be found in any schedule, although I can find its Id afterwards in the document when using "Search and Snoop" method of RevitLookup tool. But after saving, closing and re-opening the document, this Id doesn't exist any more. When using Transaction.Commit() instead of RollBack() in l.26 the problem does not appear.

To make my confusion complete, this problem only occurs when using Revit in english language version. In german everything works fine.

Find the code below where the room is not placed:

        protected override Result ExecuteCommand(ExternalCommandData revit, ref string message, ElementSet elements)
        {
            UIApplication uiApp = revit.Application;
            UIDocument uiDoc = uiApp.ActiveUIDocument;
            Document doc = uiDoc.Document;
            Application app = doc.Application;

        
            Document destination = app.OpenDocumentFile("C:\\Users\\jpilarski\\Desktop\\testProject.rvt");

            Level level = new FilteredElementCollector(destination)
                .WherePasses(new ElementCategoryFilter(BuiltInCategory.OST_Levels))
                .Where(x => x.Name == "EG- OK FFB")
                .Cast<Level>()
                .First();

            XYZ point_a = new XYZ(-100, 0, 0);
            XYZ point_b = new XYZ(-30, 0, 0);
            Line line = Line.CreateBound(point_a, point_b);

            Transaction trans = new Transaction(destination);
            trans.Start("start transaction");

            Wall wall = Wall.Create(destination, line, level.Id, false);
           
            trans.RollBack();

            View view = new FilteredElementCollector(destination)
                    .WherePasses(new ElementCategoryFilter(BuiltInCategory.OST_Views))
                    .Cast<View>()
                    .Where(x => x.Name.Contains("EG"))
                    .Where(x => x.Name.Contains("Entwurf"))
                    .First();

            Transaction trans1 = new Transaction(destination);
            trans1.Start("create room");
            Room room = destination.Create.NewRoom(level, new UV(5, 5));
            RoomTag roomTag = destination.Create
                          .NewRoomTag(new LinkElementId(room.Id), new UV(5, 5), view.Id);
            trans1.Commit();

            uiApp.OpenAndActivateDocument(destination.PathName);

            return Result.Succeeded;
        }

Any ideas? Thanks in advance for your answers.

[jeremy_tammik]

Wow. That sounds rather special, and yet probably unintentional. So, are you creating the wall element in line 24 purely for demonstration purposes, to make the extra transaction not completely empty and trivial? Could you create a complete, minimal, reproducible case for me to share with the development team? 

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

Thank you!

Cheers

Jeremy

[johannes.pilarskiCR6JN]

Thank you for your answer, Jeremy!

Yes, the wall is only created for demonstration purposes. In my real application I do some other stuff in this transaction. It doesn't matter, what I do in the transaction, but leaving the transaction completely empty does not produce the problem - so in my opinion the Rollback() is the problem.

Find attached a .zip-file with the source code of the minimal case and the revit project that is going to be opened by OpenDocumentFile() method.

I hope you can work with it.

Thanks in advance!

Regards

Johannes

[jeremy_tammik]

Dear Johannes,

Thank you for your report, clear description and sample material.

Sorry to hear about this.

I logged the issue REVIT-196989 [Transaction rollback prevents Room creation] 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 crucial. Our engineering team has limited resources and 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

[RPTHOMAS108]

This is odd I noticed that you get a failure of warning level for the room being unplaced when you add a wall in the rolled back transaction so it may be related to that.

It is also odd that it is language dependant I wonder if that has something to do with language specific transaction names used by Revit as part of the process elsewhere.

[jeremy_tammik]

Dear Johannes,

The development team analysed the issue and reply:

I did some tests using the attached files. I got a DBG_WARN from the PlanTopologyIdInfo.cpp. Looks like the phase id of the room is not set properly. I switched to another room creation API and it worked:

  PlanTopology pTop = destination.get_PlanTopology(level);
  foreach (PlanCircuit circuit in pTop.Circuits)
  {
    Room room = destination.Create.NewRoom(pTop.Phase);
    if (!circuit.IsRoomLocated)
    {
      destination.Create.NewRoom(room, circuit);
    }
  }

There is another way to verify this: Save another copy of the testProject.rvt, so that the new document will have the same phases as the old one. Run the command and you will see the room will be successfully created. testProject.rvt only has one phase "Phase 01", while a new project will have two phases (existing and new construction) as default.

I think the API method "Autodesk::Revit::DB::Architecture::Room^ Revit::Creation::Document::NewRoom( Autodesk::Revit::DB::Level^ level, Revit::DB::UV^ point )" does not set a proper default phase id to the newly created room. However, we need to do more investigation to locate the problem.

That being said, I propose first providing the two workarounds:

• Use another API method
• Check the project phases

I hope this helps.

Best regards,

Jeremy

[johannes.pilarskiCR6JN]

Hi Jeremy,

thank you for these very quick workarounds. I could verify both the workaround with another API method and the command execution from a document with the same phases.

Implementing the workarounds in my real application would take a little bit more effort, especially regarding the fact that I've already implemented a workaround in the meantime by simply leaving out the rollback() method .

Thus I'm looking forward to the results of your futher investigations that explain the behaviour (especially the language dependence) completely. And of course I will have a closer look on phases (as they seem to be the problem) in my application in this current case and also in future developments. I've never paid great attention to them until today.

Regards,

Johannes

[jeremy_tammik]

Dear Johannes,

Thank you for the appreciation and glad that it helped a bit. I am afraid I don't understand phases either. I wish I did.

Cheers

Jeremy