So my question, as stated (sort of) in the title, is about the behaviour in some respects of the Javafx (namely 2.2) Popup. Most of the time, you get a popup, and you give it a window to act as it's parent, you give it some scene, and it tends to act relatively independently.
This is all fine, however, in my case, I needed a popup that would anchor itself to a particular stage (window), at a particular location, when an event happened. That popup would then, in turn, disappear when the window disappeared (minimize, off screen, whatever), moved when it would, and in all essence and functionality, be a physical extension of the window, just with a custom shape.
Now of course, there are a lot of nuances with that, and everything for the most part, works great. The only thing I can't seem to figure out is that normally in a platform like Windows 7 64 bit, say. You open two programs, alright. Then if the programs are overlapping a little bit, whichever has focus gets to have the entire program displayed, whereas the other one gives the impression of being 'behind' the other window. (Whether or not windows actually renders application graphics 'behind' a window when another has focus on the same spot, I'm not sure.). Normally, javafx also supports this functionality just fine. But for some reason, The Popup class in javafx (see docs here) doesn't do that. It's always on top of whatever it's displayed with, without exception. For the point of completeness, here's my pretty straightforward popup code (at least the part pertaining to showing it and it's properties):
Popup myPop = new Popup();
//************************Popup Property Setter**************************
//&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
myPop.setWidth(width);
myPop.setHeight(initialHeight);
myPop.setAutoHide(false);
myPop.setAutoFix(false);
myPop.setHideOnEscape(false);
myPop.setX(xLocation);
myPop.setY(yLocation);
//&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
//**********************end of Popup Properties**************************
myPop.getContent().add(main_anchor);
myPop.show(FileChooserWindow.get_stage());
main anchor has some various components i include inside of the 'myPop' popup, and FileChooserWindow is a non-null parent window that will be open at the time of this method calling without exception.
Here is a screenshot as well of the behaviour I'm referring to. Notice the highlighted text in the pdf, that is where my cursor currently has focus. Also, the window that the popup is anchored to can be seen in the back of the pdf poking out from the left.
Any help you guys can give would be much appreciated. I really hope I don't have to check for active processes and their location relative to the popup, that's getting dangerously close to my knowledge border, and sounds like a total PITA.
So, after toying with this for a few more days, I have a rough workaround, although it is a hack in the full meaning of the term.
Although the popup behaviour is still mystifying me, I can simulate a fix in this behaviour by adding a changeListener to the stage to which it is attached (since I didn't want the popup to close if it's parent window had focus, only if anything BUT the popup and it's parent got focus).
See code as follows:
FileChooserWindow.get_stage().focusedProperty().addListener(new ChangeListener<Boolean>(){
#Override
public void changed(ObservableValue<? extends Boolean> ov, Boolean oldValue, Boolean newValue) {
if (!newValue){
if(AutogenPopup.popupReturner().focusedProperty().get()){
AutogenPopup.popupReturner().hide();
}
}else{
if(FileChooserController.refreshAutoPopup && FileChooserController.autoGen_flag){
AutogenPopup.popupReturner().show(FileChooserWindow.get_stage());
}
}
}
});
never mind some of those flags that I'm checking against, they are simply some internal tools to make sure that the popup only appears when the program is in the proper state.
Now, one interesting thing to note. The AutogenPopup.popupReturner().focusedProperty().get()
Seemed to be returning true when the popup's parent window LOST focus. Which is quite counter-intuitive to me, and in my opinion, is even a touch buggy. Now, this does not simulate the behaviour of a modern operating system where a window can slide in and out of focus incrementally, since the popup will just completely disappear upon it's parent window losing focus. But seeing as how my popup just displays additional text entry on the side of the main window, this is an acceptable compromise until I think of a better solution. (Perhaps the better solution is not to use a popup at all, and instead skin a window to act in a popup-y fashion).
Anyway, I hope this helps someone, maybe eventually there will be a more fine-grained way to control this popup functionality.
Related
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.
I was recommended to use InteractionDialog rather than Dialog, but I'm failing to see the advantages. What I can see is a problem. What I need is letting the user enter a PIN or whatever and wait for their answer. This is needed both on the EDT thread (the user choose to save the PIN) and on other threads (a web page requires the PIN for login).
With Dialog,
I can call it from the EDT thread and it works nice.
When on a different thread, I can be trivially adapted by a one-liner in the callee (see getFromGui in my linked question).
With InteractionDialog,
I can use it easily from other threads via some simple wait/notifyAll magic.
I can't use it from the EDT thread, except via callbacks like okBtn.addActionListener(...), which is verbose and ugly.
So I am confused and asking:
What do I gain from the InteractionDialog?
Is there a simple way how to use it uniformly no matter what thread I am on?
There are two separate things here:
Modality
How it works
A dialog can be modal or non-modal but it isn't interactive like an InteractionDialog. The modal dialog blocks the EDT internally using InvokeAndBlock so the current thread stops until there's a response from the dialog. This is convenient but has some edge case issues. E.g. the event that launched the dialog might trigger other events that would happen after the dialog was dismissed and cause odd behavior.
But that's not the big thing in modality. Modality effectively means the form behind you "doesn't exist". Everything that matters is the content of the dialog and until that is finished we don't care about the form behind. This core idea meant that a dialog effectively derives form and as such it behaves exactly like showing another form effectively disabling the current form. What you see behind the dialog is a drawing of the previous form, not the actual form.
Text fields can pose a problem. Because the way the dialog is positioned (effectively padded into place within its form using margin) the UI can't be scrolled as text field requires when the virtual keyboard rises. Since people use dialogs in such scenarios we try to workaround most of these problems but sometimes it's very hard e.g. if the dialog has a lot of top margin, the virtual keyboard is open and covering it. Or if the user rotates the screen at which point the margin positioning the dialog becomes invalid.
Note that in InteractionDialog Some of these issues such as the margin to position also apply.
Now InteractionDialog is a completely different beast that sprung out of a completely different use case. What if we want a dialog such as a "color palette that floats on top of the ui?
We can move it from one place to another but still interact with the underlying form. That's the core use case for InteractionDialog. As such modality is no longer something we need so it was never baked into InteractionDialog although it technically could have been (but it doesn't make sense to the core use case).
It's implemented as a Container placed into the layered pane of the current form so the form around it is real. Because the form is "live" layout works better and the removal of modality makes some edge cases related to editing slightly better. There are still some inherent problems with dialog positioning and rotation though. It also allows you to click outside of the dialog while input is ongoing which might be a desirable/undesirable effect for your use case.
Overall I try to use dialogs only for very simple cases and avoid input when possible. If I use input I never use more than one field (e.g. no-username and password fields) so I won't need to scroll. These things work badly for native UIs as well e.g. with the virtual keyboard obscuring the submit button etc. Since those behaviors are very hard to get right for all resolution/virtual keyboard scenarios.
Based on the answer from Shai, I wrote a form working as the base class for most of my dialogs. Basically, it shows the content from the subclass and adds the "OK" and "Cancel" buttons.
There's a method for use from the EDT thread like
public void showAndThen(BooleanConsumer consumer) {
assert CN.isEdt();
...
okBtn.addActionListener(a -> {
lastForm.show();
consumer.accept(true);
});
cancelBtn.addActionListener(a -> {
lastForm.showBack();
consumer.accept(false);
});
}
where BooleanConsumer is a trivial void accept(boolean b) interface.
There's another method for use from other threads
#Override public final boolean ask() {
assert !CN.isEdt();
final BooleanTransfer transfer = new BooleanTransfer();
CN.callSerially(() -> showAndThen(result -> transfer.set(result)));
return transfer.await();
}
where BooleanTransfer is a two-method class where the thread calling set passes a boolean to the thread calling await.
I am trying to have a JavaFX Pane (VBox in my case, but I don't think it matters) that has a ContextMenu that behaves correctly.
I have found these two questions: why Panes can't have ContextMenus and How to create ContextMenu within a Pane.
The problem I'm having with these two solutions (which are very similar) is that while the context menu correctly disappears if I click on the pane, it doesn't disappear if I click inside a control within that pane. The simplest way to observe this flaw is to create such a pane with a TextField. Right-click on the pane to show the context menu, then click inside to TextField to focus on it. While a proper context menu would disappear at this point, this "hacked-in" context menu (for lack of a better term) happily stays in it's place, possibly blocking the user's view of the text field they are trying to fill.
Now, I know I can add a change listener to the focused property of each and every control on my pane, but that feels redundant. Is there a better way to make sure the context menu is hidden when a control in my pane is selected (or, more accurately - when the user click the mouse anywhere in the owning window outside the context menu)?
What I tried so far and doesn't work -
Adding a change listener to the pane's focused property - it appears the pane isn't considered focused if one of it's children is
Adding a change listener to the context menu's focused property - it appears the context menu's focus isn't changed when clicking outside of it.
Ok, so after some digging in the source code for JavaFX I have found this workaround (which is what "solves" this problem for normal controls). Simply add this line of code -
contextMenu.setImpl_showRelativeToWindow(true);
Now, I know using internal implementation methods is discouraged as they may disappear, but this is the only solution I have found. If anyone has a better solution I'll be glad to hear it, but I suspect this is simply a bug that should be filed (i.e. - there should be a way to use the showRelativeToWindow mechanism when setting context menus on panes).
I guess a somewhat safer solution would be to have a throwaway control (not in the scene graph) on which to set the context menu, but I don't know if this would have any unwanted side effects:
Label throwaway = new Label(); // No special reason for using Label, could be any Control.
throwaway.setContextMenu(contextMenu); // note that this is the only place `throwaway` is used, it is never added to the scene graph
// or referenced again, but just setting the context menu on a control solves the problem.
Edit
After digging some more I have found this, and a solution in the discussion - you should call the show method overload which takes a window, not a node! Not very clear, but it works:
myPane.setOnContextMenuRequested(event ->
contextMenu.show(myPane.getScene().getWindow(), event.getScreenX(), event.getScreenY())
);
I'm trying to allow the user to change the title of a window in Java without adding components to the window itself. I'm actually trying this with a JInternalFrame, but figure the solution should be similar for a JFrame. I simply want to add an additional menu item in the context menu that pops up when right clicking on a window title bar. For example, the Set title below:
This example is on Windows XP, but perhaps there's a way to get the window context menu OS independently perhaps similar to the SystemTray.getSystemTray() (but for individual windows within an application). From this I would be able to provide my own ActionListener to popup a dialog for the user to enter a new title.
Is this a much bigger task than I'm guessing it is? Does anyone have solutions they've used before?
Short answer: I don't think this is easy. I'm not 100% sure if it is possible.
First, JFrame and JInternalFrame are actually quite different. JFrame is a top level component whose title bar and such are typically provided by the OS. JInternalFrame's entire content (including title bar) is provided by the Swing LAF.
For a JInternalFrame, the context menu is provided by the LAF, not JInternalFrame itself. You would have to do something with the UIComponent in order to change the context menu. I think you would likely have to provide a custom UI component in order to do this, which is ugly and typically breaks across different LAFs or works but looks terrible at best. See BasicInternalFrameTitlePane, the createSystemMenu method.
I don't think this is possible without digging way too deep into Swing's internal UI system and I wouldn't even consider doing this. Why don't you use the inbuilt JMenuBar of JInternalFrame?
myInternalFrame.setJMenuBar(myMenuBar);
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.