Martin Vajsar wrote:I didn't formulate my last paragraph well. I meant it as an enhancement to allow the users to change the key combination to enter the special character, ideally by pressing a key combination in a textbox or something similar. However you'd have to figure out how to record and later recognize a key event and bind the action to it. Probably even more work than the problem you've described first.
Martin Vajsar wrote:In this situation I'd probably try to use a key combination that would not collide with keyboard drivers, eg. Alt-E instead of AltGr-E. People that have the special character on their keyboard layout and are therefore used to it will be able to continue to use their natural key combination, and people that do not have it probably aren't used to a specific combination anyway and will have to learn your combination anew. Although entering characters with Alt-key is somewhat unusual, it is still much better than Copy-Paste.
Even if you'd succeed in overriding AltGr, it might present problems for someone with locale you didn't consider, who may have a different character on key combination you chose and who will not be able to enter that character because of your customization. Alt-key combinations are generally reserved for application use, so you should not encounter any collision with keyboard drivers. I'd expect Alt-key and Ctrl-key to be generally safe to use.
If your target platform is not solely Windows, you'll have to consult specific guidelines of other platforms. What I'm saying here is generally valid for Windows, but it might be different eg. on Unix or Mac - I don't know them. I have also no idea whatsoever how japanese or chinese haracters are typed on the keyboard, not even on Windows.
Martin Vajsar wrote:
After all, it might be good idea to allow the users to enter the combination they want to use, especially if you target more platforms or platforms you cannot directly test - might need some work to implement the GUI for this, but will certainly satisfy everyone.
Martin Vajsar wrote:
the question is - what are you trying to achieve?
Martin Vajsar wrote:
If you really want to intercept key events on such a low level, you'll probably have to study JTextComponent (parent of JTextField) and especially its processInputMethodEvent method. You may have to subclass the JTextField and override some methods, or register some InputMethodListeners.
This is just what I've learned from a quick peek into the javadoc and JTextComponent source code, I haven't done something like this myself. You'd be digging pretty deep into Swing so expect it will take some time to get familiar with these mechanisms. I've comparable experience with JTable, which I was extending to handle merged cells.
Rob Camick wrote:The Alt key is used to invoke the Windows System menu. Try "Alt" followed by the "Down arrow" key.
Rob Camick wrote:As a general rule you should be using Key Bindings and not listening for KeyEvents.
Rob Camick wrote:If not then maybe the approach used in the Screen Image class will help.
Rob Prime wrote:
Alexander Walker wrote:
Maneesh Godbole wrote:Why reinvent the wheel?
Check out the various JOptionaPane.showXXXDialog() methods
As far as I know JOptionPane.showXXXDialog() only works on questions, and it is not something that you can modify as you wish, like you can with a JDialog or JFrame. Like adding many buttons or textfields and/or different containers.
Sure it is. The message object doesn't need to be a String. It can be:
- an Icon -- a label with the icon will be added.
- a Component -- the component itself will be added. This component can be a simple component like a JTextField, or a full GUI on its own.
- an Object[] -- each element will be added separately.
- anything else -- the string value will be added as one or more labels, depending on the number of line breaks.
So yes, adding containers is quite possible indeed.
Maneesh Godbole wrote:
If you look at the API, you will notice those methods accept an Object message.
You can always construct your panel, put in all the UI components on it and pass the panel as the message to the method.
Rob Prime wrote:
pete stein wrote:
but myself I'd prefer not to extend JFrame or JDialog if I'm not altering their intrinsic behavior.
Is there any disadvantage with extending JFrame or JDialog, or is it only a personal preference? Good to know for future reference .
It's a bad object oriented approach. Your dialog doesn't add any behaviour or anything. Instead you should just use a regular JFrame or JDialog to which you add the rest of the GUI. So instead of your class being a JFrame or JDialog, it uses one.
But I must admit, I go the lazy way myself all too often and just extend.
Maneesh Godbole wrote:Why reinvent the wheel?
Check out the various JOptionaPane.showXXXDialog() methods
pete stein wrote:
but myself I'd prefer not to extend JFrame or JDialog if I'm not altering their intrinsic behavior.
Darryl Burke wrote:Is it legal to post copyright code on a public forum?