java popup menu has no focus with VK_CONTEXTMENU - java

I am incorporating a popup menu in my java application.
I have added a mouse listener to show it up and I have also registed a keyboard action with the key event KeyEvent.VK_CONTEXT_MENU, that brings it up as well.
Problem is that the popup has no focus when it gets to be shown. I can't use the up and down arrows in order to walk it through. In fact, it can be operated only with the mouse (which takes the stinger from my wish to operate my system using the keyboard only...).
I could not find any useful information on that issue over the net, and have already read the java tutorials entry on menu. I also tried the following (each on its own, and cooperated), and none of them worked:
Calling popupmenu.requestFocusInWindow() before and after the show is invoked.
Calling popupmenu.setSelected(firstMenuItemObjectInstance) before and after the show is invoked.
Calling firstMenuItemObjectInstance.requestFocusInWindow() before and after the show is invoked.
any ideas ?

Related

JDialog onTop overlapped by another in a strange way

I am developing a Swing application with custom CSS rendering. As part of the system I use JDialogs as well, but I need to access certain components outside of the dialog (emergency buttons).
For this I chose following method:
all dialogs are non-modal. Those I want to make quasi-modal, will be setAlwaysOnTop.
There is always one quasi modal dialog up. In this case I put another dialog up, below this one, full-screen, semi-permanent.
This "blur" dialog shall cover the whole screen, catch mouse events and forward them to the emergency buttons only. In parallel I opened gaps on it so that the emergency buttons can be seen through the semipermanent surface without any effect.
The blur dialog can never be focused or activated (I have a vetoable listener for this)
Everything works fine, until someting happens and the blur dialog seems to cover my quasi-modal dialog. However, if I move any external application window over it, the quasi-modal dialog remains on the top. Instead of a complicated explanation, see picture un following link: http://lost.lost.hu/javascreen.png
So far I tried to debug repaints, events, everything, and could not find anything that would cause this. Especially the case depicted above challenges me to understand what is going on here.
I have recently updated to Java 1.7, in hope to get rid of this phenomenon, but today it came back.

Hear text (screenreader) when mouse hovers over a JMenu object in Java / Windows

