Looping throw BOM loops indefinitely?

[mslosar]

I'm working with 2023.2.1 using the steps from the API on looping through a BOM. It's a c# conversion of "Using the BOM APIs API Sample".  For excerpt, i've named the function GetPartsListToExport. The excerpt below is what i'm using in place of the orginal "Call QueryBOMRowProperties(oBOMView.BOMRows, ItemTab)" line.  

if a checkbox is checked, dive into and go through the sub assembly.

if (checkBoxSelectAll.Checked)
                    {
                        //if the subassembly has children (if the bom isn't empty) proceed
                        if (aBomRow.ChildRows != null)
                        {
                            AssemblyDocument sDoc = (AssemblyDocument)brDef.Document;

                            if (sDoc.IsModifiable)
                            {
                                //open the assembly
                                Globals._InvApp.Documents.Open(sDoc.FullFileName);
                                //run through the parts list again
                                GetPartsListToExport();
                                //when done processing file, close it
                                sDoc.Close(true);
                            }
                        }
                    }

And that works fine as is, no functional issues whatsover.

Something always bugged me about it, though. That being it opens the sub-assembly on the screen when you run it. I found that annoying and figured i'd get rid of it.

So, i changed this line:

Globals._InvApp.Documents.Open(sDoc.FullFileName);

to 

Globals._InvApp.Documents.Open(sDoc.FullFileName, false);

That should open the sub quietly in the background so no one sees it. Well, it sort of did, but it just kept looping on the first part over and over. Tried it several times with the same result. Removing false returns it to work fine. 

So, why in the world does doing it invisibly cause it to loop?

[WCrihfield]

Hi @mslosar. I am not sure about the endless looping problem, but...

Generally speaking, any document references you would find within an assemblies BOM, will already be either 'initialized' or fully open, but not necessarily visibly open.  Initialized just means that it has been loaded into Inventor's session memory, and is 'almost' open, and any thing you might to do that Document by code will cause it to be fully opened (not necessarily visibly) automatically.  There may be exceptions though, such as when all components in your assembly that reference that one model document are currently suppressed, then that Document will be unloaded from the session memory, to conserve resources and help improve performance.  So, you may not need to 'open' that document at all, because it is likely already open.  Any time you open any assembly or drawing, it loads all of their referenced documents into Inventor's session memory in the background, and you will see the numbers in the status bar at the lower right corner of your Inventor screen go up to reflect that.  Just in case you did not already know.

[nedeljko.sovljanski]

hi @mslosar , In original code method QueryBOMRowProperties is recursive and send two objects. How do you achieve recursivity in your code?

[mslosar]

I get that, i'm not against opening them, i just don't want them displayed on the screen - i want it to look transparent to the user.

The full code is going through an assembly and on down and identifying what parts need DXFs, which need SATs, and which need STPs then exporting them.

First step is it identifies those parts and displays them in the dialog so the use can select which parts they want to export. That's where this occurs, you tell it to get the list of files and once it hits the first subassembly, it gets caught in a loop - but only if the false option is on. That's what makes no sense to me, why should it matter if it's visible? using the implied 'true' it works just as you'd expect. False, is causing unintended issues here.

[WCrihfield · Accepted solution]

OK.  It is a little difficult to judge without seeing the full code, and full design intent.  Plus I am not super good with C# either.  But that little added information gave me an idea.  The 'other' main difference between those two ways of opening a document, is that the True/Visible version will usually cause that document to become the 'active' document, because it 'activates' that document.  When specifying False, it does not cause that document to be 'activated', so it works a bit differently.  With that in mind, every Document type object has a method called Activate.  I wander if you could simply use that instead of the Open method to achieve the same functionality.  But generally, when you 'activate' any document, that document will visibly show on your screen, so not ideal.  Maybe the custom method you are calling there to repeat could have its definition customized a bit, to allow it to accept an 'Optional' input Document reference.  Then pass the sub assembly directly into that method when you call it again, so it knows to focus its attention on that document, instead of the previously 'active' document.  Just some thoughts.

[mslosar · Accepted solution]

I think I might have missed part of the point of your first post.  

Turns out GetPartsListToExport() was using 'ActiveEditDocument'. So, upon setting the open flag to false, apparently the parent assembly maintained the ActiveEditDocument state so it get going back to he first part over and over as a result.

I changed GetPartsListToExport() to GetPartsListToExport(string assemblyName) and passed off the assembly name in the excerpt in the OP as well as getting the ActiveDocument elswhere as the starting point and that seems to have it working as expected.

I just wasn't expecting visible = false to not change the ActiveEditDocument. One of the hazards of really long code i guess, out of sight, out of mind 🙂