disable ctrl-v (paste)

C

chirs

I have a code to disable ctrl-v (paste) on the 2nd box. The problem
is that when I type ctrl-v, the text shows, then disappear
after I release ctrl-v. How can I make it not to show in the box. In
VB, I can set keyascii=0 to kill the input. Is there a similar way to
do it in JavaScript? Thanks a lot.

<HTML><head></head><body>
<form name="myForm">
Password: <input type="text"><br>
Comfirm: <input type="text" name="myText"
onKeyUp = "fncKeyStop();"> </form>
<script>
function fncKeyStop(){
if (window.event.ctrlKey){
if (window.event.keyCode == 86) {
document.myForm.myText.value = ""
}
}}
</script></body></HTML>

Chris
 
M

Michael Winter

chirs wrote on 28 Nov 2003:
I have a code to disable ctrl-v (paste) on the 2nd box. The
problem is that when I type ctrl-v, the text shows, then
disappear after I release ctrl-v. How can I make it not to show
in the box. In VB, I can set keyascii=0 to kill the input. Is
there a similar way to do it in JavaScript? Thanks a lot.

<HTML><head></head><body>
<form name="myForm">
Password: <input type="text"><br>
Comfirm: <input type="text" name="myText"

Typo: Comfirm -> Confirm
^ ^
onKeyUp = "fncKeyStop();"> </form>
<script>

The type attribute is mandatory. This should read:

function fncKeyStop(){
if (window.event.ctrlKey){
if (window.event.keyCode == 86) {
document.myForm.myText.value = ""

You should access forms and form elements using their respective
collections:

document.forms['myForm'].elements['myText'].value = "";
}
}}
</script></body></HTML>

Use both the onkeyup and onkeydown events. That way, it will fire
when a key is pressed once, and when it's released (if held long
enough for the keystroke to repeat).

You should also change the function content to:

function fncKeyStop() {
// Check if the control key is pressed.
// If the Netscape way won't work (event.modifiers is undefined),
// try the IE way (event.ctrlKey)
var ctrl = typeof event.modifiers == 'undefined' ?
event.ctrlKey : event.modifiers & Event.CONTROL_MASK;

// Check if the 'V' key is pressed.
// If the Netscape way won't work (event.which is undefined),
// try the IE way (event.keyCode)
var v = typeof event.which == 'undefined' ?
event.keyCode == 86 : event.which == 86;

// If the control and 'V' keys are pressed at the same time
if ( ctrl && v ) {
// ... discard the keystroke and clear the text box
document.forms['myForm'].elements['myText'].value = '';
return false;
}
return true;
}

....and the intrinsic event bodies to:

<INPUT ... onkeyup="return fncKeyStop()"
onkeydown="return fncKeyStop()">

This works in Internet Explorer and Opera. It should hopefully work
in Mozilla and Netscape too, but I can't test them.

Hope that helps,

Mike
 
N

Nige

I have a code to disable ctrl-v (paste) on the 2nd box.

Presumably this is to stop users from pasting their email address having
typed it once. If so, may I say how annoyed I would be as a user.
 
C

chirs

Thank you a lot. The only thing is if the user typed something in
box2 and then press ctrl-v, it clears the box2. But this can be
fixed. My question is why you use
document.forms['myForm'].elements['myText'].value instead of
document.myForm.myText.value? I also read some book saying I do not
need to put type="text/javascript" in <SCRIPT> since it is default.
 
M

Michael Winter

chirs wrote on 28 Nov 2003:
Thank you a lot. The only thing is if the user typed something
in box2 and then press ctrl-v, it clears the box2. But this can
be fixed. My question is why you use
document.forms['myForm'].elements['myText'].value instead of
document.myForm.myText.value? I also read some book saying I
do not need to put type="text/javascript" in <SCRIPT> since it
is default.

Then that book is, quite frankly, a load of crap and I suggest you
get a new one. It states quite clearly in the HTML 4.01 specification
(the latest) that there is no such thing as a default scripting
language, and that the type attribute is required. This applies to
XHTML, and possibly XML (but I have no knowledge of the latter, so
you'd have to check that). Also, the language attribute in SCRIPT
elements has been deprecated under the Strict document type. If I
were you, I'd quote the following (up to, and including, the HTTP
header description) to the publisher and author of that book*:

18.2.1 The SCRIPT element

<!ELEMENT SCRIPT - - %Script; -- script statements -->
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource --
type %ContentType; #REQUIRED -- content type of script language --
src %URI; #IMPLIED -- URI for an external script --
defer (defer) #IMPLIED -- UA may defer execution of script --
Attribute definitions

type = content-type [p.53] [CI] [p.49]
This attribute specifies the scripting language of the element’s
contents and overrides the default scripting language. The
scripting language is specified as a content type (e.g.,
"text/javascript"). Authors must supply a value for this attribute.
There is no default value for this attribute.

language = cdata [p.50] [CI] [p.49]
Deprecated. [p.38] This attribute specifies the scripting language
of the contents of this element. Its value is an identifier for the
language, but since these identifiers are not standard, this
attribute has been deprecated [p.38] in favor of type.

The above is abridged: the full description is under section 18,
Scripts, of the HTML 4.01 Specification (24 Dec 1999).

The 'default scripting language' referred to in the description of
the type attribute refers to the use of HTTP headers or META elements
(examples below) to identify the default language. If you use
intrinsic events (onclick, onload, etc), you /must/ use one of those
methods to declare the language. The only reason why browsers execute
scripts lacking such declarations is because of the expectation that
authors will not add them, so they use their own defaults. You should
not rely on that behaviour - browsers are not required to do it, and
could remove such support at any time and still conform to the HTML
specification.

To declare the default language use one of these (the latter can only
be done server-side, such as through the use of PHP or similar):

In the document HEAD:

<META http-equiv="Content-Script-Type" content="text/javascript">


As a HTTP header:

Content-Script-Type: text/javascript


As for your second question (why use the forms and elements
collections). I was recently made aware by others in this group that
not all browsers interpret the line below correctly.

document.myForm.myText.value = "";

To the likes of Mr Nielsen and Mr Lahn: My description is from
memory, so I might be a little (or a lot) off. Please correct me if
I'm wrong.

This is because myForm is not actually a property of the document
object, and myText is not a property of the Form object. In that
line, they are being accessed like globals, and not all browsers
support this. However, the document object uses a collection (forms)
to refer to every form that appears in the document. Likewise, the
Form object uses a collection (elements) to refer to every form
element in the form. These collections are defined in both Netscape's
(earlier) JavaScript language specification, and the DOM
specification, and should therefore be supported by any browser that
implements JavaScript or the DOM. Basically, using the statement
below instead of the one above, means that your script will be
executed properly on more browsers than it otherwise would, and so
your possible user base will be larger.

document.forms['myForm'].elements['myText'].value = "";

The last point about this syntax, is that you can use special
characters. If you had the name, home-phone, you couldn't use the
syntax you originally used. The hyphen would be interpreted as the
subtraction operator, and the script would break. However, it's
perfectly legal to do:

document.forms['someForm'].elements['home-phone']....

Sorry if I came off aggressively earlier - it wasn't directed at you.
I'm firmly in the "follow the standards" camp with HTML, and I'm
quite disgusted that a book would /recommend/ breaking the HTML
standard.

I hope that I've answered your questions.

Mike

* I would check first that the use of META or HTTP headers to declare
the default language isn't mentioned earlier in the book.
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Presumably this is to stop users from pasting their email address having
typed it once. If so, may I say how annoyed I would be as a user.

It is a password confirm box, AFAICS, which means that using ^V rather
defeats the object of having a confirmation.
 
F

Fabian

