Introduction
I’m attempting to switch my application from windowed to fullscreen. Earlier this would have been as easy as making use of LibGDX’s setDisplayMode(Display), as well as the same library’s getDesktopDisplayMode(). Unfortunately, some things have changed.
Research
As of LibGDX 1.8.0—inside the Graphics—what was previously known as setDisplayMode(DisplayMode) has been renamed to setFullScreenMode(DisplayMode), as well as what was previously known as getDesktopDisplayMode() has been renamed to getDisplayMode().
By then, one might think, that using the renamed methods in the same way as one previously would to switch from windowed to fullscreen would work just as fine:
// Tabulator key triggers change from windowed to fullscreen
// The application works fine until that of pressing the tabulator key
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
This doesn’t work fine by any means. As a matter of fact, the application hangs followed by crashing upon pressing the tabulator key.
It’s worth to notice that the setFullscreenMode(Display)—according to the documentation—returns a boolean depending on whether or not the operation was successful. In this case, if you were to put it inside a print statement, you can clearly tell it never returns: even should you let the application be for a while.
Moreover
I took a good look around the web—in vain—searching for possible causes of as to why this might be happening. Looking at the release notes of 1.8.0, it truly seems as though all that needs be done is switch from using the previous methods contained by the library to the new ones.
Question
Does anyone have any insight on as to why the application crashes upon pressing the tabulator key—granted the code following it as shown above is present? Perhas someone could at the very least point me in the right direction?
There’s a fair chance what I’ve concluded is missing out on some important facts.
Solution
It turns out I’ve managed to be slightly silly!
Background
Whenever I create applications—especially games—even though I use libraries such as LibGDX, I like to go ahead and create myself a separate thread for handling the game logic. This yields me more control over the application as a whole—whether it be tick extremely frequently whilst rendering more seldom, or the other way around.
By the way of my logic, the provided code from the question...
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
... I decided to put inside the tick method. Since that’s inside a separate thread, LibGDX probably felt a little left out.
Moreover
From my understanding, LibGDX handles all its logic inside the ApplicationAdapter’s render method. That’s where it evaluates all of the user’s actions and makes sure they don’t collide with other things taking place to its own various different components.
For the aforementioned reasons—when I decided to put the “fullscreen logic” inside a separate thread, LibGDX crashed. Oh well, at least it works now—That is, by putting the aforementioned code inside the LibGDX’s ApplicationHandler’s render method!
Related
I have a Java application and basically I want to know all the methods that are called in the background when I do something in the GUI. I know you can view the Call Hierarchy by selecting a method but that's while the code isn't running. I want to view every single method called in every class when I select something for example so I can figure out which methods/classes/packages are responsible for this functionality. I also don't want to have to set a breakpoint at the start of every method as there are far too many methods/classes/packages for that to be feasible. Bear in mind that I don't even know the first method called for some of the operations, if I knew that, it'd be easy to figure out what's going on.
Is there a way to do this or am I ahead of my time?
I think you could use the debug mode to see all methods called
Run DEBUG in your IDE, your each step in application will move you to the right place in the code, during your program you can see each variable value.
Also you can follow each code line which your code is doing.
http://www.vogella.com/tutorials/EclipseDebugging/article.html
Regards!
I'm really no debugging expert and lately I came across a problem which hopefully has an easy solution. When I test and debug the Mathematica plugin for IDEA, I write some code, build it and run it in a sandbox IDEA.
For those who are not familiar with writing plugins for IDEA: The main problem is, that all the UI code is already there because it comes with IDEA. My plugin only implements specific interfaces which are required to make IDEA understand the Mathematica language. Therefore, setting a breakpoint or throwing something in an onClickListener like suggested by #Jeroen is not possible, because I virtually haven't written any single line of UI code*.
Now I had the situation that everything works fine, but when I cancel a specific action, something weird happens. I have no idea which specific method (it is none of mine!) is called at the moment when I press Esc to cancel this action. The current point is very likely deep inside the sources of IDEA which I have and which I can navigate with the debugger!.
Question: What is the easiest way in Java to make the debugger break, wherever it might be when I press Esc in the UI-program I currently debug?
*This is not entirely true, but for the sake of a general solution I would like to think of it that way.
As discussed in this question, you can create your own subclass of EventQueue which inspects events, and create a place in the code where you can set your break point and only catch certain kinds of events. It might look something like this:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new EventQueue(){
public void postEvent(AWTEvent theEvent) {
if(theEvent instanceof KeyEvent){
KeyEvent kEvent = (KeyEvent)theEvent;
if(kEvent.getKeyCode() == KeyEvent.VK_ESCAPE){
System.out.println("escape pressed, set breakpoint here");
}
}
super.postEvent(theEvent);
}
});
Then when you hit that breakpoint, you can step into the super.postEvent() call and see where it goes, which component(s) receive it, and when they begin to interact with some part of your code. Be forewarned that it may be a long slog, though -- AWT/Swing event dispatching can get pretty complex.
If you are working in (or can port to) Netbeans you can use their visual debugger which is specifically designed for these GUI-centric issues. It can direct you to specific source code when you interact with a GUI element, so it should be able to point you to the mystery code that is run when you click escape. I believe that other IDEs have similar features, but Netbeans is the only one I know of off the top of my head.
I have a strange behaviour with a legacy application I have to maintain. On startup, the JFrame of the application is moved to the position where it has been closed recently (which works fine, even on multi monitor settings).
When the JFrame is moved to a secondary monitor (done by calling setLocation(x, y)) and a JDialog is shown after calling setRelativeTo(mainFrame), the JDialog appears on the primary monitor.
One has to drag the mainframe on the primary monitor and back to the secondary one to avoid the problem.
I have found, that calling mainFrame.getGraphicsConfiguration().getDevice().getIDstring() returns \Display0 when the application is started (means 'Primary Display' afaik), even though it is shown on the secondary monitor. When I drag the main frame to the primary monitor and back to the secondary one, the Method returns \Display1.
Now I have 2 questions:
Is there a way to tell the application on which monitor it is positioned?
I have tried to create a simple example with JFrame and a JDialog. Unfortunately it behaves as expected and I can't reproduce the problem. Do you have a hint on what to look for in my application, that could cause this behaviour?
Thank you very much
klib
After some more research I found that I had to call mainframe.setVisible(false);and again mainframe.setvisible(true);.
This is sufficient that mainframe.getGuiConfiguration.getDevice() returned the right device-ID.
I know, this is not really a solution to the original problem, but it might help if someone else experiences the same behaviour.
Anyway, Explanations / real solutions for the problem are still very appreciated.
For your first question, you could use JFrame(GraphicsConfiguration).
If the problem isn't repeatable, there might be something else going on that is messing things up
I'm trying to have several gamepad at the same time in JInput, while also checking for newly plugged gamepad. Here is the code used to check for new controllers.
new DirectAndRawInputEnvironmentPlugin().getControllers();
If I run this code several time and store the results, the same peripheric appear on a different "Controller" instance amongst the results. Which lead to a lot of problems.
How do I check if two instance of Controller are similar ? IE if they control the same peripheric ?
I guess it could work if I checked for the name/number of components/rumblers, etc to see if they are similar (like hashing the device). But what if I plug the same gamepad twice ?
Thanks !
Currently you can't do this with JInput. Ideally you would be using the DefaultEnvironmentPlugin too, which will auto detect for the platform you are running on.
There is an interface in JInput for controller connection/disconnection, but it's never been implemented. I've asked a number of times for volunteers, but nobody seems to worry about it enough to do it. Feel free to contact us over on the javagaming.org forum if you wish to implement the notification interface.
I am attempting to setup a reset method within a program that essentially creates a replacement of itself and then closes itself down leaving the replacement running. I know that normally to do this I could use some outside driver class and have no issue, but I am seeing if it is possible to create a completely independent instance of a class with itself.
If I create a new instance and then exit the existing instance, the newly created instance exits as well. I would imagine that this is possible but I can not find any way to go about it at this point.
The particular program I am working on is a Swing GUI and I have set the default close operation to EXIT_ON_CLOSE.
The reason that I wish to do this is that it would be more simple to just replace the current window with a new one than it would be to go all the way through and reset everything back to default.
Also on a purely theoretical note I would like to find out i this is possible.
Quick Solution: don't use EXIT_ON_CLOSE as your default window close option. Check the API and choose a better one such as JFrame.DISPOSE_ON_CLOSE.
You state:
The reason that I wish to do this is that it would be more simple to just replace the current window with a new one than it would be to go all the way through and reset everything back to default.
Which leads to a longer potential discussion: you probably don't want to do this, to exit one window and pop up another. Besides being annoying, there are probably much better ways to achieve this end. For one, your GUI should be based on a model, and resetting the model should be fairly easy if it is well written. If not, then consider refactoring it so it is easy. We can help you with this.