Thanks Thomas... That and gazing wisely (or at least trying to give
the appearance of looking somewhat informed) at TextBoxBase.class got
me this...
public class MyComposite extends Composite implements
HasValueChangeHandlers<String> {
private void internalMethodToHandleUpdates() {
// handle validation and all sorts of other stuff, then
if
// if it looks good let outsiders know...
ValueChangeEvent.fire( this, "theNewValue" );
}
public HandlerRegistration addValueChangeHandler(ValueChangeHandler
handler) {
return addHandler(handler, ValueChangeEvent.getType());
}
}
..which looks like it should work. Still fuzzy on why the widget can't
manage an independent list of handlers under the hood, and the event
typing system still has me baffled, but this'll get me past the puzzle
box that kept me busy yesterday and seems less complex than what I was
doing... Thanks for your help!
On Aug 20, 2:25 am, Thomas Broyer <[email protected]> wrote:
> On Aug 20, 2:33 am, jscheller <[email protected]> wrote:
>
> > Hello -
>
> > So, I've got a composite that has something like this inside it...
>
> > private HandlerManager changeHandlers = new HandlerManager( null );
>
> > public HandlerRegistration addValueChangeHandler(ValueChangeHandler
> > handler)
> > { return changeHandlers.addHandler(ValueChangeEvent.getType(),
> > handler); }
>
> You shouldn't ever instantiate a HandlerManager (except if you use one
> as an "event bus"; but that's another story and at least this rule is
> true for widgets); just call the Widget#addHandler(...) method.
>
> public HandlerRegistration addValueChangeHandler
> (ValueChangeHandler<String> handler) {
> return addHandler(handler, ValueChangeEvent.getType());
>
>
>
> }
> > ...and somewhere down the pipeline, I want to actually fire off an
> > event to anyone who registered a handler when the composite decides
> > it's represented value has changed and wants the rest of the world to
> > know. However, the syntax for actually constructing and firing the
> > event off has got me pulling my hair out.
>
> > I've tried variants of sending the event through the change
> > handlers...
>
> > changeHandlers.fireEvent( new ValueChangeEvent("foo") );
> > changeHandlers.fireEvent( new ValueChangeEvent<String>("foo") );
>
> > ...and using the static fire() method in the event class itself...
>
> > ValueChangeEvent<String>.fire( changeHandlers, "foo");
>
> > ...and Eclipse complains loudly about all of these constructions. I
> > mean, I know this can't be that hard, but I can't find any good
> > examples of things like this using the new (GWT 1.6 or later) event
> > handlers, and reading the code sends me down a DOM event/Java generics
> > rabbit hole that I'm frankly not experienced enough to deal with
> > yet...
>
> > Any help appreciated!
>
> ValueChangeEvent.fire(this, "foo");
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
