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.
Summary: | CTRL-C to copy in Output Window causes it to scroll to bottom | ||
---|---|---|---|
Product: | cnd | Reporter: | _ tboudreau <tboudreau> |
Component: | Terminalemulator | Assignee: | ivan <ivan> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | akemr |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ tboudreau
2001-11-06 10:56:44 UTC
I don't see this behaviour in compiler OW or when OW displays output only. Please attach example, if you have another opinion. But when executed program uses input (opens input stream), then it should be sensitive on user input IMO. Yes, it works fine for output only. When I do System.out.println("....") OW changes to I/O mode and CTRL+C works properly but a square character is displayed. Why is the OW in I/O when I'm doing only output ? Or am I wrong ? I encountered this when testing an app that I set up to write voluminous debug output and needed to copy a portion of it into the unit tests that would need to match this output in the future. I did also see the square characters appear for my CTRL-C keystrokes. I think it's worth differentiating meta keystrokes, or at least doing this optionally in the output window - the two things it's likely to be used for are: Java - Copy to the clipboard C - Brutally terminate the program in neither case is scrolling the window useful. As long as we do send those keystrokes to the application's standard in as well, everything works as expected in all cases. I think I should reassign it to Ivan.. Target milestone -> 3.3.1. Target milestone -> 3.3.1. Target milestone -> 3.4 Target milestone -> 3.4 Target milestone -> 3.4 Target milestone -> 3.4 *** Issue 21035 has been marked as a duplicate of this issue. *** Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Set terget milestone to TBD Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Set terget milestone to TBD Target milestone was changed from '3.4' to TBD. *** Issue 26285 has been marked as a duplicate of this issue. *** doesn't seem we can fix it for 3.5 -> target = 4.0 *** Issue 21207 has been marked as a duplicate of this issue. *** If someone types a ^C to Term (under stock NB) currently the copy action may happen but you also get a square printed and may get other side-effects per this bug report. Term has a mechanism where the keystrokes for all actions associated with it's containing window can be used to defeat their printing (as squares). (See Term.setKeyStrokeSet()). There is an issue that the registered KSS is in terms of KeyStrokes made up of KeyCodes, while Term needs to filter out Key_Char_s. I've dealt with his as best as I can but when testing discovered that the set of Kestrokes registered with Term is not quite right. This is done in OutputTabTerm.updateKeyStrokeSet() where it uses lookup to get _some_ keymap. When I dump it it's a pretty large keymap. It contains keystrokes not relevant to OW and is missing keystrokes like Ctrl-A. So are we registering the correct keymap? 'keystroke_set' is a collection of KeyStrokes in the form: ks3 = getKeyStroke(VK_C, CTRL_MASK) we use Term.maybeConsume() in keyPressed and keyTyped events. During keyTyped the event->KS mapping gives us ks2 = getKeyStroke((char) ('c'-64), CTRL_MASK) ks2 and ks3 while logically equivalent don't hash to the same so maybeConsume() says yes to ks2 and the Ctrl-C gets passed on. So to detect whether something in 'keystroke_set' needs to be dropped we need to check at keyPress time but take action at keyTyped time. 'passOn' helps us do that. closed moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table. |