Bug 15333 - Cursor isn't on end of text after using CTRL+C [V, ...]
Cursor isn't on end of text after using CTRL+C [V, ...]
Status: CLOSED FIXED
Product: cnd
Classification: Unclassified
Component: Terminalemulator
3.x
PC Windows ME/2000
: P3 (vote)
: 6.x
Assigned To: ivan
ivan
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-10 17:36 UTC by Lukas Hasik
Modified: 2008-12-23 08:40 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Hasik 2001-09-10 17:36:45 UTC
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+...
Comment 1 akemr 2001-09-11 09:36:28 UTC
Ivan, it's probably problem in term, could you please look at it?
Comment 2 ivan 2001-09-12 03:16:29 UTC
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.


Comment 3 Jan Pichert 2001-09-12 17:34:56 UTC
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.
Comment 4 Lukas Hasik 2001-09-12 17:43:48 UTC
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 ...
Comment 5 ivan 2001-10-22 23:06:23 UTC
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. 
Comment 6 Jan Chalupa 2001-11-27 11:54:01 UTC
Target milestone -> 3.3.1.
Comment 7 Jan Chalupa 2001-11-27 11:57:24 UTC
Target milestone -> 3.3.1.
Comment 8 Lukas Hasik 2001-11-29 18:17:47 UTC
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 ;)
Comment 9 akemr 2001-11-30 10:12:08 UTC
I don't think so. I can easily reproduce it on 200111280300 
and on 200111300330 too (release33 branch)
Comment 10 Lukas Hasik 2001-12-03 14:40:11 UTC
well,
it works fine on jdk1.4-b85 but not on jdk 1.3.1
So this problem was fixed in new JDK.
Comment 11 akemr 2001-12-04 07:49:28 UTC
Confirmed, it's fixed in JDK 1.4

So, I suggest to close this issue as WONTFIX..
Comment 12 Jan Chalupa 2002-01-11 14:05:46 UTC
Target milestone -> 3.4
Comment 13 Jan Chalupa 2002-01-11 14:09:08 UTC
Target milestone -> 3.4
Comment 14 Jan Chalupa 2002-01-11 14:09:54 UTC
Target milestone -> 3.4
Comment 15 Jan Chalupa 2002-01-11 14:12:19 UTC
Target milestone -> 3.4
Comment 16 akemr 2002-03-04 13:49:36 UTC
*** Issue 21035 has been marked as a duplicate of this issue. ***
Comment 17 ivan 2002-04-05 20:53:38 UTC
Fixed in 3.4 trunk tag ivan_13
See .../terminalemulator/ReleaseNotes.ivan.txt for gory details.
Comment 18 Jan Chalupa 2002-04-11 10:19:57 UTC
Integrated into orion_fcs (by ivan & tor).
Comment 19 Marian Mirilovic 2002-05-20 09:19:41 UTC
verified in [orion](020517-rc4)
Comment 20 Quality Engineering 2003-07-01 16:28:38 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 21 Quality Engineering 2008-12-23 08:40:41 UTC
moving terminal emulator issues to terminalemulator component.
To see the correct version and target milestone of this issue look at Issue
Activity table.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo