2019年3月17日日曜日

表の境界線をイメージに置き換えてみた

前回のエントリでは、表のプロパティで境界線を"イメージ"にすると、画像がどのように境界線として表示されるのかを見てきました。

今回は、ずっと前から気になっていたアプリケーションライブラリ(dblib4.ntf)におけるデータベース名の表示の不具合(下図)を改善してみたいと思います。


「不具合」とはデータベースのタイトルが長い場合、タイトルの右側が本の外側にはみ出てしまうことです。

フォームの設計を見てみます。下図はフォームの一部です。

固定幅で1行1列(セルが1つだけ)の表に、セルのイメージとして本の画像 dblib.gif を指定しています。これではウィンドウサイズにあわせて本が縦や横に伸びたり縮んだりすることはありませんね。

これを表の境界線として指定し、かつ固定幅ではなくウィンドウの幅に合わせて表の幅も変わるようにしたいと思います。

このブログでは dblib.ntf を直接修正することはせずに(一時的に作成する)別のデータベースで検証していきます。

まずは、dblib4.ntf イメージリソースに登録されている dblib.gif を Export して画像を確認してみたいと思います。
Export したファイルをペイントアプリで開いてみると、画像のサイズは 436 x 49 px でした。

これを前回と同様に、縦と横に3等分して9つの枠に分けてみました。

この図を表の境界線として表示する場合、表が縦方向に膨らむと「左」と「右」が縦方向に繰り返し表示されます。「左」を拡大してみると、線に段差があることがわかります(下図)。

この画像をそのまま使う場合「左」が縦方向に繰り返し表示されると縦線に凸凹が生まれて見た目がよろしくありません。

そこで、3等分したときに段差がなくなるように高さを調節します。画像の縦のサイズを 11 増やして 60px に変更しました。そして画像の下半分をコピーして最下部に合うようにペーストした画像がこちらです。元の画像よりも本の厚みが若干増しました。

三等分してみると「左」の縦線にあった段差が無くなっています。

この画像をイメージリソースに Import して、表のプロパティから表の境界線のイメージとして画像を設定します。そして表の外側に表示する画像の厚みを「厚さ」から調整します(下図)。

このままでは表の内側が白抜きとなってしまいますので、表の内側を埋めるドットだけの画像を作成してイメージリソースに Import したものをセルのイメージとしてタイル状に繰り返し表示するよう設定します(下図)。

こうして表の中にある文字がいくら長くなっても本の外側にはみ出すことなく折り返して表示されるようになります。
ウィンドウの幅が広い場合

ウィンドウの幅が狭い場合
いかがでしたでしょうか。

境界線として使えそうな画像を「枠」や「フレーム」などでググると素材を扱うWebサイトがいくつかヒットしました。フォームのデザインに合う境界線があるといいですね。

表の角を丸くする仕組み

前回の「のの会」でのお話です。
Domino Domain Monitoring (DDM) についてアクセルの岡本さんがお話されている時、DDM.nsf 内にあるイベント文書を開き「この角が丸い枠はどうやってんねやろ?」みたいなことをおっしゃってました。

下図は ddm.nsf のイベント文書を開いた画面の一部です。色のついた四角の角が丸くみえます(追加した2つの赤い矢印で示しました)。

言われてみればどう実現しているのか説明できないぞ?!ということで、その場で設計を覗いてみました。

すると表の周りを角の丸い四角でふちどっているような感じでしたので、表に何らかの仕掛けがあるのかと考え「表のプロパティ」をチェックしてみました。すると「境界線のスタイル」に"イメージ"が選択され、さらに「イメージ」として "TableBorderRed.gif" が指定されていることがわかりました。(下図)


そしてのの会の翌日、ddm.nsf 内の「イメージリソース」にある TableBorderRed.gif をエクスポートしてペイントで開いてみると、サイズが横193px 縦146px、薄い赤色で角の丸い四角形が描かれていました。


なるほど。表の外側を特定の画像(の縁)で縁取ることができるようです。

しかし、Notesの表というのは表全体の幅がウィンドウやフレームの幅にあわせて変化したり、表の中に表示するものによっては縦に伸びたりする場合があります。
TableBorderRed.gif の縦横のサイズは、フォーム上に表示されれている表とは全く異なりなりますが、違和感なく表のまわりに表示されています。

この仕組みをみていきたいと思います。

下図の画像(以降「元画像」と呼びます)を用意してみました。これをイメージリソースへ登録します。


そして表のプロパティで境界線の「イメージ」に指定したものがこちらです。
左上を拡大すると次のように見えます。どうやら「伸びている」のではなく「繰り返している」ようですね。

