Open Live Writer の動作がおかしい

Open Live Writer の動作がおかしい.タスクバーのアイコンからオープンしたが,すぐ画面から消えてしまったので,一度閉じて再度開いたところ,随分前のドラフトを開いてきた.

image

このファイルはすでに公開されているし保存もしてあるのだが,これまでにも「修復しますか?」というメッセージが何度も出てその都度処理しているのに,時折思い出したようにゴーストとなって立ち上がって来る.その後,以下のような真っ赤なパネルがポップアップしてきた.

image

このパネルは,前にも少なくとも一度は見たことがある.以下のようなエラーも表示された.

image

エラーレポートには大したことは記載されていなかった.起動時にファイルが画面から消えたというのは,多分,モニターを切り替えたためと思われる.赤いパネルは何かのメッセージと思われるが,意味不明だ.

ともかく,先に進もう.大きい数字を扱えるようにするために可能なことをあれこれやっているが,その一環として,プログレスバーを廃止し,その代わりにタスクバー上のアイコンを点滅させることにした.この動作は一般にアプリをインストールする操作中にパネルが他のウィンドウの影に隠れてしまった場合,ユーザに注意を促すために使われるものなので,用法としてはやや変則だが,点滅が止まれば処理は完了しているというメッセージと解釈できるので,長く掛かりそうな場合には,放置して他のことをやるなどの応対が考えられるので,それなりに有効なのではないかと思う.

もう一つの対策として,現在valueの入力ボックスでテキストが更新された場合にはパラメータ表示を即時更新するようにしているのを,リターンキーが入力されたときにのみ確定入力として処理するよう仕様変更することにした.あちこち仕掛りになっているのだが,使い勝手にも影響するところなので,まずこれを先付けで修正を入れることにする.

キーイベントが入ってこない.なぜだろう?どこかのコントロールにフォーカスがあると,そのコントロールにイベントがパスされて,そこで明示的に放棄しないと回ってこないのではなかったろうか?ZELKOVAでは一覧画面でなにかその辺りを対策していたような気がするのだが… ⇒KeyPreviewというプロパティをオンにすればよい.⇒動作するようになった.Enterキーを受け付けたときは,長い処理でも打ち切らないようにしておこう.(自発的に指示しているので待つことができる)

おかしい,1234567の7桁で配列サイズオーバーが発生した.ToBCDで起きている.ToBCDが使っている配列はInt16.MaxValueの固定サイズだ.循環周期は34020>32767=Int16.MaxValueで明らかにオーバーしている.循環数列は計算に使っているのではなく,単に表示しているだけなのだから,打ち切ってもよいのではないか?実際,小さいテキストボックスに30000文字を格納するというのは現実的ではない.

テキストボックスのサイズは32767になっているから,その範囲なら格納することは可能だ.bcdNumberにはこの制限はかかっていないが,この値は最終的にnotation.Textに格納されるので,それ以上長い文字列を作っても意味がない.現在MAXARRAYSIZEには,536,608,768という数字が入っている.これはInt16.MaxValueよりはずっと大きいので,ここまではとりあえず処理してもよいのではないか?配列サイズをMAXARRAYSIZE固定としてとりあえず,動作した.1/1234567の固定部は73桁,循環部は34020桁で,冒頭は

A:0.000000810000591300431649315104000025920018921613812778083328000829
4406054&91642008898666496026542099375732544284757327872849347180023441
41711223449193117910976075012534759150374179773151234400401112292811973
75274083950081283559336998316008770686402601073898783946112280661964883

のような巨大テキストだ.value=1234567890として10桁入力してENTERでは,Invertまでは完了しているが,inverseの表示が出てこない.桁数も0, 0 のままになっている.どうも,BigInteger.Divideという関数の中で滞留しているようだ.Divideの引数の中で,BigInteger.Pow(b, keta)の計算に手間取っているのでははないか?InverseClickの中でも,DispParametorを実行している.これは余分な処理なのではないか?いや,DispParametorを実行しているのは,ここだけだ.もう一箇所あるが,これは単に初期表示しているだけだ.

ToBCDが結構重い処理になっている.どうも,Debug.WriteLineで糞詰まりしているようだ.InvertFuncが完了した後で,小数を整数化→文字列化しているが,InvertFuncの中でこの数字列を取得することはできないのだろうか?この数字はとても巨大で,Debug.WriteLineですら表示できないような数だ.また,その間,点滅がまったく止まってしまうというのもおもしろくないところだ.valueが7桁の1234567なら,妥当な時間で表示まで進める.

延べ来訪者数がいつの間にか11万人を超えた.ちょっぴりうれしい.

image

循環周期列とInvertの内部コードを比較してみよう.⇒確かに一致している.つまり,InvertFuncを実施すれば,その結果を使って循環周期列を直接生成できる.循環周期列の生成は巨大数を用いたコストの掛かる処理だったので,これが省けるメリットは大きい.まず,DispInvertに相当する関数を作ってみよう.⇒従来論理の出力と比較してみたが,…

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA