Community
Participate
Working Groups
If you set DELETE to the active keys the default behavior, delete text in textfields, does not work anymore.
(In reply to comment #0) > If you set DELETE to the active keys the default behavior, delete text in > textfields, does not work anymore. Additional info for reproduction (from talk with h.staudacher): I have a keyEventListener on a Table which listens to SWT.DELETE. If I now open a form which has a textField the delete key doesn't work anymore because the event is blocked by the table.
Hi Stephan, not sure if I understand correctly. You added a key listener to the table using Control#addKeyListener() AND add the DELETE key to the active keys using Display#setData() with RWT.ACTIVE_KEYS? The latter is not necessary to get the key listener on the table to work. If you add a key to the active keys, the browser's default behavior is suppressed, e.g. to omit the search popup on Ctrl-F. But it seems that this suppression is causing trouble, right?
(In reply to comment #1) Ok, this was wrong. Correct way to reproduce it: I have a dialog with a table and a textfield. For a delete-row-action on the table I add the DELETE key to the active keys using Display#setData() with RWT.ACTIVE_KEYS. Now it is not possible anymore to delete the text in the textfield using the DELETE key.
(In reply to comment #2) > Hi Stephan, not sure if I understand correctly. You added a key listener to the > table using Control#addKeyListener() AND add the DELETE key to the active keys > using Display#setData() with RWT.ACTIVE_KEYS? The latter is not necessary to > get the key listener on the table to work. > > If you add a key to the active keys, the browser's default behavior is > suppressed, e.g. to omit the search popup on Ctrl-F. But it seems that this > suppression is causing trouble, right? Hi Ralf, please read comment 3. I hope you can follow my steps. I didn't use addKeyListener on the table. Yes, it seems that this suppression is causing trouble for the "standard" keys like DELETE and possibly others like BACKSPACE or TAB.
> > Hi Ralf, please read comment 3. I hope you can follow my steps. I didn't use > addKeyListener on the table. From my point of view this behaves the expected way. When you start listening on a key like the DELETE key you need to take care of all actions regarding the DELETE key. So, is there a reason why you aren't using a keyListener on the table? When you are using the keyListener you don't have to add the DELETE key to the ActiveKeys and your problem will probably vanish.
(In reply to comment #5) > From my point of view this behaves the expected way. When you start listening > on a key like the DELETE key you need to take care of all actions regarding the > DELETE key. Well, how can I know all possible actions regarding the DELETE key (or any other key in the ACTIVE_KEY set). > So, is there a reason why you aren't using a keyListener on the > table? Yes there is a reason. I can't specify which key the keyListener should listen to. If I add a keyListener to a control the browser would send just every key press and release to the server. I don't want that much traffic.
(In reply to comment #6) > Yes there is a reason. I can't specify which key the keyListener should listen > to. If I add a keyListener to a control the browser would send just every key > press and release to the server. I don't want that much traffic. There is a proposal to extend the ACTIVE_KEY mechanism to Widgets: bug 346597. This would probably be the solution to your problem, wouldn't it?
(In reply to comment #7) > There is a proposal to extend the ACTIVE_KEY mechanism to Widgets: bug 346597. > This would probably be the solution to your problem, wouldn't it? Yes, this seem to be the solution.
Can this be considered fixed? Bug 346597 is fixed and ACTIVE_KEYS on display are no longer canceled automatically.
I'm struggling now with the opposite problem. I'm still working with the active keys on display. I have set DELETE as active key and cancel keys is empty/not set. With HEAD I receive DELETE key event only on Textfield but not every keystroke. If focus is somewhere else, i.e. a table, DELETE key events do not reach the server.
(In reply to comment #10) > I'm struggling now with the opposite problem. I'm still working with the active > keys on display. I have set DELETE as active key and cancel keys is empty/not > set. > With HEAD I receive DELETE key event only on Textfield but not every keystroke. > If focus is somewhere else, i.e. a table, DELETE key events do not reach the > server. Just tested with display filter and ACTIVE_KEYS (DELETE) set on display and events are fired regardless of the focused control. With the implementation of CANCEL_KEYS (bug 367869) the key added to the ACTIVE_KEYS list is not canceled automatically anymore. I will closed it as FIXED. Please reopen if you the issue persists for you with the latest nightly runtime.
(In reply to comment #11) > Just tested with display filter and ACTIVE_KEYS (DELETE) set on display and > events are fired regardless of the focused control. > > With the implementation of CANCEL_KEYS (bug 367869) the key added to the > ACTIVE_KEYS list is not canceled automatically anymore. > I will closed it as FIXED. Please reopen if you the issue persists for you with > the latest nightly runtime. I'll test it and would reopen this bug if necessary. Thanks for the heads up.
