Access ComponentDefinition for ANY doc type without "Member Not Found" error

[DRoam]

Most of the time, Inventor is perfectly happy with something like the following:

Dim oAssyDoc As Inventor.AssemblyDocument = ThisDoc.Document
Dim oOccurrences As Inventor.ComponentOccurrences = oAssyDoc.ComponentDefinition.Occurrences

Dim oOcc As Inventor.ComponentOccurrence
Dim oOccDoc As Inventor.Document
Dim oCompDef As Inventor.ComponentDefinition

For Each oOcc In oOccurrences
	oOccDoc = oOcc.Definition.Document
	
	oCompDef = oOccDoc.ComponentDefinition
	
	oParameters = oCompDef.Parameters
	oBOMStructure = oCompDef.BOMStructure
Next

I'm able to create a test assembly that contains sub-assemblies, Parts, AND Sheet Metal parts, and this rule runs without any errors. 

However, on some of my real assemblies, I'll get a "Member not found" error on the "oCompDef = oOccDoc.ComponentDefinition" line.

The recommendation on other threads, like this one, is to treat Parts and Assemblies separately, using a PartDocument object for parts and an AssemblyDocument object for assemblies. This, of course, fixes the "Member not found" error. However, it requires literally doubling my code. I don't need to treat assemblies and parts separately; I'm not doing anything that's unique to only parts or assemblies.

Why does doing something like the code above sometimes result in the "Member not found" error, while other times it doesn't? I even have an assembly that will produce the error upon running the code above, but if I do a "Save and Replace Component" on the problem part to replace it with an exact copy of itself, then run the code, the error somehow goes away. Why is this?

What can I do to avoid the error without having to double up my code to handle Parts and Assemblies separately?

[philip1009]

When accessing the component definition of an assembly occurrence you have to use

ComponentOccurrence.Definition() As ComponentDefinition

Otherwise you'll have to grab the parent document if you want to use the regular component definition.

Autodesk should change it so it's either Definition or ComponentDefinition no matter the method of access.

[DRoam]

The "oCompDef = oDoc.ComponentDefinition" line is what I'm trying to diagnose. That's the line that I use throughout my actual code, and in Functions, to access the ComponentDefinition of a given Document. My actual rule is processing documents, not occurrences, so "ComponentOccurrence.Definition" isn't applicable to me. The purpose of that sample rule is to demonstrate the "Member Not Found" issue with accessing the ComponentDefinition property of the "Document" object. Iterating through the occurrences was just a means to that end.

Like I said, you can actually run the code above on a test assembly that contains both sub-assemblies and Parts, and it'll run fine. It's not doing anything that should produce any errors. But on some assemblies, it will. That's why one of my questions was, why does the "Member Not Found" seem to occur at random?

Hope that makes sense...

[philip1009]

Okay, I understand the issue now.  Member not found leads me to the possibility of iParts in your assembly, is that the difference between your working and non-working assemblies?  Otherwise, at the beginning of the loop you can have a message box pop-up telling you the name of what Occurrence is being worked on so you know which document is giving you the error, then we can go from there.

[DRoam]

The "member not found" error is a VB runtime error, it's not related to iPart members. See this thread that I linked to in my OP.

I think the error basically means that the ComponentDefinition "member" (i.e. property) was not found as expected on the Document object.

I've had it happen on all kinds of documents (regular Parts, Assemblies, sheet metal Parts); it's not tied to any particular document or kind of document. It's also not something I can intentionally reproduce.

My suspicion/theory is that something happens that flips Inventor into a "mode" where, when it processes Document.ComponentDefinition, it's specifically expecting to find a PartComponentDefinition or AssemblyComponentDefinition class, even though there's no reason for it to do so. As a result, when it tries to access Document.ComponentDefinition, if it's expecting the wrong class, it produces the "Member Not Found" error.

This theory seems reasonable to me because if you explicitly declare oDoc as a PartDocument or AssemblyDocument, the "Member Not Found" error never occurs. So something about telling Inventor specifically which derived ComponentDefinition class to expect resolves the error.

But what doesn't make sense is why that's necessary. Inventor should be able to access the ComponentDefinition property of a Document without specifically expecting either the PartComponentDefinition or AssemblyComponentDefintion class type. And what makes even less sense is that Inventor usually DOES handle this just fine, but at random it will decide to do something differently that results in the "Member Not Found" error.

[LukeDavenport · Accepted solution]

Hi DRoam,

Looks like this may have been a bug that was fixed in Inventor 2019.2 - see here

See the @MjDeck solution at the end. I think he has posted a workaround in case you're not on 2019.2 also, but probably best to upgrade to the current version.

Hope it helps,

Luke

[DRoam]

Brilliant! This explains everything. Thank you, Luke.

This line from Mike's first post was especially enlightening:

@MjDeck wrote:

There is no ComponentDefinition property on the Document object. Despite that, the code will usually work by late binding to a PartDocument or AssemblyDocument object. However, it can sometimes fail.

---

This makes perfect sense and explains the behavior I've been seeing.

As you say, Mike also informs that the issue has been fixed in Inventor 2019.2, resolved as issue INVGEN-11073. Which is great for those who are up to Inventor 2019, but unfortunately that doesn't include us 😉

So I asked him if there's any workaround, to help the late binding process, that work for those of us not on Inventor 2019 yet (the workaround he proposed is to treat assemblies and documents separately, which is what I'm trying to avoid).

So I'll be watching there for his answer. Meanwhile, I'll consider this thread resolved. Thanks for your help, Luke.