Opened 16 years ago
Last modified 11 years ago
#4264 confirmed New Feature
Fire event after enterkey press is handled
Reported by: | Jon Håvard Gundersen | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | UI : Enter Key | Version: | 3.0 |
Keywords: | Cc: |
Description
I need to manipulate the created block after enterkey is pressed.
It would be very nice if the enterkey plugin could fire an event like 'enterkey' or something after the enterkey is handled.
It is not possible to hook into this code at the moment since it is runned in a timeout.
Change History (5)
comment:1 Changed 16 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 follow-up: 3 Changed 16 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
The problem is that there is currently no way to determine when enterkey is finished. The enter handler function is runned in a timeout after the enter key is pressed.
And, I do not think that enterkey would fire too frequently.
comment:3 Changed 15 years ago by
Replying to jonhg:
The problem is that there is currently no way to determine when enterkey is finished. The enter handler function is runned in a timeout after the enter key is pressed.
It's not a bad idea to have also support for the "afterKey" event, which should go into the keystroke plugin. This event should not be thrown if the "key" event is canceled.
comment:4 Changed 13 years ago by
Status: | reopened → confirmed |
---|---|
Version: | SVN (CKEditor) - OLD → 3.0 |
comment:5 Changed 11 years ago by
The reason why this is still a problem is that keystrokehandler first fires key event and then executes command. It doesn't make much sense - keystroke execution should be one of key event's listeners. Then all this would be fully flexible. We use this pattern in many other places and therefore we don't have to introduce dozens of after/before/shortlyAfter/oneSmallStepBefore events.
I think it's possible to get the newly created block by looking at the range path after enter key, coz the selection is always at the start editing position of that block.
It's seems not a good choice for us to fire an 'enterkey' event, since keyboard actions are high frequency actions which would be hanged by such events' handlers.