Isotropix Forums

Locking contexts

Clarisse Scripting related topics

Locking contexts

Unread postby jboissinot » Thu Feb 11, 2021 10:00 pm

Hi,

Besides not being able to rename the context, I was wondering what's the actual difference between set_read_only(), set_user_locked(), and set_remote() methods of OfContext? What are they used for exactly?

If I want to lock the content of a context with set_read_only() for example, I was expecting that it would apply to the context and all its sub-contexts as well? Is there a way to do so or do we need to get all the sub-contexts and set them with the same?

Also, not really related to this, but just out of curiosity, what does set_name_dirty() do exactly?

Thanks,
Jeremy
jboissinot
 
Posts: 85
Joined: Tue Jan 29, 2019 10:36 pm

Re: Locking contexts

Unread postby anemoff » Fri Feb 12, 2021 6:39 pm

Hi Jeremy,

- set_read_only and set_user_locked are very similar in that they have the same result in spite of being 2 separate states. User-locked is intended to be used by the user via the UI with the Shelf buttons Lock and Unlock, whereas read-only doesn't have UI actions (so it's mostly updated via script/code for internal logic to control items state).

- set_remote: it's used to flag the item as "remote" object to tell that it comes from an external source. Remote items have some limitations: for example, they can't be deleted or renamed but you can edit their attributes. It is mostly used internally. For example, all the items inside a Reference Context are automatically flagged as remote by the Reference engine.

- set_read_only and set_user_locked and set_remote are not recursive, so yes you need to do the recursion your self (using OfContext.get_objects and OfContext.get_contexts).

- set_read_only and set_user_locked will forbid edit actions in direct children, but not on grandchildren, so you will need to lock/unlock recursively yourself to forbid edits at all levels.

- finally, set_name_dirty is not meant for public usage. It's used by the internal name cache to notify when the name has changed. Shouldn't be public I think.

Cheers,
Anthony Nemoff
Isotropix
R&D Engineer
User avatar
anemoff
 
Posts: 391
Joined: Wed Jan 13, 2016 10:10 am

Re: Locking contexts

Unread postby jboissinot » Mon Feb 15, 2021 3:19 pm

Thanks for the explanation and clarification regarding this Anthony, it's more clear now.

Thanks,
Jeremy
jboissinot
 
Posts: 85
Joined: Tue Jan 29, 2019 10:36 pm


Return to Scripting
cron