Toggle button

[myrealemai...@gmail.com]

I am expecting that if I put a button on a page, and set in the properties simulate feedback, toggle button, and a non-zero digital join that when I press the button in iViewer that it should toggle its state without my doing anything extra. I found a button that has on and off graphics and used that to create the button, however, the button still acts as if it is a momentary button when I was expecting that the first press would turn it on and it would stay on until I pressed it again.

So, to maintain the pressed state, do I have to set the button's digital join to 1 when the button is pressed, then back to 0 the next time the button is pressed?

Thanks.

[Jarrod Bell]

Toggle works exactly as you described it.
Sounds like something else in your project is setting the joins back low.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

--
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.

[myrealemai...@gmail.com]

I'll have a look to see if I can spot anything.

After I was unable to change an existing button to a toggle button, I created a new page, put a button on the main page that navigated to the new page, put a button on the new page, and set its properties to simulate feedback and toggle, and assigned a digital join. I did not set any tags on this button, nor do I have tags on any of my other controls that refer the digital join for the toggle button. Also, I did not have any commands assigned to this button, nor did I set a watch on the button through js. I thought it might show me whether there was some misconfiguration on the button that I tried to convert to a toggle button. Yet for whatever reason, the toggle button on the new page behaved the same way, i.e., it acted like a momentary button - and that is when I posted the question about how a toggle button should behave.

Due to our conversation in another thread where I learned that if the tags for a control have a join number in them and I set that join, the join for a control having that tag will also be set, let me pose the following question as a hypothetical:

If I set a number of controls with a tag, e.g., "receiver", then I CF.setJoin a join that is specific to only one of the controls that has the receiver tag, will all the joins attached to the controls that have the receiver tag be set? If so, then I will have to alter my attempt at generic code perhaps setting a variable in js with the join that is intended to provide that command.

Thank for your patience while I learn CF.

[Jarrod Bell]

When using tags in CF.setJoin(s), the only object affected will be the object using the specific tag(s) you use in the call.
The fact that other tags are in use does not come into play in this situation. So your existing setup should be fine.

Very strange about your toggle button - do you have an interlock module in use by any chance? And have a global token setup to manipulate the interlock?

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

On 4/03/2015 5:02 am, myrealemai...@gmail.com wrote:

I'll have a look to see if I can spot anything.

After I was unable to change an existing button to a toggle button, I created a new page, put a button on the main page that navigated to the new page, put a button on the new page, and set its properties to simulate feedback and toggle, and assigned a digital join. I did not set any tags on this button, nor do I have tags on any of my other controls that refer the digital join for the toggle button. Also, I did not have any commands assigned to this button, nor did I set a watch on the button through js. I thought it might show me whether there was some misconfiguration on the button that I tried to convert to a toggle button. Yet for whatever reason, the toggle button on the new page behaved the same way, i.e., it acted like a momentary button - and that is when I posted the question about how a toggle button should behave.

Due to our conversation in another thread where I learned that if the tags for a control have a join number in those tags, let me pose the following question as a hypothetical:

If I set a number of controls with a tag, e.g., "receiver", then I CF.setJoin a join that is specific to only one of the controls that has the receiver tag, will all the joins attached to the controls that have the receiver tag be set? If so, then I will have to alter my attempt at generic code perhaps setting a variable in js with the join that is intended to provide that command.

Thank for your patience while I learn CF.

On Tuesday, March 3, 2015 at 12:19:44 AM UTC-5, Jarrod Bell wrote:

Toggle works exactly as you described it.
Sounds like something else in your project is setting the joins back low.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

I have not setup either an interlock module or a global token. I'm one to avoid globals wherever possible.

The file is essentially this one from this thread except that it is now in its mostly resolved form, and I have changed the js structure to separate the receiver commands and processing into their own js file / singleton. My plans are to not simulate feedback on the slider and let the feedback from the receiver set its value since that seems the cleanest solution.

The buttons that I tried to convert were the "up" and the "down" buttons. I assume that one should be able to convert from momentary to toggle at will. I am wondering whether there is something about those buttons that is causing the difficulty.

I'm programming in an exploratory mode. My intent was to see how it worked, then implement a few toggle buttons to control the sound programs on my receiver.

At this point, I am wondering whether the file is somehow corrupt. I have been copying the entire project directory before each change so that if I do not finish with my next task, I still have a working version to return to, so I am wondering if the copy has somehow caused a corrupted file.

Thanks again for your help!

[Jarrod Bell]

Can you send through the project again? The one in that link has no 'up' or 'down' buttons.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

Sorry about that. The project is attached. I have removed the extra page I put in. I have also noted that when running in the debugger, there are 4 digital joins that have numbers over 10,000. I did not put those in; I assumed that they are necessary. And lastly, I have not yet made the change to remove simulate feedback from the slider.

[Jarrod Bell]

Just loaded it up, and the "up" button toggles as expected.
Also I do not see any joins above 10000 in the debugger.

So I changed the "LANBridge" system (which is using the iViewer protocol for some reason, you should not do this as the LAN Bridge hardware does not understand the iViewer protocol) to point to a test TCP Server to see if that was causing the join changes.
Once connected, that didn't change anything either.

What version of iViewer are you using? I am testing on iOS (iPad Mini, OS 7.0.4) with iViewer v4.0.303

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

Interesting. We are always making jokes at work - "works on my machine." :)

I'm on Android 4.4.2, Galaxy Tab 3, 10.1 and iViewer 4.0.201. Here is a screenshot of the mysterious joins in the debugger (Chrome) using the exact file that I uploaded except that I turned off simulate feedback on the slider - which seems to respond much better unless the sliding motion is quick. The "Up" button is set to be a toggle, and it is not staying pressed.

Thanks for looking into this.

[Jarrod Bell]

OK so looks like an Android only issue. Can you test it on an iOS device?

Those joins relate to status bar visibility, and the iViewer protocol. Not sure why they only show up in debugger on Android.

Looks like we have some issues to resolve on Android. Thanks for the reports.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

I set the LAN Bridge to be a TCP client and the toggle started working. Then I set it back to iViewer protocol and the toggle stopped working. I set it back to TCP client and the toggle worked again. So it would seem that the toggle not working is related to using the iViewer protocol on the LAN bridge.

Note that the commands I have going through the LAN Bridge that execute rules on the LAN Bridge were working when it was set to iViewer protocol.

Also, I added a digital join to the slider (d3) and turned simulate feedback on again to test to see if that will provide a smoother experience, however, the digital join does not show up in the debugger for some reason. Perhaps there is something going on there.

I also have an iPad mini (iOS 8.0.3 I believe), and I could test on that, but I only have one license. At this point, though, it seems that the toggle not working is somehow related to having the LAN Bridge protocol set to iViewer. Since for you, the behavior is not the same (toggle works either way), it would seem (to me anyway) that further testing is not needed. Let me know if you would still like me to give it a shot.

Thanks again.
Matthew

[myrealemai...@gmail.com]

One more quick note, on trying to get the value of the d3 join I added to the slider when processing feedback, the value returns null.

[Hakan Lindestaf]

I seem to have a similar (except without the LAN bridge). I'm working on a server that will accept iViewer protocol (thanks for posting the protocol to the Wiki), and I too have a similar problem, my toggle buttons also send momentarily data when pressed/released, including the slider. This is on Android as well, I don't have access to an iOS device atm.

Thanks,

/Hakan

[myrealemai...@gmail.com]

Interesting.

I had set watches on the slider's pressed, dragged, and released events. When I had the iViewer protocol set for the LAN Bridge, I saw that I would get "released" events as I was dragging it. IIRC, I was also getting the pressed events as I was dragging the slider. Getting those struck me as strange. I tried that again last night after changing the LAN Bridge to be a TCP client, and I am no longer seeing the released events for the slider as I am dragging it.

[Jarrod Bell]

