Constraint Dialog wishlist

[NateLiquidGravity]

We'll be combining the 2 dialogs with hopefully the best features of both paradigms.

If combined please include a button to enable/disable the drag-in-place constraints. I find them frustrating when I only want to move parts.

Also please include the flip button from the quick constraints.

 

[Max]

If combined please include a button to enable/disable the drag-in-place constraints. I find them frustrating when I only want to move parts.

I think we're just going to get rid of this. It works in very limited cases and is not worth the UX hassle.

 

[DavidJ]

Biggest annoyance for me (still after many years) is constraint selections not taking if I hit return key - I still forget to tab or click out of the entry box sometimes after (say) entering an offset from keyboard (where natural behaviour is to hit return or enter).

 

[Max]

Biggest annoyance for me (still after many years) is constraint selections not taking if I hit return key - I still forget to tab or click out of the entry box sometimes after (say) entering an offset from keyboard (where natural behaviour is to hit return or enter).

We're thinking through some ways to solve this. Enter is bad because in almost every other dialog that means "Apply and Close", so we wouldn't use Enter except perhaps as an Apply key. But you're talking about the preview phase.

We're considering a time delay, perhaps .5 seconds, where after you're done typing it updates, as well as some other mechanics. Perhaps we can implement this product wide - not sure yet.

 

[markporter]

Please increase the width of the Offset text box. It's fine for "D1+D2" but not helpful for "myGlobalParameter1 + myGlobalParameter2".

 

[DavidJ]

Perhaps the 'fastener' constraint that I saw in images in the dialog thread addresses this. These comments aren't so much about the dialog, but about how it fits in with usage.

If having to place multiple bolts or nuts in an assembly where there isn't the possibility of using a pattern, it can be a PITA. The 'drag and drop' constraint is actually very handy for placing several bolts in holes, or nuts on bolts quickly (perhaps the only time I routinely use that method). Mating underside of bolt head, or nut face, with the item they secure requires a lot of manipulation of the model for each fastener in turn.

If there was some way to keep the face of the common item selected, whilst hopping through all the fasteners, that could speed things up a lot. Others may have specific ides of exactly what UI alternative might help - I just know it's currently very tedious.

 

[DavidJ]

We're thinking through some ways to solve this. Enter is bad because in almost every other dialog that means "Apply and Close", so we wouldn't use Enter except perhaps as an Apply key. But you're talking about the preview phase.

We're considering a time delay, perhaps .5 seconds, where after you're done typing it updates, as well as some other mechanics. Perhaps we can implement this product wide - not sure yet.

No - I'm talking about apply and close. Return or enter often does the close, but ignores the value just typed, I have to go back and re-edit the constraint.

 

[Max]

No - I'm talking about apply and close. Return or enter often does the close, but ignores the value just typed, I have to go back and re-edit the constraint.

Got it, thanks.

 

[NateLiquidGravity]

Can we get the full instance name in the constraint dialog (and design explorer)?
For example which instance of New Part (1) is in this Align?

 

[Max]

Can we get the full instance name in the constraint dialog (and design explorer)?
For example which instance of New Part (1) is in this Align?
View attachment 28923

Like this?

 

[NateLiquidGravity]

Yes, exactly. And in the constraint dialog too. Ideally every dialog for picking things in assemblies.

 

[Max]

Yes, exactly. And in the constraint dialog too. Ideally every dialog for picking things in assemblies.

So this gets a little tricky because these names are actually dynamic. If you insert copies <1>, <2>, and <3> and then you delete copy <2>, <3> will become <2>.

For most cases when you design, perhaps you are not deleting random instances so this may not be a big concern, but it is worth knowing that this happens and that it might introduce some complexity.

 

[NateLiquidGravity]

I understand 100%. I've worked with it in AlibreScript/API. I'm not advocating a static number that needs to be recorded, but displayed in situ - in the moment as a helper for determining at a glance which instance.

 

[simonb65]

So this gets a little tricky because these names are actually dynamic. If you insert copies <1>, <2>, and <3> and then you delete copy <2>, <3> will become <2>.

Just curious as to why this information is useful to the end user then? It sounds like its just the index in an array and if it changes when you insert or remove items, unless your programatically referencing it, it makes no sense to display it. To be visually useful to the user, it needs to remain constant once created, does it not? What was the original design intent for displaying the instance 'index'?

 

