Radiogroups / Radiobuttons / Required Field

Hey John, The value for the one you want selected can be one of several combos. You could do any of the following: Selected | Not selected "x" | "" "true" | "false" true | false Any should work. For your field validator, try doing it this way:

.WithValidation(FieldValidatorBuilder.Basic().Required())

I think this will fix the issues you're having. Let me know!

Thanks for the quick reply. I've tried that as well and the issue is that it passes validation as-is (the user doesn't have to make a selection). The radio button concept I'm looking for must force a user to make a selection... think of it like a survey or a test you took in school. If you try to submit without answering a question, it will not let you (because there is no default selection you want to make) but you MUST have at least one selected before it will proceed. It appears the validation using your settings or mine is purely looking for a value that I can set or not set from the back end but then the user selection appears to not make a difference so validation of a radio group being a required selection is not working. Please try it yourself. It also appears that Silanis is forcing at least 1 radio box in the group be selected initially which also is not desirable. That would be seen as "leading" the customer. Thanks again for your help and next steps.

I was able to set both with value of "" which allowed both to start deselected. If I attempted to sign, I got an error that I had not chosen a value. Once I chose a radio button, it allowed me to finish the process. It sounds like this is what you're wanting. Here is the code for my two fields:

Field field1 = FieldBuilder.RadioButton("radiobuttons")
                                   .WithId("radioId1")
                                   .WithSize(20,20)
                                   .OnPage(0)
                                   .AtPosition(165,350)
                                   .WithValue("")
                                   .WithValidation(FieldValidatorBuilder.Basic().Required())
                                   .Build();
            Field field2 = FieldBuilder.RadioButton("radiobuttons")
                                   .WithId("radioId2")
                                   .WithSize(20, 20)
                                   .OnPage(0)
                                   .AtPosition(185, 350)
                                   .WithValue("")
                                   .WithValidation(FieldValidatorBuilder.Basic().Required())
                                   .Build();

Thanks Michael! Your code helped me indirectly and I do think we should launch a bug here. The whole time the issue was the name of the radiobutton. Your code worked as expected. When I setup my code exactly like yours, it still did not work. I started looking at the different parts simply guessed that maybe the radio button name (which is long) was the problem. It was. Apparently Silanis is building some javascript based on the radio group names and button names and it doesn't appear to like it's length, inclusion of period or inclusion of the groupname in the radio button name. Not sure which. My radio button name is "[client1.capture1.radiobox1.radiogroup1.required]" this is done so I can automate in the form fields themselves which radiogroup the radiobox belongs to. I took your extracted fields concept to the next level. I was setting the name to "client1.capture1.radiobox1.radiogroup1.required" once I simplified it to "radiobox1" only or "1" it solved it and my code started working immediately. I would like to suggest that Silanis either error elegantly when creating the package if this name convention is invalid or update their documentation around radio groups and validation to include what the limits around fieldnames, groupnames are.

Field field = FieldBuilder.RadioButton(srf.Group.ToString())
                                   .WithId(srf.Name.Substring(srf.Name.IndexOf("radiobox") + 8, 1))
                                   .WithSize(srf.Width, srf.Height)
                                   .OnPage(srf.PageNumber)
                                   .AtPosition(srf.X, srf.Y)
                                   .WithValue("")
                                   .WithValidation(FieldValidatorBuilder.Basic().Required())
                                   .Build();
                            userField.Add(field);

If you're using document extraction and extending the name of the field with values that eSignLive doesn't understand, I could see why there might be issues. I'd have to combine this with an extraction example to test on exactly what you're seeing. You can use extraction in a different way than in the extraction blog, I did. You can give all of your fields any name you want and extract the fields, still. The only difference is, eSignLive doesn't know what the fields are, so you'd have to define each, in your code, so eSignLive knows what to look for. You might try out this method to see if length is an issue, still, or if it's only when you're modifying the eSL naming convention for doc extraction.

Michael, thank you for the reply. Just to be clear, I'm not using Form Extraction on this document so don't take time to try that......I am however using the field extraction nomenclature on the original forms for a few reasons: 1. If a company is going to convert 300 forms and can use form extraction on 290 of them, I want their naming convention to be the same across all documents. 2. The field extraction while awesome for signatures and basic text boxes, is insufficient for my clients needs as several of them require required fields and radio grouping 3. I have made a feature request to VASCO as currently there is no way to use field extraction to signal radiogroups or if fields are required. 4. This code will (for the short term) be used only for forms that can not be field extracted and hopefully removed if/when VASCO supports the feature request to enhance field extraction The issue remains that something about the name of the field creates issues with your code or mine. It's either the periods or the length and the error is not an exception at creation time but rather unexpected results discovered by the end user. That is why I'm asking for a bug request to be created on the issue. Setting a field name to "client1.capture1.radiobox1.radiogroup1.required" causes the system to not work correctly. Regardless of the why, ESignLive API still allows the successful creation of the transaction. My request is simply to document and tell developers the rules for what is and isn't allowed in the fieldname or update the code to fail elegantly on the create package call that tells us that field name "client1.capture1.radiobox1.radiogroup1.required" is not valid. Does that make sense?

Yeah. I think I'm understanding, now. Thanks for your patience. :) I will pass this post along to support to create an enhancement request for document extraction to be able to include grouping capabilities for radio buttons and to file a bug for the field naming convention issue. You can also post any enhancement ideas in the "Enhancement Ideas" forum so others with the same issues can +1 the issue or add their own comments/workarounds. The eSignLive project managers also look at that forum regularly. https://developer.esignlive.com/forums/forum/general/enhancement-ideas/