PDA

View Full Version : Stop Return/Enter Key Submit



Dal
07-21-2008, 01:08 AM
Hi (New member today)

I need to stop my form from being submitted via the Return/Enter key.

When I use an attachEvent I get errors that this isnt a function. Can anyone correct me?




<script type="text/javascript">
//<![CDATA[

window.attachEvent("onkeydown", StopReturnKey);


function StopReturnKey(event)
{
alert("HELLO"); //just testing at the moment.
//if(event.keyCode == 13) return false; // I think this is what I need to do.
}

//]]>
</script>



Thanks
Dal :D

Dal
07-21-2008, 02:34 AM
Forget about the above.

I really need to stop enter key at all costs but I still need submit to work on my various buttons.

IE seems to have no issue but FF3 just keeps submitting with enter, I cant find anything but old posts on google.

Anyone got a document.EnterKey = "off" suggestion???
:confused::eek:
Kind regards
Dal

Jesdisciple
07-21-2008, 05:37 AM
You're on the right track. :)

Older versions of Firefox apparently use the 'which' property instead of 'keyCode,' but Firefox 3 (what I'm testing with) uses both. I was able to figure everything out except where to put the event handler; I tried the form-tag, but this page (http://www.arraystudio.com/as-workshop/disable-form-submit-on-enter-keypress.html) set me straight: You need one handler for each input element that the effect should apply to. Also, keydown is supposedly better than keypress; see Comment #19 at the above page.
<form><input type="text" onkeydown="return event.keyCode != 13 && event.which != 13;"><input type="submit" value="Submit"></form>(Using input.onkeydown in JS might also work; try it!)

jscheuer1
07-21-2008, 09:56 AM
This seems to work page wide, at least in limited testing:


<script type="text/javascript">
document.onkeydown = function(e){
e = e? e : window.event;
var k = e.keyCode? e.keyCode : e.which? e.which : null;
if (k == 13){
if (e.preventDefault)
e.preventDefault();
return false;
}
return true;
};
</script>

If you want to use the more up to date methods for adding the event:


<script type="text/javascript">
function killEnter(e){
e = e? e : window.event;
var k = e.keyCode? e.keyCode : e.which? e.which : null;
if (k == 13){
if (e.preventDefault)
e.preventDefault();
return false;
};
return true;
};
if(typeof document.addEventListener!='undefined')
document.addEventListener('keydown', killEnter, false);
else if(typeof document.attachEvent!='undefined')
document.attachEvent('onkeydown', killEnter);
else{
if(document.onkeydown!=null){
var oldOnkeydown=document.onkeydown;
document.onkeydown=function(e){
oldOnkeydown(e);
killEnter(e);
};}
else
document.onkeydown=killEnter;
}
</script>

seems to work fine too. The important 'trick' is that in functions assigned to events in FF and most modern browsers, the preventDefault object must be used if available rather than merely returning false. Some events cannot be interfered with though, however this doesn't seem to be a problem here.

Dal
07-21-2008, 02:57 PM
Thanks Jesdisciple and jscheuer1 :)



function StopReturnKey(event)
{
//alert(event.which);
if(IDBrowser != "IE" && event.which == 13) event.preventDefault();
else if(IDBrowser == "IE" && window.event.keyCode == 13) return false;
else return true;
}

