Make instance and its parameters NOT editable

[Anonymous]

Hello,

I am getting familiar with the Revit API (in C#) and am now stuck at a problem I could not solve via Googling or searching here in the forum.

At some point at creating a drawing, we have a status of instances in the drawing, that the user/architect is NOT allowed anymore to change ANY parameters in the instance and is NOT allowed to move the instance at all!

So I found out, that you can pin the elements and make them not selectable anymore:

element.Pinned = true

var options =  SelectionUIOptions.GetSelectionUIOptions();

options.SelectPinned = false;

Also I could add a Trigger to observe a custom parameter or a built in parameter.

BUT(!) the user can still check that checkbox of the "Select pinned elements" again and I cannot find an Event that observes these user action.

The DocumentChanged event is not fired, when I click on that checkbox.

Is there any other option to make instances not editable anymore? Or can I observe the action of the user, when he/she is checking or unchecking the Selection option?

My workaround would be, that if the user would want to change the element again and it has this kind of (locked) status set, to observe this and undo the action. But this is such a dirty workaround I would not be happy with it.

I would have to set a trigger for everything in this element.. And in my opinion this is a bad solution.

Thanks a lot in advance!!

BR

Diana

[jeremytammik]

Dear Diana,

This sounds like a very logical and common need. 

I therefore very strongly suspect that Revit provides some recommended way of achieving what you require through the end user interface. 

You should always research the optimal workflow and best practices to address your task at hand manually through the user interface first.

To do so, please discuss and analyse it with an experienced application engineer, product usage expert, or product support.

Once you have got that part sorted out, it is time to step up into the programming environment.

Best regards,

Jeremy

[Anonymous]

Hey Jeremy,

This sounds like a very logical and common need.  --> yes, so did I search for the wrong keywords?

I therefore very strongly suspect that Revit provides some recommended way of achieving what you require through the end user interface.  --> yes, but until now I could not find it.. And I am searching through the API documentation etc.

You should always research the optimal workflow and best practices to address your task at hand manually through the user interface first. --> its what I already did and described in my question (??)

To do so, please discuss and analyse it with an experienced application engineer, product usage expert, or product support. --> I do not have the option in my team to discuss it with someone more experienced, do you mean I should contact the Revit support? I thought this Forum was for questions like mine, maybe I misinterpreted

Once you have got that part sorted out, it is time to step up into the programming environment. --> sure, this is what I always do

This did not help me 😞 - if it is such a common and logical need, then why can I not find anything in this Forum or Google/Youtube etc.. - Do you have suggestions for better keywords to search for?

Thank you

[jeremytammik]

Dear Diana,

Thank you very much for confirming that you went through all those research steps prior to asking and sorry for thinking that my initial suggestions might help.

Revit provides two generic mechanisms to react to database modifications: the DocumentChanged event and the dynamic model updater mechanism:

https://thebuildingcoder.typepad.com/blog/2016/01/idling-dmu-documentchanged-and-need-for-regen.html

The former is not triggered until after the change has taken place.

The latter, however, is triggered before the modification is performed and within the same transaction encapsulating the database modification, before the transaction is committed, with the option of cancelling it.

Therefore, you can definitely prevent any modification you wish by subscribing to a dynamic model updater event and cancelling the changes if any desired modification would otherwise take place. The Building Coder shares a topic group on. DMU that illustrates this and several other uses:

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

[RPTHOMAS108]

Pining the element to prevent change is probably the wrong starting point since that mechanism is mostly useful for datum elements and links i.e. the items you more often than not, want to prevent movement of. The 'select pinned items in view' button I believe is more of a user preference than a document change so I assume that setting would be per user and so not stored with the Document? Additionally if I pin something I can still change it's parameters.

There is a slow filter 'SelectableInViewFilter' which can be used to determine if something can be selected in view. So one approach could be to store the ElementIds of your protected items and run this filter for a view to ensure nothing is missing. This also seems more trouble than it is worth since it is a slow filter and you'd probably have to run it quite often.

The best approach I know of for change control is to put the protected elements on mirrored worksets:

GridsAndLevels > GridsAndLevelsReadOnly

PrimaryStructure > PrimaryStructureReadonly etc.

The 'ReadOnly' worksets above would have an owner that isn't a normal user i.e. you create a fictitious user and have that user take ownership of the worksets. This was easier in the past when you could change the Revit user name. Depending on your product licensing arrangement this may still be a viable option for you. I say it is the best approach since element ownership through worksets is an inherent aspect of Revit and so you can rely on the infrastructure already in place.

An alternative approach is to implement an IUpdater, decorate the element with a parameter value or extensible storage and then if that Element is changed post a failure with the only option being undo.

[Anonymous]

@RPTHOMAS108  thank you for your suggestions 🙂

I already looked at a video before:

https://www.youtube.com/watch?v=0KS2nwHWZRQ 

Which showed the Workset stuff that you mean - the thing is, that I can easily change my account into "Admin" and so every other user could do it like that (change his user name.. etc).

Another problem I had, was that the workset option was greyed out in my document. But I think I should first make sure what a "Workset" is and how to create and use it.

I already implemented an Updater Trigger for a user parameter (its what I mentioned in my question). And then dynamically add another trigger which catches EVERY change of the element (with Element.GetChangeTypeAny)and undo it, if its status is set to our defined "not editable anymore" status.

I just thought that this solution is not nice and thought there must be a nicer and cleaner solution to this.

But it seems there isn't.

So I will implement it like I already planned.

Thanks a lot for your help!!

[jeremytammik]

That sounds like a good approach to me. If you can keep your implementation pretty generic and are willing to share it, I am sure that other participants here would be interested in seeing it as well. Thank you!

[RPTHOMAS108]

That's fine just bare in mind there is no absolute way of preventing a user from editing something not even with the API. An Add-in only enforces something if it is running.

I think there has to be a level of trust that the users will not act inappropriately additionally there needs to be a model audit / checking process.

[Anonymous]

@RPTHOMAS108  Hei Thomas,

yes, you are right. If the user wants to commit to our database I would check, if he changed something without the Addin. The commit can only be done via the Addin.

Users are clever, they always find a way to "cheat" ...😁

I now have the contact information for support from the developer team and will ask them as well about this topic.

Maybe there is a nicer solution anyways ^^

[FAIR59]

The cleanest solution would be to prevent the user selecting the element. So program your own "SelectionChanged Event". see https://forums.autodesk.com/t5/revit-api-forum/element-selection-changed-event-implementation-strugg... 

In the "eventhandler" ( in my solution the IsCommandAvailable method )

Find the selected elements in   uiApp.ActiveUIDocument.Selection.GetElementIds(),. If your target Ids are present in the selection, remove them from the selection, effectively blocking the user selecting the element.

I don't know how time-consuming the removal of id's will be with a large number of target Ids.

[Anonymous]

Hei @FAIR59 

thanks for your answer.

The thing is, the user would then see no more information about the element.

So I think that my first suggestion with pinning the elements and making them not selectable is a very bad idea.

I asked the support and I will let you know, what the support will answer to my question.

[Anonymous]

So I have talked to the support.

Atm there is no way to "lock" an instance in the model...

Unfortunately the workaround(s) are the only ways to get such behavior...

Thanks a lot again for your help!!!

[jeremy_tammik]

Thank you for the very fruitful discussion! Edited and preserved on the blog for posterity:

https://thebuildingcoder.typepad.com/blog/2022/03/revitlookup-wpf-preventing-modification.html#2