I am having trouble getting message boxes and to a degree dialog boxes to show/function properly in Mac (v10.9.5).
I just updated the JRE and JDK to the latest version (8u31). A "java -version" from a terminal window shows that I am indeed using 8u31. (I was previously using 8u20, which exhibited the same behavior.)
The code below works perfectly in Windows and a couple of different versions of Linux that I tested, no issues. I just have issues on a Mac. I streamlined my code, which is SWT based, but this example uses Swing, to the following:
package myTest;
import java.awt.Dimension;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
public class EntryCode
{
public static EntryCode oEntryCode;
public EntryCode()
{
// TODO Auto-generated constructor stub
}
public static void main(String[] args)
{
oEntryCode = new EntryCode();
oEntryCode.open();
}
public void open()
{
JPanel panel = new JPanel();
panel.setMinimumSize(new Dimension(200,200));
JFrame frame = new JFrame("JOptionPane showMessageDialog component example");
System.out.println("open(): entry - With frame");
JOptionPane.showConfirmDialog(frame, "Wow, works on the Mac!", "Inside open()", JOptionPane.YES_NO_OPTION);
System.out.println("Point 1");
System.exit(0);
}
}
I see the first system out line, and the code hangs on the message box request. In the real code, I simply use a null as the first argument. The original version of this test code used a null too, just I was experimenting with specifying a component. I thought that might be the problem. It is not.
When displaying SWT dialog boxes, there is a tendency that clicking on a button will hang the interface. The hang is somewhere between the button being depressed and the event handler firing. The event handler never fires.
I did not include a dialog box here. I figure that since my confirmation/message box exhibits the same problem that solve one, get the other for free.
I did a search on Google for displaying java applications on a Mac, but nothing turned up.
I would think that updating the JRE/JDK to the latest version would solve any OS related issues.
I compile the code to a jar and use the following to run from a terminal window. I to press Ctrl+C to quite the hung app.
java -XstartOnFirstThread -jar myTest.jar
Thoughts?
UPDATE:
I deleted the original update but am leaving the original question, now that I understand the problem better.
The real problem is how to initiate a proper Mac OSX Cocoa restriction friendly SWT application, which uses dialog and message boxes. (To the best of my knowledge, the only way to display message boxes is to use JOptionPane.show*, which is a Swing thing, thereby sort of mixing Swing and SWT.
It is interesting to note that the problem always relates to buttons, be it on a dialog box (a purely SWT implementation) or message boxes. In the former, the issue is a hang calling the event handler and the latter displaying a message box (null first argument, as no Swing frame exists in a SWT application).
The problem may be that you are not starting the GUI in the EDT. Try this:
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
oEntryCode = new EntryCode();
oEntryCode.open();
}
});
}
More info: http://docs.oracle.com/javase/tutorial/uiswing/concurrency/initial.html
Another issue is using -XstartOnFirstThread with Swing. Swing does the equivalent of what -XstartOnFirstThread is doing, but in its own way. You should not use -XstartOnFirstThread with Swing, just as it's not a good idea to mix SWT and Swing.
If you add SwingUtilities.invokeLater() and remove -XstartOnFirstThread, your example should run normally.
Not quite sure if this might be the error since I can't test it on my Mac at the moment. But you never setting visibility of the JFrame to true. When you pass the frame as a parameter to the JOptionPane the pane tries to show the pane in the frame.
So try :
public void open()
{
JFrame frame = new JFrame("JOptionPane showMessageDialog component example");
System.out.println("open(): entry - With frame");
frame.setSize(300,300);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
JOptionPane.showConfirmDialog(frame, "Wow, works on the Mac!", "Inside open()", JOptionPane.YES_NO_OPTION);
System.out.println("Point 1");
System.exit(0);
}
Also why do you create the JPanel the panel is never used as far as I can see ?
Since the frame is not visible this could cause problems. Just a guess...
This would also explain why it looks like your application is "freezing". Its because it is waiting for you to make the selection in your JOptionPane but you can't make that selection because you can't see the JOptionPane.
I know you wrote you also tried with passing null as argument but I could think this could also cause problems when there is no other JFrame shown. As i said just a guess. Just try it out and come back here to provide further information.
EDIT
Just tested and looks like your code is fine. Your error has to lie in your mac or java setup.
EDIT 2
I think I found your answer. Looks like the startOnFirstThread is the problem here. I just tested via javac and java on command line. Have a look at this:
Swing stops working, because -XstartOnFirstThread implies that that
someone else (very likely the SWT) is going to come around, and start
pumping the event loop on thread 0 with CFRunLoop or the like
This could explain why your JOptionPane struggles to show up. (Taken from: here
Also a bit older but describes your problem:
The AWT problems generally come down to which thread the jvm was started on. When using the java launcher (as pde does) on Mac, java by default starts on the second thread (which is what AWT wants) unless you specify -XstartOnFirstThread (which is what SWT wants).
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=212617)
Related
I am currently developing a digital clock widget. I have designed it using a JPanel form and add it to a JDialog. Here is the code.
static JDialog jDialog = new JDialog();
public static void main(String[] args)
{
jDialog.setUndecorated(true);
jDialog.add(new QuickLauncher());
jDialog.pack();
jDialog.setBackground(new Color(0, 255, 0, 0));
jDialog.setLocationRelativeTo(null);
jDialog.setVisible(true);
}
The problem is when I run this program twice it opens two windows. So what I need is I need only one window to run and if I run the program again instead of running the program again, it needs to focus the application. I tried various examples and methods like isVisible() and isActive() but I can't figure it out how to fix this issue. I tried this also,
How to check if a jframe is opened?
Please anyone can help me? Thanks in advance.
There isn't a particularly clean way to do this. If you're able to use Java 9, you can use the new process API to get a list of all processes with ProcessHandle.allProcesses() and search for ones that match your program, but otherwise you'd need to resort to platform-dependent behavior.
An alternative method (not requiring Java 9) would be to use a FileLock. You would create a file in a known location, then lock it (see above link). When the JVM shuts down, the lock will be released. When your program starts, you can then check whether the file is locked to determine whether your program is already running.
I'm working on a Java project in Eclipse that has a class extending PApplet to run a Processing sketch.
First I have a JFrame login screen, and after the user logs in there, I call
PApplet.main("Game"); //"Game" is the class that extends PApplet
to start the sketch.
Now when the game ends I want to close the sketch window, but not the original JFrame window.
Normally I would call
exit();
in Processing but this closes the entire application (ie all windows).
I have also tried
dispose();
but this does nothing.
I guess I'm looking for something like
frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
but for PApplet.
First, you have to get the instance holding your sketch. That means using the runSketch() function instead of calling main() directly:
Game game = new Game();
String[] args = {};
PApplet.runSketch(args, game);
Now that you have a reference to your sketch instance, you can use it to get to the internal window. How you do this depends on which renderer you're using, but you can figure it out using a mix of the Processing JavaDoc and the Processing source code.
Here's an untested example using the default renderer:
PSurface surface = game.getSurface();
SmoothCanvas smoothCanvas = (SmoothCanvas)surface.getNative();
JFrame frame = (JFrame) smoothCanvas.getFrame();
Now that you have the parent window, you can do whatever you want with it, including:
frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
frame.setVisible(false);
Like I said I haven't tested this code, and this is going to depend on exactly which renderer you're using, but this process of using the source code and JavaDoc to figure out what's going on under the hood to get to the underlying window is what you have to do.
*EDIT 2: I just discovered that this is a compiz+java GUI problem. It apparently happens where those two elements intersect.
I'm running the latest Ubuntu 11.04 (classic desktop, not Unity) with all updates. The problem happens with both Sun java and OpenJDK. It is related to using the Window-Rules Compiz plugin -- which I need to use.
As stated in comments below, I previously verified that my controls are added to the correct thread. Now I found that disabling the Compiz Window-Rules plugin resolves my issue. Since I need to use the plugin, I am looking for a solution.*
Original post: I am working on a Java swing application. It was built with NetBeans 6.9. It uses GridBagLayout manager. The look and feel is currently Nimbus (but that doesn't seem to have any effect on the issue I'm going to describe). Most users run the app on Linux. A few use Windows. Most of the time the app works fine. But at random times a view will open without some of the GUI buttons. For example, the Save and Cancel buttons might be missing. The other GUI elements will usually be present (although once I have heard that a view was completely empty with no GUI elements -- just an empty gray window).
If the user closes that view with the "X" in the upper corner and simply re-opens it, it will be drawn correctly. The missing buttons issue happens less than 1% of the time. The close/reopen sequence fixes it almost 100% of the time. (A second close/reopen may have been needed once, if I recall correctly.)
Typically, if some buttons are missing, the other elements are still drawn correctly. This does not affect the whole view (form). It seems to affect the lowermost panel, but I'm not sure if that is actually a repeatable pattern. It is very difficult to reproduce this. I use the software every day and I see this less than once a month. A few users see it more frequently, but it is still rare.
There are no error messages. I have no idea what to try next. This behavior has persisted across different computers, different Linux distros (although all are based on Debian), and many different code changes, including changing the layout manager. (We used the NetBeans GUI designer previously.) Any ideas?
EDIT: 2011.07.05
This is what the code looks like in general:
public void show_some_view() {
setTitle(...)
setLayout(new GridBagLayout());
JPanel butnPanel = new JPanel();
butnPanel.setLayout(new GridBagLayout());
try {
//add stuff to panels (butnPanel, etc.)
} catch (Exception e) {
Logger.log(e);
}
setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
int[] wh = ApplicationContext.get().getDisplayWidthxHeight();
setSize(wh[0], wh[1]);
setFocusable(true);
setVisible(true);
}
But at random times a view will open without some of the GUI buttons.
Make sure you add the buttons to the GUI on the EDT. Read the section from the Swing tutorial on Concurrency for more information.
Make sure you add the buttons to the GUI BEFORE invoking setVisible(true);
I had the same problem: sometimes my JMenu wouldn't draw (also on Ubuntu 11.04).
I fixed it by just adding
menuBar.setVisible(false);
menuBar.setVisible(true);
To my code, right after I added it to my JFrame (Which was alreasy set to visible).
I know it's messy but it solved my problem so I'm fine with it.
Hope this helps!
I'm searching for a solution in order to keep a JFrame always on top and with always I really mean always.
setAlwaysOnTop( true );
This won't work when I'm starting a game in fullscreen mode. I know you normally don't want your windows to stay on top but in this case it's required.
This can't be done.
For example, the Windows Task Manager, even when set to Always on Top will get covered up by full-screen applications.
This is due to the fact that full-screen applications typically use a different graphics context and can't be overlayed.
Start another process to check if the window is on top,if not, set it on top.
This is a sample code that should be helpful
public class AllWaysOnTop extends JFrame implements WindowListener {
AllWaysOnTop() {
// Code to setup your frame
addWindowListener(this);
// Code to show your frame
}
// The window event handlers. We use WindowDeactivated to
// try and keep the splash screen on top. Usually only keeps
// the splash screen on top of our own java windows.
public void windowOpened(WindowEvent event){};
public void windowActivated(WindowEvent event){};
public void windowDeactivated(WindowEvent event){
toFront();
}
public void windowIconified(WindowEvent event){};
public void windowDeiconified(WindowEvent event){};
public void windowClosed(WindowEvent event){};
public void windowClosing(WindowEvent event) {};
}
Reference
This forum post
This sounds like the kind of question that Raymond Chen always has to answer over at Link. How can you really really forever and for true keep a window in the foreground? You can't. Because what happens if somebody ELSE's window uses the same trick to keep itself always always and forever in the foreground? Which one wins?
If you mean fullscreen as in DirectX/OpenGL/whatever, I'm not sure you can (or should) really pull it off. Most operating systems disable their native windowing during full screen to improve rendering performance. Swing works via the native windowing toolkit.
You could write something that uses a timer and in short intervals (e.g., 200ms) instructs your window to go to the top. Depending on your operating system this would be exactly what you need, or a horrible cause of performance trouble or flickering.
I'm not sure but i would bet that the Fullscreen window also has Always On Top set to true, and in that case you have stumbled into the realm of undefined behavior. In general when two windows are set to always on top there is no guarantee about ordering. I think in general though the order is just dependent on the order in which they were set to always on top. So in that case i would just wait until the app has gone fullscreen to set it to always on top and see if that works.
In other cases ive seen people start threads and then occasionally reset the fram to always on top.
All these solutions are ugly, so just use the one that lets you sleep at night.
I know this post is old, but I encountered this problem and I found a satisfying solution.
My program has some notifications that I wish to be always on top, but when a movie entered full-screen, they disappeared. Fortunate, my program updates these notifications every 5 seconds, and if I call setVisible(true) on these JWindows, at each update, they regain the top position, if they have lost it.
I was looking to do the same thing as OP, have my app running in the foreground while my game ran. It doesn't work in fullscreen but if you put the game into windowed mode and adjust the window settings to fit your tv it works. I only needed the frame.setAlwaysOnTop to make it work.
I wrote the following piece of code, which is supposed to return a panel with one checkbox and one button. The idea is that the button should be enabled only if the checkbox is checked.
It works, meaning that if the checkbox is not checked, and I try to push the button, nothing happens. However, the visual appearance of the button is wrong, it appears as disabled when it should appear as enabled, and vice-versa.
Any idea what's wrong with my code ?
Thanks a lot in advance
public Panel createCalibrationPanel(final ImagePlus imp) {
final Panel panel = new Panel();
panel.setLayout(new BoxLayout(panel, BoxLayout.LINE_AXIS));
panel.add(Box.createHorizontalStrut(20));
final Checkbox checkbox = new Checkbox(
"Use image spatial calibration for q scale", true);
final Button button = new Button("Set scale");
useCalibration = checkbox.getState();
button.setEnabled(checkbox.getState());
panel.add(checkbox);
panel.add(button);
checkbox.addItemListener(new ItemListener() {
public void itemStateChanged(final ItemEvent e) {
boolean state = checkbox.getState();
setUseCalibration(state);
button.setEnabled(state);
}
});
button.addActionListener(new ActionListener() {
public void actionPerformed(final ActionEvent e) {
imp.unlock();
IJ.run(imp, "Set Scale...", "");
imp.lock();
}
});
return panel;
}
The logic controlling the button is correct. I modified your sample code and it works as you described. (This is the version I used: http://pastebin.com/f6cd6cfac, tested on Sun Java 6).
But, there are some other methods that you call, but which you haven't shown us: setUseCalibration, imp.unlock, and IJ.run. Are you sure they are returning correctly? You should remove the external calls from code, and add them back in one at time until you find which one(s) is causing the problem.
I was pretty sure you're doing everything correctly, and my test bore this out. I removed the image reference and the action code, and the button behaves as intended.
I'm running JDK 6 from Sun on Ubuntu Linux. But that shouldn't make any difference.
I wonder if imp.lock() is doing something heinous. If this is the kind of lock associated with synchronization and concurrent processing, it looks intuitively wrong, because you're keeping the poor imp locked up for most of the program's lifetime. In any case, you could have a look at what happens when you comment out the action code.
I can't reproduce the problem either using Sun Java 6 on 64 bit OpenSuse 11.0. However, this doesn't mean that the code is correct. It just happens to work for me on my machine, OS and JRE today.
From your description it sounded like button.setEnabled(state) wasn't updating the appearance of the button, so I wondered if adding a button.repaint() directly after the call would make it work? This is more of an experiment than a solution, as even if it works it doesn't explain why your original code runs for me and not for you.
Either way I suspect one of:
Something in the way that the code is called.
Something in the library code.
A bug in the JRE (if it's a Sun JRE you can search the bugs
database).
A threading problem (make sure that the AWT code runs on the
EventDispatchThread and synchronize on mutable data members that are shared between threads).