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: | Cursor isn't on end of text after using CTRL+C [V, ...] | ||
|---|---|---|---|
| Product: | cnd | Reporter: | Lukas Hasik <lhasik> |
| Component: | Terminalemulator | Assignee: | ivan <ivan> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | akemr, rmatous |
| Priority: | P3 | ||
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Windows ME/2000 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
Ivan, it's probably problem in term, could you please look at it? Need some clarification: a) Did you in fact mean to say that the cursor moves right? b) Is the 'strange' character a square? If not, what is it? Assuming both the answers are yes, what should OW do? Did you expct ^C to copy ^v to paste etc? If so, the fix is to be done in OutputTabTerm where these characters should be added to the terms keystrokeset and appropriate actions associated with them. Otherwise control characters are valid ASCII and unicode characters and so Term doesn't treat them any differently. They might not have a useful representation in the chosen font. On solaris I get spaces and on windows "unprintable" characters usually appear as boxes. No the Ctrl+c writes no vissible character. The cursor moves few pixels left. If you hit ctrl+c many times the cursor will move well before (to the left) of the last character. Therefore it is in an invalid position. It apears normally it is just moved to the left. Pressing enter resets the cursor to the the correct position. ad a, cursor (black rectangle) moves to left. New typed text is added at the end of text but cursor is somewhere else. ad b, yes, it's square on my win2000 If CTRL+C, +V would work as usually it'd be nice :) It's confusing for user if (s)he writes sequence of this CTRL+... and cursor is moving somewhere into text and new characters appears still at the end ... After seeing gifs sent by Ales it's clear what's going on. The root of the problem is that Term depends on "Monospaced" fonts and the font that you are getting under windows renders "unprintable" characters as a square _and_ this square is of wider width the all the other characters. Terms calculation for the cursor position is based on the width of characters and is correct. Term uses Graphics.drawChars() to render the characters and the extra-wide squares end up getting ahead of the cursor. So, this seems to really be a Microsoft (Or Java's binding of "Monospaced") "bug". The workaround in Term would be to render characters one at a time, but that is prohibitively expensive. Target milestone -> 3.3.1. Target milestone -> 3.3.1. Ivan, it looks that this issue is fixed. Cursor stays at the end of text in build 200111280300 from release33 branch. So this issue should be marked as fixed ;) I don't think so. I can easily reproduce it on 200111280300 and on 200111300330 too (release33 branch) well, it works fine on jdk1.4-b85 but not on jdk 1.3.1 So this problem was fixed in new JDK. Confirmed, it's fixed in JDK 1.4 So, I suggest to close this issue as WONTFIX.. 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. *** Fixed in 3.4 trunk tag ivan_13 See .../terminalemulator/ReleaseNotes.ivan.txt for gory details. Integrated into orion_fcs (by ivan & tor). verified in [orion](020517-rc4) Resolved for 3.4.x or earlier, no new info since then -> closing. moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table. |
Try to write into OW. Cursor moves a few pixels to left when using CTRL+C (or others CTRL+...) because CTRL+C writes 'strange' char into OW and cursor isn't at the end of text. Workaround - push Enter to be on new line - delete 'strange' chars written by CTRL+...