How to set iPart member custom parameter using API

[DonStauffer99]

I created an iPart factory called Rails.ipt, with some custom parameters in the table. The first one is a parameter called ScalingFactor. All dimensions of the solid are multiplied by ScalingFactor. Initially I only made one row in the table. In that row, ScalingFactor is 1.

I made a member named Adjuster Rail.ipt, by placing the iPart into an assembly. I opened that member, and in the object browser, I right clicked on the Table and chose Activate, clicked the Table tab and then changed ScalingFactor to 1.5. When I clicked OK, the solid immediately increased in size by 50%, as expected.

I wanted to write an external rule to change ScalingFactor in the member, so as a test I decided to try to change it to 0.98 using code. I got some odd results. I basically wanted to duplicate the actions I had just taken manually, but with a different number. I can do it manually, so I should be able to do it by code. But ...

The code below reads the parameter, and the value coming back is 1.5, so it's clearly coming from the table in the member part file - the one I changed to 1.5. The factory still has 1. When I SET the value, though, using the same cell reference, 2 odd things happened. First, the cell reference seems to have been invalidated, so that if I try to use the cell variable again without re-assigning it, I get an error.

When I read the value in the member again, it's unchanged; I was expecting it to be 0.98 afterward, but it was still 1.5. But ... the value in the FACTORY is now 0.98 instead of 1! Checking the table in each part file, I confirmed that although cell.Value returned the value in the member file, it changed the value in the factory file.

I'd appreciate any observations on what might be happening here, and how to accomplish this.

Dim docs As Documents = ThisApplication.Documents
Dim doc As PartDocument = docs.Open("C:\Users\Don\Documents\Inventor\Shared\Linear Adjuster\Adjuster Rails.ipt")
Dim pcd As PartComponentDefinition = doc.ComponentDefinition
Dim member As iPartMember = pcd.iPartMember
Dim row As iPartTableRow = member.Row

Dim cell As iPartTableCell = row.Item(3)

'	Get original value; this will come from table in MEMBER:
Dim s As String = "Original: " & cell.Value

'	Set new value; this will change value in FACTORY table:
cell.Value = 0.98

' Trying to use cell here causes an error unless you re-assign cell:
cell = row.Item(3)

'	Get new value; this will come from table in MEMBER:
s = s & vbCr & "New: " & cell.Value

MsgBox(s)

[WCrihfield]

Hi @DonStauffer99.  Is the iPart factory contained within the file you are opening in that code?  Or is the file you are opening in that code just one of the member model files that got generated from the factory file in a sub folder?  A document update or rebuild may be needed after changing parameter values, but before checking its value again after the change.  Usually, when we want to change a member model file, we make the changes in the factory table, then 'regenerate' any 'members' that those changes are supposed to be effecting, before the pre-existing member files will get updated to the new values in the factory table.  The member model file should not be attempting to pushing changes to itself back up to the parent iPart factory.  But I am a bit rusty when it comes to iParts, because I do not use them anymore.

[DonStauffer99]

The iPart factory is a separate file called Rails.ipt. The file I open in the code is the member, called Adjuster Rails.ipt.

I'm not trying to do anything with the factory. In fact, that's exactly the problem: I don't want to change anything in the factory. I want to change the parameter in the member only. But the API code which should change the member parameter changes the factory parameter instead. Bizarrely, reading and writing that cell operate on 2 different files. 

Dim s As String = "Original: " & cell.Value ' Gets the cell value from the member

cell.Value = 0.98 ' Changes the cell value in the factory

[WCrihfield]

The details you pointed out do sound odd, no doubt about it.

However, when I manually open one of my old iPart member files, there is:

• no modeling history
• all sketch tools, and all modeling features are greyed out, preventing us from creating any new sketches or features
• all work feature creating tools are disabled
• we can not have or create any iLogic rules or forms within the member model file
• When we right-click on the table at the top of the modeling tree, the only option we have is to break the link to the factory, with no options for modifying this member's specifications. 

Therefore, it is pretty clear that we are not meant to be making changes directly to the iPart member model files, from the iPart member model files.

So, if we want to change the member model file, we must make those changes at the factory level, then regenerate the model member file from the factory.  By code, it seems the only way to do that is with either the iPartFactory.CreateMember method, or the iPartFactory.CreateCustomMember.  I believe that when you use that method, and a model file already exists for that row/member, it will either regenerate the model in that file, or replace that file.  The iPartFactory.Delete method tells us that if we delete the table from an iPart factory, that will turn the factory into a 'regular' part, and will also make all of the member model files 'sick'.  This is because they were all directly dependent on the factory for their specifications.  Maybe if you broke the link between the member model file and its factory, it would then let you make the changes you want to it that will then be independent of the factory.  Those types of situations are one of the reasons I stopped using them.

[DonStauffer99]

This was a custom iPart. So I could manually change parameters, and the model adjusted. I just couldn't do it programmatically, because it seems like that property works differently with a set than a get.

[CGBenner]

@DonStauffer99 @WCrihfield 

Hi guys,  I'm trying to follow this thread but it is going way above my skill set.  LOL  Has this been resolved in any way?
 

[DonStauffer99 · Accepted solution]

I decided for what I'm doing a conventional part is better than an iPart. I never did get a resolution on the contradictory behavior of the iPartTableCell object's Value property when it comes to assignment vs. using the value. It seems to me it's a bug, and both iPartTableCell.Value = and = iPartTableCell.Value should involve the member and not the factory, if the iPartTableCell object comes from an iPartTableRow that came from the iPartMember object's Row property. But at the very least, they should both access the same part, and which one should be documented. But since an iPartMember object is where the iPartTableCell object comes from proximately, that suggests the member is what it should always refer to.

In general, I'm finding the API handles this dichotomy not based on any containing object, but that columns refer to factories and rows refer to members, which seems arbitrary but would be usable if it were completely consistent. This behavior also needs to be documented, whatever convention gets settled on, because I only figured it all out by experimenting. The documentation only tells what objects can be found where, not what they actually represent in terms of your parts.