Wondering if someone can suggest a solution/fix for the following:
I have a grid of switches that need radio button functionality by column (i.e. there can be only one button active by column). Also, one button always needs to be active in each column.
The following script executes on any change to expression x of the switch grid and it does the radio button thing (see below) however when I touch the currently active switch, Lemur always toggles the switch off. I'm stumped how to prevent this.
----------------------------------
decl i;
button_pressed = nonnull(seq_note_buttons_new - seq_note_vals.x);
bc = button_pressed%grid_cols;
for (i=0;i<sizeof(seq_note_vals.x);i++) if (((i%grid_cols)==bc) && (seq_note_buttons_new!=0) && (button_pressed!=i)) seq_note_vals.x=0;
seq_note_buttons_new = seq_note_vals.x;
----------------------------------
Any suggestions would be appreciated.
Regards,
Scott
Troubleshooting manual radio button script
Troubleshooting manual radio button script
Regards,
Scott
Scott
Re: Troubleshooting manual radio button script
Hi Scott,
Could you post the template so we can see how the script works within it?
radiobuttons can be tricky at first.. and there are a few ways to go about working with them.
You may be doing some or all of this.. or it may not apply to your template design, but I have been approaching radios like this:
1) initialize the state of buttons with an onload() script in the button container or right above it.
I typically use something like:
seq_note_vals.x=stretch(0,sizeof(seq_note_vals.x));
Then set the 1st button you'd like to have active with
seq_note.vals.x[buttonNumber]=1
Try to remember to array bounds (sizeof like you've used in the for loop) before assigning values to an existing button array, otherwise Lemur may crash and your work will be toast.
2) run an onchg() for x on the button object which is what it seems like you are doing.
Your code must be forcing the button to 0.
Have you tried using the firstof(x) to read the button?
button_pressed = firstof( seq_note_vals.x );
3) look at button array seq_note.vals.x in a monitor object. when i find myself wasting time
trying to figure out what is wrong with my Lemur logic, simply seeing what the variables currently contain
is an eye opener and time saver.
J
Could you post the template so we can see how the script works within it?
radiobuttons can be tricky at first.. and there are a few ways to go about working with them.
You may be doing some or all of this.. or it may not apply to your template design, but I have been approaching radios like this:
1) initialize the state of buttons with an onload() script in the button container or right above it.
I typically use something like:
seq_note_vals.x=stretch(0,sizeof(seq_note_vals.x));
Then set the 1st button you'd like to have active with
seq_note.vals.x[buttonNumber]=1
Try to remember to array bounds (sizeof like you've used in the for loop) before assigning values to an existing button array, otherwise Lemur may crash and your work will be toast.
2) run an onchg() for x on the button object which is what it seems like you are doing.
Your code must be forcing the button to 0.
Have you tried using the firstof(x) to read the button?
button_pressed = firstof( seq_note_vals.x );
3) look at button array seq_note.vals.x in a monitor object. when i find myself wasting time
trying to figure out what is wrong with my Lemur logic, simply seeing what the variables currently contain
is an eye opener and time saver.
J
Dashboard gear control templates: User 112 Idx :: LModIt Lite :: SVG image converter for Lemur Canvas
Re: Troubleshooting manual radio button script
Thanks for your reply J. Here is a somewhat revised template that doesn't work as well as the version I was talking about earlier, but does track last_button_pressed in each column. I believe that this is ultimately required for the template to work properly.
I seem to have 2 issues:
1) In order to handle both the "button off" and "activate new button" events, I have set the execution mode of the "action()" script (under the "seq_note_vals" switches object) to trigger on any change of expression x. This leads to the script re-triggering whenever I manipulate the value of seq_note_vals.x from anywhere within Lemur, including from within the script itself. These spurious re-triggers are modifying values iteratively and really confusing things. Is there a way of preventing an object's script from triggering except when triggered by the UI of object itself?
2) Because one button must always be active in each column, a second press of the currently active switch should not turn it off. To prevent this I compare the number of the pressed with the value of the switch last pressed in that switch's column (stored in the "last_button_pressed" array). If they are the same, the script turns the switch back on. Unfortunately the expression "button_pressed = nonnull(seq_note_buttons_new - seq_note_vals.x)" returns 16 (sizeof(seq_note_vals.x)+1) when my "before" and "current" switch state arrays are identical. This means I can't trap which switch was actually pressed to turn it back on. Is there another way of identifying which switch was last pressed other than by subtracting the "current state" array from the "previous state" array?
Apologies for the rambling. I'm quite confused here.
Regards,
Scott
I seem to have 2 issues:
1) In order to handle both the "button off" and "activate new button" events, I have set the execution mode of the "action()" script (under the "seq_note_vals" switches object) to trigger on any change of expression x. This leads to the script re-triggering whenever I manipulate the value of seq_note_vals.x from anywhere within Lemur, including from within the script itself. These spurious re-triggers are modifying values iteratively and really confusing things. Is there a way of preventing an object's script from triggering except when triggered by the UI of object itself?
2) Because one button must always be active in each column, a second press of the currently active switch should not turn it off. To prevent this I compare the number of the pressed with the value of the switch last pressed in that switch's column (stored in the "last_button_pressed" array). If they are the same, the script turns the switch back on. Unfortunately the expression "button_pressed = nonnull(seq_note_buttons_new - seq_note_vals.x)" returns 16 (sizeof(seq_note_vals.x)+1) when my "before" and "current" switch state arrays are identical. This means I can't trap which switch was actually pressed to turn it back on. Is there another way of identifying which switch was last pressed other than by subtracting the "current state" array from the "previous state" array?
Apologies for the rambling. I'm quite confused here.
Regards,
Scott
- Attachments
-
- col_radio_button_sandbox.2.1.jzml
- (10.64 KiB) Downloaded 144 times
Regards,
Scott
Scott
Re: Troubleshooting manual radio button script
Hi Scott,
I've attached a more simple example using pads, not checked with the lemur (only on Lemur Editor)
Hope that helps,
Cheers,
I've attached a more simple example using pads, not checked with the lemur (only on Lemur Editor)
Hope that helps,
Cheers,
Re: Troubleshooting manual radio button script
Thanks very much Antonio. This is exactly what I was looking to do.
I see you have taken a very different approach to this task. There is a lot for me to learn here.
The Community rules.
Regards,
Scott
I see you have taken a very different approach to this task. There is a lot for me to learn here.
The Community rules.
Regards,
Scott
Regards,
Scott
Scott
Re: Troubleshooting manual radio button script
Hi Ahone,
You'e welcome, glad to know that helps,
Cheers,
You'e welcome, glad to know that helps,
Cheers,
Re: Troubleshooting manual radio button script
Thanks again Antonio. Your approach shows how well you understand Lemur. It is very simple and elegant. I learned a lot from it.
Regards,
Scott
Scott
Re: Troubleshooting manual radio button script
this is a what ive been looking for!, however, how do i get it to work so that i have 10 buttons going up and 4 across? Where do i alter the code? also i found a small bug... i noticed if u touched more squares vertically which is cool, but the las row of 4, if u hold 2 boxes, u cant get rid of the second box...