Dynamic model update after loading family

[Anonymous]

Hello fellow Revit-enthusiasts,

Somewhere in 2015 I wrote a post where I asked for the correct usage of a dynamic model update (compared to the idling event). I've experimented a little bit with the dmu since then. There's one issue I haven't fixed up till now. I'm trying to use the dynamic model update to register at which date and time elements are created or modified. This information is stored in project parameters which are assigned to the corresponding categories for both instances and types..However, when I edit a family and afterwards reload it in to my project, each type of the family seems to be recognized as a modified element, even though in some cases I modified only one type by changing one or more of its parameter values. This situation causes Revit to change all projectparameter values in which the date and time are stored for all the types from the family which is being reloaded after editing.

Example: A structural column family has type "200x200" and "200x400" which are both created by inserting the family at 23 february 2016 at 3:00 PM. When I edit the family I only change some parameter values of type "200x400". But when I reload the family both type "200x200" and "200x400" are recognized as being modified which causes their parameter values used for the storage  of time and date being set to a new value (for example 3:15 PM) while it's supposed to recognize only type "200x400" as being modified.

Some background information. I'm using GetAddedElementId's and GetModifiedElementid's for the retrieval of the relevant elements. Can someone explain how to correctly check if individual types have been modified when I load them back to my project? Do I need to store all the information (parameters) in a temporary file perhaps or does the API already provide me with a more direct approach?

Thank you all in advance,

Tim

[Anonymous]

Additionally I noticed that clicking on a type displayed in the project browser also invokes the execution of an dynamic model update. Is there a way to suppress or by-pass this?

[Anonymous]

Last noted only occurs the first time I click on a type.

[jeremytammik]

Dear TTCornelissen,

Maybe my recent element modification tracking system will be of use to you:

http://thebuildingcoder.typepad.com/blog/2016/01/tracking-element-modification.html

It is probably vastly simpler and more effective for your specific purpose than either DMU or any other continuous event handler mechanism.

Cheers,

Jeremy

[Anonymous]

Dear Mr Tammik,

Your solution looks really impressive. I haven't had the chance to implement the main fundamentals in my project yet. As a starting programmer, the concept of hash code is still new to me but it looks like the right way to go. My main concern is how it will effect the perfomance of the routine.

The main purpose of my tool is that each addtition or modification will be registered by modifying some parameters including a "time-parameter" and "date-parameter". To do so, but correct me if I'm wrong, I need to trigger an event or use a DMU to determine when an element is added or modified.

Maybe I can use your snapshot technique combining it with a DMU. But doing so the DMU also collects a lot of data next to the snapshot routine. Is this necessary? Are there alternatives to affoid this sort of useless multiple data collecting?

