Way to get specific textbox item by prompted entry?

[lroberts8VWSJ]

Instead of iterating through all the textboxes in the titleblock for a sheet and getting the prompted entry of the drawing number, is there a way that I can do something akin to

dim shtTb as TitleBlock = sheet.titleblock

dim shtTbTextboxes as TextBoxes = shtTb.Definition.Sketch.Textboxes

dim dwgNumBox as TextBox = shtTbTextboxes.Item("DrawingNumber")

dim dwgNum as String = shtTb.GetResultText(dwgNumBox)

A collection that only contains textboxes with prompted entries would at least narrow it down quite a bit for the iteration, but preferably I'd like to get to it by specifying the prompt. It would speed up our setting the prompted entry with tools as well.

Inventor 2022, VB.net

[A.Acheson]

Here is a post that searches the titleblock for a text box containing prompted entry. I haven't tested it but it looks correct. 

[lroberts8VWSJ]

No, that's doing the iteration over the collection I'm specifically trying to avoid. The For Each or For i=... loop means that if the prompted entry happens to be later in the collection, and there are a lot of textboxes for whatever reason (and there are), that you're running a test repeatedly on things you don't want. I don't think there is, but I'm hoping I can find a way that more directly accesses the textbox than the snippet from your suggestion below.

For Each oTextBox In oTitleBlockDef.Sketch.TextBoxes
       If GetPromptField(oTextBox.FormattedText) = "<Part Name>" Then
            bFound = True
            Exit For

      End if

Next

[WCrihfield · Accepted solution]

Hi @lroberts8VWSJ.  The DrawingSketch.TextBoxes collection and its Item() property only allow Integer/Long type index specification, not Object (String) index, so you would not be able to use the Item property directly the first time around to specify exactly which TextBox you wanted, unless you have already investigated which TextBox Index items are for what purpose.  If you want to avoid iterating over all TextBox items in the collection many times, you would have to somehow record which ones are for what in the first iteration, then use that recording to access the specific ones you want from that point on.  But since TextBox objects don't have a Name, you would have to use other means to identify which ones are for what, in order to identify them.  One thing you can do is use the TextBox.AttributeSets to assign each one an Attribute you can look-up in the future with the AttributeManager's tools.  Similar to how you name Face, Edge, Vertex objects in a Part model environment, but there will not be a user interface tool for assigning those names in this case.

[lroberts8VWSJ]

So with the AttributeSets option I'd be looking for the attribute first, then if that's not found I would do the traversal and assign the attribute for later if I found it that way. Over time more drawings would have the attribute and would therefore not require iteration? That sounds like an excellent thing to explore, particularly since the majority of the textboxes are static, and we use a select few so often. Thank you!

[WCrihfield]

Yes. Sort of.  I don't know how many drawing templates you have or how many different title block definitions you use but you could go through the title block definition(s) you use regularly in your template drawing(s), figure out which text boxes are for what, assign an attribute to the ones you have identified, so that you can easily find them again and know what they are in the future.  Then since the title blocks you place on your sheets are just placed instances of the title block definition, you should always be able to find the text boxes you are looking for in all new drawings.  In older/existing drawings you can do a replace title block definition routine that will source the title block definition to use from the template, which will have the attributes in it.  The AttributeSet object has a property called CopyWithOwner that you will likely want to True, so that copies of the title block definition will retain the attributes to the copies.  And yes, if using a code that not only looks for the existing attributes, but will also assign attributes if not found, would also eventually build-up those attributes within your older/existing drawings, if you want to go that route.

Also...don't forget about using the AttributeManager, and its tools.  That may save you a lot of time in finding existing AttributeSets, Attributes, and the TextBox objects they are attached to.

[lroberts8VWSJ]

My primary problem is that I'm unable to change the titleblock definition for older units, as the tool may be running on a drawing that's already been released and is just going through a revision process for a spare parts order. We've been using Inventor for over a decade, and particularly drawings from the beginning are very different than what we use today. We have a wide array of equipment and drawing types that require different titleblocks or sheet formats, and some of our customers also require us to use a variant of their own. I'd say there are probably a little over 50 titleblocks out there with unique names and setups, and some of the more recent titleblock names have changed definition a few times even within the last year or two.

