Revit API Forum
Welcome to Autodesk’s Revit API Forums. Share your knowledge, ask questions, and explore popular Revit API topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Transactions not reliably showing up in Revit Undo

6 REPLIES 6
Reply
Message 1 of 7
Anonymous
882 Views, 6 Replies

Transactions not reliably showing up in Revit Undo

The transactions performed by my application are not reliably showing up in the Revit Undo list and when they do they may not all show up. This has been driving me crazy for a while. I've read everything I could find to no end and I've tried every combination of using transaction and using transaction group. The application in question functions just fine. It it just that the operations it makes do not show up in the Revit Undo.

 

I am thinking I am not understanding something simple. I am expecting every transaction start/commit to show up in the Undo with its text description as designated and I am expecting the Undo list to remain until the Revit file is saved, whereupon I assume the Undo items would disappear. This application can search-for-replace-with rename views. Instead I am seeing Undo items sometimes show up. For example a whole set of search-for-replace-with operations might show up in the Undo, but usually not and I have not been able to pin down the condition where the Undos do show up. I suspect when it does work, ie show up in the Undo, then all subsequent intended app operation Undos might also show up. Any Undos that do show up will undo as expected. Undos not undone remain in the Undo list after the file has been saved. I am surprised at that. Revit obviously cannot do anything with those ort undo list items. I forget what error message it reports. Perhaps something like, "... cannot index .. ". If I run the app subsequent times when there were items already in the Undo list and if the app's operations did manage to make it to the undo list, then the previous Undo list items are gone.

 

The application is performing the operations from within a Windows Form. I'm not going to post the code because it looks just like every other transaction using and group using code I've seen and I have tried every combination and style of start and commit location within the code. The application currently has the start and commit bracketing each view rename. The overall question is how can transactions not show up in the Undo list. I am assuming they all should. (Revit 2016) Any help would be much appreciated. Thank you.

6 REPLIES 6
Message 2 of 7
BobbyC.Jones
in reply to: Anonymous

If you're using a TransactionGroup, are you calling Assimilate() before disposing it? 

--
Bobby C. Jones
Message 3 of 7
Anonymous
in reply to: BobbyC.Jones

Yes and No. I've tried every combination and flavor except dispose. It is my understanding dispose is not necessary when employing a using statement.

 

I've discovered the same symptoms occur when manually renaming views. What I have been thinking all along is abnormal behavior in the add-in is actually "normal". 

Message 4 of 7
BobbyC.Jones
in reply to: Anonymous

You are correct, the using statement handles calling Dispose().  I wouldn't expect the transaction's ability to show up in the undo stack to hinge on the methods you call inside the transaction.  However, when you say, "The application is performing the operations from within a Windows Form", are you modifying the Document from the Form's code-behind?  I could see that causing erratic behavior.

--
Bobby C. Jones
Message 5 of 7
Anonymous
in reply to: BobbyC.Jones

Yes, I frequently do this with a modal form with no problems and no erratic behavior. Modeless operation where you are trying to interact with the Revit user interface is where there is trouble. As long as the link is one way there is no trouble. The one-way link can also go the other way. For example an add-in can use a Form ( a "borderless" WPF is what I use) as its feedback display window during the add-in's workflow steps. The WPF is fired up by the add-in, which instructs the WPF to change its displayed contents, ie. feedback to use, instructions etc, as the add-in runs. Meanwhile the WPF, its own floating entity, can get user focus to be positioned and resized by the user as he or she likes it. It can also save that information to its own settings for the next time it is fired up. The WPF is in its own little world. Revit is in its world, but it can control the WPF. The add-in closes the WPF when it finishes its Revit operations. The user no longer has to constantly look down to status line to figure out what state Revit is in or what the current prompt is reading. 

 

Back to this problem. I am seeing odd things happen when manually renaming views.

Message 6 of 7
BobbyC.Jones
in reply to: Anonymous

Gotcha!  I thought you may have been trying to access the API from the form itself.  As that doesn't look to be the case, I'm out of ideas.  As for the view renaming/missing undo oddness, I haven't a clue there either.  Hopefully someone more qualified than I will step in now.

 

I am watching this post though, as earlier this week we received a ticket requesting development of a tool to rename views.

 

--
Bobby C. Jones
Message 7 of 7
Anonymous
in reply to: BobbyC.Jones

Well this one is working just fine. It is just the Undo that is an issue and from what I've seen so far the problem is not this application. I can share if you want ideas or even the app as a starter. I got tired of renaming and knew that the feature could be incorporated into an earlier application made for deleting views and experimenting.  This is what it looks like.

 

ViewManager.PNG 

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


Autodesk Design & Make Report