Remote set of range slider

Seems like I am missing something for a remote set of a range slider

The following will only set the first value:
receive('/SET', "range_matrix/0_val_rslider", 1, 1200)

How do I set the second value?

Thanks!

I am now realizing I have the same question for setting the values of a canvas as well.

Perhaps it is by design, but if I call this twice then it sets both values.

It's supposed to work with a single message. It works as expected with a minimal session here, could you please upload your session file so that I can check what's causing this ?

Note that /SET is meant to simulate a user interaction (it makes the widget send its message), if you only want to update the value of a widget you can send a message that matches its address and preArgs (the same message it would send itself when interacted with)

same situation seemingly with the direct address (thanks for pointing that out btw):
receive("/range_matrix/0_val_rslider", ...model.ranges[0])

Perhaps it is a problem that the slider is in a fragment. The canvas also seems unresponsive and is in a fragment within a fragment

attached is the session files as well as the fragments which go in a framents folder at the level of OpenStageControl. I also attach my current custom-module.

Thank you for your help.
seeds_and_ledgers_gui.json (84.1 KB)
env.json (12.4 KB)
dur_probs_panel.json (3.3 KB)
slider.json (4.7 KB)
range_slider.json (4.9 KB)
custom_module.js (9.1 KB)

The issue with the range slider is not related to the use of fragments, it's a circular update issue (the range updates two inputs, and the first input that gets the value erases the second value before the second input gets it by triggering the recalculation of the range's value property). I'm not sure yet how to fix it properly yet, I'll keep you posted.

Regarding the canvas issue, it doesn't seem to be the same problem although I must admit I didn't dig very deep here. First I'd suggest to get rid of all @{} calls in the scripting properties, as they are likely to cause unexpected behaviors (advanced syntaxes should be avoided in scripts as stated here)

Amazing. I was just about to write back that I also diagnosed the first problem accordingly. Keep me posted.

I missed that even getting the id could be problematic using advanced syntaxes. I will clean this up and get back to you.

Thanks : )

Well using only the id should be safe since it's not supposed to change a lot, but then you're just a step away from using some widget's value and that's something you don't want :).

Thanks. I will clean it up just to be safe. Also... just to be sure... in a fragments props, is it ok to use an advance syntax?

Yes it is, but do mind that these will be resolved at the fragment widget's scope before its content is generated. The matrix widget has a mechanism to circumvent that (see the description of matrix.props), I didn't think of porting it to the fragment widget but it might be interesting.

I think I am confused a bit. Forgive me.

I have a fragment with a custom variable: "grandparent": @{parent.id}, which passes its parents id. In that fragment is a panel which inherits its variables from parent. In that panel is a slider. in the slider onValue script:
console.log("@{parent.variables.grandparent}")

works. what would be the kosher way to do that without using advance syntax? the actual test I am making is this:

if("@{parent.variables.grandparent}" !== 'undefined') {
  set("@{parent.variables.grandparent}_vals", value);
}

I am basically saying. Is there a grandparent? If so, set the variable widgets value. Essentially propogating a value from a grandchild to its aunt/uncle.

That'd be the way to go in scripting properties

var parentVariables = getProp('parent', 'variables')
if (parentVariables.grandparent) {
  set(parentVariables.grandparent + '_vals', value)
}

I found a fix for the first issue, to be included in next release.

Great! Thanks for all. I cleaned up everything with your help. No advanced syntax in any scripting anywhere. I will keep you posted if I can get the nested canvas to set properly.

just an update that I fixed my canvas issue. It had to do with how I was handling stringifycation of arrays. Nothing related to the above. I build my own breakpoint envelope editor. It would not be suitable for prime time use given the problem I just fixed. But it would be a nice widget to have in the collection.

Again, thanks for all your help. Things are going swimmingly and the next release will fix that small issue.

1 Like