//...
<form action="" name="myform" method="post" enctype="multipart/form-data" onkeypress="StopReturnKey(event);"> <!-- form tag (I upload some images hence the enctype attribute -->



I could have used your advice earlier this morning but unfortunatly I needed to get this working so after trying various methods posted on various boards across my google search I though of it logically and devised my own solution. I used onkeydown originally but thought that onkeypress might be a little more secure in capture, however Ill change this back as you stated Jesdisciple, onkeydown is still more conventional.

jscheuer1: there one hell of a size scripts for doing the job. :o Im sure I can use all of these methods if I need to fine tune. The main thing I wanted to avoid is slamming more event captures into each form entry so the form event capture does the whole lot. Seems to work in IE, FF, Opera and safari any other browser then you take your chances. I did however think that this type of event would be easily turned off/on via javascript, Im expecting too much from that though :p

Thanks again
Kind regards
Dal

PS: seems I got a lot more response from this forum than the ever dying programmingtalk forum (for javascript atleast). So thanks!

jscheuer1
07-21-2008, 03:23 PM
jscheuer1: there one hell of a size scripts for doing the job.

Not really, the shorter version you posted uses browser sniffing (almost always a bad idea) the code for which, if included, would make your function about the same size as my original version. I added the part that uses eventListener and attachEvent just for compatibility purposes should the script be used on a page that already had an onkeydown assignment, but its added code is generally not required. An advantage to my version as well is that it requires no assignments in the form(s) on the page. If you were to have a few forms, the added code from that included in your version would bloat it a bit more, relatively speaking.

Dal
07-21-2008, 03:39 PM
Cool, thats noted, Oh about my BrowserID function which I didnt include uses my own version of browser detection. It bases alot on the navigator.userAgent string which seems to work wonderfully accross all major browser types although the website will only utilise the latest technologies (no support for older browsers) I dont need to cover anything outside a specific scenario. Other event attachments are only geared towards the mouse (mousedown,mouseup and mouseclick) so this script will not have any consequence. I was looking for someone to answer me back the way you have jscheuer1 as I am a little in the dark with doing things my own way rather than googling ever script request so thank you. Im sure the script will serve its purpose for this perticular page but if I need to apply a tighter alternative I will certianly be back on this thread to pickup these scripts.

Kind regards and many thanks
Dal.
Is there an option to append this thread title with solved like programmingtalk forum or do I simply leave it open?

jscheuer1
07-21-2008, 03:53 PM
We generally don't close topics in these forums or mark them solved in any way. I can close the thread for you, but I'm not sure it needs to be, or that it is necessarily over. Others may have views. We usually just close a thread if it is getting somehow out of hand, or especially as happens with certain types of questions, becomes an invitation to spammers.

Now, I would hope that if you are sniffing the browser that you are using more than just the userAgent string, because that can be spoofed in Safari and others to make it appear to be IE, but once such a browser passes that test, it may not be able to handle the code for IE. That is why I prefer feature (object) detection as I have used in my function. The script uses what exists. It doesn't care or need to know which browser is being used.

Dal
07-21-2008, 04:15 PM
Thanks jscheuer1 :) wasnt sure if I needed to mark this post. So left open is fine if thats the way it works.

My browser sniffing works on useragent string alone (just checked my script) but it handles safari and opera strings. Its not that important to me as I am simply displaying a notice to users to make use of IE or FF (FF prefered) since these two are the main stream, safari, opera, flock, avant, konquerer and anyother sub-standard (less than 10% global use) is although tested, NOT garanteed. This isnt a problem as the site uses only the LATEST technologies so if the script thinks its a gecko engine and its not, then the site features probably wouldnt work anyway. :)

Object detection is good but I prefered to use the simple string test for the simple fact that if a nonstandard browser is used...goodluck.
I only test for
IE6 - Not supported
IE7 - supported, some bugs with W3c compliancy
IE8 - supported, some bugs with W3c compliancy but less than IE7
FF < 2 - Not supported
FF 2 - supported, some bugs with certain features
FF 3 - supported
Avant - supported (latest ver)
Opera - supported (actually quite good!)
Safari - Not supported problems with z-index /zIndex features from CSS
Flock - Well much the same as FF

Anything else is regarded as unknown and user is advised to download FF3. I kinda take the same approach on technical support, download the latest drivers and update windows/linux to the latest patches. Same applies to the website browser. Im not trying to be akward just advise users what the site was intended to use.


Thanks again.
Dal