On top of that my program may be working on a drawing set with over 100 drawings, with various titleblocks depending on what that particular one is supposed to be showing, like foundations, lifting plans, electrical information, or whether the drawing is for the customer or fabrication.

Using something like an attribute that's invisible to the PDF of the print is actually quite a valuable solution. I may end up having questions as I've never used attributes or attribute sets in my code beyond iProperties, but I'll give it a shot before asking further. Thanks again!

[WCrihfield]

I sort of understand that situation. We also have around 10 years worth of Inventor documents, so there are a variety of page sizes, borders, & title blocks, but luckily we have far fewer variations to deal with, and only stuff we designed ourselves. And similarly, the stuff we make drawings for it pretty dynamic too, so most drawing automation efforts are somewhat limited in scope/use, or even futile.

Like many design automation solutions, there is often a significant upfront cost of time & frustration in preparing things to suit your needs effectively and efficiently, but the end result is usually worth the effort. However, in situations where the end result of an automation solution would need to be extremely dynamic, you have to make the difficult decision whether it will be worth the investment or not. And that is often very hard to judge early on, when you are just learning the basics of things like iLogic, Inventor's API, VBA, VB.NET. But every little bit helps in the long run, and the more you know about automation the easier it becomes to judge whether or not it A) can be done B) about how difficult it may be to achieve.

Here is another similar routine that may give you some ideas, that looks like it might be useful to you.

Dim oDDoc As DrawingDocument = ThisDrawing.Document
Dim oSheet As Inventor.Sheet = oDDoc.ActiveSheet
Dim oTB As TitleBlock = oSheet.TitleBlock
Dim oTBDef As TitleBlockDefinition = oTB.Definition
Dim oSketch As DrawingSketch
oTBDef.Edit(oSketch)
'prepare a variable to hold all the TextBox objects that are for Prompted Entries
Dim oPromptTBoxes As List(Of Inventor.TextBox)
'set its value(s) with a compact, yet specific filter
oPromptTBoxes = oSketch.TextBoxes.OfType(Of Inventor.TextBox).Where(Function(tb) tb.FormattedText.Contains("</Prompt>")).ToList
For Each oTBox In oPromptTBoxes
	oFText = oTBox.FormattedText
	'get part of text, after the opening Prompt XML tag
	oAfterPromptTag = oFText.Split("<Prompt>", 2)(1)
	'now get the remaining text before the closing Prompt XML tag
	'(should be the text you see that explains what you should enter here)
	oPrompt = oAfterPromptTag.Split("</Prompt>", 2)(0)
	'get the current value of this Promted Entry
	oCurrentValue = oTB.GetResultText(oTBox)
	'prompt user to enter a new value, while offering current value as default
	oNewValue = InputBox(oPrompt, oPrompt, oCurrentValue)
	'set new value to the TitleBlock's Prompted Entry for that TextBox
	oTB.SetPromptResultText(oTBox, oNewValue)
Next
oTBDef.ExitEdit(True) 'True = save changes
oDDoc.Update

[lroberts8VWSJ]

Yeah we have a rather large suite of in-house tools to automate all kinds of things. Currently everything to do with the drawing number prompted text (which is the primary one filled in by tools) uses the normal iteration through the textboxes collection to find it. I'm in the process of a pretty large update to all of our drawing-related tools, and the fact this process required an iteration when so little else does made me wonder if there was a better way. I definitely had never thought of the .OfType.Where(Function .contains()).ToList construction, but doesn't that effectively do an iteration of its own in the backend?

[WCrihfield]

In a way, I'm guessing yes, but for some reason I have found that this way usually processes much quicker, and more efficiently.  It's just an up front quick filter, and you will probably only notice a difference if there are otherwise a ton of stuff to loop through.  It still leaves you with an iteration to do afterwords, though.  Just putting some ideas out there.  As I said, sometimes every little bit can help.

[maxim.teleguz]

-