[Max]

Just curious as to why this information is useful to the end user then? It sounds like its just the index in an array and if it changes when you insert or remove items, unless your programatically referencing it, it makes no sense to display it. To be visually useful to the user, it needs to remain constant once created, does it not? What was the original design intent for displaying the instance 'index'?

I too am curious what others say, but my guess is that it's the following case, among others: let's say you have 10 bolts, and resulting 30 constraints for them. You see some red constraint and edit it to analyze it. You just see Bolt and not Bolt<8>. So how do you go to the design tree to find the bolt the constraint refers to? In other words the info is less useful during creation and more useful during editing / analyzing. There are other ways of finding out its Bolt<8>, just takes more clicks.

 

[simonb65]

You just see Bolt and not Bolt<8>. So how do you go to the design tree to find the bolt the constraint refers to? In other words the info is less useful during creation and more useful during editing / analyzing. There are other ways of finding out its Bolt<8>, just takes more clicks.

So the issue is really allowing 2 or more items to be 'named' the same? as an instance refers to the same underlying item.

Example:

Create a feature A, its a 1/4" bolt, now rename it to be 'Bolt' and then copy it a few times in your part. You then have Bolt<1>, Bolt<2>, Bolt<3>.
Now create another feature B, it's a 5/16" bolt, now rename that it to be 'Bolt' and then copy it a few times in your part. You then have another Bolt<1>, Bolt<2>, Bolt<3>.

Now, how does the user distinguish Bolt<2> (the 1/4" one) from Bolt<2> (the 5/16" one) if they have named them the same simplified and general name?

The instance does nothing to distinguish the two and has no real relevance. To make it work you need to make the 'name' unique, so that it becomes 1/4" Bolt<1>, 1/4" Bolt<2>, 1/4" Bolt<3>, 5/16" Bolt<1>, 5/16" Bolt<2>, 5/16" Bolt<3>.

At which point the instance <1>,<2>,<3> is no longer adding any value add as in reality you have 2 parts 1/4" Bolt and 5/16" Bolt which happen to be used in multiple places. As you can't change individual instances, they are all copies!

or am I missing something ... ?? are you assuming the user will name things uniquely? does that need to be forced? do you really need to know the named item is used multiple times? maybe the addition of the feature dimensions/values to the displayed string are more useful than an instance that changes? Just food for thought ...

As for your hyperthetical question, maybe a menu option to integrate through the tree and expand the nodes and highlight the one(s) that contain the constrain references? ... i.e. let Alibre find and show you them, it can do it more efficiently and quicker!

EDIT: Ignore most of that, I guess in the context of an constraint, the instance is paramount!! but other times, not so much, if at all. But it still doesn't need showing if Alibre shows you the explorer item its referencing.

 

[Max]

No, the issue is having a single part Bolt.ad_prt that has been duplicated in an assembly (instanced). In the Design Tree you will see Bolt<1>, Bolt<2>, etc. where the <#> serves as an instance identity of Bolt.ad_prt. The ask here is that the instance information <#> be brought into locations that involve referencing Bolt.ad_prt, for example constraint dialogs, creating a plane offset from a plane related to Bolt.ad_prt etc.

 

[simonb65]

No, the issue is having a single part Bolt.ad_prt that has been duplicated in an assembly (instanced). In the Design Tree you will see Bolt<1>, Bolt<2>, etc. where the <#> serves as an instance identity of Bolt.ad_prt. The ask here is that the instance information <#> be brought into locations that involve referencing Bolt.ad_prt, for example constraint dialogs, creating a plane offset from a plane related to Bolt.ad_prt etc.

Yeah, I just thought that one through a bit more and see my EDIT ...

 

[NateLiquidGravity]

Its the same idea as what already happens for Edges, Faces, and Verticies - but for assembly components.
Another location it would be useful is in the Advanced Selector dialog.

 

[Lew_Merrick]

So the issue is really allowing 2 or more items to be 'named' the same? as an instance refers to the same underlying item.

Create a feature A, its a 1/4" bolt, now rename it to be 'Bolt' and then copy it a few times in your part. You then have Bolt<1>, Bolt<2>, Bolt<3>.

One reason why my "hardware" gets Technical Names" such as "SAE Grade 8 Hex Head Cap Screw 0-2500-20UNRC X 0-375 Long" so I know what I am looking at.