Events Not Being Triggered

[Matthew_Policelli]

Has anyone else had this problem? I have been working on some new event triggered rules, but twice in the past two weeks I've had my event triggers stop working. The first time, it was On New Drawing Document, and this time it was On Drawing Document Close. The rules all work if I manually run them, and everything I'm seeing suggests that the actual event is not being triggered. Closing and reopening Inventor solves the problem.

Is there a possibility one of my other new rules is hanging up somewhere, preventing Inventor from listening for events until I close and reopen it? I would be surprised if this is the case, since Inventor isn't frozen and I can still interact with it, but I'm at a loss. If this might be the case, how would I find which rule (and where in the rule) the hangup is happening? I could put Logger statements at the beginning and end of each rule, but since this seems to happen very rarely, waiting for it to happen and then checking iLogics doesn't seem to be an optimal method.

Further thoughts:

One of the rules I am testing deletes legacy document-stored iLogic rules since we now run only external rules (for troubleshooting/improvement purposes). It runs in the Before Save event. If one of the deleted rules was also in the before save event (or after save perhaps), could it have been queued to run before being deleted, causing Inventor to look for the rule but not be able to find it and causing the issue?

[Frederick_Law]

I've found when IV when IV first started, event trigger are "off".

Need to go to event trigger page to turn it "on".

[WCrihfield]

Hi @Matthew_Policelli.  That certainly sounds like a complicated situation to figure out.  In the later half of your statements/questions you were interested in the timing of these rules.  When you put iLogic rules into the Event Triggers dialog, and there are multiple rules listed under a single event, they will basically be ran in the order that they are listed under that event.  The exception to that order may be if an earlier rule in the list causes other rules to run that are not listed there.  Another variable in that situation is if you have other rules listed under that event on other tabs within the Event Triggers dialog, such as 'All Documents', 'Parts', 'Assemblies', 'Drawings' tabs.  I believe that if those rules were under those events in the other tabs first, before you added the rules under that event on the 'This Document' tab, they would be ran first, but I do not have actual testing data to back that up yet, it would just make logical sense for it to be that way.

On another note, I have heard several testimonies from different people about events not triggering properly after using code to create or copy Event Triggers related settings within the documents.  That situation has been a problem for years, and was a tough one to figure out.  The code visually appears to create or copy the settings just fine, but the actual triggering was not working right.  We later found out from some folks at Autodesk what may have been the problem.  Have the Event Triggers settings been modified by code in your case, or has it all been done manually?

[Matthew_Policelli]

Can you expand more on what you mean by using code to create or copy Event Triggers related settings within documents?

As far as touching iLogics, here is my code that deletes internal Document iLogic rules:

	Sub Main()
		Dim iLogicAuto As IiLogicAutomation = iLogicVb.Automation

		'only need to run rule if there are iLogics saved to the document
		If iLogicAuto.Rules(ThisDoc.Document) Is Nothing Then Return

		'don't run on standard content center parts since these can't be edited the same way
		If (ThisDoc.Document.PropertySets.PropertySetExists("ContentCenter") AndAlso iProperties.Value("ContentCenter", "IsCustomPart") = "0") Then Return

		'replace the below code with this line if/when we decide to remove all event triggered rules from This Document events, including External Rules
		'iLogicAuto.DeleteAllRulesInDocument(ThisDoc.Document)

		'Delete Internal Document Rules
		If iLogicAuto.Rules(ThisDoc.Document).Cast(Of Autodesk.iLogic.Interfaces.iLogicRule).Count > 0 Then
			Logger.Info("Removing Document Level iLogic Rules for " & ThisDoc.FileName(True))
			Do While iLogicAuto.Rules(ThisDoc.Document) IsNot Nothing
				For Each oRule As Autodesk.iLogic.Interfaces.iLogicRule In iLogicAuto.Rules(ThisDoc.Document)
					iLogicAuto.DeleteRule(ThisDoc.Document, oRule.Name)
				Next
			Loop	'loop because it doesn't delete the first time
		End If


	End Sub

[WCrihfield]

