I made a checkbox to be required and this should not have been done. I can change it in the .fb file and export all over again but I have made several tweeks in the files that shall be lost so i do not want get the require state undone like this. In the validation.js file I saw the line with the checkbox required statement. I turned it into flase (kept the message) but this did not unrequire the checkbox. Are ther other locations or files that must be changed? Or is it the message that has to be removed also.

There's a lesson to be learned here...

Big Lesson: Do not edit your files for the forms until the form is completely finished so you don't have to worry about overwriting things later when you need to make changes.

Remove the word "required" from the html input.

@Jo ann, Some things have to be tweaked in the html and css file to customize the form. So the wise lesson does not really apply in this.

@Eric first of all thanks for the support you are offering me lately. In the HTML file the text input fields have "required" methods and this is what I first looked for and thought this could be solved quickly :-( . The checkboxes do not have a "required" method in the HTML form. In the validation file they are scripted with a "required". I removed required and the message but no improvement. Any other thoughts?

Thx

Solved, inthe html there is no adaptment needed, int the validation.js file look up the line and set the required to false, in the form.cfg.php look up in the rules (bottom section) and set numbers_required to 0 and set required to false.

And in the program it's just a check box on and off

What part of this can't be done and completed "before" editing your files manually Shark? Truly this is going to be a nightmare if you decide you need to add a field, remove a field, change the form in any way that requires using the program again so you're going to have to redo all your changes again if that happens. All I'm saying is make sure the form has all the fields, etc. that you need "before" you start messing with editing the code manually so that you don't have to worry about overwriting the files later for changes.

In your case maybe that is already done? The post didn't sound like it to me is why you got my comment Things like what you're trying to do with this right now being a "required" setup are done all right in the program, so that is what I meant by making sure it's all done first before you edit things like box sizes and adding jquery extras etc. That way all the possible changes that the program can make (which are many) will be done and you may not need to redo anything in the program later.

I think I missed something but you should be able to make your settings in the form builder because like Joann says you can set the number of boxes required in the form builder.

@Jo ann At first it had to be required on second thought it was not desired to be a required field, Forgot to perform this change and exported the files. Then started tweaking the CSS file, setting some values in the html form adaptation of the form.cfg.php file. With a total new export I would have lost all tweaks.
That is why I wanted to know where to change the file. You are wright whenever a new fieldneeds to be put in the form it'll take some more time. But my form is completly made to my standards and layout of the site.

@Eric yes in the builder it is made in a snap but due to tweaking this was not really applicable.

Th sunny side of this is that I understand the WFB code a lot better

Interesting topic -- and very timely for me. The ability to prototype and quickly generate code for sophisticated forms is great with WFB, but as Jo Ann and others note, if your project requires customization of the code *after* it's been generated, this is a one-way trip, and must be repeated any time you modify the design with WFB and regenerate code.

This isn't unique to Web Form Builder, but is common to workflows that include any type of automated code generation in which the final product requires manual code modifications. Jo Ann's "big lesson" is certainly apropos, but unfortunately this approach may be contrary to the principles of Agile development, in particular the notion that the team invites and embraces change requests late into the development cycle. Hopefully, with something like this, a form is a sufficiently self-contained item so that it can be defined pretty thoroughly early in the project lifecycle. Unfortunately, in my latest project, my client is identifying needed changes as the most complex form becomes increasingly useful, evolves, and is more thoroughly customized. No really graceful way to avoid it at this point. Hopefully I can convince clients to think through requirements earlier in the lifecycle next time around!

A thought however, and I realize that there's a thread somewhere here for suggestions to CoffeeCup, but I thought I'd float the idea here first.

Some code generators actually allow you to insert specially tagged chunks of code - tweaks, if you will - in a project, to be respected and preserved by the code generator on subsequent code generation runs. This could be via method overloading in jQuery, conditional code that looks for specially tagged custom code or external routines that users may (or may not) create, etc. Not a trivial exercise, and I'm not minimizing it -- but something like this would be a great enhancement for Web Form Builder down the road. Imagine, if you will, just one example of this: if your form (like mine), needs an additional layer of validation once the field level validations are done, e.g., the value in field 1 must be greater than the value in field 2, or a certain field becomes required if and only if 3 other fields have certain values, etc. A clean way to allow for this without impacting current users with less off-the-wall requirements might be: have the developer (us) write the form-level validation as a jQuery function that returns an array of messages -- if empty, there was no error -- if not, the errors are displayed and the form is not submitted. The name of this function could be optionally specified in Form Options.

Along with, and as an extension to this, it would be great if we could provide a unique identifier for each field in properties, so that our code could reference the fields without having to manually examine generated code, and without risking that the field names all change if we insert another field. I know that WFB uses DOM component ID's already -- perhaps any name a form designer provides could be inserted in the final code as an added CSS style, unique to the single field that it affects (or perhaps not -- maybe, like a normal style, application could be across multiple fields or controls if appropriate). However done, it would be great if we, as users, could assign unique selectors to form elements that jQuery code could refer to.

OK -- enough blue-skying for the moment. Apologies if this really should have been in another thread. My primary thought, though was triggered by the observation in the thread that customizations are undone any time the form code is regenerated.