ゼルコバの木システム構成図を入力する

ランニングテストを兼ねて「ゼルコバの木システム構成図」を作っているところだが,いろいろと不具合が検出されている.これらのデバッグないし改善は後回しにして,もう少しデータ入力を続けることにしよう.ゼルコバの木システム構成図の上半分は①COUPLING(系図システムオブジェクト)を頂点とするコンポーネント(実体を持ったオブジェクト)の包含関係図,下半分は②NODULEクラスを基底クラスとするクラスの継承関係図になるということが分かった.当面は両者を無理やり結びつけるのではなく,2つの独立した図面として描画してみるというところから始めてみたい.①はすでに半分まで出来上がっているので,あとは基本クラスを要素として追加するだけだ.

図面①ではオブジェクトの接続関係を実親子関係とし,参照関係を養親子関係として表記することにする.これはメモリ上に配置されたオブジェクトはそのオブジェクトが所属する親オブジェクトを一つだけ持っているという実態に即したものだ.下位オブジェクトへのポインタを格納するスロットにはオブジェクトへのリンクが格納されている.これは接続の場合も参照の場合も同じ.異なるのは子オブジェクトには親オブジェクトへのリンクがあるという点だけだ.「ルート以外のすべての節点が親節点を一つだけ持つ閉路を持たない有向グラフは木になる」のでこの図面は階層的な木を構成する.

スロットに格納されるリンクには二つの場合がある.単体のオブジェクトを参照する場合と,リストのようなオブジェクトの複合体を参照する場合だ.これを図示できないと全体の構図を把握することができないので何らかの工夫が必要になる.ここでは名前の後ろに※を付けることで「集合オブジェクト(一般にはリスト,つまり単純な順序集合)」であることを示すようにしてみよう.また,複数のスロットを使って複数の「集合オブジェクト」を操作しているような場合には,その機能を日本語で表示するノードを説明的に挿入するということにする.

また,ゼルコバの木では性別をカラー表示できるので要素オブジェクトを男性,要素クラスを女性としておこう.要素クラス(基本クラス)はオブジェクトの中に実体があるので実子関係になるものと思われる.しかし,この図面ではたとえばnoduleクラスというのは基本クラスとしてどこにでも出てくるのでそれを同一ノードとみなしたときにはゼルコバの木はそれを強引に描画しようとして相当無理な図面になってしまうことが考えられるので,とりあえず,同一名の別オブジェクトとして登録しておくことにする.

▲kakeizuの子どもにnoduleを入力して登録→すでにcouplingの子どもとしてnoduleを登録してあるので2つのnoduleを同一ノードとして図示→kakeizuの子ども欄でnoduleをnodule1にリネームして登録で下のパネルが出た.

image

このパネルを複数回出したあと正常動作に戻ったが,noduleはフロート状態になり,couplingは子どもを失った状態になった.この後couplingの子どもにnodule(女性)を追加して登録では新たなカードが生成された.本来ならフロート状態のnoduleとリンクされなくてはならないところだが,kakeizuの子ども欄はイエローになっていた.これは複数の候補があることを示すものだが,状況からしておかしい.UNDOで戻ってもう一度確認してみよう.ヒントには

image

とあるが,半ば意味不明だ.これは,氏名入力欄に名前を入力したときの同定カード探索では「あいまい検索」していることが原因だ.ダブルクリックするとカード巡回パネルが出て子ども氏名欄はショッキングピンクに変わる.これで確定選択ボタンを押せば,このカードが登録されるということになるので操作的にはこれでよいと思われる.

image

ヒントの「ダブルクリックして子どものカードに移動」はよいとして,次の「未入力の場合は新規カードを作成」は意味不明だ.確かに子ども氏名欄が未入力の場合はダブルクリックで新規カードを作成するという動作になっているが,記入されている氏名欄の上で出されるヒントとしては不適切だ.⇒いくつか改善項目が考えられる.①あいまい氏名(イエロー表示)が残っている場合には登録時に注意を促すプロンプトを表示すべきではないか?できるだけパネルの表示頻度を減らしたいという意図と思われるが…②ヒントの用語はですます調の方がよい.

