General

About yourself
I am the owner and primary consultant for Core, my e-Signature consultancy with expertise in e-SignLive by Silanis, DocuSign and EchoSign. Prior to consulting I was a developer with U.S. Bank who implemented Silanis technologies for pennies on the dollar by building and leading a talented team to complete the project from start to finish. After deploying the system enterprise wide and growing to also own content generation (document generation) and parts of enterprise content management, I began speaking at conferences across North America about our success. It wasn't long after that I decided it was best to set off on my own, partnering with the top e-Sign vendors to help financial services and health care companies with their own successful implementations.

Account


Earned badges

Achievement: Latest Unlocked

Topic Started

Topics
I'm thinking there MIGHT be a bug but wanted to post here before claiming that entirely.

Replies Created

Reply to: Radiogroups / Radiobuttons / Required Field

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

Reply to: Radiogroups / Radiobuttons / Required Field

0 votes
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);

Reply to: Radiogroups / Radiobuttons / Required Field

0 votes
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?

Subscriptions

Topics Replies Freshness Views Users
I'm thinking there MIGHT be a bug but wanted to post here before claiming that entirely.
7 6 years 2 months ago 99

Code Share

This user has not submitted any code shares.