Has anyone else seen a problem where the "top" of characters is cut off when the character is typed?
For example, the dot of an i or the top half of the vertical line in a d or b.
I'm using version 3.0 with the following settings:
Connection = SSH2
TERM = VT100
Translation = ISO-8859-1
Colors = ANSI Defaults
Client OS = Win2k
Server OS = RH 7.2, 8.0
The character becomes "complete" if I hit Enter or sometimes if I backspace and re-type it. It doesn't happen constantly, but it's not rare either.
[size=1][ February 18, 2004, 01:52 PM: Message edited by: Brian T. Pence ][/size]
Robert,
What happens when you just hold down the 'i' key and create a string of them quickly? Do some get cut off and others don't?
Yes, some of the i's are fine and others are "cut off." However, when the line wraps (I have the window set to 80 cols) all of the "cut off" i's become complete.
I *have* seen this, but I thought I'd fixed it. It's a bit of a difficult problem to identify, though, as it's very unpredictable as to where and when it will happen. It is at least OS specific, and possibly OS/Video card specific.
Can you give me some more info about your hardware specifices?
Also, if anyone else reads this and has this problem, please post your hardware/software information here!
What I need:
PC type/model number
Video card model
Video card driver version
OS Version (and SP number)
Amount of memory
AbsoluteTelnet version
PC Type: x86 based PC
PC Model: Kenetic (something or other....it's a generic clone)
Processor: x86 Family 6 Model 8 Stepping 6 GenuineIntel ~871 Mhz
Video Card Model: ATI Technologies Inc. RAGE XL AGP 2X
Video Card Driver: atidrab.dll
Driver Version: 5.00.2179.1
OS Name: Microsoft Windows 2000 Professional
OS Version: 5.0.2195 Service Pack 4 Build 2195
Total Physical Memory: 261,596 KB
Absolute Telnet Version: 3.00
It might be worth noting that this problem did not occur with previous versions of Absolute Telnet, 2.13 being the last one I used. No hardware changes have been made to the system since switching from 2.13 to 3.00.
Right. Nothing may have changed in your system, but changes did occur in AbsoluteTelnet. Specifically, the drawing mechanisms have changed to eliminate the flicker on screen when things change on the screen quickly. Now, the program uses double-buffering to paint to an area of memory and then update the screen in one shot.
Unfortunately, this seems to have an unwanted side-effect. I've seen the exact behavior you mention, but I thought I'd fixed it and I can no longer reproduce it myself. That's why knowing more exact information about your system may be helpful.
Tell me something.... If you resize the screen to something very small (under 60 chars wide), do you still have the problem??
I've tried to resize the window to less than 60 chars wide and the problem still occurs.
It's logical that an application change could cause this problem, I just wanted to paint as complete a picture as possible. In a situation like this, any detail might be important.
Do you think combinations of Translation, font type and font size could alleviate the problem?
Or do you think that this is an application wide bug that only occurs with certain systems (OS, hardware, drivers, etc.)?
I've seen it happen in some fonts and not others. It would happen more often at wider screen sizes, regardless of screen height. Larger fonts would make it worse.
I've only seen it happen under Win2k, and I haven't seen it happen now in awhile, which makes it difficult for me to diagnose.
sigh.......
I've got a beta version for you to try. I found an issue that might be related and may affect your problem. Unfortunately, since I can't reproduce your exact problem, I have no way to be sure if this will fix it. Give it a try and let me know...
Thanks!
I've tried the beta version, and the problem still exists.
Since I can reproduce the problem easily, is it possible to give me a debug version with extra log messages in it (it's something I've done with my own stuff in the past)? This way I can reproduce the problem and give you the log.
Just a thought....
That would normally be useful, especially when I've never seen the bug before. Unfortunately, I've already seen this one and had a hard enough time troubleshooting it inside my own debugger. As soon as I'd get close enough to identifying the bug, it would go away!!
I have a feeling it's a timing issue between the thread that's receiving data and the main thread that's painting it, but I've had a difficult time proving this. The fact that it no longer happens to me is doubly frustrating
Let me stare at the code a little more tonight and see if I can come up with a test case for you to run to verify some assumptions.
later...
It's been a few weeks, so I was wondering if you'd had any ideas on this one?
I'm now using version 3.11 RC14 and the problem still occurs.
Once again, if you'd like to give me a debug version, I'd be happy to run a few tests for you to try and shed some light on this one.
Robert,
I appreciate your offer to debug. The only problem is that I'm not sure what area to focus the debug on to isolate it. I've had this particular problem before, in the debugger itself. My problem was that as soon as I got close to isolting it, the problem mysteriously went away. And, as with most problems that mysteriously go away, they mysteriously come back as well!
RC14 contained some modifications that were supposed to help. I'm disappointed to hear that they did not. One other thing I'd like you to check is the settings of your graphic card's hardware acceleration.
Check ControlPanel->Display->Settings->Advanced
It should be somewhere under there. If enabled, disable them and try again.
Let me know...
Brian
Robert, I've got another Beta I'm anxious for you to try! I’m *almost* positive it resolves the problem you are having, however I cannot be sure until you test it. In version 3.00 and above there were two issues that cropped up that seemed to be related but I could never resolve. On some systems, under rare conditions, AbsoluteTelnet would experience one or both of the following conditions:
1. Seemingly random cut-off characters
2. Excessive (but harmless) page faults when you’re watching the process run in Task Manager. Now,
I always believed the two problems were related, as they both appeared in version 3.00 and at least both seemed to be related to some of the screen drawing code that changed between version 2.13 and version 3. The problem in debugging is that I can not reproduce condition number 1 and condition number 2 was elusive and evaded me for some time. I happy to announce that I’ve found the cause for condition number 2 and have provided a fix in RC15!!! My belief is, also, that this will take care of condition number 1, so please give it a test and let me know your results!!
Thanks for your help!
Brian Pence
Celestial Software
