Featurescript: Editing Logic Function does not update length parameter in Feature UI

antlu65

Have looked through the documentation as well as the Spur Gear example code, but I seem to be missing something obvious. I would like for the Logic Editing Function of my Custom Feature to change a numerical value entered by the user, and for this updated value to be reflected in the Feature UI dialog. When the user changes any parameter in the Feature UI, the Logic Editing Function is triggered. I modify the corresponding value in the 'definition' variable and return it from the function. This appears to work for boolean values, but does not work for my numerical value.

I've attached a minimal document illustrating my issue here:
https://cad.onshape.com/documents/99f64ae634cf6ee14ab3fece/w/7f6c6a530464ce65695a2d3b/e/ec2fc7c827f04f821c42d795

(As an aside, when I try to 'Ask a Question' directly in the Featurescript subforum, it indicates I am not allowed to post questions there. Does that forum require additional privileges? Or am I just asking really silly questions...)

Alex_Kempen

Sure. The bug appears to occur only when a field value is overwritten by editing logic immediately after it is submitted. For example, if the user enters a value into definition.length, the bug occurs if the editing logic immediately attempts to set definition.length to something else. So so long as the trigger for updating definition.length is not the user changing definition.length (like if it triggers in response to definition.myBoolean or definition.otherLength or whatever), everything works as expected. Thus, since overwriting a parameter immediately after a user changes it is pretty dubious from both a UX and a general usefulness perspective, I don't think the bug you've found is very likely to actually rear its head under "real-world" conditions.

antlu65

To clarify: the numerical value is correctly changed in the 'definition' map and visible to the rest of my featurescript code. But it is not being reflected in the UI unless I close and re-open the UI dialog.

Alex_Kempen

I see the behavior you're seeing, and agree that it's a bit buggy. However, I think it's only occurring because you're overriding the value of the parameter immediately after the user submits a value, rather than doing it conventionally (where parameters are only updated in response to external changes, like the feature being created or a new configuration being selected that requires a different default value). When you update the length parameter in response to a change other than the length parameter itself being changed, everything behaves as expected.

Is this particular behavior important for a feature you're working on?

antlu65

Alex_Kempen said:

I think it's only occurring because you're overriding the value of the parameter immediately after the user submits a value, rather than doing it conventionally (where parameters are only updated in response to external changes, like the feature being created or a new configuration being selected that requires a different default value). When you update the length parameter in response to a change other than the length parameter itself being changed, everything behaves as expected.

Is this particular behavior important for a feature you're working on?

Thanks for the reply! I don't understand the distinction between 'external changes' and the user inputting a value in the feature UI dialog. Are these not treated the same? I was under the impression that any user input in the feature UI dialog causes the feature to re-execute or refresh itself. To clarify, I am looking for the behavior found in the 'Spur Gear' FS [Link] - when, for example, the user inputs a value in the 'Module' field, the 'Pitch Diameter' field immediately updates visually in response.

This behavior isn't critical - just nice to have a responsive UI.

Alex_Kempen

Sure. The bug appears to occur only when a field value is overwritten by editing logic immediately after it is submitted. For example, if the user enters a value into definition.length, the bug occurs if the editing logic immediately attempts to set definition.length to something else. So so long as the trigger for updating definition.length is not the user changing definition.length (like if it triggers in response to definition.myBoolean or definition.otherLength or whatever), everything works as expected. Thus, since overwriting a parameter immediately after a user changes it is pretty dubious from both a UX and a general usefulness perspective, I don't think the bug you've found is very likely to actually rear its head under "real-world" conditions.

antlu65

Alex_Kempen said:

Thus, since overwriting a parameter immediately after a user changes it is pretty dubious from both a UX and a general usefulness perspective, I don't think the bug you've found is very likely to actually rear its head under "real-world" conditions.

I think this is too broad an assumption - depending on the particular scenario, it may be preferable to overwrite a numerical value that has dynamic bounds determined by other inputs, instead of throwing an error and forcing the user to figure out what the correct range of values should be.

