Manufacturing DevBlog

Inventor API: Change sketch parameters of draft view in drawing document

By Xiaodong Liang

In drawing document, draft view also contains sketch with the similar functionalities of genetic sketch in part or assembly. While it looks the dimension constraint of the sketch entities are not managed by Parameter in the document. 

With API, we can still access these parameters and manipulate them directly.  The VBA code demos a workflow to change a specific parameter of a specific sketch of a specific draft view. Since draft view could have the same name, the code uses index as a unique identification. 

 

 

Sub test()

  Call changeDraftSketchConstaintParam(1, "d0", "200 in")
  
End Sub
Sub changeDraftSketchConstaintParam(draftIndex, paramName, newV)

    Dim oDoc As DrawingDocument
    Set oDoc = ThisApplication.ActiveDocument
    
    Dim oSheet As Sheet
    Set oSheet = oDoc.ActiveSheet
    
    Dim oView As DrawingView
    Set oView = oSheet.DrawingViews(1)
    
    If oView.ViewType = kDraftDrawingViewType Then
        Dim oDraftSketch As Sketch
        Set oDraftSketch = oView.Sketches(draftIndex)
        
        If Not oDoc.ActivatedObject Is oDraftSketch Then
           oDraftSketch.Edit
        End If
        
        Dim oDim As DimensionConstraint
        For Each oDim In oDraftSketch.DimensionConstraints
            Dim oParam As Parameter
            Set oParam = oDim.Parameter
            
            If oParam.Name = paramName Then
                 oParam.Expression = newV
                  
            End If
        Next
        oDraftSketch.Solve
        oDraftSketch.ExitEdit
    End If
    oDoc.Update
End Sub . 

iLogic does not provide a direct module to access these parameters, but the same VBA code could be used in iLogic with just a little bit modification:

Sub Main()

  Call changeDraftSketchConstaintParam(1, "d0", "200 in")
  
End Sub

Sub changeDraftSketchConstaintParam(draftIndex, paramName, newV)

    Dim oDoc As DrawingDocument
    oDoc = ThisApplication.ActiveDocument
    
    Dim oSheet As Sheet
    oSheet = oDoc.ActiveSheet
    
    Dim oView As DrawingView
    oView = oSheet.DrawingViews(1)
    
    If oView.ViewType = kDraftDrawingViewType Then
        Dim oDraftSketch As Sketch
         oDraftSketch = oView.Sketches(draftIndex)
        
        If Not oDoc.ActivatedObject Is oDraftSketch Then
           Call oDraftSketch.Edit()
        End If
        
        Dim oDim As DimensionConstraint
        For Each oDim In oDraftSketch.DimensionConstraints
            Dim oParam As Parameter
            oParam = oDim.Parameter
            
            If oParam.Name = paramName Then
                 oParam.Expression = newV
                  
            End If
        Next
        Call oDraftSketch.Solve()

        Call oDraftSketch.ExitEdit()
    End If
    Call oDoc.Update()
End Sub

  

Remove OLE Links using ReferencedOLEFileDescriptor

By Xiaodong Liang

A few years ago, my colleague Wayne composed a blog on how to remove missing OLE links. Recently, a customer wanted to remove any OLE links when checking in to Vault. Ideally, he needs an iLogic code. So I refactored a little with the code Wayne demoed in VBA and iLogic:

Sub Main()
 
    Dim oDoc As Document
    oDoc = ThisApplication.ActiveDocument
    
    
    If TypeOf oDoc Is AssemblyDocument Then
            Call compositeDoc(oDoc)
    ElseIf TypeOf oDoc Is PartDocument Then
             Call singleDoc(oDoc)
    ElseIf TypeOf oDoc Is DrawingDocument Then
             Call singleDoc(oDoc)
    Else
    	Call MsgBox("wrong file type!") 
    End If
    
    Call oDoc.Update2(True)
     
  
End Sub
 

Sub singleDoc(doc)
        
    Dim oEachOLEDesc As ReferencedOLEFileDescriptor
    For Each oEachOLEDesc In doc.ReferencedOLEFileDescriptors
        oEachOLEDesc.Delete
        doc.Dirty = True
    Next
     
   
End Sub
 
Sub compositeDoc(parentAssDoc)
 
     'remove links of top document
     Call singleDoc(parentAssDoc)

    'remove links of sub document
     For Each oEachDesc In parentAssDoc.ReferencedDocumentDescriptors
        Dim doc As Document
        doc = oEachDesc.ReferencedDocument
        
        Dim oEachOLEDesc As ReferencedOLEFileDescriptor
        For Each oEachOLEDesc In doc.ReferencedOLEFileDescriptors
            oEachOLEDesc.Delete
            doc.Dirty = True
        Next
       
        If TypeOf doc Is AssemblyDocument Then
            Call compositeDoc(doc)
        End If
    Next
   
End Sub

The below code is written in VBA.

Sub breakLinks()
 
    Dim oDoc As Document
    Set oDoc = ThisApplication.ActiveDocument
    
    
    If TypeOf oDoc Is AssemblyDocument Then
            
            
            Call compositeDoc(oDoc)
    ElseIf TypeOf oDoc Is PartDocument Then
             Call singleDoc(oDoc)
    ElseIf TypeOf oDoc Is DrawingDocument Then
             Call singleDoc(oDoc)
    Else
    
        Call MsgBox("wrong file type!")
            
    End If
    
    Call oDoc.Update2(True)
     
  
End Sub
 

Sub singleDoc(doc)
        
    Dim oEachOLEDesc As ReferencedOLEFileDescriptor
    For Each oEachOLEDesc In doc.ReferencedOLEFileDescriptors
        oEachOLEDesc.Delete
        doc.Dirty = True
    Next
     
   
End Sub
 
Sub compositeDoc(parentAssDoc)
 
      'remove links of top document
     Call singleDoc(parentAssDoc)

      'remove links of sub document
     For Each oEachDesc In parentAssDoc.ReferencedDocumentDescriptors
        Dim doc As Document
        Set doc = oEachDesc.ReferencedDocument
        
        Dim oEachOLEDesc As ReferencedOLEFileDescriptor
        For Each oEachOLEDesc In doc.ReferencedOLEFileDescriptors
            oEachOLEDesc.Delete
            doc.Dirty = True
        Next
       
        If TypeOf doc Is AssemblyDocument Then
            Call compositeDoc(doc)
        End If
    Next
   
End Sub

How to reference the AutoCAD COM API in an iLogic rule

By Wayne Brill

You can use AddReference to reference the AutoCAD COM Interops. Below is an iLogic rule to test this. (It just Dims a couple of types) iLogic needs to be able to find the AutoCAD Interop dlls. The path where it looks for the interop dlls is set in the Advanced iLogic Configuration. (tools tab Options). You can copy Autodesk.AutoCAD.Interop.dll and Autodesk.AutoCAD.Interop.Common.dll to the “iLogic AddIn DLLs directory” to avoid the error with the AddReference line of code. This screenshot shows the path where iLogic will look for the interop DLLs. 

 

Here is the iLogic rule that references the AutoCAD Interops. It shows declaring types from the AutoCAD COM API. AcadBlockReference and AcadCircle. It also creates or gets a running session of AutoCAD.

AddReference "Autodesk.AutoCAD.Interop"
AddReference "Autodesk.AutoCAD.Interop.Common"

Imports Autodesk.AutoCAD.Interop.Common
Imports Autodesk.AutoCAD.Interop

Sub Main
Dim oAcadApp As AcadApplication
oAcadApp = CreateObject("AutoCAD.Application")
'If AutoCAD is already running use GetObject
'oAcadApp = GetObject(,"AutoCAD.Application")
oAcadApp.Visible = True

