Manufacturing DevBlog

Forge DevCon - Call For Proposals

By Adam Nagy (@AdamTheNagy)

Have you created something cool using the Autodesk Forge platform and want to share with others what you learnt? :)
Then why not do it at our next Autodesk Forge DevCon taking place at the Fort Mason Center, San Francisco,  June 27th to 28th, 2017?

Call for proposals is now open.

To submit your proposal, visit forge.autodesk.com/AttendDevCon and click on the 'Call for Papers' tab - or go straight to the Call for Papers site, where you'll find more information about the types of sessions we're looking for.

Add to "Frequently Used Subfolders" collection

By Adam Nagy (@AdamTheNagy)

As mentioned in this forum post, unfortunately, the relevant API does not work :(

Until it gets sorted, you could use the following workaround: edit directly the Project file (*.ipj), which is in fact an xml file.

The <Path> needs to starts with "Workspace\" and then continue with the path to the subfolder you want to add. 

I'm showing how to do it in VBA, but .NET (also accessible from iLogic) has similar support for xml editing.  Just add a reference to the "Microsoft XML, v6.0" library:

Sub AddFrequentlyUsedSubfolder()
    Dim oProjectManager As DesignProjectManager
    Set oProjectManager = ThisApplication.DesignProjectManager
    
    Dim oProject As DesignProject
    Set oProject = oProjectManager.ActiveDesignProject

    ' Use 'Microsoft XML, v6.0'
    Dim xmlDoc As DOMDocument60
    Set xmlDoc = New DOMDocument60
    xmlDoc.async = False
    
    Dim strProjectPath As String
    strProjectPath = oProject.FullFileName
    
    ' Load the project file (*.ipj)
    Call xmlDoc.Load(strProjectPath)
    
    ' Select the  node
    Dim xmlProjectPaths As IXMLDOMNode
    Call xmlDoc.setProperty("SelectionLanguage", "XPath")
    Set xmlProjectPaths = xmlDoc.selectSingleNode("/InventorProject/ProjectPaths")
    
    ' Add the new subfolder
    ' We need to add something like this:
    ' <ProjectPath pathtype="FrequentlyUsedFolder">
    '   <PathName>MyFolder</PathName>
    '   <Path>Workspace\MySubfolder</Path>
    ' </ProjectPath>
    Dim xmlProjectPath As IXMLDOMNode
    Set xmlProjectPath = xmlDoc.createNode(1, "ProjectPath", "")
    
    Dim xmlPathType As IXMLDOMAttribute
    Set xmlPathType = xmlDoc.createAttribute("pathtype")
    xmlPathType.value = "FrequentlyUsedFolder"
    Call xmlProjectPath.Attributes.setNamedItem(xmlPathType)
    
    Dim xmlPathName As IXMLDOMNode
    Set xmlPathName = xmlDoc.createNode(1, "PathName", "")
    xmlPathName.Text = "MyFolder"
    Call xmlProjectPath.appendChild(xmlPathName)
    
    Dim xmlPath As IXMLDOMNode
    Set xmlPath = xmlDoc.createNode(1, "Path", "")
    xmlPath.Text = "Workspace\" + "MySubfolder"
    Call xmlProjectPath.appendChild(xmlPath)
    
    Call xmlProjectPaths.appendChild(xmlProjectPath)
    
    ' Make another project active so that we can save the changes
    Call oProjectManager.DesignProjects(1).Activate(False)
    
    ' Save the changes
    Call xmlDoc.Save(strProjectPath)
    
    ' Make our project active again
    Call oProject.Activate(False)
End Sub

 

Fusion API: Which API I should choose?

By Xiaodong Liang

Fusion API provides 3 types of languages: Python, JavaScript and C++. I found an interesting discussion on Fusion API forum, where our API designer Brian Ekins gave an answer on the specifics of each language. To make it more searchable on internet, I posted it in the blog. And we could polish it with more information in the future.

There are several things to consider when choosing a language.

As far as the API for each of the languages being developed; functionality is delivered for all three languages at the same time.  Internally, we implement the C++ interface first but then wrappers are constructed automatically for Python and JavaScript.  So all three have the same capabilities.  However, there's one exception to this in that JavaScript doesn't support all of the events.  We ran into a technical problem with events and JavaScript so we've blocked exporting most events in JavaScript.

For speed of execution, C++ will be the fastest since it is compiled code that runs within the Fusion process.  On Windows and Mac, Python also runs in-process but it's interpreted and Python isn't known as a particularly fast language.  On Windows, JavaScript runs out of process and as a result is much slower.  On Mac, it runs in-process and is similar to Python.

For speed of development, much depends on which language you have the most experience with already.  A new language always has a learning curve at the beginning.  But assuming that you are comfortable with all three, I would say that Python is probably the language someone could develop code the fastest in.  One reason for this is that you do the development and debugging within the same IDE.  You can also do some prototyping using the text window in Fusion.  C++ has an advantage that it is typed so you're able to catch many problems while writing and compiling, while you end up debugging a lot of problems at run time with the other two languages.

Another thing to consider is if you plan to deliver your program commercially.  With JavaScript and Python you're essentially delivering your source code.  With C++ you're delivering a binary which is much harder for someone to crack.

If you don't care about the security of your code, I would recommend Python and if you do need to protect your code then C++.

I agree with Brian’s comments. Just one of my practices of Fusion API: I prefer to Python because it is easy to debug and make a quick demo code.

iLogic: ActiveDocument.ComponentDefinition throws exception for specific document

By Xiaodong Liang

Recently, we got a strange issue. With a specific dataset, we opened all files in cascade views, then activated each document and ran an external rule. The rule is quite simple. It just gets the document ComponentDefinition and access parameters.

Dim compDef = ThisApplication.ActiveDocument.ComponentDefinition

For most documents, it works well. but for specific assembly document, it throws an exception that says: Member not found.

We doubted ComponentDefinition / Parameters have been broken when activating the document at his side, so we tested with a VBA code. But the code tells the ComponentDefinition / Parameters are always valid. While the issue seems not always reproducible.

Finally, our expert of iLogic Mike Deck shared the insights:

It is caused by internal .NET behavior to do with COM interop. Here’s a simplified rule that will reproduce it:

- Create a new part

- Run the rule in the part

- Create a new assembly

- Run the rule in the assembly

The order matters: it won’t break if you run it in the assembly first.

Here’s what’s happening: ActiveDocument returns a Document object. There is no ComponentDefinition property on the Document object. So VB.NET tries to do late binding. When you run the rule on a Document that is also a PartDocument, it will find a ComponentDefinition property with a DispId on that object. Then later you run the rule on a Document that is also an AssemblyDocument. It also has a ComponentDefinition property, but with another DispId.

For some reason, VB.NET will fail to find that property. it might probably cache the first DispId (from PartDocument), and associates it with the Document interface. Then it thinks that it can always use that DispId to access ComponentDefinition on a Document. But that DispId will fail if the object is an AssemblyDocument.

It seems like an issue of Microsoft .NET. So in such case, there is a workaround. In VB.NET code, never try to access the ComponentDefinition on a Document object. Instead, always cast it to a PartDocument or AssemblyDocument first. Here’s sample code to get the UserParameters:

Dim doc = ThisApplication.ActiveDocument

Dim params As Parameters = Nothing

If doc.DocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then

  Dim assemDoc As AssemblyDocument = doc

  params = assemDoc.ComponentDefinition.Parameters

ElseIf doc.DocumentType = DocumentTypeEnum.kPartDocumentObject Then

  Dim partDoc As PartDocument = doc

  params = partDoc.ComponentDefinition.Parameters

End If

 

Dim userparams As UserParameters = params.UserParameters

It requires a lot more than a single line of code, but it avoids the problem.