• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 471
  • Last Modified:

Submit button not working.

I have a ColdFusion webpage that displays one of two submit buttons, depending on logic.  One of the button submits the form as it should, the other does not.  The page works on our Development and Test webservers, and was working on the Production web server, but now is not.

Both buttons do the same thing, which is submit the form.  This is the code for the form header.

<form name="formname" action="webpagename.cfm" method="get">

Again, both submit buttons work on our Dev/Test servers, but one of the the buttons does not work on the Production server.  Code for button not working:

<input name="Lock" type="submit" value="Approve & Lock"/>
<input name="Unlock" type="Submit" disabled="disabled" value="Unlock"/>

I think it must have something to do with the server, and not the page.  

Any help is appreciated.
0
dkbailey1
Asked:
dkbailey1
  • 12
  • 8
  • 2
  • +1
1 Solution
 
ExpertAdminCommented:
Have you tried removing the disabled property just for testing it?

M@
0
 
dkbailey1Author Commented:
Yes.  I have even tried adding a new Submit button, but that doesn't work, but one of the existing buttons still does the submit successfully.
0
 
ExpertAdminCommented:
The only other difference I see it that you have "submit" (lowercase) on one and "Submit" (uppercase "S") on the other. There is no reason to think that would matter, but somthing has to be causing it.

Try making a copy of the one that works and see if you can get the copy to work as well. If you can, then modify it and see if it breaks. I will be thinking about what could cause this otherwise.

M@
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
dkbailey1Author Commented:
I was able to copy the Submit button of the one that works, and the copy did work!  Does this tell you anything?  None of this makes sense.
0
 
dkbailey1Author Commented:
Here is the IFTHEN logic that builds the buttons.  Both of the Unlock buttons in first part of the IF work.

<CFIF Query_Locked eq true>
  <input name="Lock" type="submit" disabled="disabled" value="Approve & Lock"/>
  <input name="Unlock" type="Submit" value="Unlock"/>
  <input name="Unlock" type="Submit" value="Unlock"/>                        
<CFELSE>
  <input name="Lock" type="Submit" value="Approve & Lock"/>
  <input name="Unlock" type="Submit" disabled="disabled" value="Unlock"/>
</CFIF>
0
 
dkbailey1Author Commented:
Just added the 'test' button.  Which I made as a 'new' button, not a copy, and it did NOT work.

<CFIF Query_Locked eq true>
  <input name="Lock" type="submit" disabled="disabled" value="Approve & Lock"/>
  <input name="Unlock" type="Submit" value="Unlock"/>
<CFELSE>
  <input name="Lock" type="Submit" value="Approve & Lock"/>
  <input name="Unlock" type="submit" value="test" />
  <input name="Unlock" type="Submit" disabled="disabled" value="Unlock"/>
</CFIF>
0
 
ExpertAdminCommented:
I am still seeing a variation in the usage of "S" and "s". Again, I don't see how this could affect it, but it is the only difference. Try making them the same.

M@
0
 
dkbailey1Author Commented:
Adjusted the 'S', no luck:

<CFIF Query_Locked eq true>
  <input name="Lock" type="Submit" disabled="disabled" value="Approve & Lock"/>
  <input name="Unlock" type="Submit" value="Unlock"/>
<CFELSE>
  <input name="Lock" type="Submit" value="Approve & Lock"/>
  <input name="Lock" type="Submit" value="test" />
  <input name="Unlock" type="Submit" disabled="disabled" value="Unlock"/>
</CFIF>
0
 
rob_lorentzCommented:
i suspect it might be the '&' in the lock buttons value. depending on how this gets encoded by the user's browser you might not be getting the value you expect. Type spelling it out. 'Approve and Lock'

0
 
ExpertAdminCommented:
I just noticed that you are ending your tag declaration with "/>". Again, not that I think this is causing the problem, but it should be simply ">".

Try this:

<CFIF Query_Locked eq true>
  <input name="Lock" type="Submit" disabled="disabled" value="Approve & Lock">
  <input name="Unlock" type="Submit" value="Unlock">
<CFELSE>
  <input name="Lock" type="Submit" value="Approve & Lock">
  <input name="Lock" type="Submit" value="test">
  <input name="Unlock" type="Submit" disabled="disabled" value="Unlock">
</CFIF>
0
 
dkbailey1Author Commented:
No luck.

<CFIF Query_Locked eq true>
  <input name="Lock" type="Submit" disabled="disabled" value="Approve & Lock">
  <input name="Unlock" type="Submit" value="Unlock">
<CFELSE>
  <input name="Lock" type="Submit" value="Approve & Lock">
  <input name="Lock" type="submit" value="Test">                        
  <input name="Unlock" type="Submit" disabled="disabled" value="Unlock">
</CFIF>
0
 
dkbailey1Author Commented:
Rob, tried that already.  No luck.  As a reminder, this page works on our dev and test web servers.  Thanks.
0
 
dkbailey1Author Commented:
Do webpages become corrupted?  Doesn't seem like they would, since they are basically a text file??
0
 
ExpertAdminCommented:
I noticed something else about your HTML that isn't quite right:

where you have disabled="disabled" it should be simply disabled. Like this:

<input type="Submit" name="Lock" value="Test" disabled >

But for now, lets dispense with the CF code and the disabled flags and get back to something that does work, then you can start adding code back.

 I would start here:

<input name="Lock" type="Submit" value="Approve & Lock">
<input name="Unlock" type="Submit" value="Unlock">

See if that works.

M@
0
 
dkbailey1Author Commented:
Just had sort of breakthrough.  I checked to see if the page would work on a different record, and it did!!  I have taken a closer look at the 'problem' record, and noticed that a set of parentheses is in one text field, and commas are in the text of other text fields.  When I took the parentheses out, the page worked; or, when I took one of the commas out the page worked!  This must have something to do with the fact that the form is using 'get' method.  Just a guess.  

Does this turn on any lightbulbs?  I think maybe the right solution for invoking the webpage is javascript.  All that the page does that is being submitted by the form is executing one of two UPDATE statements depending on whether a URL variable exists or not; then a CFLOCATION.

Any thoughts??
0
 
dkbailey1Author Commented:
Well, let me correct myself.  When I cut one of the text fields off of the web page, and then submit it, it works.
0
 
ExpertAdminCommented:
Can you post the offending text input? Maybe there is something wrong with the way it is defined.

M@
0
 
dkbailey1Author Commented:
I won't be able to do that.  But, there are six text fields that contain data on the page, when I delete around 30 characters in either one field, or a combination of fields, then the submit button will work.  Maybe there is a text limitation involved here somehow.
0
 
dkbailey1Author Commented:
I went ahead and wrote some javascript as a workaround.  Never quite understood what was the root cause, but enough has been lost.  Wish I could award points.  

Regards.
0
 
JeffHowdenCommented:
dkbailey1, don't let ExpertAdmin's suggestions for changing "/>" to ">" or disabled="disabled" to disabled mess with you.  If you're using an XHTML doctype, then your original code is completely valid.  However, the point about the cause of the "type" attribute value (submit) is accurate.  It *must* be in all lower-case.

I've a funny feeling this has absolutely nothing to do with the submit buttons though.  Instead, I think you need to dump the data to the page from the url scope and see if you're receiving what you expect or not.  I suspect that will illuminate the source of the problem.
0
 
ExpertAdminCommented:
JeffHowden,

Umm....I guess you didn't mean that to sound mean, so I am going to assume it wasn't intended that way. I clearly stated that I seriously doubuted those things were causing it, but was just trying to get down to something that did work. We never did get there.

M@
0
 
JeffHowdenCommented:
dkbailey1, there certainly seems to be a text limitation involved.  Most browsers have a limitation of 4096 characters long for the query string.  That's partially why it's highly recommended to use POSTed data whenever possible unless your form is very small (search box, for example).

ExpertAdmin, no, I wasn't meaning to sound mean.  I was just hoping the OP wouldn't keep those elements stripped from his code if he was using an XHTML doctype as that'd result in invalid code.  As an aside, "/>" isn't actually the best way to close non-container tags.  For optimal browser support, it should be " />" (notice the leading space).
0
 
ExpertAdminCommented:
OK. No problem. I agree with your suggestions on this too.

dkbailey1...if what JeffHowden suggested works, feel free to have an admin give him the points. I have no problem with that.

M@
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

  • 12
  • 8
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now