1.6.4 - duplicate onKeyDown events

[jchimene]

Hi,

Is anybody else seeing duplicate events with a (now deprecated)
KeyBoardListener?

I get duplicate events even when I replace the deprecated handler with
the 1.6 event version. The target/source widget IDs are the same for
both events.

The problem does not occur using the 1.5.3 library.

This is pretty simple stuff:
suggestBox.addKeyboardListener(new KeyboardListenerAdapter() {
public void onKeyDown(Widget sender, char keyCode, int modifiers) {
if (191 == (int)keyCode) { // question mark
GWT.log("help",null);
}
}
});

[jchimene]

OK, so I've isolated it to the following routine inside
com.google.gwt.user.client.ui.Composite.class

@Override
public void onBrowserEvent(Event event) {
// Fire any handler added to the composite itself.
super.onBrowserEvent(event);

// Delegate events to the widget.
widget.onBrowserEvent(event);
}


How do I declare my class so that the two onBrowserEvent() calls don't
wind up in the same routine?

[jchimene]

Hi,

The similar routine from the 1.5.3 library does not have the duplicate
calls:

com.google.gwt.user.client.ui.Composite.class

@Override
public void onBrowserEvent(Event event) {

// Delegate events to the widget.
widget.onBrowserEvent(event);
}

Was this a bugfix for the 1.6 revision? If so, how do I prevent the
duplicate call to the SuggestBox widget?

[Jason Essington]

I'm guessing don't call super.onBrowserEvent() in composite, just
delegate ...

-jason

[Sumit Chandel]

Hi jchimene,

Thanks for catching this. What you've discovered is essentially a bug. I reproduced it on my end and can confirm that events will fire twice for pretty much any class extending Composite because of the two onBrowserEvent calls in the Composite class (one to super, the other from the wrapped widget).

It looks like the rationale for making this change was discussed in Issue #3211 (link below). While it seems to make sense, I think this case of Composites wasn't considered, and so we're seeing double-fire events like the one in your code snippet above.

Issue #3211:

http://code.google.com/p/google-web-toolkit/issues/detail?id=3211

A potential workaround you can use in the case of the SuggestBox would be to extend it and override the onBrowserEvent() method once more, this time making a single call to onBrowserEvent from the wrapped widget.

E.g.:

public class MySuggestBox extends SuggestBox {

  @Override

  public void onBrowserEvent(Event event) {

    getWidget().onBrowserEvent(event);

  }

}

Give that a try and let us know how it goes. Meanwhile, I'll file an issue on the tracker for this bug and let you know once it's reported so you can follow up on it.

Hope that helps,

-Sumit Chandel

[Sumit Chandel]

Issue #3533 submitted:

http://code.google.com/p/google-web-toolkit/issues/detail?id=3533

Thanks,

-Sumit Chandel

[Jeff Chimene]

On 04/09/2009 03:36 PM, Sumit Chandel wrote:
> public class MySuggestBox extends SuggestBox {
> ��@Override
> ��public void onBrowserEvent(Event event) {
> �� �getWidget().onBrowserEvent(event);

> ��}
> }
Hi Sumit,

Thanks for the follow-up!

I'll implement that code. There can be little doubt that overriding to
the 1.5.x behavior will address the issue.

Cheers,
jec

[Jeff Chimene]

On 04/09/2009 03:36 PM, Sumit Chandel wrote:

> Hi jchimene,
>
> Thanks for catching this. What you've discovered is essentially a bug.
> I reproduced it on my end and can confirm that events will fire twice
> for pretty much any class extending Composite because of the two
> onBrowserEvent calls in the Composite class (one to super, the other
> from the wrapped widget).
>
> It looks like the rationale for making this change was discussed in
> Issue #3211 (link below). While it seems to make sense, I think this
> case of Composites wasn't considered, and so we're seeing double-fire
> events like the one in your code snippet above.
>
> Issue #3211:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=3211
>
> A potential workaround you can use in the case of the SuggestBox would
> be to extend it and override the onBrowserEvent() method once more,
> this time making a single call to onBrowserEvent from the wrapped widget.
>
> E.g.:
>
> public class MySuggestBox extends SuggestBox {
> ��@Override
> ��public void onBrowserEvent(Event event) {
> �� �getWidget().onBrowserEvent(event);
> ��}
> }
>
> Give that a try and let us know how it goes. Meanwhile, I'll file an
> issue on the tracker for this bug and let you know once it's reported
> so you can follow up on it.
>
>

'ta bien

public class JecSuggestBox extends SuggestBox {

public JecSuggestBox(MultiWordSuggestOracle multiWordSuggestOracle) {
super(multiWordSuggestOracle);

[Vitali Lovich]

Regarding the example given in the issue, I don't think you are using the new event system properly, are you?  See my note in the issue.

As for the bug using the deprecated event system, don't use the deprecated event system.  Hence the reason it's called deprecated - you get unsupported behaviour.

Cheers

[Jeff Chimene]

On 04/09/2009 05:13 PM, Vitali Lovich wrote:
> Regarding the example given in the issue, I don't think you are using
> the new event system properly, are you? See my note in the issue.
>
> As for the bug using the deprecated event system, don't use the
> deprecated event system. Hence the reason it's called deprecated -
> you get unsupported behaviour.
>
> Cheers

Hi Vitali,

There's been a bug filed on this, for the 1.6 branch. The problem occurs
even when using the new event system.

See issue #3533:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3533

Cheers,
jec

[Vitali Lovich]

Please refer to that issue as well where I point out the proper way to use it in the new event system.

[Jeff Chimene]

On 04/09/2009 05:13 PM, Vitali Lovich wrote:

> Regarding the example given in the issue, I don't think you are using
> the new event system properly, are you? See my note in the issue.
>
> As for the bug using the deprecated event system, don't use the
> deprecated event system. Hence the reason it's called deprecated -
> you get unsupported behaviour.
>
> Cheers

Hi Vitali,

Perhaps posting only the 1.5 code while referring to 1.5 and 1.6 was
confusing. My apologies.

Both the 1.5 code (deprecated when using the 1.6 library) and the new
1.6 code manifest the same faulty behavior. I never posted the new 1.6
code to this list. A sample of the rewritten code is now associated w/
the issue conversation thread. Even when calling
event.stopPropagation(), the rewritten code manifests the faulty
behavior. The deprecated code using the 1.5.x library never manifested
the faulty behavior.

Cheers,
jec