iProperties in referenced document (Modelstate) + Vault

[richterBKSAC]

Hi everyone,

I've create a userform which does show the iProperties of the active drawing and it's referenced document (IPT/IAM). Also it lets me "transfer" the iProperty values of the drawing, which you can edit via the form, to the referenced document (so the title block of the drawing updates).

I've also added some code so you can choose the referenced document to write to, when there is more than one referenced document.

Now to my actual problem:

I've came across an exception where the drawing has an assembly with 2 custom modelstates and the default modelstate. Only the 2 custom modelstates are displayed on the drawing. By looking at the "api tree" I've found out that Inventor also creates 2 referenced Document Items, which makes sense. The problem is that if I write the iproperty values of the drawing to one of these Items and check them into Vault the "title" iproperty, for example, remains empty. Also the title block "title" remains empty. I've also found out that you have to write the iproperties into the default modelstate of the referenced document for it to show in the title block as well as in Vault.

My question is how can I access the propertysets of the default modelstate if it isn't present in the drawing?

Of course I could open the part or assembly and fill out the information manually, but that's kind of against why I created the form in the first place, to not have to edit both files.

[Frederick_Law]

The default is always first ModelState.

It's name is always 

ThisServer.LanguageTools.CurrentPrimaryModelStateString

in iLogic.

[W.Scott.Dempster]

It's possible I am not fully informed because I haven't used Model States or iParts that extensively, but adjusting iProperties in both Model States and iParts is somewhat buggy to me unless you also include the iProperty in the Design Table.  This way, you can access the Model State directly and change the corresponding iProperty.

For example and assuming you want to predetermine the iProperty's location for the not-displayed Model State in the Excel table (C2, for example), you can use code like this:

Sub iPropertyModelStateTable()

    Dim oApp As Application
    Set oApp = ThisApplication

    Dim oPart As PartDocument
    Set oPart = oApp.ActiveDocument

    Dim oModelStateTable As Excel.WorkSheet
    Set oModelStateTable =  oPart.ComponentDefinition.ModelStates.ExcelWorkSheet

    oModelStateTable.Range("C2").Value = "Your Property"
    oModelStateTable.parent.Save
    oModelStateTable.parent.Close

End Sub

[WCrihfield]

Hi @richterBKSAC.  I don't know how all your code behind that VBA Userform is set-up, but there are several ways do access and modify either one specific ModelState, or all ModelStates in the drawing's referenced file.  The most direct way may be to use the regular Documents.Open() method, and specify the proper FullDocumentName, which includes the ModelState name within "<" & ">" brackets right after the file extension of the FullFileName.  That will open, and leave you with a reference to that exact ModelState version of the document.  The tradition route of editing individual ModelStates differently from each other is to first make sure the MemberEditScope is set to the 'member' variation (instead of the 'factory' variation), then 'activate' each specific ModelState just ahead of making the edits to its properties.  Or you could access the ModelStateTable object, which is laid out very similarly to iPart/iAssembly tables are, and make the edits there, where each row represents another ModelState.  Or you could edit the ModelStateTable through the ModelStates.ExcelWorkSheet, if you are familiar with working with Excel by code.  But to use either of those last two options, you just want to make sure that you access them from the current factory document, which is basically just the version under the control of the file's 'active' ModelState.  Having multiple ModelState variations of the same model file represented in a drawing is pretty nice in some respects, but it sure complicates things when tryng to control everything by code.

[richterBKSAC]

Thank you all for your response.

@W.Scott.Dempster 

I tried your solution, but according to the Inventor API Help the .ExcelWorkSheet is a read-only property and I wasn't able to edit the Worksheet. Just in case it is possible, would you be able to provide a solution?

In the end I found a way to edit the iProperties of all ModelStateMembers. I'd be interested if you guys would solve it differently or more elegantly.

Dim refdocs = ThisApplication.ActiveDocument.ReferencedDocuments
Dim ISI As String = "Inventor Summary Information"
Dim oModelstate As ModelState
Dim oModelStates As ModelStates = refdocs.Item(Parameter("ILOGIC_Konstruktion_Refdoc_Auswahl")).ComponentDefinition.ModelStates

If refdocs.Item(Parameter("ILOGIC_Konstruktion_Refdoc_Auswahl")).ComponentDefinition.IsModelStateMember Then
For Each oModelstate In oModelStates
				oModelstate.MemberDocument.PropertySets.Item(ISI).Item("Title").Value = iProperties.Value(ISI, "Title")
Next
Else
....
End if

 The userform is only iLogic, so I had to create custom parameters to include them in the form.

The Parameter("ILOGIC_Konstruktion_Refdoc_Auswahl") is used to store the user selection of the referenced Document, if there is more than one present in the drawing.

[CattabianiI]

---

@W.Scott.Dempster 

I tried your solution, but according to the Inventor API Help the .ExcelWorkSheet is a read-only property and I wasn't able to edit the Worksheet. Just in case it is possible, would you be able to provide a solution?

It is a readonly property which means you cannot set it, but you can edit the excel worksheet instance.
The following is an iLogic rule that edit the worksheet, I give this a try for performance reasons few months ago but I've still not used this approach in production: it's quite tricky to use it especially if you need to add columns (iproperties, parameters, ...)

Dim doc As Document = ThisApplication.ActiveDocument

Dim mss As ModelStates = doc.ComponentDefinition.modelstates

Dim colCount As Integer = mss.ModelStateTable.TableColumns.Count

Dim rowCount As Integer = mss.ModelStateTable.TableRows.Count

Dim wks = mss.ExcelWorkSheet

