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.
NetBeans IDE 200408081800 on java 1.4.2_05 1, Create simple class, where part of code is executed repeatedly and set breakpoint on the repeated code 2, Run this code in debugger 3, Invoke Continue several times, till output window (debugger console) is full of messagesa about reached breakpoint 4, Invoke Continue again => the message is written on invisible part of output and scrollbar is updated only. I would prefer to scroll the output automatically to make the last line visible. Output behaves like this, when brekapoint is modified not to suspend debugging.
AFAIK we can't control scrolling in output window, assigning to core for evaluation.
Updating the output runs on a timer; also, the timer will only know there is some new output if a \n is part of the output. Easy fix: Call OutputWriter.flush - this will generate an event that forces it to refresh, even if some output is only partially written.
But /n is part of output. We are printing whole lines. Flushing does not help! Just try: public class Test { public static void main(String[] args) { int i, k = 10000; for (i = 0; i < k; i++) System.out.println("print " + i); //breakpoint here and continue, continue.... } } Output from ant ("Test (debug)") works, but output from debugger ("Test"_ not.
The commit message, which says it all: #47030 - debugger output on breakpoint doesn't scroll. More hacks. We really need an API for this, ala boolean OutputListener.iAmWorthyOfAttention(). In the meantime, more hardcoded strings. Which is the case. The output window will stop scrolling on the first linked line, unless it matches a few hardcoded conditions (the line contains the text "warning", "deprecated", and now, "stopped"). Before "stopped" (is it localized? I hope not), it would identify any line with an associated output listener that didn't contain "deprecated" or "warning" as something the user should pay attention to, and so, stop scrolling. What we need is some additional method like "isImportant" on OutputListener, to be able to decide which things are really errors you should stop scrolling for, because the user will need to see them, and which are semi-interesting noise (which these particular debugger messages are).
Verified on build 200409131800