Trigger event after document get modify.

[sneha.sadaphal]

Hi,

I want to trigger the event after document modification (like feature modification/ add new feature/ change iproperties from tab)

I see there are lots of events for each modification, like below

OnFeatureChange

OnparameterChange

OnNewEditObject

OnNewFeature

OnNewParameter

OnDelete

But i am not able to find out any event for properties changed from Iproperties tab.
Do we have only one event to check this in Inventor 2024/2023?

[Frederick_Law]

Not everything has an event.

iProperties is in model and drawing.

You might need to check DocumentEvents.OnChange and see what was changed.

What are you trying to do?  iProperties usually is changed by user.  Unless you have program to change it.

[sneha_sadaphalW6XLM]

I wanted to check through API whether document is modified in any case.

[WCrihfield]

Hi @sneha_sadaphalW6XLM.  I am not sure why you want to monitor for all possible changes to a document, but as you have already found out, there are a whole lot of ways to change a document, and several different events for some of those different types of changes.  And @Frederick_Law already mentioned the 'main' one (DocumentEvents.OnChange) that comes to mind, which there is sort of two different versions of (also the ApplicationEvents.OnDocumentChange).  The difference between them is scope.  One only monitors a single document, while the other monitors all documents.  And as you can imagine, there are tons of things that can trigger either one of those events.  They do offer a certain level of feedback about what caused the change, but it does not get super specific.  One of the common things they return is whether or not the the document is 'Dirty' now.  And yes, we can use that event to monitor for iProperty changes, but it is relatively complicated, and I am not sure if it would know the difference between if it was changed due to manual dialog interaction, or by automation code.  And, it is pretty complicated to determine which iProperties were changed, if that is important.

You are likely already aware of the 'EventWatcher' application example that comes in the SDK DeveloperTools folder, which can be pretty handy for quickly checking these types of things.  I usually end up creating my own 'inspection' type routines for 'reporting' when specific events happen, and what data is available via the event handler in certain situations too.  Attached is a text file containing the code that can be used within an external iLogic rule.  This rule can be ran manually, if just briefly testing, or when a document opens.  It uses the document scope events, which I like better for testing, because they go away when you close that document.  If you set it up to run when every document opens, then you would have to close all documents before modifying it, for the changes to take effect.  It essentially monitors the OnChange event, and writes a single report to the iLogic Log window once each time that event gets triggered, but on the 'Trace' level, so it won't drive me nuts with entries (can change Log level to see less detail).  I use a unique system to keep track of things like this, utilizing the iLogic 'SharedVariable' resource, and a new 'GUID' to String for each document (since 2 documents can have same internal name).

[Frederick_Law]

Here is my CheckDirty code:

Sub Main()
Dim oDoc As Document
Dim oCompDef As ComponentDefinition
Dim oModelStates As ModelStates
Dim oModelState As ModelState
Dim oOccu As ComponentOccurrence
Dim oOccuDef As ComponentDefinition
Dim oOccuDoc As Document
Dim CommandEnum As Integer

'break

oDoc = ThisDoc.Document
Logger.Info(oDoc.DisplayName & " Changed " & oDoc.RecentChanges)
CommandEnum = oDoc.RecentChanges
If (CommandEnum >= 1024) Then
	Logger.Info("View Rep Switch " & CommandEnum)
	CommandEnum = CommandEnum - 1024
End If
If (CommandEnum >= 512) Then
	Logger.Info("ModelState Switch " & CommandEnum)
	CommandEnum = CommandEnum - 512
End If
If (CommandEnum >= 256) Then
	Logger.Info("ModelState Update, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 256
End If
If (CommandEnum >= 128) Then
	Logger.Info("File Format Change, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 128
End If
If (CommandEnum >= 64) Then
	Logger.Info("Reference Change, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 64
End If
If (CommandEnum >= 32) Then
	Logger.Info("NonShapeEdit, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 32
End If
If (CommandEnum >= 16) Then
	Logger.Info("Reference File Change, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 16
End If
If (CommandEnum >= 8) Then
	Logger.Info("Properties Change, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 8
End If
If (CommandEnum >= 4) Then
	Logger.Info("File Op, dirty " & CommandEnum)
	CommandEnum = CommandEnum - 4
End If
If (CommandEnum >= 2) Then
	Logger.Info("Query " & CommandEnum)
	CommandEnum = CommandEnum - 2
End If
If (CommandEnum >= 1) Then
	Logger.Info("Geometry Change, dirty " & CommandEnum)
End If
End Sub

It can tell if the files is dirty because of iProperty changed.

You still need to find out which one is changed.

Your "request" is casting a very wide net to catch everything.

Is it possible to narrow it down?

A certain iProperty?  User changing iProperty?

[sneha_sadaphalW6XLM]

Hi @Frederick_Law I agree with your point. User can do any kind of changes and that is actually not possible to track. My request is not to identify which property is changed I just want whether user did the changes in Iproperty or not so that I can do my further implementation based on that flag. I checked with the event you mentioned above but those are not triggered if I change the properties.
I will try your shared code and will try to find out which one is changed.

[WCrihfield]

Hi @Frederick_Law.  I like your code example for examining change types.

I have something sort of similar that you may also like, but it was laid out in a more complicated way.  It extracts the Enum variation names and values into a Dictionary, and optionally edits their names to remove the leading "k", and following "CmdType" text.  Then it sorts them in descending order by their numerical values.  Then it iterates that collection, in that order.  While iterating, it is cross checking the value from the document against the value from the collection instance, and doing the process of elimination as it goes, similar to your example above.

It is set this up as an external iLogic rule that can either be ran directly (or with no arguments), or can be called to run from another process (with or without arguments).  But if arguments are supplied (for the document to inspect), then we can get a report back from it, if needed.  Sort of like a Function within a referenced resource.  If it is called directly, it will simply write a single report to the iLogic Log window, but if called remotely with arguments, it will only return that report to the calling routine, using the iLogic RuleArguments resource.

I have attached 2 text files.  One contains the code for that main external iLogic rule.  The other just contains code that can be used an example of some other iLogic rule that is calling that main one to run, with arguments, and how to receive that report back from it.  I haven't really seen that many examples on the forum showing both 'send' & 'receive' processes, and I really like that functionality, so that is how I set this one up.  Not that there is really a popular need for remotely retrieving that type of report as a String.  I just wish I had seen some when I was first getting started in this type of thing years ago.  It would have saved me a lot of research and testing.

[Frederick_Law]

Basically it's a binary bit "map" enum.

I think there are faster way to do the compare.

It can be Case statement also.