Editing Logic: Equal Lengths

EvanReese

I've set definition.myLength2 to equal definition.myLength1 with editing logic like this:

export function editTest(context is Context, id is Id, oldDefinition is map, definition is map, isCreating is boolean) returns map
{
    definition.myLength2 = definition.myLength1;
    
    return definition;
}

It works until I manually set myLength2 to something else, then it stops changing. If I manually make it equal myLength1 again it will keep up with it and match. Can someone explain why?

mahir

If you want them to always match, you can start by comparing values of definition vs oldDefinition. Depending on which input was edited, you could then update the other one to match.

MBartlett21

@Evan_Reese

You could try using a copyParameter (std | manipulator.fs), which is supposed to copy the value, including configurations and everything, like what happens in the variable feature (std | variable.fs). The variable feature copies the value to another parameter so that its formatting of the value in the feature title is correct.

The copyParameter function is marked @internal, so there is no docs in the FS library.

If the parameters need to depend on each other in a more complex way, you should probably add UIHint.UNCONFIGURABLE to the parameters to stop the user configuring them, like what happens (annoyingly) in Onshape's hole feature.

mahir

Shot in the dark, but maybe it has something to do with the editing function not being able to change myLength2 while it is still active or being edited?

mahir

If you want them to always match, you can start by comparing values of definition vs oldDefinition. Depending on which input was edited, you could then update the other one to match.

Fda

Escriba su comentarioIt seems to me something very interesting.

Do you think something like this could work?

<div>export function editTest(context is Context, id is Id, oldDefinition is map, definition is map, isCreating is boolean) returns map</div><div>{</div><div>&nbsp; &nbsp; definition.myLength_3 = definition.myLength_1 + definition.myLength_1;</div><div><br></div><div>&nbsp; &nbsp; return definition;</div><div>}</div>

The relationship between data.

[Volume] [density] [weight]

EvanReese

 Fda said:

Escriba su comentarioIt seems to me something very interesting.

Do you think something like this could work?

<div>export function editTest(context is Context, id is Id, oldDefinition is map, definition is map, isCreating is boolean) returns map</div><div>{</div><div>&nbsp; &nbsp; definition.myLength_3 = definition.myLength_1 + definition.myLength_1;</div><div><br></div><div>&nbsp; &nbsp; return definition;</div><div>}</div>

The relationship between data.

[Volume] [density] [weight]

You should be able to do make it calculate the relationship between some things if you have the right equations. If all you want to do is read the result then a reportFeatureInfo might be better than editing logic. If you used editing logic though, you could make it change other editable fields when one is changed. See the Spur Gear feature for an example of this. Editing "Pitch" changes the "module" too, and editing "module" also changes the "pitch".

EvanReese

mahir said:

If you want them to always match, you can start by comparing values of definition vs oldDefinition. Depending on which input was edited, you could then update the other one to match.

Thanks, Mahir. This is a made-up exercise to help me understand how it works, so I guess I don't want anything specific. This was helpful. I'm doing some more complicated editing logic on an actually practical feature, but I wanted to practice some basics first.

MBartlett21

@Evan_Reese

You could try using a copyParameter (std | manipulator.fs), which is supposed to copy the value, including configurations and everything, like what happens in the variable feature (std | variable.fs). The variable feature copies the value to another parameter so that its formatting of the value in the feature title is correct.

The copyParameter function is marked @internal, so there is no docs in the FS library.

If the parameters need to depend on each other in a more complex way, you should probably add UIHint.UNCONFIGURABLE to the parameters to stop the user configuring them, like what happens (annoyingly) in Onshape's hole feature.

EvanReese

Thanks, @MBartlett21 I always learn so much when you comment on things. To make sure I understand, you'd mark them UIHint.UNCONFIGURABLE so that the values cannot be changed from outside the feature, which wouldn't invoke the editing logic, so the values might not relate to each other correctly. Is that right?