I am trying to Embed a Game Window inside Java JFrame using SetParent. I am using the following kind of Code using Java JNA User32 library.
SetParent(GameWin,JFrameWin);
SetWindowPosF(GameWin,null,Game_X_pos ,Game_Y_pos+1,0,0,0x0020 | 0x0001 | 0x0008);
The above code is working fine and my game window is becoming a part of the JFrame successfully.
But the controls kept in my JFrame like Drop down list and Buttons heavily slow down after doing this process.
Whenever I am clicking any button or dropdown list in my JFrame, it is responding after a lot of time something like after 1 or 2 minutes.
If I don't Embed my game window inside JFrame then everything works fine as usual.
When you make a window from one process be parented by a window of another process you are attaching the message queues of those windows.
The game window likely has a message loop that is quite different from a normal GUI app. Almost certainly this game is not very interested in dispatching your window's queued messages in a timely fashion. The game did not expect to be hijacked in this way.
There's probably not much that you can do to ameliorate this situation. Cross process parenting is something that basically should not be done. More reading on the subject here: http://blogs.msdn.com/b/oldnewthing/archive/2013/04/12/10410454.aspx
Related
I am curious about how Java actually goes about creating a JFrame in swing; how does a window magically pop up? So, I went ahead and looked at the source code for the JFrame and ended up at the source code for the Window class.
In the Window class, there’s so much going on I can’t tell what hints at the initialization of a displayed window. I am a beginner, and even if it’s really high level stuff, I still want to be to see the actual code for making a window.
Maybe I’m looking at the wrong stuff. If someone could point me in the right direction or provide links, that would be great.
EDIT:
If anyone is confused by what I’m trying to ask, say you were to create a window just like a JFrame but from scratch, how would it be done? How is it done in swing?
Window (or more formally java.awt.Window) is a Java API to the platform native toolkit window. All modern OSes (that support display anyway) come with a toolkit.
JFrame and Swing were a secondary attempt at providing a user interface (UI) toolkit in Java that would look and work the same way over multiple OSes. The classes in java.awt like Frame and Dialog were the first attempt, but they had native peer classes (see java.awt.peer - compiled C/C++ code), and rendered and performed very differently across different OSes.
So what is going on under the hood is that JFrame is first creating the most basic window possible from the OS toolkit, and then dressing it up (adding menu bars, scroll bars, etc) to be a JFrame or a JDialog within the swing Java classes themselves.
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'm new here and not so much familiar with applets.
I searched the site and many other forums for answer but i found nothing.
I have made an application in Java which starts with an applet login form, and continues with JFrame subforms which are doing several things like running JOptionPanes for example when a customer make a change in his profile.
My problem is that when the JOptionPane appears, the applet start form comes on top even if i have opened 2 or 3 JFrames.
I forgot to say that my app is big so i cannot post any code (and i think is not needed).
Thanks in advance!
Avoid mixing frames and applets, your working with competing paradigms. If you MUST use an applet, use something like a CardLayout or JTabbedPane to allow the user to switch between forms.
If you can, try using Java Web Start, which will allow you to start your application off the web, but have the same restrictions as that of any embedded GUI.
As to your problem, it sends like you are mixing the native peer for the JOptionPane. Make sure that the parent reference is correct (ie references the frame or child of the frame)
I've just started making my first GUI application in Java and I decided to use the NetBeans IDE to do it. I think its working fine so far, except for one problem; it seems to be slow updating the content of a window.
Even in very simple windows with few controls I find that when - for example - closing or resizing a window, I get the normal window border working properly but the inside is completely see through for a second.
It's not the biggest deal in the world, I just find it mildly annoying.
EDIT: I've tried the HelloWorldSwing from the official Java tutorial but I have the same issue, only now, when resizing, instead of being transparent, the new area of the window is black until the contents updates.
You should ensure that all of your GUI updates are performed in the Event Dispatch Thread, and that any other long running tasks are performed in worker threads. If you have long running tasks running in the EDT, your GUI will feel sluggish. Take a look at this tutorial for concepts on Swing Threading.
In the absence of any technical problems with your app, this could simply be JVM warmup effects. Do updates speed up if you resize the window a few times?
This could be a Java2D hardware accelleration issue. Is your 3D graphics card driver fully updated?
I'm trying to create a java desktop application that holds desktop icons. The app will be a menu/panel that is invisible until you hover your cursor near the top of the screen, at which point the menu full of desktop icons will drop down. To add new icons to the menu one must simply drag icons from the desktop into the menu and they should snap to grid. As I am an intermediate level programmer but I havn't ever done a GUI app before in any language, I was wondering if someone could help me out, both with how to approach the problem and on the packages and methods I should be using. Also, I'm thinking of doing this with NetBeans unless you have any other suggestions.
Thanks,
Andrew
As an alternative to Chad's option, you could also do this by creating a frame and using Java's transparent window capability to make the frame transparent (or translucent, if you want a hint that it's there), and using mouse entered/exited events to return the frame to its normal "solid" opacity.
Personally I'd try this solution just because I'd rather use event-based notification than polling the mouse position, but I expect it's more work than the other alternative.
As to drag and drop, I haven't used it extensively enough in Java to give any solutions, but it's not immediately obvious (from a cursory internet search) of how to handle native desktop drag and drops. I'd suggest starting with some dnd tutorials within an application so that you really understand Java's drag and drop API and capabilities.
You can use java.awt.MouseInfo to get the location of the mouse at any point in time, even if you don't have any windows open.
So, you could start a java program, then in your main loop poll the mouse location. If it's in the 'top', then you can open a window.
You can use the easiest thing to do would be to use JButtons or JLabels with images to represent the desktop icons. Just load the image you want to use and stick that on as a label.
I'd start by going through swing tutorial and writing a few simple GUI programs to get the hang of it.
But the MouseInfo thing is what you need to tell when the mouse is at the top of the screen.