pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@googlemail.com>
Subject Pivot event handling
Date Tue, 08 Jun 2010 17:20:20 GMT
I have a question about the preferred way to modify event related behaviour
defined in a component's skin.

A simple example might be to modify the behaviour of a ListView responding
to key presses.
(To keep this example simple, I will assume that all list items are
If the first list item is selected (index 0) when the UP key is pressed, I
want the selection to jump to the last list item.
Similarly, if the last list item is selected when the DOWN key is pressed
the selection should change to the first list item.

org.apache.pivot.wtk.skin.terra.TerraListViewSkin handles UP & DOWN key
press events and is installed as the first ComponentKeyListener on the
As I understand things, this listener code changes the selected list item
before any custom listeners are called.
Custom listeners therefore do not know if the list item has just been
changed from index 1 to index 0 (a press of the UP key handled by the
default skin listener).
This means that they do not know whether they need take further action in
order to alter the selection as described, or do nothing.

I have previously accomplished similar things by
a) grabbing a reference to the relevant listener from the listener
b) removing that listener from the listener list
c) populating a custom 'prioritised' ComponentKeyListener with my own high
priority listener which functions as desired, as well as the original
listener as a low priority
(This calls the listeners in order of highest priority until one has
consumed the event)
d) adding the custom listener back into the listener list
This results in my listener being called first, and only calls the default
listener (from the skin) if I haven't already handled the event.

What is the preferred method of achieving this sort of thing with Pivot?
Should I create a modified version of TerraListViewSkin which overrides the
'problem' code and set this against the specific ListView?
I can see this being likely if the custom listener could not do all it
needed to using publicly accessible API methods of the given component, and
instead needed to directly interact with any private instance data held by
the skin.

I imagine (or rather hope!) that the preferred method would not involve
additional listeners to track the selection states between keypresses.



View raw message