Please Help my understanding of the ChangeProcessor

[Qube-it]

(Working in C#)

I have read through the Change Processor Overview article in the online help multiple times and I have looked at the sample Add-in "Custom Command" that comes with the SDK and I am unable to succesfully create a ChangeProcessor for my add-in. I think that I understand what the Change Processor does, but I could be wrong on that. Could someone tell me when using the Change Processor is better than the Transaction Manager or vice-versa?

-Brian Hall-

[Anonymous]

I have been meaning to ask the same question. Using a Change Processor seems like much more work than using Transactions. I can't find any benefits that would make this extra work worth-while.

[Qube-it]

UPDATE:

I think I need a break because I was missing something entirely stupid (the execute method - DUH!!). I got the change processor to work just fine.

This may be to general of a question, but I see a several other properties and a couple of methods that seem pretty powerful with regards to transacting actions through the API. At this point I have not created an Add-In sophisticated enough to make use of those object members. I'm sure someone out there has and I would be curious to know the context of using those members and some of the gotcha's to watch out for.

-Brian Hall- Edited by: Qube-It on May 10, 2010 10:07 AM

[Qube-it]

Alright, I'm at a loss...

Basically, I'm trying to encapsulate several operations into one undo/redo. I'm creating a rectangle that is constrained about the origin of where the user selects (i.e. a center point rectangle). I'm also replicating the behavior of Inventor's standard two-point rectangle where the size of the rectangle is determined by where the user drags his mouse around (after the origin point is selected). This requires me to subscribe to the OnMouseMove event in order to resize the rectangle to where the user moves their mouse. Of course that means that I'm calling the method that resizes the rectangle a few dozen times (maybe more depending on how much the user moves the mouse around while sizing the rectangle).

When the user clicks the mouse a second time (which then fully instantiates the rectangle) I'm calling a method I named "LockTheRectangle". Inside that method I basically call a method which deletes the rectangle, and then I create the change processor which ultimately calls a method that recreates the rectangle inside one method.

I have everything working just fine. Even when I undo the center point rectangle. The problem is that the undo operation only undoes the method that recreates the rectangle. It doesn't undo all of the rectangle resizing that was done prior to the creation of the ChangeProcessor object.

I understand why this occurs, but I'm just not sure how to include the interactive resizing of the rectangle as well as the final instantiation of the rectangle into one ChangeProcessor object. Should I be looking into InteractionGraphics? Perhaps I just answered my own question.

Any other thoughts?

-Brian Hall-

[Anonymous]

If you're drawing the "preview rectangles" using
InteractionGraphics, this becomes very easy, as the InteractionGraphics do not
need to be transacted (in fact, they ARE NOT transacted).

This sounds oddly reminiscent of the problems I
encountered when I was writing Revision Cloud 4.5 years ago.

брайян р.
ивашкевич

style="FONT-FAMILY: Verdana; FONT-SIZE: 14pt">inventor
specialist

[Qube-it]

Thank you for your response (not sure how to spell your name LOL). This is my first foray into developing. I have a much larger project in mind, but I wanted to get my feet wet with a couple of "simple" tools that I could put out there for everyone to use (and beat up) and a center point rectangle is one of them.

After posting my last response, I realized that interaction graphics is probably the way to go. It seems like it would be much lighter on the processing, thus giving better "performance" to the user. I have yet to look into interaction graphics but I will do so now. Thanks again.

-Brian Hall-

[Anonymous]

Can you Explain , what is exactly mechanism of change Processor . i am asking because of , nesting of transaction is possible while nested change processor is not works properly ! why?

[BrianEkins]

My advice is not to use it and use transactions instead.  Transactions will let you group multiple steps into a single undo, which is all that most people want.  The change processor mechanism is quite complex to implement and provides the same capability. 

The reason the change processor functionality was added to the API was primarily for internal applications.  The main thing that the change processor provides that transactions do not is the ability to create test scripts.  These are used internally to test Inventor.  How this works is that a registry setting is changed so that a test script will be created.  You then use Inventor interactively and it records what you're doing into a transcript.  This transcript can later be replayed to get the same result.  This is useful for testing because a bunch of transcripts can be run and if they fail it means something has changed in Inventor to cause a regression.

These transcripts are not in a very user-friendly format and are certainly not in a programming language.  It's basically a list of the commands that were run and the input.  It's also capturing information to reproduce selections.  Because of this, it must be run on the same part that the transcript was originally created with, so the geometry it expects is there.

What the change processor provides is a way for your add-in command to write out information to the transcript about what the command did.  When the transcript is replayed, your change processor will be called by Inventor and provided this information so it can do the same thing it did when the user used it interactively.

If you just want to group commands into a single undo, which is mostly what 99.99% of use want to do, just use transactions.

[Anonymous]

But in most of the cases we have seen change processor is faster than
transaction , if we are doing somthing changes or modifications for
geometry .
Suppose if we are creating a single block then the transaction time and
change processor time will be same. But if we create more than 300 block
then in this situation change processor will gives you efficient way
compare to transaction. Yaa it is true the implementation of transactions
is much easier compare to changeprocessor ,but for larg geometry changes
changeprocessor will be efficient.

[BrianEkins]

The reason for the difference in speed is that the change processor is automatically creating a "global" transaction.  You can also do this with standard transactions.  Doing this I would expect the performance to be equivalent.  You can read more about this in a paper I presented at Autodesk University several years ago.  It's as easy to use as standard transactions without all of the complexity of the change processor.

[Anonymous]

Yes , I am strongly agree with you in the case of loop execution . For example if there is a loop with time complexity order of (n^2) or more than it ,then in this case transaction will gives you same result as Change Processor gives. But in the case of creating geometry , for example suppose we are coloring 500+ cavity or block simultaneously  , in this case i experienced  that standard transaction took 45 second  while Change Processor took only 12 second to color all cavity. 

That's why i am saying ! any way whatever you told about change processor it was new for me , that it is created for internal application . Thanks for it.