Community
Accepted solution
This might get you closer to your goal.
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
'define the variable "oName"
oName = "ModelState1"
For Each oOcc As ComponentOccurrence In oADoc.ComponentDefinition.Occurrences
If TypeOf oOcc.Definition Is PartComponentDefinition Then
Dim oPDef As PartComponentDefinition = oOcc.Definition
Dim oFound As Boolean = False
For Each oMS As ModelState In oPDef.ModelStates
If oMS.Name = oName Then
oFound = True
Exit For 'found it, so don't create it
End If
Next
If oFound = False Then
'did not find it, so create it
oPDef.ModelStates.Add(oName)
End If
oOcc.ActiveModelState = oName
End If
NextIf 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 :light_bulb: or you can Explore My CONTRIBUTIONS
Wesley Crihfield
(Not an Autodesk Employee)
This might get you closer to your goal.
Dim oADoc As AssemblyDocument = ThisApplication.ActiveDocument
'define the variable "oName"
oName = "ModelState1"
For Each oOcc As ComponentOccurrence In oADoc.ComponentDefinition.Occurrences
If TypeOf oOcc.Definition Is PartComponentDefinition Then
Dim oPDef As PartComponentDefinition = oOcc.Definition
Dim oFound As Boolean = False
For Each oMS As ModelState In oPDef.ModelStates
If oMS.Name = oName Then
oFound = True
Exit For 'found it, so don't create it
End If
Next
If oFound = False Then
'did not find it, so create it
oPDef.ModelStates.Add(oName)
End If
oOcc.ActiveModelState = oName
End If
NextIf 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 :light_bulb: or you can Explore My CONTRIBUTIONS
Wesley Crihfield
(Not an Autodesk Employee)
Accepted solution
I see @WCrihfield was just a bit faster than me but here is my approach.
Dim doc As AssemblyDocument = ThisDoc.Document Dim occ As ComponentOccurrence = doc.ComponentDefinition.Occurrences.Item(1) Dim facDoc As PartDocument = occ.Definition.Document If (facDoc.ComponentDefinition.IsModelStateMember) Then facDoc = facDoc.ComponentDefinition.FactoryDocument End If Dim modelStates As ModelStates = facDoc.ComponentDefinition.ModelStates Dim newModelStateName = "YourNameHere" Dim modelState As ModelState = modelStates.Add() modelState.Name = newModelStateName modelState.Activate() occ.ActiveModelState = newModelStateName
if you want to know why I find the factory document first then you can read my blog post on that topic.
Jelte de Jong
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Blog: hjalte.nl - github.com
I see @WCrihfield was just a bit faster than me but here is my approach.
Dim doc As AssemblyDocument = ThisDoc.Document Dim occ As ComponentOccurrence = doc.ComponentDefinition.Occurrences.Item(1) Dim facDoc As PartDocument = occ.Definition.Document If (facDoc.ComponentDefinition.IsModelStateMember) Then facDoc = facDoc.ComponentDefinition.FactoryDocument End If Dim modelStates As ModelStates = facDoc.ComponentDefinition.ModelStates Dim newModelStateName = "YourNameHere" Dim modelState As ModelState = modelStates.Add() modelState.Name = newModelStateName modelState.Activate() occ.ActiveModelState = newModelStateName
if you want to know why I find the factory document first then you can read my blog post on that topic.
Jelte de Jong
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Blog: hjalte.nl - github.com
Can you post an images of what the other tab of that error message says? Most often the "More Info" tab of those error messages contains more useful information, so I usually advise folks to post an image of the contents of both tabs of any error messages they get, when trying to diagnose the error.
Also, just a tip, but if you just want to work with one specifically named component, you can get it directly by its name (using ItemByName()), without needing to loop through all components, unless that component is at a lower level (below some sub-assemblies). Here is an alternative to the last code you posted that shows how to use this technique.
Dim doc As AssemblyDocument = ThisDoc.Document
oName = "COURSE 1 STEEL TANK SHEET:8"
occ = doc.ComponentDefinition.Occurrences.ItemByName(oName)
Dim facDoc As PartDocument = occ.Definition.Document
oPCD = facDoc.ComponentDefinition
If oPCD.IsModelStateMember Then
facDoc = oPCD.FactoryDocument
End If
oMStates = oPCD.ModelStates
newModelStateName = "N1"
oMState = oMStates.Add(newModelStateName)
oMState.Activate()
occ.ActiveModelState = newModelStateName
iLogicVb.RunRule(oName, "ManwayCutOut")
Wesley Crihfield
(Not an Autodesk Employee)
Can you post an images of what the other tab of that error message says? Most often the "More Info" tab of those error messages contains more useful information, so I usually advise folks to post an image of the contents of both tabs of any error messages they get, when trying to diagnose the error.
Also, just a tip, but if you just want to work with one specifically named component, you can get it directly by its name (using ItemByName()), without needing to loop through all components, unless that component is at a lower level (below some sub-assemblies). Here is an alternative to the last code you posted that shows how to use this technique.
Dim doc As AssemblyDocument = ThisDoc.Document
oName = "COURSE 1 STEEL TANK SHEET:8"
occ = doc.ComponentDefinition.Occurrences.ItemByName(oName)
Dim facDoc As PartDocument = occ.Definition.Document
oPCD = facDoc.ComponentDefinition
If oPCD.IsModelStateMember Then
facDoc = oPCD.FactoryDocument
End If
oMStates = oPCD.ModelStates
newModelStateName = "N1"
oMState = oMStates.Add(newModelStateName)
oMState.Activate()
occ.ActiveModelState = newModelStateName
iLogicVb.RunRule(oName, "ManwayCutOut")
Wesley Crihfield
(Not an Autodesk Employee)
You may also want to post the contents of that other rule you are trying to run, because the error message suggests that the error is in that rule. It may have to do with document references and/or using iLogic snippets that target the 'active' document by default, when you may need to be more specifically targeting the 'local' document instead. When running code from a main assembly, usually that main assembly will remain the 'active' document, until you do something that 'activates' another document to become the 'active' document. This little issue trips tons of folks up, and it can be difficult to diagnose without lots of experience/knowledge about the references/methods being used.
Wesley Crihfield
(Not an Autodesk Employee)
You may also want to post the contents of that other rule you are trying to run, because the error message suggests that the error is in that rule. It may have to do with document references and/or using iLogic snippets that target the 'active' document by default, when you may need to be more specifically targeting the 'local' document instead. When running code from a main assembly, usually that main assembly will remain the 'active' document, until you do something that 'activates' another document to become the 'active' document. This little issue trips tons of folks up, and it can be difficult to diagnose without lots of experience/knowledge about the references/methods being used.
Wesley Crihfield
(Not an Autodesk Employee)
OK. So in this case, the info in that other tab wasn't that helpful after all. But after seeing your other rule, I can instantly see why it is having problems. You are using the unquoted names of local parameters and the Feature.IsActive() iLogic snippet without specifying a target component name or document name. That set-up is usually great for local rules, but when you run that rule remotely, while another document is the 'active' document, it may cause problems. I'm not 100% sure whether the Feature.IsActive() iLogic snippet targets the 'active' document or the 'local' document by default, when you don't specify a component name or document name as the first input variable. I assume it is targeting the 'active' document though. And in this case, the main assembly is still the 'active' document when this rule is getting ran remotely, which may be causing the problem.
There are some alternative ways this rule could be laid out, but it starts to get more complicated when we do.
What I would suggest first, before attempting to rewrite your local rule differently, would be to activate this document just before we use that line of code to run it. That may eliminate the problem. If not, then we may look into rewriting that rule a bit to make it work in this situation.
So...I just slightly tweaked the earlier main code to activate that part document just before the line to run the rule.
Dim doc As AssemblyDocument = ThisDoc.Document
oName = "COURSE 1 STEEL TANK SHEET:8"
occ = doc.ComponentDefinition.Occurrences.ItemByName(oName)
Dim facDoc As PartDocument = occ.Definition.Document
oPCD = facDoc.ComponentDefinition
If oPCD.IsModelStateMember Then
facDoc = oPCD.FactoryDocument
End If
oMStates = oPCD.ModelStates
newModelStateName = "N1"
oMState = oMStates.Add(newModelStateName)
oMState.Activate()
occ.ActiveModelState = newModelStateName
facDoc.Activate
iLogicVb.RunRule(oName, "ManwayCutOut")
're-activate the main assembly afterwards, if needed
'but test both ways, in case more time is needed for the rule to do its thing
'doc.Activate
Wesley Crihfield
(Not an Autodesk Employee)
OK. So in this case, the info in that other tab wasn't that helpful after all. But after seeing your other rule, I can instantly see why it is having problems. You are using the unquoted names of local parameters and the Feature.IsActive() iLogic snippet without specifying a target component name or document name. That set-up is usually great for local rules, but when you run that rule remotely, while another document is the 'active' document, it may cause problems. I'm not 100% sure whether the Feature.IsActive() iLogic snippet targets the 'active' document or the 'local' document by default, when you don't specify a component name or document name as the first input variable. I assume it is targeting the 'active' document though. And in this case, the main assembly is still the 'active' document when this rule is getting ran remotely, which may be causing the problem.
There are some alternative ways this rule could be laid out, but it starts to get more complicated when we do.
What I would suggest first, before attempting to rewrite your local rule differently, would be to activate this document just before we use that line of code to run it. That may eliminate the problem. If not, then we may look into rewriting that rule a bit to make it work in this situation.
So...I just slightly tweaked the earlier main code to activate that part document just before the line to run the rule.
Dim doc As AssemblyDocument = ThisDoc.Document
oName = "COURSE 1 STEEL TANK SHEET:8"
occ = doc.ComponentDefinition.Occurrences.ItemByName(oName)
Dim facDoc As PartDocument = occ.Definition.Document
oPCD = facDoc.ComponentDefinition
If oPCD.IsModelStateMember Then
facDoc = oPCD.FactoryDocument
End If
oMStates = oPCD.ModelStates
newModelStateName = "N1"
oMState = oMStates.Add(newModelStateName)
oMState.Activate()
occ.ActiveModelState = newModelStateName
facDoc.Activate
iLogicVb.RunRule(oName, "ManwayCutOut")
're-activate the main assembly afterwards, if needed
'but test both ways, in case more time is needed for the rule to do its thing
'doc.Activate
Wesley Crihfield
(Not an Autodesk Employee)
OK. That's fine. Generally, unless the assembly is in 'Express Mode' all components within the assembly are at least 'initiated', if not fully open (in the background, not visibly). So you usually don't have to open or close any of those documents that are being represented by the components. But I can understand not wanting the other document visibly activated, especially when the code leaves them that way when its done. It can be annoying and might possibly interfere with other operations.
Sure, we can look into changing that other rule as needed for this situation. I created something for you to try. I left several lines of comments in this code for you, just as additional information that may be useful to you. When dealing with parameters, there is a tricky & extremely annoying situation to be aware of, involving the 'units' of any numerical values (other than unit-less). There are several ways of accessing and dealing with parameters, and some return different results than others. When using either the unquoted name of a 'local' parameter in a 'local' rule, and when using the iLogic snippet 'Parameters("parameter_name")', these will both return the true 'document units' value of the parameter directly. But when using either the iLogic snippet 'Parameter.Param("parameter_name").Value', or the normal API way 'Document.ComponentDefinition.Parameters.Item("parameter_name").Value' to get the parameter's value, it will return the 'database units' version of its Value, instead of the 'document units' version of it. I generally prefer to use the API route, then convert the units back as needed, instead of using the iLogic snippets for this task, because it's more reliable, clearer, & better documented. But I would need to know what type of units were being used ahead of time, to convert the units properly within the code.
Here is the new version of that local rule that you can try:
'just using a dummy variable here,
'to preserve automation/triggering behavior of unquoted local parameter
oDV = ManwayType
'get the 'local' part document object (the document this rule is saved within)
Dim oPDoc As PartDocument = ThisDoc.Document
oPDef = oPDoc.ComponentDefinition
'if the parameter is numerical, and not unit-less,
'this will return 'database units' version of the parameter's Value,
'not the 'document units' version of it
'oManwayType = oPDef.Parameters.Item("ManwayType").Value
oDocName = ThisDoc.FileName(True)
'these two will get the 'document units' version of the parameter's Value
'oManwayType = ManwayType 'unquoted parameter name
oManwayType = Parameter(oDocName, "ManwayType")
oFeats = oPDef.Features
If oManwayType = 600 Then
oFeats.Item("MWAY600 Centre").Suppressed = False
oFeats.Item("MWAY600 Holes").Suppressed = False
oFeats.Item("MWAY600 PCD").Suppressed = False
oFeats.Item("MWAY800 Centre").Suppressed = True
oFeats.Item("MWAY800 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
oFeats.Item("MWAY900 Centre").Suppressed = True
oFeats.Item("MWAY900 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
ElseIf oManwayType = 800 Then
oFeats.Item("MWAY800 Centre").Suppressed = False
oFeats.Item("MWAY800 Holes").Suppressed = False
oFeats.Item("MWAY800 PCD").Suppressed = False
oFeats.Item("MWAY600 Centre").Suppressed = True
oFeats.Item("MWAY600 Holes").Suppressed = True
oFeats.Item("MWAY600 PCD").Suppressed = True
oFeats.Item("MWAY900 Centre").Suppressed = True
oFeats.Item("MWAY900 Holes").Suppressed = True
oFeats.Item("MWAY900 PCD").Suppressed = True
ElseIf oManwayType = 900 Then
oFeats.Item("MWAY900 Centre").Suppressed = False
oFeats.Item("MWAY900 Holes").Suppressed = False
oFeats.Item("MWAY900 PCD").Suppressed = False
oFeats.Item("MWAY800 Centre").Suppressed = True
oFeats.Item("MWAY800 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
oFeats.Item("MWAY600 Centre").Suppressed = True
oFeats.Item("MWAY600 Holes").Suppressed = True
oFeats.Item("MWAY600 PCD").Suppressed = True
End If
oPDoc.Update
Wesley Crihfield
(Not an Autodesk Employee)
OK. That's fine. Generally, unless the assembly is in 'Express Mode' all components within the assembly are at least 'initiated', if not fully open (in the background, not visibly). So you usually don't have to open or close any of those documents that are being represented by the components. But I can understand not wanting the other document visibly activated, especially when the code leaves them that way when its done. It can be annoying and might possibly interfere with other operations.
Sure, we can look into changing that other rule as needed for this situation. I created something for you to try. I left several lines of comments in this code for you, just as additional information that may be useful to you. When dealing with parameters, there is a tricky & extremely annoying situation to be aware of, involving the 'units' of any numerical values (other than unit-less). There are several ways of accessing and dealing with parameters, and some return different results than others. When using either the unquoted name of a 'local' parameter in a 'local' rule, and when using the iLogic snippet 'Parameters("parameter_name")', these will both return the true 'document units' value of the parameter directly. But when using either the iLogic snippet 'Parameter.Param("parameter_name").Value', or the normal API way 'Document.ComponentDefinition.Parameters.Item("parameter_name").Value' to get the parameter's value, it will return the 'database units' version of its Value, instead of the 'document units' version of it. I generally prefer to use the API route, then convert the units back as needed, instead of using the iLogic snippets for this task, because it's more reliable, clearer, & better documented. But I would need to know what type of units were being used ahead of time, to convert the units properly within the code.
Here is the new version of that local rule that you can try:
'just using a dummy variable here,
'to preserve automation/triggering behavior of unquoted local parameter
oDV = ManwayType
'get the 'local' part document object (the document this rule is saved within)
Dim oPDoc As PartDocument = ThisDoc.Document
oPDef = oPDoc.ComponentDefinition
'if the parameter is numerical, and not unit-less,
'this will return 'database units' version of the parameter's Value,
'not the 'document units' version of it
'oManwayType = oPDef.Parameters.Item("ManwayType").Value
oDocName = ThisDoc.FileName(True)
'these two will get the 'document units' version of the parameter's Value
'oManwayType = ManwayType 'unquoted parameter name
oManwayType = Parameter(oDocName, "ManwayType")
oFeats = oPDef.Features
If oManwayType = 600 Then
oFeats.Item("MWAY600 Centre").Suppressed = False
oFeats.Item("MWAY600 Holes").Suppressed = False
oFeats.Item("MWAY600 PCD").Suppressed = False
oFeats.Item("MWAY800 Centre").Suppressed = True
oFeats.Item("MWAY800 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
oFeats.Item("MWAY900 Centre").Suppressed = True
oFeats.Item("MWAY900 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
ElseIf oManwayType = 800 Then
oFeats.Item("MWAY800 Centre").Suppressed = False
oFeats.Item("MWAY800 Holes").Suppressed = False
oFeats.Item("MWAY800 PCD").Suppressed = False
oFeats.Item("MWAY600 Centre").Suppressed = True
oFeats.Item("MWAY600 Holes").Suppressed = True
oFeats.Item("MWAY600 PCD").Suppressed = True
oFeats.Item("MWAY900 Centre").Suppressed = True
oFeats.Item("MWAY900 Holes").Suppressed = True
oFeats.Item("MWAY900 PCD").Suppressed = True
ElseIf oManwayType = 900 Then
oFeats.Item("MWAY900 Centre").Suppressed = False
oFeats.Item("MWAY900 Holes").Suppressed = False
oFeats.Item("MWAY900 PCD").Suppressed = False
oFeats.Item("MWAY800 Centre").Suppressed = True
oFeats.Item("MWAY800 Holes").Suppressed = True
oFeats.Item("MWAY800 PCD").Suppressed = True
oFeats.Item("MWAY600 Centre").Suppressed = True
oFeats.Item("MWAY600 Holes").Suppressed = True
oFeats.Item("MWAY600 PCD").Suppressed = True
End If
oPDoc.Update
Wesley Crihfield
(Not an Autodesk Employee)
Oops... I didn't mean to leave that line in there. I was just playing around with the different methods of getting that parameter. Just delete that whole line.
Wesley Crihfield
(Not an Autodesk Employee)
Oops... I didn't mean to leave that line in there. I was just playing around with the different methods of getting that parameter. Just delete that whole line.
Wesley Crihfield
(Not an Autodesk Employee)
Based on that recap and what you said at the end of 'Message 5', my best guess is that there is a bug preventing us from running local rules (or all rules effecting that document) while a ModelState other than "Master" is active. It kind of sounds familiar...like I've heard about this before somewhere, but I can't remember where. May have been a webinar or something about the current limitations of ModelStates. And it also seems to be blocking your simple call to set the value of the parameter while a ModelState other than "Master" is active. I know that non-Master ModelStates have a table in them that can be edited, similar to an iPart, iAssembly, or iFeature table, that can be edited like a spreadsheet (with Excel or whatever native editor you have). And I know that the ModelStates object has a MemberEditScope property that needs to be set to specify whether changes effect all ModelStates or just the 'active' ModelState. But I honestly have not tried this specific task before yet.
Here's a thought as we explore this idea. I bet we have to first set the MemberEditScope setting to "kEditActiveMember" (without quotes). Then either edit the table, or dig down into the ModelState.FactoryDocument, then into its ComponentDefinition.Parameters.Item("parameter_name").Value to get/set its value only for that one ModelState, when dealing with a Parameter. Similar process for suppressing or un-suppressing a feature only in that one ModelState. Using the API route would look like oModelState.FactoryDocument.ComponentDefinition.Features.Item("feature name").Suppressed = True. We may have to do all of this from that main rule in the assembly, instead of using that local rule within the part document. I'm not 100% sure, though. The process I just stated makes better/clearer sense to me right now though. If we were to edit the table, it might get more complicated, because we won't know how its all laid out to find stuff within, so we would likely have to use a series of loops through rows & columns to find the right cell values to change.
PS. I tested that route on a test assembly and it works. (Digging down into the FactoryDocument to get the Parameters & Featrues, that is.)
Wesley Crihfield
(Not an Autodesk Employee)
Based on that recap and what you said at the end of 'Message 5', my best guess is that there is a bug preventing us from running local rules (or all rules effecting that document) while a ModelState other than "Master" is active. It kind of sounds familiar...like I've heard about this before somewhere, but I can't remember where. May have been a webinar or something about the current limitations of ModelStates. And it also seems to be blocking your simple call to set the value of the parameter while a ModelState other than "Master" is active. I know that non-Master ModelStates have a table in them that can be edited, similar to an iPart, iAssembly, or iFeature table, that can be edited like a spreadsheet (with Excel or whatever native editor you have). And I know that the ModelStates object has a MemberEditScope property that needs to be set to specify whether changes effect all ModelStates or just the 'active' ModelState. But I honestly have not tried this specific task before yet.
Here's a thought as we explore this idea. I bet we have to first set the MemberEditScope setting to "kEditActiveMember" (without quotes). Then either edit the table, or dig down into the ModelState.FactoryDocument, then into its ComponentDefinition.Parameters.Item("parameter_name").Value to get/set its value only for that one ModelState, when dealing with a Parameter. Similar process for suppressing or un-suppressing a feature only in that one ModelState. Using the API route would look like oModelState.FactoryDocument.ComponentDefinition.Features.Item("feature name").Suppressed = True. We may have to do all of this from that main rule in the assembly, instead of using that local rule within the part document. I'm not 100% sure, though. The process I just stated makes better/clearer sense to me right now though. If we were to edit the table, it might get more complicated, because we won't know how its all laid out to find stuff within, so we would likely have to use a series of loops through rows & columns to find the right cell values to change.
PS. I tested that route on a test assembly and it works. (Digging down into the FactoryDocument to get the Parameters & Featrues, that is.)
Wesley Crihfield
(Not an Autodesk Employee)
Forums Links
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
