伝説のツール「NotesPeek」をQtでリメイク開発記2017-7-30
前回はリッチテキストに対して切り込みましたが、今回は設計要素(設計文書)に対して切り込みを入れます。
Notesの設計要素は、広義では「文書(Note)」に当たります。もし、データとしての「文書」と分けるのであれば、「Document」がNotesで一般的に使われる文書に当たります。設計要素もデータ文書も、保存形式としては「Note」という単位で保存されるんですね。これが「Notes」という名前の所以なのかもしれません。
では、API的にはどのように設計要素を区別するのでしょうか。
文書(Note)には「文書クラス」というパラメータがあります。一般的なものを列挙してみます。
シグネチャ | 値 | 意味 |
---|---|---|
NOTE_CLASS_DOCUMENT | 0x0001 | データ文書/ドキュメント |
NOTE_CLASS_INFO | 0x0002 | データベースについて |
NOTE_CLASS_FORM | 0x0004 | フォーム |
NOTE_CLASS_VIEW | 0x0008 | ビュー |
NOTE_CLASS_ICON | 0x0010 | アイコン |
NOTE_CLASS_DESIGN | 0x0020 | 設計文書を含む内部ビュー |
NOTE_CLASS_ACL | 0x0040 | アクセス制御リスト |
NOTE_CLASS_HELP_INDEX | 0x0080 | Notesクライアントのヘルプのインデックス |
NOTE_CLASS_HELP | 0x0100 | データベースの使い方 |
NOTE_CLASS_FILTER | 0x0200 | エージェント |
NOTE_CLASS_FIELD | 0x0400 | 共有フィールド |
NOTE_CLASS_REPLFORMULA | 0x0800 | 複製式 |
「設計文書を含む内部ビュー」?「ヘルプのインデックス」?さらりと書きましたが、今ひとつピンときません。愛読書Notes/Domino APIプログラミング―C++とSTLによる実践的プログラミングでも、このあたりを特別掘り下げているわけではないようです。今回は遺憾ながらその点についてはスルーします。
さて、設計要素のフォームやビューは、確かに文書クラスによってドキュメントとは区別されているのは分かりました。しかし、設計要素はこれだけだったでしょうか。サブフォームは?フレームセットは?フォルダは?共有アクションは?XPagesは?
安心して下さい。あります。
ただ、このようないわゆる「後発の」設計要素は文書クラスではなく、フラグ($Flagsアイテム)によって区別されます。フラグは単なる文字列で、サブフォームは'U'という文字で識別します。シグネチャとしては「DESIGN_FLAG_SUBFORM」として定義されています。後付けのゴチャゴチャ感は否めませんが、とにもかくも、文書クラスでざっくり分けたあとに、フラグで詳しく設計文書を識別する必要があります。サブフォームの場合は「フォームクラス」の「サブフォームフラグを含む」設計文書を見つければいいということになります。
それでは、今回の開発進捗の報告です。
今回は、設計要素、特にフォームを中心に設計要素を見られるようにしてみました。
「Form Elements」というカテゴリを展開すると、文書クラスがフォームである設計文書を見ることができます。この画像ではメールデータベースを見ていますが、GIF画像だらけですね。GIF画像も文書クラスではフォームに分類されるということになります。その下にはXML文書も確認できますが、これは「ファイル」というくくりの設計文書になっていると思います。
メールフォームのアイテムを展開して見てみます。これはドキュメントではなくフォームの設計文書なので、「$SubForm_RepIDs」のような見慣れないアイテムも存在します。これはきっとサブフォーム用の何かでしょう。
さらに、「$Body」というコンポジットアイテム、いわゆるリッチテキストを見てみます。これは、フォームの中身の設計を表していて、ドキュメントのリッチテキストではお目にかかれない、フィールド用のデータ(EXT2_FIELD)も見ることができています。