Greg,
After investigating it a bit more, I tried adding an AWT KeyListener to the
DisplayHost. This seems to work. Regardless of which component in my form
has focus I can now "catch" the ctrl-enter. The code looks simply like:
java.awt.Component frame =
presentation.getHost().getDisplay().getDisplayHost();
frame.addKeyListener(
new KeyListener() {
@Override
public void keyPressed(KeyEvent e) {
System.out.println("keyPressed: " + e);
if (e.getKeyCode() == KeyEvent.VK_ENTER &&
e.isControlDown()) {
System.out.println("keyPressed got
ctrl-enter");
e.consume();
}
}
...
The problem now is that even though I'm consume() on the event, it's still
processed by pivot. This seems strange as, according to the InputEvent
javadoc at least, calling consume on an InputEvent should prevent the event
source from processing the event as normal. Does the DisplayHost check the
isConsumed() flag before processing a generated InputEvent?
On Sat, Dec 4, 2010 at 12:07 PM, ocean ocean <[email protected]> wrote:
> Thanks Greg. I'm still stuck on 1.5.2 but will try this again in the
> future. I think supporting this feature in a more standardized manner would
> be very useful btw. It's something I think a lot of people would expect and
> the framework should support out of the box.
>
>
> On Sat, Dec 4, 2010 at 8:22 AM, Greg Brown <[email protected]> wrote:
>
>> Try it with the latest source.
>>
>> On Dec 4, 2010, at 12:07 AM, ocean ocean wrote:
>>
>> Greg,
>>
>> This seems to work with TextInputs but not with TextAreas. When TextAreas
>> have focus it looks like they're consuming the ctrl+enter keypressed event.
>> Any other ideas? Is the only way to do, as Chris mentioned, somehow
>> attaching a listener to every component in the form?
>>
>>
>> On Sat, Nov 27, 2010 at 9:15 AM, Greg Brown <[email protected]> wrote:
>>
>>> I sent a reply to this last night but apparently it never came through.
>>> Try listening for keyPressed() instead. That shouldn't be consumed by the
>>> text inputs. Also, I'd suggest attaching the listener to the form instead of
>>> the window if there is no reason not to.
>>>
>>> On Nov 26, 2010, at 8:19 PM, ocean ocean wrote:
>>>
>>> > I'm still having a lot of trouble implementing the default button
>>> functionality. Basically I'd like to have the user be able to type
>>> 'ctrl-enter' in various forms and have this automatically click on an 'OK'
>>> button that causes the form to be submitted. This seemed to have been
>>> working before but now it doesn't. I've tried adding a ComponentKeyListener
>>> to both a Dialog and a Window (obtained via Dialog.getWindow()), that reacts
>>> to ctrl-enter eg:
>>> >
>>> > dialog.getWindow().getComponentKeyListeners().add(
>>> > new ComponentKeyListener.Adapter() {
>>> >
>>> > @Override
>>> > public boolean keyTyped(Component component, char
>>> character) {
>>> > if (character == Keyboard.KeyCode.ENTER &&
>>> Keyboard.isPressed(Modifier.CTRL)) {
>>> > System.out.println("*** ctrl-enter
>>> pressed");
>>> > return true;
>>> > } else {
>>> > return false;
>>> > }
>>> > }
>>> > });
>>> >
>>> > The problem seems to be that for forms that have TextInputs, this logic
>>> doesn't work when those TextInputs have focus. In this case the TextInputs
>>> consume the event. Is there a way to get my hands on the key typed before
>>> any controls in the window/dialog consume it?
>>>
>>>
>>
>>
>