では、元画像のどの部分を繰り返しているのでしょうか。

元画像のサイズは 24 x 24 の正方形です。下のように縦横三等分して9つの枠で示すことができます。この9つの枠それぞれに「左上」「中」といったように名前をつけてみました。

これを先の拡大図にあてはめてみると、次のようになります。
左上隅に、元画像の「左上」が表示されました。
左上の下側には、元画像の「左」が縦方向に繰り返し表示されます。
また「左上」の右側には、元画像の「上」が右方向に繰り返し表示され、「左」の右側と「上」の下側には「中」が繰り返し表示されました。

さて、縦横三等分した「左」と「上」と「中」が繰り返されていることがなんとなくわかったので、表の右側も見ていきます。下は表の右上を拡大したものです。
最上段では「上」が右方向に繰り返し表示され、最後に「右上」が表示するのですが、表のサイズは元画像の倍数とは限りませんので、余りが生じる場合があります。その余りとして「上」が部分的に表示されました。
「右上」の下側にある「右」の左に接するものも同様に「中」が部分的に表示されました。

続いて表の左下です。
 表の左側では「左」を縦方向に繰り返し表示して、最下段に「左下」を表示しますが「左」と「左下」の間には余りとして「左」が部分的に表示されました。
「左下」の右側は「下」が繰り返し表示されますが、その「下」の上に接する「中」も余りとして部分的に表示されました。

そして最後は表の右下の拡大図です。
表の右下の隅には元画像の「右下」が表示され、それに接する「中」「右」「下」が部分的に表示されました。

表の伸縮へは、元画像の「上」「右」「下」「左」「中」の繰り返しと、幅と高さの余りの調整にそれらを部分的に表示することで対応していることがわかりました。


ところで、皆さんは「データベースライブラリ」というデータベースをご存知でしょうか。Dominoサーバーやローカルにあるデータベースを登録することができるデータベースです。バージョン 10.0.1では、テンプレート "Application Library (8)" dblib4.ntf を使って作成できます。

「データベースライブラリ」にデータベースを登録し、登録した文書を開いたものが下図になります。

本を横にしたような画像があり、その背表紙には登録したデータベースのタイトル(図では ”HTTPRequest” )が表示されます。

ここへ登録したデータベースのタイトルが長い場合、下図のように本の中に納まってくれません。これが個人的にはすごーーく気になっていたのです。

この不具合は表の境界線で”イメージ”を活用することで改善できそうです。
次回はこれを改善してみようと思います。

2019年3月8日金曜日

変数の型とパフォーマンス

昨日は会社帰り「のの会」に参加しました。


ところで Notes の設計をちょっといじっただけで見違えるほど体感速度がかわることってありませんか?

例えば「ビューのカテゴリを閉じた状態で開く」とか。

今回はそんな「ちょっとしたこと」を LotusScript の処理のパフォーマンスと絡めてご紹介しました。

下のスライドで共有いたします。



のの会では、発表中の発言は自由ですので「1億回ループの処理時間をどうやって計ったの?」「ダイナミックって言うけどいつ割り当てるの?」等、やさしい質問から厳しいツッコミまでいただきました。いちユーザーの立場では製品の内部仕様まで存じ上げないこともあり、これまでの経験から「あーじゃない?こーかも?たぶんそう!」程度の受け答えしかできないこともありますがそこはご容赦ください(汗)

スライドのコードはわかりやすくする目的でシンプルにしましたが、もっと現実味のあるコード(?)のほうがののさん向けだったかも、と反省してます。

2019年2月25日月曜日

エンドユーザーが全文検索をもっと使いやすくするアイデア

ビューの上部に表示される検索バーへ Japan などとタイプして Enter キーを押す、という操作は多くのエンドユーザーが行っていますが、この場合すべてのフィールドにある Japan というワードがヒットしてしまいます。
検索結果をもっと絞り込みたい場合、例えば
[Country] = "Japan"
といったようにフィールド名を含めたクエリーに書き換えて検索するようエンドユーザーへ勧めますが、これがなかなか浸透しません。

浸透しない理由は、フィールド名はエンドユーザーに馴染みがないからではないか、と推測しています。フィールド名が多く覚えられないことも原因の一つかも?

検索ビルダーを利用してフォームを使って検索できることは承知しているのですが、例えばキーワードリストから選択するようなフィールドの場合は検索ビルダーではキーワードリストが表示されず、タイプするために値を覚えておく必要があったりと使い勝手はいまひとつと言わざるを得ません。

