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.
Related
I need some help understanding a piece of code found in an application developed by my company. Because it is proprietary code I am not able to post the exact snippet but I will try to explain my problem.
The application is a java ee webapp, that has a listener implemented to catch a certain type of event. All normal so far...
Here's where it gets weird. The listener, after it catches the event it's looking for, triggers the same type of event from within itself, before finishing the rest of it's instructions.
It seems to be like calling a method from withing itself, only in this case it's a listener triggering the same event it is listening for.
It doesn't work, in this specific implementation, and that's a problem.
My question is: could this actually work?
I've tried to explain as best as I could but this is a strange piece of code. I tried to make a diagram of the way it is trying to work, maybe that will be more clear than my explanation. Image link below:
Please help me understand if what this person was trying to do is actually achievable or just very bad design.
Thanks in advance!
Sounds strange. It is normal for one event listener to "respond" by sending a separate event with the result - events are one way. Look carefully at the event identification, character for character, to ensure it really does send the same event it receives. Also, trying scrubbing out any company details and provide the code.
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!
I was using JFileChooser for browsing the files. I have selected the view as "details".In detail mode the files are listed under four columns ie. Name, size,Item Type, Date modified. When I modify a file which the JFileChooser is currently showing and then if I right click and select the refresh option, the "Date modified" field does not get updated with the new time.
But when I go back to one folder level up and come back, the "Date modified" field will be updated with the new time.
What is the resolution to this problem??? Is it a bug???
I am using NetBeans 8.0 & its swing GUI Builder.
Please Help.
Thanks
EDIT: I removed the old answer because it is not correct.
Explanation
You mention you're using a GUI builder from NetBeans. Without seeing the code that was generated, I can only speculate at what is happening. To speculate, I would say that yes, the GUI builder from NetBeans is at fault for this - but then you might be at fault as well, depending on your perspective.
A good rule of thumb is never shalt thou ever use a GUI builder, especially in Swing. Code generation is a non-trivial task to begin with, but Swing is far more complex than most frameworks, and it makes Swing code generation that much worse. Essentially, you can look at a Swing GUI builder as a terrible entry-level developer, who will do whatever he can just to get it to work - no matter how unmaintainable or terrible the code is. The problem with this, is when something goes wrong (like it has for you), then not only do you have to know Swing to know what to look for, and you have to debug code you've never looked at before and likely will spend a great deal of time to understand, but now you the code you are trying to debug is terribly written at that. You really need to manually create your GUIs.
That being said, as I continue to speculate at what your problem is because you have no code posted, I'm guessing you tried to manipulate what the JFileChooser looks like...is this correct? If not, I suggest updating your question.
If it is the case, then that is your problem. It may seem obvious to you that the JFileChooser you are looking at in your UI is the JFileChooser that contains all the JComponents and Objects in the code. This is very wrong, unfortunately (did I mention Swing was complex?).
The JComponents you are looking at are actually part of your FileChooserUI object. If I'm not mistaken, the default FileChooserUI for any OS is javax.swing.plaf.metal.MetalFileChooserUI (it's at least the default for my local testing, and I don't think I've ever seen different for any other time I've used a JFileChooser). For your reference, here is an unmodified MetalFileChooserUI:
Now, I mention all this because it sounds like you modified how the JFileChooser looks by dragging and dropping things around. Since all the JComponents are actually housed in the FileChooserUI and not in the JFileChooser itself, what you actually did was modify the FileChooserUI. By doing this, I'm willing to bet that NetBeans created a new subclass of MetalFileChooserUI (or whatever FileChooserUI you are using). The way you might install a new UI to a JComponent would be by calling ComponentUI#installUI. There seems to be a flaw with this though. I haven't been able to figure out exactly how this flaw becomes a problem for the refresh, but I have my guesses. Either way, I will explain how this is a problem in the general way.
Basically, when you call installUI, it will make the UI that you are actually physically seeing look the way you told it to. However, the ComponentUI object has a reference to itself stored within the JFileChooser class and when you install the new UI, that old reference is not overridden with your new UI object. There seems to be some interaction between your JFileChooser object and the ComponentUI object when you attempt to refresh, and I believe that it is still calling the old ComponentUI reference when it needs to do any kind of update.
Solutions
There are two solutions here.
Solution 1
The first is to set the look and feel to the ComponentUI object you want before you ever create the JFileChooser using the UIManager#put(java.lang.Object, java.lang.Object), where the first parameter is the name of the UI you want changed (in this case it's 'FileChooserUI' and the second parameter is the string representation of the full classpath to the ComponentUI object you want to use. Before I go any further, let me say that I have not been able to get this to work properly, and my look and feel never seems to get used. What you're supposed to be able to do is the following:
UIManager.put("FileChooserUI", "com.my.classpath.to.MyNewFileChooserUI");
new JFileChooser().showDialog(null, "FOO");
and the JFileChooser will show up using the look and feel in com.my.classpath.to.MyNewFileChooserUI. The way this works, is when an JComponent is created, it goes to the UIManager and asks what look and feel it should use, and then instantiates the class it finds. You can read more about that in the JComponent documentation. As I said though, I have never been able to get that to work.
Solution 2
The solution I have gotten to work, is to do something a little hacky. Objectively, I don't even like this solution, and if Solution 1 worked, I would say absolutely don't do this. Since I can't figure out solution 1, I will tell you the only thing I know to work:
JFileChooser fc = new JFileChooser();
MyCustomFileChooserUI fcUI = new MyCustomFileChooserUI();
try{
Method method = JComponent.class.getDeclaredMethod("setUI", javax.swing.plaf.ComponentUI.class);
method.setAccessible(true);
method.invoke(fc, fcUI);
} catch (Exception ex) { /*catch whatever you want and handle it however you want*/ }
fc.showDialog(null, "FOO");
What's happening here, is that I'm calling a function that is protected. This function will install your ComponentUI for you, and also override the old ComponentUI reference inside the object. So, when the JFileChooser wants to access the look and feel by reference, it will now make sure it accesses the correct look and feel Object. This is what I was speculating the issue was; it was accessing the old ComponentUI reference when trying to 'refresh' the JList inside of the look and feel that displays the files.
Disclaimer
There are some things I didn't talk about here, like how to override the ComponentUI object, because I think that's a little out of scope. Also, this is a long detailed answer about something that I'm speculating, because you provided very few details in your question. Another rule of thumb for you: the fewer details you provide in a question, the less people will want to help you, and the people that do will likely give you an answer you weren't looking for because they don't know what you want.
Call the following instead of updateUI to refresh the JList in the JFileChooser:
((javax.swing.plaf.basic.BasicDirectoryModel)list.getModel()).fireContentsChanged();
I am working in supporting/fixing the bugs for an existing product. The product is written completely in java and swing. Some times to debug the code I need to find out which method is getting executed when I click on a particular button or perform some operation. Is there any java utility that helps me in doing this. To attach to the debugger I need to know which method it is executing when I perform some operation. As the product is so huge
I can not predict the Classes etc based on the operation.
Run the code in a debugger such as the one built into Netbeans IDE. You can then step through your code - you insert the breakpoint at the start, or in the event handler for the button click, and proceed step-by-step from there. You don't ever have to hit the "continue" button if you don't want to.
In other words, no, you don't have to understand the whole calling pattern of the code to debug it - and that's one of the advantages of a debugger, it helps you see what the program is really getting up to.
Or you may "instrument" your code by inserting log/print statements as each method is called.
You can use a free code coverage tool like EMMA or jaCoCo which have their own eclipse plugin.
Code Coverage tools help you know which parts of your code are being executed while you launch a java application or unit test so I think is what you want.
For you to understand which method gets called when you click a button, you will need to do the following.
Consider the following sample code:
class MyPanel extends JPanel {
private JButton testButton;
MyPanel() {
testButton = new JButton("Test");
init();
}
private void init() {
testButton.addActionListener(new MyButtonListener());
}
}
Suppose you need to see the events attached with testButton, find its usages in the code to see what listeners are attached to it. In NetBeans and Eclipse, you can right-click on the variable and choose "Find usages" or similar action to see where all the object is being referenced.
Once you find the listeners, you will need to see what methods are being handled in the listener and if you mark a debug point in those methods, you can easily trace down the code execution flow.
I am working on a fairly complex Java application using Swing.
On some occasions there are unwanted beeps without any user intervention. No crash, application keeps working fine, I'm respecting the EDT rules etc.
Yet in some cases a beep can be heard: I may be doing something silly triggering that beep but in any case it s not a user action for it can happen upon importing data, when the user is away.
Is it possible, for a Java application that should never ever emit any sound to configure it, say by setting a property for the whole application that says: "dont' ever emit a beep"?
I ve been Googling for that issue and I ve found message by people having the same issue but no answer: all I found was some hack saying that there was a known issue with JEditorPane and that using a putProperty("IgnoreCharsetDirective", Boolean.TRUE) was helpful to make unwanted beeps happen less often. Yet information is very scarce on the subject.
It s a real issue because the application is used in an environment where the sound is needed on the computer, but this Java application emitting noise is unacceptable.
Your problem is discussed on the Java Forum:
// Write a custom toolkit
public class MyToolkit extends sun.awt.windows.WToolkit
{
public void beep() {
}
}
// Set this property
System.setProperty("awt.toolkit", "MyPackage.MyToolkit");
NOTE: The use of this workaround is discouraged. You should still try to find the root of the problem.
Edit: Removed a link, since the thread on Java Forum is now offline.
In Swing you need to override the LookAndFeel as follows:
UIManager.setLookAndFeel(new NimbusLookAndFeel() {
#Override
public void provideErrorFeedback(Component component) {
// Your beep decision goes here
// You want error feedback
super.provideErrorFeedback(component);
}
});
Typically your beep decision would reference some kind of external configuration/preferences flag for your application.