When you open the Event Triggers dialog, there are usually 5 tabs along the top, which have to do with the scope of control.  The tab named "This Document" is usually always the 'active' one when you open it.  The settings on the right within that tab are stored in a hidden PropertySet within the document, and each rule you add under an event name is stored as a property within that hidden set.  The name of the property and its PropID are very specific to a set pattern having to do with the type of event, and the property's value is the name of the rule.  The settings in all the other tabs within the Event Triggers effect multiple documents, so those settings are stored externally in a single XML file.  Some users found out about this back around 2013, and we have been messing around with those settings by code since then.  But there has always been some seemingly unexplained failures in the process at times.  The only way to find that hidden property set, if it exists (because it does not exist yet in 'New' documents), is by its exact name, not by looping through all PropertySets.  If it exists, we can explore it, edit it, or delete it.  If it does not exist yet, we can create it, then edit it.  But in situations where it did not already exist in the document, and you simply create that PropertySet, then edit it in an attempt to add some triggering functionality, sometimes it will seem to be created and edited just fine, but the actual triggering action will not be working correctly afterwards.  This is usually because certain details were not taken into consideration during that code process, and it may require either certain manual steps afterwards, or completely redoing it to fix it.

But it does not sound like you have done this process to any of your files, so that should not be an issue in your situation.

[Matthew_Policelli]

I previously had an extra part to the rule I shared above that would add some iLogics to the This Document triggers. At that time I was running the rule manually on certain files.

However I removed this from my code because I realized I could attempt to do everything our This Document rules were doing from all "global" triggers, so they'd all be stored in the XML rather than the Document file.

I never noticed any problems with the previous function of the code though, but is it possible that on a document where I ran that code previously (even several months ago), problems with event triggers could creep up when editing those documents? Or, even if there was a problem, would it only effect the This Document triggers and not the "All Drawings" triggers?

[WCrihfield]

Based on what I've seen, and what others have discussed with me (and others here on the forums), the problems with rules not being triggered to run after editing the local Event Triggers settings by code, were in situations where the document did not previously have any iLogic rules or iLogic Forms in it, and did not already have anything in its Event Triggers, then they created the PropertySet within the document, and either created or copied Event Triggers properties within it.  I do not believe the problem happens if there were already rules in the document, and already a PropertySet for the local Event Triggers settings.  And since we have not really discussed editing the external XML for the global Event Triggers settings, I have no idea if any of this could effect that, but I highly doubt it.  And in most cases, the user was able to manually delete the rule from the This Document tab of the Event Triggers dialog, then add it back manually, and that seemed to fix the problem with the triggering.

I have seen many posts were folks simply delete the existing PropertySet, then create a new one, then either create or copy Properties into it for triggering rules to run.  But that is not really a good practice in many situations.  Not only does that delete all settings that were within it, but when creating the new set, this problem might occur.  It is better to leave the original PropertySet in place, and use a more careful approach to creating or copying new properties into the set, or editing existing ones, instead of deleting and recreating them.

I believe the main thing to pay attention to when creating the PropertySet within the Document, is that the document must have a DocumentInterest for the iLogic ApplicationAddIn before, and during the process.  A DocumentInterest mainly just indicates that the document is being effected by / or is somehow controlled by a specific Inventor ApplicationAddIn.  And simply creating a DocumentInterest from scratch with the correct ClassIdString in it, does not seem to be the best way either, because it will only stay there very temporarily.  The best way to ensure that the document has the needed DocumentInterest for the iLogic ApplicationAddIn is to simply add an internal iLogic rule to the document.  It can be a simple, empty rule, for temporary purposes, and can be deleted later on.

If you have some existing files that seem to be having problems with their triggering, based on the This Document tab of the Event Triggers, and you believe they were created by code, you might consider taking a screenshot of what rules are under what events, then delete the PropertySet for those settings, then recreate those settings manually, through the dialog.  And to help avoid more problems in the future, I believe you can actually prepare your template documents ahead of time, so that when you use the New command to generate new documents, they will not have these types of problems.  I did not experience these problems myself, because of my templates, but when someone else sent me a template file to try, (or I used an untouched original template from the installation files), I was then able to experience the same problems they were having.