iLogic Opening and Modifying Document In Unexpected Fashion

[alexander_anderson4353E]

I am attempting to open a document (chosen by the user) to then modifying using another iLogic rule. Documents open as expected, rules run as expected, however I am having an issue with what is treated as "active" for certain lines of code/rules. 

For example:

MessageBox.Show(ThisApplication.ActiveDocument.FullDocumentName)

Will return the drawing that is active in Inventor, however: 

customParameter = customParameters.AddByValue("DrawingType", "", UnitsTypeEnum.kTextUnits)

 Modifies the drawing that was open when the initial rule was run. Additionally, this line will always fail with an error of  "Error on line 14 in rule: CreateParams, in document: Drawing2 MultiValue: Could not find a parameter named: "DrawingType""  (In this Drawing2 was the document that was open when the rule was run)

'Rule "CreateParams"
Dim oDoc As DrawingDocument = ThisApplication.ActiveDocument
Dim customParameters As UserParameters = oDoc.Parameters.UserParameters
Try 
	dummyVariable = Parameter("DrawingType")
Catch
	customParameter = customParameters.AddByValue("DrawingType", "", UnitsTypeEnum.kTextUnits)
	'Parameter("DrawingType") = "Janus Drawing"
	'set the list
	MultiValue.SetList("DrawingType", "ValueA", "ValueB", "ValueC", "Test Doc")
End Try

When run in the drawing itself this works fine, however, when the drawing is opened by iLogic and then changed I encounter errors.

doc = ThisApplication.Documents.Open(item, True)
doc.Activate()
MessageBox.Show(ThisApplication.ActiveDocument.FullDocumentName)
iLogicVb.RunExternalRule(“CreateParams”)

Correctly identifies the drawing intended to be modified, however the parameter changes are seemingly applied to the wrong drawing.

I have tried:

-pausing before making the document active

-pausing after making the document active

-pausing before creating the parameter

-pausing after creating the parameter

-Removing all references to "this.doc" ( i read that this references the document running the rule) and replaced with "ThisApplication.Activedocument"

These pieces work individually, but now are having issues.

Edit: "ThisApplication.Activedocument" with "ThisDrawing.Document" addressed the customParam error

[alexander_anderson4353E]

Use of "ThisDrawing.Document" over "ThisApplication.ActiveDocument" fixed all issues. 

[WCrihfield]

Hi @alexander_anderson4353E.  The Inventor API Property "ThisApplication.ActiveDocument" only captures whichever Document happens to be currently 'visible' on your screen at that moment, ready to be directly edited.  If an assembly was visibly open on your screen before your code starts, then that is the one that property will capture.  If you start iterating though documents that the assembly references, those are usually not visibly open on your screen at that moment, so those will need to be referred to differently.  If you run some other iLogic rule, but do not indicate to that other rule which document it should be focused on, then it will most likely act upon whichever document is currently, visibly open on your screen at the moment it runs, unless set-up differently within that other rule.

I use the uniquely iLogic code phrase "ThisDoc.Document" about 95% of the time, because it is a lot more dynamic, and will point to 'the most appropriate' document in most complex situations.

For example, the ThisDoc.Document will:

• If used within an 'internal' iLogic rule, it will 'default' to pointing to the Inventor Document that the rule itself is saved within...even if that Document is not the 'active' document at that moment.
• If used within an 'external' iLogic rule, then it will 'default' to pointing to the Inventor Document that was 'active' at the moment that external rule got called to run, and will stay pointing to that document.
• (internal or external rule)  If the iLogic rule was triggered to run by an event in the Event Triggers dialog, then it will point to the Document that the event happened within/to...even if it is not the 'active' document at that moment in time.
• (internal or external rule)  If the rule gets ran by one of the iLogic 'RunRule' or 'RunExternalRule' type methods that are defined after the 'iLogicVb.Automation' code phrase (no the ones just under 'iLogicVb'), then it will point to the Document specified by those methods for the rule to focus on...even if it is not the 'active' document at that moment.

When I know that my code is going to be doing something where the user needs to manually interact with the same document that the rule is focused on, then I will use the 'active' document phrase instead, because that will be the most appropriate for that type of situation, but that situation is more rare, since it takes away from the 'automation' value when the user needs to manually get involved.