Dim myBlockRef As AcadBlockReference
Dim oAcadCircl as AcadCircle

MessageBox.Show(oAcadApp.Caption, "Title")

End Sub

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.

Inventor iLogic: Dislay Mass from Different LOD on Drawing

By Xiaodong Liang

This is from a forum post in which one customer wanted to get mass of each LOD and display them on the drawing of top assembly. 

The advocate Rossano Praderi shared a solution which is nice to me. He provided the dataset only. I think it will be helpful for more customers with the workflow and codes out of the dataset. So I wrote this blog. Thanks Rossano Praderi!

1. In the attached dataset, there is a top assembly with several components. Three LOD (First, Second, Third) are created.

2. The corresponding drawing of the top assembly is also created.

3. An iLogic rule is attached with this assembly. It activates each LOD one by one, and updates the value of corresponding custom property with the Mass value. If such custom property does not exist, it will be created automatically.

'get RepresentationsManager Dim repMgr As RepresentationsManager = ThisApplication.ActiveDocument.ComponentDefinition.RepresentationsManager   'record current LevelOfDetailRepresentation Dim oCurrentRepName As String  = repMgr.ActiveLevelOfDetailRepresentation.Name   Dim oRep As LevelOfDetailRepresentation Dim oRepName  Dim oMass   For Each oRep In repMgr.LevelOfDetailRepresentations     oRepName = oRep.Name     'activate this LOD     repMgr.LevelOfDetailRepresentations.Item(oRepName).Activate     'get mass      oMass = iProperties.Mass      'update value of custom property      iProperties.Value("Custom", oRepName) = iProperties.Mass Next   'restore repMgr.LevelOfDetailRepresentations.Item(oCurrentRepName).Activate

4. In the drawing document, define some Property Text (from model) in the sheet. e.g. if we need the information of First/Second/Thrid LOD. The values will be displayed in the sheet.

 

Keep selection between rule executions

By Adam Nagy

There is a blog post on selecting multiple components interactively from an iLogic Rule, but it does not highlight the selected objects while the Rule is running in the Inventor versions I tested it in - something might have changed in the meantime. However, using a HighlightSet seems to work fine:

Dim oSet As HighlightSet

' Check to make sure the active document is a part.
If ThisApplication.ActiveDocumentType <> 
DocumentTypeEnum.kPartDocumentObject Then	
  MsgBox("A part document must be open.")
  Exit Sub
End If

' Set a reference to the active part document.
Dim oDoc As PartDocument
oDoc = ThisApplication.ActiveDocument

oSet = oDoc.CreateHighlightSet

While True
  Dim oFace As Object
    oFace = ThisApplication.CommandManager.Pick(
      SelectionFilterEnum.kPartFaceFilter, 
      "Select a face") 
	
    ' If nothing gets selected then we're done	
    If IsNothing(oFace) Then Exit While
	
    oSet.AddItem(oFace)
End While

oSet.Clear()

When you run an iLogic Rule it behaves as starting a command, which also means that the current selection will be cancelled. So we would need to store which entities were already selected inside our Rule and reselect them. In order to keep a list we would need to have a global static variable that could hold on to those entities. Even if we just kept them in a HighlightSet we would still need a global static object to keep a reference to the HighlightSet, because as soon as that goes out of scope it will be deleted and then highlighting will be gone. 

In case of VB.NET the way to create a global static variable is to use the Shared keyword. It is possible to add global variables to an iLogic Rule by implementing the whole Rule class as shown in this article:
https://www.cadlinecommunity.co.uk/hc/en-us/articles/203491091-Inventor-2016-iLogic-Using-Global-Variables

Actually, because you can define the whole Rule class, you can also handle events in it if you want. That means you could even use the InteractionEvents class which enables you to do multi and window selections. However programmatically selecting entities inside a rule using SelectSet.Select or CommandManager.DoSelect does not seem to work well: the entities only get highlighted once the rule finished.

If we stick to HighlightSet then we could use it like this to do selection and re-selection of previously selected entities:

Class ThisRule

  ' Keep track of selected entities
  Shared oSelectedEnts As ObjectCollection  

  Sub Main()
    Dim oSet As HighlightSet

    ' Check to make sure the active document is a part.
    If ThisApplication.ActiveDocumentType <> 
    DocumentTypeEnum.kPartDocumentObject Then	
      MsgBox("A part document must be open.")
      Exit Sub
    End If
	
    ' Initialize the entity collection
    ' If you want to keep track of the previously 
    ' selected entitites then only initialize this variable
    ' if it has not been initialized before
    If oSelectedEnts Is Nothing Then
      oSelectedEnts = ThisApplication.TransientObjects.CreateObjectCollection()
    End If  

    oDoc = ThisDoc.Document
    oSet = oDoc.CreateHighlightSet

    ' Show the previously selected entities
    For Each ent In oSelectedEnts
      oSet.AddItem(ent)
    Next
	
    While True
      Dim oFace As Object
      oFace = ThisApplication.CommandManager.Pick(
        SelectionFilterEnum.kPartFaceFilter, 
        "Select a face") 
		
      ' If nothing gets selected then we're done	
      If IsNothing(oFace) Then Exit While
		
      oSet.AddItem(oFace)
      oSelectedEnts.Add(oFace)
    End While
	
    oSet.Clear()
  End Sub
End Class

 

Customize iAssembly / iPart member creation

By Adam Nagy

I've seen a few posts on the forum about trying to use iLogic code inside iAssembly and iPart factories to customize the created member file to change e.g. some of its iProperties. 

So I thought it could be useful to talk about the internal process of member creation.

iAssembly

This is quite straight-forward. In this case when an iAssembly instance's row is changed in the containing assembly document then Inventor checks if the appropriate member file already exists. If it does, there is nothing to do. If it does not, then:
1) it copies the iAssembly factory file and names it according to the member name
2) updates the properties in the member file based on the iAssembly table row info
3) saves and closes the member file

So in this case if the iAssembly factory has a rule that fires on "Before Save Document" which modifies the document, then it basically modified the created member file - which is what you probably want.

iPart

This is more complicated. When an iPart instance's row is changed in the containing assembly document then Inventor checks if the appropriate member file already exists. If it does, there is nothing to do. If it does not, then:
1) it creates a new part file based on the active part file template and names it according to the member name 
2) in the factory file it starts a transaction which will be aborted later, so that the factory file does not get modified in the end
3) inside the transaction it changes the iPart row to the required one
4) stores all the info it will need later on for the member file: the generated geometry, iProperties, Parameters, etc
5) aborts the transaction
6) copies the previously stored info into the member file 
7) saves and closes the member file

So in this case if the iPart factory has a rule that fires on "Before Save Document" which modifies the document, then it has no effect on the created member file because the event is not firing inside the member file, but inside the factory. Also, inside member files most iLogic functionality, along with lots of other features as well, is disabled so it could not fire an event anyway (you could run a rule explicitly though).

Unfortunately, there are no events specific to member file generation steps that would fire e.g. before the information from the factory file gets saved.
We only have the ModelingEvents.OnGenerateMember (the closest to it in iLogic is "iPart or iAssembly Change Component" but that also fires if the member is already available) but that fires inside the assembly that contains the iPart/iAssembly member instance, not inside the member or the factory.

