Edit Family Requires No Transaction

I recently received a note from Matt Mason pointing out that the behaviour of the EditFamily method changed in Revit 2013, and a suggestion to highlight this fact.
The suggestion is very valid, since his note was quickly followed up by a matching

question
by

Woong Ki Sung
on

reloading a family
,
who ran into the very same issue:

Question: I am testing some code to edit family types in Revit 2013, and I have a transaction problem even though I set up manual transactions properly.

The code is
very simple, so could you please check? In advance, thank for your help.

Here is the answer by Matt:

Answer: A quick note after I saw your recent post on upgrading add-ins.

I had an interesting case the other day:
there is a new API requirement in 2013 that all transactions must be closed before calling EditFamily
– it throws an exception to that effect.

I hadn’t really focused on this before, and the add-in in question was actually still set up for Automatic mode
– I had to convert my add-in to manual transaction mode so that I could control the transactions and close them all prior to calling EditFamily.

The remarks on the EditFamily method in the Revit 2013 API help file RevitAPI.chm now clearly state:

<

p style=”color:darkblue”>Gets the document of a loaded family to edit. This creates an independent copy of the family for editing. To apply the changes back to the family stored in the document, use the LoadFamily overload accepting IFamilyLoadOptions.

<

p style=”color:darkblue”>This method may not be called if the document is currently modifiable (has an open transaction) or is in a read-only state. The method may not be called during dynamic updates. To test the document’s current status, check the values of IsModifiable and IsReadOnly properties.

Many thanks to Matt for pointing this out!


Comments

6 responses to “Edit Family Requires No Transaction”

  1. Hi Jeremy, do you know if there are any changes in the performance of the EditFamily (or even in the LoadFamily) methods in the new 2013 API?
    Thanks

  2. Dear Fabio,
    Nope, no idea.
    Why don’t you benchmark it yourself and let us know?
    http://thebuildingcoder.typepad.com/blog/2012/01/timer-code-for-benchmarking.html
    Thank you!
    Cheers, Jeremy.

  3. I think this is another example of the transaction discussion previously. Consideration of discreet transactions or in someways a ‘unit of work’ is clearly much more important in the design of commands for R13 and beyond.
    In addition to Arnost’s recommendation of scoping transactions maybe it’s time to recommend using the Manual transaction mode only and the removal of Automatic mode. This would pave the way for removing the transaction and regeneration attributes all together.
    Cheers,
    Guy

  4. Dear Guy,
    I fully agree, and practiced exactly what you suggest at the Revit API training in Munich last week, with one small caveat:
    I personally never use automatic transaction mode, but I do use both the manual and read-only ones.
    It would actually be interesting to know the exact difference between an external command using read-only mode and one using manual without opening any transactions.
    Cheers, Jeremy.

  5. Arnošt Löbel Avatar
    Arnošt Löbel

    I believe I said it publicly before, but probably not on this blog yet, Jeremy. First of all, Automatic Transaction Mode is considered obsolete, and we (Autodesk.Revit) do not recommend using it for new external applications. It only exists to ensure compatibility with older applications. The Automatic mode has many limitations (for what an external command can or cannot do), while it has virtually no benefits whatsoever. It is somehow likely it will go away in some future release of Revit.
    Real-Only transaction mode does two things (well, it’s one thing, really, but I’ll split it.) For one, the command using it cannot have any transactions and may not call any methods that modify a document, directly or indirectly, or even temporarily. Secondly, while this external command is being executed, nobody else is allowed to modify the document or have a transaction either; that includes Revit itself, but also applies to other applications that might be invoked through events (for example). All this basically guarantees that during the entire execution of the external command the current models stays unmodified.
    Arnošt

  6. Dear Arnošt,
    Cool, edifying, and very clear!
    I promoted your answer to a post of its own to ensure it does not go unnoticed:
    http://thebuildingcoder.typepad.com/blog/2012/05/read-only-and-automatic-transaction-modes.html
    Thank you!
    Cheers, Jeremy.

Leave a Reply to Jeremy TammikCancel reply

Discover more from Autodesk Developer Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading