Through the Interface

Series of posts on mobile Revit model viewing

I’m hopefully sunning myself on the beaches of Brittany, at this point, but here’s some information that Mikako Harada kindly brought to my attention.

Adam Nagy has put together a fantastic series of posts on the AEC DevBlog that I think will be of general interest:

• Revit model viewer for iOS – part 1
• Revit model viewer for iOS – part 2
• Revit model viewer for iOS – part 3

Adam was apparently inspired by Philippe Leefsma’s Inventor viewer for Android – something I’ll also link to, once I see it’s been published.

September’s Plugin of the Month live on Autodesk Labs: TransTips

Regular readers of this blog may have followed the development of this plugin, but I’ve written this post is to announce its availability more officially (in addition to Scott’s post from last week).

TransTips uses the Bing Translator web service to translate tooltips into one of 36 languages on-the-fly, as they are displayed by AutoCAD, Inventor, Revit, 3ds Max and the products based upon them.

The 36 languages are those currently supported by the Bing Translator service:

Arabic, Bulgarian, Catalan, Chinese, Czech, Danish, Dutch, Estonian, Finnish, French, German, Greek, Haitian Creole, Hebrew, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, Slovak, Slovenian, Spanish, Swedish, Thai, Turkish, Ukrainian, Vietnamese

(This list has grown by one since I started work on this tool: Hindi was added sometime in the last few weeks, and I expect the list will grow further, over time.)

I haven’t listed English, but it should also be noted that the tool can also be used to translate into English from localized versions.

To help announce the tool, I’ve put together a short YouTube video to demonstrate some of its capabilities:

I’m excited about this plugin for a number of reasons…

Firstly – from a customer perspective – I’m optimistic that this kind of technology will make the difference for customers currently having to use a product in a language they’re not overly familiar with. Machine translation doesn’t always provide great results, but it is getting better (the technology itself isn’t necessarily the problem, as much as the way the translation engine is trained: the quantity, quality and domain applicability of the material used makes a huge difference). And as this plugin checks a local XML cache before translating, it can also be used to deploy “preferred” translations, which also happens to remove the need for a live Internet connection. But anyway – the point is that while MT isn’t perfect, but it may be just enough to help make sense of something that was previously a complete mystery.

Secondly – from a technology perspective – I think it’s really cool that the core implementation of this plugin works across several products (four core ones plus the various vertical products based on them). Some product-specific code is needed to enable loading in each environment – which means a separate DLL is still needed for each main product – but the core implementation is the same. The implementation is also pretty simple: an implementation with relatively few moving parts creates some very interesting results. Results which will scale both with the languages provided by Bing and with the breadth of content added to our products’ ribbon user interface (it should work well with tooltip content you provide for your own application’s ribbon items, for instance).

A final comment on this tool: while I doubt many readers of this blog will themselves need to use this plugin to understand the capabilities of Autodesk products, please do help spread the word if you belong to a community that you feel would benefit from using it. I’m very keen to get feedback on the tool, to see how best to take it forward.

The “My First Plug-In” series

A few years ago I mentioned that my team was looking into learning paths for novice programmers. This effort has led to the “My First Plug-In” series, of which we now have two guides ready:

My First Revit Plug-In

My First Inventor Plug-In

This series is really intended for power-users of Autodesk software who want to take their use of our products to the next level, but need some targeted help on the programming side of things.

We currently have guides for Maya and AutoCAD in the works. While many of this blog’s readership won’t need this kind of assistance, I think many will enjoy what Stephen Preston is cooking up for AutoCAD. ;-)

And perhaps others will enjoy learning a little about Revit and Inventor with the above guides: be sure to take a look and let us know what you think.

Translating tooltips in AutoCAD, Inventor, Revit and 3ds Max using .NET

After adding Revit and then Inventor support to the original AutoCAD application, it made sense to go ahead and include support for 3ds Max. Here’s a solution supporting these four products (and their verticals). And I can now confirm that a version of this application will be September’s Plugin of the Month on Autodesk Labs.

You may have noticed a lot of UI consistency introduced across these Autodesk products, in recent years, mainly due to a coordinated push from our product teams for a more consistent user experience. An internal acronym was used for the project driving consistency across these four products, which happens to be the name of a famous Nike running shoe (any guesses? ;-). We tend not to use the name externally – as it’s an existing product name – but the project has done a fantastic job of driving consistency and technology sharing across these products, ultimately paving the way for the introduction of suites.

It’s this sharing of component technology across our products – in particular of the AdWindows.dll module – that has enabled this application to work across all these products with a relatively small amount of product-specific code.

Here’s a quick screenshot of TransTips working inside 3ds Max. With 2012 there’s a fairly lightweight ribbon implementation, which means this tool doesn’t really help translate very much of 3ds Max’s functionality, but it’s something. The below image shows a tooltip being translated into Latvian:

