Replies: 2 comments 3 replies
-
|
ref = Db.BlockReference(ref_id)
dynRef = Db.DynBlockReference(ref_id)
ref.upgradeOpen()
dynRef.getBlockProperties() # should failBest practice, IMHO is to only leave Db Objects opened for write as short as possible. ref = Db.BlockReference(ref_id)
dynRef = Db.DynBlockReference(ref_id)
ref.upgradeOpen()
# do write stuff
ref.downgradeOpen()
dynRef.getBlockProperties() # should be okor the inverse ref = Db.BlockReference(ref_id, Db.OpenMode.kForWrite)
dynRef = Db.DynBlockReference(ref_id)
if ref.isWriteEnabled():
ref.downgradeOpen()
dynRef.getBlockProperties()
ref.upgradeOpen()It would have been nice if |
Beta Was this translation helpful? Give feedback.
-
|
Thinking, I could combine |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Are there any rules/best practices for using
BlockReferenceandDynBlockReference?DynBlockReferenceis a different object thanBlockReferencebecause it doesn't have theclose,dispose, orcastmethods. The rules seem to be the same as using multipleEntityobjects – you can have multiple objects for reading, but only one for writing. The problem is thatDynBlockReferencedoesn't throw an error if you instantiate it while aBlockReferenceobject is already open for writing, but calling.getBlockProperties()returns an empty list. It would be helpful to have immediate information when opening aDynBlockReferenceobject, but even if it were possible, it would probably create unnecessary overhead..?Beta Was this translation helpful? Give feedback.
All reactions