Revit 2018 API - Undocumented Changes - Have you found any?

[matthew_taylor]

Hi Everybody,

Each year I upgrade my codebase for use with the new version of Revit. Each year, I rid my code of deprecated and/or obsolete function warnings/errors.

Each year I seem to find an undocumented change in the way the Revit API works.

'The Factory', can we *please* have a more detailed and complete list of changes? Can you add this change to the documentation, please?

My 'find' this year is a change in the way PromptForFamilyInstancePlacement works.

This function used to just return focus to your function upon cancelling by the Reviteer. In Revit 2018, cancelling of this function by your Reviteers throws an Exceptions.OperationCanceledException [sic] exception.

Easily fixed, once discovered:

Try
    docUi.PromptForFamilyInstancePlacement(familySymbol)
Catch ex As Exceptions.OperationCanceledException
    'the user cancelled placement. This should only trigger in Revit 2018.
    'do something if you like
End Try

This change even makes sense! It's a good idea!

It also fills me with dread. What else is going to throw an exception unexpectedly? What other changes are there?

(Yes, I know that this item is *vaguely* alluded to in the 'what's new' document, but it's not documented anywhere.)

Have you found any hidden 'treasures' that you want to share?

[Sherbs]

Yikes!  Good catch!  This is more than a bit concerning.

Undocumented exceptions are generally going to be application fatal.  I hope this sort of thing can be addressed more systematically in upcoming releases.

Regarding the specific find, my opinion differs:

There really is nothing "exceptional" or "unexpected" here.  Cancelling placement may be infrequent, but it is an entirely normal user action.  Why even throw in this case at all? 

I'm not terribly passionate about this, just throwing out another viewpoint.  I'm a bit of minimalist when it comes to the use of exceptions. 

-G

[Revitalizer]

Hi Matt,

I think this thread should be put on top of all the other forum topics.

In fact, it's much more important than the "This forum is for Revit API/Programming questions".

Hope it won't exceed more than one single page.

<Sigh.>

Revitalizer

[jeremytammik]

Hi Matt,

Thank you for pointing this out!

I would say that it is precisely alluded to, not vaguely:

http://thebuildingcoder.typepad.com/blog/2017/04/whats-new-in-the-revit-2018-api.html#2.7

The behavior for UIDocument.PromptForFamilyInstancePlacement() was changed to be same as that of PickObject() methods...

Raising the exception you mention corresponds exactly to the PickPoint behaviour.

As you say, the detailed consequences are not explicitly spelled out.

I also fully agree with Greg's statement: exceptions should be exceptional:

• Exceptions should be Exceptional -- http://jacopretorius.net/2009/10/exceptions-should-be-exceptional.html

Expected behaviour should not be communicated using exceptions.

I keep preaching this to little avail:

• Fixing RvtMgdDbg for MEP Connectors -- http://thebuildingcoder.typepad.com/blog/2009/08/fixing-rvtmgddbg-for-mep-connectors.html
• Duplicate Mark Values -- http://thebuildingcoder.typepad.com/blog/2010/03/duplicate-mark-values.html
• Selecting Model Elements -- http://thebuildingcoder.typepad.com/blog/2010/10/selecting-model-elements.html
• Language Independent Subcategory Creation -- http://thebuildingcoder.typepad.com/blog/2011/01/language-independent-subcategory-creation.html
• Exporting Parameter Data to Excel, and Re-importing -- http://thebuildingcoder.typepad.com/blog/2012/09/exporting-parameter-data-to-excel.html
• Parameter DisplayUnitType, Bretagne and Decompilers -- http://thebuildingcoder.typepad.com/blog/2013/03/parameter-displayunittype-and-decompilers.html
• External Command Lister and Adding Ribbon Commands -- http://thebuildingcoder.typepad.com/blog/2013/05/external-command-lister-and-adding-ribbon-commands....
• The Pick Point Methods Throw an Exception on Cancel -- http://thebuildingcoder.typepad.com/blog/2014/09/planes-projections-and-picking-points.html#07
• Never Catch All Exceptions -- http://thebuildingcoder.typepad.com/blog/2017/02/revitlookup-using-reflection-for-cross-version-comp...

Cheers,

Jeremy

[matthew_taylor]

Hi @Sherbs,

Systematically is the key word. I believe that the API is automagically created, so one would imagine automagically creating the documentation is an obvious thing to do also. (Well, it looks like it is. It's using the function <summary> info. It's just not up to date.) Create a diff from the last version, and you have your updates list ready for embellishment.

After some further thought, I agree. Not exceptional!

Hi @Revitalizer,