そこで、こういった検索バーにおける不便を解消するため、次のような作りこみを行い、実現しました。
  1. ビューのアクションボタン「詳細検索」をクリックする(ダイアログボックスを表示する)
  2. ダイアログボックスにあるフィールドへ文字列をタイプ(またはリストから選択)して[OK]ボタンをクリックする(検索バーへ転記する文字列を生成してクリップボードへ転記。検索バーを表示してクリップボードの値を貼り付け、Enterキーを押すコードを実行し、ビューに検索結果を表示する)
しかしながら、Enterキーを押すために Win32 API をコールしており Windows 向けのものとなっています。このコードではもうすぐ登場する Domino Mobile Apps に対応できないと考えています。

もし、検索バーへのクエリーの転記をもっとシンプルにしたり、転記後にEnterキーを押すコードを呼ぶこと無しに検索が始まるアイデアなどございましたらシェアしてくださると嬉しいです。

以下、現在のコードです。

ビューのアクションボタン「詳細検索」では次のコードを書いています。

--- 詳細検索ボタンの式 ---
tmp := @DialogBox("MakeQuery"; [AutoHorzFit]: [AutoVertFit]: [NoNewFields]: [NoFieldUpdate]: [NoNote]: [SizeToTable]; "Input for Search String");
@If(tmp=@True; @Success; @Return(""));
@Command([ViewShowSearchBar]; "1");
@Command([EditPaste]);
@Command([RunAgent]; "PressEnterKey")

1行目で呼び出すダイアログボックス内で使用しているサブフォーム「MakeQuery」には、キーワードのリストからの選択が可能なフィールド「Country」を配置しています。
フィールド「Country」で値を選択してダイアログボックスのOKボタンをクリックすると、フィールド「Query」の式がクエリー文を生成します。

--- フィールド Query の式 ---
str := Country;
"[Country] = (\"" + str + "\")"

※MakeQuery には Country 以外にも複数のフィールドがあるのですが、ここでは1つだけとしています

生成されたクエリー文をサブフォームのイベント Postrecalc のコードでクリップボードへ転記します。

--- Postrecalc のコード ---
Sub Postrecalc(Source As Notesuidocument)
    Call Source.GotoField("Query")
    Call Source.SelectAll
    Call Source.Copy
End Sub


「詳細検索」ボタンの3行目以降で、検索バーを表示してクリップボードの値を貼り付け、Enterキーを押すコード(エージェント「PressEnterKey」)を呼び出します。

--- Enter キーを押すコード(エージェント「PressEnterKey」) ---
Declare Sub keybd_event Lib "user32.dll" (ByVal bVk As Integer, ByVal bScan As Integer, ByVal dwFlags As Integer,ByVal dwExtraInfo As Integer)
Sub Initialize
    keybd_event &hd,0,0,0 ' Enter key down
    keybd_event &hd,0,2,0 ' Enter key up
End Sub

以上

2019年2月24日日曜日

Domino V11 と IBM と HCL と

おととい(2019年2月22日)は朝から晩までノーツづけの一日でした。

ノーツコンソーシアムの「ユーザー情報交換会」に始まり、その後「通常総会」。
午後は大きな会場へ移動し「ノーツコンソーシアム FESTA」と「IBM Notes/Domino Day 2019 Spring」。その後、会場ロビーにて「大感謝祭」と称したパーティーが催され、終了後は有志による二次会と、どのタイミングで隣の人に話しかけても Notes Domino を知らない人はいない、そんな一日でした。

ノーツコンソーシアムFESTA 2019 オープニング
午後一番はノーツコンソーシアム FESTA 2019 から始まりました

大きな話題の一つである、昨年12月に発表された HCL 社への Notes/Domino の売却については、どこへ行っても冒頭にお話しがありました。
HCL 社はコンタクトのあった日本の Notes ユーザー企業への訪問を始めているようです。日本 IBM の人が HCL 社へ移る時期について具体的な話はありませんでしたが、有効なSS&S とライセンスは自動的に HCL 社へ移行される見込みとのことでした。

NDDay の Ayasa さんによるパフォーマンス
Notes Domino Day 2019 Spring のオープニングは Ayasa さんによるパフォーマンスで始まりました
IBM Notes/Domino Day 2019 Spring のオープニングは Ayasa さんによるヴァイオリン演奏のパフォーマンスでした。本イベントのエンディングにもパフォーマンスを披露されたのですが、その時スクリーンに流れた映像が Notes Domino History とも言えるもので、映像が素早く切り替わっていくあたり、これからの Domino がめざましく進化していくように感じ、Ayasa さんが演奏する曲ともマッチしていてとても感動的でした。

