How to check if DocumentObject is still in memory?

[PolemEngineering]

I created an event listener addin for Inventor.

Various events can be a reason to execute an iLogic rule. Some consecutive iLogic rules are necessary here. The rest I filter out early. These Rules are largely checkpoints to see if iProperties and Variables are still formatted correctly.

Because I noticed the behavior where short consecutive RunRuleWithArgument commands were ignored because a previous Rule had not yet finished, I created a Queue. Later even a (perhaps unnecessary) ConcurrentQueue. Events now add an Element (consisting of DocumentObject, EventDescription and RuleName) to this Queue.

A TimerEvent checks at one-second intervals whether there are still elements in the queue and starts the RuleRunner if it is ReadyForWork (and at least 1 document is active).

This works quite well, except when (or actually after) closing a document. Here a (before)-OnSaveDocument-event is triggered which, probably due to the single thread character, cannot be executed anymore before the document is closed, but is only processed when a document is active again.

So at the time of the event, DocumentObject IsNot Nothing, but when processing the Queue, this DocumentObject is no longer in memory.
I had hoped to find out if the document still existed by querying the DisplayName of the Object in a simple Try...Catch...End Try, but the Object itself has this information available.

My question is how can I find out if the DocumentObject is still present in Inventor memory (so that I can dequeue it without further actions while processing the Queue)?

Thanks, René

Inventor 2023.5.1

[C_Haines_ENG]

Wow that sounds extremely complex! I can only imagine the use case of code like this. However, if you are actually running this over and over and over, you could use something like this:

Dim Search As String = "FILE PATH"
Dim bOpen As Boolean = False


For Each oDoc As Document In ThisApplication.Documents.VisibleDocuments
	If oDoc.FullFileName = Search Then bOpen = True
Next

Not sure how many documents you have open, but this For Loop usually runs pretty fast so performance shouldn't be a huge issue. 

[PolemEngineering]

Thanks for the response!

That enormous complexity is entirely my own fault... I misinterpreted the signals during debugging. Completely mixed up cause and effect. This made me do something pointless. Came to my senses during the last few days off. Back to basics.

Events had the ability to trigger the module to run the external rules before the previous rule had been executed. All I had to do was wait for the function to return. Instead I drowned in a half-baked multithreaded program with a thread-safe queue. All unnecessary...