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.
Using NB on a dual monitor system, if the size of the displays is different, moving the editor to the secondary monitor causes the scrolling in the editor to be completely garbled: essentially the "central" part of the view stays the same, and only the top/bottom lines sort of change (at least, one can see them partially scrolling). As such, the IDE is totally unusable. This issue is specific to 6.0 as I used all versions of NB since 4.1 and never had such a problem on a similar setup. (certainly, not from 5.1) Moving the window back to the first (primary) monitor fixes the issue.
Apparently a workaround is to make the wider monitor 'primary' When issue IS present: primary: 1280x1024 (editor works fine in this display) secondary: 1680x1050 (scroll is mangled) switching primary/secondary fixes the issue (NB starts in the 'primary' widescreen where it evidently reads the pixel sizes w x h and stores them for future reference) Note - doing the switch, messes up the startup, as NB for whatever reason opens up the window "out of bounds" - fix was to remove the .netbeans/6.0 folder and have NB re-create it
What JDK are you using ?
*** Issue 122325 has been marked as a duplicate of this issue. ***
and which OS? It seems to be JDK error, not NetBeans one. Could you create small Swing application with scrolling JEditorPanes in two jframes and verify if issue appears with this test app? Then we could submit JDK bug if my expectations are right.
i have successfully reproduced this issue on win xp, jdk1.5. if the primary screen has lower resolution than the secondary screen and netbeans is moved to the secondary screen, editor window has repaint problems when using its scrollbar. however this problem goes away with -Dsun.java2d.noddraw=true command-line switch (which is now default option in recent builds). scrolling in swingset demo in the same scenario seems to be fine. i suggest reassigning to editor guys for evaluation:)
OK, so workaround for reporter is either to add -Dsun.java2d.noddraw=true to netbeans.conf or to run on development build. Passing to editor guys as Standa recommended. The fact that SwingSet2 demo doesn't have problems means that our editor is somehow involved.
Well, if it's working with JDK6 or the noddraw=true switch then I think this is bordering WONTFIX category.
Removing the INCOMPLETE status, I guess there is no need for it anymore. Any progress in this? Should this be closed as WONTFIX then?
-Dsun.java2d.noddraw=true is now a default switch in netbeans etc config, i suggest closing this as WONTFIX
Closing the issue for now, please reopen if there is still some problem.