Adding VB External Rule Dependencies to VB External Rules

[Anonymous]

I am currently trying to produce a number of modules as iLogic External Rules with Straight VB Code enabled. My hope is that each module will host a series of functions that can be called from a iLogic rule without instantiating a object of a class. Each of these modules may use functions from a separate module as part of a functions code. Right now I can get the iLogic code able to reach one deep, but it runs into a issue trying to access a function from that module to another module. The test code looks like this:

Main iLogic Code:

AddVbFile "FunctionTools\foo.vb"

Sub Main()
	Dim oDoc = ThisDoc.Document
	foofunc(oDoc)
End Sub

The First Level External VB Module:

Imports System
Imports System.Math
Imports System.Collections
Imports System.Windows.Forms
Imports Microsoft.VisualBasic
Imports Autodesk.iLogic.Interfaces
Imports Autodesk.iLogic.Runtime
Imports Inventor

AddVbRule "FunctionTools\bar.vb"

Module foo
	Public Function foofunc(oDoc As Document)
		MsgBox("FOO" & oDoc.FullFileName)
		barfunc(oDoc)
	End Function
End Module

The Second Level External VB Module:

Imports System
Imports System.Math
Imports System.Collections
Imports System.Windows.Forms
Imports Microsoft.VisualBasic
Imports Autodesk.iLogic.Interfaces
Imports Autodesk.iLogic.Runtime
Imports Inventor

Module bar
    Public Function barfunc(oDoc As Document)
        MsgBox(oDoc.FullFileName)
    End Function
End Module 

I am hitting "Error on Line 12 : Declaration expected." on the AddVbRule line which either implies that the syntax is incorrect for how you call other rules in Straight VB, or this kind of chained call is not allowed. I have tried using Imports and AddVbFile to no success.

[WCrihfield]

Try this, just as a proof of concept.

Create an external iLogic rule called GetFullFileName (the actual name is not important other than you have to remember & use it when referencing it in other rules.

Within the iLogic Rule Editor for that Rule, copy & paste the following:

Class ThisRule
	Public Function GetFullFileName(ByRef oDoc As Inventor.Document) As String
		If oDoc IsNot Nothing Then
			GetFullFileName = oDoc.FullFileName
		End If
	End Function
End Class

No extra 'Header' statements should be needed in the rule above, to be able to use this example.

Now save and close that rule, without running it.

Now create another external iLogic rule and paste the following in it:

In the Header Area:

AddVbFile "S:\Engineering\SHARED\External iLogic\REF FUNCTIONS\GetFullFileName.txt"

The example above is obviously custom to my machine, and needs to be changed to suit your situation, but I'm basically telling it to reference & use the specific other external iLogic rule.  I have all my external iLogic rules using the .txt extension, for simple & easy editing with Notepad, outside of Inventor, when needed.  (extension doesn't matter, as long as it matches your file)

In the main rule body paste this:

Sub Main()
	Dim oDoc As Inventor.Document = ThisApplication.ActiveDocument
	MsgBox(GetFullFileName(oDoc), vbOKOnly, " ")
End Sub

Then save and run it.

It should show a simple message box showing the FullFileName of the currently active Inventor document.

You'll notice that this has to be getting that info from the other referenced rule, to work.

[WCrihfield]

Another sometimes highly useful, yet similar way of using another external rule to add functionality to your current rule, is to pass one or more variables to the other rule, then get other variables back from it, using NameValueMap, and RuleArguments.  They are also discussed within one of the links from the last post.

Below is a very basic example of one rule running a second rule and passing a name-value pair to it, that second rule doing something with that data, then returning data to the first rule.

Rule 1:

'Create a NameValueMap
Dim oMap As NameValueMap = ThisApplication.TransientObjects.CreateNameValueMap
'Add a Name / Value pair into it.
oMap.Add("TestName", "TestValue")
'Run your second rule here.
iLogicVb.RunExternalRule("NameValueMap Recieve & Send Test", oMap)
'This is where you get the other Value back from the second rule.
MsgBox("First Rule - Value returned from second rule = " & oMap.Value("Return"))

Rule 2:

'Retrieve NameValue Pair from calling rule
'Arguments is a NameValueMap
Dim oRecivedValue As String = RuleArguments.Arguments.Value("TestName")
'This next line is just prooving that this rule recieved what you sent to it.
'You can delete it when you've learned the trick.
'MsgBox("Second Rule - Recieved Pair Value = " & oRecivedValue)
'Do something with the oRecieved Value

'Now establish the value you want to send back to the Calling Rule.
Dim oValueToSendBack As String = "It Worked!"
'Return a new Value to the Calling Rule
RuleArguments.Arguments.Value("Return") = oValueToSendBack

[Anonymous]

I attempted you top solution but hit similar errors:

Error on Line 5 : 'GetFullFileName' is not declared. It may be inaccessible due to its protection level.
Error on Line 3 : Declaration expected.

My code looked like the following:

Top Level iLogic

AddVbFile "FunctionTools\foo.vb"

Sub Main()
	Dim oDoc As Inventor.Document = ThisApplication.ActiveDocument
	MsgBox(GetFullFileName(oDoc), vbOKOnly, " ")
End Sub

foo.vb

