On Fri, Feb 6, 2015 at 8:45 PM, Scott Palmer <swpal...@gmail.com> wrote: > >> On Feb 6, 2015, at 8:21 PM, Tomas Mikula <tomas.mik...@gmail.com> wrote: >> >>> On Fri, Feb 6, 2015 at 7:33 PM, Scott Palmer <swpal...@gmail.com> wrote: >>> Is it possible to modify the event in an event filter or otherwise tweak >>> the event that is ultimately received by the target? >>> >>> <snip> > >>> >>> There are no public constructors for KeyEvents, >> >> Are we looking at the same Javadoc? >> http://docs.oracle.com/javase/8/javafx/api/javafx/scene/input/KeyEvent.html#KeyEvent-javafx.event.EventType-java.lang.String-java.lang.String-javafx.scene.input.KeyCode-boolean-boolean-boolean-boolean- >> > > No. :-) > I wanted to do this originally with Java 7 > The JavaFX 2.2 docs do not list any constructors. > >>> >>> I suppose the 8u40 support for formatted fields is what should be used for >>> my example, but the idea of tweaking the events before they are delivered >>> to an event handler, or synthesizing a new event is more general. Is it >>> possible? >>> >>> Scott >> >> 1. So I think that you can proceed with what you have in mind: consume >> an event and create and fire a new one (with Event.fireEvent(target, >> event)), but I am afraid that is going to mess the order of events. >> Suppose you type JavaFX *really* quickly (or when the UI thread is >> busy with something else). IMO you end up with is JFXAVA instead of >> JAVAFX. > > Yeah that would be a problem. I suppose I could be extra clever and remember > and consume the 'F' and 'X' events in my filter and then fire new ones after > I see my synthesized event come through. > This is starting to smell though. > >> >> 2. You could instead consume the event in the event filter and handle >> it properly yourself, i.e. call textField.replaceSelection() and such. >> (Not very nice, I know, I would not like reproducing TextField's >> behavior.) > > Agreed. > >> >> 3. I understand that you don't want some property to ever hold an >> invalid value, but does it have to be the textProperty of the >> textfield? > > It just makes things easier to use without the intermediate property and > temporary lowercase state on the textProperty, but yes that is one workaround. > >> If you set up your data flow like this: >> >> ObservableValue<String> upper = EasyBind.map(textField.textProperty(), >> String::toUpperCase) >> upper.addListener((obs, oldVal, newVal) -> textField.setText(newVal)); >> >> And then use `upper` wherever you used textField.textProperty() >> before, the rest of your code will never observe any lowercase >> characters. >> >> 4. Your idea of tweaking an event on its route is interesting, though. >> Let's see if other people have some opinion about that. > > Perhaps a new kind of filter could simply return an event if it is meant to > be passed on, or return null to prevent it from going any further. Then I > would just return a different event than the one that was passed in if I > needed to tweak it.
Makes sense to me. I like this better than the side-effecting consume() method. Better yet, return Optional<Event>. > Perhaps returning an array of events would be more appropriate, then one > event could cause many downstream events. I am not so sure about this. What use case do you have in mind? Tomas > > > Scott
