VBA Rebuild All

[e_frissell]

Hi guys, I was wondering if anyone might be able to help explain the difference between the VBA rebuild and rebuild2?  I currently run a script that I tie to ctrl+s that's basically rebuild and save using the VBA rebuild method and when I wrote this script it looked like if it was ran from an assembly it would update all the components in that assembly.  Unfortunately it seems I misunderstood the rebuild command because last week there were some sub-assemblies that were loaded in a main assembly without the latest changes from the sub-asssembly being reflected in the main assembly but the sub-assembly, when opened, showed parts correctly constrained.  I'm thinking my rebuild and save script may need an accompanying script that does a more thorough job of ensuring each sub-assembly gets rebuilt.  I've looked at Rebuild and Rebuild2 and from what I gather they pretty much function the same way except Rebuild2 has some small error handling?  If that's the case would something that iterates through the assembly, all sub-assemblies, and all parts to ensure everything is up to date essentially need to loop through all the referenced components and run a rebuild?  Just a bit irritated that I lost about an hour and a half and some hair over the part where the sub-assembly constraints were right in the sub-assembly but wrong in the main assembly and the rebuild and save script I run didn't get things to change, then happened again on some hole locations and missing cut-outs this morning

The script I'm running for reference

Public Sub RebuildAndSave()
    On Error GoTo GetOut
    ThisApplication.ActiveDocument.Update2
    ThisApplication.ActiveDocument.Rebuild2
    ThisApplication.ActiveDocument.Save2
    
GetOut:
End Sub

Sub Rebuild()
Member of Inventor.Document
Performs compute operations on all of the entities within this Document's scope as if all of the driving entities had been 'dirtied'

Function Rebuild2([AcceptErrorsAndContinue As Boolean = True]) As Boolean
Member of Inventor.Document
Method that performs compute operations on all of the entities within this Document's scope as if all of the driving entities had been 'dirtied', returns False if any errors are encountered during the rebuild

[WCrihfield]

Hi @e_frissell.  This may be because of ModelStates.  If the lower level model document had more than just the one original ModelState, then the changes at that level may have been recorded by a different ModelState than what the assembly component in the assembly is set to.  Or, the sub assembly that the lower level sub assembly/part was put into as a component, may have more than one ModelState, and the ModelState of the component was set differently in one sub assembly level ModelState vs the other.  This can be difficult to weed out.  ModelStates need to be set-up from lowest level to next level, to highest level, in that order, or top level stuff may not be seeing the lowest level stuff properly.

Below are just links to the online help documentation pages for the 2 update methods, and 2 rebuild methods, for others to reference.

Document.Update 

Document.Update2 

Document.Rebuild 

Document.Rebuild2 

[e_frissell]

Thanks, I'll take a look and as always I really appreciate your help and been feeling a bit guilty that I haven't been great about getting back to you - been having a lot of 10~20 hour projects recently which has me trying to figure out iLogic solutions to small problems and then encountering something totally different 2 days later.

Regarding the model states you are right that model states were involved however I'm positive the constraints were equal - they were a pair of doors and the constraint was set by the distance between a right and left side hinge, then again with a symmetric constraint across one of the planes.  What happened was that in the main assembly distance from one hinge to the symmetry plane was different than the other side although in the sub-assembly it was correct. The fix for this was that I added 1" to the distance between the hinges, then removed that inch, and it was enough for the main assembly to note the sub-assembly had changed and it fixed it.

Anyways, going through that documentation, each states that it does a compute operation on "all entities within the Document's scope" - would the entities of a sub-assembly be considered a "entity" of the parent document?  If yes it seems rebuild would force everything to update, if no then it seems like a loop would be required?

From looking at my script again running update2 and rebuild2 in consecutive lines might be a bit redundant

[WCrihfield]

Don't worry much about getting back to anyone in a timely manner.  Most of us are likely busy at work while on these forums, which is a dynamic scenario.  Multi-tasking is pretty much a must these days.  Got 2-3 longer term projects going on, and multiple shorter term projects going on, then have forum open on separate screen while all that is going on.  Seems like getting busier with time, instead of more free time, so slowing down on forums to keep up with increasing work load & increasing responsibilities. 

The only thing the main assembly document knows about any other documents is that they are being referenced, and after checking, if they are 'dirty', and/or need to be updated.  Main assembly does not know about details within referenced documents.  I am not sure how their (Autodesk) system works for checking if updates to referenced documents is needed or not.  Document.Dirty status is understandable, but not sure about knowing when updates to referenced documents may be required.  There is a Document.RequiresUpdate property, but I am not 100% sure how/when its value gets changed, since it is ReadOnly.  I do know that if all you did was view related stuff, that does not dirty the document, and does not change the RequiresUpdate status, unless those changes were the type that gets recorded by DVR's (DesignViewRepresentation), like visibility / appearance changes.

When using Update, similar to using regular Save, it might not actually do anything, if it does not believe that it is necessary.  It seems like Rebuild though, is supposed to 'do' something, even if it things that it may not be necessary.  But even then, I would imagine many of the same things get checked.  For example, I would assume that if a document is not Dirty, it will not go any deeper into it, but if Dirty is true, then check RequiresUpdate, then only if True, go further and update.  I can not possibly know why some things in someone else's large assembly are getting updated and some are not, but it sounds like the software is not picking up a change somewhere, so it is not getting reported in a way that would change one of those flags.  May need to ask Autodesk tech support about it, not sure.  Hopefully others have encountered the same thing and have a readily available explanation and solution.  I know I have encountered similar situations before, but do not recall doing anything super special by code to fix it.  My next step would be recursive iteration with Rebuild, but that can cause extremely long processing time in large assemblies.