Show part number and description in tree

[xavi.saus]

Hello everybody

I am struggling trying to use a rule to show both part number and description on the tree.  I used this code I found on the forum:

'create reference to part
openDoc = ThisApplication.ActiveDocument
 
'format display name
openDoc.DisplayName = iProperties.Value("Project", "Part Number") & " (" & iProperties.Value("Project", "Description") & ")"
openDoc.Rebuild
 
'update
iLogicVb.UpdateWhenDone = True

But every time I make a save aand replace, it keeps old name and description, and I need to open the part from the assembly and save it again. Inventor also shows errors when using this rule.

Also, what would be the best option to trigger the desired rule? After saving, when changes on the iproperties...

[Jonnox]

Hi @WCrihfield,

Thanks for the updated code, I have run some more tests on it and have the following comments.

I again created a top-level assembly which contained one sub assembly and one part. Within the sub assembly it had two parts.

When I ran the code on the top level (assembly 2.iam) it returns this error.

The sub assembly (assembly 1) updated with the information, just not the part (Part 1). Code ran with representation set to Master, Master, Master.

So, I thought I would suppress "Part 1" and run the code again. This time it worked as required! Whoop!

I ran the code like this with various Representation configurations and it all work perfectly!

The only thing was the repeat of the "Model State1" we have discussed. I did what you suggested with the show extended names, but it doesn't make a difference.

After a few tests, the model state always shows (if not master) and updates automatically. 

So, I think maybe its best if your code doesn't control the displaying of the model state, as inventor already does it.

One other thing, is there a way of overwriting the text from the when the code was previous ran (maybe even run "rename browser nodes" set to "default" before it runs your code?).

As I want to set this to trigger when people save the document. So, it'll end up with lots of text after a few saves -

This is the main reason wht I only want it to change the tree on that level, as it will be running alot and dont want to delay the saving process.

I opened the sub assembly "Assembly 1" and ran the code. An error occurred like the one above but just on line 19 this time, but nothing was changed or added to the parts text in the assembly model tree.

So, it's something to do with parts within an assembly, as assemblies in assemblies' work.

Hope this all makes sense, thank you for your work so far, this is going to be great in the end!

Best Regards

Jonnox

[WCrihfield]

The 'More Info' tab of the error message showed what I needed to see.  The error is happening when it 'getting' the value of the ComponentOccurrence.ActivePositionalRepresentation property.  I don't know why I didn't think of this earlier, but parts do not have positional representations...only assemblies do.  Both parts and assemblies have ModelStates and view representations.  That's why it is throwing an error when it encounters components that represent parts.  The ComponentOccurrence object has properties for all of those, but not all source models have properties for them to pull that data from, leading to errors like that.  To eliminate that error, and let the code continue, I will just put that data request within another Try...Catch...End Try statement.

I will also eliminate capturing the ModelState name, and eliminate attempting to add that into the component's name, since I do not recall if there is a way to eliminate it automatically getting included anyways.

I am not 100% sure what is causing the same data to stack-up in the component name when ran multiple times.  However, I do have a suspect.  I think it may be where I am attempting to get the original 'Index' from the component's name.  By default, every component is named like the source model's file name (without file extension), then it has a colon character (:), followed by an Integer, as its index, to keep the names of multiple instances of the same source model unique.  That line of code is attempting to capture the portion of the component's original name that is just after its last colon character, expecting it to just be a simple Integer, not a whole bunch of custom stuff.  My code was not preserving the colon character though either, which was a mistake on my part.  Since this is a very unique and custom situation, we may need to forget about the original/previous index of each component, and come up with a way to use a new indexing system, because we still need there to be an index system, to keep their names unique when there are multiple instances of the same source model.  An idea that comes to mind is using a two-factor collection, like a Dictionary, to keep track of each 'source document' FullFileName, and the Index of the last one, as we iterate though the components.  If we have not encountered a source document before, then the index for that first component referencing it should start at one.  If we have encountered other component occurrences referencing that source document before, then we get the index of the last one we encountered, add one for the current instance's index, then record the new index value for next time.

I am not sure if you ever use the iLogic Log window, or the iLogic Logger resource, but I highly recommend doing so.  In order for an iLogic rule to be able to write entries into the iLogic Log window, the tab for that iLogic Log window must be 'visible' (not necessarily the active tab though), before you run any iLogic rules that may be trying to write something to it with the Logger lines of code.  Then, when the rule is done, you can click on that iLogic Log tab, to see what entries (if any) the rule may have written to it.  There are lots of reasons why you may want to use that Logger resource, but 'debugging', providing progress feedback, and key pieces of information that the rule encounters along the way, are three of the most popular reasons.  It became available in the 2019 version of Inventor, and I have been heavily using it ever since, because it has been super useful.

When setting the name of a component by code, if the new name you are trying to set is already being used, it will throw an error.  This is one reason why renaming components, or even attempting to 'reset' component names, can be complicated.  Normally, 'resetting' their names to their 'default' would be done by iterating through them, and set their names to an 'empty' String, which causes it to automatically adapt its 'default' name.  But even doing that can cause an error for the same reasons.  I do not know of a way to instantaneously rename all occurrences at the exact same time by code, so that user interface tool can really help for that purpose, and there is no Inventor API or iLogic API equivalent to that tool.  One strategy is to use a completely unique 'base name' for all components, and add an Integer type index to the end for each one, to rename all of them a first time, then go back a second time and rename all of them to 'empty' strings, to reset them.

This time, I will attach the updated code as a text file, since it is getting pretty long.  Makes it quicker & easier for others to read through the discussion later.

[Jonnox]

Hi @WCrihfield ,

Sorry about the late reply, as said I have now upgraded (and everyone else) to Autodesk 2025 products, took longer than I had thought.

The code you gave me is excellent! Does everything I want it too!!!!

It adds the description of the parts, after the filename and will also add the view & positional rep (if they are not "primary"). Model states then add onto the end if not "primary".

I managed to get spaces in front of the description to separate it a little, also managed to move the index number just after the filename. Feel like a coder now 🤣🤣🤣🤣.

If I take it a level higher, it works as expected, i.e.  it also adds the position representation of an assembly (if not primary).

I have set it to trigger the ilogic to "before save", it’s also now overwriting the previous text. So, all working great!

I have attached the edited file for others to use in the future (or you could check it), if they find it useful.....................

So, as it stands this works exactly as intended, thank you so much for your hard work on this!

Best Regards

Jonnox