6-16-17)ログと前ロールの許容量

IPtalkは、入力したログや読み込んだ前ロールをRichEditに保存しているため容量に制限があるようです。

ただ、通常は、読み込む前ロールやログの容量は気にすることはありません。1Mバイトを超えても大丈夫です。

問題の無いパソコンは、全く問題ないのですが、一部のパソコンでは問題が発生すると言うのは事実のようです。
しかし、原因やどのパソコンで発生するかは、はっきり分かっていません。

<従来の説明>
前ロールがあまりに大きくなるとパソコンによっては、動作が不安定になる場合があります。20Kバイト程度に止めることを進めます。原稿前ロールでは、20Kバイトを越えて読み込んだ場合、警告メッセージが出ます。
これは、Windowsの仕様(?)の一つに64Kバイトというのがあって、マイクロソフトの言うことを信用すれば64Kバイトの前ロールまでは問題ないはずです。実際、ほとんどの場合は、問題がありませんし、それ以上を読み込んでも問題が出ない事もあります。しかし、非常に稀ですが、30Kバイト程度で問題を起こしたという報告をもらっているので、余裕を見て20Kバイトでメッセージを出しています。自分のパソコンで何バイトまでなら正常に動作するかを事前に確かめる事を勧めます。



<030906追記>
1)1.7Mバイトのテキストファイルを9iシリーズのテンプレート前ロールに読み込ませて少し動かし、保存して、前後の前ロールをfc.exeというファイルを比較するソフトで文字化けなどがあるかチェックしました。私の持っているパソコンやラルゴの講習会に集まってくれた人たちのパソコン(Windows95,98,2000,XP)では前後に差はありません。つまり、64kバイトをはるかに超えても大丈夫ということです。
2)大きなファイルを読み込み中に他のソフトを起動するなどすると「ほとんど必ず」ハングするようです。(XP)



<その他の情報>
1)最新版(?)のRichEditでは、扱う文字列のバイト数を指定できます。何も指定しないと32Kバイトになるという説があります。IPtalkを作っているC++Builderでは、扱う文字列の大きさを指定しないと「大きさに制限が無くなる」という説明がありましたが、「それはバグで、64kバイトになる」という説明を読んだ記憶もあります。IPtalkは、「文字列の大きさを指定しない」で作っています。
2)マイクロソフトは、新しいRichEditは、「メモリがある限り読み込むことができる」と言っているという話も聞きました。
3)メモリに乗っている時は大丈夫だが、スワップが発生すると危ういという話も聞きました。



<040308追記>
9sシリーズの自動保存を10kバイトから60kバイトにしたところ、Meでワープロ画面の「RichEditの行挿入エラー」が発生した。
このため、元の10kバイトに戻したところ不具合は解消した。
ワープロ画面では、入力文を追記するのに複雑な操作をしているので同じ条件では無いと思うが、前ロールでも基本的に32kバイト以上は避けた方が良いという印象を持っている。



<041226/IPtalk9i50/IPtalk9s77>
4)表示部ワープロ画面やテンプレート前ロール、スライド前ロールなどで編集追加できる量を明示的に640kと指定した。
95,98,Meの場合は、640Kバイト。2000,XPの場合は、640k文字=全角1.28Mバイト。
ワープロ画面やテンプレート前ロールで文を追加して行くと上記の容量を超える文字を追加できない。
(従来は、OSに依存する指定にしていたので、64Kバイト(または32k)を超える文字を追加できなかった。)
従来と同じように、受信した文やファイルの読込は、この制限を受けずメモリーのあるだけ読み込むことが可能。
また、読み込みなどで制限を越えると手入力でも編集追加できるようになる。
5)「保存」ページの「定期的な消去と自動保存」に「「表示・入力」tabに記録量を表示」チェックを追加した。
チェックを入れると、「表示・入力」tabに記録量のバイト数を表示する。
記録量が多くなると動作のおかしくなるパソコンがあるため、定期的な消去の目安とするために追加しました。
6)「テンプレート前ロール」の「読み込み」ボタンを押した時に、20Kバイト以上の場合、読み込んだ文章量のバイト数をメッセージで表示するようにした。
7)「テンプレート前ロール」の「追記」チェックを入れ「読み込み」ボタンを押した時に、巨大なファイルを追記読み込みすると処理に時間がかかりハングしたように見えるので、読み込み途中の様子が前ロールに表示されるようにした。同時に読み込み時間も1/3程度に短縮した。
8)「スライド前ロール送信」ウィンドの「前ロールの読み込み」ボタンを押した時、20Kバイト以上の場合、読み込んだスライド前ロールの大きさをバイト数をメッセージで表示するようにした。
9)「スライド前ロール送信」ウィンドの「追加」チェックを入れ「読み込み」ボタンを押した時に、巨大なファイルを追記読み込みすると処理に時間がかかりハングしたように見えるので、読み込み途中の様子が前ロールに表示されるようにした。(読み込み時間は変わらない)

<ヒント>
4)〜9)は、ログが多量になったり、巨大な前ロールを読み込んだ時に「動作がおかしくなる」パソコンがあることに対する対策です。
しかし、今回、IPtalkの中を見直したり、いろいろテストしてみて、基本的にはログの量などは不具合の直接的な原因ではないのではないかと考え始めています。
(以下はその話です。)
パソコンの仮想メモリー(Cドライブの空き)が十分あり、IPtalk以外のソフトを動かさなければ(リソースに余裕がある)、非常に古いパソコン(リブレット20、486DX75MHz、20M RAM)でもIPtalkは正常に動作します。
リブレット20で、2Mバイト以上のログにして、さらに2Mバイト以上の巨大な前ロールを読み込んでも「動作がおかしくなる」という不具合を再現できません。
Windowsは、OS自身で使うメモリー(95で64Mバイト、98で96Mバイト)を確保しに行くので、古いパソコンのほとんどは仮想メモリーでIPTalkは動いていると思います。
それで「ログが多量」=「長時間の入力」、「巨大な前ロール」=「長時間の前ロール流し」と考えると、Windows95,98,meの有名な「メモリー管理のバグ」が原因ではないかと疑い出しています。
この対策としては、定期的にWindowsを再起動するか、「メモリ確保ソフト」を使う方法があります。
「メモリ確保ソフト」は以下のフリー・ソフトがお勧めです。
----------------------------------------------
「めもりーくりーなー」/クロノス・クラウン合資会社
http://crocro.com/pc/soft/mclean/index.html
----------------------------------------------
<参考>
起動直後のIPtalk使用メモリー量(XPタスクマネジャの数値)
9s77:11.2M
9i50: 9.5M
9g36: 9.8M
9h36: 9.7M