ThisDoc.Document vs ThisApplication.ActiveDocument

[utm007]

Hi to all,

I've tried the following code to see the differences, but Set Doc=ThisDoc.Document give run time error 404 no object, while the second one is correct.

What's wrong in my usage of ThisDoc?

Sub example()

Dim oDoc As Document, Doc As Document

Set oDoc = ThisApplication.ActiveDocument
Set Doc = ThisDoc.Document

MsgBox oDoc.DocumentType + "ThisApplication example"
MsgBox Doc.DocumentType  + "ThisDoc example"

End Sub

[A.Acheson]

ThisDoc.Document is an ilogic function only with link to API help here.

ThisDoc refers to the document in which the rule is written. For more information API help is here

[Curtis_W]

Hi @utm007 

Imagine you have a part file in an assembly and that part file has a rule in it that sets the description iProperty. And that part rule gets triggered when a parameter named Length is updated.

Now imagine also that the assembly has a rule that sets the Length in that part.

If your part rule uses ThisDoc.Document then when the rule triggers, then the rule is looking at the part document. 

But if the part rule is using ThisApplication.ActiveDocument then it will be looking at the assembly, because that is in fact the active document.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[WCrihfield · Accepted solution]

What a coincidence.  I actually wrote a contribution post about this exact topic a year or so ago.  Maybe reading through that will help out some too.

ThisApplication.ActiveDocument vs ThisDoc.Document (Document References Explained In More Detail) 

[WCrihfield]

Also, just to add to what @A.Acheson said earlier, it's a little hard to tell if you are trying to write that code for an iLogic rule or for a VBA macro, but I would guess that is is for a VBA macro, due to your use of the keyword 'Set' before the two lines of code.  That 'Set' term is not really used in iLogic.  And as he mentioned, that term 'ThisDoc' is only defined within the iLogic add-in, so it will not be recognized within a VBA macro.  That may be why that one is not working as expected in that situation.

[utm007]

Thanks Curtis,

I've written this example because I'd like to acces the ipt  selected within an assembly.

I'm writting it in VBA.

With iLogic and ThisDoc.Document it works, as you've correctly written before.

With VBA and ThisApplicatio.ActiveDocument I can acces only the assembly and not the ipt in the assembly.

Now, how can I write something like ThisDoc.Document in VBA that runs like ThisDoc.Document in iLogic ? And before do it. Is it possible?

I'm trying to read something about the links you've given me.

Thanks.

[utm007]

Yes, in VBA.

Thanks

[utm007]

Oh, great!!!!

I've read the doc, and the solution should be:

[...]

The term 'ThisApplication.ActiveEditDocument' seems to have been created for the specific scenario of when you are working within an assembly document, so that the assembly is the 'active' document, but you have entered into the Edit Mode for one its components, so that all the other components are greyed out, and you want to refer to that component document which you are actively in-place editing. Although it was created with that specific scenario in mind, it can also be used in other situations too, and will then return the active document, and is not document type specific

[...]

I'm trying and let you know!!!

Thanks

[br.sbrava]

I'd really like to read your article, but it seems like Autodesk has changed the forum URLs and the link is broken.

Also couldn't find it searching online. Would you mind posting an updated URL?

[WCrihfield]

Hi @br.sbrava.  I can not remember the actual date that Autodesk took down everyone's 'Contribution Articles' which were posted in the Autodesk knowledge base area, but it has been a few years now, and when they did, it left a TON of broken Links all over the Autodesk Community afterwards, which really disappointed a lot of folks.  I think I had around 16 of them at the time, but I only 'preserved' the contents of a few of the most popular ones at that time, by copying most of their contents over into Microsoft Word documents, then exporting those to PDFs.  I am not sure I still have that specific article, but I will attach a few similar resources I have on hand which I think you will find helpful.

I can summarize that article from memory though:

