Ilogic - Model State - Event trigger

Ilogic - Model State - Event trigger

serge2NPMD
Participant Participant
106 Views
1 Reply
Message 1 of 2

Ilogic - Model State - Event trigger

serge2NPMD
Participant
Participant

I'm having trouble with event trigger when using model state :

 

We are 4 designer and we use a Shared Project, Inventor 2024

 

We use an ilogic rule to automate check in of the document. The ilogic rule is trigger for All document using the "Close Document"

 

The issue we face : the rule is trigger when switching model state. Most of the time the rule fail. Is there a way to avoid the rule to be triggered when switching model state ?

 

We also notice that the rule fail sometime, only with document using model state, and especially model state that was previously "level of details".

 

When using the File Status interface and launching the command "check in tree", all the check in are done properly.

 

Here is  a copy of the ilogic code.

 

 

 

 

Dim oDoc As Document

Try
	If ThisDoc.Document.DocumentType = DocumentTypeEnum.kDrawingDocumentObject Then
		oDoc = ThisDoc.Document
	Else
		oDoc = ThisDoc.FactoryDocument
	End If
	'Logger.Debug(oDoc.DisplayName & " : Affectation réussi")
Catch
	Logger.Debug(ThisDoc.Document.DisplayName & " : " & ThisDoc.ActiveModelState & " : Affectation Catch")
	Exit Sub
End Try


	

Try	

	If oDoc.ReservedForWriteByMe = True Then
		'Logger.Debug("Document : " & ThisDoc.Document.DisplayName)
		
		If oDoc.DocumentType = DocumentTypeEnum.kDrawingDocumentObject Then
			Try
				oDoc.RevertReservedForWriteByMe
			Catch
				'Logger.Debug(oDoc.DisplayName & " : Drawing Catch")
			End Try
			
		ElseIf oDoc.DocumentType = DocumentTypeEnum.kPartDocumentObject Or oDoc.DocumentType = DocumentTypeEnum.kAssemblyDocumentObject Then
			Try
				oDoc.RevertReservedForWriteByMe
			Catch
				Try
					oDoc.ReservedForWriteByMe = False
				Catch
					'Logger.Debug(oDoc.DisplayName & " : Part and assembly Catch")
				End Try
			End Try
				
		End If
			
	
	
		If oDoc.ReservedForWriteByMe = False Then
			'Logger.Debug(oDoc.DisplayName & " : Succès check in")
		Else
			Logger.Info(oDoc.DisplayName & " : Échec check in")
		End If
	End If

Catch
	'Logger.Debug(oDoc.DisplayName & " : Main Catch")
End Try

 

0 Likes
107 Views
1 Reply
Reply (1)
Message 2 of 2

WCrihfield
Mentor
Mentor

Hi @serge2NPMD.  That sounds like a tough situation to diagnose.  I rarely ever use the event named 'Close Document' in the iLogic Event Triggers dialog, so I am not 100% sure if that gets triggered just before, or just after the 'real' document close event happens.  Knowing that little detail will make all the difference, because if that document has already been closed at that point, then you may not be able to access it with your code anymore.

 

Are you familiar with using event handlers without the help of any settings in the iLogic Event Handlers dialog being involved?  Well, if not, it can be a complicated area of automation coding to get into at first.  But when you do, you will notice that some events have a 'timing' related property which can be used to react to the event just before it actually happens, or just after it happens.  Not all events have this functionality though.  It sounds like you need your code to react to that event just before it actually happens, so that you still have access to that document object.  There are ways to do this without using the iLogic Event Triggers dialog settings, but it is far more complicated to set-up, and often requires something like an Inventor add-in.  This is because an add-in is loaded when Inventor starts, and remains running in the background the entire time Inventor is running, to enable custom behavior, event handling, and make custom tools available, and even customize the user interface.  Using iLogic rules for handling events like that is very limited by comparison.  A few related events that can be accessed / used in the Inventor API are as follows:

ApplicationEvents.OnCloseDocument 

ApplicationEvents.OnTerminateDocument 

ApplicationEvents.OnUndoOpenDocument 

DocumentEvents.OnClose 

In the event arguments of those events you will see a variable called 'BeforeOrAfter' which represents a variation of the EventTimingEnum.  This is not something that we can change, but is something that we can check the value of when the event gets triggered, because events with that resource available to them will actually get triggered twice...once just before the actual action takes effect, and once just after the action takes effect, allowing is to react differently, depending on its value.

 

Another thing to keep in mind is that not only are documents opened and closed, but they can also be 'initialized' and 'terminated'.  Initialized is when they get invisibly, and partially loaded into Inventor's session memory, such as when you open an assembly or drawing, and it automatically initializes all the 'referenced' documents in the background.  There will not be visible document tabs for them, but there will be a total number of them in the lower right of Inventor's status bar (if you have Inventor's status bar visible).  Similarly, documents can be closed without them actually being unloaded or cleared completely from Inventor's session memory.  Once they have finally been cleared out of Inventor's session memory, that is when it gets 'terminated'.

 

And as you may know, when we have Inventor model documents with multiple ModelStates, that means that is is possible for there to be multiple Document objects defined within that one File on disk, with potentially one for each ModelState.  A Document is automatically generated for a new ModelState once you have placed an instance of it into an assembly.  There may be other occasions where that action takes place also.  Because of this, we can have one File open, and there be multiple Documents loaded in Inventor's session memory for that one File.  Something that has made automating Inventor when those types of files are involved a lot more complicated at times since they were introduced.

 

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes