This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build 201301300001 Copied from bug 10622: "I'm in application which I'm debugging. When I cause an action which reaches the breakpoint in my code I think the IDE should get the focus. Otherwise when you reach the breakpoint your application froze and you might have "no idea" what happened (especially when your application is maximized)." BTW it should be the editor not some other debugger window.
Product Version: NetBeans IDE 7.3 (Build 201302062200) Java: 1.7.0_11; Java HotSpot(TM) Client VM 23.6-b04 Runtime: Java(TM) SE Runtime Environment 1.7.0_11-b21 System: Linux version 3.0.0-12-generic running on i386; UTF-8; cs_CZ (nb) User directory: /home/cesilko/.netbeans/7.3 Cache directory: /home/cesilko/.cache/netbeans/7.3 Works fine for me. I opened AnagramGame sample project, put a line 185 breakpoint in StaticWordLibrary.java and started debugger. I switched focus to Debugging view in NetBeans. I maximized Anagrams application window and then pushed Guess button. NetBeans started to blink and when I switched to it Editor had focus and cursor was blinking at line 185.
If I debug the Anagram Game in full screen mode and the debugger hits a breakpoint then NetBeans remains behind the game screen. That is because NetBeans really does not steal the focus as it should. Perhaps because of my task bar settings: - "Lock the taskbar" unchecked - "Auto-hide the taskbar" checked - Keep the taskbar on top of other windows" unchecked As a debugger, perhaps unlike other applications, NetBeans really must steal the focus because there is absolutely no point in doing anything with the application being debugged at this time. For example one can easily start multiple (unwanted) threads in a browser window if one keeps clicking a button after the debugger has hit a breakpoint. As you wrote, you switched to the IDE manually. This is about letting the IDE do it automatically.
I see. Then this is probably a duplicate of issue #170976. The word "Editor" in the bug's description confused me. *** This bug has been marked as a duplicate of bug 170976 ***
Thanks. Apparently Windows innovation :). I have quite a few debugger issues that I can reproduce easily while others have seen them only randomly like disappearing breakpoint annotations bug 226219, out of sync breakpoints bug 225311, bug 184933, bug 176797, duplicate breakpoints bug 195613, 210501. I see all of them most of the time. Debugging is a really bad experience for me. I would think there is some value in being able to reproduce at least some issues all the time. How can I help? Are there any plans to improve the overall situation? Instrumentation? Thanks.
We have really problems to reproduce such issues. It would help a lot, if you can isolate such erroneous behavior in some test project and provide steps to reproduce. One additional question, that came to my mind: Do you use project groups? Do you switch between several project groups? Do you have two or more projects with identical package and class structure (like different versions of the same sources)?
In the next NetCAT program you should join Debugger Tribe. It would be beneficial for everyone. Martine, maybe you could add some extra logging, build the responsible debugger modules specially for bht and wait for his log file(s).
I have not used project groups. Multiple versions of the same class structure have been involved, but this is not where the errors have occurred. I am aware of that issue so I am avoiding to debug projects that have identical class structures. But I will watch this. Good to be aware of this. I would be keen to produce test cases which I always do if I see a chance of success. However I cannot see one at the horizon yet. Therefore I am hoping that you might be able to provide instrumentation via logging etc. However, I will keep watching and trying. My usage pattern in the last case where I encountered all of these issues is as as follows: Web project with 1000 classes, debugger connected to GlassFish. The IDE session is already 10 hours old, and the IDE has slowed down because of this. Memory is at 250 to 350 out of 400 which indicates to me that there is some slow resource leak. I have a framework bug in my main ant web project and I try to reproduce it with a small Maven test case (different class structure). I fail to reproduce this. My next approach is to make a copy of the main project and close the original project. Big frustration because NetBeans scans the copy while it copies it. Next is an iteration: 1) Debug the project to see whether the bug still exists 2) Delete some files which breaks the project 3) fix the project until it becomes runnable 4) go to 1 This is chaos. So after a number of iterations, perhaps 10 I have a test case for that framework bug (not NetBeans). But during this process which has taken up to 10 hours, Netbeans really shows its limits. In the past, I have filed other NetBeans bugs that occurred with this process. They are fixed now. Only the debugger bugs are left. A likely compounding factor is that my PC is extremely slow while memory is not an issue. I just keep the PC because I think it helps find NetBeans bugs more easily. As an example, I was able to reproduce bug 206513. You solved it via logging at my end. I can also do things like bug 224184. The interesting part is that multi-threaded I/O translates into CPU starvation - more cache available than the CPU can handle. So the CPU cannot breathe because it is not waiting for disk activity. Windows XP 32 bit, 3GB of RAM, fast IDE hard drive, CPU http://www.cpubenchmark.net/cpu.php?cpu=AMD+Athlon+XP+1800%2B&id=221 So if I had a test project, then you would not necessarily be able to reproduce the errors on a fast PC. But perhaps it could help if you could fix bug 225418 while I am still trying because I am seeing in the log multiple normalizeFile() warnings for the same file in succession - as I said, multi-threaded I/O kills NetBeans performance.