Topic: Object Reactor callback causing error: object is not open for write

[jhadams82]

So I've recently started trying to make use of reactors (I know, I must be crazy, lol).  It's going well so far, but I've run into something that's making me nervous.

At my job, we have a bunch of dynamic blocks in model space whose visibility states show different configurations.  If we change a block's visibility state, that automatically means we also need to change one or more detail blocks in paper space that have a corresponding visibility state.  I'm trying to create a reactor such that whenever any block's visibility state is changed, all the corresponding blocks get their visibility states changed accordingly.  I actually got it working, but there's a problem.  When I change the visibility state of one object, the other changes just like I want.  But I also get "error: Automation error.  Object is not open for write". 

I suppose I could just live with the error message or try to suppress it, but I have a feeling it means there's something I don't know about reactors and it could come back to bite me.  It seems the error message is coming from the if statement where I check to see which object is passed as the notifying object.  Maybe there's a different way I should be checking to see which is the notifier?  I can probably get around this error by only having one owner per reactor, but that doubles the size of my code and I feel like it would be much cleaner to have one reactor watch both objects.  Any ideas?

TIA, you guys rock

[Lee Mac]

The error you are receiving is the only thing that is stopping your reactor callback function from descending into an infinite callback loop. Consider that your 'MEmodel' block reference and 'MEdetail' block reference are both owners of the Object Reactor, hence, when MEmodel is modified, the vlr-modified event triggers the callback function to be evaluated which then modifies the MEdetail block reference, whose modification triggers the callback function to be evaluated, which then modifies the MEmodel block reference, whose modification triggers the callback function to be evaluated...

The only thing preventing this infinite cycle is that the object which triggers the first modification event cannot itself be modified until its own modification (outside of the scope of the reactor) has completed, hence the error as the object is "read-only" to the reactor whilst being modified by AutoCAD.

To fix this issue, I would suggest testing whether or not the visibility state of the target object is already in the desired state before issuing my LM:SetVisibilityState function to set it (which will then trigger the modification event).

In general when developing reactor-driven programs, it is paramount that code be watertight and account for situations such as these, as this form of error can potentially result in AutoCAD crashing which may then result in loss of work.