言い切りだとコマンドのように聞こえる.たとえば,「子どもの名前を入力して既存カードにリンク」ではユーザはどこからどこまで自分でやればよいのか分からない.「子どもの名前を入力して既存カードにリンクします」なら,(ここでは)操作の主たる目的が「既存カードにリンクすること」だということが(何となく)わかる.このヒントは「一般の場合」のヒントで氏名入力中のヒントにはなっていない.氏名欄の状態によって表示内容を変える方が望ましい.色については①のプロンプトで説明できるかもしれないが…

couplingにnoduleを再登録するときも子ども欄はイエローになったが,ダブルクリックして確定選択でフロート状態のカードにリンクできた.

▲マルチスクリーンで作業しているとき,削除パネルなどが別のモニターに出るのはよくない.現在のスクリーンに表示すべきだ.⇒コマンドを受け付けたウィンドウがどのスクリーンにあるかを特定する必要がある.ただし,パネルは前回表示した場所に開くという原則もある.

考えてみるとゼルコバの木のオブジェクトはすべてnoduleの派生クラスなので個別にnoduleを子どもとして持たせる必要はないのではないか?その方が図面もわかり易い.ほとんどのクラスはnoduleから直接派生している.noduleの孫クラスというのはかなり少ないと思う.Bobjectはその一つだが,何か他にあるだろうか?BASETABLEにはCARDTABLEとMARGTABLEという2つの派生クラスがある.Bobjectの派生クラスはNAMEBOXを初めとしていろいろある.

▲PARTIALMAPがクラス名とCARDCOMMANDのコマンド識別子として使われているが避けた方がよい.⇒いや,間違えた.クラス名はPARTIALNAMEだ.⇒単なるミスタイプと思われる.

▲人名カードでテキストボックスをダブルクリックしてテキストを全選択状態にしようとして戻ってしまう.

あるオブジェクトの基本クラスをそのオブジェクトの下位要素として配置するのはよいとしても,同じクラスに属する複数のオブジェクトが存在する場合にはどこかにクラスの代表ノードが存在しないとあまりに冗長になってしまう.これを避けるため,所属クラスを配偶者ノードとして表示することを考えてみる.これが通用すればクラスノードは一箇所に一度だけ出現するので図面をかなりコンパクトにできる.

たとえば,クラスSIMPLEGRAPHにはnodelist, edgelist, complistの子どもがあり,子どものいない配偶者としてgraph1, graph2, graph3, tajugraph1, tajugraph2, tajugraph3, tempgraph, copygraph, keisengraphがあるという具合だ.子どもたちは単身婚のこどもとしてクラスノードの直下に配置する.⇒いや,これもあまり素敵とは言えない.むしろそのオブジェクトの下に配置した方がましな気がする.複数のオブジェクトと養子縁組すればよいのではないか?

ゼルコバの木では循環が発生するような矛盾した直系血族間の結婚を配偶者同定探索対象からあらかじめ弾いているようで,graph1の配偶者SIMPLEGRAPHをカットして,子ども欄に貼り付けてもボックスはグリーンにならず,登録で新しいカードを生成する.

▲複数のグラフオブジェクトの配偶者SIMPLEGRAPHを子どもに移す付け替えをやっていて下記のエラーになった.tajugraph2の操作を行っているところでエラーが起きた.

image

UNDOで戻したものを反例サンプル(ERR2)として保全しておく.⇒残念ながら再現しない.いや,次のtajugraph3で出た.前回出なかったのは女性→男性に変更していなかったためと思われる.⇒ひなアイコンをクリックしたタイミングでパネルが出ている.登録は実行できる.

▲SIMPLEGRAHPHの父母ページで4ページ目に移動するとエラーパネルが出る.登録ページ数は4.

image

