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();
Related
I am currently completely stuck with the following problem: I want an GUI with a cotrol panel at the right to type in some program parameters that should be used to draw multiple lines onto a graphic panel at the left side of my GUI. My approach was to use the Form Designer to arrange the Layout with all the Buttons, Lables and TextFields. Than I created a Class "GraphicPanel" that extends JPanel and I overrided the PaintComponent method of this class in order to draw the lines.
Now I want to add this custom created component via the form Designer to my UI. But when I try this via the Non-Palette-Component option: nothing happens and the component is not even shown in the hierarchy-tree. I have already serached the web for solutions and found that my class needs to be compiled and the ReloadCustomComponents-Button must be clicked after inserting custom stuff. My class is compiled but the ReloadCustomComponents-Button is not shown up in the UI-Designer Toolbar. I tried to configure the toolbar manually - and in the configuration setup Intellij is also listing the Button as a displayed icon - but it is not there when I apply the configuration. Did anyone had the same problem or does anyone have any suggestions what I can try or what else I can check out? I am actually wondering if this is a software bug or whether I missed something different. I am quite a beginner and especially working with UI's and Swing is new for me so I have no real idea how to go on with this. Thanks for any help!
(I am using Intellij Idea 2020.3.1 on Windows and JDK 15.0.1 and my output format for the UI-form code is set to binary class files)
UI component classes used in the UI Designer palette must be compiled for the same or lower Java target version as is used to run IntelliJ IDEA. IDE JDK version is available in Help | About dialog and is 11 for 2020.x IDE versions.
Change the target JDK version to 11 so that IDE can load the component classes. See this answer for the relevant places where JDK language levels are configured.
Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.
The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
I have a web application (struts 1.3, Weblogic 10.3.0, Toplink, Oracle) that has a Java applet which isn’t working in the browser (IE7/8) when the Next-Generation Plug-in setting is enabled in the Java control panel but works fine when it’s disabled. The trouble is that this setting is set to disappear in an upcoming Java release meaning that my users would have to keep using Java 1.6_xx on their workstations as they are currently. I have little influence over which version they use because they are all governed by their local IT departments across the country. So, either I have to find a simple fix to allow the Next-Generation setting to work, or we have to look at replacing/rewriting the applet with something else (but would be a last resort due to funding constraints), most likely something AJAX-friendly so as to avoid the need for a plugin. This application is quite old, written around 2001 before AJAX was really around.
The main window has a left, right, and top frame (JSP’s), as well as a center frame which is where the applet is. The applet has a main content area in the middle and a lower panel at the bottom which has some buttons. The buttons tell the content area (which is basically a treegrid) what to do (Save, Copy, change status, etc ). When I press one of the buttons the entire window (surrounding frames plus the applet itself) repeat inside the area where the applet is. It’s like a kaleidoscope or like a repeating fractal pattern kind of thing, or like when you take a picture of yourself in the mirror and you see the room repeated over and over in the mirror. In this case it repeats for each button press and the repeated set gets smaller each time. Weird!!
So, based on my research, the Java Next-Generation plugin works differently by allowing more than one process or thread whereas the classic plugin only uses a single thread. So my suspicion is that a new process is being spawned for each button press. I tried using the “separate_jvm” applet parameter but it made no difference whether it was set to true or false. I don’t see any other applet parameters which seem to be relevant.
Another idea I had is that maybe it’s something to do with the JSP frameset, maybe something like “target=_top” needs to be added somewhere…but I’m not sure how this relates to applet threads if at all.
Anyone have any suggestions, ideas or experiences that might help?
you can use velocity to handle these type of problem and it will also help you for future enhancement also.
The problem is not related to version of IE but rather to version of Java. Below excerpt from letter of certificate provider (they took it from some forum, so direct link to source cannot be provided):
For JDK version higher than 1.6.0 and below 1.6_15, you can just
clear all kinds of cache in web browser, java console and java control
panel. Then it should works fine!
For JDK version between 1.6_15 and 1.6_30, you should disable the "next-generation java" option in java control panel.
For JDK version higher than 1.6_30, you should turn on "next-generation java" option in java control panel.
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"
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.