01112 98/07/28 12:25

RE:01110 win98up後秀内のｽｸﾘｰﾝに残像

投稿者：斉藤秀夫

　Windows98でのテストとしては、こちらでは以前からWindows98のβ3を使ってテス
トしていたんですが、スクリーンに残像が残るような症状は起きていませんでした。

　ほかの方のところでどういう症状が起きているのか、いろんな情報が集まらないと、
今のところなにが悪いのか判断できないです。

　とりあえずパソコンの種類とかビデオカードの種類とか教えてほしいです。

01113 98/07/28 12:25

RE:01111 秀Term Evo での行抜け

投稿者：斉藤秀夫

コメントを投稿する

　改行コードですが、0Dの場合、カーソルは行頭に移動するだけで、スクロールアッ
プはしません。これは通信ソフトならどれも同じでして、秀Termだけ違う動きをする
訳ではないです。

　ただし、「受信時 CR->CR+LF変換」をonにしておけば、0Dを受信しただけでもちゃ
んとスクロールアップするようになります。

　0Dの改行と0D0Aの改行をまぜて送ってくるような場合には、少なくとも秀Term、と
いうか、通信ソフトで受信する以上は正常に表示することはできないです。

　送り側の人に対処してもらうしか無いと思います。

01114 98/07/28 19:38

RE:01113 秀Term Evo での行抜け

投稿者： tsuka

コメントを投稿する

>　改行コードですが、0Dの場合、カーソルは行頭に移動するだけで、スクロールアッ
>プはしません。これは通信ソフトならどれも同じでして、秀Termだけ違う動きをする
>訳ではないです。
>
>　ただし、「受信時 CR->CR+LF変換」をonにしておけば、0Dを受信しただけでもちゃ
>んとスクロールアップするようになります。
>
>　0Dの改行と0D0Aの改行をまぜて送ってくるような場合には、少なくとも秀Term、と
>いうか、通信ソフトで受信する以上は正常に表示することはできないです。
>
>　送り側の人に対処してもらうしか無いと思います。
>
ご指摘の状況は分かっています。
ただ、e-mailer (例えば、IE4.0)などで受ける分には問題ないのです。
送り手に対処してもらえばそれに越したことはありませんが、少なくとも、他の
通信ソフトは、0Dのみのケースは0Dを削除しているみたいで0D0Aで初めて改行
としているようです。多分にこれは、謝ったケースでも通信の確実性から、送信
文字列を保証するという思想からきていると思われます。
秀TERMの「受信時CR->CR+LF変換」をONは一つの解決策です。ですが、この場合
0D0A行は 2行の改行となってしまい、非常に間延びしたテキストとなってしまい
これも不自然です。
やはり、0Dのみの行は0Dを削除するのがベターと考えています。実際、スクリプト
でキャラクタ毎の受信としておき、キャラクタ毎にこの判定を入れて処理すると
なんら不都合はありません｡でも、この場合でもストックファイルは、0Dを行頭
に戻してしまうので、受信内容を欠落したように見せてしまいます。規約から
すれば、秀TERMの処理が正しいとも思ってはいますが、通信の送り手の意図を
欠落させないと、いう考え方に立てば、柔軟な解釈がなされてもよいのでは ?
とも考えています。いかがでしょうか。

新規に投稿する