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.
When my editor (or output) window is on my second monitor (I have a docked laptop with a stand-alone monitor as an extended desktop), I often get a strange scrolling problem: When scrolling (with either the mouse wheel or arrow keys), the screen only updates the 1st and last lines of text; everything in between remains frozen. The middle portion seems "alive" in that clicking on errors after a compile opens up the code on the editor pane. However, the links aren't lined up with the links visible, so it appears that I am actually clicking on a link below the visible screen. Set up: Windows XP, 5.0 RC2, Dell Latitude D600 and NEC MultiSync FE950 (2nd monitor).
Could you reproduce this problem with just one monitor? WHat JDK version are you using?
Comments from reporter: --------------------- It seems to happen only on the second monitor and only in SDI mode. I have discovered that if I change the resolution of the second monitor while Netbeans is open, the problem goes away for the entire session. However, it returns the next time I load Netbeans. I have attached a picture of the info from my Netbeans help -> about screen. BTW, is there no way to select and copy the text from that page anymore? I seem to recall doing that in previous versions, but that could just be short circuiting in my brain. Thanks for the help. JDK 1.5.0_06 -----------------------------
IMO you've hit a variant of JDK problem http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6331073 (fixed in Mustang - J2SE 6.0) There are certain workarounds listed in the JDK issue that you might try. I'm confident that this is a JDK issue because what you see is part of the behavior of the (JScrollPane's default) blit scrolling i.e. the image is scrolled by moving image's bytes in the offscreen buffer and just the remaining part is rendered in a usual way. For some reason moving of the bytes in the offscreen image is not performed which causes the behavior that you observe.