Toggle through broken Constraints to repair

[d_eckel]

Hello everyone,
I want to write an iLogic that finds a broken constraints in an assembly and opens the constraints edit window. The affected components are isolated, the others are hidden.
Is there a way in the script to wait for the user to close the window. Among other things, to reset the view at the end of the script?

Currently I'm manually running the rule twice to get backt to the original view.

option explicit on
Dim oAssemblyDoc As AssemblyDocument = ThisDoc.Document
Dim oPart1 As ComponentOccurrence
Dim oPart2 As ComponentOccurrence

Dim oView As DesignViewRepresentation
Dim oViewMerker As DesignViewRepresentation = ThisDoc.Document.ComponentDefinition.RepresentationsManager.ActiveDesignViewRepresentation
ThisDoc.Document.ComponentDefinition.RepresentationsManager.DesignViewRepresentations.item("Vorgabe").Activate
Try 
	ThisDoc.Document.ComponentDefinition.RepresentationsManager.DesignViewRepresentations.item("Reperatur").Delete
Catch
End Try

For Each oConstraint As AssemblyConstraint In oAssemblyDoc.ComponentDefinition.Constraints
	
	If oConstraint.HealthStatus <> oConstraint.HealthStatus.kUpToDateHealth And _
       oConstraint.HealthStatus <> oConstraint.HealthStatus.kSuppressedHealth Then 
	   
	   		Try 
				ThisDoc.Document.ComponentDefinition.RepresentationsManager.DesignViewRepresentations.item("Reperatur").Activate
			Catch
				Logger.Info("Ansicht Reperatur nicht gefunden --> anlegen")
				oView = ThisDoc.Document.ComponentDefinition.RepresentationsManager.DesignViewRepresentations.Add("Reperatur")
				oView.Activate
			End Try
	   
	   		oPart1 = oConstraint.OccurrenceOne
			oPart2 = oConstraint.OccurrenceTwo
			
			ThisApplication.CommandManager.DoSelect(oPart1)
			ThisApplication.CommandManager.DoSelect(oPart2)
				ThisApplication.CommandManager.ControlDefinitions.Item("AssemblyIsolateCmd").Execute
			ThisApplication.CommandManager.DoUnSelect(oPart1)
			ThisApplication.CommandManager.DoUnSelect(oPart2)
			
			ThisApplication.CommandManager.DoSelect(oConstraint)
				ThisApplication.CommandManager.ControlDefinitions.Item("AssemblyEditConstraintCtxCmd").Execute
			ThisApplication.CommandManager.DoUnSelect(oConstraint)
			
			Return 
		
	End If  
Next

[WCrihfield]

Hi @d_eckel.  When executing commands by code you do not have much control over what happens after that point, because you do not have full control over whatever dialog may (or may not) show at that point.  If you were showing a form that you can created, it would usually allow you to specify if the form was 'modal' or not.  When a form is modal, you can not interact with anything else but that form while it is displayed, and the process that showed the form, will usually remain paused while the form is being displayed, and will resume when the form is closed.  But when you just execute a command, you do not have any reference in the code to any dialog that may show, so you are at the mercy of how it was designed to work by its creators.  There are often other ways to do things by code than by executing commands, but they will not include being able to use the User Interface tool that you would normally benefit from when doing it manually, and will usually be a lot more complicated to achieve.

By the way, are those 'DoSelect' lines working OK for you?  When using the BrowserNode.DoSelect method on multple items in a row, the second DoSelect will cause the previously selected object to not be selected anymore, but I do not often use the command manager version of DoSelect, so that may act differently.  I usually use the Document.SelectSet object, and its Select or SelectMultiple methods for selecting things prior to executing a command.

Edit:  Since you recorded the 'active' DVR before the loop started to the oViewMerker variable, why not just Activate that DVR after the end of that loop to restore it to its original state?

[d_eckel]

Hi @WCrihfield,

many thanks for your very detailed answer.

Setting the DVR "oViewMerker" at the end of the skript, closes the edit constraints window right away. So the last line needs to be the "AssemblyEditConstraintCtxCmd" to give the user a chance to fix it.

The idea came from an employee to quickly isolate and fix defective constraint(s). But i think it doesn't work that way and we have to go the built in "repair" way.

I've never worked with the "DoSelect" lines before. While writing and testing this skript, I had no problems with this command.

[WCrihfield]

OK.  I liked idea about trying to at least partially automate fixing a series of broken assembly constraints.  I have also thought about creating a solution along those lines on a few occasions, but have not created a fully functioning solution that works for all situations.  As you may be aware, the AssemblyConstraint object is just a base Class for a lot of other Classes that are derived from that Class.  This basically means that there are a lot different sub-types of constraints, and some properties of each constraint are not available until you identify which more specific type of constraint it is, then create a variable for that more specific type, and set the AssemblyConstraint object as its value.  Then you can see the additional properties that are available to only that specific version.  For instance, not all constraints, or types of constraints will be associated with two different assembly components.  And some may be constrained to an assembly origin plane/axis/point, or other WorkPlane/WorkAxis/WorkPoint, and other possible things that may not necessarily belong to another component.  And different types of constraints have differently named properties that are used to specify or reference the parameter being used to control the numerical aspect of the constraint, like an offset distance, or angle, etc.  I believe that if developed extensively enough, and taking the uniqueness of each possible sub-type of the constraints into account, and checking things like EntityOne/EntityTwo/GeometryOne/GeometryTwo in an intelligent, error avoidance way, and maybe throwing in a Pick method here and there for the possibly needed user interaction, a relatively good tool could be developed.  Good luck in whatever directions you may choose to go with your Inventor automation journey.