This is driving me crazy. When I set an appropriate size for my window in design-mode it just ignores this size and uses something else when I compile and run. Even tough I set the minimumSize and preferredSize it just ignores this... Why? How can I set my own size?
Even if you've set the size with minimumSize and preferredSize, you might have forgotten to call Window.pack() in which Swing will resize the components (and all of it's subcomponents) according to the sizes set.
You call it in your window (or whatever is building your window) after all the preferred sizes are set.
Alternatively you can use the Component.setSize() method but it comes with some caveats.
Have you checked if you really set the size of the JFrame or of a contained JPanel?
Have you tried setSize?
I've found myself in a similar situation while using netbeans ide. I had a read of the following thread, that helped:
http://forums.netbeans.org/ptopic28011.html
Seems as though the swing application framework is saving the app's window size in a subfolder within your home dir (for Windows, the "Application Data" folder, for Linux, in your "~/" home folder).
For example, for my application 'CrapApp', swing had saved some last-window-size info into the sub-folder "~/.CrapApp/", into a file called "mainFrame.session.xml".
So no matter how I re-sized the window within the designer, upon running, it seemed to have ignored it and instead loaded the window size from the preferences within this sub-folder.
So my solution was to delete this preserved-settings sub-folder, eg, in my case, "rm -rf ~/.CrapApp/"
Then the problem went away and I could re-size within the designer and run the app with this re-sized window now visible.
This made me want to learn what triggered this issue. I noticed that simply running the app within the netbeans ide and closing it didn't generate the sub-folder.
After a bit of tinkering with my app, I noticed the following action triggered the generation of this "~/.CrapApp/" sub-folder.
Going to my app's "Help >> About"
Click the "Close" button in the about dialog that appears
Exit the app
And now the "~/.CrapApp/" sub-folder re-appears. This help/about dialog was auto-generated by netbeans ide, so I didn't really tinker with it, but this seems to have been the culprit in my case.
Perhaps it may be a bug in the netbeans ide, I'm using a somewhat old version (v6.8), which seems roughly from the era of your original post too.
Related
I am trying to add keyboard shortcuts to an existing Java app. The relevant part is as follows:
public final class Main{
...
private MyKeyEventDispatcher keyDispatcher; /*implements KeyEventDispatcher*/
...
KeyboardFocusManager manager =KeyboardFocusManager.getCurrentKeyboardFocusManager();
keyDispatcher = new MyKeyEventDispatcher(this);
manager.addKeyEventDispatcher(keyDispatcher);
viewer = makeJViewer(); /*an extension of JPanel, which shows a video stream.*/
...
}
Now, the keyboard focus system works as one would expect with the software rendering. However, since the addition of GL rendering support, the behaviour is different. Upon starting the program, keyboard manager works fine. child objest of Main have the focus and the focus manager behaves as defined in Main. When I click on the stream-video button however, ie. when internal JPanels inside Jviewer are rendererred for the first time, although the same buttons and Panels keep the focus, the keyboard manager suddenly stop working. I will have to click on the Jviewer or the gui tools such as buttons, etc. or Tab-out and then tab-in the program for the keyboard to work again. After that, it works fine. Also, this only happens the first time a stream is loaded.
I should also say that this behaviour only occurs with my windows machine and the linux machine handles the same (maven) build just fine. What is interesting, is that if I run the same program in the IntelliJ build environment with JDK java 1.6.0.39, it also works fine in windows.
My questions are:
What is causing the problem? Is the Jviewer somehow not "revalidated" after the rendering of those internal stream JPanels?
Why does the same build work in Windows and not in linux? Something to do with LookAndFeel?
On Windows, Why does the IntelliJ build work fine and the Maven build doesn't? They do seem to have different set of paths for looking up libraries, etc.
How does the focus subsystem decide on the KeyboardFocusManager to use? Is there anything like: getCurrentKeyboardFocusManager().isItBlank() or any way of checking its content programmatically?
Unfortunately the project is fairly modular and I can't define the action for the keyboard shortcuts in my "swing package" as my "Main" package imports "Swing" and Java doesn't like circular dependency; if it wasn't I could define keyboard manager for each child object, including Jviewer individually, but I can't! Is there a property to set so that all the Components in a given window would use the same KeyboardFocusManager?
FYI, Maven version: 3.2.5 and uses same Java JDK as my IDE.
The focus manager issue can be resolved by clearing the global focus owner:
KeyboardFocusManager.getCurrentKeyboardFocusManager().clearGlobalFocusOwner();
I recently tried to open a JPanel form that I created with NetBeans GUI Builder and NetBeans almost freezes up on me. The design form is an all-gray background, not the usual gray area where I can place components surrounded by a white background. If I click on the Source button and then switch back to Design view, all of the tabs in the editor pane disappear.
Fortunately I am using Git for version control. The last commit of this file was over a week ago. I might have to revert to an earlier version to see where this problem was introduced. In the mean time, does anyone have any idea what could cause this behavior? Is it possible that my .form file is corrupted? The application compiles and runs just fine.
It sounds like Netbeans can't load the form due to some internal error. This can sometimes be fixed by doing a clean & build to clear out any old cached data.
If that doesn't work, you can check out the "message.log" for the error...and yes, I wish it would display it on the screen
Off memory it use to be in "{user.profile}/.Netbeans/{version}/var/log" (I think). It got moved on Windows under 7.2 to "{user.profile}\AppData\Roaming\NetBeans\7.2\var\log"
I use ubuntu 10.04, but have discovered this on other ubuntu distributions as well.
When I start the first JFrame of an application, it won't start in its default size (specified by setSize()), but instead is maximized all over the screen.
I have one workaround for this, which is to use setResizable(false) (which brings the
window to its intended size), then I set it back to true (I still want to be able to resize).
Anybody knows where this bug is from? Is there any elegant way to deal with this?
Thanks,
It is a window manager preference. Either disable it in ubuntu or modify your program live with users wanting to resize your program.
To disable (from ubuntu forum post):
Open System->Preferences->Startup-Apps
Find the entry for 'Maximus' and uncheck it
Logout/login
We have a Java Applet built using AWT. This applet lets you select pictures from your hard drive and upload them to a server. The applet includes a scrollable list of pictures, which works fine in Windows, Linux and Mac OS X 10.5. We launch this applet via Java Web Start or within a web page.
Our applet does not behave properly in Mac OS X 10.4, regardless of the version of Java (1.4 or 1.5). You can find a screenshot of the incorrect behaviour, when scrolling, here:
http://www.lavablast.com/tmp/ui_error.png
Simply put, sometimes when scrolling the pictures end up overlapping the header or footer of the application. This behaviour does not occur on other platforms. On Mac OS X 10.4, it shows the pictures in the incorrect location when scrolling, which would not be so bad if it refreshed the screen after painting the image at that location. However, it does not appear that the application knows it painted it incorrectly and thus does not refresh.
If the window is minimized, resized or even moved, the application is refreshed and the incorrectly positioned elements vanish and the application resumes normally. I spent quite some time trying to force a refresh of the background image unsuccessfully. (the repaint the image directly, repaint all children of a few panels, etc. ) Thus, I am looking for any tips that would help me resolve this problem under Mac OS X 10.4 or, in the worst case, simply simulate a full applet refresh.
Until recently, everything was compatible with Java 1.1 but this has changed in a few locations which now require 1.4. I don't feel these changes created the issue, I am just providing this as extra information. If you are interested in implementation details of the scroll panel, I will investigate, but I am assuming this is a common platform bug for which workarounds must be known.
To replicate the problem, open the following Java Web Start application:
http://www.lavablast.com/tmp/opal-webstart.php.jnlp
Select a folder containing lots of images and play with the scrollbar. At some point (fairly quickly), you should get the refresh problem.
Edit: I followed the first suggestion here and replaced all my controls that feature background images with a Swing equivalent and the issue is still there. (Plus, there are numerous other fixes I would need to do to do a complete change). Any other ideas? A simple one line of code that forces a full refresh would be great :)
Edit2: The main thread creates the panels and launches X threads. Using an observer/notifier pattern, the threads complete and notify the main control, which adds a panel to the page. This is done via an EventQueue.invokeLater which, unless I am mistaken, should run on the right thread. The issue is at its most severe when scrolling even if no extra threads are running (as during the loading).
It does look like mixing lightweight (usually Swing) and heavyweight (AWT) components together. Moving to Swing you need to replace every last AWT component Swing equivalents (hint: avoid import java.awt.*).
Threading is often a potential problem for odd bugs. Swing components must always be used on the EDT (use java.awt.EventQueue.invokeLater). AWT is thread-safe is theory, but not in practice - also restrict usage to the EDT.
As you already require Java 1.4 you should consider some small changes to take into use SWING GUI instead, it solved our Applet refresh issues with AWT. (Mac, Linux etc)
If you have e.g. Panel, you need to replace it with JPanel etc.
You need this:
import javax.swing.*;
I want to create a hangman game as an applet, so I have some labels and buttons that will be initialized by the generated code of the gui designer but I also have some labels I create on my own, after knowing how long my word is. Therefore I use absolute layout for my applet.
In netbeans my applet works finde when I run it but when I try to run it in the browser (I tried Firefox and IE) nothing is on the display, the applet is empty.
can someone help me with that?
Here you can find the source if it is helpful
http://root.xelluloid.de/Hedgeman/Hedgeman.java
With kind regards
Sebastian
Did you look at the Java console for the browser? It likely contains something that says that the program crashed because it could not find the AbsoluteLayout class.
This is for an older version of NetBeans, but the same should apply: http://forums.sun.com/thread.jspa?threadID=597783
I just had the same trouble with an applet and AbsoluteLayout and netbeans 7.1.
Everything works fine but errors are thrown when the applet runs from a browser.
I solved this by switching, in the form designer, from AbsoluteLayout to "Free Design" (which seems to default to GroupLayout in the code that is actually generated) but offers similar functionality (widgets can be placed without restrictions, borders, or even on top of others).
You could probably include the AbsoluteLayout Class/jar into your project and continue using this code. But in my case the code can't exceed 32KB and needs to be self contained (single file) as it needs to be uploaded to a small embedded device.