レイアウト領域のダイアログボックス

前回は、@DialogBox を紹介しました。ダイアログボックスとして表示する画面は、通常のフォームと同様に作るのですが、前回の事例では表を利用しました。今回は、もう一つのデザイン方法であるレイアウト領域を使った例をご紹介します。

レイアウト領域とは

Visual Basic のフォームを作成するような操作で画面を作成できるのがレイアウト領域です。

ノーツフォーム上では段落（1 行）単位で文字やボタンなどを配置していきますが、レイアウト領域では、エリア内にオブジェクトを自由に配置できます。上記画面では前回作成した、部門の選択画面をレイアウト領域に書き換えてみたものです。自由な位置とサイズで、固定のテキストやフィールドを配置しています。

レイアウト領域の作成

フォーム内にカーソルを置き［作成］－［レイアウト領域］－［新規レイアウト領域］で作成します。追加された白い四角がレイアウト領域となります。領域の大きさは、黒い四角の点をドラッグドロップして変更できます。

レイアウト領域のプロパティでもサイズの調整は可能です。

3D スタイルにチェックを付けると背景がグレーになり、ダイアログボックスらしい色遣いになります。また、グリッドを表示して、グリッドに合わせると、この先のオブジェクトの位置揃えがしやすくなります。

オブジェクトの作成

レイアウト領域を選択してフィールドを作成すると、次のようになります。マウスで移動やサイズを変更ができるところが特徴ですね。ツールバーからさまざまなオブジェクトが作成できます。

フォームでは文字は直接入力できるのですが、レイアウト領域では、テキストボックスを作成してその中に文字を入れることになるので注意してください。

ペイントなどで作成した画像を配置することも可能です。クリップボードから貼り付ける際に［図形要素ボタン］を選ぶと、ホットスポットとして動作する画像にすることも可能です。

この記事の最初の画像で、メッセージ下にある青い線はこの ”図形” で作成しています。

なお、非表示設定はオブジェクト単位で行います。通常のフォームのように段落という考え方はない点もポイントです。

レイアウト領域のテスト

フィールドの設定などは通常のフォームとは多少違いますが、似たような操作で作業を進めます。でき上がったらプレビューで確認します。

希望通りのデザインになっていれば完成です。プレビューを閉じるとき保存するとそのフォーム名の文書ができるので注意してください。

ダイアログボックスとしての利用

フォームが完成したら、ダイアログボックスとしてテストします。前回作成したメインフォームの［選択］ボタンの式を書き換えます。フォーム名を変更し [SizeToTable] キーワードを削除します。

@DialogBox("dlgSetDept2"; [AutoHorzFit]:[AutoVertFit]; "部門の選択")

メインフォームをプリビューして［選択］ボタンをクリックします。次のようなダイアログボックスが表示されたら成功です。

まとめ

今回は、レイアウト領域を使ったダイアログボックスの作成方法についてまとめました。

レイアウト領域を使った場合、表より細やかな制御や自由な画面が作成できます。半面、位置合わせは非効率ですし、非表示制御など設定個所が増え煩雑となります。特徴を理解したうえで使い分けるといいでしょう。

@Dialogbox の使い方

@Dialogbox 関数はその名の通り、ダイアログボックスを表示することができます。この関数の使い方についてまとめます。

@Dialogbox の概要

@Dialogbox 関数を実行すると現在開いている文書をポップアップの画面（以下、ダイアログボックス）で開き、それを閉じるまで元に戻ることができません。ダイアログボックス内では、関数の引数で指定したフォームに切り替えて表示されます。

通常、ダイアログボックス内で更新したフィールドは、画面を閉じたタイミングで元の文書に反映されます。

@Dialogbox の仕様

デザイナーヘルプによると @Dialogbox の構文は次のように記載されています。

@DialogBox( form ; [AUTOHORZFIT] :[AUTOVERTFIT] :[NOCANCEL] :[NONEWFIELDS] :[NOFIELDUPDATE] :[READONLY] :[SIZETOTABLE] :[NOOKCANCEL] :[OKCANCELATBOTTOM] :[NONOTE] ; title )

なんだかややこしいですね。

整理すると引数は 3 つであることがわかります。

1	form	文字列	フォーム名
2	オプション	キーワード	動作オプション設定（後述）
3	title	文字列	ウィンドウタイトル

オプションにはたくさんの種類がありますが、普段使いのものだけ列挙すると次の通りです。

[AUTOHORZFIT]	ダイアログボックスの横幅を、レイアウト領域または表に合わせます。
[AUTOVERTFIT]	ダイアログボックスの高さを、レイアウト領域または表に合わせます。
[NOCANCEL]	ダイアログボックスに［キャンセル］ボタンを表示しません。
[SIZETOTABLE]	[AUTOHORZFIT] と [AUTOVERTFIT] とともに指定することで、フォーム内の最初の表に合わせて、ダイアログボックスを表示します。

複数のオプションを指定する場合は、:（コロン）で連結して指定します。

ダイアログフォームの作成

サンプルとして部門を選択する画面を作ってみます。

ダイアログフォームは通常のフォームと同じように作成します。フォーム名には dlg を接頭語につけるなるなど、それとわかる名前を付けましょう。私は、通常のフォームではないことを明示するため名称に ( ) を付け、別名を指定するようにしています。

サンプルのダイアログフォームは表に合わせるタイプで作成します。

まず、1 行 1 列の表を配置し、その中にダイアログの画面を作ります。この中身がダイアログボックスに表示されるということですね。表のセルには文字でメッセージを記述し、フィールドは見栄えがいいようにカスケードした表に配置しています。

フィールドの設定は、以下の記事で紹介したものを流用するのですが、主題ではないので割愛します。必要に応じて、リンクをご確認ください。

• @DbLookup の使い方
• ダイアログリストフィールドの設定と挙動

メインフォームの作成

ダイアログボックスを呼び出す側のフォームは次のようなイメージです。

部門用の Dept と Func フィールドは テキスト / 作成時の計算結果 となっており、初期値は null です。そして、［選択］ボタンには以下の＠式を記述します。

@DialogBox("dlgSetDept"; [AutoHorzFit]:[AutoVertFit]:[SizeToTable]; "部門の選択")

@Dialogbox の動作

メインフォームをプリビューして動作確認をします。［選択］ボタンをクリックするとダイアログが表示されます。

部門を選択して［OK］ボタンを押すと選択した結果がメインフォームに反映されます。［キャンセル］ボタンで閉じたときにはメインフォームには反映されません。

もう一度［選択］ボタンをクリックするとメインフォームの部門がダイアログボックスに表示されます。メインフォームとダイアログで同じ文書を参照していることがよくわかりますね。

まとめ

今回は @DialogBox 関数を紹介しました。

ポップアップで表示することにより、入力に集中させたり、関連する項目だけを入力させるなど、強調させることが可能となります。また、メインフォーム書いては冗長になる、入力時のガイドの表示も可能ですね。

また、複数のフォームで利用できる機能をダイアログボックス化することで、部品化することも可能です。うまく活用すると、メインフォームの設計をシンプルにできますね。

ビューで条件に応じて色を設定する方法

ビューで特定の文書だけを目立たせたいことはよくありますよね。今回は、条件に応じて、ビューの文字や背景色を設定する方法についてまとめます。以下のサンプルビューでは、10000 円以上の商品を赤、1000 円以上の商品を黄色で表示しています。

ビューの色の設定は、列のプロパティの［色で値を表示］を使用して設定します。少々クセのある設定ですので、順に確認しましょう。

初期状態

まず、作業前のビューの確認です。

文字色は、商品名を青、それ以外の項目をグレーで表示しています。ビューの背景は白で、一行おきの色に薄いグレーを設定しています。

単価のフィールド Price の値に応じてビューに色を設定します。

文字色の指定

色を指定する列を一番左に追加します。列式には表示する文字色を決定する式を記述します。

@If(   Price >= 10000;     128:0:0;   Price >= 1000;     128:128:0;     "" )

10000 円以上は赤、1000 円以上は黄色を指定します。色の指定は R G B の順でリスト値で指定します（それぞれ 0 ～ 255）。色を変えない場合は、null 文字列を指定しています。このあたりはいかにも Notes らしいですね。

列のプロパティとしては、［色で値を表示］にチェックを入れ、列を非表示に設定ます。

これで、行全体の文字色が金額に応じて変化します。

背景色の指定

もう少し目立たせたい場合には、背景色を設定することができます。一列目の列式を以下のように変更します。

@If(   Price >= 10000 ;      255:240:240:128:0:0;   Price >= 1000 ;     255:255:240:128:128:0;     "" )

色の指定が 6 つのリスト値となっています。この場合、前の 3 つが背景色、後ろの 3 つが文字色として利用されます。この式ではそれぞれ、薄い赤と薄い黄色を背景色として追加して、文字の色はそのままです。

特定の列だけ色を指定

色を指定する列は先頭である必要はありません。例えば 2 列目に移動するとそれ以降の列にだけ反映されます。

商品名の列だけに色を付けたい場合には、商品名の後ろの列でも色を指定します。

今回のビューは後ろの列はすべて、文字がグレーで背景は白なので、試しにその色を指定してみました。

@If(   Price >= 10000 ;     255:255:255:128:128:128;   Price >= 1000 ;     255:255:255:128:128:128;     "" )

すると、ビューの一行ごとの色が "白" に強制されてしまいました。赤の行でわかる通り、縞々の設定が微妙で、文字の背景が白なのに、余白は背景色の薄いグレーです。これでは中途半端で美しくないですね。

これを回避するためには、-1 を指定すると元の色で表示できるようです。

指定した式は次の通りです。

(-1):(-1):(-1):(-1):(-1):(-1)

なお、-1 をそれぞれ ( ) でくくっているのは、符号の演算子であるマイナスより、リスト連結の演算子であるコロンの方が優先順位が高いことから、確実に符号を処理させるためです。

応用技

元の列色で表示する技を応用すると、冒頭のような色設定が可能となります。

具体的には、次のように設定ます。色を指定する列は合計 3 つ作成し、背景色は条件に一致する場合には色を変えます。文字色は商品名だけ色を変え、それ以外の列は列のプロパティの色に従う設定としています。

各 ”(色を値で表示)” 列の式は左から順に以下のように設定します。

@If(   Price >= 10000 ;     255:240:240:(-1):(-1):(-1);   Price >= 1000 ;     255:255:240:(-1):(-1):(-1);     "" )

@If(   Price >= 10000 ;     255:240:240:128:0:0;   Price >= 1000 ;     255:255:240:128:128:0;     "" )

@If(   Price >= 10000 ;     255:240:240:(-1):(-1):(-1);   Price >= 1000 ;     255:255:240:(-1):(-1):(-1);     "" )

こうしておけば、将来、金額やカテゴリの色を変えたくなっても自由に設定できますね。

まとめ

今回はビューで条件に応じて色を設定する方法について、紹介しました。

途中で登場した、-1 を指定して元の色を表示する方法は、デザイナーヘルプやテクニカルサポートに確認して記載したものではありません。きっとインプリされているだろうと思い、トライ＆エラーで確認した結果となります。正しい方法か確認できておりませんので、あらかじめご了承ください。

なお、動作検証は Notes 14.5 を使用して行いました。

GetDocumentByKey が正しくヒットしない現象 !?

前回、約 20 年前に GetAllEntriesByKey を使用して、トラブルが発生した話をしました。これがきっかけでトラブルを引き寄せたのかもしれませんが、またしても、ビューの検索でトラブルが発生しました。

今回は、GetDocumentByKey に起因する問題でした。トラブル内容をまとめますので、みなさまもお気を付けください...

発生した問題

まずは、問題の原因からです。Google で検索した結果、すでに不具合情報（Defect Article）が上がっておりました。

Domino Designer 64ビット版で設計を保存すると、Notes 32ビット版では GetDocumentByKey が正しく動作しない

発生条件としては次の通りです。

• 32 ビットと 64 ビットの Notes が混在する環境で発生
• 64 ビットで保存し、32 ビットで実行すると発生
• GetDocumentByKey の検索キーに配列を指定した場合に発生
• 11.0.1 FP9、12.0.2 FP3 以降の 32 ビット版では発生しない

発生状況

私がサポートしている環境は、一般ユーザは Notes 11 を使用中です。現在バージョンアップを計画中で、検証のため私の PC には 14.5 が入っています。私の PC だけが 64 ビット版ということです。

私が開発作業をすればするほど、正常に動作しない DB が増え、傷口が広がるというトラップでした...

現象としては、GetDocumentByKey の検索キーが配列ときに発生する現象のため、頻度は低めだったのは幸いでした。それでも、いくつかの症状に見舞われました。

「ビューを検索して、ヒットしなかったら文書を新規作成する」という処理では、かったぱしから新規作成されていました。また、申請番号を管理する機能において、管理文書が取得できず、初期番号が付与され、番号が重複する現象が出ました。

特に後者は後続の業務に番号を使用していたので、システムだけでなく、業務部門にも訂正作業が発生し、大きな影響がありました。

まとめ

最初に掲載した不具合情報は 2025年5月29日 の掲載でした。最新情報ではありませんが、注意喚起のため記事にしました。Notes / Domino 11 がサポート切れになったこともあり、これからバージョンアップする方もいるかと思います。移行期間中は、32 ビットと 64 ビットの混在環境になりますので、この現象にご注意ください。

本件の対策は、32 ビットで LotusScript コンパイルすることです。［すべての LotusScript をリコンパイル］でも回避できます。開発者のマシンを最後にバージョンアップ（64 ビット化）するのは非現実的ですので、32 ビットでコンパイルしてから運用 DB に反映することをリリース手順に入れた方がいいかもしれませんね。

私のような被害者がにとりでも減ることを祈っております...

LotusScript でビューを検索するメソッドの違い

先日、8 月 22 日は、ノーツコンソーシアムの Domino Lounge Osaka（旧研究会）の京都開催でした。現地参加 17 名の大所帯で、大変な盛り上がりと熱量の中の開催でした。途中 10 分程度の休憩はあったものの、4 時間びっしり多種多様なセッションが目白押しでした。

私はというと『あの頃敵だった GetAllEntriesByKey が、実は最強だった件』と題して、ノーツコンソーシアム主催の次世代エース養成ワークショップのテキスト作成作業で知った新事実について発表しました。今回の記事は、そのまとめ記事となります。

きっかけ

20 年以上前の 2003 年に R5 にバージョンアップした時の出来事です。新機能だった GetAllEntriesByKey を利用したところ、サーバがダウンする現象が発生するようになりました。Lotus テクニカルサポート（当時）に問い合わせたところ、GetAllEntriesByKey から取得したオブジェクトで ColmunValue プロパティを利用すると障害が発生するとのことでした。

この結果を得て私のチームでは GetAllEntriesByKey の利用禁止を開発ルールに組み込みました。そして、私はビューの検索を GetAllDocumentsByKey しか使わないようになってしまいました。

失敗はこの問題修正をウオッチせず、利用禁止を解除することなく、現在に至っていることです。こんな、大きな問題が 20 年以上放置されるはずがなく直されているはずです（FixList をざっと確認したのですが、この障害を発見できなかったので ”はず” という表現になっています）。

そんな中、次世代エース養成ワークショップのテキスト作成で、GetAllDocumentsByKey の戻り値がビューの並び順とはならないこと、GetAllEntriesByKey は並び順の通り出力されることを紹介するため、改めて、2 つのメソッドの違いをサポートに確認しました。

メソッドの比較

まず、この 2 つのメソッドの機能の違いは次の通りだそうです。

GetAllDocumentsByKey	GetAllEntriesByKey
文書そのもの (NotesDocument) のコレクションを返す	ビューの行情報 (NotesViewEntry) のコレクションを返す
ビューの索引で文書を特定した後、文書全体のデータを一つ一つ読み込む	軽量な索引情報を読み込むため、高速でメモリ消費も少ない傾向
メモリ消費が多くなりがち（特に文書数が多い場合）
文書の単なる集まりであるため、並び順は保証されません	ビューで定義された通りの並び順を保証
	ColumnValues プロパティで各列の値にアクセス

並び順とビューの列情報にアクセスできることは知っていましたが、高速でメモリ効率がいいとは知りませんでした。明らかに、GetAllEntriesByKey の方が高性能です。

そして、ビューを検索するおススメの手順は次の通りだそうです。

• GetAllEntriesByKey で高速に行情報を取得
• 必要な場合にのみ、Document プロパティで文書全体を取得

GetAllEntriesByKey 一択といった感じだったので、GetAllDocumentsByKey の存在意義について質問したところ、GetAllEntriesByKey は R5 で追加された機能で、それ以前のスクリプトとの互換性を保つ目的が大きいとの説明でした。

なんだか GetAllDocumentsByKey が不憫になってきました...

なお、ここまでの情報は、Customer Support FAQ に掲載されています。詳しくは、下記のリンクをご確認ください。

NotesView クラスの GetAllDocumentsByKey と GetAllEntriesByKey メソッドの比較

メソッドの使い方

参考までに、2 つのメソッドと関連するクラスの関係をまとめると以下のような感じです。

NotesViewEntry クラスには Document プロパティがあり、ここから文書を取得できます。ただ、文書を取得することが目的であれば、GetAllDocumentsByKey の方が文書に素早く到達できます。コードをシンプルに保ちやすいと言えるかもしれません。

また、NotesViewEntry クラスのプロパティには、IsCategory や IsTotal が示すように、ビューのカテゴリや合計にアクセスできるようです。GetAllDocumentsByKey と同じように扱うと想定外の結果になる可能性がありそうですね。

GetAllEntriesByKey が機能的に優位であるのは間違いなさそうですが、機能の違いを理解した上で使い分けるべきだと思いました。

具体的には、検証した上で別途記事にしたいと思います。

まとめ

過去のトラウマがきっかけで、GetAllDocumentsByKey しか利用しない偏ったスタイルだったと気づかされました。そのおかげできっといろいろ損をしたと思います。情報のアップデートは必要ですね。また、重鎮の方は、これらメソッドの違いを知っていて、しっかり使い分けられていると伺いました。まだまだ修行が足りないと感じました。

ノーツコンソーシアムの Domino Lounge Osaka では、最初の画像にあるアジェンダの通り、さまざまな立場の方が発表します。内容は技術的なものからプロジェクト事例まで難易度も幅広く、どの発表にも「伝えたい思い」が込められています。そのため、参加者は多くの気づきを得られるだけでなく、自分の知らなかった世界を知るきっかけにもなるはずです。

そして、京都開催では本編以外にもお楽しみがあります。納涼川床での懇親会です。普段では味わえない非日常の環境で Notes/Domino の本音トークができます。今年は、台風やにわか雨に邪魔されることもなく無事開催できてよかったです。

DXL Step-by-Step：#63）ビューの列

数回にわたりビューの設計と DXL について紹介してきました。最後はビューの列 についてまとめます。

列の基本構造

まずは、一番シンプルなパターンです。次のような列を DXL に変換して基本構造を確認します。

列のプロパティが column ノードの属性に設定されています。列幅は width、サイズ変更可能は resizable、複数値の分離記号は separatemultiplevalues 属性です。属性名を見ればどの設定か想像できますね。

column 直下にあるサブノードの font は、列に表示される値のフォントです。

columnheader ノードはその名の通り列ヘッダーの設定で、ヘッダに表示する値が title 属性に、ヘッダーのフォント設定がサブノードに出力されます。

列の値と計算式

列の値としてフィールドを指定した場合は、そのフィールド名が itemname 属性に出力されます（上図の DXL 参照）。

計算式の場合には、event が 'value' の code ノードが追加され、そこに式が出力されます。

itemname には '$5' とフィールド名ではないものがセットされます。これは、列のプロパティの［詳細］タブにある名前のようなのですが、この名前と式がどのように関連しているのか不明瞭に感じます。ただ、DXL では式がサブノードにセットされているので、明確ですね。

前回

DXL Step-by-Step

DXL Step-by-Step：#62）アクションボタン

前回はアクションバーについてまとめましたが、スタイルの部分だけとなっていました。今回は、アクションバーに配置されているアクションボタンについてまとめます。

アクションボタンと DXL

アクションボタンの DXL は actionbar ノードのスタイル表示の後ろに action ノードとしてまとまっています。action ノードは配置されているボタンの数だけ出力されます。

具体的に、アクションボタンを DXL に変換した例を示します。

アクションボタンのプロパティが action ノードの属性に設定されています。

ボタンクリック時に実行する式が code ノードに出力されています。また、ボタンのラベル式も code ノードとして出力されています。このように code ノードは状況に応じて複数することになります。あたりの仕組みは、ビューの選択式やイベントにプログラムを記述した場合と同様ですね。

