Honestly, I took the time to change the code up as a method to teach some coding.
1: Using select case statement instead of a bunch of if statements.
2: Calling a function vs a sub, functions return values sub's don't. So if you don't plan on returning anything, just make it a sub.
3: Combining like processes, this you already get, but squeeze more commonality (normalizing) make for easier to read code (most of the time).
4: Classes vs Modules. Technically this is beyond the scope of iLogic and more into VB.Net's realm. But when you were defining variables without definitions, and scattering them all over the place, and passing them around back and forth, you tend to loose sight of the 'scope' of that variable. In a class, you can define variables up top (and in a module, but not an iLogic module for some reason), then reuse them without redefining or passing them all over the code structure. But Classes have to be instantiated (hence the oClass = new Class) in order to be created when using. Think of a class as a custom tool bucket that holds precisely the tools you want (form fitting foam snap in tool buckets). When you want to use it, you must first put the tools into it.
5: Defining variables, define them when they are being created, even if you don't have too (modern code editors and put up with it), because that helps you to find and read the variable's scope. Scope is important, because it could be for the entire rule, just the method, or several times in the method. If you place a new variable of the same name and the editor lets you, think to yourself, is it creating a new data bucket, or tying into the other one with the same name. This creates problems where you think your editing a value, and your actually editing a different value, or you think your editing a different value and your actually overwriting a common value. Scope is important. Cleaning that up will keep you from getting confused.
6: Indentation. Clean code makes for fast reading code. For me to take the time to read your long bits of code is very rare on here, you just got lucky today. For better help, make clean indentation, 'tight' separation, and notes...
7. Notes, if you type ''' by the third ' the iLogic editor will create the standard xml notation header for you properties and methods. These allow you to hover over the name of the method elsewhere and read your notes describing the method and what it does. You can also just put simple comments to separate logical sections of code (this you already know). I like to 'comment my notes like an outline then write the code between the comments.
8: New ideas vs old. When you come up with a new idea, that makes an old one obsolete, rem out the code, until you prove out the new idea, then DELETE the old code to clean up your text. Makes for faster reading.
I regret I couldn't use the Logging.Info method inside of the class (still figuring that one out), but if you create a class free rule, then you can use Logging.Info, and open the iLogic Log window (see the + button next to the model window). This allows you to dump values into a text pane while the code is running. Old school is the 1 million message box method. I had to test to see if the value expected was the value being gotten.
Inventor clearly knew what the value expected was. The issue was getting the BOM of the part definition (of the occurrence) and not the assembly's component occurrence (of the part).
Jamie Johnson : Owner / Sisu Lissom, LLC https://sisulissom.com/
