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+...
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
So, this seems to really be a Microsoft (Or Java's binding of
"bug". The workaround in Term would be to render characters one at a
but that is prohibitively expensive.
Target milestone -> 3.3.1.
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)
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
*** 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