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

Answers

• antlu65 Member Posts: 59 EDU

  July 2022

  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.

  0
• Alex_Kempen Member Posts: 250 EDU

  July 2022

  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?
  

  Software Developer at Epic Systems
  FRC Design Mentor - Team 1306 BadgerBots
  
  
  

  0
• antlu65 Member Posts: 59 EDU

  July 2022 edited July 2022

  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.

  0
• Alex_Kempen Member Posts: 250 EDU

  July 2022 Answer ✓

  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.
  

  Software Developer at Epic Systems
  FRC Design Mentor - Team 1306 BadgerBots
  
  
  

  0
• antlu65 Member Posts: 59 EDU

  July 2022

  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!

  0
• Alex_Kempen Member Posts: 250 EDU

  July 2022

  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.

  Software Developer at Epic Systems
  FRC Design Mentor - Team 1306 BadgerBots
  
  
  

  2
• antlu65 Member Posts: 59 EDU

  July 2022 edited July 2022

  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.
  

  0
• dbaarda Member Posts: 13 ✭

  May 7

  I've been fiddling with this and I think there are possibly a few things going wrong here, and I think it's because the Spur Gear feature is trying to be a bit too smart, and maybe also the https://cad.onshape.com/FsDoc/uispec.html#editing-logic-function-arguments editing logic function is not always getting triggered when some things change. Others have encountered problems too like;

  https://forum.onshape.com/discussion/22498/why-doesnt-the-spur-gear-feature-script-update-properly-when-using-a-variable-studio

  
  
  Things I've noticed are;
  
  1. If I create a variable or configuration variable and use it as the value in in the Spur Gear feature's feature UI, and then later the value of that variable is changed, the editing logic function is not triggered. The Spur Gear feature uses the the editing logic function to re-calculate the pitchCircleDiameter input when the numTeeth or module inputs change, and re-calculate the the module input if the PitchCircleDiameter changes (because PitchDiameter=Module*numTeeth). So when I use a variable to set the module value in the UI, and then change the variable value, the pitchCircleDiameter is not correctly updated. I can see that the module change is applied because it also affects the length of the gear teeth and I can see them change, but the gear doesn't correctly increase in diameter.

  2. If I do set some of these UI values with variables and/or configuration variables, and then do something that does trigger the editing logic function like change something else in the UI, the re-calculation logic it uses overwrites all those variables with the re-calculated values. This is pretty obvious when I encountered it, but it does complicate trying to drive it with configuration variables. It's particularly complicated because the config UI actually has 3 different ways to configure the module value using different settings that hide/unhide depending on a gearInputType dropdown selection, and all of these are recalculated when the editing logic function is triggered.

  I'm not sure if the editing logic function not being triggered for variable changes is a bug or not, but even if this was changed it would just make problem 2. above worse, making it even harder to use and drive this with configuration variables. So I'm inclined to see it as a convenient feature :-)
  
  I'm going to have a bit more of a play with this and see if I can figure out how to make it work. Failing that, I'm going to fix the featurescript, because I've already done some other work on improving it.

  0
• Caden_Armstrong Member Posts: 263 PRO

  May 7

  Editing logic only triggers when the feature dialog is open and the user modifies inputs of the feature (or manipulators).
  
  Editing logic is best at setting default parameters. The calculation of teeth/pitch/diameter should take place in the main body, editing logic removed, and then the user is given an option of which combination of parameters to use, using if/else in the predicate to show/hide the appropriate fields.
  
  Editing logic can solve a lot of tricky problems, but it has its downsides.
  I'd love to see an option to make the editing logic function trigger on regen - it would solve some of these types of headaches.

  www.smartbenchsoftware.com --- fs.place --- Renaissance
  Custom FeatureScript and Onshape Integrated Applications

  0