iLogic Triggers running up the chain

iLogic Triggers running up the chain

c_bouw
Explorer Explorer
284 Views
2 Replies
Message 1 of 3

iLogic Triggers running up the chain

c_bouw
Explorer
Explorer

I have some iLogic rules set up that I want to run in parts and/or assemblies only, but only when triggered specifically by that part or assembly. One that I have set up that is only relevant to parts, for example, will try and run when I save the drawing for that part, and pop up an error window. Or another that should run for either assembly or part environments, but when I open the assembly, it will try to run it in EVERY part, which in this case is not possible or relevant. (It's a quick tool to autozoom and set to Home view upon opening)

 

I have tried various tricks such as ThisDoc and ActiveDocument, etc, with no luck.

 

'If ThisApplication.ActiveDocumentType() <> kPartDocumentObject
Dim activeDocName As String = ThisApplication.ActiveDocument.FullFileName
Dim thisDocName As String = ThisDoc.Document.FullFileName

If (activeDocName <> thisDocName) Or ThisApplication.ActiveDocumentType() <> kPartDocumentObject Then
	Exit Sub
End If

 Here's one such example of one that should only run in the part environment yet tries to run from the drawing. It's for automatically applying specific colors to toleranced holes. Am I wording this section improperly? How can I prevent the active file from triggering external rules in associated documents?

 

For reference, most of my triggers are before save or after open.

0 Likes
Accepted solutions (1)
285 Views
2 Replies
Replies (2)
Message 2 of 3

WCrihfield
Mentor
Mentor
Accepted solution

Hi @c_bouw.  When using the Event Triggers dialog to automate stuff, we have less control over the specifics than when we automate stuff using the object Events themselves, with our own custom event handling codes, but custom event handler codes are generally best suited for use in Inventor add-ins, not regular iLogic rules.  When we open an assembly or drawing, that also opens all of the documents being referenced by the assembly or drawing, and when we save an assembly, it sometimes also saves some of its referenced documents at the same time.  In situations like this, I almost always instruct folks to use the 'ThisDoc.Document' iLogic phrase in their iLogic rules to refer to the document that the rule is to focus on, instead of ThisApplication.ActiveDocument, because ThisApplication.ActiveDocument will always refer to whichever documents happens to be currently visible on your screen at the time, which causes a lot of folks, over lots of years, lots of troubles, like in this case.  The 'ThisDoc' iLogic term is pretty dynamic, and refers to different documents in different situations, but there is next to no accurate official documentation explaining exactly how it will work in all those different situations, so I have had to conduct my own testing and research about its functionality over the years.

 

When used in an internal iLogic rule (the rule is saved within an Inventor document, not external), it will default to representing the document that the rule is saved within.  If used in an external iLogic rule, then it will default to representing the document that was 'active' (visibly showing on your screen) when the rule was first started.  If the rule was triggered to run by an Event Trigger, it will represent the document that the Event happened in.  If the rule was ran by calling it to run from another rule, using something like 'iLogicVb.Automation.RunExternalRule(oDocForRuleToTarget, "ExternalRuleName")', then it will represent the document that oDocForRuleToTarget variable represents.  And so on.  If any of the rules involved in any of these situations used the phrase 'ThisApplication.ActiveDocumet' anywhere within their code, thinking that they are referring to the document that the rule is to take actions on, then they most likely will not work correctly, and those references will likely need to be changed to using 'ThisDoc.Document' to make them work right, if they may be called to run remotely by things like Event Triggers, or codes like RunRule, or other similar situations.

 

If you rule is for zooming and positioning a model on the screen, and it is possible that this document may not be the 'active' document, then you could use something like the following:

Dim oDoc As Document = ThisDoc.Document
If oDoc IsNot ThisApplication.ActiveDocument Then Return
If (Not TypeOf oDoc Is PartDocument) And (Not TypeOf oDoc Is AssemblyDocument) Then Return
'at this point, we know that this document is the 'active' one, and is a Part or Assembly
'now use the oDoc variable as your reference to this document, for any further code

If this solved your problem, or answered your question, please click ACCEPT SOLUTION .
Or, if this helped you, please click (LIKE or KUDOS) 👍.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
Message 3 of 3

c_bouw
Explorer
Explorer

Thank you for your explanation. As you stated, the specific funcitons/caveats of each statement is not well documented, and I was just trying to replicate examples I could find which performed other functions. Without knowing exactly what each is doing, my results were not, you could say, optimal.  😅 I put your example lines in some of my problem rules, and so far so good. In my case, all rules need to be run external, not embedded in individual documents, so I need to be able to make them "applied to all, applicable to some".

0 Likes