« AU Begins | Main | Parameter Modification Performance »

December 03, 2008

Comments

"""If it is important to the add-in to not "modify" the model inadvertently, you need to keep track of whether you have made modifications, return Succeeded if you did, and Cancelled or Failed if you did not."""

You can have readonly commands that don't modify the model and can run successfully or be cancelled by the user. As far as the journal is concerned a command has one transaction. It's for that reason I'd argue Result.Succeeded needs to be split into Result.Succeeded and Result.SucceedTransact with IsModified set for SucceedTransact but not Succeeded. Allowing a true indication of user response v's command transaction state.

Guy

Hi Guy,

Thank you for the clarification! I completely agree. To keep it as simple as possible for the default case and simultaneously maintain maximum backwards compatibility, Result.Succeeded could close the transaction and a new enumeration value Result.SucceededUnmodified could be added to indicate succcess and still abort the transaction.

Best regards, Jeremy.

I vote for Result.Completed

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

Jeremy Tammik

AboutTopicsIndexSource