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.
Currently, if a program (either being "run" or "debugged") requires input the only option the output tabs (from IOProvider) provide is to type input into a text field below the main text area. This has various problems. First off, it separates input from output. Its not separated if the same program is run from a terminal. Even worse, if the program outputs a prompt (ie, text without a newline), the prompt isn't displayed until after the user types input. In many cases, the user won't type the input because they're waiting for the prompt! The following class demonstrates this problem: package javaapplication1; import java.io.IOException; public class Main { public static void main(String[] args) { System.out.print("prompt: "); try { System.in.read(); } catch (IOException ex) { } } }
I submitted before finishing... I've never understood why this type if input hasn't been perceived as a decifiency in netbeans (Eclipse handles this exactly as you'd expect). In my groups case (the cnd team) we feel this type of support is critical for C/C++ developers.
your described scenario shall already work in trunk with the output window. It doesn't work with the ant-built projects because ant sends only complete lines to output.
I downloaded the nb60 milestone 3 and the latest CND nightly. I see no change in behavior from nb50 or nb55. When I run my C app I get an input textfield (separate from the main output panel) and my input still appears before my prompt. A (very) quick look at core/output2 sources shows very few differences between nb55's version and the trunk version. In fact, I diff'ed InputPanel.java from nb55 (1.5.68.1) and the trunk (1.6) and the only differences were white space.
this ought to work. please review how you write to the output window. AFAIK this doesn't work for ant builds for example because they write line-per-line to the output. Thus a non-finished line (print()) is cached and printed only after a new line arrives. YOur issue is probably similar. I have tests for the partial line printing so i'm pretty confident it works in OW. The input line is still separated in a text field that's why there's no change in INputPanel.
Adjusting summary to reflect the outstanding concern.
rewriting the OW to support entering input directly into the output pane would constiture a major rewrite of the output window and would need to have resources assigned. I'm not even convinced it would be possible while maintaining the current throughput display optimizations therein.
actually with a few limitations the text could be entered in the output window. 1. text is always entered at the end, no matter where the cursor is. 2. if new output arrives, the input text moves to the end again. 3. the input is still sent to process line-by-line 4. only a limited set of editor actions is available, Enter sends line to process, backspace removes the last char..more necessary? please let me know if with these limitations it still fulfills your requirements.
> 1. text is always entered at the end, no matter where the cursor is. > 2. if new output arrives, the input text moves to the end again. > 3. the input is still sent to process line-by-line > 4. only a limited set of editor actions is available, Enter sends line to > process, backspace removes the last char..more necessary? These limitations come very close. The main issue I see is that the current output window ignores a '\n' and leaves the cursor at the end of a line. For instance, if a build outputs "Build Failed\n" then the cursor is left at the end of this line rather than at the start of an empty line. Since I expect this cursor will be my input insertion point, that doesn't work. On the other hand, if the cursor is moved to the beginning of the next line when '\n' is output (and doesn't move if I output a string without a '\n"), then that should work.
the requirement you mention is new to me, it was never discussed before and is not part of the initial summary. I'm not sure I can incorporate it into the fix for this bug. Please let me know if the current solution without the cursor tweaking is acceptable or not.
Created attachment 36398 [details] patched output2 module
Created attachment 36399 [details] test application
attached is the patched binary of the output2 module. please test it and provide feedback. a few changes.. 1. when the cursor is within the editable input text at the end, it inserts the character at the location at the cursor 2. also deletes by backspace and delete keys work (a minor bug is that after deleting a char, the cursor moves badly) 3. if the cursor is outside the editable area, the text still appears inside the editable area..
Is the output2 jar file attachment for NB 5.5, 5.5.1, or trunk? I'm not sure we build or run with the current trunk (editor APIs have changed and we recently switched from the release55 branch to release551). If possible, a 551 jar file would be best. If not, it will take me a week or 2 to be able to get cnd building from the trunk (maybe longer as I'm still working on FCS issues).
it's trunk. but I think it should work in 5.5 as well if dropped into the installation.
The patch seems to be working on Win XP except: - when I was writing a too long line exceeding the visible area then I couldn't see what I was writing. Either show up the horizontal scroll bar or wrap the line. - An exception was thrown when I wrote the long like and deleted part of it and hit enter. I can try to reproduce if you want. - the progress bar indicating running application behaved *very* strange. But this is probably another issue.
jrojcek: i'll take a look at the scrolling issue. my bigger concern is usability. Will the users figure out that it's possible to write into the OW after we've had the input textfield for many releases?
My test program is a simple program called cvt. It reads a line of input and converts case on all alphabetic characters. If run from a terminal, here is the output: $ cvt Converting stdin: cvt: abcd ABCD cvt: qwerty QWERTY cvt: x Done! I typed the "abcd" and "qwerty". The rest is program output. When I ran cvt from inside netbeans (with your patched output2 jar file) I got incorrect output. Of the 4 times I ran it (with fresh userdirs) I had about the same results each time. The one area where it changed is that characters were reversed 2 of the 4 runs (ie, "abcd" became "dcba"). It looks like the insertion point wasn't moved to the right of the typed character. Here is the output from running it: Running "dist/Debug/GNU-Solaris-Sparc/cvt" in /home/gordonp/cvt Converting stdin: abcd cvt: ABCD qwerty cvt: QWERTY x cvt: Done! Run successful. Exit value 0. cvt: Done! Run successful. Exit value 0. Again, I typed "abcd" and "qwerty". One error this doesn't show is that as I type the characters are echoed at the end of the previously output line. But those characters are removed and shown on the following line after I press Return. So right before my 1st return I saw: Convertiong stdin:abcd| where '|' is the (visible) insertion point. For the runs where my letters were reversed, the '|' stayed to the left of the input character and I'd see: Converting stdin:|dcba This same pattern repeated with the 2nd and 3rd lines of input: cvt: ABCDqwerty and cvt: QWERTYx Would it help if I sent you a cnd cluster so you could test it on your machine? We haven't ported to the trunk so the stuff I did to get a running cnd in the trunk won't get committed for several months. If I could talk you into backporting your changes to release551 it would be much easier for us to test them and get feedback to you very quickly. I also moved the insertion pointer once (via arrow keys). Before I pressed Return I had moved it back to its original location. None the less, I get a StringIndexOutOfBoundsException (see 2nd attachment).
Created attachment 36695 [details] Tar file of my test program (the entire project)
Created attachment 36696 [details] Stack trace of exception
We (SunStudio) would like this fix backported to 5.5.1
Created attachment 37523 [details] updated version of patched output2 binary
status update: I fixed the exceptions that were appearing on edits. cursor moves in sane way now. still not production ready though. 1. cannot distinguish if the last output line was a complete one or not and put input approately (either same line or next) 2. in wrapped mode cursor is offsetted by 1 char to the right 3. selecting a block and deleting it, moves the block and does reselection I have placed the result on a branch (named by the issue number). Still not ready for trunk. In any case the fix is rather complex and unpredictable, so definitely don't recommend putting into 551 (even if the outstanding issues are resolved in time)
Removed MARS keyword. A fix is considered too risky/complicated for 5.5.1 and is no longer required for Mars release. We would still like to see it fixed in 6.0.
-> M9
integrated in trunk. will file the remaining issues as bugs. IDE:------------------------------------------------- IDE: [5/2/07 2:14 PM] Committing started Checking in test/unit/src/org/netbeans/core/output2/OutputDocumentTest.java; /cvs/core/output2/test/unit/src/org/netbeans/core/output2/OutputDocumentTest.java,v <-- OutputDocumentTest.java new revision: 1.12; previous revision: 1.11 done Checking in src/org/netbeans/core/output2/ui/AbstractOutputTab.java; /cvs/core/output2/src/org/netbeans/core/output2/ui/AbstractOutputTab.java,v <-- AbstractOutputTab.java new revision: 1.14; previous revision: 1.13 done Checking in src/org/netbeans/core/output2/ui/AbstractOutputPane.java; /cvs/core/output2/src/org/netbeans/core/output2/ui/AbstractOutputPane.java,v <-- AbstractOutputPane.java new revision: 1.41; previous revision: 1.40 done Checking in src/org/netbeans/core/output2/WrappedTextView.java; /cvs/core/output2/src/org/netbeans/core/output2/WrappedTextView.java,v <-- WrappedTextView.java new revision: 1.21; previous revision: 1.20 done Checking in src/org/netbeans/core/output2/AbstractLines.java; /cvs/core/output2/src/org/netbeans/core/output2/AbstractLines.java,v <-- AbstractLines.java new revision: 1.23; previous revision: 1.22 done Checking in src/org/netbeans/core/output2/OutputDocument.java; /cvs/core/output2/src/org/netbeans/core/output2/OutputDocument.java,v <-- OutputDocument.java new revision: 1.17; previous revision: 1.16 done Checking in src/org/netbeans/core/output2/OutputPane.java; /cvs/core/output2/src/org/netbeans/core/output2/OutputPane.java,v <-- OutputPane.java new revision: 1.21; previous revision: 1.20 done IDE: [5/2/07 2:14 PM] Committing finished
I cannot get it to work correctly with a C/C++ program. I'm using the following test program: #include <stdio.h> int main(int argc, char **argv) { char *cp, buf[BUFSIZ]; printf("prompt: "); scanf("%s", buf); printf("got: %s\n", buf); } When run in external terminal, I get: prompt: hello got: hello When run from the IDE, I get: Running "dist/Debug/GNU-MacOSX/application_3" in /Users/thp/NetBeansProjects/Application_3 hello prompt: got: hello Note "prompt" has not been flushed. Question: is there something special we to do on our end to make this work? You can use the full distribution of NB to duplicate the problem. Create a C/C++ Application, add an empty C++ file and and paste the main from above into it. You switch from external terminal execution to output window execution by changing Running|Console Type project property to Output Window.
the equivalent java program is working fine, so my assumption is that on your end you are feeding the output window in a wrong way (as was doing ant for some time) you need to make sure that non-complete lines are read from the programs output and forwarded to the netbeans output window, currently you probably do a line-by-line forwarding.