Event Filtering

[Scott Palmer]

> On Feb 7, 2015, at 11:36 AM, Tomas Mikula <tomas.mikula at gmail.com> wrote:
> 
>> On Fri, Feb 6, 2015 at 8:45 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>> 
>>>> On Feb 6, 2015, at 8:21 PM, Tomas Mikula <tomas.mikula at gmail.com> wrote:
>>>> 
>>>> On Fri, Feb 6, 2015 at 7:33 PM, Scott Palmer <swpalmer at 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