Hi @drafting4KGWTN. Is that a true Inventor.RevisionTable type object in the image, or is it custom geometry that was created within the sketch of the TitleBlockDefinition, with individual TextBoxes placed within its geometry for the needed data? If it is custom geometry with a bunch of individual TextBoxes added in, then the primary challenge here would be to determine which specific TextBox object is for which specific piece of data. Is every piece of text in that image a prompted entry? If so, then when you attempt to manually fill in their values right now, what do the prompts in that dialog look like?...and how can you tell which ones are which within that dialog? The names of the prompts may be different than what is actually showing in that image, and if so, we may need to know those prompt names, and may need to list them within the code somewhere if we will be checking for them. We may need to create something like a Dictionary(Of String, String) or NameValueMap within the code, so that we can fill in all the prompt names, paired with the values that we want to set for them. Then as the code iterates through them, it can check each one against the specified prompt names to find just the ones you are interested in, and when that happens, fill in its value with the value specified for that prompt name in the Dictionary or NameValueMap.
Since TextBox objects do not have 'names', we must rely on the values of a few of its properties to help us identify them. When the TextBox is not for a prompted entry, and does not contain any 'Linked' type value, then the TextBox.Text property's value will simply contain the exact contents of the TextBox. But when it is for a prompted entry, or 'Linked' data, then the TextBox.Text property's value may be what you see in the Format Text dialog box, instead of the actual data that may be showing within that TextBox when not editing its definition. So, in those cases, we must either be familiar with what that looks like in the Format Text dialog, or be familiar with what the FormattedText will contain (also usually not what you will see in the TextBox when not editing its definition). In the most basic and simple scenarios, like when the TextBox only contains simple typed in text, with no special formatting, no prompted entry, and no 'Linked' data, then both the TextBox.Text property and the TextBox.FormattedText properties will both contain the same contents, which will just be that typed in text...but that is the only situation when that will be the case.
I mentioned that the TextBox object does not have a 'Name' type property, but there is actually another way that we can assign a name or unique identifier to each of them, with some extra preparation effort and with come additional code based help. This can be done starting from the TextBox.AttributeSets property. That AttributeSets collection object that you get from that property will normally not contain any actual AttributeSet objects at first, so we would have to create one using its AttributeSets.Add method, which asks us to assign it a name when we create it. But that is not where we will assign the name for this TextBox, just a name for the collection of similar assigned names (like "Revision Table Prompted Entries Set"). Then, we can use the AttributeSet.Add method to create an actual Attribute object in it. This is where we can set a name for the Attribute object itself (such as "Revision Table Prompted Entry"), and set its value type (ValueTypeEnum.kStringType), and finally set the name for the TextBox object as the value of this Attribute (such as "Rev #" or "Date #" or "Designer #", where # is replaced by row number, or something like that, to differentiate the one in one row from the same one in another row.
There is simply a lot to this sort of thing, and it is all very highly custom to just you, and that one TitleBlockDefinition's Sketch.
Maybe attaching one of your drawing files would help (not in a Zip file, because I can not download those), but I can not guarantee that I will be able to spend much time working on it, because I have a lot of my own stuff to get done where I work.
Wesley Crihfield

(Not an Autodesk Employee)