jscheuer1
07-21-2008, 05:10 PM
You are not just relying upon browser sniffing to advise users as to the best browser to use. You are also using it in your enter key function, possibly other places as well. If a Safari browser spoofing IE 7 or FF 3 encounters your site, as I understand it (I may have missed something here) they will get no warning to use another browser, but will have problems with the site.

Also, if z-index is the only problem in Safari, you are probably just doing it wrong. Though I am referring to Safari 3, which is a very good browser in many respects. Safari 2 was less so.

Another problem with browser sniffing is that the criteria that establishes a browser may change over time, there is no standard for it, so it isn't guaranteed to work. Well thought out object detection can always be relied upon to be up to date.

Dal
07-21-2008, 05:30 PM
BrowserID variable is relied upon for IE specification only. I would love to just say that IE is not supported but its too bl**dy big to disregard. I advise users that FF is the main browser which seems to be the closest thing to W3C there is. IE tried to comply but W3C say that this is not a W3C browser (indirectly for legal reasons). Safari I have tested my zIndex on is ver 3.1.1 and although it works with setting z index as static when changing through zindexes with javascript even safari have said its not supported.

I could make all this so perfect for every type of browser and every scenario but what would be the point if the user still cant use the site so I test for scenarios that I need to cover and the browser sniff function covers me mainly for IE and FF as the javascript has to be different for each. I test my site as I go and I have found no issues that havent been addressed. Safari fell over at zIndex and this is the only reason why I cant advise its use on my site. (currently offline otherwise I would provide a link). Konquerer I think has a few issues but I dont have access anymore to a linix server / desktop.

The bugs that occur between the browsers are more of just superficial and they dont cause any confussion. Theres a display issue in FF2 but has been corrected in FF3 which still conforms to my Latest technology specification. IE6 WILL NEVER work with my site and anything that is too far away from W3C will suffer, Im trying to conform to standards and I cannot be anything but right for complying with them standards. I used to use my own standards which was far easier to comply to :p but I dropped that practice and now Im backing the W3C 100%. IE will hopefully become either obsolete or follow the same path I took and STOP making there own stuff up.

How would I change zIndex in safari on say a div with an id of "test";



document.getElementById('test').style.zIndex = 1;


The above doesnt work above in safari!
It doesnt report any error either but you have 3 absolute layers

div1 zindex = 1
div2 zindex = 2
div3 zindex = 3

change div2 to zindex 3 and div3 to zindex 2 and the browser will just sit there laughing at you.

(This is untested, been so long ago when I built that function but I spent days looking for an answer, everyone says the same, zindex doesnt respond the way it should in safari)

Kind regards
Dal

jscheuer1
07-21-2008, 05:47 PM
The z-index style property being manipulated via javascript is essential for at least two scripts in the Dynamic Drive script library. These two:

http://www.dynamicdrive.com/dynamicindex14/fadeinslideshow.htm

and:

http://www.dynamicdrive.com/dynamicindex14/swissarmy/index.htm

both of which work fine in Safari 3. I am even told (though I have never tested) that they both work well in Safari 2.

This looks fine (what you posted):


document.getElementById('test').style.zIndex = 1;

But according to the specification (not always followed in all browsers) elements with z-index must all be either relatively positioned or absolutely positioned for the z-index to have effect. Other issues could exist in the code as well.

Dal
07-21-2008, 05:49 PM
^ Sorry was writting this post when you posted \/

Ive just checked safari again and I cant find the problem, did the previous ver to 3 have problems with zindex???

Anyway the project is all over the place at the moment so I cant fully test it.

NOTE: I take back what I said about safari for now. :D (I really do hope its sorted because its another browser which the site can be run on for all those mac users atleast.)

Cool, well maybe something knocked it out, Im going to have to fully test everything again on all the latests updates for all the browsers Ive tested for so Im sure we will see whats going on, Ill probably need some help with fine tuning once Im done. But like I say above I cant replicate the problem I had originally so I cant tell you what I was doing and what safari was doing about it. :D