Do elements themselfs contain relevant information about their own creation or modification (perhaps a certain property that most people aren't aware of)? If so, I can use a single event (sort of like your suggestion on your blog), for example the DocumentSavingAs event. Last possible solution I can think of at the moment is a way to look even deeper in to the updaterdata/-information hoping it contains more general information about the addition or modification of the relevant elements.

Hoping that you'll understand the scenario I'm describing. For now I wil try to use the snapshot routine combining it with a DMU and a viewactivating event. Last mentioned will be used to determine whether another document becomes active (when a user has openened multiple projects). I will place an update when I have succesfully created a working solution to discuss the results with you fellow readers. If someone can tell me if this solution probably won't really work please do so.

Many thanks in advance,

Tim

[jeremytammik]

Dear Tim,

Thank you very much for your appreciation.

I think the main characteristic of the modification tracker is simplicity, rather than impressiveness.

Of course, simplicity is much more impressive than impressiveness 🙂

If you want to be notified on every single modification of an element and store that information immediately, then indeed you can and have to use either DMU or the DocumentChanged event.

The latter does not allow you to modify anything in the same transaction, though, whereas the former does.

If you want to guarantee that your date and time markers stored in Revit parameters are always up to date, immediately, then you need to use DMU.

But do you really need that?

You need to understand that DMU is complex and adds a significant burden to Revit, depending on how many elements trigger it, which in your case would be many.

Do you really need to keep track of the element modification on a split second-by-second basis?

Would it not be enough to track changes every minute, or every ten minutes?

If so, then you can vastly simplify your approach and vastly reduce the burden on Revit by using the modification tracker and completely avoiding DMU and the DocumentChanged event.

Just track changes based on snapshots taken every X minutes, for instance.

Regarding the issue of the hash code: that is a minor detail, and pretty irrelevant.

You can just store the full data. Depending on what criteria you use to define when an element has changed, you might need to store a lot of information for each element.

I suggested the hash code as a way to reduce and unify that data storage, but that has absolutely nothing to do with the fundamental concept.

To quote the original post: "We use the hash code to determine whether the state has been modified compared to a new element state snapshot made at a later time. We could obviously also store the entire original string representation instead of using a hash code. The hash code is small and handy, whereas the entire string contains all the original data. It is up to you to choose which you would like to use."

The hash code will not affect performance much, just reduce the memory used to cache the starting snapshot.

I would recommend thinking this through in depth and peace and quiet.

If you do not require split-second time slice data, I would avoid the DMU and DocumentChanged events, both, completely.

I am very much looking forward to hearing and discussing your further thoughts on this.

Cheers,

Jeremy

[jeremytammik]

Dear Tim,

Step one is completed and documented:

http://thebuildingcoder.typepad.com/blog/2016/03/implementing-the-trackchangescloud-external-event.h...

Looking forward to hearing your thoughts on this.

Cheers,

Jeremy

[Anonymous]

Dear Jeremy and the rest of the community,

It has been some time ago now since we last discussed this subject in this thread. I put all my effort in trying to solve this puzzle but the results aren't satisfying enough up till now. Perhaps I bit off  a bit more than I can chew as a starting programmer.

Jeremy's solution functions really well but its Achilles' heel seems to be lying in the fact that it can't be implemented in a real-time solution in it's current state. The reason for this is that, although it takes just a few seconds to collect all specified data in bigger projects, when being called on each addition/modification, designers are being interrupted too often by this process.

What I really like about Jeremy's code is that, in comparison to a DMU triggered by the geometry changetype, only the relevant geometrical data is analysed. E.g. in a floorplan I'm drawing 3 chained walls in a U-shape form. Each wall is joined with the adjacent wall at each wall end. When I use Jeremy's code to take a snapshot, move the left wall to the left, take another snapshot, it reports me that 2 walls have been modified. Sounds logical right?

Now when I create a DMU that will be triggered by geometrical changes (Element.GetChangeTypeGeometry) and have a routine set a parameter value for the modified elements based on a value that the user has set beforehand using a combobox in the ribbon (the system works similair to using worksets) we'll get a different response than the first situation with Jeremy's snapshot technique. For example: I'm drawing the same walls in the same shape. Beforehand the user has set the parameter value to "1" in the combobox. After drawing all 3 walls the parameter values for parameter, let's say, "Level" are set to "1". Here comes the part where I got confused. After setting the combobox to "2", and moving the left wall to the left, the parameter values of all 3 walls have been set to "2". So the right wall has also been recognized as an modified element, which is, in my opinion, not true concerning the geometrical aspect.

In conclusion, because the main criteria for my addin is getting a real-time response from adding and modifying elements, I think I'm forced to use the DMU. I've been trying to combine a DMU with the Jeremy's solution but the load that is put on a decent draftsman's computer is just to big. This leads me to my final question, is it possible to adjust the DMU in a manner that it functions the same way that Jeremy's code, making a more accurate analyses of geomatrical changes? Concerning these geomatrical changes, I would really like to make it function based on the principle "what you see is what you get": only geometrical changes that I can see need to be processed with its corresponding elements. Is it possible to do this in some other way? Perhaps by using the journal files.

If someone reads this post and doesn't neccesarily have an answer to my questions please feel motivated to share your thoughts and philosophize about this subject. Many thanks in advance.

Kind Regards,

Tim

[jeremytammik]

Dear Tim,

Thank you for your appreciation and interesting update.

Why do you need full real-time info?

I can see a number of ways to improve the current implementation to reduce the load, for instance:

• Use the DMU in conjunction with a timer. Make a note of the added, deleted and modified element ids, but do not process them unless a certain amount of time has passed.
• Use the DMU to capture the list of s, but do nothing else with them. Enhance the regular timer-based TrackChanges snapshot to process only the listed elements instead of the entire database. Run the TrackChanges snapshot as often as needed, but not more, e.g. only once a minute.

I hope this helps.

I will be glad to enhance the public GitHub version in this manner if you confirm that it will help:

https://github.com/jeremytammik/TrackChangesCloud

Best regards,

Jeremy

[arif.hanif]

interesting to find this post, as i am trying to implement something similar in a real world application where revit is tied to a web interface through socket io connection for bi directional information exchange.

i will post my findings as i complete the project.