iLogic Forms - Native or .NET

To view my latest article please navigate to our new blog site:

iLogic Forms - Native or .NET

Format Your Code: Part II

In my last post, I brought up some guidelines and tips to help you (and others) to more easily understand your code.  In that previous post (click here in case you haven't read that one already), I discussed Collapsible Code Regions.  In this post, I'll discuss Indentation, Line Breaks, and Empty Spaces.

Indentation

Indentation can have a tremendous impact on how quickly you can look at code and understand what it’s doing.  Consider the differences between the two code blocks below:

While the color coding that iLogic gives you does help differentiate functions and conditional statements from other data, it’s much easier to review the code on the right and easily see where each case ends.  This is not only more appealing to the eye, it’s a time saver when looking at code, especially code that someone else wrote.  A couple of quick TABs is all that is needed or you can use the Increase Indent and Decrease Indent commands that are on the Rules Editor Editing toolbar.  Hint:  If you use the Editing toolbar, you can have your cursor anywhere in the line or you can select multiple lines and use the TAB key.

Line Breaks

Line Breaks are used when a single line will wrap past the right edge of the Rules Editor window and are another tool that is used to make your code easier to follow.  Line Breaks are created by a single space and then an underscore:  _.  Care should be taken to ensure the break is placed at a spot in the line that is easily understood.  The next line should be indented so that it’s easily recognized as a continuation of the preceding line.

Line breaks keep the reader from having to scroll to the right to read all of the code.

Empty spaces


Empty spaces are another easy way to organize your code.  They are simply a few carriage returns to put some empty space between blocks of code.  Empty spaces are a visual way of telling the reader “This bit of code has nothing to do with that last bit of code”.   It sounds simple and it is simple but it goes a long way to making your code easier to follow.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." ~ Brian W. Kernighan

Thanks,
Randy

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,

Format Your Code: Part I

Have you ever had to make changes to your iLogic code?  Or maybe you’ve had to review someone else’s code?  It can be a little overwhelming to open up an iLogic rule and find 500 lines that look like the image to the right…..

While there are no hard and fast rules about formatting code in the iLogic Rules Editor you’ll find that if you format your code following some basic guidelines and tips that you (and others) will be able to understand your code much easier, therefore saving time and money.

Over the next few blog posts I'll go over five different methods you can use to make your code more ‘user friendly’ in the iLogic Rules Editor.  Those five methods are Collapsible Code Regions, Indentation, Line Breaks, Empty Spaces and Commenting. 

Most of these methods are built in to programming environments such as the Visual Basic Integrated Development Environment.  Maybe some day we'll get them in the iLogic Rules Editor.

Collapsible Code Regions

Collapsible code regions allow you to group together bits of code which you can collapse and expand just as you do with features or components in the Inventor Model Browser.  This will help you and your reader navigate your code as well as clean up how it looks.

You define the beginning of a collapsible code region by inserting a single quote and a left square bracket: ‘[.  To define the end of the code region, insert a single quote followed by a right square bracket: ‘]. 

Notice the hierarchical outline tree that is to the left of the code.  You can also have nested collapsible code regions.

You can collapse and expand the code by clicking on the icon at the top of the region.  It will be a minus sign (-) if the code is expanded and a plus sign (+) if it’s collapsed.  A collapsed code region looks like this:

You can also collapse and expand the code by using the Outlining tools.  Place your mouse in the expanded code you wish to collapse, right click and choose Outlining > Toggle Outlining Expansion from the contextual menu.  This works the same as if you had clicked the (-) sign at the top of the code region.  The benefit here is that you don’t have to scroll the 200 lines to get to the top of the code region.  If this is done on collapsed code, it will expand.  Repeated use of the Outlining > Toggle Outlining Expansion will toggle back and forth between collapsed and expanded code.

Another wonderful Outlining tool that is right at your fingertip is the Toggle All Outlining option.  This will collapse and / or expand all collapsible code regions in the rule.  I recently had a rule what was approximately 5,000 lines and I would use the Toggle All Outlining and then expand just the section I wanted to work with.  I found it much easier than hiding a ‘here comment in my code and using the search command (I always seem to forget to delete those ‘here comments).

The other tools that are available on the Outlining fly-out are:

Stop Outlining:  This will expand all collapsed code regions and disable the ability to collapse code.  Once you’ve done this, you’ll then have a new option called Start Automatic Outlining

Collapse to Definitions:  In other programming, Collapse to Definitions will collapse your code down to the definitions in the procedure.  In iLogic, this function works the same as Toggle All Outlining.

You can also start and stop the outlining by using the button that is just above the vertical scroll bar.

"Good design adds value faster than it adds cost." ~ Thomas C. Gale

Thanks,

Randy

Debugging iLogic under Windows 10

A while ago I posted on debugging methods using SysInternals DebugView.  Well, this past week IT upgraded my machine from Windows 8.1 to 10 and with a few small exceptions things have been working well.

Until I went to begin debugging an iLogic rule and while DebugView launched fine and loaded my existing filters like a champ, it just sat there with a blank look on it's face.

I'd have sooner given up my right arm than agree to forego DebugView on the new platform.  I immediately reached out to a team member who I knew had been on Win10 for a while and uses DebugView daily.  "No problem here", he states...crap, the problem is local.  Or maybe not...


Like most when faced with a quandary of monumental proportion, I did a Google search and came up with the following post on Sysinternals forum:

Topic: DbgView and Windows 10

The first post almost broke my heart.  Not compatible with Windows 10?  Are you kidding me?

Fear not, keep reading...

About 2/3's down the page alanadams had an interesting comment about his experience with the problem. It seems that DebugView silently installs a .sys file in the ...\System32\Drivers folder.  Once there it seems that Windows keeps it from being written again because Windows says the driver is already running.

The solution?  Rename the original dbgv.sys file, then restart DebugView.  For some reason that seems to pacify Windows and lets DebugView run normally.  Who knew?

alanadams claimed, (at least for him), that this only fixes DebugView for that session and the step may need to be repeated, but for me at least DebugView continues to run even after several restarts including reboots.

I also run DebugView as Administrator just because I can, not necessarily because I need to.

So, hopefully you're like my fellow co-worker and DebugView works right out of the box, but if not you now have something to potential ease the pain.

Happy Coding,

Multi-Value List Controls

We often use multi-value parameters in our automation projects as they are a way to offer options for your end user to select from.  Usually you, as the developer, will want to limit these options to what’s available, either due to selections already made or other constraints.  In this post, we’ll describe how to control values for one option based upon another selection.

Have a look at the User Interface (UI) shown below for a conveyor design by Salt Automation.

When the end user selects a Duty Cycle of Heavy, the Motor Selection options should be 7-1/2 or 5 hp, as shown in the image.  But, what if the options need to change when the end user selects a Duty Cycle of Light, to either 2 or 1 hp?

Let’s take a look at how we can accomplish this.  We can set the value options for the Duty Cycle parameter in either the Parameters dialog box via traditional methods or we can set it via iLogic code, using MultiValue.SetList.

The scheme for the MultiValue.SetList is:

    MultiValue.SetList("parameter name", "value 1", "value 2", "value 3")

In our example, it would look like this:

    MultiValue.SetList("Duty_Cycle", "Heavy", "Light")

The benefits to setting the value options in code versus the traditional method are that you can set the order in which you want them displayed but more importantly, you modify the value options at run-time through your code.

Let’s look at how we can modify the value options of our Motor Selection parameter at run-time.  We’ll do this using the Case structure.  This could also be done with an If Then statement.

    Select Case Duty_Cycle

        Case "Heavy"

            MultiValue.SetList("Motor_Selection", "7.5 hp", "5 hp")

        Case "Light"

            MultiValue.SetList("Motor_Selection", "2 hp", "1 hp")

    End Select

The code above will set the Motor Selection options based up on the selection of the Duty Cycle parameter.

The entire code is listed below.  I am also setting the ValueOptions, which will be covered later.

' Set multi-value options

    MultiValue.SetValueOptions(True, DefaultIndex := 0)

    MultiValue.SetList("Duty_Cycle", "Heavy", "Light")

' Set Motor Selection based on Duty Cycle

    Select Case Duty_Cycle

        Case "Heavy"

            MultiValue.SetList("Motor_Selection", "7.5 hp", "5 hp")

        Case "Light"

            MultiValue.SetList("Motor_Selection", "2 hp", "1 hp")

    End Select

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” ~ Mosher’s Law of Software Engineering

Thanks,
Randy