wks.Cells(1,colCount+1).Value = "customDescr" + colCount.ToString  +" [Custom]" '"iPropTestName [Custom]"

wks.Cells(2, colCount + 1).Value = "a"+ colCount.ToString

wks.Cells(3, colCount + 1).Value = "b"+ colCount.ToString

'wks.Cells(4, colCount + 1).Value = "b"

Dim wbk = wks.Parent

wbk.Save()

wbk.Close()

[WCrihfield]

Hi @richterBKSAC.  That is certainly a creative way to do it.  And you are apparently using a 'hidden' property of the ModelState too (MemberDocument), because that one is not listed in the online help documentation for the ModelState API object, but I tested it on my PC (Inv Pro 2024) and it seems to work.  I'm guessing it would coincide with the ModelState.Document property, which has pretty much the same definition.  In general, it is not a good idea to rely on 'hidden' properties in code meant for production type use, so it may be better to switch that one term from MemberDocument to Document instead.

[CattabianiI]

about this one instead:
> In the end I found a way to edit the iProperties of all ModelStateMembers. I'd be interested if you guys would solve it differently or more elegantly.

Be careful because the ModelState.MemberDocument property is undocumented and hidden!
Why don't you try to use ModelStates.MemberEditScope setting it to MemberEditScopeEnum.kEditAllMembers? as @WCrihfield said in his comment?
You can find few examples here in the forum.

[richterBKSAC]

Hey @WCrihfield ,

thanks for your reply!

I usually browse the 'internal tree' (see screenshot below) to find some solutions to my problems, that's how I came across the 'hidden' property. Unlike you assumed I can't just use Modelstate.Document instead because it's value is Nothing.

I'm also curious to why it's not a good idea to use 'hidden' properties? Just because they are undocumented and it's not known if they interact with other functions? Until you've mentioned it I wasn't even aware that there are 'hidden' properties.

[WCrihfield]

It is simply a general rule of thumb for good practice, and Autodesk themselves warn us about that at this link (and others), that it is not a good idea to rely on hidden or undocumented Methods, Properties, Events, etc.  When creating source code, you often have 'private' or hidden stuff for their own internal use, that they do not intend for the end user to interact with, and then there is 'Public' or normal stuff that you do intent for the end users to make use of.  The Public/normal stuff is generally very reliable, stable, and function as designed, but the private/hidden stuff may be unreliable, unstable, or only there for future development expansion use only.

I honestly had not looked into the VBA Object Model tree under the ModelState object yet, because I have been avoiding VBA as much as possible the past few years, due to the inherent security concerns that Autodesk has warned about, and are the reason that Autodesk has not included VBA in the past few Inventor installations (Link1, Link2).  But I do find it interesting that they have chosen to show that Property there, but not in the official online documentation for the ModelState API object.

[Frederick_Law]

If you extract the SDK, you'll get this:

[WCrihfield]

I was looking into the 2024 version earlier also, but it simply does not go into that much detail.  It doesn't show what all the Methods, Properties, or Events are for each object, just the structure of how to get to the main objects.  But here is that Inventor 2024 API Object Model PDF anyways, just for the additional reference.

[Frederick_Law]

VBA and VS object browser will show all available objects also.

Usually I use it to find the data I need.  Like object name, file name, feature name etc.

Place a stop and watch.

As you said, we should only use documented features.

[richterBKSAC]

I've tried to change the MemberEditScope but I couldn't make it work yet.

[richterBKSAC]

I'll stick to your advise in the future. Thanks again for pointing it out.

I only use VBA to browse the Object Model tree to get a better understanding of what I'm doing or how I could do something.

[richterBKSAC]

I'll try your solution soon. The excel syntax you suggested looks different from the goexcel. iLogic syntax.
If that's the case, can you recommend any website where I can look it up?

[CattabianiI]

Hi @richterBKSAC ,
give a read to this autodesk blog post to start: https://adndevblog.typepad.com/manufacturing/2013/02/manipulate-rows-and-columns-of-ipart-1.html
Just consider it's ten years old! 
If you are in iLogic you don't need to reference any excel reference and you can find some use in this forum too: https://forums.autodesk.com/t5/inventor-ilogic-and-vb-net-forum/use-ilogic-to-fill-in-ipart-table-va...

Oh what I'm assuming is that the model state excel object is the same as the ipart one.

If you're looking to an api manual for the WorkSheet object, check this out: https://learn.microsoft.com/en-us/dotnet/api/microsoft.office.interop.excel.application?view=excel-... 

To being able to write into the excel worksheet you need to take that object from the factory document!

[CattabianiI]

---

@richterBKSAC wrote:
I've tried to change the MemberEditScope but I couldn't make it work yet.

---

Could you share the code? The error could be that you're not setting that property via the factory document.

[richterBKSAC]

Dim refdocs = ThisApplication.ActiveDocument.ReferencedDocuments
Dim oModelStates As ModelStates = refdocs.Item(1).ComponentDefinition.ModelStates
oModelStates.MemberEditScope = MemberEditScopeEnum.kEditAllMembers

I think this leads back to my original problem that I can't access the "default" modelstate if I only have custom modelstates displayed on my drawing. 

I'm testing with a simple test part, which has a "default" modelstate and two custom modelstates.

[richterBKSAC]

Hey @CattabianiI ,

thanks for the links 🙂 I'll definitely read them.

---

To being able to write into the excel worksheet you need to take that object from the factory document!

---

I assume that's why it didn't work in my case. Maybe it is an idea to place a view of the "default" modelstate on the drawing outside of the actual drawing. This way I could access the factory.