ところで Notes Domino の今後については、ADFS 連携やテンプレート拡張といった、日本からの要望があったものが V11 で採用されるといった嬉しい話がありました。
また、軽量版 Notes クライアントと、iPad 版に加え Android版 と Chrome OS 版の Domino Mobile Apps の計画があること、英語版のリリースと同時に日本語を含む言語版もリリースすること、XPages への投資が継続されること、が特に気になったポイントでした。

次世代クライアントとは Red Pill Now で見たアレかしら

ADFS 同期は日本の V11 Jam でも重要性を伝えた機能

日本の V11 Jam で指摘した、アプリやサンプルテンプレートのことにも触れていました

それから、来る新元号にも対応を予定しているとのことで、今後こちらが更新されるようです。

新元号対応を 9.x と 10.0.x で予定

V11 の文字が現れ、演奏はクライマックスに

そうそう。イベント開始前に前から5列目くらいに陣取っていたら「IBM Champions はリザーブシートへどうぞ」と2列目中央の特等席へ案内してくださいました。その時最前列の HCL 社の Rechard 氏と会話する機会があり「HCL では Champions でなく Heros です」と教えてくださいました。

その後の大感謝祭では、多くのノーツ関係者で大賑わいの中、新たな IBM Champions のひとりとして紹介していただいたり、ノーツコンソーシアムから感謝状を頂いたり、このブログを見ていただいている方からお声掛けいただいたりと嬉しいことが波のように押し寄せました。

その後も有志のメンバーから2次会にお誘いいただいたのでそちらへも参加させてもらったのでした。
初めてのラクレット!

そんなこんなで頂いた品々がこちらです。


励ましの言葉などたくさんのパワーをいただいた一日でした。
どうもありがとうございました!

(個人的に一番楽しみにしていた DQL Explorer が見えなかったような...)

2019年2月16日土曜日

Domino Query Language (DQL) を他の検索と比べました

昨晩(2019年2月15日)は「テクてくLotus技術者夜会」に参加しました。

今回のテクてくのテーマが

新 IBM Champions for ICS にいろいろ聞いてみよう!

ということで、40分の枠をいただいて、本ブログにも度々登場している Domino Query Language (DQL) についてお話させていただきました。



今回の検証で新たに分かったことは、ODS バージョンが 20 と古くても検索できますし、クライアントのローカル nsf ファイルを検索することができることです。

また、これまでの検索機能とのスピード比較を行い、その結果を記載しています。

まだあまり知られていない(?) DQL ですが、ぜひ試してほしい機能のひとつです。

2019年2月7日木曜日

ODS

昨晩(2019年2月6日)は会社帰りに「のの会」に参加しました。

ずーっと前ですが、常駐先のエンドユーザーからこんなことを聞かれました。
データベースのプロパティに表示される「ODSバージョン」ってデータベースによって違うんだけど、何なの?
Domino のバージョンをアップグレードする担当者にはおなじみのODSですが、エンドユーザーにとってはあまり気にすることも無いだろうし、そもそもデータベースのプロパティを見るエンドユーザーなんて存在しないだろうと高をくくっていたこともあって、少々説明に困ってしまいました。

そんなことがあり、少しまとめたものがあったのですが、V10も出ているので加筆修正したものを今回「のの会」でお話させていただきました。



以下、補足します。

案外、クライアント側のODSバージョンは放っておかれがちです。ODS 20 のNSFファイルをアップグレードして Notes の起動が早くなったという Panagenda社の事例(スライド中に事例へのリンクあり)を読み、私のローカル環境にも ODS20 のデータベースがあったことから、それらをアップグレードした結果、確かに早くなったことを実感できました。

また、8.5.1 以降のバージョンでは、Domino で DAOS を有効にしている場合、クライアント側の ODS もアップグレードすると「DAOS オブジェクトコピーの最適化」が機能して添付ファイルの転送にメリットがあるとのこと。※こちらは未検証です

ODSをアップグレードする理由として、古いバージョンによる「不具合を解消するため」といった後ろ向きな理由も中にはあるでしょう。けれど、文書や設計の圧縮といった新機能を有効にすることで I/O 性能が向上することによるパフォーマンスアップが体感できると思います。

なお、ODSアップグレードにはデータベースの圧縮が伴います。デスクトップポリシーを使うなどしてクライアントの notes.ini ファイルへ NSF_UpgradeODS=1 を追加する場合、圧縮中のデータベースをユーザーが使えないため、注意が必要です。

最後に、実際にアップグレードする場合は、最悪のケースを想定して事前にバックアップを取っておくなどしましょう。