Automate event trigger edit

[JohnKHouston]

Hello!

I'm writing to ask for some help to correct a problem we have in our existing .idw files. When I initially set up our drawing template I found an iLogic code to create the Total Weight of all the parts in an assembly. This iLogic code parsed the unit string and allowed me to round the value to a reasonable length.

Unfortunately I wasn't very aware of the Event Triggers and the effect it had on the drawing files. I added the trigger both before, and after the Save function. This creates a problem because the file wants to be saved again, because I've modified the file after the save.

In order to correct the error, I simply need to move the TotalWT from the 'After Open Document' to 'Before Save Document' and then remove the TotalWT from 'After Save Document'.

I've been doing this edit manually but we have thousands of drawings that need this edit. Is there some way for me to use some sort of process to update all of the drawings that need the edit? I'm hoping that perhaps there's some way to use the job processor to help with this process. I'm thinking maybe iLogic code could do this, but I'm only guessing (hoping).

I've attached a couple of screen shots which shows the Even Triggers, before and after the edits.

Any suggestions would be greatly appreciated!

Best regards,

John

[WCrihfield]

Hi @JohnKHouston.  The good news is that I do believe this is possible to accomplish.  We have been able to access those settings shown within the Event Trigger dialog using iLogic for several years now, but it's not the simplest task.  There are two different places these type of settings are kept.  The settings on the other tabs of the Event Triggers dialog (All Documents, Parts, Assemblies, Drawings) are stored in an external XML file.  But the settings in the 'This Document' tab are stored within that Inventor document itself, as a hidden iProperty set.  This hidden set can only be found/accessed by specifying either its its very specific internal name or its display name, not by looping through the regular iProperty sets.

We would probably create one external iLogic rule to do the core task of handling the single 'active' or assigned document at a time, and changing those settings within it.  Then devise a separate plan for making that rule run on a batch of files at a time.  This batch processing can likely be done in multiple ways.  There are ways to have one iLogic rule that will loop through all Inventor documents of a specified type within a specified directory, and run a process on each one that matches certain criteria.  The process here would be the other external rule.  This type of process using iLogic rules though will likely bog down Inventor while its running.  There are other more advanced ways, such as maybe creating a standalone .exe file or Add-in, that might reduce the impact of processing a bit, but they will still most likely have to 'use' Inventor one way or another, and are far more complex to create.

There are a few resources available here on this forum related to this topic, but not many.  Here are links to 3 of my contribution posts related to accessing the Event Triggers settings, but none of them are designed for the task here.

How To: "Unhide" the "Hidden" Event Triggers iProperties PropertySet using an iLogic rule 

Add an iLogic Rule to an Event Trigger Using an External iLogic Rule 

Copy All iLogic Rules & Event Triggers From One Document To Another Using An External iLogic Rule 

There are other posts too that you could likely find by searching this forum, if you're interested in learning more.  It would take some time to develop a custom solution for this specific task, but it's not too huge of a task.

[JohnKHouston]

Hi Wesley,

Hope you don't mind if I call you by your first name. I saw it in the post you linked. 🙂

I did take a minute to quickly scan the links and it seems that there is a path to completing the task I'm looking to do. But, like you suggested, it will take some time for me to digest what you've written.

It's probably way above my ability to create the custom rules but I'll review what you've suggested and see if I can manage to create something.

Thank you for the suggestion and the links to the articles. I'm glad that there's a way to fix this problem I created. I really wish that I knew then what I know now!  😉

John

[b.mccarthy]

@WCrihfield 

I am interested in looking at the information referenced at the end of your post, however, the links appear to be broken. I tried with different browsers, but still receive an error:

An error occurred while processing your request.

Reference #97.4e94d817.1684707718.64a22fc6

Can you update the links, or post the code here?

Thank you.

[WCrihfield]

Hi @b.mccarthy.  Those resources, as well as everyone else's personally authored articles within the Autodesk Knowledge Base, got removed back in early March of 2023, supposedly to make room for other Autodesk online community related projects.  And since I chose not to host an online blog site, I just saved some (not all) of my articles to local Microsoft Word & PDF documents.  Now I just attach them to forum responses as needed here and there.  Unfortunately, there is no way for me to recall every place I had posted the links to those resources to go back and replace them with actual attachments.

I will attach a copy of the locally stored resources I have here now though.  I do not believe I kept a copy of the article about 'unhiding' the PropertySet though, because it simply was not that useful.  We simply do not need to unhide it to be able to work with it, as long as you know its Name &/or its InternalName.  And in order to do so, you need to delete it, then recreate it, because its name is ReadOnly.  The article did show a way to preserve its contents in order to write them back in after it gets recreated though.

