Background Processes

Background Processes

npetulla
Participant Participant
1,140 Views
6 Replies
Message 1 of 7

Background Processes

npetulla
Participant
Participant

Hi everyone, 

I have been working on my programming skills and I am starting to venture into the Revit Background Processes. My goal is to be able to timestamp each placed element (Fab.Part) with the date and time. I have read @jeremy_tammik post ( https://forums.autodesk.com/t5/revit-api-forum/background-process-api-access/td-p/11937077 ) on creating background processes. I am familiar to external events and handlers and understand why they have to be used, the only thing I cannot figure out for the life of me is how to implement the custom process into the document. I have it loading with our ribbon but without a document being opened or an implementation of the process I cant use the DocumentChanged to find recently added element ids and continue testing. 

Documentation and examples for this topic are really hard to find. 

Thanks for your time, and I hope you have a great day!

-Nick

0 Likes
Accepted solutions (1)
1,141 Views
6 Replies
Replies (6)
Message 2 of 7

jeremy_tammik
Alumni
Alumni

Congratulations on all your work and understanding so far.  Then you understand that the Revit API is single-treaded, and all Revit API calls must be made from a valid Revit API context residing in the main thread. A background process is a process that executes in a different thread, a background thread. It cannot access the Revit API, so all interaction with Revit and the BIM needs to be marshalled back and forth in some way between the background thread and the main thread. That is all I can say really. Background threads are not part of the Revit API, so this is not the right place to discuss them. For more information, you can start out by reading up on something like ".net background thread":

  

   

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 3 of 7

jeremy_tammik
Alumni
Alumni

Two more notes on this:

  

> timestamp each placed element (Fab.Part) with the date and time. 

  

This cannot be achieved in a background process, since the element lives in the Revit database, so access and modification will require a valid Revit API context.

  

> Documentation and examples for this topic are really hard to find. 

  

I disagree. The Building Coder has discussed related issues with great frequency, and they have also come up a lot in previous discussions here in the forum; a background process is basically a modeless context, so the interaction between those and the BIM are covered by the discussions on Idling and external events for modeless access and driving Revit from outside:

  

   

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 4 of 7

npetulla
Participant
Participant

Jeremy, 

Thank you for your swift response!

I had a feeling that since the Fab. Parts are within the DB it would cause some difficulties so I thought about some other directions I can go as well. I have thought about writing something that would read the Revit journals files but there is so much information to decipher, and I dont believe the journal takes record of any parts ElementId, UniqueId, or PartGUID, so that didnt look too promising. 

 

I will look more into the Building Coder and see if I can find some more resources that will help me! 

 

You are a huge help regarding anything Revit API, for which I Thank You.

Have a Great Day, and Weekend!

 

-Nicholas Petulla   

0 Likes
Message 5 of 7

npetulla
Participant
Participant
Accepted solution

Hey @jeremy_tammik

I managed to use the controlled application to register the Document_Opened, which in return will register the Document_Changed and will add a timestamp to a parameter field for added elements. Its still obviously a test but it is working as expected. 

Thank you again!

Have a Great One!!

-Nicholas Petulla

0 Likes
Message 6 of 7

jeremy_tammik
Alumni
Alumni

Congratulations.

   

Just to clarify: that is a normal Revit API event, providing a valid Revit API context, running in the main thread, so all is easy. Advantage: very simple indeed. Disadvantage: modifying the BIM in DocumentChanged requires a new transaction, and the user can possibly undo your transaction without undoing the previous one that triggered DocumentChanged.  Note the differences between DocumentChanged and DMU:

  

   

Also, please note that DocumentChanged and Document_Changed are completely different things. Never heard of the latter. I assume you mean the former.

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 7 of 7

jeremy_tammik
Alumni
Alumni
0 Likes