Thanks for the explanation - I knew that already (had to do so with Tree to change a private method).
This is a good approach. Now I just have to think how to implement it. I will try some different things - I have some ways in mind by now. If I find a good workaround, I will let you know! Thanks again for your answer. Jakob On Sep 14, 9:02 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > On Sun, Sep 14, 2008 at 12:43 PM, jakob.korherr > > <[EMAIL PROTECTED]> wrote: > > Hmm. This would maybe help, although the SuggestBox is final and not > > really designed for extending. > > You can work around that by maintaining your own version of > SuggestBox. If you extract SuggestBox.java from gwt-user.jar and put > it in a source directory in your project that comes before > gwt-user.jar on the CLASSPATH, the GWT compiler will pick up the > extracted version instead of the version in gwt-user.jar. You can > then modify the extracted version to suit your needs--whether that > means just removing the final keyword, or more invasive changes. If > the "right" place to make the change is in a class other than > SuggestBox, just extract its source file instead. If you come up with > a clean patch that looks generally useful, you could submit it for > inclusion in GWT 1.6, too. > > > A great way would be changing the order of the events, so that the > > click event fires before the focus event. Do you thinkt this is > > possible - or even better: do you know a way to do this? > > I think that might be difficult to impossible. Ignore GWT for a > moment and consider just what the browser is doing: clicking on the > pop-up list causes the text box to lose focus. I'm pretty sure every > browser will fire the lost-focus event on the text box before firing > the click event on the pop-up's element. GWT can't do anything about > the order in which the browser delivers events, and the only way it > can fire lost-focus or click events for itself is by piggy-backing on > the browser-native events. > > The only idea I have that might make it possible is to complicate > SuggestBox's event handling. When the wrapped text box fires > onLostFocus, the SuggestBox could set up a delayed call to fire its > own onLostFocus, rather than firing it directly. In the pop-up's > onClick listener, the delayed onLostFocus would then be canceled. The > idea is that if focus is lost because some other widget has gained it, > then the delayed onFocusLost will fire. If, on the other hand, focus > is lost because the pop-up has gained it, then the SuggestBox as a > whole hasn't really lost focus, so the pending onFocusLost can be > sanely canceled. > > The biggest problem I see with the above approach is that it would > probably re-order related onFocusLost and onFocus events. Normally, > if widget A loses focus to widget B, A's onLostFocus fires before B's > onFocus. If widget A is a SuggestBox modified as above, though, then > I think B will fire onFocus before A fires onFocusLost. Ideally, > that's not a problem--event driven programmes shouldn't normally > depend on the order of events being fired, I wouldn't think--but real > life is hardly ideal. > > Ian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
