For Radio buttons, the communications: OnClickChangedSend allows a serial command to be sent.
This works correctly, in both directions. From (A) checked to unchecked and from (B) unchecked to checked.
This results in the same serial command being sent twice, whenever there is a change. The first from (A) and the second from (B). I have always assumed that only one command would be sent, for the unchecked to checked. This is not the case.
I don't believe that the initial command (A) is required, only the changed to the checked state (B) is really needed.
I'm not sure that sending two commands is intended. It has caused a problem as the actions of the first command sequence are not completed before the second command is initiated. This is generating errors. I can try to trap the first (A) command, but it really needs a proper solution.
Simplest, only allow the (B) command. This is the assumed case.
Create two command options. This would be an option to sent from unchecked to checked and a second option from checked to unchecked. This would allow different actions to be taken, the timing can then be managed by the user code.
Radio buttons: OnClickChangedSend behaviour
Short follow up:
to trap the command sent when the radio button "rName1" becomes unchecked, I added
!TCommandName [1 * rName1.CheckedAsByte] \r\n
The value of "rName1.CheckedAsByte" is then zero and can be identified in the code.
The checked radio button "rName2" has the equivalent command:
!TCommandName [2 * rName2.CheckedAsByte] \r\n
The value of "rName2.CheckedAsByte" is then an integer value and has a unique value, so the checked button can be identified.
The order that the commands from the two radio buttons are sent seems to be random. The error was caused when the second command was from the radio button that became unchecked.
to trap the command sent when the radio button "rName1" becomes unchecked, I added
!TCommandName [1 * rName1.CheckedAsByte] \r\n
The value of "rName1.CheckedAsByte" is then zero and can be identified in the code.
The checked radio button "rName2" has the equivalent command:
!TCommandName [2 * rName2.CheckedAsByte] \r\n
The value of "rName2.CheckedAsByte" is then an integer value and has a unique value, so the checked button can be identified.
The order that the commands from the two radio buttons are sent seems to be random. The error was caused when the second command was from the radio button that became unchecked.
Got creative and I think this would work for 2 or more radio buttons. MegunoLink interface file attached.
- Attachments
-
- Radio Button Test.zip
- (12.52 KiB) Downloaded 826 times