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.
It would be useful for testing to be able to get whole content of the Output Window.
Target milestone -> 3.3.1.
Target milestone -> 3.4
I suggest to use "redirection to file" feature and then you can get text simply from this file.. What do you think?
I don't like this solution. I can redirect to file even after tab pane appears in Output window. It is after first string is written to output and this string is not written to a file. Or is there exist some API method to redirect to file? I think it would be much more simplier to just call term.getText(). Is it hard to implement it?
Jiri, you can redirect output in general. Use 'Redirection to File'(true) and 'Redirection Directory'(path) properties in Options dialog [IDE Configuration->Look&Feel->Output Window]
If you got term instance, you can use following call to get content of Term buffer (=getText): term.textWithin( Coord.make(0,0), term.getCursorCoord() ) I think it should be sufficient for testing purposes. If there won't be objection (I discussed it with Jiri before) I'll close this issue as WONTFIX.
Suggested solution works for me, but it ignores new line characters ('\n'). I don't know, if it is desired behavior of textWithin() method or if it is a bug.
I see, but I'm not sure - Ivan, what is your opinion? IMO solutions can be: 1. Change calling visitLines in textWithin to: visitLines(begin, end, true,... or 2. Add boolean newlines parameter to textWithin method or 3. Add new method getText, which will return whole text (with newlines).. ?
this is a must-have. QA has been complaining about this missing feature for a long time. I raised prio to P1 for 3.4
I'm not sure that the solution proposed by Ales is generally useful. The usage of the Term component is an implementation detail. It's true that we have ways to find a reference to the Term instance and call its methods, but it's still a hack that may not work for other types of users. IMO, a clearner solution would be to extend the public API (of InputOutput?) and provide methods allowing clients to get the contents of the Output window tab.
It's not easy to extend API, because InputOutput is an interface :-( Anyway, I don't think there should be general solution for all users. There is only one request for getText (this one from QA) - for testing purposes, and there it will be sufficient, won't be?
Hmm, what about adding a new inteface InputOutput2 (or better FilteredInputOutput) and changing the current core implementation(s) to support both InputOutput and InputOutput2? Is this really such an obscure requirement? IMO, module writers might find such API useful too.
CCing Jarda because of requested API change in InputOutput
Looking at Term.textWithin, it seems like an oversight to have dropped the newlines. visitLines() should've been called with newlines=true. re InputOutput2 ... is there a precedent for evolving interfaces in this manner? Just curious.
I fixed missing newlines problem, so now you can use: term.textWithin( Coord.make(0,0), term.getCursorCoord() ) to get text.
This is a must have and needs to be fixed because QA complains about it for long time. On the other hand, QA is the only known user of this feature and we usually do not modify API until needed by more people - even two sometimes are not enough. But I think that there is a simple solution without change of API. Ales, please override method toString () of the object that implements InputOutput. Jiri, call inputOutput.toString () to get the selected text. I would rather leave this undocumented because it is not clear what it should return - in such case remove the API keyword. Otherwise try to documented in the JavaDoc - Let me know when done I wonder how you will describe the functionality ;-?
Great idea! Using toString will be much better.
Hmm, I think that using an undocumented toString() implementation for this is an ugly hack. If you really don't want to expose this functionality in the API, we can probably live with the term.textWithin() call. :-( To Ivan: > re InputOutput2 ... is there a precedent for evolving interfaces in > this manner? Just curious. 1. In NetBeans - probably not. 2. In Java in general - I was educated once that binary compatibility of abstract classes addresses such needs perfectly. Unfortunately, here we are dealing with an interface. 3. In COM/DCOM - yes. COM interfaces are immutable. Adding a new interface (usually inherited from the old one) and changing the implementation to support both is a recommended way of interface evolution.
I added toString() method to OutputTabTerm, returning text content of output tab. BTW - there is bug after calling textWithin() method - see #20626. Also term.textWithin( Coord.make(0,0), term.getCursorCoord() ) OutputTabTerm.toString() doesn't use textWithin(), so I suggest to use it.
OK. It works.
moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table.