Using FM 7 and have a repeating radio button of Yes or No. I want to calculate how many yeses (and nos) and show this number to the user. Can someone suggest a script? Must I use Let variables? Any help is appreciated. Thanks again.
I would suggest a matching calc fields with the same number of repetitions. One where you turn Yes to 1, and another where you turn No to 1, for each of those calculated repeating fields you can then use Sum() to get how many Yes or No you got.
You could certainly use a script to get the same result, looping on your field repetitions, but there could be cases where you cannot turn to a script, so I mentioned the calc field option also.
Your suggestion sounds very good and effective but I don't understand what you mean by "matching calc fields". When I look it up it talks about importing and matching up the fields (which I am familliar with). I am sure I am just not looking at the right area. So can you elaborate for this beginner? Much appreciated.
I did try using a sum calculation and a summary type in the defining fields but I think I am missing a step.
I'm sorry for the confusion. I did not mean matching as when doing imports, I meant matching as they will mirror your data field. They are very simply regular calculation fields with as many repetitions as your data field. The calculation should be something like if( dataField = "Yes" ; 1 ; 0 ). Because it is a repeating field pointing to another repeating field, FileMaker should resolve the calculation by pairing each repetition. I hope this clarifies.
I suppose it depends how and when you need this information.
If you need this live, without the need for a find operation, then @Bobino's suggestion to use a calculation makes sense. Be careful as this will be an unstored calculation or a summary field… so the larger the record set, the longer the calculation time.
If you are OK with needing to perform a find to obtain the result, then you need not translate the radio button values into numbers. The found count will give you the value you seek.
Keep in mind there is a third value to your radio buttons: yes; no; no answer (empty). You will want to keep this in mind in your design. If a "no answer" value can't exist, you will need to either have a default value or a validation that barks at the user when committing a record.
Hope this helps.
yes it does clarify things...I will try it and get back to you. Thanks so much!
The calculation I'm talking about can be stored and indexed, assuming a repeating field holding data in the same table as the calculation table.
Off course, if you want to calculate total answers of one type for multiple records, this will rely on a summary field and, depending on your found set, may not give you the best performance.
sorry just see you are on FMP7 - then the WHILE to be replaced with a relationship
I don't have .fp7 FMP
here is a simple file without any tricks:
RepeatingRadioButton_FMSoup_7.fmp12 (280 KB)
PatternCount ( List ( RepeatingRadioButton_SelfJoin::RadioButtonVector ) ; "YES" )
PatternCount ( List ( RepeatingRadioButton_SelfJoin::RadioButtonVector ) ; "No" )
Relationship to the same record matching Primary Key
Ensuring that everything is done in v7 code is an interesting challenge. Variables don't arrive until v8 - something for you to look forward to @Jenyen 
but everything we need seems to be in the v7 toolkit.
I found it very easy to do with some fields, the script is only reporting on what they are calculating.
Step 1. Define the fields
Step 2. Fields on the layout
You can see that the amounts are easily calculated
Step 3. A script to display the results
3 Likes
You nailed it @Malcolm list function was not available in FMP7.
1 Like
So fascinating -- It was a trip down memory lane seeing the screenshot of field definitions in @Malcolm's post. There was a time when I had solutions with lots of fields like that...
1 Like
Brilliant! Thanks so much - this is exactly what I was looking for.
I know it is a very old version, so I appreciate it all the more 
Totally appreciate the effort and the link! Thanks.
1 Like
Suggest avoiding repeating fields for anything that stores data. Use a child table instead.
Repeating fields are painful to manage data and might be best sequestered to transient UI information.
LOL - Everyone says this about repeating fields I agree with you when it comes to major data storage...I'm just using them for something very simple and manageable. In future versions does FM develop this feature so it can be better used? I am using v7.
In this area, nothing has changed since v7; repeating fields are a legacy construct that the relational structure has all but replaced, and not expecting to see any enhancements to repeating fields.
The one place I use them is to populate a button bar segment set. Nothing stored, just UI stuff.