Custom iProperties not populating iProperties properly
So it sounds like this text parameter and custom iProperty are working OK or as expected in your model documents, but not working in your drawing documents...is that correct? How is this custom iProperty supposed to populate your drawing's title block? Is there a textbox within your title block definition's sketch that is linked to this custom iProperty in the model document? Is this custom iProperty supposed to be copied over to the drawing document, then the textbox in your title block is supposed to be linked to that local custom iProperty? Is this information somehow being filled in manually within the drawing's title block, like with Prompted Entry or regular text notes?
I may need more information about the specifics of this situation before I can offer a solution for it.
There are settings within the drawing's Document Settings > Drawing tab > Copy Model iProperty Settings..., that can be set-up in your drawing template so that you always copy certain standard iProperties over from a model document when you place its first view. However, this usually isn't going to be populated with any custom iProperties until after you have placed a model view into the drawing, so it isn't ideal for copying custom iProperties over. An external iLogic rule and/or a VBA macro with a button in the ribbon are what I would recommend for copying custom iProperties from the model document to the drawing document. I have a few examples of these types of rules/macros if that's what you think you need.
Wesley Crihfield
(Not an Autodesk Employee)
OK. So, if you're using an iLogic form, and that form has a drop-down list in it which is already populated with values for you to select from, that list of values is from the user parameter, not the custom iProperty. And when you select a value from the list in the form and click OK/Done, that sets the value of that user parameter. Then, if that user parameter is set to be exposed as a custom iProperty, the value of the custom iProperty will be updated when the user parameter's value is changed. (A parameter is set to be exposed as a custom iProperty when you check the checkbox for that parameter's row in the Parameters dialog box, in the "Export Parameter" column.) That update action only works in one direction though, as the parameters value is pushed to the custom iProperty when the parameter's value changes, but changing the custom iProperty's value won't update the value of the parameter. And unlike a multi-value user parameter, an iProperty can only hold one value at a time.
In your post you said that your title block is linked to the user parameter directly, instead of the custom iProperty, correct. If so, then what is the custom iProperty being used for. Does that user parameter exist within the drawing document, or just in the model document? If the user parameter is being copied from the model document to the drawing document, then the title block is linked to that user parameter on the drawing's side, then you may just need to implement a way to keep the drawing side user parameter up to date with the model. Same for the custom iProperty. If you are copying the custom iProperty from the model to the drawing, then your title block is linking to the custom iProperty on the drawing side, you may need to implement a way to keep the drawing's custom iProperty up to date with the model.
Here is a link to one of my contribution posts that shows you how to copy custom iProperties from a drawing's model document over to the drawing document by either iLogic rule or VBA macro.
I'm thinking that if your rule is creating the custom iProperty first, then creating and/or populating the user parameter after that, you may want to change that order of actions around, or even eliminate the part that creates the custom iProperty, and just set the parameter to be exposed as a custom iProperty, so it is created automatically (and kept up to date). If your rule is creating the user parameter, and you don't know how to set it as 'exposed' so it will create the custom user parameter, I can show you how to do that within your rule.
If this solved your problem, or answered your question, please click ACCEPT SOLUTION.
Or, if this helped you, please click (LIKE or KUDOS) 👍.
If you want and have time, I would appreciate your Vote(s) for My IDEAS 💡or you can Explore My CONTRIBUTIONS
Wesley Crihfield
(Not an Autodesk Employee)
Here is an example of how you can set-up the iLogic rule that creates the user parameter and exposes it as a custom iProperty. When set-up this way, the custom iProperty will be updated every time the user parameter's active value changes, but changing the custom iProperty's value manually won't change or update the active value of the user parameter.
Dim oDocType As DocumentTypeEnum = ThisApplication.ActiveDocumentType
Dim oUParams As UserParameters
If oDocType = DocumentTypeEnum.kPartDocumentObject Or _
oDocType = DocumentTypeEnum.kAssemblyDocumentObject Then
oUParams = ThisApplication.ActiveDocument.ComponentDefinition.Parameters.UserParameters
ElseIf oDocType = DocumentTypeEnum.kDrawingDocumentObject Then
oUParams = ThisDrawing.Document.Parameters.UserParameters
End If
Dim oUParam As UserParameter
Dim oName As String = "FINISH"
Dim oValues As New List(Of String)
oValues.Add("MILL")
oValues.Add("PAINTED")
oValues.Add("GALVANIZED")
oValues.Add("ANNODIZED")
'or
'oValues.AddRange({"MILL","PAINTED","GALVANIZED","ANNODIZED"})
Dim oExists As Boolean ' False by default
For Each oUParam In oUParams
If oUParam.Name = oName Then
oUParam.ExpressionList.SetExpressionList(oValues.ToArray)
oExists = True
End If
Next
If oExists = False Then
oUParam = oUParams.AddByValue(oName, oValues.Item(1), UnitsTypeEnum.kTextUnits)
oUParam.ExpressionList.SetExpressionList(oValues.ToArray)
'oUParam.Comment = "SELECT FROM LIST"
oUParam.IsKey = True
Try
'try to expose this parameter as a custom iProperty
oUParam.ExposedAsProperty = True
oCPF = oUParam.CustomPropertyFormat
oCPF.PropertyType = CustomPropertyTypeEnum.kTextPropertyType
oCPF.Units = ThisApplication.UnitsOfMeasure.GetStringFromType(UnitsTypeEnum.kTextUnits)
Catch
MsgBox("Couldn't expose this parameter as a 'custom' iProperty.",,"")
End Try
End If
'Output Parameters values from this rule to the Model. (Use this before Document Update)
RuleParametersOutput()
'Immediately update the current document.
iLogicVb.DocumentUpdate()
When dealing with text inside a title block sketch of a drawing template file, the options for linking to other stuff is more limited than usual. In this situation it seems you can't link to any Parameters, and only certain Properties. The Property options are "Properties - Model", "Properties - Drawing", "Custom Properties - Drawing", "Drawing Properties", "Sheet Properties", "Prompted Entry", "_Piping Style", "Physical Properties - Model", & "Sheet Metal Properties". The list doesn't include the one we need ("Custom Properties - Model"). That option usually only becomes available in situations like a leader note attached to a model edge in a drawings model view, where it has a clear reference to a model. So, in light of this situation, I believe the best option left is to use something like the above rule to copy the custom iProperty from the model document to the drawing document, then have your title block text linked to the "Custom Properties - Drawing", and that custom property within the drawing. This still isn't ideal, because the value of that custom iProperty within the drawing will need to be kept up-to-date somehow. To keep this value up to date, I'm thinking the best option may be to have an iLogic rule that will copy the model's custom iProperty value to the drawing. Then put that rule into your Event Triggers dialog (Manage tab > iLogic panel), under the "iProperty Change" event within the model document. Then every time the iProperties change in the model document, it will trigger the rule to run, which will push the value to the drawing. (Make sure the rule checks if the drawing document exists before it attempts to push the values to it, to avoid potential errors.) That rule, or another one like it, could also just be ran manually from the drawing, when you want to be sure it is up-to-date. I could also help you create that rule too if needed, but it would likely be pretty similar to the one I provided a link to in the earlier post.
If this solved your problem, or answered your question, please click ACCEPT SOLUTION.
Or, if this helped you, please click (LIKE or KUDOS) 👍.
If you want and have time, I would appreciate your Vote(s) for My IDEAS 💡or you can Explore My CONTRIBUTIONS
Wesley Crihfield
(Not an Autodesk Employee)
I thought so too when I first investigated, because I was just looking at a regular leader drawing note placed on a drawing, and looking at what it had available to be linked to, but that was a different situation than when your dealing with the text within the sketch for a title block definition of a drawing template file. If you are wanting to set this up within your drawing template file, it won't have a model document to pull custom iProperties from, and can't pull parameters from the model document either, but it can link to custom iProperties within the template document itself and that custom iProperty can already exist within the drawing template file if set-up that way.
And you would still need to keep the multi-value text type user parameter too, because it is being used by your iLogic Form to show you the available options and let you choose one. Therefore, setting that user parameter within the model file to be 'exposed' as a custom iProperty seems like the next best option. Then after you place your first model view into a new drawing, the drawing document will then have access to the model, and be able to copy the value of the model's custom iProperty over to itself, which will update the linked text in your title block. I have similar scenario's set up in some of my drawings too. I don't specifically have text within my title block linked to 'custom' iProperties, just regular iProperties and other related stuff. But I do sometimes have custom Sketch Symbols containing text linked to custom iProperties, and other standard drop-in text blocks I use in my drawings that are linked to custom iProperties. This usually works out OK, but if I'm doing a lot of going back and forth making changes to the model, then back to updating the drawing, I will sometimes have to run either my iLogic rule or the equivalent VBA macro to copy all custom iProperties from the model to the drawing, to make sure those linked texts are up-to-date. As I said, it's not a 100% ideal scenario, but it is handy and convenient.
Another possible process to accomplish a similar outcome might be to manually run a rule to update your non-linked title block text to show the model's finish after the drawing has been created and drawing views placed onto it. Of course this wouldn't be ideal either because you would have to remember to run that rule to update that value. Trying to get a title block text to link to anything that might possibly not exist, especially something in another document, like a custom iProperty or Parameter, is going to involve some level of risk or complication.
A custom add-in might work better for a situation like this. The add-in can be running/waiting in the background when you start Inventor, for when you place the first drawing view of a model into a drawing document, and when that happens, automatically make all this stuff happen, so you don't have to remember to do anything manually. Unfortunately, I won't be able to create such an add-in for you, due to corporate restrictions (no employees have admin rights to their own PCs) at work. But if that is the direction you want to go in, you can either attempt to learn how to make it yourself, or maybe ask others here on the forums to help you create it (if you're even able to install/use them at work).
Wesley Crihfield
(Not an Autodesk Employee)
Hi @pbibyFDYXV. That is a good question. I am not really aware of a 'book' that is all about automating Inventor by code, but there are several other resources available that can help with that. About the only books I can think of are ones for learning to use Inventor itself, but I don't know if they go into the automation side of things. Another of the highly active forum members named Curtis Waguespack helped author some books who's titles start with "Mastering Autodesk Inventor", and he has a link to them on his blog website (https://inventortrenches.blogspot.com/).
I will attach a PDF of some quick reference information I created some time ago, and several Links to other useful resources and references that may be useful.
Likely one of the most basic things to understand are the various primary ways we have available to us for automating Inventor, and what the differences are between them. Perhaps the oldest is the VBA editor. When you have Inventor open, you can usually go to the Tools tab, and find a button in the Options panel somewhere that will open this editor, but only if it has been installed. I believe all newer versions of Inventor since around 2021 have not included the VBA editor in standard installations, due to it being an older coding system that is no longer being maintained by Microsoft, and is therefore a security risk. But we can still install it later, if we want. Some who are used to it, and have used if for years, and have lots of resources already prepared in it, find it indispensable, and some others have chosen to shift any existing or new automation solutions/projects over to newer system. Next is Inventor's iLogic add-in. Its user interface dialog/window has a far more basic layout/appearance than the VBA editor, so many who have a long history of coding find it a bit lacking in features/tools, but others love its simplicity. You can read more about that in the PDF, but it lets us use the newer (yet still pretty old) vb.net coding language. This has a lot of similarities to VBA, but has been much further developed, and has several distinct differences. The other main tool some folks choose to use is Microsoft's Visual Studio. It is a huge, highly developed application for all different types of software development in many different coding languages, so it can be very intimidating for those who are not super serious about coding. It has free versions, and paid versions. It is completely separate from Inventor, so the resources you create with it often need to be...prepared certain ways to be able to use them either within Inventor, or to control Inventor remotely. So, if you are just getting started with automating Inventor, and do not have much previous coding experience, I would personally suggest learning all you can about the vb.net coding language, and exploring Inventor's iLogic resources. One of the key things to understand when using iLogic rules is that the iLogic add-in has some of its own 'object types' and 'methods' that are unique, and not part of the main Inventor API (application programming interface). The Inventor API is the primary, application level way to interact with Inventor, and the iLogic add-in provides one way to access that resource. The VBA editor is another way to access Inventor's API. Visual Studio can also access Inventor's API to control it, but when using VS, you can sometimes use other coding languages, if you are more familiar with them than with vb.net. Inventor 2024 was using vb.net Framework 4.8 system (slightly older version), while Inventor 2025 is now using vb.net 'Core' 8 (Core term no longer used), which is a newer version with some slight differences.
Wesley Crihfield
(Not an Autodesk Employee)