Incorrect iProperty Value Getting Automatically Copied From Model To Drawing

Incorrect iProperty Value Getting Automatically Copied From Model To Drawing

WCrihfield
Mentor Mentor
404 Views
4 Replies
Message 1 of 5

Incorrect iProperty Value Getting Automatically Copied From Model To Drawing

WCrihfield
Mentor
Mentor

Hi folks.  I have an odd situation happening that I think may be a bug in 'the system'.  The Part Number being shown in the title block of my drawing is incorrect, and I can't figure out why.  That TextBox in my title block is linked to the Part Number iProperty of the drawing itself.  It has been that way for years, so the problem isn't there.  The drawing's Part Number iProperty gets copied over from 'the model' automatically when I place the first view of 'the model' in the drawing.  That is done by the settings within the Document Properties > Drawing tab > Copy Model iProperty Settings....  In that 'Copy Model iProperty Settings' dialog box, I have the Part Number iProperty checked (and several other 'standard' iProperties too).  Those settings have been mostly the same for years too (no recent changes).  However, that system has been copying an incorrect value from the model to the drawing, for some reason.  The value it is copying is what I would describe as an older version of the property's value, not its current value.  When I look at the iProperties dialog of the model, I see the correct value shown though.  I can even click the 'Update Copied Properties' button (Manage tab > Update panel), but that still does not copy the correct value over to the drawing, for some reason.  I can even save the model document again, then go back to the drawing and click that button, and it still does not copy the correct value.  However, I can go into the iProperties dialog of the model, place my cursor at the end of the Part Number's current value, hit the space bar on my keyboard, then backspace, then click OK on that dialog, and then suddently, with no other interactions, I can now copy the correct value from the model to the drawing.  That is why I think this is a bug of some sort.  I am currently using Inventor Professional 2022.3.1.

 

When this problem occurs, the process starts with me generating a new part using a part configuration template.  When I click new and select that template, a form pops-up asking me to choose specifications & sizes, then some iLogic rules run to change the model according to the specifications.  One of those rules fills in appropriate iProperty values, but does not mess with the Part Number iProperty.  Then I click the Save button, which acts like SaveAs for the initial save.  I specify a location and name and save it.  Generally when you initially save a document, it automatically fills in the Part Number iProperty with the new file name, which I like, and it does in this situation too, and I do not usually mess with it afterwords.  Immediately after saving the model, I can open the iProperties dialog, and see the new file name as the value of the Part Number iProperty, as expected.  However, that is not the value being copied to the drawing when I create a new drawing for the model.  It is copying the previous value of the Part Number, which is the file name of the template, instead of the current value.  What is going on here?  Is this a bug?  How do I fix this situation...the proper way?  I have VBA/iLogic tools which can easily compare/copy iProperties back and forth between drawing and model, but that is not a fix in my opinion.  Something is fundamentally wrong here, because this shouldn't be happening.

 

PS.  All the other iProperties are getting copied over from the model to the drawing just fine, with correct values.  It's just the Part Number iProperty copying an old/incorrect value.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
405 Views
4 Replies
Replies (4)
Message 2 of 5

JelteDeJong
Mentor
Mentor

Just a quick thought. I could only reproduce the problem if I used a model with 2 model states. The part number copied is always from the "Master" model state. That is the only thing I could think of...

Jelte de Jong
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


Blog: hjalte.nl - github.com

Message 3 of 5

dalton98
Collaborator
Collaborator

Only similar thing I can think of is when you save a file without a part number, inventor automatically sets the part number to the file name. I remember seeing somewhere this feature can be turned off, but didnt look into it any further.

 

Edit: you said this...

0 Likes
Message 4 of 5

WCrihfield
Mentor
Mentor

Thanks for the input @JelteDeJong.  This sounds promising.  My part does have 1 custom ModelState, and sometimes it varies whether the original or the custom one is active when the part gets saved initially.  This could be the detail I was overlooking.  I will look into it today.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
Message 5 of 5

WCrihfield
Mentor
Mentor

Unfortunately, the multiple ModelState idea does not seem to be the source of the problem.  Not only does the part remain set to the original 'Master' ModelState throughout the whole process, but the other ModelState does not contain a different value from the Master one.  When I start the new part by clicking the New button in the quick access toolbar, then choose then either double click the template, or select the template and click the Create button, that new part does not appear to have any 'visible' value in its Part Number iProperty, for either of its 2 total ModelStates, when looking at the iProperties dialog.  Also, when looking at the iProperties dialog at this stage (before initial save), I can see that the Title & Description are blue when the custom ModelState is active, letting me know that they are custom values, or under the influence of a ModelState.  When the Master ModelState is active, those two values are the normal black color.  But neither are showing a value for Part Number.  Then after I save the part initially, that appears to automatically fill in the Part Number with the file name I just specified in the Save screen (without file path or file extension), as expected.  I can even click the Save button multiple times after this point, and doing so does not appear to cause the 'hidden/old' value to be flushed from memory, because if I create a drawing of the part at this point, the Part Number in the drawing shows the file name of the template that was used to create the part.  This is very baffling, because according to my observations, the Part Number has already had two other values since that value (empty and new file name).  I can even go back to the part document and edit other standard iProperty values within the iProperties dialog, then click Save on the part, then go back to the drawing and click the 'Update Copied Properties' button, and it will not update the shown Part Number to the correct value yet.

 

Only certain invasive actions I have found so far, taken on the model side, will cause the old cached value to finally be flushed from the background somewhere, and cause the drawing to be able to retrieve the correct value.  The one action I mentioned in my first post, where I actually edit that Part Number value in the iProperties dialog of the Part, will cause this update to happen, but not editing other standard iProperties.  Also even though the Part does not seem to need any updating (both the 'Local Update' & 'Global Update' buttons are greyed out), if I click the 'Rebuild All' button, this somehow causes that hidden cached value to be flushed out so that clicking the update iProperties button finally works on the drawing side.  I even tried using the Update Mass button on the model side, but that does not cause the hidden update to happen. 🤔

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes