伝説のツール「NotesPeek」をQtでリメイクする(その5・@式その2)
少し時間が空いたので、前回のおさらいをしておきます。
- @式(または@関数)はR4以前からある操作言語である。
- フォームは文書(Document)設計用の文書(Note)である。
- ウィンドウタイトルは、フォーム専用のフィールドである。
- @式は文字列として書かれ、バイナリとして保存される。
おおざっぱに言えば、このような感じです。
今回のリメイクツールでは、データベースのツリーアイテムを展開すると、すべての文書(Document)を取得して子アイテムとしてデータベースアイテムにぶら下がります。そして、各文書アイテムでは、NotesPeekのように、ウィンドウタイトルを表示させることにします。
ちなみに、NotesPeekではこのように文書(Document)を表示しています。
もし表示されない場合は、メニュー「View−Options」としてこのダイアログを表示し、左ペインで「Notes」を選択し、右ペインで「Title」にチェックを付けると出てきます。
この「Title」として表示されるのが「ウィンドウタイトル」になります。
前回も触れましたが、このウィンドウタイトルを取得するまでの手順もおさらいします。
- 文書(Document)を取得する。
- その文書の「Form」フィールドのテキスト値(フォーム名)を取得する。
- フォーム名に該当するフォーム(設計文書)を取得する。
- フォームの「ウィンドウタイトル」フィールドの値(＝@式、バイナリ形式)を取得する。
- 文書(Document)を引数にして、ウィンドウタイトル式を評価(Evaluate)する。
それでは、順に関連するAPIを紹介していきます。文書の取得、テキスト値の取得は既出なので省略します。
それでは最初にフォーム文書(フォームNote)の取得です。フォームを含む設計文書の取得には、NIFFindDesignNoteを使用します。
#include <nif.h> STATUS LNPUBLIC NIFFindDesignNote (DBHANDLE hFile, const char far *Name, WORD Class, NOTEID far *retNoteID);
hFileにデータベースハンドル、Nameに設計要素名、Classに文書クラスを与え、、retNoteIDに該当する設計要素文書のNoteIDが返ってきます。
次に、文書から@式を含む任意のフィールド値を取り出すには、NSFItemInfo関数を使います。
#include <nsfnote.h>
STATUS LNPUBLIC NSFItemInfo (
NOTEHANDLE hNote
, const char far *Name
, WORD NameLength
, BLOCKID far *retbhItem
, WORD far *retDataType
, BLOCKID far *retbhValue
, DWORD far *retValueLength);
入力値として、hNoteに文書(Note)ハンドル、Nameにフィールド名、NameLengthにフィールド名の長さを指定します。
出力値としては、retbhItemにアイテム用のブロックID、retDataTypeにアイテムの型、retbhValueにアイテム値用のブロックID、retValueLengthにその長さが設定されます。
BLOCKIDとは、端的に言えば、文書内に格納されたデータへのハンドルです。@式の場合、アイテム値用のブロックIDをロックして、@式のバイナリデータを取得できます。ロックにはOSLockBlock、アンロックにはOSUnlockBlockを使います。
#include <pool.h> #define OSLockBlock(type,blockid) ((type far *)(OSLock(char,(blockid).pool) + (blockid).block)) #define OSUnlockBlock(blockid) OSUnlockObject((blockid).pool)
取得したバイナリデータは、自前で用意したメモリに格納しておきます。自前でメモリを用意するにはOSMemAlloc、用意したメモリを解放するにはOSMemFreeを使います。メモリはハンドル形式なので、メモリ内を使う場合はブロックID同様ロックして使いますが、微妙に仕様が異なります。
#include <osmem.h> STATUS LNPUBLIC OSMemAlloc (WORD BlkType, DWORD dwSize, DHANDLE far *retHandle); STATUS LNPUBLIC OSMemFree (DHANDLE Handle); void far * LNPUBLIC OSLockObject (DHANDLE Handle); #define OSLock(blocktype,handle) ((blocktype far *) OSLockObject(handle)) #define OSUnlock(handle) OSUnlockObject(handle) BOOL LNPUBLIC OSUnlockObject (DHANDLE Handle);
次回は@式に関するAPIを説明します。
伝説のツール「NotesPeek」をQtでリメイクする(その5・@式その1)
@式、または@関数は、NotesがR4でLotusScriptを実装するまで、唯一の操作言語でした。@式はあらゆるところで使えます。フィールドの計算式、列式、UI操作(@Command)、Webの時代が来ても、CGIのような使い方ができたりしました。そんな@式は、API側から見るとどのようになっているのでしょう。NotesPeekリメイクプロジェクトにおいて、最初に出会うのはフォームのウィンドウタイトルになるので、これを中心に@式を見ていきます。
フォームは、文書です。
役割を省くと、フォームは文書(Note)に分類されます。データを保存するのか、文書のための設計要素を保存するかで、Noteは文書かフォームかに分けられます。Noteには「クラス」という属性値があり、文書はNOTE_CLASS_DOCUMENT、フォームはNOTE_CLASS_FORMとなります。厳密に言えば、NOTE_CLASS_FORMはフォーム以外の設計要素にも用いられています。初期のNotesはそれほど設計要素を持っていませんでしたが、バージョンを重ねていろいろな要望を取り入れる中で、クラスとしてはフォームでも、ある属性値を持って細分化されていきました。細分化された設計要素については、後日説明する機会があると思います。
ウィンドウタイトルは、フィールドです。
Note上に格納されるあらゆるものが、属性を除けばフィールドということになります。ウィンドウタイトルは、フォームというNote専用のフィールドになります。フィールドにもいろいろなタイプがあります。テキスト、数値、日時、リッチテキストなどがそうです。ウィンドウタイトルは何タイプなのか。これは「@式」型になります。Domino Designerを使って普通にフォームを作成する分には作ることのできないフィールド型です。
@式は、バイナリです。
@式は、バイナリになります。テキストとしての@式(文字列型)は、コンパイルすることでバイナリの@式になります。逆にバイナリの@式をデコンパイルするとテキストの@式が得られます。@式を評価する(@式を計算して値を得る)場合は、バイナリの@式から計算ハンドルというものを取得して、計算をさせます。通常、@式は文書をベースに計算します。フィールドの計算結果や、ビューの列式も、原則文書単位で計算されます。
話をウィンドウタイトルに戻します。フォームのウィンドウタイトルは、文字通り現在開いている文書情報を元に、ウィンドウやタブのタイトルとして表示するための@式です。フォームNoteの中には、フィールド名「$WindowTitle」の@式型(コンパイル済みのバイナリ)として格納されます。
なお、本プロジェクトでは、コンパイル済みの@式を使うので、当面はコンパイル(テキストからバイナリ)のプロセスは含めずに進めていきます。 (@式その2に続く)
伝説のツール「NotesPeek」をQtでリメイクする(その4・IDテーブル)
IDテーブル
IDテーブルは、Notesにおける文書のためのコンテナの役割を持っています。Notes/Domino APIプログラミング―C++とSTLによる実践的プログラミングでも書かれていますが、
文書IDテーブルとは、文書ID(NOTEID)を昇順で保持するコンテナで、std::set
とほぼ同じ機能を提供します。
と、あります。もともとAPIはC用に作られているので、C++のコンテナをそのまま使うわけにはいきません。CのみであればこのIDテーブルを使えばいいわけです。またC++であればstd::set
まず、IDテーブルクラスの実装を紹介する前に、ここで扱うIDテーブル関連のAPIを紹介します。
IDテーブルは、IDCreateTable関数によって生成し、IDDestroyTable関数によって破棄します(例外もあります)。生成されたIDテーブルはDHANDLEにて管理します。
#include <idtable.h> STATUS LNPUBLIC IDCreateTable (DWORD Alignment, DHANDLE far *rethTable); STATUS LNPUBLIC IDDestroyTable(DHANDLE hTable);
ここで、Alignmentはsizeof(NOTEID)を渡すことになります。
IDテーブルにIDを追加するには、IDInsert関数を使います。
#include <idtable.h> STATUS LNPUBLIC IDInsert (DHANDLE hTable, DWORD id, BOOL far *retfInserted);
戻り値はいつものステータス値ですが、IDが挿入できたかどうかは3番目の引数、retfInsertedを見ます。これは、IDがすでにIDテーブル内に存在していればfalseを返します。必要なければnullptrを与えておきます。
テーブル内のIDは通常IDDeleteかIDDeleteAllを使って削除しますが、その実装は後日とします。また、Noteクラスとの連携に唯一getNoteメソッドを実装していますが、これも後日説明します。
それでは、僕流のIDTableクラスと、IDTable::iteratorクラスです。
// ntlx/idtable.h
#ifndef NTLX_IDTABLE_H
#define NTLX_IDTABLE_H
#include "ntlx_global.h"
#include "ntlx/status.h"
#if defined(NT)
#pragma pack(push, 1)
#endif
#include <nsfdata.h>
#if defined(NT)
#pragma pack(pop)
#endif
namespace ntlx
{
class Database;
class Note;
/**
* @brief IDテーブルクラス
*/
class NTLXSHARED_EXPORT IDTable
: public IStatus
{
public:
/**
* @brief イテレータインナークラス
*/
class NTLXSHARED_EXPORT iterator
{
public:
/**
* @brief デフォルトコンストラクタ
*/
iterator();
/**
* @brief NOTEIDを返す演算子
* @return NOTEID
*/
NOTEID operator*();
/**
* @brief 前置きインクリメント演算子
* @return 自身への参照
*/
iterator& operator++();
/**
* @brief 後置きインクリメント演算子
* @return インクリメントする前のイテレータ
*/
iterator operator++(int);
/**
* @brief NOTEIDに対応したNoteオブジェクトを取得する
* @param db 取得元になるデータベースオブジェクト
* @return Noteオブジェクト
*/
Note getNote(Database& db) const;
protected:
/**
* @brief コンストラクタ
* @param pIdTable IDTableオブジェクトへのポインタ
* @param noteId NOTEID
* @param isLast 最後を示しているか
*/
iterator(IDTable* pIdTable, NOTEID noteId, bool isLast = false);
IDTable* idTable_;
NOTEID id_;
bool isLast_;
/**
* @brief 等値演算子
* @param lhs 左辺値
* @param rhs 右辺値
* @return ブール値
*/
friend NTLXSHARED_EXPORT bool operator==(
const iterator& lhs
, const iterator& rhs
);
/**
* @brief 不等値演算子
* @param lhs 左辺値
* @param rhs 右辺値
* @return ブール値
*/
friend NTLXSHARED_EXPORT bool operator!=(
const iterator& lhs
, const iterator& rhs
);
friend class IDTable;
};
/**
* @brief コンストラクタ
*/
IDTable();
/**
* @brief デストラクタ
*/
virtual ~IDTable();
/**
* @brief 最初のイテレータを返す
* @return 最初のイテレータ
*/
iterator begin();
/**
* @brief 最後のイテレータを返す
* @return 最後のイテレータ
*/
iterator end();
/**
* @brief NOTEIDを挿入する
* @param id NOTEID
* @return 重複していなければ真
*/
bool insert(NOTEID id);
private:
DHANDLE handle_;
friend class iterator;
};
} // namespace ntlx
#endif // IDTABLE_H
// idtable.cpp
#include "ntlx/idtable.h"
#include "ntlx/note.h"
#if defined(NT)
#pragma pack(push, 1)
#endif
#include <idtable.h>
#if defined(NT)
#pragma pack(pop)
#endif
namespace ntlx
{
IDTable::iterator::iterator()
: idTable_(nullptr)
, id_(0)
, isLast_(false)
{
}
NOTEID IDTable::iterator::operator *()
{
return id_;
}
IDTable::iterator& IDTable::iterator::operator++()
{
isLast_ = !IDScan(idTable_->handle_, id_ == 0, &id_);
return *this;
}
IDTable::iterator IDTable::iterator::operator++(int)
{
iterator it = *this;
operator++();
return it;
}
Note IDTable::iterator::getNote(Database &db) const
{
return Note(db, id_);
}
IDTable::iterator::iterator(IDTable *pIdTable, NOTEID noteId, bool isLast)
: idTable_(pIdTable)
, id_(noteId)
, isLast_(isLast)
{
}
bool operator==(const IDTable::iterator& lhs, const IDTable::iterator& rhs)
{
if (lhs.isLast_ && rhs.isLast_)
return true;
else
return lhs.id_ == rhs.id_;
}
bool operator!=(const IDTable::iterator& lhs, const IDTable::iterator& rhs)
{
return !operator==(lhs, rhs);
}
IDTable::IDTable()
: IStatus()
, handle_(NULLHANDLE)
{
lastStatus_ = IDCreateTable(sizeof(NOTEID), &handle_);
}
IDTable::~IDTable()
{
if (handle_)
IDDestroyTable(handle_);
}
IDTable::iterator IDTable::begin()
{
if (handle_ == NULLHANDLE)
return end();
return ++iterator(this, 0);
}
IDTable::iterator IDTable::end()
{
return iterator(this, 0, true);
}
bool IDTable::insert(NOTEID id)
{
Q_ASSERT(handle_);
BOOL b = false;
lastStatus_ = IDInsert(handle_, id, &b);
return b;
}
} // namespace ntlx
Domino Web Server APIで自作Web APIは作ることはできるのか？プロローグ
Domino Web Server API、略してDSAPI。いわゆるHTTPタスクのアドインです。HTTPタスクに介入できるようになったのは、R5からだったと記憶しています。
昔からDSAPIで標準提供されているものに、Domino Offline Service(DOLS)がありますし、DSAPIではないですが、iNotesやXPagesなどもDSAPIを起点にしてHTTPタスクに統合されていったのではないかと勝手に想像しています。
Domino Data Service(DDS)は、DominoサーバをREST/WebAPI化する強力なサービスで、ググると8.5.3 SP1からの提供であるようですが、これ以前に、自前でRESTサービスをDominoに組み込めないか、よく思案したものです。
DDSはJSONでレスポンスを返すので、Node.jsやJavaScriptフロントエンドなどと相性もよく、標準のデータベースアクセスのほかにカレンダーに特化したものもあり、機能的にはそんなに遜色ない出来だと思っています。
でも、使い込んでくると欲が出てくるもので、「ああ！こんな機能があったらいいのに！！！」と思ったことは一度や二度ではなかったですね。
そんなわけで、これまた昔からの小さな夢を、実現してみようかと思い立ち、自作Web APIを作ってみることにしました。今回はそのプロローグ、Hello,Worldです。
OSとDominoはWindows、ライブラリはVS2013 32bitとQt5.6、Dominoは9.0.1です。VSモジュール(msvcr120.dll、msvcp120.dll)とQtCoreのDLLを、パスで解決できる場所に置きます。DSAPIを使ったアドインDLLは、他のアドインと違って序数1によるエキスポートは不要ですが、Cリンケージ(extern “C”)にしておく必要があります。
DSAPIは、関数やシンボルなどを「FilterXXXX」と命名しているように、基本的にHTTP処理のフィルタリングを主目的としているようです。処理できる段階は、リクエストの受付時からレスポンスの返しまでの一般的なものから、認証処理時、名前リスト構築時など、認証機能を備えたDominoならではのタイミングもあります。今回は、認証済みのタイミング(kFilterAuthorized)を使ってみました。
Webブラウザなどから、http://domino.server/csapi/とたたくと、Hello～とプレーンテキストで返すだけの単純なサンプルは、以下の通りです。
main.cpp
#include <QByteArray>
#pragma pack(push, 1)
#include <global.h>
#include <dsapi.h>
#include <addin.h>
#pragma pack(pop)
extern "C"
__declspec(dllexport) uint FilterInit(FilterInitData* pInitData)
{
pInitData->appFilterVersion = kInterfaceVersion;
pInitData->eventFlags = kFilterAuthorized;
strcpy(pInitData->filterDesc, "Chiburu Systems API");
AddInLogMessageText("Chiburu Systems API Started.", NOERROR);
return kFilterHandledEvent;
}
extern "C"
__declspec(dllexport) uint HttpFilterProc(
FilterContext* ctx
, uint eventType
, void* /*ptr*/
)
{
uint errID;
switch (eventType)
{
case kFilterAuthorized:
{
FilterRequest request;
ctx->GetRequest(ctx, &request, &errID);
QByteArray url(request.URL);
if (url.startsWith("/csapi/") && request.method == kRequestGET)
{
QByteArray buffer(request.version);
buffer += " 200 OK\r\n";
buffer += "Content-Type: text/plain\r\n";
buffer += "\r\n";
buffer += "Hello, Chiburu Systems Web API!\r\n";
ctx->WriteClient(ctx, buffer.data(), buffer.size(), 0, &errID);
return kFilterHandledEvent;
}
}
break;
}
return kFilterNotHandled;
}
訂正(2017/4/10)
誤：Domino Server API => 正：Domino Web Server API 誤：\n => 正：\r\n
IBM Notes C APIのMacにおけるDWORD問題
現在、このブログでQtによるNotesPeekリメイクプロジェクトを進めていますが、ここで今日、問題が発生しました。
Notesデータベースから文書を取得する際にNSFSearch関数を使用し、NOTEID型を取得しようとしました。
Windows、Linux(Ubuntu)では問題は出ませんでしたが、Mac環境において、正確にNOTEIDが取得できませんでした。
NOTEIDはDWORD型です。APIにおいてDWORDは、32bit幅の符号なし整数になります。この定義は、APIのglobal.hヘッダーファイルに含まれています。
Win32やUNIX(LINUX)においては問題が発生していません(Domino Serverを対象にしたWin64の場合は検証できていません)。
しかし、Macのコンパイラにおいて、他のOSと違ってDWORDの幅が異なりました。
APIに掲載されているオプションもいろいろ試しましたが、今のところ、解決できた追加オプションは以下の通りです。
DEFINES += LONGIS64BIT
何かわかり次第、補足したいと思います。
伝説のツール「NotesPeek」をQtでリメイクする(その3・その2の補足)
ここでは、その2で紹介したコードについて、ファイル検索以外の点について補足します。
ntlxライブラリ
QString Status::toMessage()
StatusクラスにtoMessageメソッドを追加しました。以前は、
QString msg = Lmbcs(status).toQString();
としていましたが、
QString msg = status.toMessage();
と、Status単独でステータス値からメッセージを取得することができます。
IStatusクラス
メソッドとしては値を返り値にしたいが、関数が処理したステータスも重要な場合、いちいち引数にStatusのポインタを置くのも面倒です。そんな時、クラスにこのインターフェースクラスを多重継承します。メソッド内部で取得したステータスをメンバ変数lastStatus_に預けることで、メソッドから戻ってきてもステータス値を失うことなく処理を継続できます。
initEx関数、term関数
NotesInitExtended関数、NotesTerm関数のラッパー関数です。
PathSetクラス、NetPathクラス
Notesデータベースへのパスに使用するクラスです。PathSetは、パス、サーバ名、ポート名を一度に扱えるクラスです。NetPathはLmbcsクラスを継承して、Notes状のフルパスである「ネットパス」に対応しています。Databaseクラスを使って、データベースをオープンする場合、次のように書けます。
Database db1(PathSet("names.nsf", "Server1")); // PathSet使用
Database db2(PathSet("names.nsf", "Server2").toNetPath()); // NetPathに変換してもOK
PathSetからNetPathへはPathSet::toNetPathを使用しますが、NetPathからPathSetにする場合はNetPath::toPathSetを使うことができます。
DbInfoクラス
データベースのタイトルやカテゴリを取得する場合、Lmbcsから継承したDbInfoクラスを使用します。データベース情報はタイトル、カテゴリ、DBクラス、設計元DBクラスの4つの情報を有していますが、実体は128バイトしかないLMBCS文字列です。そこで、この文字列をDbInfo内に置き、メソッドによってタイトルなどの各情報を取得することができるようにしました。以前はDatabaseクラスに組み込まれていましたが、NSFSearch関数によって取得したサマリーバッファでも、データベース情報のパースが必要になることがわかったので、Databaseクラスから切り離し、DbInfoクラスとして独立させることにしました。
伝説のツール「NotesPeek」をQtでリメイクする(その2・ファイルの取得)
ではNotesPeekリメイク版、最初のミッションです。
最初の目標は、「ローカルのデータディレクトリから直下のファイルを取得」します。
Notes APIで、データベースの一覧を取得する関数は、NSFSearch関数です。
#include <nsfsearc.h>
STATUS LNPUBLIC NSFSearch (
DBHANDLE hDB,
FORMULAHANDLE hFormula,
char far *ViewTitle,
WORD SearchFlags,
WORD NoteClassMask,
TIMEDATE far *Since,
NSFSEARCHPROC EnumRoutine,
void far *EnumRoutineParameter,
TIMEDATE far *retUntil
);
NSFSearchは、この引数のネーミング通りに受け止めれば、文書検索が目的の関数です。しかし、ファイルリストを取得するのにも利用します。ディレクトリに対してDBHANDLEを取得することができ、NoteClassMaskにFILE_xxxを適用すると、目的がファイル検索になるという、不思議な関数です。
このNSFSearch関数を利用するには、DBHANDLEを取得しておかなければなりません。通常、データベースへのネットパス(ポート名、サーバ名、ファイルパスを組み合わせたNotesの世界のフルパス)を元に、データベースハンドルを取得しますが、ディレクトリへのネットパスでNSFDbOpen関数を使うと、ディレクトリに対するデータベースハンドルを取得することができます。
#include <nsfdb.h> STATUS LNPUBLIC NSFDbOpen (const char far *PathName, DBHANDLE far *rethDB);
もちろん、ディレクトリに対してデータベース操作はできません。データベースハンドルが、データベースのものか、ディレクトリのものか、判別する関数があります。
#include <nsfdb.h> STATUS LNPUBLIC NSFDbModeGet (DBHANDLE hDB, USHORT far *retMode);
このNSFDbModeGet関数に、ハンドルとUSHORT変数へのポインタを渡すと、DB_LOADED(データベース)か、DB_DIRECTORY(ディレクトリ)かを返してくれます。
NSFSearch関数に話を戻しましょう。
2番目の引数FORMULAHANDLEは、コンパイル済み@関数の選択式へのハンドルですが、ファイル検索では使用しないので、NULLHANDLEを渡します。3番目の引数ViewNameは、前述の選択式内に@ViewTitleを使っている場合、ビューの名前を指定する必要があります。これもファイル検索では使わないので、nullptrを渡します。
4番目のSearchFlagsは、検索フラグを指定します。ここでSEARCH_FILETYPEというフラグを立てておくと、検索対象がDB中の文書から、ディレクトリ中のファイルに変わります。続く5番目のNoteClassMask(文書クラスのマスク)が、FILE_xxx(ファイル用マスク)の意味に変わります。
4番目のSearchFlagsではもう1つ、SEARCH_SUMMARYというフラグを立てておきます。これを立てておくと、サマリーバッファというデータにアクセスすることが可能になります。サマリーバッファについては、今回説明は割愛しますが、簡単に言うと「文書を開かなくても読み取り可能なデータ群」のことで、ファイル検索時には、データベースファイルに関する情報は、このサマリーバッファから取得することになります。
5番目のNoteClassMaskには、前述の通りFILE_xxxで定義されているファイル用のマスクを使って、取得したいファイルの種類を指定します。通常、FILE_DBANY(NSFファイル)、FILE_FTANY(NTFテンプレートファイル)を使いますが、他にもいくつか定義されています。また、上位8ビットがフラグビットになっていて、FILE_DIRS(ディレクトリ名も取得)、FILE_RECURSE(サブディレクトリも検索)などを組み合わせることもできます。ちなみに、下位8ビットはフラグビット状にはなっていません(0から順に取得できるファイルの種類が決められている)。
6番目のSinceは、この日時以降の文書を検索対象とするもので、ファイル検索には使用しないので、NULLを指定します。
7番目の関数ポインタは、検索対象が見つかるたびに呼び出されるコールバック関数です。形式は以下の通りです。
#include <nsfsearc.h>
typedef STATUS (LNCALLBACKPTR NSFSEARCHPROC)(
void far *EnumRoutineParameter,
SEARCH_MATCH far *SearchMatch,
ITEM_TABLE far *SummaryBuffer);
最初の引数は汎用ポインタで、検索対象のデータを格納するためのコンテナ変数へのポインタを渡すのに使用します。2番目はSEARCH_MATCH構造体へのポインタです。文書IDや文書クラス、文書の権限などの情報が含まれます。また、選択式にマッチしているかどうかを判定するのに使うメンバSERetFlagsもあります。通常、ファイル検索では使用しません。最後がサマリーバッファへのポインタです。
いったん、NSFSearch関数に話を戻します。8番目のEnumRoutineParameterは、さきほどのコールバック関数の最初の引数に渡される汎用ポインタです。9番目の引数は、検索の終了日時が返されます。次にNSFSearch関数を呼び出す時に、Sinceにこの日時を指定することで、検索対象の日時を重複させず、前回以降に追加修正があった文書だけを対象にすることができます。もちろん、ファイル検索には使用しないので、NULLを指定します。
さて、最後にサマリーバッファについて、ファイル検索時に必要な、最低限のポイントに触れておきます。
サマリーバッファは、コールバック関数に渡されるSummaryBuffer(ITEM_TABLEへのポインタ)を使ってアクセスします。ポインタ構造としては、以下のようになっています(例はアイテムが3つの場合)。
| ITEM_TABLE | ITEM | ITEM | ITEM | NAME | VALUE | NAME | VALUE | NAME | VALUE |
|---|---|---|---|---|---|---|---|---|---|
| ITEM_TABLE | 1 | 2 | 3 | 1 | 1 | 2 | 2 | 3 | 3 |
(Markdown、タイトルなくてもいいようにならないかな？)
ITEM_TABLE::Itemsに、ITEM構造体がいくつあるかが示されていて、ITEM_TABLEの直後のポインタから始まっています。ITEM構造体には、名前の長さと値の長さが格納されていて、前述の通り、ITEM構造体の個数分の直後から配置されています。名前はchar*として示されたバイト数分だけ取得すればOKです。値の方はひとひねりあり、値が示している最初の2バイトは、値の型(アイテム型)を表しています。単一文字列はTYPE_TEXT、数値はTYPE_NUMBER、日時はTYPE_TIMEといったWORD型のデータです。ですから、値の取得には最初の2バイトで型を判別し、3バイト目からITEM::ValueLength - sizeof(WORD)の長さで値を取得してくる必要があります。ポインタの移動についても処理が煩雑になるので、少々面倒な作業になります。
ただ、型が単一文字列(テキスト型)で、名前もわかっていれば、NSFGetSummaryValue関数が使えます。
#include <nsfnote.h> BOOL LNPUBLIC NSFGetSummaryValue (const void far *SummaryBuffer, const char far *Name, char far *retValue, WORD ValueBufferLength);
NSFGetSummaryValueは、サマリーバッファから既知の名前のテキストデータを取得できます。1番目にサマリーバッファへのポインタ、2番目に名前(LMBCS)、3番目に文字列格納用のバッファ、4番目にそのバッファの長さを指定します。成功すれば0以外が返ります。
ファイル名を取得するには、DBDIR_PATH_ITEMかFIELD_TITLEを、データベースタイトルを含むDB情報を取得するにはDBDIR_INFO_ITEMを指定すればOKです。Notes/Domino APIプログラミング―C++とSTLによる実践的プログラミングには、データベースタイトルの取得にFIELD_TITLEを使うと書かれていましたが、当時の仕様から変更されたのか、FIELD_TITLEではファイル名しか取得できないので、注意しましょう。
NotesPeekリメイクアプリケーションの暫定名を、「nsfinder」としました。そのデモ画面(Mac版)です。
NotesPeekと同じ、ツリー構造です。「Local」というローカルディレクトリを表すアイテムが初期配置されています。
Localで右クリックを押すと、コンテキストメニューが表示されます。Refresh Childrenをクリックします。
ローカルのデータディレクトリが検索され、該当するNSFファイルのファイル名とデータベース名が表示されます。
構築環境は、以前のIntroQtデモと同じです。nsfinder本体と、ntlxライブラリのコードはBitbucketから取得できます。
クローンをダウンロードしたあと、タグv0.1.1をチェックアウトしてください。
こちらはタグv0.9.0をチェックアウトしてください。
Mac以外にWindows、Linux(Ubuntu)でも動作確認しています。Qt Creatorなどの設定は、以前の記事をご覧ください。
