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

ＩＰｔａｌｋは、入力したログや読み込んだ前ロールをＲｉｃｈＥｄｉｔに保存しているため容量に制限があるようです。

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

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

＜従来の説明＞
前ロールがあまりに大きくなるとパソコンによっては、動作が不安定になる場合があります。２０Ｋバイト程度に止めることを進めます。原稿前ロールでは、２０Ｋバイトを越えて読み込んだ場合、警告メッセージが出ます。
これは、Ｗｉｎｄｏｗｓの仕様（？）の一つに６４Ｋバイトというのがあって、マイクロソフトの言うことを信用すれば６４Ｋバイトの前ロールまでは問題ないはずです。実際、ほとんどの場合は、問題がありませんし、それ以上を読み込んでも問題が出ない事もあります。しかし、非常に稀ですが、３０Ｋバイト程度で問題を起こしたという報告をもらっているので、余裕を見て２０Ｋバイトでメッセージを出しています。自分のパソコンで何バイトまでなら正常に動作するかを事前に確かめる事を勧めます。

＜０３０９０６追記＞
１）１．７Ｍバイトのテキストファイルを９ｉシリーズのテンプレート前ロールに読み込ませて少し動かし、保存して、前後の前ロールをｆｃ．ｅｘｅというファイルを比較するソフトで文字化けなどがあるかチェックしました。私の持っているパソコンやラルゴの講習会に集まってくれた人たちのパソコン（Ｗｉｎｄｏｗｓ９５，９８，２０００，ＸＰ）では前後に差はありません。つまり、６４ｋバイトをはるかに超えても大丈夫ということです。
２）大きなファイルを読み込み中に他のソフトを起動するなどすると「ほとんど必ず」ハングするようです。（ＸＰ)

＜その他の情報＞
１）最新版（？）のＲｉｃｈＥｄｉｔでは、扱う文字列のバイト数を指定できます。何も指定しないと３２Ｋバイトになるという説があります。IPtalkを作っているC++Builderでは、扱う文字列の大きさを指定しないと「大きさに制限が無くなる」という説明がありましたが、「それはバグで、６４ｋバイトになる」という説明を読んだ記憶もあります。ＩＰｔａｌｋは、「文字列の大きさを指定しない」で作っています。
2)マイクロソフトは、新しいＲｉｃｈＥｄｉｔは、「メモリがある限り読み込むことができる」と言っているという話も聞きました。
3)メモリに乗っている時は大丈夫だが、スワップが発生すると危ういという話も聞きました。

＜０４０３０８追記＞
９ｓシリーズの自動保存を１０ｋバイトから６０ｋバイトにしたところ、Ｍｅでワープロ画面の「ＲｉｃｈＥｄｉｔの行挿入エラー」が発生した。
このため、元の１０ｋバイトに戻したところ不具合は解消した。
ワープロ画面では、入力文を追記するのに複雑な操作をしているので同じ条件では無いと思うが、前ロールでも基本的に３２ｋバイト以上は避けた方が良いという印象を持っている。

＜０４１２２６／ＩＰｔａｌｋ９ｉ５０／ＩＰｔａｌｋ９ｓ７７＞
４）表示部ワープロ画面やテンプレート前ロール、スライド前ロールなどで編集追加できる量を明示的に６４０ｋと指定した。
９５，９８，Ｍｅの場合は、６４０Ｋバイト。２０００，ＸＰの場合は、６４０ｋ文字＝全角１．２８Ｍバイト。
ワープロ画面やテンプレート前ロールで文を追加して行くと上記の容量を超える文字を追加できない。
（従来は、ＯＳに依存する指定にしていたので、６４Ｋバイト(または３２ｋ）を超える文字を追加できなかった。）
従来と同じように、受信した文やファイルの読込は、この制限を受けずメモリーのあるだけ読み込むことが可能。
また、読み込みなどで制限を越えると手入力でも編集追加できるようになる。
５）「保存｣ページの「定期的な消去と自動保存」に「｢表示・入力」ｔａｂに記録量を表示」チェックを追加した。
チェックを入れると、「表示・入力」ｔａｂに記録量のバイト数を表示する。
記録量が多くなると動作のおかしくなるパソコンがあるため、定期的な消去の目安とするために追加しました。
６）「テンプレート前ロール｣の「読み込み」ボタンを押した時に、２０Ｋバイト以上の場合、読み込んだ文章量のバイト数をメッセージで表示するようにした。
７）「テンプレート前ロール」の「追記」チェックを入れ「読み込み」ボタンを押した時に、巨大なファイルを追記読み込みすると処理に時間がかかりハングしたように見えるので、読み込み途中の様子が前ロールに表示されるようにした。同時に読み込み時間も１／３程度に短縮した。
８）「スライド前ロール送信｣ウィンドの「前ロールの読み込み」ボタンを押した時、２０Ｋバイト以上の場合、読み込んだスライド前ロールの大きさをバイト数をメッセージで表示するようにした。
９）「スライド前ロール送信」ウィンドの「追加」チェックを入れ「読み込み」ボタンを押した時に、巨大なファイルを追記読み込みすると処理に時間がかかりハングしたように見えるので、読み込み途中の様子が前ロールに表示されるようにした。(読み込み時間は変わらない）

＜ヒント＞
４）〜９）は、ログが多量になったり、巨大な前ロールを読み込んだ時に「動作がおかしくなる」パソコンがあることに対する対策です。
しかし、今回、ＩＰｔａｌｋの中を見直したり、いろいろテストしてみて、基本的にはログの量などは不具合の直接的な原因ではないのではないかと考え始めています。
（以下はその話です。）
パソコンの仮想メモリー（Ｃドライブの空き）が十分あり、IPtalk以外のソフトを動かさなければ（リソースに余裕がある）、非常に古いパソコン（リブレット２０、４８６ＤＸ７５ＭＨｚ、２０Ｍ　ＲＡＭ)でもＩＰｔａｌｋは正常に動作します。
リブレット２０で、２Ｍバイト以上のログにして、さらに２Ｍバイト以上の巨大な前ロールを読み込んでも「動作がおかしくなる」という不具合を再現できません。
Ｗｉｎｄｏｗｓは、ＯＳ自身で使うメモリー（９５で６４Ｍバイト、９８で９６Ｍバイト）を確保しに行くので、古いパソコンのほとんどは仮想メモリーでＩＰＴａｌｋは動いていると思います。
それで「ログが多量」＝「長時間の入力」、「巨大な前ロール」＝「長時間の前ロール流し」と考えると、Ｗｉｎｄｏｗｓ９５，９８，ｍｅの有名な「メモリー管理のバグ」が原因ではないかと疑い出しています。
この対策としては、定期的にＷｉｎｄｏｗｓを再起動するか、「メモリ確保ソフト」を使う方法があります。
「メモリ確保ソフト」は以下のフリー・ソフトがお勧めです。
----------------------------------------------
「めもりーくりーなー」／クロノス・クラウン合資会社
http://crocro.com/pc/soft/mclean/index.html
----------------------------------------------
＜参考＞
起動直後のＩＰｔａｌｋ使用メモリー量（ＸＰタスクマネジャの数値）
９ｓ７７：１１．２Ｍ
９ｉ５０：　９．５Ｍ
９ｇ３６：　９．８Ｍ
９ｈ３６：　９．７Ｍ