Hi Marc,
there is no official information availlable on this flag. Everything i posted is based on my own observation. An
inquiry at my Autodesk-Dealer lead to the answer "That's none of you're business" (well just a little more
politely expressed, but that was basically the message).
But i downloaded the sample file, conducted a few experiments, and found out, that you're in fact dealing on a
MassProp-issue: At a first glance on the part itself, everything seems to be fine: the "update massprops"- button
in the iProperty-dialog is grayed out, there are nice values presented, and even the value of the "Valid
MassProps" - Property in the "Design Tracking Properties" is "31", i.e. all five bits set (something else, where i
would appreciate some more information on the meaning of the bits)
But then try out the following:
1: Set your application options to "update Massprops -> Parts only" on the General tab. Then create a new Assembly
from scratch, insert your part, and save the assembly. The "eAuditInvalidate"-flag of "6110.ipt" is not raised.
2: Do the same again (of course without saving 6110.ipt before), but set your Application options to "update mass
props -> parts and assemblies. Now, when you try to save the assembly, the "eAuditInvalidate" flag of "6110.ipt"is
raised.
3: Open 6110.ipt alone. Go to your VBA-client, and type "debug.Print
ThisApplication.ActiveDocument.componentdefinition.massproperties.mass" into the immediate window, hit Return, and
return to Inventor. Now have a look at your part's editflags via the "about Inventor"- Window (control-"d"). The
"eAuditInvalidate"-flag is raised.
Conclusion: Inventor is fooling you again by presenting self-contradicting information to you. Apparently he has
once again "forgotten" to perform some pending updates.
Here some more Information about updating MassProperties:
When you edit the geometry of a part, and the massprops aren't updated, ('cause the updatemasspropsonsave-option
is not active on your machine, and you haven't performed it manually), next time you open it, and do update the
massprops (either manually or automatically upon saving on a machine, where this option is active) the
"eAuditInvalidate"-flag is raised.
On the other hand, when changing the mass by altering the material without performing any geometric changes, the
massprops don't need to be "updated". they're automagically correct "without updating" (the volume and
"normalized" moments of inertia don't need to be recalculated, you only have to apply another proportional factor:
the density"
Now, when dealing with Assemblies, it gets even more confusing:
Once again the Example from my post on the MFC-flag:
ASM_2.iam
|
'-> ASM_1.iam
|
'-> PRT_1.ipt
We have changed the mass of PRT_1 by editing it's density without applying any geometric changes.
Now we open ASM_1:
-It's massprops are presented as automagically up2date in the iProps-Dialog.
-The eAuditInvalidate flag is not raised
-The "Valid MassProps" - Property in the Design Tracking Properties (DTP) ist volatilely set to "1" i.e. MassProps
are NOT up2date
-Last time, ASM_1 was saved, the Massprops were correct, thus the file on disk does still contain the outdated
values
-When we save ASM_1 now, the values in DTP are updated: In case the updatemasspropsonsave-option is active for
both, parts and assemblies, the correct values are written to the propset, otherwise the "Valid MassProps"
property is reset, and the Mass is not updated in DTP (although apparently known to Inventor).
Assume, we haven't opened and saved ASM_1 before, but open ASM_2 instead:
When we go to the "Physical"-tab in iProperties, the fields do all contain "-" and the "update"-button is active.
Klick it! now both, ASM_1 AND ASM_2
have their "eAuditInvalidate"-flag raised.
Still not lost?
Open the orignal and unaltered ASM_1 together with an also unaltered PRT_1.
Open PRT_1 for edit, change its Material, and return to ASM_1 without saving. now the "Valid MassProps"-Property
of ASM_1 is reset in Memory, whereas that of PRT_1 is not.
In the end, i cannot reproduce and thus explain the indefinite masspropstate of your part.
All i can say, is that these experiments strongly indicate, that "eAuditInvalidate" has something to do with
outdated Massprops.
BUT(!!)...
...you can also raise this flag without fumbling with massprops:
Take the Example from above:
Edit the "Part Number" property of PRT_1 using the Property-handler inside Windows-Explorer.
Open ASM_1.
Now, the BOMRequiresUpdate-flag inside the API is raised (this is none of the "eBlablabla" -flags from the save-
dialog).
Update the BOM by klicking on the BOM-button on the "Assemble"-Ribbon.
Check out your edit flags: the only one raised is "eUpdateCmd".
Close it without saving.
Open ASM_2 instead.
Click on "BOM"
Now open ASM_1 and check its editFlags!....
... Any questions???
PS: I personally do not consider it a good idea to make library parts adaptive, or reuse adaptive parts in another
assembly, or using adaptivity at all together with Vault.
PPS: Inventor gives a da mn on what the vault says about any file. You cannot prevent Inventor from demanding write
access to any file due to some phantom pain, by not checking it out, "releasing" it, or putting it inot a library-Folder.
On the other hand, the best way to completely mess up the data integrity inside your vault is to ignore updates
you consider illegitimate, calm Inventor by saving them "out of turn", and then check in the superior assembly ->
now the next one to download the assembly cannot get the expected version of the dependent file as it does only
exist on your workstation, and the vault has absolutely no clue, that the two files he is delivering to the next
workstation do not fit together. Maintaining data integrity and prevent producing garbage takes up 70% of my time,
and requires very much knowledge about inventor's internal file structure and updating mechanism, which i have
gathered throughout all the years i have been working with this System (which still consumes another 20% of my
time, as yet, i still do not know everything)
)
When I saw the bluish tee icon in the screencast I was wondering if something about the routed system rules causing it. I've come across other issues as well that were related to routed system rules when the tube & pipe module is loaded. Granted this 
