和ろぐ【わろぐ】

NotesUIDocumentクラスのRefreshについて

確認環境：Notes 6.5.4
OS ：WindowsXP+SP2

NotesUIDocumentクラスのRefreshメソッドは現在開いているフォームの各計算結果フィールドを再計算してくれますが、Notes6よりパラメータが追加になりそれにより効果が変わるため注意が必要です。

１．パラメータをFalseにする（パラメータ指定なしも同じ）
　○記述例
　　Dim NUIDoc as NotesDocument
　　　:（中略
　　Call NUIDoc.Refresh( False )

　○効果
　　・各計算結果フィールドの再計算および非表示式の再計算をしてくれる
　　・リッチテキストの値はバックエンド文書へ更新されない

　○注意
　　・実行後は表示用の計算結果フィールドの値を参照できなくなる（Null値になる）
　　　→（仕様なのかバグなのかは不明）

２．パラメータをTrueにする

　○記述例
　　Dim NUIDoc as NotesDocument
　　　:（中略
　　Call NUIDoc.Refresh( True )

　○効果
　　・各計算結果フィールドの再計算をしてくれる
　　・リッチテキストの値もバックエンド文書へ更新される
　　
　○注意
　　・SaveOptionsフィールドに"1"が設定されている状態で実行すると保存されてしまう
　　・非表示式の再計算は行われない（仕様なのかバグなのかは不明）
　　　→非表示式も更新したい場合はRefreshHideFormulaメソッドで別途非表示式のみ更新する

Format関数による日付の文字列変換について

確認環境：Notes 6.5.4
OS ：WindowsXP+SP2

私は、LotusScriptで日付を"yyyy/mm/dd"のように"/"で区切った文字列へ変換するためにはFormat関数で以下のように記述するだけで良いと思っていましたがどうやら間違って覚えていたようです。

Format$( Now(), "yyyy/mm/dd" )

実際は"/"の部分が必ずしも"/"にはなりません。
OSの日付の区切り文字に設定されている文字となります。
例えば、OS設定で区切り文字を"-"に設定していた場合、上記の結果は"2009-07-10"となります。

これは時刻の変換で":"を使った場合も同様です。
ただし、"/"以外で指定した場合はその文字が適用されるようです。
Format$( Now(), "yyyy.mm.dd" ) →　"2009.07.10"

ヘルプをきちんと読まれている方なら当たり前のことかもしれませんが、私は今日まで気づきませんでした．．．

ということで、"yyyy/mm/dd"形式の文字列を環境に影響されずに取得したい場合は別途加工が必要ですのでご注意下さい。

Format関数の障害

Format関数で日付を文字列へ変換において３桁の年数を指定する場合は注意が必要です。
ヘルプでは

yyyy 西暦の完全な (4 桁) 数値 (0100 - 9999)

と記述されているので３桁の場合、頭に０(Zero)がつくのかと思えるが、実際にはつかない。

例）Format( 日付変数, "yyyy/mm/dd")で「100年4月1日」を変換した場合

"100/04/01"

が返される。

■おまけ
ちなみに、他にも以下のような変換がされるので注意！

年数下２桁が５０未満(1-49)の場合、年数に2000が加算される

0001/04/01→2001/04/01
0049/04/01→2049/04/01

年数下２桁が５０以上(50-99)の場合、年数に1900が加算される

0050/04/01→1950/04/01
0099/04/01→1999/04/01

■確認環境
Notes R5.0.11
Notes R6.5.4

ノーツメールからインターネットメールへ送信時の注意

ノーツメールの本文に右寄せや中央揃えの書式を指定してインターネットメールへ送信するとサーバによっては受信拒否されます。

ある受信側サーバ管理者の方におききしたところ「メール内の文書終了を表す"."がない」状態でサーバに届いているとのこと。

IBMからは右寄せや中央揃えを使わないようにとの回答あり。

作成時の計算結果フィールドについての注意

「作成時の計算結果」フィールドはその名の通り、フィールドを初めて作成した時（フォームで新規文書を開いた時）にのみ値式が計算されるフィールドです。
ボタンやアクションなどでプログラミングすれば後から値を更新することもできます。

ただし、フィールドの種類が「数値」または「日時」の場合は更新できないという仕様（IBMへ確認済み）になっています。
「数値」や「日時」以外の、例えばテキストフィールドの場合は更新可能です。
このように種類によって仕様が異なるため注意が必要です。

■確認環境
Notes/Domino R5(R5.0.11)

@Contains使用にあたっての注意

ノーツ式の「@Contains( String; Sub-String )」は、String（文字列または文字列リスト）中に、Sub-String（リストの場合はいずれかの文字列）が含まれるか判定する関数ですが、指定の文字列が ""（空文字列）の場合も、 含まれていることを示す値 1 (True)を返します。
ヘルプでみる限りそのような記述はない（見落としの可能性はあります）のですが、注意して下さい。

例）以下のような式で、フィールド「INPUTFLD」が空文字列（""）の場合、 1 (True)が返されます。

@Contains( "aaa":"bbb":"ccc"; INPUTFLD )

■確認環境
R5.0.11
R6.5.4

名前フィールド（またはアイテム）の文字列比較時の注意

■発生環境
Notes R5.0.11

■現象

フィールドの種類が「名前」の場合、スラッシュを含む文字列を入力すると式やスクリプトで値を取得した時に「CN=xxx/OU=xxx/O=xxx」のように各階層名が自動的に付けられる。
※読者や作成者は未確認
※フォームを開いている場合のみと思われる

文字列としてチェックをするような場合は注意が必要。

例）先頭に#がついているかどうかチェックする

AAAフィールド（種類＝名前）に「#aaa/xxx」と入力した場合

Dim vValue As Variant

vValue = NDoc.AAA
If vValue(0) Like "[#]*" Then '→vValue(0)には "CN=#aaa/O=xxx" が入るため先頭に#がついていないことになる

<省略>
end if

■対策

NotesNameクラス（スクリプト）や@Name関数（式）で階層名をつかない形式（Abbreviate等）に変換してから比較する。

Dim vValue As Variant
Dim NName As NotesName

Set NName = New NotesName( vValue(0) )
If NName.Abbreviated Like "[#]*" Then
<省略>
end if

ビューの列に他の列の値が表示される現象について

【現象】

ある列に設定した式の結果とは違う値が列に表示されてしまうことがあった。
よく見るとある列と同じ値が表示されていた。

【原因】

列プロパティの「詳細」タブの、「名前」が他の列の名前と同じだったため
この名前はフィールドを表示している場合はフィールド名になるが、式の場合は"$1"のように識別子が自動的につけられる。
他のビューから列をコピーした時に、たまたま同じ名前になっていたことが原因でその列より前の列で同じ名前の列があればその列の値を参照することになる模様。

【対策】

１つのビューの中では列の名前が重複しないようにする。

■確認環境
　Lotus Notes 6.5(R6.5.4)

文書リンクについて

文書リンクをプログラムで生成する場合以下の点に注意していないと正しく動作しない

１．必ずデフォルトビューがデータベース内に存在すること！　

　※「データベースを最初に開くときデフォルトで表示する」にチェックがつけられたものがデフォルトビュー

２．デフォルトビューにアクセスできること

　許可されていないユーザ以外は文書リンクを作成できなくなる

３．"URL"という名前のフィールドを作成しないこと！

　このフィールドがあると文書リンクが機能しなくなる。

＠関数式：@Adjustによる日付算出時の注意

@Adjust関数は日時の算出をするのに便利な関数ですが以下の仕様を理解していないと思わぬ日付が返されることがあります。

この関数は下の位、つまり「秒→分→時→日→月→年」の順に計算する仕様のようです。

例えば「日付＋１ヶ月後－１日」という計算をする場合、以下のように記述してしまいがちです。

@Adjust(日付;0;1;-1;0;0;0)

ほとんどの日付の場合望み通りの日付を返してくれますが「３月１日」の場合のみ、「３月２８日」（閏年の場合は２９日）を返します。
これは前述したように@Adjust関数が「日→月→年」の順に計算するため、最初に「－１日」が計算されて「２月２８日」になり、その後「+１ヶ月」して「３月２８日」となるためです。
他の日付の場合は、テストをしても３月１日以外であれば全て思ったとおりの結果なので気づきにくい間違いですので注意が必要です。

ちなみに望み通りの日付を算出するには、以下のように記述すればOKです。

@Adjust(@Adjust(日付;0;1;0;0;0;0);0;0;-1;0;0;0)