シンプルアクション

アクションボタンには＠式や LotusScript  以外にシンプルアクションを設定できます。シンプルアクションを設定したボタンの DXL は少し構造が変わるので注意が必要です。

code ノードの属性である event が 'action' となり、simpleaction というサブノードが配置されます。また、この DXL では simpleaction が 2 つ出力されています。シンプルアクションは一つのボタンに複数のアクションを設定できます。これに対応するため、配列のような構造になっているということですね。

simpleaction ノードの属性にシンプルアクションで実行する処理が記述されます（上図はエージェントの実行の場合）。シンプルアクションには、さまざまな種類があり、その種類ごとに設定できる項目が変化します。そして、DXL もその種類ごとに変化します（詳細は別の機会にまとめます）。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#61）アクションバー

前回はビューの code ノードを確認しました。今回は actionbar ノードについてまとめます。

actionbar ノードの構成

まずは、Domino Designer を使って DXL の構造を確認します。actionbar ノードを開くと、色やスタイル、フォントなどのアクションバーの設定があり、そのあとにアクションボタンである action ノードが配置されています。

アクションバーのスタイル

前述の通り、アクションバーのスタイルは、actionbar の属性といくつかのサブノードから構成されています。ざっくりいうと、プロパティのタブとノードは対になっています。いかに記載がないタブと一部に例外が actionbar の属性に配置されています。

◇ フォント

アクションバーのプロパティの［ボタンのフォント］タブの設定は、font ノードに集約されます。

フォント名（name）やサイズ（size）などが含まれます。この構造はリッチテキストの文字の装飾と同じですね（DXL Step-by-Step：#22）文字の装飾）。

◇ ボタンのプロパティ

アクションボタンのサイズや色などを設定する［ボタンのプロパティ］タブは、actionbuttonstyle ノードに出力されます。

◇ アクションバー境界

アクションバーに影をつけたりできる境界の設定は border ノードに出力されます。

境界線の幅は width 属性で設定でき、上/右/下/左の順でピクセル指定します。この指定方法は表のセルの境界線 borderwidth と同じですね（DXL Step-by-Step：#38）セルの設定 - 表の罫線）。

また、境界を表す border ノードは、表やインラインイメージの境界としても利用されています。

◇ アクションバー背景

プロパティの［アクションバー背景］タブの設定は、actionbarstyle ノードに出力されます。

イメージリソースを利用すると imageref ノードが登場します。これは、リッチテキストにインラインイメージを表示する場合と同じです（DXL Step-by-Step：#26）イメージリソースの DXL）。

まとめ

今回はアクションバーに関してまとめました。

font や border、imageref のようにリッチテキスト内で利用したノードが出てきました。また、今回紹介した actionbar ノードはフォームやサブフォームにも登場します。このように DXL は部品として再利用しやすいよう構造化されています。この点を理解しておくと DXL の理解が早くなります。

積み木やレゴのように組み合わせてモノを作る感じが面白いですね。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#60）ビューの選択式と Code

前回はビューの DXL の全体構成を確認しました。今回からサブノードの構造を確認します。最初は、code ノードです。

選択式

code ノードを開いて詳細を確認します。

同じ部分を VS Code で整形して表示すると次の通りです。

見ただけでわかりますね。この部分はビューの選択式を表しています。formula サブノードには選択式が記述されていることが確認できます。

event 属性

code ノードの event 属性には ’selection’ と設定されています。これが配下のコードは選択式であることを示しています。たとえば、このビューにフォームの式と文書の貼り付け禁止を設定します。

このビューを DXL で確認すると次のように code ノードが３つ出力されています。

フォームの式と貼り付け禁止については event 属性が form、querypaste となっています。このように code ノードはデザイナーのオブジェクトごとに作成され、event 属性でどのオブジェクトかを表しています。

コードと DXL

ビューの設計内に記述したプログラムも DXL 内に出力されます。式言語の場合は formula ノード、LotusScript では lotusscript ノードが作成され、その配下のテキストノードにプログラムが出力されます。

このように記述した言語に応じたノード名で出力される仕様となっています。

前回

DXL Step-by-Step

次回