Stop telling me I need to save something I haven't changed

[andrewiv]

Inventor shouldn't be prompting for a save on a file that hasen't changed.  I'll give an example.  I insert assembly1 into assembly2 and set it to positional rep1.  I save assembly2 and close it.  Now I re-open assembly2 and it asks me if I want to update.  I say yes and now it asks if I want to check out assembly1.  I say no since I haven't done anything to it.  Now Inventor tells me that I need to save assembly1 and assembly2 even though I just saved them and the only thing I have done is open them.  I think this is wrong and it can create a ton of unneeded versions of the assembly when using vault.

[bradeneuropeArthur]

Hi Bert,

Per default we do not update the mass properties, because inventor always want to update the mass properties, independent if the file is read only or not. We have created an add in that provides us the correct weight of the assemblies and the parts without updating them (Dirtying) the files.

Can you please give me an overview of the I-properties you use with their expressions. for example Like: Description ; =<Part Number> <Stock Number>

Maybe I can see the same problem as we had in the past.

[Bert_Bimmel]

Dear bradeneurope

thank you for your suggestions. I tried to figure out, if my MFC-Document issues had something to do with formulas in iProperties. In fact i do make use of this feature occasionally, but not very often, and after digging into this i could not find any connection. instead, i figured out the following according my MFC-Problem (especially scenario 4):


initial Situation:

Simple Assembly Tree (created and cleanly saved before):

ASM_2.iam
|
'-> ASM_1.iam
      |
      '-> PRT_1.ipt

Scenario 1.1 (plausible):

All three Files are open in their own Window and PRT_1 has received changes, that are neither physically nor geometrically nor BOM-relevant, i.e. the eEditCmd and the eNonShapeEditCmd-flags have been raised (for instance the Renderstyle has been changed.)

Pending actions when saving ASM_2 (or closing it, beeing prompted to save):


* ASM_1 + ASM_2 desire to create new Thumbnails and new Current- Next- and Previous Version-iProps

* As the DataBaseRevisionID of PRT_1 is about to be changed and saved together with ASM_1 and ASM_2, ASM_1 desires to update its File-Reference-list inside the UFRxDoc-Stream with the new DataBaseRevisionID of PRT_1

* Although the DataBaseRevisionID of ASM_1 is NOT changed upon altering its UFRxDoc, ASM_2 does also want to update its own UFRxDoc, resulting in nothing else but a new TimeStamp of its own creation, as nothing else has changed (ASM_1 has no new DataBaseRevisionInfo, thus, its record inside ASM_2 is not altered)


Self-contradicting diagnostic information:


* consulting the "Save Status" Windows of ASM_1 and ASM_2 via ctrl +d inside the "about-Inventor" Window do not inidcate MFC-Document-changes

* neither do the "Dirty"-properties of these files inside Inventor's API

* neither are ASM_1 or ASM_2 marked with an asterisk in the Vault Browser

* the save-dialog of ASM_2 does indicate MFC_Document-Changes for ASM_2 but not for ASM_1 upon ctrl-RMB, whereas the save-dialog for ASM_1 does (ASM_2 is not listed here)

* The "Save Status" Window indicates 0x41 for the edit flags of PRT_1, whereas the "RecentChanges" property inside the API says 0x21

Save Suggestions provided by Inventor:


* PRT_1 -> yes (relevant changes)

* ASM_1 & ASM_2 -> no (changes considered irrelevant)

Results:


1. Everything is saved -> upon next opening of any of the above files everything is fine and all references are consistent

2. PRT_1 is saved but ASM_1 and ASM_2 aren't -> upon next opening of ASM_1 or ASM_2 Inventor will stumble over the unexpected new DataBaseRevisionID of PRT_1, but won't bother the user as it can track back to the expected RevisionID inside the RSeDbRevisionInfo-Stream and see, that no changes of the above mentioned relevances have been applied to PRT_1 since. Thus, once closed and reopened at any time will not promt for MFC-Document-changes any more. Clicking on the save-button in ASM_1 or ASM_2 has no effect until other changes are applied to any document.


Remark: Appearently, writing a new UFRxDoc does not mandate altering the DataBaseRevisionID. When glancing at the folder structure of the Windows-compound-file container of any Inventor file (for instance using 7-Zip which is capable of dealing with compound files), this seems plausible, as it is nested within the container file's root folder, and not inside the RSeStorage. On the other Hand, editing nothing else but iProperties should be possible too without altering the DataBaseRevisionID, as the PropertyStorages do also all reside inside the Root-folder and are 100% Microsoft-Technology (MFC document/view-architecture). And actually it IS, when editing iProperties using the property handler inside Windows explorer. Instead, When editing properties inside Inventor, the eViewCmd- and the ePropertyEditCmd-flags are raised (why eViewCmd???), and a new DataBaseRevisionID is created (enhancing the confusion about the data-integrity)


Scenario 1.2 (semi-plausible):

The same situation as above: all three files open, PRT_1 is changed, but its changes are saved in its own context/window before proceeding: The behaviour is now the same as after closing and reopening in the example before, where ASM_1 and ASM_2 haven't been saved: no prompt on closing, no reaction on clicking the save-Button.