Edit:  Also, you will notice that many of the uniquely iLogic 'Rule Objects' that we use within iLogic rules, it is not obvious which document they will focus their attention on in various situations, when you consider some of the unique situations I mentioned above.  Some of them do offer a way to specify a document or component for it to focus on, but it it not always clear how to do so effectively.  Most of those tools will focus on the same document as the 'ThisDoc.Document' code phrase will focus on, by default, unless specified otherwise.

[alexander_anderson4353E]

The intent is to modify drawings with no user input after selecting the folder the drawing is in. 

For the Rule Objects, do you know of methods to specify which drawing they should focus on? Between using ThisDrawing.document or ThisDoc.Document I've noticed little to no difference. 

The code now runs (substituting one or the other in) however they are still modifying the drawing that was initially opened. 

I might have to play around with it a bit to see how I can get it to do what I'm looking for.

[WCrihfield]

Hi @alexander_anderson4353E.  Since 'ThisDrawing' is another 'Rule Object', which represents the IManagedDrawing Interface.  Since 'ThisDoc' is also a 'Rule Object', representing the ICadDoc Interface, they both work almost identically, as far as their 'Document' property value, except that the 'ThisDrawing' on is specifically for DrawingDocument Type, when 'ThisDoc' is for any type of Document.  So, if you are using the 'ThisDrawing' object in an external rule, and an AssemblyDocument is the active document type, then it will either throw an error, or not have a valid value, because there is no DrawingDocument available when the rule starts.  I used to use 'ThisDrawing' quite a bit myself, and there are still certainly many valid reasons for using it.

On another note...in every iLogic rule, we have access to the Rule Object named 'iLogicVb', which represents the ILowLevelSupport Interface.  That object has a method named CreateObjectProvider, which asks for us to supply a Document object as input, and returns an IStandardObjectProvider Interface.  From that 'object provider', we have access to most of the other 'rule objects', but the valuable thing about it is...all those rule objects that we access through that object, will be focused on the Document object that we provided as input.  Eliminating any confusion over which document they will focus their attention on.  Just keep in mind that the 'object provider' is 'disposable', meaning we need to 'dispose' of it when we are done using it, to clean up the resources/memory it was using.  So, we can either use it within a 'Using...End Using statement, or we can just call its 'Dispose' method when done with it.

Other Rule Objects, such as the 'iPropeties' or 'Parameters' objects, have methods (Link, Link) which have 'optional' inputs that ask for either:  1) ComponentOccurrence.Name of the ComponentOccurrence that you want it to focus on ; or 2) the Document.DisplayName of the 'referenced' Document that you want it to focus on.

[alexander_anderson4353E · Accepted solution]

After some looking i stumbled upon this

https://help.autodesk.com/view/INVNTOR/2022/ENU/?guid=20a9a482-0e9c-6b88-a6f2-e200b332ee62

Function RunExternalRule ( 
	doc As Document,	ruleName As String
) As Integer

iLogicVb.Automation.RunExternalRule(doc, ruleName)

Which works like how I desire, so i will be using this in situations like this from now on. 

The advice about thisDoc vs ThisDrawing didn't work for me, when i tried both in a new set of code, they both referred back to the drawing I ran the rule/form from. I'm inclined to believe the advice is true, and that there is something different that I've done that is causing them to act differently.

[WCrihfield]

I use those 'run rule' method under the Automation object in pretty much every occasion, instead of the ones directly under the 'iLogicVb' object, for that reason...more control.  Another thing to keep in mind is the 'arguments' that we can pass to other rules.  When using one of those 'run rule' type methods, it wants us to create a NameValueMap, then add some entries into it, with each entry having a 'name' and a 'value'.  The name part is always just a String, but the value part can be all sorts of different types of things.  One of the things we can put in as a value is an actual Inventor.Document object.  We can also have a 'List(Of String), type value, or Dictionary.  Very useful to keep in mind.  When including the 'arguments' though, you must prepare the rule on the 'receiving' end, to receive those arguments, and be able to use them.  To do that, we can use the 'RuleArguments' Rule Object, which represents the IRuleArguments Interface.  It is pretty much just a simple iLogic tool for working with those temporary NameValueMaps, and is similar to the iLogic 'SharedVariable' system, so it is pretty easy to use.