When using a screenreader, like NVDA, I want to be able to hear the text of the menu when I hover my mouse over it. I am able to hear the text when I push the buttons in the menubar, but not when I hover over them (the screenreader does reads the menu's of other programs when only hovering over the buttons).
I have set the AccessibleContext like below:
JMenu.getAccessibleContext().setAccessibleName("text");
JMenu.getAccessibleContext().setAccessibleDescription("more text");
I can set listeners to the objects that detects when a mouse hovers over them, but I do not know if/how I can cast a text to the screenreader to read. I tried ToolTipText, but that text is not read by the screenreader either. RequestFocus on the JMenu works, but setting the focus to an object just by hovering over it with the mouse provides other problems.
Does anyone knows how I can let a screenreader reads the JMenu-text when hovering with the mouse over the menubar?
I am using Java6 EE and the Java AccesBridge (version 2.02) on a Windows machine (XP and w7).
Swing is the weaker of the GUI technologies relating to accessibility in Java, compared to SWT at any rate. There's a few things you can try.
First is to make sure any accessibility fields are set (which you've started on). I can't remember if Java has an AccessibleRole field, but you can try setting that to menu and menuitem for your menu items.
Another thing you can try is the AccessibleMenu JMenu.AccessibleJMenu component. This one's the product of further reading, so I can't verify it from experience. But it and its surrounding classes may suit your needs.
If those don't work, you could try the option of talking to people's screen readers directly. Quentin C has a good library to do this, Universal Speech. I'm new to this library myself, but it does have a Java implementation in there that should show you how to use it in a Java program. Normally I wouldn't recommend this approach unless making the UI accessible really isn't working.
The last option would be to use the SWT components instead of the Swing ones, even if just for your menu bar. I wasn't sure how keen you'd be on this one, but it is an option and should resolve it.
I hope one of these suggestions helps you solve your problem.

Passing accelerator keystrokes to the main menu in Java

I have added some accelerators to the main menu, using MenuItem.setAccelerator(). Just basic stuff like ctrl-c for copy, etc.
This works ok. But the app is a bit like an IDE, it has several panels containing JTables. If a table cell has focus, it absorbs the accelerator key, which means the main menu never sees it.
Clearly, if an editable table cell is active I would like the cut and paste keys to function normally, but in every other case I would like the main menu to respond.
Any ideas?
KeyStrokes go to the component that has focus first. Since JTable binds Ctrl+C to an Action, that action is invoked.
If you don't like the default Action of the table, then you would need to remove the binding from the table.
Read the section from the Swing tutorial on How to Use Key Bindings. It shows you how to remove a binding.
Thanks, that got me on the right track.
Removing the bindings didn't quite work, it just stopped the table doing its default action so the keypress was ignored altogether.
However, adding this to the table itself worked ok:
component.getInputMap().put(KeyStroke.getKeyStroke(KeyEvent.VK_C, ActionEvent.CTRL_MASK), "copy");
component.getActionMap().put("copy", actions.copyAction);
(Repeated for each desired key of course). Needs to be kept in synch with any changes to the main menu itself, but I can't see a way to avoid that with any method.

JAVA-I don't want clicking on my app make other apps lose focus

Wow, what a stupid question you might say. But is it possible? I have a mouse move event in a Jpanel and it works even when the application is not in focus, now can I have something like that for the clicking event or something similar. And most importantly I don't want other apps (even something like the main menu) to lose focus when i click on my app.
I thought of the system's event queue but i'm not sure where that would lead me to.
Thanks in advance.
[EDIT - the purpose]
I want to create an app that mimics the users interactions with the system in a later time. for example a user takes the mouse and clicks and writes and my app will mimic that in say 2 hours time. ofcourse i would need a system hook for the outer events but i wanted to avoid os-dependant code so i basically capture the screen, take it to my app,for example the user clicks on an icon in the captured picture and then for making that come to life, i translate the coordinates to the real icon and click it (with a Robot) and in this way i can capture the user's events in my own app. the problem occurs when the user clicks on the main menu or right clicks (he's doing that in my app, and my app does that to the system so my app is in between) and ofcourse the real main menu will lose focus when the user tries to click on one of it's items.
sorry for my english.
I'm still not sure I follow what you are trying to do. But the concept of an app getting focus when you click on it is fundamental to the GUI and I suspect rather difficult to get around.
I just found this:
Focusable Windows
To support palette windows and input methods, client code can prevent a Window from becoming the focused Window. By transitivity, this prevents the Window or any of its descendants from becoming the focus owner. Non-focusable Windows may still own Windows that are focusable. By default, every Frame and Dialog is focusable. Every Window which is not a Frame or Dialog, but whose nearest owning Frame or Dialog is showing on the screen, and which has at least one Component in its focus traversal cycle, is also focusable by default. To make a Window non-focusable, use Window.setFocusableWindowState(false).
In this doucment http://java.sun.com/j2se/1.5.0/docs/api/java/awt/doc-files/FocusSpec.html
That sounds like it might do what you want.

Error Dialog Not Being Destroyed

I am working on a project that is using a JTable to display, among other things, a column of dates. We needed validation for the user input for dates, so I have implemented a combination of masking for format validation and parsing for actual date validation. I have done this using a custom CellEditor for the date column.
Inside my MaskedCellEditor, I have a JFormattedTextField. I setup the masking for dates. Then I add an InputVerifier to allow for actual validation. My InputVerifier implements verify() to check: 1. textField.isEditValid() 2. DateValidator.ValidDate(). If either is invalid, verify returns false and the InputVerifier locks the focus into the text field (the cell editor) and a small message dialog is displayed reminding the user of the date format.
The error message is a small, undecorated, non-modal, non-focusable JDialog that pops up underneath the cell being edited. It disappears on a keypress or a successful date verification. It is working great except for a small edge case.
If the user selects a menu button on the top of the application while an invalid edit has popped up the dialog, it switches screens, destroying everything currently on the screen (including the table). However, since the dialog is being shown and a keypress/successful edit has not occurred, the dialog is never hidden. It remains visible in a completely unrelated context on a different screen. Once the user has switched off the screen with the table, there is no way for the user to get rid of the dialog.
I have debated throwing either a Timer and/or a MouseListener on the dialog itself that would cause it to disappear, but I feel that I am ignoring the actual problem. The dialog is never being disposed of and I am pretty sure its because it is still set to be visible and it is preventing the garbage collector from getting rid of it.
I have a Cleanup method on the panel holding the JTable, but I cannot find a good way to reference the dialog (a component of the InputVerifier) in order to get rid of it. The dialog is pretty far removed from the table's parent panel. (Panel -> JTable -> CellEditor -> JFormattedTextField -> InputVerifier -> JDialog)
Any ideas on how to force the dialog to be hidden when the table is destroyed? If you need more details, let me know. I'm trying not to get you guys bogged down in the details, but there is a lot going on.
As a first thought, can you not go down the listener approach. If you have a closeErrorDialog() type method that gets called when upon successful valdiation, then you can also call it when a menu action is selected.
As an alternative, perhaps you could control the transition from menu to menu in some way, and create a "cleanup" method which will close down any exisiting error dialogs. This would allow for any other actions that need to take place when changing menus, to happen in the same place.
Just a couple of quick ideas of the top of my head. Hope they are along the lines of what you meant
Many people will vote me down for saying this, but it sounds like your dialog should be modal so that users can't switch away from it without dismissing it first. Or at least disable the menus that allow people to switch away while this dialog is displayed.

Categories