Block Swing pop-up from losing focus and closing - java

I'm developing a plugin for IntelliJ IDEA, which obviously uses Swing.
For a feature I have introduced I'd like to stop a JPopupMenu which uses JCheckBoxMenuItems from losing focus and closing.
You can see it in action.
I've debugged the code, but I couldn't figure out how to do it, also being I'm not that into Swing.
Could you maybe point me to useful listeners/blocks of code/ways to prevent this?
If you want to see code, the IntelliJ classes are
ActionPopupMenuImpl.MyMenu
ActionMenuItem

Edit: a better way need to be found as the uiRefreshed event isn't always called at the right time.
Just coordinate your code in a good way ;)
The Swing mechanism in IDEA is too complicated, and maybe it's better to not touch it. Just know that the mouse events are handled by a special listener and then redirected to Component(s).
That said, having an hold on the menu ActionButton. You can listen for the Lookup's uiRefreshed event and programmatically:
myMenuButton.click()
That's all.
You need to call it after the UI has been refreshed because the LookupUi might have changed in dimension or location.

Related

Disabling everything while swingworker is working?

I have searched the net and can't find the specific thing that would help me out. I have my Swing Worker class doing some work in the background, while that is happening i would like to disable everything on my UI.
I don't want to go from one button to the next (Jlist, Jtable) etc and disabling everything. is there an easier way; Like drawing something on top of my UI and then removing it when Swing Worker is done? can somebody show me how to do something like that. Or what would be your suggestion.
I already know how to get a notice when Swing Worker is done. just looking for the best way to disable everything.
Best would be to parse your JFrame.getChildren() in a recursive manner.
But you could also use a GlassPane- see Root Panes

Disable dialog close for ProgressMonitor

I'm working with Swing's ProgressMonitor.
This produces this nice dialog box for me:
Honestly, I think there's a flaw in the design of ProgressMonitor: What do you think happens if the user closes the dialog box by pressing the red/white cross ? Yep, you guessed it: It simply closes/hides the dialog and whatever job you have going in the background of course continues. There's no way to get the dialog box back, afaik.
Closing the window should either mean "cancel" or simply not be allowed, because I need the user to either wait for the task to complete or cancel it. How do I achieve either of this?
If I could just get a reference to that JDialog then I could do:
dialog.setDefaultCloseOperation(JDialog.DO_NOTHING_ON_CLOSE);
but I can't get that reference.
UPDATE AND FINAL ANSWER
So, I wasn't telling you the full story. In fact I use ProgressMonitorInputStream which of course under the covers use ProgressMonitor, so I thought it didn't matter for the case at hand. But it does!
Andrew is right when he says that ProgressMonitor sets the isCancelled flag when the dialog is closed. This can be verified by looking at the JDK sources. But in order to catch that event you'll need a PropertyChangeListener. When working with a ProgressMonitorInputStream you are likely not to have one (like me) because updating the ProgressMonitor is all taken care of by ProgressMonitorInputStream so you won't have to do that part yourself. I was under the assumption that ProgressMonitorInputStream's raison d'etre was in not having to do boilerplate coding.
I have to say that I find the benefits of using a ProgressMonitorInputStream to be extremely small or even negative compared to a DIY approach.
Check ProgressMonitor.isCanceled(), which indeed, the ProgressMonitorDemo does.

Key event not captured in Applet AFTER I've pressed one of my GUI buttons

I have music Applet which uses keyboard, mouse and GUI buttons. When applet is first loaded keyboard events work fine, as do mouse events. However, after I have pressed one of my GUI buttons the mouse events still work but the keyboard events don't, and don't start working again until I refresh the applet.
After hunting around on the net I found some posible solutions, I've tried adding button.setFocusable(true); and button.addKeyListener(this); to all my buttons, and and my panels. No effect at all. I've seen recommendations for converting to a JApplet and using key binding, but surely there must be a simpler way?
Sorry for the lack of code, I've been working on this project since I was a newbie and it's a bit of a mess, and very long!
Any help much appreciated!
button.setFocusable(true); and button.addKeyListener(this); to all my buttons
For JButton use Swing Action or default implementations for ActionListener, rather than KeyBindings (for Swing based Container and JComponents), nor using KeyListener
EDIT
if isn't there really important reasons, don't use prehistoric AWT Applet, use JApplet, may be sufficient would be plain JFrame
Try to cut the problem area out of your project and put it here. Its highly probable, than while localizing the problem area you'll find some errors already.
If your project is a mess already, then the first and the most important thing you should do, is to order it. If it is a mess for you, that means you don't understand it. So, it simply can't work. That is your first and main error.

Java problem, disabled controls still fires events!

I'm new to Java, I'm coding on NetBeans. The problem is that whenever I disable a control
i.e jmenu.setEnabled(false) it still fires events! holy crap! how is it! :P
How can I prevent it?
From the javadoc:
Note: Disabling a lightweight
component does not prevent it from
receiving MouseEvents.
Note: Disabling a heavyweight
container prevents all components in
this container from receiving any
input events. But disabling a
lightweight container affects only
this container.
You might want to check out disableEvents(long mask).
To fit in with the event model adopted by Swing, I think your best option is to just add a check of isEnabled() in the handlers that you don't want executed when the component is disabled.
Consider using javax.swing.Action-controlled Swing components.
In this way, you can instead disable an Action directly with Action.setEnabled. Its component(s) will adopt its state automatically. When disabled in this manner, the components won't receive MouseEvents.
See the docs on the constructor JButton(Action).

Resizing JPopupMenu and avoiding a "flicker" issue

I am trying to implement a search results popup list similar to the style found here:
http://www.inquisitorx.com/
(I'm not trying to implement a Google search, I'm just using this as a rough example of the style I'm working on.)
In any event, I am implementing this by using a JList contained within a JPopupMenu which is popped up underneath a JTextField.
When a user enters search terms, the list changes to reflect different matching results. I then call pack on the JPopupMenu to resize it.
This works, however, it creates a slight flicker effect since it is actually hiding the popup and showing a popup. (See the private method getPopup in JPopupMenu where it explicitly does this.)
Is there any way to just get it to just resize itself (aside from using a JWindow)?
to me work :
popup.pack();
popup.validate();
this work in linux with java version "1.6.0_34". I don't know is that work on windows.
The setSize() method didn't work in my case. The popup.pack() approach did work, but also resulted in a flicker. The best solution that I have found was the one found here. In short:
Window window = SwingUtilities.getWindowAncestor(popupMenu);
window.pack();
window.validate();
Have you tried setSize()? It looks like that gets handled in JComponent and might avoid the repaint issues.
I think the issue that getPopup is addressing is what to do when the dimensions of the popup will not fit within the window. When that happens, it drops back from a lightweight component to a heavyweight and that definitely requires a hide and show. So, I think if you can guarantee your popup won't extend beyond the window the setSize might do the trick.

Categories

Resources