As you stated, changing other numerical values does produce the expected behavior in the 'length' parameter. The exception appears to be if one opens the UI dialog and *first* changes the length parameter before making any other changes - in which case, the 'length' parameter remains unresponsive despite changes to other inputs until the UI dialog is closed and reopened. At least, that is the behavior I am observing in my minimal example linked above. Oh well. I guess I will just have to work around it for now.

In any case, I really do appreciate your time and effort, so thank you!

Alex_Kempen

If your goal is to create dynamic bounds, I think you’re much better off simulating a standard out of bounds error (using the faulty parameters arg of throw regenErrror and reporting the correct bounds in the error message) rather than overwriting the user input immediately to be in the correct bounds. The problem with overwriting the user input immediately is it isn’t always immediately clear to the user that their input has in fact been overwritten, or that the value they tried to enter was invalid in the first place. If they do in fact notice the value being used is different from the one they tried entering, their first reaction is very likely to be entering the invalid value again (thinking.that Onshape is bugging out and refusing to accept their input) rather than coming to the realization that the value they’ve just tried to enter is invalid.

To extend this to a thought experiment in the standard library, imagine if the requirements for the name parameter of the variable feature (cannot start with a number, no spaces or other special characters) enforced themselves automatically by deleting any invalid characters as they were entered. Clearly, this would be a disaster for the user experience, as lots and lots of people would likely be confused when they attempt to enter a variable name like My variable and it immediately snaps to Myvariable. Instead, the current behavior of explicitly highlighting the name field and displaying an appropriate error message (Variable names start with a letter and can only contain letters, numbers, and _) makes it clear to the user that the input is incorrect and gives them a chance to fix it in a way that makes the most sense to them.

And of course, you can always coerce values into updated bounds automatically when the bounds are changed in the first place. In the spur gear FeatureScript, when the tooth count is changed, the pitch circle diameter is automatically changed to match. If the diametrical pitch is then updated, ether the tooth count or the pitch circle diameter must then be updated to match, which is once again quite reasonable from a feature design perspective. Your bug shouldn’t affect this type of behavior, as a field is never being overwritten immediately after the user submits it, only in response to another field changing.

antlu65

If your goal is to create dynamic bounds, I think you’re much better off simulating a standard out of bounds error (using the faulty parameters arg of throw regenErrror and reporting the correct bounds in the error message) rather than overwriting the user input immediately to be in the correct bounds. The problem with overwriting the user input immediately is it isn’t always immediately clear to the user that their input has in fact been overwritten, or that the value they tried to enter was invalid in the first place. If they do in fact notice the value being used is different from the one they tried entering, their first reaction is very likely to be entering the invalid value again (thinking.that Onshape is bugging out and refusing to accept their input) rather than coming to the realization that the value they’ve just tried to enter is invalid.

To extend this to a thought experiment in the standard library, imagine if the requirements for the name parameter of the variable feature (cannot start with a number, no spaces or other special characters) enforced themselves automatically by deleting any invalid characters as they were entered. Clearly, this would be a disaster for the user experience, as lots and lots of people would likely be confused when they attempt to enter a variable name like My variable and it immediately snaps to Myvariable. Instead, the current behavior of explicitly highlighting the name field and displaying an appropriate error message (Variable names start with a letter and can only contain letters, numbers, and _) makes it clear to the user that the input is incorrect and gives them a chance to fix it in a way that makes the most sense to them.

And of course, you can always coerce values into updated bounds automatically when the bounds are changed in the first place. In the spur gear FeatureScript, when the tooth count is changed, the pitch circle diameter is automatically changed to match. If the diametrical pitch is then updated, ether the tooth count or the pitch circle diameter must then be updated to match, which is once again quite reasonable from a feature design perspective. Your bug shouldn’t affect this type of behavior, as a field is never being overwritten immediately after the user submits it, only in response to another field changing.

As I stated, it would depend on the scenario. For a critical input, it would obviously be appropriate to throw an error and force the user to choose a new input. For a less critical input, it *may* be preferable to simply overwrite the value and proceed with execution in order to ease workflow - particularly for numerical values. This would have to be used judiciously, because as you correctly note, the last thing we want is to give the user unexpected behavior. I agree that string values would be a poor choice for this.