Mod the Machine

New API Help Format

With the latest release of Fusion, a new format for the syntax in the help has been introduced.  Although this change has been made for the Fusion help, the same help system is also used for Inventor so these changes can also be fairly easily made for the Inventor API help too.  Because of that I would like to get feedback from both Inventor and Fusion users about this new format.

In the old help, the syntax was shown using a pseudo Python or Javascript syntax that represented that function as if you were writing the function.  In Inventor it uses a VBA style syntax.  It was pseudo code because it also included argument types which aren’t actually needed in Python or JavaScript but were include because they help to provide the full description. 

 

Old Style
Below is an example showing the MirrorFeatures.createInput method in both Python and JavaScript.

 

And here’s an example of how properties were represented using the isSuppressed property of the MirrorFeature.

 

New Style
With the new syntax style it attempts to show how you would actually use the method, property, or event in your code.  So instead of showing the format for the person developing the API, it’s showing the format for the person using it. It’s not really a runnable sample but in many cases is very close.  Below is  the new format for the same method and property illustrated above.

 

And here’s the syntax for the isSuppressed property.

 

There is also event specific syntax.  A Python example is shown below.  This illustrates fully what’s needed in order to implement that event.

 

You can see all of the new help at the Fusion Learning Site.  Click the “Programming Interface” link and then use the table of contents to access the “Fusion 360 API Reference Manual” section, as shown below.

 

I Need Your Help
I can use your help with honest opinions about whether this new format is better than the old and then, with whatever format we continue with, suggestions about how to improve it.  I know there is still a lot of room for improvement.  Every time I use and look at the help I see some things that could be improved and I work on some of them in each release, but I’m sure some of you have some other and better ideas.  Feel free to post comments here or you can also send them directly to me at brian.ekins@autodesk.com.

-Brian

Fusion 360 Hackathon (Earn $500)

We’re still putting the specific details together but I wanted to give some advance warning for a Fusion 360 Hackathon coming up in September.  This will be an  online Hackathon that spans several weeks and consists of presentations and lots of online mentoring to help you get your Fusion 360 apps developed and on the Fusion Exchange Store.  To help encourage you a bit more, if you publish your app on the Exchange store by a defined deadline you’ll get $500.

With the Fusion 360 API supporting add-ins and now with the latest release also supporting C++, and with a $500 incentive, it’s now a great time to begin investigating Fusion to see if Fusion is a viable platform for your app.  These don’t have to be large full-scale applications but can also be smaller utilities that enhance the use of Fusion 360.

-Brian

C++ is Here for Fusion

The latest update for Fusion went out this past weekend so if you’ve run Fusion since then you have it.  You’ll now see a new “C++” option when you create a new script or add-in, as shown below.

That will create a new C++ project.  A C++ project consists of a .manifest file, (the same as Python and JavaScript), but also a .cpp file and two project files; a .vcxproj file for Windows and Visual Studio and a .xcodeproj file for Mac and XCode.

The API is the same as what’s been exposed for Python and JavaScript.  In fact the Python and JavaScript interfaces are layers on top of the C++ interface.  Each language has it’s own quirks so the API is used a bit differently for each one but it is the same API. You can read all about the C++ quirks in the C++ Specific Issues topic in the Fusion 360 API User’s Manual.

Some highlights of the C++ API are:

• You can now deliver your applications as a binary file instead of source code.
• You now have a typed language which means you’ll be able to user reliable Intellisense (code hints) when writing your program.  This is a huge benefit and means you’ll spend a lot less time in the documentation looking to see what methods and properties a certain object supports and what the arguments are for a particular function.
• Performance is much better than Python and JavaScript.
• You get to use a development environment you’re already familiar with.

Probably the biggest downside is that because you’re delivering the runtime binary, you have to compile your code separately for Windows and Mac.  Except in cases where you’re using Windows or Mac specific libraries you should be able to have a single set of source but you’ll need to compile it on Windows to create the Windows compatible .dll file and then also compile it on a Mac to create a Mac compatible .dylib file.

You can post any comments (positive or negative) or problems you have to the Fusion 360 API forum, where I’ll be watching.

-Brian

Tracking API wishes

IdeaStation's are a good idea for tracking wishes. This way people can also see ideas that they too thought of, but did not actually log in the end thinking that not many people would care about them. Now they just have to give a thumbs up :)
- Inventor IdeaStation
- Fusion IdeaStation

Though they were mainly created for product wishes, I do not see why they could not also be used for API wishes - and some people are using them for that already.

If you plan to log there an API wish then please use the API-iLogic category add a tag that would make it easier to track those kinds of wishes: InventorApi for Inventor API wishes, and FusionApi for Fusion API wishes. If it simply has an API tag and you click on it then it shows the wishes for all the products.
Note: I use InventorApi instead of InventorAPI, because for some reason the system automatically turns the tag name into that. :-/

I already added those tags to most API wishes:
- http://forums.autodesk.com/t5/tag/InventorApi/tg-p
- http://forums.autodesk.com/t5/tag/FusionApi/tg-p/board-id/125 

-Adam

Fusion app paths

If you are developing apps for the Fusion app store then it could be useful to know where exactly Fusion is looking for add-in bundles to load, so that you can test the loading on your side. To see what a .bundle should contain you can just download any of the free apps from the Fusion app store. 
Note: on MacOS you have to right-click the .bundle folder and select Show Package Contents to see what's inside it:

The Windows and MacOS file structure is different so the add-in folder locations will be different. But on MacOS we also have two install types of Fusion:
- web install
- Mac App Store (MAS) install

All MAS apps run in a sandbox environment, and they cannot load additional modules from outside their folder structure without user interaction. That's why the MAS version of Fusion is using a different path for Fusion apps.

Windows:
%APPDATA%\Autodesk\ApplicationPlugins

MacOS web install:
~/Library/Application Support/Autodesk/ApplicationPlugins 

MacOS MAS install:
~/Library/Containers/com.autodesk.mas.fusion360/Data/Library/Application Support/Autodesk/ApplicationPlugins 

Note: if you want to use the above paths inside a script on MacOS, you need to deal with the spaces in folder names - e.g. in /Application Support/. Unlike in Windows, here you cannot put the whole string between apostrophes, because then the special character '~' (which means the current user's folder) would not get resolved. So either you can just escape each space character in the string with a backslash '\' e.g.:
~/Library/Application\ Support/Autodesk/ApplicationPlugins
... or put the part after the '~' character between apostrophes:  
~'/Library/Application Support/Autodesk/ApplicationPlugins' 

-Adam

One Million Downloads on Autodesk Exchange

The Autodesk Exchange store has now had over one million apps downloaded.  By chance, the one millionth app happened to be for Inventor.  You can read more about it and how customers are using the store in the official announcement.

The Inventor store now has 206 apps available.  With the continued work on Fusion 360 and it’s API, it’s now also feasible to begin writing apps for Fusion.  The first few are now available on the Fusion 360 store.

Many of these apps have been developed by readers of this blog and I want to thank you for helping to make Autodesk Exchange a success and would like to encourage you to keep creating apps that will help to make Inventor and Fusion 360 customers more successful.

-Brian