Set instance parameters at insertion or modification

Set instance parameters at insertion or modification

Anonymous
Not applicable
1,812 Views
5 Replies
Message 1 of 6

Set instance parameters at insertion or modification

Anonymous
Not applicable

Hello world,

 

Last week I was trying to develop some extra functionality within Revit which automatically registers when and who ads or modifies family types and instances. To realize this I introduced some project parameters that are assigned to the specific families. What I am trying to do is that when something is added or modified, the parameters automatically are set. So far, so good.

 

I've tried multiple solutions but until now I just can't figure out the last step. To retrieve the elementid's I've tried a documentchanged event which does find the right id's but, because the event isn't meant for changing or manipulating elements in any way what so ever, I got stuck.

 

Another solution I've tried is the use of IUpdaters. When it comes to modifying it does the job fairly good job. However, copying elements doesn't work seem to work properly: when I copy an instance, the parameters of the newly created element are set to the values of the original element. Besides this issue I stumbled upon a bigger problem: adding instances. Where the DocumentChanged event retrieves all the elements, the IUpdater can't retrieve the last element because the timing comes in a bit earlier than the DocumentChanged event. Example: when I'm placing a wall chain of three walls, the first two walls are set properly but the parameters of the last one comes empty.

 

My question: how can I retrieve all added and modified elements (or corresponding id's) and change there associated parameters?

 

Kind regards,

Tim

 

PS: If desired, I can post/send/attach fragments of my code.

0 Likes
Accepted solutions (1)
1,813 Views
5 Replies
Replies (5)
Message 2 of 6

jeremytammik
Autodesk
Autodesk

Dear Tim,

 

I think you are absolutely on the right track.

 

You are apparently missing one really funcdamental important piece, though:

 

The dynamic model updater interaction happens in the same transaction as the operation that triggers it.

 

The document changed event is called after the transaction has been closed.

 

Also, the latter can no longer make any changes to the model; it is a read-only event.

 

If you need to collect information from both of these events -- which you apparently do -- you certainly can, no problem whatsoever.

 

One possibility to afterwards process and save this info in parameters on the modified and copied elements would be to temporarily subscribe to the Idling event.

 

In the Idling event handler, you can modify the model again as you wish, i.e., save your data, and also immediately unsubscribe from the Idling event again.

 

The Building Coder has discussed many related issues, e.g.:

 

http://thebuildingcoder.typepad.com/blog/2012/06/documentchanged-versus-dynamic-model-updater.html

 

I hope this helps.

 

It would be great if you would like to implement and test this suggestion as a proof of concept in a separate stand-alone sample add-in, independently of your application, and publish the entire solution, not just fragments.

 

Thank you!

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 3 of 6

jeremytammik
Autodesk
Autodesk

Cleaned up and published my answer:

 

http://thebuildingcoder.typepad.com/blog/2015/07/clicks-dmu-surfaces-firerating-feedback-vacation.ht...

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 4 of 6

Anonymous
Not applicable

Dear Jeremy,

 

First of all, thank you for the quick reply. I tested your solution and it did exactly what I initially described. Many thanks!

 

After further testing I noticed that a new problem emerges: where dmu's can set the parameters in the current transaction of placing an instance, setting the parameters after the placement transaction with the idling event, I'm now having problems with the use of the undo- and redo-command. When I thought it through it made sense. Undoing a transaction after the use of the idling event means changing the value of a parameter which in itself is new modification (transaction) to an element which raises the documentchange event and so on, and so on.

 

In summary, using a combination of the documentchanged and idling event doesn't seem to be an option, but please correct me if I'm wrong. That leaves us with the implementation of dmu's.

 

New question would be: Is it possible to collect the same elementid's with dmu's as with the DocumentChangedEvent? Secondly, to avoid further conflicts the undo- and redo-command, is it possible to set the values of these parameters in the same transaction when there hosts (and this case being an family instance) are placed?

 

I've attached two examples to this message. One uses a dynamic model updater, the other a combination of the DocumentChanged and Idling Event. I kept the code as plain as possible. Please forgive me all you C#-users but I've wrote it in vb.net.

 

Many thanks in advance.

 

Kind regards,

Tim

0 Likes
Message 5 of 6

Revitalizer
Advisor
Advisor
Accepted solution

Hi,

 

regarding the "adding instances" problem:

 

what about replacing

Element.GetChangeTypeAny()

with

ChangeType.ConcatenateChangeTypes(Element.GetChangeTypeGeometry(), Element.GetChangeTypeElementAddition())

 

Some years ago, I had a similar problem when placing new doors and set their parameters at the same time.

GetChangeTypeElementAddition() did the trick for me.

 

 

Revitalizer




Rudolf Honke
Software Developer
Mensch und Maschine





Message 6 of 6

Anonymous
Not applicable

That did the job. Thank you very much.

0 Likes