Drawing HoleThreadNote Formatted Text Bug Precision and Tolerance when not set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I have found myself delving into processing HoleTheadNotes. However it is proving quite frustrating due to an inherit bug in the way the API is returning the FormattedHoleThreadNote text. (And the way inventor processes xml, but that is anothe story)
There have been a few posts over the years about a bug where accessing the HoleThreadNote.FormattedHoleThreadNote has some weird precision and tolerance data even if this data is unset.
Here are a few posts talking about it - there is even an old bug filed in one these.
https://forums.autodesk.com/t5/inventor-programming-ilogic/modify-holethreadnotes/m-p/6474972
For testing, I have code that simply sets hole formatted text to itself... The expected behavior is that nothing happens. But in specific situations, the precisions and tolerances change on it.
For my use (Inventor 2025.2.1) I have narrowed down the issue to only counter bores and counter sinks - the type of hole does not matter (blind, thru, threaded, etc.) Simply the prescence of the <CBDIA> or <CSDIA> parameters in the note GUI will cause this issue even if the underlying hole does not have the feature(s).
I think this bug has been partially fixed a few times since in some of the above posts, it was happening for more parameters than just the two I've mentioned?
For counterbores or countersinks I expect the formatted text to say this
<HoleProperty HolePropertyID='kCBoreDiameterHoleProperty'
SetTolerances='False'/>but this is incorrectly returned instead
<HoleProperty HolePropertyID='kCBoreDiameterHoleProperty'
Precision='2'
AlternatePrecision='2'
UpperTolerance='0.000000'
LowerTolerance='0.000000'
ToleranceType='kSymmetricTolerance'
TolerancePrecision='2'
ToleranceAlternatePrecision='3'/>Essentially the when reading the hole property, the api believes Use Global Precision is unchecked, and the feature tolerance is checked even though they are not.
If I programamtically set the FormattedHoleThreadText to
<HoleProperty HolePropertyID='kCSinkDiameterHoleProperty'
SetTolerances='False'/>It correctly sets the precision with no tolerance, but accessing the formatted text again returns the incorrect attributes like before.
From what i can tell, if the user has manually input a tolerance, or unchecked use global precision, it does not override the user's values. It is only an issue when either is unset.
There seems to be a disconnect between how the API is reading the hole note and how it actually is.
The way the holethreadnote determines whether Use Global Precision is checked or not is determined if any of the HoleProperties have custom precision, then they all will be set when re-setting the formatted text via API. This is why the precision changes for all values when setting the Formatted Text to itself.
I have attached a sample part and drawing with an ilogic sample that takes the selected Hole Note and sets its value to itself. Holes with <CBDIA> and <CSDIA> change. Other holes do not change from what I can tell.
What does this mean for me today?
I have been writing methods to take any formatted note and convert it to a single line while retaining symbols, spacing, etc. Just accessing the note.Text for a note puts everything on a single line, but it does not add spaces, and it does not handle the AIGDT font. I have been successful in converting general notes, dimension text, view labels, and feature control frame text. But for hole notes, because of this bug, its going to be a lot harder... I think I will have to set the hole note formatted text to one parameter at a time and check the note.Text values and swap them into the formatted text or something...