AddVbFile "FunctionTools\bar.vb"

Module foo
End Module

bar.vb

Class ThisRule
	Public Function GetFullFileName(ByRef oDoc As Inventor.Document) As String
		If oDoc IsNot Nothing Then
			GetFullFileName = oDoc.FullFileName
		End If
	End Function
End Class

 It doesn't appear to be a issue of the file path as I can directly run foo.vb fine with my previous code. In this case even if I directly reference bar.vb from my ilogic level I hit the same errors. I am unsure how I would be able to directly access the GetFullFileName method without the creation of the class (unless ThisRule by nature has special properties).

[WCrihfield]

ThisRule is a pre-defined Class within Inventor's iLogic, so yes it may have special properteis.

See the Additional Statements section of the following link.

Advanced iLogic Techniques Reference 

And here is a link to one of Luke Davenports posts on Cadlinecommunity which mentions the use of ThisRule.

I haven't tried the second layer deep reference, as you seem to be trying to do, but the example I posted above worked for me.  (using Inventor Pro 2021 & Win 10 Enterprise)

Did you mark both of the reference rules as "Straignt VB code" in their options tab?

Which version of Inventor are you using?  (Not really sure if it matters, but this functionality may have not always been available in previous versions.)

[WCrihfield]

Here are a couple of screen shots showing my 'options' settings and variable recognition within both of my example rules.

Here's the first rule.  Only Silent operation & Fire dependent rules immediately are turned on.

And you can see that when I hover my mouse over the Function name, it recognizes it.

Here is the second rule.  I have Silent operation, Fire dependent rules immediately, and "Straight VB code" enabled.

And you can see that when I hover my mouse over GetFullFileName (within the If statement), it is recognized.

And here is another shot of the second rule, where I'm hovering my mouse over "FullFileName" (after oDoc.), and it is recognized.

[Anonymous]

It is possible that what is making that function for you might be the Inventor difference, my company currently has everyone still on 2017 with maybe a update to 2018 coming this year. As such I do not have access to highlighting or the separate header section. I am also on Windows 10 Pro.

[DonStauffer99]

Now create a third rule and reference the second one the same way. It doesn't work. That was what the original post asked about.

The answer is, this is a bug and I'm not aware of a workaround.

[WCrihfield]

Back when I posted those earlier replies, I think I had only been using 1 or 2 of those external rules with the Straight VB Code option, as externally referenced resources, and they did not have a lot in them yet, and I still wasn't really using them that often yet.  I was likely most often using the 'send & receive' technique to turn other regular external rules into similarly used Subs or Functions with 'input parameters' and 'return values' at that time, which was working OK for me at the time.  Now I have a whole list more of those externally referenced rules with that option turned on.  Some containing one or more custom Classes, while others contain custom Modules, some with 'extensions', others for utilities and helper methods and such, with lots of contents in them.  Some that started out as custom Classes I later turned into Modules, to avoid the instantiation and disposal steps, where appropriate.

And yes, as far as I know, we still can not reference other external iLogic rules using the 'AddVBFile' line from within the header of another external rule that is marked for 'Straight VB Code', so we still can not 'daisy-chain' them together as the original poster was suggesting.  But I have never needed to do so either.  The 'regular' rule that is referencing the special external rule(s) can also include multiple AddVBFile lines in its header for referencing multiple of those special external rules with the Straight VB Code option on, and I doubt there is a limit to how many one rule can be referencing, as long as there are no conflicts between them.  I do not know if our inability to daisy chain them together is a 'bug' though.  In fact, it actually makes some sense, because I believe the 'AddVbFile' line is unique to iLogic, therefore is not necessarily recognized as 'straight VB code', plus, it has not been put together as a true DLL, so...  It may just be a simple limitation, maybe of the VB.NET Framework system which is used in iLogic rules, but I do not know for sure either way.

There was another discussion on this forum about our ability to use the 'AddReference' lines in the header of those special external rules with the Straight VB Code option turned on.  The 'Imports' lines always worked just fine, but not the 'AddReference' lines.  I got past the required 'order' of those types of lines in the header relatively early, but kept getting errors because of them, when that rule would get referenced from another 'regular' rule that was trying to use it.  So, I started including the 'AddReference' line into the Header of the regular rule that was referencing the special external rule, and that seemed to work just fine...but was obviously not ideal. It seems like some others were able to use those lines OK from within those types of rules, but were maybe using it in a different way where they included lots of other stuff in that line of code besides just the quoted file name of the external DLL file.  My guess is that the rule, or at least that line of code in the header of the rule, was created/generated through the use of Visual Studio or something like that, which added all that extra stuff into it automatically.

For example, the following is shown in the online help page for adding a reference to the 'Global Assembly Cache' using a 'qualified name'.

AddReference "VsWebSite.Interop, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”

I am simply not familiar enough with that specific detail yet, to know where to pull all that odd looking information from, so that I could type or copy/paste it into the header of an iLogic rule.  Sure, I sometimes see stuff like that within error messages, and I have seen lists of references being used by some of my more complex rules that are being included automatically (in the background), where we could potentially copy it from, but knowing exactly what all of that means, and if it is 100% correct for my situation is another thing altogether.  This is yet another 'grey' area that they simply do not offer enough official documentation about yet.