The 'ThisApplication.ActiveDocument' property (defined within Inventor's API directly, not in iLogic) will always return Inventor's true 'active' Document, no matter what else is going on.  Inventor's active document is the one visibly showing on your screen, ready for editing, at the moment that property's value is used.  Often times this means that if you start (run) an iLogic rule while an assembly is Inventor's active document, it will usually remain Inventor's active document even if your rule is accessing many other 'referenced' or invisibly opened documents in the background.  This usually means you would have to use other ways to access those other documents that you want the rule to interact with besides that code phrase.  However, our code process can visibly open other documents, then 'activate' them, if necessary, which may make them the new active document, depending on the situation.  So, this is the easiest one to explain.

'ThisDoc' is an iLogic 'Rule Object' (predefined/set rule variable) representing the ICadDoc Interface, which is unique to the iLogic add-in's API (not in Inventor's API).  This Interface has several Properties & Methods, but we will focus on its ICadDoc.Document Property here.  Using this property is the most popular, and most robust (and often most accurate) way to access the 'current' (not necessarily 'active') Document that we want our iLogic rule to be working with.  This is because it works differently in different situations, which makes its 'official' documentation so lacking, and in need of much further explanation.  Its official documentation only says "Gets the document in which the rule is running."

• When using an 'internal' (saved within the Inventor Document) iLogic rule:  'ThisDoc.Document' will point to the Document which the current iLogic rule is saved within - by default, with some possible exceptions
• When using an 'external' iLogic rule:  'ThisDoc.Document' will point to the Document that was 'active' when that rule first started - by default, with some possible exceptions
• When an iLogic rule was 'triggered' to run by a setting in the iLogic Event Triggers dialog:  'ThisDoc.Document' will point to the Document that the Event was triggered within
• When we use the iLogic methods like RunRule, RunRuleWithArguments, RunExternalRule, RunExternalRuleWithArguments to run a secondary rule from within a primary rule, which are listed under the IiLogicAutomation Interface (accessed by 'iLogicVb.Automation' code phrase), those methods ask us to input the Document that we want the 'other' rule (which we are about to run) to focus its attention on.  In those types of cases, when the 'ThisDoc.Document' phrase is used in that other rule, it will point to that specified document that we input in those methods.
• There are likely other similar scenarios which could be mentioned here, too.

In many of those cases, the value of the 'ThisDoc.Document' property can potentially be a different Document than the one we get from the 'ThisApplication.ActiveDocument' property.  On the other hand, when we are writing code to automate Inventor in Inventor's VBA editor, or when we are writing code for an Inventor add-in (ApplicationAddIn), of for an external EXE type application, the 'ThisDoc' term is not recognized, because it is unique to the iLogic add-in, which is why the 'ThisApplication.ActiveDocument' remains popular in code examples.  One of the most common scenarios where this mis-match happens is when editing or saving a Drawing or an Assembly, because both of those document types 'reference' other documents in the background.  When we open a drawing or assembly, Inventor also partially or fully loads all of those referenced documents into Inventor's session memory invisibly, in the background.  And if any (savable) changes are made to any of those referenced documents while the parent assembly or drawing is open, and you attempt to save the assembly or drawing, it will also want to save the referenced documents that were changed at that time.  When those changes or saves happen to those background referenced documents, it sometimes 'triggers' those Event Triggers settings to run iLogic rules on those background documents...none of which are Inventor's true 'active' document at that moment in time.  So, if the code phrase 'ThisApplication.ActiveDocument' is being used within those 'triggered' rules to refer to the document that those rules should be working on, there is a good chance that they will be attempting to access the wrong document, which will often cause unexpected errors...or worse yet, unexpected changes to the wrong document(s).  Other than the Inventor.Application object itself, which the 'ThisApplication' term represents, the Document object is the next most important object that our iLogic rules reference/use/access, so it is important to understand how to access the right ones, the right way.  Whew. 😅

[br.sbrava]

Hi Wesley,

Thank you SO much for the fast response and for taking your time to clarify this, even including reference links. This really helps me a lot understand the nuances because, indeed, the documentation is not specific enough about this, given all the possible scenarios.

True, I have noticed this unwanted behavior of Event Triggers quite early in my iLogic undertakings and stopped using them altogether. I think a lot of these issues boil down to the fact that Inventor loves to "dirt" files that are open in the background.

Such a shame all of Contribution Articles have been vaporized. Thanks for sharing these PDFs, very good source, particularly for the InternalNames, those are always tricky to find.