I agree! A list of known bugs would be useful also.

I hope so too.

Hi @jeremytammik,

Haha, upon further thought, yes; it was just alluded to.

---

@Anonymous wrote:

Expected behaviour should not be communicated using exceptions.

---

Perhaps you should preach this to 'The Factory' developers?

Can you request an addition to the documentation, please?

[jeremytammik]

Dear Matt,

Fully agree on all points. Remains the question, Is the factory amenable to preaching?

In any case, since this issue also arose in an ADN case, I decided to highlight it on the blog as well:

http://thebuildingcoder.typepad.com/blog/2017/05/prompt-cancel-throws-exception-in-revit-2018.html

Sure, I'll ask them to add this to the docs.

Thank you very much for raising this!

Cheers,

Jeremy

[Anonymous]

The fact that Jeremy has only recently modified his own code shows that Autodesk dropped the ball on this on... 

[Anonymous]

Hi, I already posted this one on Jeremy's blog. I am finding that duplicating a linear dimension style in 2018 (type.Duplicate("MyType") is returning 'SecretInternalLinAngDimStyle....' instead of 'MyType'. The full code snippet is on The Building Coder. Has anyone else experienced this?

[jeremytammik]

Can you add a link to your post, please?

Thank you!

[Anonymous]

Sure here it is:

http://thebuildingcoder.typepad.com/blog/2017/04/whats-new-in-the-revit-2018-api.html#comment-333137...

Thanks!

[jeremytammik]

OK, I see. 

To keep things in order, I suggest that you submit your issue as a new discussion thread here in the forum and attach a complete minimal reproducible case to it:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Please include the problematic code as a macro in the minimal sample model so the development team can analyse it easily.

Thank you!

[Anonymous]

Wow that's some hoops to jump through! To reiterate the problem then: When duplicating a linear dimension style in Revit 2018, the name of the duplicated type is not "MyType" but some obscure string "SecretInternalLinAngDimStyle...". This was working fine in 2017 and previous. Please find the code to reproduce this behaviour in the attached file.

Thanks.

[Anonymous]

Hi Jeremy,

I posted a new discussion thread as you suggested with code snippet to reproduce. Any progress on this?

Regards

Paul

[jeremytammik]

Not yet. I'll keep you posted.

Cheers,

Jeremy

[Anonymous]

There seems to be an undocumented 'fix' to assigning a bounding box to the View3D's CropBox property in Revit 2018. In prior versions of Revit, when you assigned a bounding box to this property, it would assign the Min and Max values and ignore the Transform property. In Revit 2018 it appears that if you assign a bounding box whose Transform does not match the original Crop Box's transform, then Revit transforms the Min and Max values such that the crop box is incorrect. The 'fix' I've found is to ensure that your new bounding box has a transform that matches the original crop box before assigning to the CropBox property..

https://forums.autodesk.com/t5/revit-api-forum/setting-cropbox-for-a-3d-view-with-revit-2018/td-p/71...

[Anonymous]

Thanks Jeremy.

[Anonymous]

Hi Jeremy,

I still have not received any advice as to how to get around not being able to duplicate dimension styles in 2018. I had hoped it would be fixed or workaround suggested before we released our product.

Best regards

Paul

[matthew_taylor]

Hi Paul,

2018.1 is out. Have you tested using that version?

If you're desperate for an API workaround, here's one way to do it:

1. Open a second model. (I think you can do this without a template now?)
2. Use the copy-paste utils to copy your main model dimension style to the second model.
3. Rename the style in the second model.
4. Copy-paste the renamed style back to your main model and modify as necessary.
5. Close the second model.

It'll be slow, but it should work.

[Edit]

p.s. If you've not signed up to Revit Beta testing, then it would be worthwhile doing (to see if the issue persists there).

[/Edit]

[Anonymous]

Hi Matt,

Thanks for your suggestion, but not sure how the new style would be loaded by customers.

The problem persists in 2018.1, so I guess my post didn't get through to the developers - I thought this Forum was monitored by them?.

The annoying part is although I only create the custom style if it isn't present in the model, users are going to end up with 100's of dimension styles called "SecretInternalLinAngDimStyle5473j6181" - because this is not the name I gave it.

I would appreciate this being passed on to the developers with most urgency. Meanwhile I will check if we are part of the beta program.

Best regards

Paul

[matthew_taylor]

@Anonymous,

I've just got it working okay - it's not a bug (in 2018.1 at least). I'll reply on your forum topic:

https://forums.autodesk.com/t5/revit-api-forum/linear-dimension-style-does-not-duplicate-in-2018/m-p...