Z
znndrp
Hi all,
Anyone knows how to use fireEvent to simulate a shit+keypress in a textarea?
thanks,
Anyone knows how to use fireEvent to simulate a shit+keypress in a textarea?
thanks,
M
Michael Winter
There is no standard approach. The DOM 2 Events Specification defined ways
of dispatching HTML, mouse, and UI events into the document tree, but
keyboard events were not specified. The DOM 3 Events Specification does
add keyboard events, but the Specification was never agreed upon, so
few[1] browsers implemented it.
That means that anything you might do, *might* work in Mozilla and IE, but
it's highly unlikely to work anywhere else.
Sorry,
Mike
[1] Mozilla did, but their implementation was made early, and properties
and methods have changed since.
Y
Yann-Erwan Perio
znndrp said:
You seem to be targeting IE only, so the solution will be IE only. Note
that triggering a keypress event does not deal with the built-in
pre-event mechanics, i.e. you won't see any letter in your textarea. As
for manipulating the textarea's value, use IE ranges.
Though the idea of triggering events is a good one, I believe that there
usually are better approaches, using handlers and "proxies", but not
knowing what you want to do makes it difficult to determine the best one
---
<form>
<textarea onkeypress="foo(this, event)"></textarea>
<input type="button" value="bar()" onclick="bar()">
</form>
<script type="text/javascript">
function foo(elem, evt){
alert(
[
"elem : " + elem.nodeName,
"shiftKey : " + evt.shiftKey,
"keyCode : " + evt.keyCode
].join("\n")
);
}
function bar(){
if(document.createEventObject) {
var evt=document.createEventObject();
evt.shiftKey=true;
evt.keyCode=121;
document.forms[0].elements[0].fireEvent("onkeypress", evt);
}
}
</script>
Z
znndrp
Yann-Erwan Perio said:You seem to be targeting IE only, so the solution will be IE only. Note
that triggering a keypress event does not deal with the built-in
pre-event mechanics, i.e. you won't see any letter in your textarea. As
for manipulating the textarea's value, use IE ranges.
Though the idea of triggering events is a good one, I believe that there
usually are better approaches, using handlers and "proxies", but not
knowing what you want to do makes it difficult to determine the best one
I think I don't know myself either
But I don't think this is the solutionto my problem. While I was reading some more on this subject I also noticed
there's method called 'handleEvent()'. What's the difference between
fireEvent and handleEvent?
M
Martin Honnen
znndrp wrote:
fireEvent (as implemented in IE 5.5 and 6) only allows you to have any
event handler for the event being fired but for key events for instance
a key is never entered that way.
fireEvent (as implemented in IE 5.5 and 6) only allows you to have any
event handler for the event being fired but for key events for instance
a key is never entered that way.
Y
Yann-Erwan Perio
znndrp said:I think I don't know myself either
solution to my problem.
What about telling us the test scenario? This might help!
There are 2 main events models in the web-browsers' world: Internet
Explorer model, and W3C (standard) model. Both generally permit to do
the same things (IE's model being much limited) but are structured and
scripted differently.
fireEvent and handleEvent are not part of the same model, and moreover
don't do the same thing
fireEvent is part of the IE's events model; it is used to dispatch an
event from a specific target, with an optional event "template". The W3C
equivalent is dispatchEvent.
<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/fireevent.asp>
handleEvent is part of the W3C's model and has no equivalent in IE. It
is the only method of the EventListener interface, i.e. this is the
handler itself. Usually, we define event listeners this way:
document.onclick=function(evt){alert("hello");};
This is a cross-browser way; using W3C's model you can do:
document.addEventListener(
"click",
function(evt){alert("hello");},
false //no capture
);
or (and this is where handleEvent comes out)
document.addEventListener(
"click",
{handleEvent:function(evt){alert("hello");}},
false
);
The latest isn't well-supported though, the preferred way is to pass
directly the handler as second argument.
<URL:http://www.w3.org/TR/2003/NOTE-DOM-.../events.html#Events-EventListener-handleEvent>
The equivalent IE way (to some extent) would be:
document.attachEvent(
"onclick",
function(){alert("hello");}
);
HTH
Yep.
M
Michael Winter
[snip]
You're getting confused between two different DOMs.
fireEvent() is part of Microsoft's proprietary event model. It dispatches
a user-create event into the document tree.
handleEvent() is part of the World Wide Web Consortium's (W3C) DOM 2
Events specification. However, this method doesn't exist for JavaScript
(look at the ECMAScript bindings for the EventListener interface). In
JavaScript, an EventListener is a function, so handleEvent() isn't
necessary. In Java, EventListener is an interface which cannot do anything
in itself. The programmer must implement the handleEvent() method to
define behaviour for that listener[1]. In other words, handleEvent() is
called in Java in the same way a handler function is in JavaScript.
The equivalent in the W3C DOM is dispatchEvent().
Hope that helps,
Mike
[1] Sorry, that's as good an explanation as I can come up with at the
moment. If you know the Java language, you'll know what an interface is,
and I shouldn't need to it describe how to use the mechanism.
You're getting confused between two different DOMs.
fireEvent() is part of Microsoft's proprietary event model. It dispatches
a user-create event into the document tree.
handleEvent() is part of the World Wide Web Consortium's (W3C) DOM 2
Events specification. However, this method doesn't exist for JavaScript
(look at the ECMAScript bindings for the EventListener interface). In
JavaScript, an EventListener is a function, so handleEvent() isn't
necessary. In Java, EventListener is an interface which cannot do anything
in itself. The programmer must implement the handleEvent() method to
define behaviour for that listener[1]. In other words, handleEvent() is
called in Java in the same way a handler function is in JavaScript.
The equivalent in the W3C DOM is dispatchEvent().
Hope that helps,
Mike
[1] Sorry, that's as good an explanation as I can come up with at the
moment. If you know the Java language, you'll know what an interface is,
and I shouldn't need to it describe how to use the mechanism.
M
Michael Winter
On Tue, 17 Aug 2004 12:36:57 +0200, Yann-Erwan Perio
[snip]
Are you certain about that? The handleEvent() method is described in both
level 2 and 3, but it isn't in the ECMAScript bindings for either. In
fact, it states in level 2:
Object EventListener
This is an ECMAScript function reference. This method has no
return value. The parameter is a Event object.
and more directly in level 3:
EventListener function:
This function has no return value. The parameter is an object
that implements the Event interface.
[snip]
Mike
[snip]
Are you certain about that? The handleEvent() method is described in both
level 2 and 3, but it isn't in the ECMAScript bindings for either. In
fact, it states in level 2:
Object EventListener
This is an ECMAScript function reference. This method has no
return value. The parameter is a Event object.
and more directly in level 3:
EventListener function:
This function has no return value. The parameter is an object
that implements the Event interface.
[snip]
Mike
Z
znndrp
Yann-Erwan Perio said:
Sorry
, I've got this htmledit object which treates a single [enter] as'</p><p>' and a [shift]+[enter] as '<br>'. My goal is to make this work the
other way round (there's been a few threads on their forum so I doubt it's
even possible :/). So I thought 'let's capture those events cancel them, and
fire a new event with the 'shiftKey' property inversed'. But that doesn't work.
The object im using can be found here:
http://www.interactivetools.com/products/htmlarea/
The function I'm hacking is the 'editor_event()' function in 'editor.js'
R
Richard Cornford
Michael said:
Mozilla browsers allow (or have allowed) a Java-style object with a -
handleEvent - method to be used in place of a function reference. But as
the behaviour is contradictory with the ECMAScript binding for DOM
events it probably isn't a good idea to ever use it. Indeed, accompanied
by a failure to properly distinguish between Java and javascript, it has
been the cause of 'cross-browser problems' reported to the group at
least once.
<snip>
Yes, in ECMAScript the function object *is* the - EventListener -
interface.
Richard.
M
Martin Honnen
Michael said:
I think you are right that the ECMAScript binding doesn't in any way
suggest that an object with a handleEvent method can be used as an event
listener but Mozilla has always supported that e.g.
document.addEventListener(
'click',
{ handleEvent: function (evt) {
document.body.appendChild(document.createTextNode(evt.type + ' '));
}
},
false
)
besides taking a function object directly. As Opera 7 however will throw
an error with the above construct when it tries to call the event
listener it is not recommended to use it when scripting HTML documents.
But there are other DOM Events implementation, for instance in SVG
documents, and with Batik 1.5.1, a Java based SVG viewer that allows
ECMAScript to script the SVG document it is possible to use the above
construct e.g. in
<?xml version="1.0" encoding="UTF-8"?>
<svg
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 100 100"
onload="init(evt);">
<script type="text/ecmascript"><![CDATA[
var svgDocument;
var svgNamespace = 'http://www.w3.org/2000/svg';
function init (evt) {
svgDocument = evt.target.ownerDocument;
if (svgDocument) {
svgDocument.addEventListener(
'click',
{ handleEvent: function (evt) {
var tspan = svgDocument.createElementNS(svgNamespace, 'tspan');
tspan.appendChild(svgDocument.createTextNode(evt.type + ' '));
svgDocument.getElementById('debug').appendChild(tspan);
}
},
false
);
}
}
]]></script>
<rect x="0" y="0" width="100" height="100" fill="lightblue" />
<text id="debug" x="0" y="10" font-size="3"></text>
</svg>
the handleEvent method is called when someone clicks.
Y
Yann-Erwan Perio
Michael said:
Honestly I hadn't looked at the EcmaScript bindings, so I'm definitely
not certain
While in the process of learning events, I had testedproperties/methods directly from the specs, and inferred possible usages
from having them work on my browsers. handleEvent working in Mozilla was
therefore enough for me.
Ah that's true, but I also read :
addEventListener(type, listener, useCapture)
This function has no return value.
The type parameter is a String.
The listener parameter is an object that implements
the EventListener interface.
The useCapture parameter is a Boolean.
in which case the use for {handlerEvent:func} would be legitimate,
although, as you say, this object isn't described later on; their
mentioning the EventListener function makes no doubt possible however,
the "correct", and not "preferred", way is indeed to use a function.
Regards,
Yep.
Y
Yann-Erwan Perio
znndrp wrote:
That's a pretty huge script, however at the function you've pointed out
there's commented code; changing this code a little seems to give the
results you're looking for:
if (ord == 13 && editEvent.type == 'keypress') {
editEvent.returnValue = false;
editor_insertHTML(objname, shiftKey ? "<p>" : "<br>");
return;
}
I haven't (nor will) read the whole script so cannot tell whether this
will be safe; only the author could tell
The conception behind the script is very strange, the author mixes
timeouts with event management, which is something that should never be
done; ISTM that she/he has drawn incorrect conclusions about events
concurrency, resulting, in the end, in the program flow getting quite
complicated.
HTH,
Yep.
Sorry
as '</p><p>' and a [shift]+[enter] as '<br>'. My goal is to make this
work the other way round
That's a pretty huge script, however at the function you've pointed out
there's commented code; changing this code a little seems to give the
results you're looking for:
if (ord == 13 && editEvent.type == 'keypress') {
editEvent.returnValue = false;
editor_insertHTML(objname, shiftKey ? "<p>" : "<br>");
return;
}
I haven't (nor will) read the whole script so cannot tell whether this
will be safe; only the author could tell
The conception behind the script is very strange, the author mixes
timeouts with event management, which is something that should never be
done; ISTM that she/he has drawn incorrect conclusions about events
concurrency, resulting, in the end, in the program flow getting quite
complicated.
HTH,
Yep.
Z
znndrp
....Yann-Erwan Perio said:
Yes, I've noticed that piece of code, but if I uncommented that, the
UnOrderedList button doesn't work correctly anymore, so that's not an
acceptable solution.
I haven't (nor will) read the whole script so cannot tell whether this
will be safe; only the author could tell
I'm now expanding the authors code you pointed me to, so that it _will_ work
correctly with UnOrderedList.
Y
Yann-Erwan Perio
znndrp said:
Then try the following hack instead :
if (ord == 13 && editEvent.type == 'keypress') {
if(editor_obj.tagName.toLowerCase()=="iframe") {
if (
(function(){
var el=editor_obj.contentWindow.document.selection.
createRange().parentElement();
var lc;
while((lc=el.nodeName.toLowerCase())!="body"){
if(lc!="p") break;
el=el.parentNode;
}
return lc=="body";
})()
) {
editEvent.returnValue = false;
editor_insertHTML(objname, shiftKey ? "<p>" : "<br>");
return;
}
}
}
(ugly, eh?)
HTH,
Yep.
Z
znndrp
Yann-Erwan Perio said:
Hmm, that seems to work. But I must admit I'm not exactely a JS guru so
you've got to help me a bit here
What are you doing between the
if ((function(){ * })) ??
Yep
I also worked out a hack myself, which is a bit larger but appears to have
the same effect.
--------------------8<--------------------------------------------------
//if enter NOT pressed, reset
if (ord != 13) {
b_PressedBefore = false;
}
//look up which buttons are pressed
var a = document.all["_" +objname+ "_InsertUnorderedList"].className;
var b = document.all["_" +objname+ "_InsertOrderedList"].className;
b_btnDown = true;
c_btnText = 'btnDown'
//if a button is pressed set var
if (a != c_btnText && b != c_btnText) {
b_btnDown = false;
}
//if no buttons are pressed and no shift is pressed
if (ord == 13 && editEvent.type == 'keypress' && !b_btnDown && !shiftKey) {
editEvent.returnValue = false;
//if enter WAS pressed before insert </p><p>
if (b_PressedBefore) {
editor_insertHTML(objname, "</p><p>");
b_PressedBefore = false;
}
//if enter was NOT pressed before insert <br>
else {
editor_insertHTML(objname, "<br>");
//mark as pressed before
b_PressedBefore = true;
}
return;
}
if (ord == 13 && editEvent.type == 'keypress' && !b_btnDown && shiftKey) {
editEvent.returnValue = false;
editor_insertHTML(objname, "</p><p>");
return;
}
------------------------------>8----------------------------------------
I guess this one's quite dirty too
Y
Yann-Erwan Perio
znndrp said:Hmm, that seems to work. But I must admit I'm not exactely a JS guru so
you've got to help me a bit here
No problem, just ask
The function expression is used to create a specific scope; the script
is big and I wouldn't like to declare variables that might collide with
outer variables, so I used a function to have "local" variables.
From what I've seen so far, the script uses a TEXTAREA as fallback and
an IFRAME when the design mode is supported; it then uses execCommand to
make the change on the iframe.
So the first thing we want to check is whether we're in the iframe or
the textarea. Once you've asserted you're in the iframe, you need to
decide whether change the insertion mode or leave it as normal. For
instance, if you're already "inside" an ordered list, you want the
standard behavior to be run, if you're just under the BODY then you want
to change the insert behavior.
The point is to determine where we are and what to do. To find where we
are, we retrieve the selection range (i.e the caret, in a keypress context):
var el=editor_obj.contentWindow.document.selection.
createRange().parentElement();
The "parentElement()" method will give the element containing the range;
then we just have to go up the nodes' tree.
var lc;
while((lc=el.nodeName.toLowerCase())!="body"){
if(lc!="p") break;
el=el.parentNode;
}
return lc=="body";
The idea is to change the behavior only if we are inside specific tags
(I've set "P" tags, but you could add more tags, such as FONT, B, I...).
If we encounter another tag (for instance UL) then we exit the loop. In
the end, there are two possible results:
- either we've reached the BODY tag, which means we've accepted
all parent tag; the behavior can be changed.
- or we haven't reached the BODY tag and have exited the loop
beforehand; the behavior should not be changed.
To fully understand the logic you need to have in mind the DOM tree:
range -> P -> BODY => OK
range -> P -> UL ... => FAIL
Yes, but you hold the logic in regards of the buttons pressed, not the
document structure, which could lead to problems if the user doesn't
follow the order button-action; however given the way the editor seems
to work this should be okay I think.
HTH,
Yep.
Z
znndrp
Yann-Erwan Perio wrote:
....
aahh, ok
thanks for your help!
....
aahh, ok
thanks for your help!