And the article showing how to add a rule to an event trigger was pretty informational, but the 'initialization' step code was still not 100% fool proof to work good in every scenario yet.  I later found out through multiple other forum articles, where others were using those codes and experiencing troubles with the rule(s) were listed in the event triggers correctly, but the actual triggering of those rules was not always working correctly yet, and it seemed somewhat random as to why/when it was not working.  I later found out from some very knowledgeable folks at Autodesk that there may need to be a 'DocumentInterest' present in that document for the iLogic ApplicationAddin, before edits to the event triggers by code will work correctly.  And although there is a normal way to add one using Inventor API code, it will automatically go away when the document gets updated, if there is no normal reason for it to be there.  So, the next simplest way to cause one to be included (and stay there) is to add an empty, temporary internal iLogic rule to the document.  This is part of the reason why this behavior seemed so erratic, sometimes folks already had some internal iLogic rules in their document, and sometimes they did not, and we never thought about this little detail as being a cause of any problems.  Once that was figured out, and a plan was is in place, as far as I could tell the erratic functionality went away, and it seemed to be more stable across the board.

[WCrihfield]

I have several rules related to the Event Triggers, but a couple of the newer ones not included in those articles have to do with what I used to call 'initialization' or the needed iLogic DocumentInterest.  These are just a couple fairly simple little separate custom routines.  The first one can be used early in the overall process, to make sure the needed resource is in place, with a Boolean feedback.  The second one is just a optional cleanup step, if the first one was used, and returned True (True indicated that a temporary, empty iLogic rule was added to the document).

Here is the first routine.  Keep in mind that these are not a standalone iLogic rules, but supplemental routines that your main iLogic routine can call to run when it is included in the rule somewhere after the Sub Main...End Sub.

Function AddTempEmptyRule(oDoc As Document, Optional sRuleName As String = vbNullString) As Boolean
	If IsNothing(oDoc) Then Return False
	Dim iLogicClassID As String = "{3BDD8D79-2179-4B11-8A5A-257B1C0263AC}"
	If oDoc.DocumentInterests.HasInterest(iLogicClassID) Then Return False
	If String.IsNullOrEmpty(sRuleName) Then sRuleName = "Delete Me"
	Dim oRule As iLogicRule = iLogicVb.Automation.AddRule(oDoc, sRuleName, "")
	oDoc.Update : Return True 'True = a rule was added to the document
End Sub

... and

Sub DeleteTempEmptyRule(oDoc As Document, Optional sRuleName As String = vbNullString)
	If IsNothing(oDoc) Then Exit Sub
	Dim oAuto As IiLogicAutomation = iLogicVb.Automation
	Dim oRules = oAuto.Rules(oDoc)
	If IsNothing(oRules) Then Exit Sub
	If String.IsNullOrEmpty(sRuleName) Then
		For Each oRule As iLogicRule In oRules
			If oRule.Text = "" Then oAuto.DeleteRule(oDoc, oRule.Name)
		Next
	Else 'rule name was supplied
		Dim oRule As iLogicRule = oAuto.GetRule(oDoc, sRuleName)
		If oRule IsNot Nothing Then oAuto.DeleteRule(oDoc, sRuleName)
	End If
	oDoc.Update
End Sub

When you call the first one to run, you can capture its returned Boolean value to a variable.  If it returned False, then no internal iLogic rule was added to the document, and you will not need to call the second routine to run.  If the first routine returned True, then an empty iLogic rule was added to the document, and the second routine could then be called to run somewhere near the end of the rule, after you have done what you need to do with the Event Triggers, and it will attempt to delete that empty rule.  It would not really hurt anything to leave that empty rule in there though.

[b.mccarthy]

Thank you for the files and your thorough explanation. 

At this point, I am writing 2 simple drawing rules. One deletes all events, and the other will insert specific events.

Hopefully, I can use what you have provided to get me there.

Many thanks!

[WCrihfield]

If all you want to do with one rule is delete any existing event triggers in a document, then something very simple like this should work.

Dim oSet As PropertySet
If ThisDoc.Document.PropertySets.PropertySetExists("{2C540830-0723-455E-A8E2-891722EB4C3E}", oSet) Then
	oSet.Delete
End If

That will simply try to find that PropertySet by its InternalName, and if found, will try to delete it.  That will instantly wipe out any settings in the Event Triggers in the 'This Document' tab for that document.  It will not change any of the settings in any other tab of the Event Triggers though, because those are stored in an external XML file.

Edit:  Of course you may also want to include a document update and/or Document.Save to save those edits.