This post originated from an RSS feed registered with Java Buzz
by Danno Ferrin.
Original Post: Use The Source, Duke!
Feed Title: And They Shall Know Me By My Speling Errors
Feed URL: http://shemnon.com/speling/archives/cat_GUI.rdf
Feed Description: Danno Ferrin's Many Reasons he was a Comp Sci Major and not an English Major
As a continuation from my Problems with JTree I cam a cross another gem for the Obscure Java Nuances list: How do you override an existing keybinding on JTable to make it do something else?
Here's the real-world use case, I'm createig a frame that shows a long list of tabular data that the user may want to drill down on to get more specific info that what is available in the table columns, you know, like multi-paragraph data? So I gout the double and right click menu stuff wokring and while playing with it I came to the conclusing that a user using the keyboard to navigate the table may want to uset the enter key to bring up the dialog. Very standard situation UI... use the keyboard to navigate to the widget in question and press the enter key to interact with it. Simple enough?
So the obvious first course of action, use the NetBeans GUI editor to listen to keyboard events on the table and act when I see the enter key. Should be a 2 minut hack right? Worng. The listener will never see the Enter key typed action because of Input Map, Action Map, and the standard key assignments for JTable. In the spreadsheet work that JTable is based off of enter means "go down one row" rather than "do the default action." Which is all fine and dandy except for the fact that like any good UI I am perverting teh default compnent sets for my own purposes.
InputMap and ActionMap aren't a problem for me, I've used them before and it's merely a hassle writing a few more lines of code. Add the action, bind it to to the VK_ENTER KeyStroke, compile run and... WTF!? It's still going to the next row!? Drop in some code, so I see what I am overriding in the Input map, nothing, look to see what other actions are mapped in the InputMap, nothing at all. A quick internet search using the Google(tm) search engine service reveals that people are more interest in doing the oposite of what I am doing. At this point I heard a Alec Guinness whisper to me "Use the Source"
It never ceases to amaze me how when you are looking for the question to a very specific answer how much more information you can get from looking at source code for something that you may not understand than from reading all of the documentation in the world. The reason for this I assume is that no one can ever document every possible question a developer may ever have. However when you do something non-standard that should be a clue that you should document it.
Deep in the bowels of the basic plaf implemenation of the JTable UI in a method that hasn't been used since Java 1.2.2 I find the answer in a comment...
// We register all actions using ANCESTOR_OF_FOCUSED_COMPONENT
// which means that we might perform the appropriate action
// in the table and then forward it to the editor if the editor
// had focus. Make sure this doesn't happen by checking our
// InputMaps.
It turns out that all of the default key bindings for a JTable are stored in the InputMap for when it is an ancestor component and not the focused compnent. On deeper reflection it makes sense when you think of the cell editors and such. But without that information it is difficut, ney impossible to make that logical leap since it is at it's core a design decision.
So where is this documented? In the JavaDocs? No. In the JTable tutorials? No. In the default key bindings for JTable? Even though it would make sense no. Thank goodness that Java ships the source to exposed classes, or else I never would have made the leap. When all else fails... Use the Source, Duke.
Previous Topic