このサンプルを(ERR3)で保存しておく.SIMPLEGRAPHは親を8人持ち,そのすべてを上の操作で登録したつもりだったが,4人しか入っていない.⇒4ページ目で出るのではなく,4ページのあとの空白ページに移動しようとしてエラーになっている.父母ページ数の上限が4になっていたのだろうか?確かに4になっている.MAXPARENTS=8に変更してビルドしたものを再インストールしてみる.

▲リリース版をビルドしたが,OCXが認識されない.VB→参照の追加で該当バージョンのOCXへの参照を追加しようとすると,

image

のようなパネルが出る.VB→プロパティ→参照にはOCXは何も登録されていない.ツールボックスには残っていた.ツールボックスに残っているOCXを削除し,ツール→ツールボックスアイテムの選択からOCXを選択しOKでも同様のエラー↓になる.

image

他に参照を操作できる場所は存在しない…今度はツールボックスへの追加で以下のようなエラーになった.

image

どうも何かが決定的にこじれてしまったような感じがする.もはやこうなったら,Visual Studioを再インストールするか,Windows 10を再インストールするか,あるいは,モジュール名をすべて付け替えるか?の三択しかないような気がする.なぜこんなことになってしまうのか?まったく理解に苦しむ.昨日まではVSを2つ立ち上げてそれぞれを個別に同時実行できていたのが,急に一つも動かなくなるというのはどういうことなのか?誰か説明してほしい…リリース版はともかくデバッグ版まで走らないというのは考え難い.⇒バックアップに戻ってビルドし直した.ビルドは通ったが,実行時エラーになった.

image

HRESULT = 0x80040111は前にも出たことがあると思うが,どう対処したのだろう?クリーンビルドしたら却って悪化した.ビルドが通らなくなってしまった.多分このあとは同じだろう.デバッグモードでビルドできないのだから,セットアップの問題ではない.OCXの参照の問題であることは確かだが,何が障壁になっているのかその辺りの見当がつかない.テスト版に切り替えて動作を見てみよう.⇒ダメだ!再開始スタート版の前まで戻ってみたが状況はまったく変わらない.このようなときには大概奥の手が効いたものだが,それが効かないというのが致命的だ.もやは打つ手なしという感じになっている.

リリース版のOCXをregsvr32で登録しようとしてみたが,下記エラーになった.HRESULT = 0x80040200

image

レジストリが壊れているとしたらWindowsを再インストールするしかないかもしれない…regsvr32でレジストリの登録解除ができる.Zelkova for Test 2.0をアンインストールするためZelkovaForTestから/uを実行してみたが,HRESULT=0x80040201エラーになった.regsvr32 /uを実行するには管理者権限が必要だが,管理者権限で実行してもまだエラーになる.

image

打ち間違えていないはずなのだが,ZELKOVAとZELKOVAFORTESTの両方で実行してみたがどちらも効かなかった.どちらもdebugフォルダにはOCXが生成されている.CCleanerを導入してレジストリのクリーンアップもやってみたが効果はなかった.VB→プロジェクト→参照の追加→COMではZelkovaZ3.ocxが3つレジストリ登録された状態になっている.Zelkova For Test 2.1, 2.2, 3.0だ.⇒ようやく一つ消せた.あとは3.0を消すだけだ.PowerShellを使い,C:\Windows\Syswow64に移動してregsvr32を実行して成功できた.これもうまく行った.

OCXがレジストリ登録時と同じフォルダにあることが必須条件であるのかないのかは分からないが,念のため登録時のバイナリがある場所で登録解除した.あれ,おかしい.まだゼルコバの系図エンジン for TEST 2.1というのが残っている.消したつもりだったが…⇒失敗した.テスト版を作っている.今度はうまくゆくと思ったが,まだ参照追加できない.⇒パワーシェルからレジストリ登録して成功しているのに参照追加できない.どうも完全にいかれてしまったようだ.こうなると最後の手段としてはモジュール名の付け替えしかないように思われる.

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA