close ad
WARNING PC USERS: Do Not Install the DREAMWEAVER CC 2017 Update »
open ad
View Menu

Technical Support Forums

Free, outstanding support from WebAssist and your colleagues

rating

Reproducible BUG found!

Thread began 12/14/2009 12:30 am by beezodog304808 | Last modified 9/22/2010 10:28 pm by keith505 | 2747 views | 11 replies |

beezodog304808

Reproducible BUG found!

Here were the circumstances:

I created a form yesterday and applied verification to each of the required fields. I also attempted to filter each field of what I thought were invalid characters.

After having done this I today added another form to the page, just above the one from yesterday. This new form had a single button and no input fields. It allowed me to capture a button click and redirect to a new page.

The client sent an email and complained that the fields on the form created yesterday were not allowing enough characters. He want to be able to enter commas, pound sign characters and the like. My first thought was to add in the allowable characters and realized that simply omitting the alphanumeric validation would achieve the same effect, so I did.

I clicked the FINISH button and went to test the validation. The form kept complaining that a field intended to hold a ZIP CODE was invalid. I was stunned so I started checking what could be causing this.

It was then that I discovered that each of the fields as described in the ONSUBMIT portion of the FORM tag had the very same field name. I tried nearly a dozen times to get it to produce the validation text correctly but it would not.

Finally I decided to remove the first form and re-enter the page and try to add the corrected validations again. This time it worked. I ended by pasting the newly created form back into its location and everything worked well.

SUMMARY: The bug appears to be associated with the presence of the second form. Not sure why but it was repeatable.

Sign in to reply to this post

Jimmy Wu

Could you post a link to the page with the forms? Also were you applying client validation or server validation to the forms?

Sign in to reply to this post

beezodog304808

Reproducible BUG

Originally Said By: Jimmy Wu
  Could you post a link to the page with the forms? Also were you applying client validation or server validation to the forms?  



The URL to my test pages is here:

ppmemb.php

The validation was CLIENT side.

I worked again with this page and think that the problem is how the forms are specified. You are using ".forms[0]" in the validation code in the FORM tag. But the table that was added was ABOVE that form. So when the code is re-examined upon re-opening the page the position of the form in the page hierarchy has gone from ".forms[0]" to ".forms[1]". I am guessing that your code in the extension does not take this into account?

Sign in to reply to this post

Jimmy Wu

So I checked with another engineer and this is how Validation Toolkit works. When Form Builder came out, validations were updated to use the form id rather than the index. If you have CSS Form Builder, this error shouldn't occur when applying validations for that.

Sign in to reply to this post

beezodog304808

My concern is this...

Granted IF I owned the CSS Form Builder this would not have been a problem. But I bought the uppermost package you folks sell and it has a "bug". Are you now suggesting that I pay additional money to find a proper solution?

I just checked and see that what I purchased was the SUPER SUITE. However it appears that at the time CSS Form Builder was not part of the selected group of items. I purchased this suite fairly recently, so I am concerned that what I got (which has since been updated) leaves me "high and dry".

Does this seem acceptable?

Sign in to reply to this post

Jimmy Wu

I was just checking to see if you had Form Builder. I have already logged a bug under Validation Toolkit for this. For now, if you change where it references the form index:
form[0]

to reference the form name:
getElementById('form1')

where form1 is the name of the form being validated.

Then the validation will be applied to the correct form even if you add a new form above it.

Sign in to reply to this post

brennanm231363

Validation bug seems to be in current version

I see that the bug that was reported over a year ago is present in the current version. Is this going to be fixed?

Sign in to reply to this post

Jimmy Wu

It was logged less than a month ago, and I am currently unsure about when a Validation Toolkit update is scheduled to be made. Currently you can follow the steps to change the reference to be that of the form name and not the form index.

Sign in to reply to this post

keith505

I hate to chime in on an older post but I it still very relevent to me. I posted a complaint about this exact problem about a year ago (I know others had as well), and was told that PHP now only supports the form index and not the id... or something of that nature, so that is why the index has to be used from now on. The problem is that when dealing with forms when there is an include file above with another form, or when adding new forms above existing ones, the WA Validation gets confused. This has been one of the banes of my existence for the last year... whenever I have to update certain site with Validation Toolkit... I shudder because it has become so aggravating under these circumstances.

Sign in to reply to this post

steve355714

Unfixed bugs?! No purchase from me!

I was looking at this forum to see if Validation app is worth the money, or if the library payment is worth the money, when this is one of the apps I would use.

Reading this thread just convinced me not to go w/ the app or the library payment. Nearly every forum reports bugs & problems w/ software. (And my own purchase of the first version of CSS Sculptor left me very disappointed. The software is insanely slow -- it's really unusable except to generate an initial default site framework. I've heard later editions are faster, but this should have been fixed in the very first version. Plus, later versions of any extension here require purchasing later versions of Dreamweaver...)

Anyway, I just want to let WebAssist know that business can be lost when bugs are not fixed.

And, you know, there are developers out there who fix bugs within 24 hours of reports. Check out the support that Oleg provides at Metaproducts, for example!

Sign in to reply to this post
loading

Build websites with a little help from your friends

Your friends over here at WebAssist! These Dreamweaver extensions will assist you in building unlimited, custom websites.

Build websites from already-built web applications

These out-of-the-box solutions provide you proven, tested applications that can be up and running now.  Build a store, a gallery, or a web-based email solution.

Want your website pre-built and hosted?

Close Windowclose

Rate your experience or provide feedback on this page

Account or customer service questions?
Please user our contact form.

Need technical support?
Please visit support to ask a question

Content

rating

Layout

rating

Ease of use

rating

security code refresh image

We do not respond to comments submitted from this page directly, but we do read and analyze any feedback and will use it to help make your experience better in the future.

Close Windowclose

We were unable to retrieve the attached file

Close Windowclose

Attach and remove files

add attachmentAdd attachment
Close Windowclose

Enter the URL you would like to link to in your post

Close Windowclose

This is how you use right click RTF editing

Enable right click RTF editing option allows you to add html markup into your tutorial such as images, bulleted lists, files and more...

-- click to close --

Uploading file...