You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by ocean ocean <ri...@gmail.com> on 2010/12/04 06:07:38 UTC
Re: Default Button on Forms
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 <gk...@mac.com> 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?
>
>
Re: Default Button on Forms
Posted by Greg Brown <gk...@verizon.net>.
Let me look into that. Maybe we can handle the ENTER key in keyTyped().
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 <gk...@mac.com> 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?
>
>
Re: Default Button on Forms
Posted by Greg Brown <gk...@verizon.net>.
Not sure I agree with that. As I mentioned in an earlier thread, there is no standard definition of "submitting a form" in a Java app, as there is in HTML. Also, I'm not sure how common the Control-Enter key combination is - from my experience, Enter (no Control) is more common.
However, it might make sense to define a submit() method on the Form class that subclasses could override. The form skin could call this method whenever Enter (or whatever) is pressed. We could also consider firing a FormSubmitListener#formSubmitted() event to cover the case when a developer wants to implement the submit logic in script rather than by subclassing.
Just out of curiosity, what is keeping you on 1.5.2? Any major hurdles to updating to 2.0?
On Dec 4, 2010, at 12:07 PM, ocean ocean 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 <gk...@verizon.net> 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 <gk...@mac.com> 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?
>>
>>
>
>
Re: Default Button on Forms
Posted by Greg Brown <gk...@verizon.net>.
> Does the DisplayHost check the isConsumed() flag before processing a generated InputEvent?
This is a bug in 1.5.x. In 2.0, when a Pivot event is consumed, the AWT event is also consumed.
Re: Default Button on Forms
Posted by ocean ocean <ri...@gmail.com>.
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 <ri...@gmail.com> 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 <gk...@verizon.net> 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 <gk...@mac.com> 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?
>>>
>>>
>>
>>
>
Re: Default Button on Forms
Posted by ocean ocean <ri...@gmail.com>.
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 <gk...@verizon.net> 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 <gk...@mac.com> 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?
>>
>>
>
>
Re: Default Button on Forms
Posted by Greg Brown <gk...@verizon.net>.
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 <gk...@mac.com> 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?
>
>