月別アーカイブ: 2020年12月

4D プロジェクトフォームとテーブルフォーム、イベントプロパティが違う　その２

以前のブログで間違いがあったので修正するとともに、印刷用フォームについて再考した。プロジェクトフォームとテーブルフォームで制御できるイベントプロパティが違うのは「テーブルのレコードセレクションを前提としたイベントがプロジェクトフォームではサポートされていない」ということだった。以前ブログを書いた時の理解が足りていなかっただけで、考えてみればプロジェクトフォームには帰属するテーブルがないから、セレクションを前提としたプロパティが設定できないのは当たり前だ。

たとえばプロジェクトフォームのプロパティには「On Printing Detail」などの印刷時に発生しそうなプロパティがない。これはPrint selectionの時に有効で、セレクションが必要なのでテーブルに帰属していることが前提になるためにテーブルフォームにしかないプロパティなのだ。

たとえば、印刷時に「文字列が多くて印字領域に収まらなかった時に文字フォントを小さくして印刷する」という技を使っているのだが、これは印字しようとしている文字列長によって適用するかしないかが異なる。「On Printing Detail」が発生した時、文字列を一度配置してみて文字列オブジェクトの矩形の長さを評価して、所定の幅に収まりきらなかったら小さいフォントサイズを再設定するという仕様だ。それで「On Printing Detail」にコードを記述することになる。この実装がプロジェクトフォームでもテーブルフォームでも動いてしまう。あれっ、と思って調べたらどちらのフォームにも「On Printing Detail」イベント（Form event = 23）が発生していたのだ。では、テーブルフォームで「On Printing Detail」チェックを外したらどうなるか。これでも「On Printing Detail」イベントは発生していた。

印刷時に使っているコマンドは次。

Print form([Z_PrintForm];”PP11_PrintList”;Form detail)

ここで印刷するフォームオブジェクトに配置されているのは配列要素またはプロセス変数でありテーブルのセレクションは無関係。

Print formではフォームプロパティのイベント「On Printing Detail」のチェックオフが無視される。Print formでForm detailを直接印刷しているため、4Dが内部的に「On Printing Detail」イベントを発生させているように見える。よく見たらPrint formの説明に書いてあった。つまり、Print formを使うということは、印刷イベント「On Printing Detail」を強制的に発生させるという意味であり、フォームのプロパティ設定は無視される、ようだ。しかしヘッダーを印刷するとき、つまりPrint formの指定領域が「Form header」でも同じイベント「On Printing Detail」が発生するのはわかりにくい。どうやら指定領域ごとに異なるイベントを発生させる必要はない、と考えているようだ。まあ実用上は問題ないかもしれない。次のコードはいずれも「On Printing Detail」が発生した。

Print form([Z_PrintForm];”PP11_PrintList”;Form header)
Print form([Z_PrintForm];”PP11_PrintList”;Form detail)
Print form([Z_PrintForm];”PP11_PrintList”;Form footer)

以前のブログは次のように補足しよう。

１）Print formを使う場合、「On Printing Detail」イベントプロパティのチェックは印刷時に影響しない。

２）配列を印刷する場合のフォームはプロジェクトフォームでもテーブルフォームでもよい。

Print formで配列を印刷する場合はセレクションが関係しないため、どちらにフォームを作っても問題はない。テーブルフォームに作ることもできるがテーブルに帰属させる必要性はない。フォームを整理するという側面からは、テーブルの内容を一覧する（配列に転送したとしても）ものはそのテーブルのフォームに作る、ことは意味があるかもしれない。

しばらくは、印刷用フォーム専用テーブル[Z_PrintForm]に印刷フォームを作成して、プロジェクトに印刷フォームがどのくらいあるかを把握できるようにしたい。フォーム名は出力するデータの元のテーブルのプレフィックスをつけて、１０番代から始める。たとえば上記であれば、PPというお売りフィックスのテーブルの１番目の印刷フォーム「PP11_」をつけてフォーム名を続ける。「PP11_SiharaiIchiran」とか。

以前のブログはこちら
4D プロジェクトフォームとテーブルフォーム、イベントプロパティが違う　その１

4D ローカル変数名にコロンが含まれていた

4Dでは、メソッド間で、たとえば呼び出す側が２つ引数を渡す時、呼び出される側のメソッドは第１引数を$1で、第２引数を$2で参照する。しかし引数名のまま$1や$2で参照すると、渡される値が何かがわかりにくいし、後で引数の順番が変わった時に不具合の元になるため、次のように記述して、引数をローカル変数に代入してから使うことにしている。こうしておけばREAD ONLY以降のコードを再利用しやすくなる、というオマケも期待できる。

C_LONGINT($1;$tr_id)
$tr_id::=$1
C_OBJECT($2;$objTR)
$objTR:=$2
C_TEXT($0;$numOfRecs)
READ ONLY([TRADEMARK])
QUERY([TRADEMARK];[TRADEMARK]TR_ID=$tr_id)
$numOfRecs:=Records in selection([TRADEMARK])
If ($numOfRecs=1)
  //オブジェクトで値を返す
$objTR.bikou:=[TRADEMARK]TR_BIKOU
End if 
$0:=$numOfRecs

上記のコードをよくみて欲しい。一つ目のローカル変数名にコロンが含まれていたのだ。これが不具合の原因だったのにしばらく気付かなかった。4Dは変数名にコロンを含んでていても構文エラーにならない。

たとえば「$tr_id:」をダブルクリックすると、「$tr_id」部分（コロンなし）が選択される。コピーして検索ダイアログを表示してペーストして検索実行すると、以下のコードの「$tr_id」は検索にヒットするため検索条件は正しく記述されているように見えて誤りに気付きにくい。ダブルクリック時に「$tr_id:」（コロンつき）を選択できていれば、検索実行で以下のコードにコロンつきの変数名がヒットしないことがわかったはず。そこで、変数名のタイプミスに気づくはずだ。

実行時のエラーにもならない。「$tr_id:」という変数に$1の内容を代入、QUERYでは未代入の「$tr_id」（値はゼロ）でクエリーしているだけだからだ。デバッガーで見ると呼び出した側は正しい値を与えているのに、なぜか期待した値がヒットしない、という結果になる。

「変数名にコロンを使える」という4Dの仕様に問題があるような気がする。「=」とか「-」を変数名に含めると構文エラーになるのに。

コロンを変数名に含めて良いのであれば、コロンが含まれた変数名をダブルクリックして選択した場合にコロンも選択範囲に含めてほしい。誤りに気づきにくい仕様になっていると思う。今回たまたま画面解像度が高くて文字が小さくなっていて、さらに焦ってコーディングしていたという事情はある。それにしてもこれまでこの事故が起こらなかったことが不思議だ。目視ですぐに気づいていたのか、こんなところでタイプミスはしなかったのか、老眼が進んでいなかっただけなのか？

試してみたらプロセス変数名も同様にセミコロンを含めることができた。見れば分かるだろというコーディングミスではあるけど要注意、というお話。

今回のハマりレベルは３、一人では抜け出せなかった。ハマりレベルとは、１：自力解決、２：ドキュメントで解決、３：他者によるサポートにより解決、４：翌日以降に解決、５：未解決。