fireEvent

[znndrp]

Re: fireEvent

Yann-Erwan Perio wrote:[color=blue]
> Then try the following hack instead :
>
> if (ord == 13 && editEvent.type == 'keypress') {
> if(editor_obj.t agName.toLowerC ase()=="iframe" ) {
> if (
> (function(){
> var el=editor_obj.c ontentWindow.do cument.selectio n.
> createRange().p arentElement();
> var lc;
> while((lc=el.no deName.toLowerC ase())!="body") {
> if(lc!="p") break;
> el=el.parentNod e;
> }
> return lc=="body";
> })()[/color]

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(){ * })) ??
[color=blue]
> (ugly, eh?)[/color]

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+ "_InsertUnorder edList"].className;
var b = document.all["_" +objname+ "_InsertOrdered List"].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.retur nValue = false;

//if enter WAS pressed before insert </p><p>
if (b_PressedBefor e) {
editor_insertHT ML(objname, "</p><p>");
b_PressedBefore = false;
}
//if enter was NOT pressed before insert <br>
else {
editor_insertHT ML(objname, "<br>");
//mark as pressed before
b_PressedBefore = true;
}
return;
}

if (ord == 13 && editEvent.type == 'keypress' && !b_btnDown && shiftKey) {
editEvent.retur nValue = false;
editor_insertHT ML(objname, "</p><p>");
return;
}
------------------------------>8----------------------------------------

I guess this one's quite dirty too :)

--
,_,
(O,O)
( )
---"-"-alex

[Yann-Erwan Perio]

Re: fireEvent

znndrp wrote:
[color=blue]
> 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 :)[/color]

No problem, just ask:-)
[color=blue]
> What are you doing between the
> if ((function(){ * })) ??[/color]

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.c ontentWindow.do cument.selectio n.
createRange().p arentElement();

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.no deName.toLowerC ase())!="body") {
if(lc!="p") break;
el=el.parentNod e;
}
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
[color=blue]
> I also worked out a hack myself, which is a bit larger but appears to
> have the same effect.[/color]

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.

[znndrp]

Re: fireEvent

Yann-Erwan Perio wrote:
....[color=blue]
> 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.[/color]

aahh, ok :)

thanks for your help!

--
,_,
(O,O)
( )
---"-"-alex