> On Feb 7, 2015, at 11:36 AM, Tomas Mikula <tomas.mik...@gmail.com> wrote: > >> 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?
Mostly just thinking out loud. E.g. generating multiple key events from a single one to build a sort of macro. I'm not convinced either, but I thought I would throw it out there for discussion. Scott
