Thanks for the quick response, Greg. I absolutely agree that the listener list 'hack' is just that and far from perfect, but it allows for the trivial change to be injected with very little effort and just a few lines of code. The reason I took that approach is that it seemed too much effort for the other routes that I could think of, and none of them seemed any more elegant. (Not that I was avoiding the effort, it just suggested to me that those other approaches were not the best way either)
At least I now know that I wasn't missing something obvious. Chris On Wed, Jun 9, 2010 at 12:46 AM, Greg Brown <[email protected]> wrote: > Extending the default list view skin is certainly one solution. However, I > actually don't see a problem with monitoring selection change events as well > as keyboard events. There is no implied association between keyboard events > and selection change events - it is up to the skin (or other listener) to > create that association. So, I might say that, by definition, you need to > listen for both types of events in order to implement the logic you > describe. > > I don't think that hacking the listener list is a great approach, though. > Seems like...well, a hack. :-) > >