OK so it seems there is a bug relating to digital join changes not showing for sliders unless there is an iViewer Protocol system in place.

Can you try adding a button somewhere in your project on the same digital join, and seeing if that coerces the slider join to work both with and without an iViewer Protocol system?

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[Jarrod Bell]

The iViewer Protocol system does not respect button state, it sends messages relating to press/release events.
It is up to your server side to send back the join change to update the state in your project (but toggle simulation mode works independently of this, at least it is supposed to).

So any data you see on the iViewer Protocol system when you press a button is purely the events that are happening, not the button state.
This is documented on the wiki page where it mentions what commands are sent on button press/release. I will update this to make it more clear it has no relation to simulation mode.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

--

[Hakan Lindestaf]

Hmm, I feel that is concerning, it would render the toggle functionality completely useless since there would be no way to know if the button toggled on or off. Wouldn't it make more sense to send the toggle state over iViewer when a button is set to sim feedback=toggle? I can't see any reason why you would want the press/release in that case.

Thanks,

/Hakan

[Jarrod Bell]

The iViewer protocol is not meant for what you are trying to do. It is made for connecting to servers that control the feedback states of objects.
You cant have it both ways, either the server controls the state, or the simulation does.

Otherwise, do not use the iViewer Protocol. Use a normal TCP system and send commands/feedback as you need.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[Hakan Lindestaf]

But with the normal TCP system I would have to create a command for every single button, that's a lot of work compared to just throw a single iViewer system in there. I understand that it's up to the server to manage state with iViewer, no problem with that, but I think it would be better to allow both options (both server-side state and button toggle state), which you could if a button set to toggle would only send it's state, not the press/release. I can't see any downside to that. The server would receive the state and it could set the state if necessary.

/Hakan

[Jarrod Bell]

The downside is it will break existing systems that rely on being sent button press/releases, no matter what state is shown.
The protocol is for sending events. You should adjust your server side to handle this.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

I added another button and gave the slider and the button the same digital join number. In either case, with or without iViewer protocol system in place, the slider did not show up on the join while the button did.

It seems that there may be some confusion as to the digital join change on a slider showing up with an iViewer protocol system in place, so I tested this, too. Same thing. In either case, the digital join did not show up on the slider - that is simply that the digital join change on the slider is not showing up with or without a button on the same join and/or with or without an iViewer protocol system in place.

The onPressed and onReleased events that I mentioned as happening when sliding the slider with the iViewer protocol system present happened on the analog join.

HTH

Matthew

[Jarrod Bell]

OK we need to look into that and get a fix.

So the way to block updates to the slider whilst sliding is to use a flag that is set onPress and removed onRelease. Then when feedback comes in, if the flag is set, do not update the slider.
This is the best of both worlds, realtime feedback updates, and smooth simulated slider whilst dragging.

Maybe in a future release we can make that a simple option in a slider that has simulation mode enabled: "Prevent external slider updates whilst dragging".

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

[myrealemai...@gmail.com]

On Wednesday, March 4, 2015 at 9:24:19 PM UTC-5, Jarrod Bell wrote:

OK we need to look into that and get a fix.

So the way to block updates to the slider whilst sliding is to use a flag that is set onPress and removed onRelease. Then when feedback comes in, if the flag is set, do not update the slider.

 

I will try that and let you know. I have not tried it again since removing the iViewer protocol from my LAN Bridge. In that case, the flag was always clear by the time that feedback returned.

This is the best of both worlds, realtime feedback updates, and smooth simulated slider whilst dragging.

Maybe in a future release we can make that a simple option in a slider that has simulation mode enabled: "Prevent external slider updates whilst dragging".

To me, this sounds like the best approach. Otherwise, there is the possibility of a race condition developing which, given the iViewer protocol system, I am sure was behind the jerky movement of the slider.
 

[myrealemai...@gmail.com]

Just got a chance to try setting a flag in the onPressed event and clearing it in the onReleased event with simulate feedback set on the slider. So far, this seems to be the smoothest action for the slider.

