Using VB based forms in iLogic Trick

I was recently building a form in VB.NET using Visual Studio Express and was faced with the task of wiring it up to Inventor.

In case you've never done it before, you need to use an iLogic rule to pass current parameters to the form class then back again.  This is typically done as follows:

' add a reference to the DLL hosting the form
AddReference "myAutomation"

' make the connection to the form

Using dlg As New myAutomation.MainForm


' shows the dialog
Dim i As Integer = dlg.ShowDialog()

' pass parameter info to matching variables in the form code

dlg.PreOrder_Initials = iProperties.Value("Custom", "PreOrder_Initials")
dlg.Shop_Order_Number = iProperties.Value("Custom", "Shop_Order_Number")

dlg.Customer_Stock_Number = iProperties.Value("Custom", "Customer_Stock_Number")

When the form closes you need to reverse the process and pass the data from the form back to Inventor, so those three sample lines become:

iProperties.Value("Custom", "PreOrder_Initials") = dlg.PreOrder_Initials
iProperties.Value("Custom", "Shop_Order_Number") = dlg.Shop_Order_Number

iProperties.Value("Custom", "Customer_Stock_Number") = dlg.Customer_Stock_Number

Seems simple right?  And, it is, unless you've got a complex form and 300+ parameters to hand back and forth.

Those that follow this blog know that I"m a huge fan of Notepad++ for creating/editing external iLogic rules.

Using a free add-in for Notepad++, called FingerText to create some shortcuts that allowed me to quickly create my initial entries for pushing values to the form.  But, now I was faced with essentially mirroring the string about the "=" sign.  To me that represented a ton of selecting, copying, replacing, etc. and I could tell that somewhere along the line I would get distracted or fat finger an entry then have to track down the bug.

My saving grace was learning that I could use Notepad++ to do the switching for me.  Here's the process I used:

1. Copy all the dlg.xxx lines and pasted them into the same document after the .ShowDialog() line.  These would become the code that would pass the form values back to Inventor.
2. I used the Notepad++ Replace function to find and mirror the text for me using a regular expression.

In the Find what: cell, enter:   ^(.*)=(.*)$

In the Replace with: cell, enter: \2 =\1

Set the search mode to Regular expression

After that it's a simple matter of Find Next and Replace.  I caution not to use Replace All as it will also mirror your originals.

dlg.UID = iProperties.Value("Custom", "UID") becomes

   iProperties.Value("Custom", "UID") = dlg.UID at the click of a button.  It doesn't get much simpler than that!

I hope that you find this little trick useful.

Happy Coding,

2015 Purge Unused Parameters & iLogic Rules

With the release of Inventor 2015, we finally have an easy built-in way of purging unused parameters in both assemblies and parts.  In the Parameters dialog box is the new Purge Unused command:

Warning

This command checks to see if a parameter is used in a feature.  It does not check to see if the parameter is only being used in an iLogic rule.

Hopefully this will save you from an OOPS.

Randy

"There are only two mistakes one can make along the road to truth; not going all the way, and not starting." - Buddha

Placeholders on iLogic Forms

I recently had a case where a colleague was setting a custom iProperty (Program Number) to either the file name or a custom field and he was using a boolean parameter to determine which of these to use to set it.

Here is his original code:

'********************************************************
'Set Program Name

If Set_Prog_Name = True Then
    iProperties.Value("Custom", "Program Number") = ThisDoc.FileName(False) 'without extension
Else
    iProperties.Value("Custom", "Program Number") = ""
End If

'********************************************************

We can see from the original code that when Set_Prog_Name = False that the Program Number will be set to <blank>.  He needed a way to allow the end user to enter a value in the Program Number field.

My immediate response wast to set up an input box but he preferred to not have an additional dialog box.

The end solution was one to add a placeholder iProperty, which I called Program_Name_Temp, on the form in place of the original Program Number and set the value of the Program Name iProperty equal to the placeholder when Set_Prog_Name = False.  As an additional bonus, I added a controlling parameter for Program_Name_Temp which is called Set_Prog_Name_Controls.

'********************************************************
'Set Program Name

If Set_Prog_Name = True Then
    Set_Prog_Name_Controls = False
    iProperties.Value("Custom", "UserInfo2") = ThisDoc.FileName(False) 'without extension
    Program_Name_Temp = iProperties.Value("Custom", "Program Name")
Else
    Set_Prog_Name_Controls = True
    iProperties.Value("Custom", "Program Name") = Program_Name_Temp
End If

'********************************************************

I hope this helps you on a future or current project.

Randy

"Even if you're on the right track, you'll get run over if you just sit there ." - Will Rogers

Searching Excel with iLogic

This is an interesting iLogic solution to a problem where part inventories may dictate the values of a component in an assembly.
Perhaps the inventory changes somehow on a regular enough basis and modifying the actual code would not be practical; or the person who determines the value of that database is not an Inventor user.

This particular client had an ever expanding list of customers with varying requirements for the end product including machining tolerances, available fastener specifications and approved material lists to name a few.

As new customers were added it seemed to be a constant struggle to add the new values into the iLogic code and, believe it or not, sometimes the existing customers would change their mind - almost NEVER happens right? ;-)

Controlling Parameter and iProperty Values

We can use iLogic to help us enforce standards and other values I like to refer to as “tribal knowledge”. Having customized code trap errors in design to help prevent (or at least flag) those “freelance” design changes is a powerful and effective way of managing the expense of change at the earliest stages of the process and turning your 3D models into true knowledge assets.


In this example we have established the proper number of ribs needed for this model based on the material of the part and are enforcing them with a rule. We are also enforcing the overall size limits of the model so that the Length must be between 4” and 10” and the Width must fall between 2” and 3”. We’ll also have a rule that will enforce the increment value of Length and Width.