Curious to compare notes - not sure if I did something wrong, or if changes made under the covers in the recent update account for what I'm seeing.

I downloaded and ran the install for the WFB upgrade, and the installer - pretty much as expected - suggested that the old version would be uninstalled first and asked if I was OK with that. I agreed, and the installation completed. I loaded up the form I've been using in my current project, all looked good, so I saved it again and exported it again (manual server setup).

I realize now that what I'm describing is not part of the officially supported function, it would appear that I really can't count on internals (that end users normally don't see), to remain unchanged from release to release. In my case:I pull the form dynamically into my webpage on page load, and when a user clicks the submit button, I have a jQuery script listening for the button click event, performing some form-level (inter-field) validations (such as one field cannot be greater than another, etc), and only proceeding to submit to the next page if all validations check out.

First thing I noticed upon merging the newly exported form to the website: my form validations no longer worked. I did some checking and found that, under one version of WFB, the button is assigned the ID:

"fb-submit-button" while in the other version of WFB, the button ID is:

"fb-custom-button"

For those family with jQuery, you can understand why my jQuery script couldn't bind to the button using the old name anymore. Took me a while to find this, as there was no error -- just that the script had no button by the old name to bind to.

I modified my jQuery script to bind to the click event of the button with the new ID, and it appears that the script is firing properly again. I'm just wondering -- was this due to something I did, or is this just one of the internal changes that will always use this new ID for the button?

I know that I can't expect the parts of the product that aren't officially offered to developer to remain unchanged. A bit frustrating, but understandable from CoffeeCup's perspective. I have to check deeper though, because it's also perfectly reasonable to anticipate that the field ID's may have changed as well - potentially rendering some or all of my validations that examine the fields non-working.

I'll start digging through all of the generated code more closely tomorrow, but I'd suggest that anyone writing low level code that refers directly to the submit button and/or input fields keep a backup of the prior version of your form, and check the generated html against your hand-written code. While I'll be able to eventually work around this -- and I understand full well that what I'm doing isn't part of the officially supported product -- I've just bought myself several hours of work to figure out what how much of my code still works, and how much has to be revised. If others have a similar need, be sure to set aside time in your project to allow for such changes.

According to the email I got covering the latest update, there was a change made to how the 'submit' button works. That probably accounts for the change in the ID. I don't know about other changes.

Basically, this program was developed for 'ease of use'. When you add code from outside the program you will always be at risk for changes made to the program. Hopefully it won't happen too often...but who knows

Jon this is part of the submit button being able to be controlled with the built in conditionals. This way you can show and hide based on user input. Not totally sure about it handling the depth of need that you had but definitely fills the needs of several users on the forum.

Thanks guys -

I do understand - really - and know that what I'm doing is outside the realm of "supported features". I'm not complaining so much as having been surprised (although my surprise was probably not reasonable either!). The added value of the conditional display of the submit button is one of several valuable enhancements, and the innards are up to CoffeeCup of course. I'll just have to figure out what's changed that might impact my code.

OK...this is a bit embarrassing... I suspect that the changes that I thought I saw in the code generated by Web Form Builder probably aren't a result of anything that changed in the tool itself. I'm pretty sure that the differences are actually due to modifications I made to the generated code from the last version -- long enough ago so that I had forgotten all the changes I had made.

My apologies!!!

This goes back to an earlier question I had re: more complex inter-field validations before a form could be submitted, such as "the value in field A must be greater than the value in field B", etc. Back then, I didn't know what the CoffeeCup JQuery procedures had hooked -- the submit button click, the form submit event, or what. Rather than breaking the built-in validations, I hid that official button on the page, and added my own that *looked* like the original, but had an element type of "button" instead of "submit". On click, I have a jQuery routine evaluating the form -- if the validations find errors, they notify the user who then has a chance to fix them and try again. If all the validations pass, my routine silently "clicks" the hidden "official" submit button. To make this work, I had to modify the html form that WFB generates, as well as the "default.css" so I could hide the official button and display my new one. I haven't had to the touch the form in weeks -- and so had forgotten that I did all that! When I downloaded the new version and generated the form code again, all the custom html and css was overwritten...THAT's what I had forgotten needed to be re-applied.

Again -- my apologies for raising a confusing issue that probably isn't an issue at all!

All is good. Simple mistakes make for simple solutions. Even though I know it's a pain to put it back in, but it's really not that bad. After you do it a few times you start remembering where it all goes.