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? > > Let's say I have a TextField and I only want to allow typing of capital > letters. That is easy enough to enforce with an event filter.. if the > KeyTyped event doesn't represent a capital letter I can consume it in an > event filter and it won't get to the control. > > But let's say that I want to allow the user to type lowercase letters and > have them appear in uppercase. I don't ever want the text property of the > TextField to hold a lowercase character. Can that be done? > > 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- > and the fields are > immutable. So it doesn't seem like I can change the event that is > delivered to the target. (What are the copyFor(...) methods on Event used > for?) You don't need to worry about the copyFor methods, AFAIK they are used only by the event dispatching mechanism. I think you need to implement them if you define your own event type. > > 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. 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.) 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? 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. Regards, Tomas