Scenario 1.3 (semi-plausible):

PRT_1 receives the same changes as in scenario 1.1, but ASM_1 and ASM_2 are not open meanwhile. The changes to PRT_1 are saved, and ASM_1 and/or ASM_2 are opened afterwards. The result is the same as in Scenario 1.2: no prompt on closing, no reaction on clicking the save-Button.

Conclusion: Inventor suggests to save some pending updates inside the respective session, but does not bother the user about these any more, once the session was closed without saving these changes.

Scenario 2 (not plausible):

ASM_2 is open, and PRT_1 is activated for editing in the context of ASM_2, but returned to ASM_2 without performing any changes:
Now the MFC-Document-flag of PRT_1 is raised. ASM_1 and ASM_2 behave like in scenario 1.1

Scenario 3 (not plausible):

All three files open, some random editing on PRT_1 is undone back to its state when it was opened:
Same behaviour as in Scenario 2

Conclusion: Inventor is not capable of detecting that the user has returned to the last saved state, and there actually are no changes


Scenario 4.1 (erratic):

All three files are open, plus another PRT_2.ipt. Now the VBA-Editor is accessed via the Button in the "Extras"-Ribbon, OR, any macro (that is not supposed to change anything but dump diagnostic information instead only - even if the only executable line of the assigned macro is 'debug.print "Hello world"') is executed from a shortcut in any of the ribbons: the "MFC-Document has changed"- flag is raised for all PART-files, that are open in an own window (in this case PRT_1 and PRT_2), and thus, the parent assemblies prompt for save too.

This does NOT occur, if the VBA-Editor is already open, and accessed via the Windows Taskbar, and/or the macro is started from within the Editor instead of by a shortcut.


Scenario 4.2 (inconsequently inerratic):
Same as 4.1, but only ASM_1 and ASM_2 are open in an own window, whereas PRT_1 and PRT_2 are not: Nothing happens. Apparently only Partfiles are affected by this Bug.

This did not happen in Inventor 2012!!


Remark: Apparently, starting a macro from an assigned ribbon-shortcut behaves differently than starting the same macro from the VBA client: Another sample: In 2012, the select-events did not work properly, when the macro was started from the ribbon, thus a macro that needed some interaction with the user by selecting any entity in Inventor's graphics-window, was bound to be started from within the VBA-editor.
Now, as it does not run in a 32-Bit sandbox any more, as Microsoft finally had the mercy to port VBA to 64 bit, this issue has been solved, but another one has been introduced instead. As I do run macros very often, and of course have placed some shortcuts, I ran into this bug a thousand times a day, but it took me almost a year to isolate this from all the other issues I'm dealing with, when working on a machine with several thousand parts (or getting so pissed, that I finally decided to dig into it systematically).


My suggestion to Autodesk: Clean out the VBA-MFC-Bug, Shoot your fuzzy-logic for updating files to the Moon, so that it becomes transparent to the user again, prompt for update on any changes to dependent parts, and then perform ALL(!!!) pending updates (i.e. including Mass- and BOM-updates), add an "revert to saved" option for components inside an assembly with only imaginary changes, and maybe provide some additional diagnostic information which subordinate parts are causing a pending update)



I'll be back with another essay about MassProperties and the eAuditInvalidate - flag, that drives me crazy too, as soon as I have answered all my questions about this myself. Unfortunately I have to return to the task my employer does actually pay me for: designing new machines and not diagnosing bugs in Autodesk's flagship!