Hooking into other events could achieve some results, but it might not be very robust.
E.g. if you have a rule in the iPart factory that is set to fire on "Part Geometry Change" to modify some geometry and in it you also synchronously update the document to reflect the changes immediately (using Document.Update2()), then it can modify the geometry that gets copied into the created member file.
But e.g. if you try to modify there an iProperty (like Project >> Description) that will be too late. It seems by the time "Part Geometry Change" is fired those already got stored. Also, that seems to be the only event firing during member creation.
Note: the workaround in the following article only works when you modify the iPart table row explicitly when the factory file is open. It does not work if the row is changed as a result of a row change on a member instance inside an assembly: http://adndevblog.typepad.com/manufacturing/2015/12/no-iproperty-change-event-fired-for-ipart-row-change.html

Bottom line 

Best thing is to keep everything you want to drive inside the member files in the iPart/iAssembly table: the Parameters, the iProperties, etc. 
So if you want to drive e.g. the Project >> Description property, add that to the table:

Since iParts and iAssemblies are driven by an Excel table, you can also use Excel functions to calculate things and set up relationships between cells:

 

Autodesk® Inventor® iLogic™ or Inventor API: Which Is the Right Tool for Me? (Autodesk University Session)

By Wayne Brill

A couple of years ago I had a session on iLogic and the Inventor API. The handout and class examples may help when you first start using iLogic or the Inventor API. As these materials are no longer available on the Autodesk University site you can download them here.

Download CP2544_iLogic_Inventor_API

Download CP2544_iLogic_Inventor_API_code_examples

Download AddIn_That_Adds_rule_from_assembly_tab

No iProperty Change event fired for iPart row change

By Adam Nagy

If you have an iLogic rule then you can hook it up to various events - one of those is iProperty Change:

Though ideally this event should fire even when the iProperty changes as a result of an iPart factory row change, it does not. It's a limitation in the Inventor API.

However, the following workaround is available.

First of all, you might have to add a new user parameter to the part just for this purpose:

Add this parameter to the iPart table and make sure its value changes whenever the iProperty (in this case Title) changes - i.e. it needs to have different values in each row. 

 

Then add a line like this to the rule:

trigger = UserParameter

Even though the purpose of the rule is to work with the iProperty, you can use the parameter change to trigger it.

Attached is the sample part file:  Download IPartTest

Convert VBA to .NET / iLogic

By Adam Nagy

Most of the sample code I publish is in VBA because that is by far the best place to test things out: it's part of Inventor, it has intelli-sense, lets you step through code, you can place break points, use Watches window to check variable values, see all the objects and their functions and properties in the Object Browser, etc. 

When you try to convert VBA code to .NET / iLogic then the 2 main things you need to be aware of are these. I'll show them through trying to run this VBA code from an iLogic rule:

Sub MySubMethod()
  Dim doc As Document
  Set doc = ThisApplication.ActiveDocument
  
  Call MsgBox(doc.DisplayName)
End Sub

Sub MyMainMethod()
  ' Do something
  
  ' Then call another method
  Call MySubMethod
End Sub

1) Main function needs to be the first

If you have multiple methods then the first one should be the one where the whole code execution starts and should be named Sub Main(). In case of my sample I need to move Sub MyMainMethod() to the top of the code and rename it to Sub Main(). 

2) No Let/Set

You simply have to delete the "Set" keywords from your code

The final iLogic code:

Sub Main()
  ' Do something
  
  ' Then call another method
  Call MySubMethod
End Sub

Sub MySubMethod()
  Dim doc As Document
  doc = ThisApplication.ActiveDocument

  Call MsgBox(doc.DisplayName)
End Sub

One more thing which is not necessary but I think worth changing is moving from On Error Resume Next to Try/Catch. So instead of doing this:  

On Error Resume Next
Dim doc As PartDocument
doc = ThisApplication.ActiveDocument
If Err.Number = 0 Then
  Call MsgBox(doc.DisplayName)
Else
  Call MsgBox("No active part document")
End If
On Error Goto 0

... you would do this:

Dim doc As PartDocument
Try
  doc = ThisApplication.ActiveDocument
  Call MsgBox(doc.DisplayName)
Catch
  Call MsgBox("No active part document")
End Try