[myrealemai...@gmail.com]

I am posting to this thread because I initiated it, and also either my understanding is incomplete, or there is yet another issue with iViewer 4.0.201 on Android. As I previously stated, I am using a Galaxy Tab 3 10.1 running Android 4.4.2 .

From what I have read elsewhere, my understanding of how a toggle button should work is that when the associated digital join is 0 and the button is pressed, the value of the join should be 0 when I receive the button press event in an OnObjectPressed handler, and if the button is pressed when the value of the digital join is 1 (i.e., the button is On), I should receive a 1 as the value of the join in an OnObjectPressed handler as I am watching for the pressed even through the digital join associated with the toggle button.

However, no matter what the associated digital join is set to, I always receive the value of that join as 1 in the OnObjectPressed handler. If I watch the OnObjectReleased event, the value of the join is always 0. This is happening for every toggle button that I create.

Am I missing something?

[Jarrod Bell]

Sounds like another bug in Android. Leave it with us.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

On 17/03/2015 12:57 am, myrealemai...@gmail.com wrote:

I am posting to this thread because I initiated it, and also either my understanding is incomplete, or there is yet another issue with iViewer 4.0.201 on Android. As I previously stated, I am using a Galaxy Tab 3 10.1 running Android 4.4.2 .

From what I have read elsewhere, my understanding of how a toggle button should work is that when the associated digital join is 0 and the button is pressed, the value of the join should be 0 when I receive the button press event in an OnObjectPressed handler, and when the value of the digital join is 1 (i.e., the button is On), I should receive a 1 as the value of the join in an OnObjectPressed handler as I am watching for the pressed even through the digital join associated with the toggle button.

However, no matter what the associated digital join is set to, I always receive the value of that join as 1 in the OnObjectPressed handler. If I watch the OnObjectReleased event, the value of the join is always 0. This is happening for every toggle button that I create.

Am I missing something?

[Jarrod Bell]

OK we have reproduced this one and will get it fixed in next Android app release.

During testing on Android, I could not replicate anything relating to buttons not actually toggling though. They always toggle state perfectly fine for me, with or without an iViewer Protocol system in the project.
I even tested your GUI you sent through again. So I could not reproduce any bug relating to toggling states.

Regards,

Jarrod Bell
CommandFusion
www.commandfusion.com

On 17/03/2015 12:57 am, myrealemai...@gmail.com wrote:

I am posting to this thread because I initiated it, and also either my understanding is incomplete, or there is yet another issue with iViewer 4.0.201 on Android. As I previously stated, I am using a Galaxy Tab 3 10.1 running Android 4.4.2 .

From what I have read elsewhere, my understanding of how a toggle button should work is that when the associated digital join is 0 and the button is pressed, the value of the join should be 0 when I receive the button press event in an OnObjectPressed handler, and when the value of the digital join is 1 (i.e., the button is On), I should receive a 1 as the value of the join in an OnObjectPressed handler as I am watching for the pressed even through the digital join associated with the toggle button.

However, no matter what the associated digital join is set to, I always receive the value of that join as 1 in the OnObjectPressed handler. If I watch the OnObjectReleased event, the value of the join is always 0. This is happening for every toggle button that I create.

Am I missing something?

[myrealemai...@gmail.com]

Thanks, Jarrod.

It sounds like we are seeing the same thing. Though I did not mention this in my post, the toggle states do work properly. That is, when the button is pressed, it goes to and maintains the appropriate toggle state, and also when set through its associated digital join, the button goes to and maintains the proper toggle state. My apologies for not mentioning this in my post. That was why I was questioning whether there was something I was missing because the button is in the proper state, but the value of the digital join from the OnPressed handler did not always match the state of the button.

Any thoughts of when there might be an update to the Android version? The main reason that I ask is that this can be worked around by maintaining a state variable for each toggle button in code, and I am wondering whether it might be worth it for me to do that.

Thanks again.

Best Regards,
Matthew