Just so much for now: a more appropriate name for the "eAuditInvalidate"-flag seems to be "eMassPropsOutdated", and I disagree, that disabling the "Update MassProps on Save"- option is a good idea, and it is impossible to get this straight (as long as you don't use PosReps, wich is another large issue). it's just not trivial, but i will figure this out some day!

Cheers, Bert

[Curtis_Waguespack]

So it seems there are multiple reasons for this issue.

The most common one being that the file(s) were last saved in an older version of Inventor.

Solution:

How to batch migrate file with Task Scheduler

But there are others that Autodesk has been made aware of, but can not provide a solution for at this time, such as Bert_Bimmel details above and in this link:

http://forums.autodesk.com/t5/vault-general-discussion/vault-library-file-smudging/m-p/6438913#M6371...

Certainly this needs be made a higher priority than it has been for the last (how many? ) years.

[Anonymous]

100000000 YES

[cbenner]

A-flipping-men!

[Gabriel_Watson]

It's all in the behind-the-scenes properties and references, being updated and feeling like they're out of sync. This is a tough issue to untangle, but it does make total sense, and affects all users, advanced or basic.

[Anonymous]

100%, I don't want to see any new fancy features, next revision, just a fix for this, If I haven't changed it, it doesn't need saving, If it can't be saved, tell me why, and above all if it's a released Vault file don't even think about changing it. (If changes I make require a released file to be saved, tell me all about it.

[bradeneuropeArthur]

It seems to be not a very critical issue for Autodesk team to my opinion, because the issue is already very old.

Or on the other hand they are not able to solve the problems regarding updates and dirty files.

For many users it is an huge issue, isn't it????

My general Remarks:

Autodesk inventor is a very fine tool, and regarding the update and dirty files there is no problem when working with a not vault system.

Autodesk Vault is also a good tool when not working with a inventor system.

To my opinion the communication, and their requirements, between the Autodesk teams (Vault and Inventor) should be better.

The 2 product teams need to be in very short contact and need to have the same knowledge and views about the software products.

At the moment it looks like the inventor software needs to be downgraded (Regarding tools and features) when working together with a vault system.

Autodesk should not only show us what's new in newer editions, but should also show us what tools and features cannot be used in combination with vault. This should be implemented as a additional training for and from our resellers.

Or there should be a separate Autodesk Vault - Inventor edition, that will unload tools not working in combination with Vault. it should not be possible to do anything not working together with vault.

This means the vault add in should be rewritten and eliminate unwanted actions regarding update, dirty files etc etc.

To my opinion the Autodesk Inventor software is always presented as a system without vault. We all know that when working together with a release process (vault) we should not use some tools and features in inventor.

A reply from the Autodesk teams would also been appreciated I think regarding the issue, isn't it?

[mrattray]

If I could vote 20 times for this I would.

[dg2405]

This behavior occurs when geometry of sub-assemblies with positional representations has been changed. The consequence is that inventor not update the mass properties of the posreps.

Try following:

-go in each positional representation of the sub-assembly an klick in the ribbon "manage" on "update mass"

-The icon now should be greyed in each posrep

-Save the subassembly

-Go into the assembly, update them and save, now no savedialogue should occur

We have a rule wich will be fired everytime on save do this for each positional representation. Since we have that there are no further problems with this stuff.

Good luck Daniel

[bradeneuropeArthur]

This seems to be one of multiple issues.

During the release process this workaround is not working to my opinion.

On the second hand inventor always wants to update the complete design without keeping the release status in mind.

One of the things that is working is to disable the files form updating "Mass".

Per default we do not update the mass properties, because inventor always want to update the mass properties, independent if the file is read only or not. We have created an add in that provides us the correct weight of the assemblies and the parts without updating them (Dirtying) the files.

[bradeneuropeArthur]

Per default we do not update the mass properties, because inventor always want to update the mass properties, independent if the file is read only or not. We have created an add in that provides us the correct weight of the assemblies and the parts without updating them (Dirtying) the files.

[Anonymous]

This is an even more serious issue when you use the stress analysis module.  What happens is Inventor thinks something has changed when it has not. Then when you open your study at a later time, you LOSE ALL YOUR RESULTS!  Just gone.  So effectively there is no way to save your results in stress analysis.  Thats crazy!  More than just an annoyance.

This whole situation is just a bug or series of bugs Autodesk has not addressed, plain and simple.  None of the workarounds work properly.  It's not just the Vault, it's not just positional representations etc. etc.  It's a pervasive bug the runs right through every aspect of Inventor.

Way past time to fix it Autodesk!

[Gabriel_Watson]

Yeah I gotta agree this is one of the bugs that make me think of switching to Solidworks. All other bugs seem more avoidable or have some kind of workaround. This one just adds a 1% overhead time in engineering, which might be very costly.

[Anonymous]

It's more than 1% for us, especially when we have to always re-run our analysis every time we open it.

Also one has to count the many hours trying all the suggested workarounds only to find that they may work in one case but not another.

[ust25238]

this should be real easy, If the file is marked read only ignore the dirty state at check in or save.

[bradeneuropeArthur]

Impossible to check I'm dirty files.
Do not know how you are checking in files that are dirty. On the second hand this is really an unsure situation or solution.because files are different than they are meant to be, when saving them. This is not a stable and a good solution in a release process.

[DanSingleton]

Infuriating when it does this for locked, released parts. We've set it to read only on purpose... O_o

[Anonymous]

Agree THIS ISSUE should be TOP priority!

There is many other flaws in the Inventor / Vault combination but THIS issue

cost customers probably the most.

Money and time wasted because a software vendor can't coordinate 2 suppose

to work together products. As far as I've investigated I think the flaw is mostly

on the Inventor side. The "dirty" flagg is set at almost any action.

I understand that this is a difficult issue but it should be at least be looked into!

If no fix is possible some good advice/documentation of how to get out of

a "locked" situation should be provided.

[Curtis_Waguespack]

Another related link:

http://forums.autodesk.com/t5/inventor-forum/inventor-causes-dirty-file/m-p/6823265/highlight/false#...

[n.schotten]

My mayor problem with the dirty files is with iassemblies, especially in the library folder.

I have several iasm's that work with table-replace iparts (UFL bearing housings and it's bearing are 2 iparts sitting in an iasm with table replace).

Often when working with an asm with these bearings in them I can't check the asm in because files need saving (that don't get saved when saving) turns out it's the bearing iasm and it's children, the ipart masters.

I need to check them out, force them to save and then i can check every thing in. Doing this raises the version number. And i can imagine it could be troublesome when using revision's (in vault pro/workgroups).

It is a mayor pain in the butt.