Michael Winter hu kiteb:
type = content-type [p.53] [CI] [p.49]
This attribute specifies the scripting language of the element$BCT(B
contents and overrides the default scripting language. The ===========================
scripting language is specified as a content type (e.g.,
"text/javascript"). Authors must supply a value for this attribute.
There is no default value for this attribute.
===================================

I think this specification could do with some proof-reading if your
interpretation is correct.
<META http-equiv="Content-Script-Type" content="text/javascript">

Does this replace the TYPE attribute in the SCRIPT tag?
 
L

Lasse Reichstein Nielsen

Fabian said:
Michael Winter hu kiteb:
type = content-type [p.53] [CI] [p.49]
This attribute specifies the scripting language of the element
contents and overrides the default scripting language. The ===========================
scripting language is specified as a content type (e.g.,
"text/javascript"). Authors must supply a value for this attribute.
There is no default value for this attribute.
===================================

I think this specification could do with some proof-reading if your
interpretation is correct.

Not really.

There is a "default scripting language" for a page. It can be set
with the META tag shown below. It is the default scripting language
for all scripts on the page.

There is no default *value* for the script tag's type *attribute*.
Furthermore, the type attribute is required, so in practice, the
default scripting language doesn't apply to script elements.

The "default scripting language" and the "type attribute" of script
tags are completely independent. The latter has no default value.
Does this replace the TYPE attribute in the SCRIPT tag?

No. It's not about script tags at all. Script tags require the type
attriubte. The intrinsic event attributes (e.g., "onclick") have no
type attribute, and they use the default scripting language of the
page.

Intrinsic events:
<URL:http://www.w3.org/TR/html4/interact/scripts.html#events>
/L
 
F

Fabian

Dr John Stockton hu kiteb:
JRS: In article <[email protected]>, seen in


It is a password confirm box, AFAICS, which means that using ^V rather
defeats the object of having a confirmation.

In which case, shouldnt the form object be of type=password? iirc, that
type has cut and paste functions disabled as a 'security' measure.
 
M

Michael Winter

Fabian wrote on 28 Nov 2003:
Michael Winter hu kiteb:
type = content-type [p.53] [CI] [p.49]
This attribute specifies the scripting language of the
element$BCT(B contents and overrides the default scripting
language. The ===========================
scripting language is specified as a content type (e.g.,
"text/javascript"). Authors must supply a value for this
attribute. There is no default value for this attribute.
===================================

I think this specification could do with some proof-reading if
your interpretation is correct.

It's not an interpretation, that is quoted verbatim. The only edited
sections are the descriptions of the src and defer attributes (which
I removed completely).
Does this replace the TYPE attribute in the SCRIPT tag?

The type attribute is required. That why the specification says (as
you quoted!): "Authors must supply a value for this attribute." The
Content-Script-Type META element or HTTP header is used when parsing
intrinsic events. It is explained in section 18.2.2, Specifying the
scripting language, of the HTML 4.01 specification.

Mike
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
Dr John Stockton hu kiteb:

In which case, shouldnt the form object be of type=password? iirc, that
type has cut and paste functions disabled as a 'security' measure.

You do not RC! Copy and Cut are disabled, but Paste works, in my
browser, in a Password box. But it seems likely that it should be
type=password.
 
D

David Leverton

chirs said:
I have a code to disable ctrl-v (paste) on the 2nd box.
[snip]

How do you know that Ctrl-V is the shortcut for Paste? You could be
disabling some other completely different and important feature of the
browser.
 
L

Lasse Reichstein Nielsen

David Leverton said:
chirs said:
I have a code to disable ctrl-v (paste) on the 2nd box.
[snip]

How do you know that Ctrl-V is the shortcut for Paste? You could be
disabling some other completely different and important feature of the
browser.

E.g., it probably also disables Ctrl-Alt-V, which has a function in
Opera. Not one that you would probably want the user to use, though,
as it sends the page to an HTML validator :)

/L
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,754
Messages
2,569,527
Members
45,000
Latest member
MurrayKeync

Latest Threads

Top