Author Topic: .IsDynamicBlock returns false ?  (Read 6760 times)

0 Members and 2 Guests are viewing this topic.

WILL HATCH

  • Bull Frog
  • Posts: 450
Re: .IsDynamicBlock returns false ?
« Reply #15 on: September 04, 2013, 02:49:55 PM »
This is really difficult to try to walk you through with only having a small piece of the whole problem.  But to fix your invalid state problem I'm guessing you've opened the attributes and blockreference for write and you're having issues opening them later.  A downgrade open will solve this problem for you I do believe.  If you wish to minimize the overall changes to your code instead of using the top transaction within each subroutine create a new transaction, I think (you will need to confirm) that when the nested transaction is ended the open state of the objects is downgraded for you so you won't need to modify code much.

Quote from: docs
Transactions can be nested—that is, you can start one transaction inside another and end or abort the recent transaction. The transaction manager maintains transactions in a stack, with the most recent transaction at the top of the stack. When you start a new transaction using AcTransactionManager::startTransaction(), the new transaction is added to the top of the stack and a pointer to it is returned (an instance of AcTransaction). When someone calls AcTransactionManager::endTransaction() or AcTransactionManager::abortTransaction(), the transaction at the top of the stack is ended or aborted.

When object pointers are obtained from object IDs, they are always associated with the most recent transaction. You can obtain the recent transaction using AcTransactionManager::topTransaction(), then use AcTransaction::getObject() or AcTransactionManager::getObject() to obtain a pointer to an object. The transaction manager automatically associates the object pointers obtained with the recent transaction. You can use AcTransaction::getObject() only with the most recent transaction.

When nested transactions are started, the object pointers obtained in the outer containing transactions are also available for operation in the innermost transaction. If the recent transaction is aborted, all the operations done on all the objects (associated with either this transaction or the containing ones) since the beginning of the recent transaction are canceled and the objects are rolled back to the state at the beginning of the recent transaction. The object pointers obtained in the recent transaction cease to be valid once it's aborted.

If the innermost transaction is ended successfully by calling AcTransactionManager::endTransaction(), the objects whose pointers were obtained in this transaction become associated with the containing transaction and are available for operation. This process is continued until the outermost (first) transaction is ended, at which time modifications on all the objects are committed. If the outermost transaction is aborted, all the operations on all the objects are canceled and nothing is committed.

dba

  • Guest
Re: .IsDynamicBlock returns false ?
« Reply #16 on: November 02, 2015, 06:45:25 AM »
Hello,

I don't know, wether the OP's issiue is solved or not, I just liked to place a hint for getting Blockdef-Names (Blocktablerecords)
Blockreferences have 3 Id-s to their Blocktablerecords:

- .BlockTablerecord: points always to the deifning Block, meaning to the "real" one in case of a static Block, and to the Anonymous one (*U....) in case of (modified) dynamic Block
- .AnonymousBlocktableRecord: points to the defining Blockdefinition  (*U...) of an altered dynamic Block (means, some Properties were set), else null/Nothing
- .DynamicBlocktableRecord: points to the "main" BTR, so to the real one in case of static block, and to the master in case of dynamic blocks, this is ALWAYS set, regardless of Blocktype

Conclusion:
to test the Name, or content of ANY Blockref, you can always parse the "br.DynamicBlockTableRecord"

As I said, this may not help in this issue, but could be useful if someone reads the post.
BR,
Daniel