For now I’ve held off on the crowdsourcing-related enhancements (including the hooks and UI for direct XML editing). It’s likely I’ll come back to this, at some point, but for now I’m going to wait and see how the plugin is received (and used).

Loading blocked and network-hosted assemblies with .NET 4

As you’re probably mostly aware, many of our 2012 products use .NET 4 as standard. This has proven “interesting” (i.e. challenging) when it comes to loading – for example – plugin DLLs downloaded from the web, due to .NET’s updated security model.

Our ADN Plugins of the Month on Autodesk Labs are a prime example: most were posted prior to AutoCAD 2012 shipping, but when downloaded locally and NETLOADed into AutoCAD 2012, very often a security error gets reported:

Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Program Files\Autodesk\AutoCAD 2012 – English\ADNPlugin-QRCodes.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) File name: 'file:/// C:\Program Files\Autodesk\AutoCAD 2012 – English\ADNPlugin-QRCodes.dll ' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

It also happens in our other products making use of .NET 4 (Revit, in particular).

This is now by far the most common problem reported regarding these plugins, in spite of efforts to document the problem and the solution. (There’s also some helpful information on MSDN, in case.)

When this problem first arose, it took a while for it to be understood (by me, at least). If you build the DLLs locally, clearly there isn’t a problem. And if *.autodesk.com happens to be in your trusted sites zone in Internet Explorer (which it is for most Autodesk employees, understandably) then the issue doesn’t happen, either. Luckily it doesn’t occur for the Exchange Store as every app is wrapped in a simple installer and so doesn’t suffer from this issue.

Anyway, to make life easier when working with these plugins, I make use of a little trick – modifying acad.exe.config, to add the loadFromRemoteSources element – to stop the issue from occurring. Here’s my current acad.exe.config, which also includes the change to reduce debugger output noise mentioned previously:

<configuration>

  <startup useLegacyV2RuntimeActivationPolicy="true">

    <supportedRuntime version="v4.0"/>

  </startup>

  <runtime>         

    <loadFromRemoteSources enabled="true"/>

  </runtime> 

  <system.diagnostics>

    <sources>

      <source name="System.Windows.Data" switchName="SourceSwitch">

        <listeners>

          <remove name="Default" />

        </listeners>

      </source>

    </sources>

  </system.diagnostics>

</configuration>

The loadFromRemoteSources change works well for Revit, too. Interestingly it doesn’t have any effect in Inventor 2012, which is still using .NET 3.5.

One other important thing to note: this allows you to load .NET assemblies from network locations, something that has been an issue for a long time. This is especially needed now that I’m working inside Parallels on my MacBook Pro: I don’t store data inside my Windows 7 installation, I leave it on the native hard-drive which gets mapped through to Windows as a network location. Which means I can now load .NET DLLs from that drive into AutoCAD and Revit (but not into Inventor, as yet).

I will say that making this change could potentially leave your (or – more importantly – your users’) system(s) more open to the execution of malicious, so make it at your own risk.

Translating tooltips in AutoCAD, Inventor and Revit using .NET

Once again, it turned out to be pretty straightforward to add Inventor support to our TransTips application. We now have a single solution which builds plugins for AutoCAD, Inventor and Revit. The plugins share a common translation and caching engine as well as a WPF graphical user interface for selecting languages.

Here’s a demonstration of the various plugins in action:

I’ve fixed the right-to-left issue highlighted in the video, incidentally.

The next steps are to implement an in-product editing capability and then perhaps to support 3ds Max. One great aspect of this project is that I’m getting to learn a little more about developing for products other than AutoCAD, which is fun. :-)

Translating tooltips in both AutoCAD and Revit using .NET

A quick update, today. Last week Jeremy posted a migrated version of the TransTips plug-in for AutoCAD, this time working inside Revit. Thanks to the shared use of AdWindows.dll in both products, this was actually really easy.

After this initial version, it made sense to refactor the code to have a core, shared file (not necessarily a separate DLL component – sharing source can give many benefits for smaller projects, such as this) used to build plugin DLLs for both AutoCAD and Revit.

Here’s the result: a single solution which will build TransTips DLLs for AutoCAD and Revit (including built versions of the DLLs). I won’t go into the specific details, here, although I did do as promised with regards to checking for network availability: if the app doesn’t manage to contact the Bing Translate service, it continues to work in offline mode, picking up translations from local XML files, where available. It’s also possible to specify this mode by default (with a very minor code change).

Otherwise the code itself should be reasonably straightforward. I used the “Add Existing Item –> Add Link” capability in VS 2010 to maintain a common file across both projects in the solution, which was new to me, and gave me exactly the project structure I was after.

In the next post in this series: support for Inventor (that one’s for you, Alex ;-) and additional work to share a common, WPF-based language selection UI across all the projects. At some point, beyond, I’ll also look at an editing capability for the XML data (also shared), and perhaps even some true componentization. We’ll see about that, though – in many ways I quite like the current approach of building a single DLL per-product.