confusing slider behavior and slider question

[myrealemai...@gmail.com]

I am running on Android 4.4.2, iViewer 4.0.201. I have a page with a two buttons, a slider - join a1, a static text field, and a text field that I have set the join to s10. I have the min value for the slider set to -161, and the max value set to 33. I am listening in javascript for the the slider pressed, slider dragged, and slider released events. I have 3 tags set for the slider "receiver", "vol", and "s10". When I get any one of those events, I add an extra tag to the tags array that comes through. For the on pressed and dragged events, the tag is "set". For the on released event, the tag is "get", but I am not using the "get" at the moment. I also have three tcp systems setup, one for receiver, one for LANBridge, and one for a custom service I have running on my android. I am not using the custom service in iViewer.

When I get the on pressed/dragged events I call a "ProcessCommand" function in a "true singleton", i.e., the singleton has a getInstance function, and in that "ProcessCommand" function, I get [sliderval] from the tokens array, convert it to a number, divide it by two, and then convert it to a string using .toFixed(1) so that it has one decimal place. I then set a command string to the volume command for my receiver, and I concat the value string to it. I then use the "receiver" tag to CF.send the command to my receiver appending \x0A\x0D to the string and using CF.UTF8. When the command returns to the on pressed / dragged / released event handlers, the "set" and "get" tags that I appended to the tags array are removed using array.splice(index of "get"/"set", 1)

As far as I can tell, this all works great - that is, my receiver gets the value and sets the volume level to the value sent.

As I understand the slider documentation on the wiki, sliders have an analog join who's value ranges from 0 to 65535 and this value is supposed to be independent of [sliderval].

Here is where I am confused: When I get the "set" command, I call CF.setJoin with s10 as the join, and a string which amounts to [sliderval] / 2 + the string " dB" to indicate the volume level that was sent to the receiver in text on the UI. However, even though I have explicitly set the join to "s10" (both with a hard-coded string and with the value passed in the tags array), the call somehow sets the value of the analog join "a1" which is attached to the slider to [sliderval] / 2, and the indicator on the slider disappears. The text field associated with this join does get set to "[sliderval] / 2 dB" as I would expect. I had searched this group for how to handle this situation, and I believe this approach has been suggested to others trying to do essentially the same thing. One time, iviewer crashed, and I did submit a bug report.

Note that if I comment out the call to CF.setJoin("s10", "volume string"), then the analog join stays at its current value, and the slider indicator stays fixed at its current value.

Am I doing something incorrectly? I do not see any indication in the properties for the controls that would give me the impression that the text field's serial join would somehow become bound to the slider and its analog join. So I am confused.

Here is the question I have which is independent of the above:

Would using CF.setToken("a1", "[sliderval]", value) be the correct approach to setting [sliderval] after querying my receiver for its current volume level?

Thanks.

Matthew

[myrealemai...@gmail.com]

So it would seem that the project code is worth a thousand posts like my original one for anyone who would like to try to recreate what I am seeing with CF.setJoin in my code. The code is attached.

[myrealemai...@gmail.com]

How things got in this state, I am not sure. However, it does look like the serial join was bound to the slider as when I selected it in the debugger, it listed that it was connected to the slider. I even tried assigning a different join number to the text field, yet this new join number was still attached to the slider.

After some tinkering, I did get it to work finally. In the process, I used the join manager to clear all the joins in the project, then recreate the appropriate joins without recreating the rogue join. However, the debugger still listed the rogue join and that it was attached to the slider.

So, my process was to:

1. Delete the text field that the rogue join was assigned to. (This still did not delete the join's attachment to the slider.)
   
2. Put in another text field.
3. Assign the new text field a different serial join number (s5 in my case).

At this point, I was able to set the value of the text field through the s5 join without it affecting the slider / analog join value. In the debugger, the rogue join still existed, and it was listed as still attached to the slider. Eventually, however, the rogue join disappeared from the debugger.

A rather frustrating experience, but it is working now.

[Scott Ahlers]

 

Best Regards,

Scott Ahlers

Scott Ahlers

Integrator/Designer

Direct (949) 407-5902

Fax     (949) 242-2929

At this point, I was able to set the value of the text field through the s5 join without it affecting the slider / analog join value. In the debugger, the rogue join still existed, and it was listed as still attached to the slider. Eventually, however, the rogue join disappeared.

A rather frustrating experience, but it is working now.

--
You received this message because you are subscribed to the Google Groups "CommandFusion Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commandfusio...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jarrod Bell]

So the answer was quite simple after understanding your problem more - thank you for the updates and feedback, pointed me in the right direction.

The answer: joins and tags are both basically the same thing. So when you do CF.setJoin("s10", "some value"); any object on serial join 10, or with a tag "s10" will be assigned the value.
So because you had a tag "s10" on your slider, it was being updated as well. So instead of using an actual join number as a tag, use something else.

I suspect your solution worked because you no longer had "s5" as a tag on the slider.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

At this point, I was able to set the value of the text field through the s5 join without it affecting the slider / analog join value. In the debugger, the rogue join still existed, and it was listed as still attached to the slider. Eventually, however, the rogue join disappeared.

A rather frustrating experience, but it is working now.

--

[myrealemai...@gmail.com]

Thanks, Jarrod.

That is good to know that if there is a tag on a GUI object that it is essentially considered the same as a join. I will keep that in mind, and refrain from using tags that equate to a join in the future in cases where it may cause difficulties.

In an effort to make my code more generic, I was using that tag to tell me the serial join I needed to update with the volume level text.  I am doing things differently now than I was. My receiver pushes an update (for the receiver interface I am currently using) on each set for some of its settings - volume being one of those. So I am handling this as a feedback event rather than something that needs to be done when the slider is changed.

Honestly, to me sliders seem more complicated than they need to be, although, at this point this is a bit off-topic.

[Jarrod Bell]

Yes sliders are quite complicated because they have to deal with so many different scenarios.
They are extremely flexible this way. The only thing missing is the ability to call JS natively from the slider, rather than via the roundabout way of via a command.
This is something we will be addressing in future releases.

Your method of using feedback to update data values is a more preferred approach so as to use real-time (not faked) feedback anyway, so good idea to change tact.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

--

[myrealemai...@gmail.com]

I do have another annoying issue.  What I am seeing is that if sliding the slider, the feedback is causing the slider to jump. Unless I switch to the receiver's other, xml based interface, the updates are pushed out and there is no way to turn them off.

So, what I see is that the slider jumps around and is not smooth at all. What I suspect is happening is that by the time the feedback gets to the slider, the slider is where it should be, and the feedback is a step or two behind. If I do not set the slider using feedback, then the slider slides smoothly. I have tried various ways to mitigate this, using a flag, checking to see if the sliderval on the join is already equal to what it is being set to, etc., but nothing really seems to work properly - mainly because there is no indication in the feedback of what caused the feedback in the first place other than the feedback is a result of a change in volume.

Any suggestions?

[Jarrod Bell]

Use the digital join of the slider to know when your finger is on it.
Whilst that digital join is active, ignore feedback.

Or disable simulation mode, and only show realtime feedback (as fast as the device can send it back).

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com