4D」カテゴリーアーカイブ

4Dアプリ開発ガイドをv18対応に改訂、キーフィールドが必須に

4Dアプリ開発ガイドを改訂。v15対応(以下、旧ガイドと呼ぶ)をv18対応(以下、新ガイドと呼ぶ)にした。

4Dの仕様変更に従って一部内容を変えた。当時の4DはSQLと同様に「レコードのキーフィールドはなくてもいい」という仕様だった。Display selectionとModify recordでレコードを操作する場合はそれでよかった。しかし旧ガイドは、ハンズオンの目標としてリストボックスをダブルクリックするアプリを作る都合上「キーフィールドは必須」だ。そのためキーフィールドに格納するユニークなレコードIDを生成するためにシリアル番号テーブルを実装していた。SQLではよくやる手だ。

v18ではキーとなるIDフィールドの実装が必須になった。SQLとは異なる仕様だ。新ガイドではSQL的な実装をやめて4Dの機能を使うようにした。IDフィールドには、重複不可の属性をつけて自動入力属性でユニークIDを入れるという実装だ。これによりシリアル番号テーブルは不要になった。旧ガイドで実装していたのはシリアル番号テーブルとログインユーザテーブルの2つ。シリアル番号テーブルがなくなると、実装するのは「ログインユーザ」テーブル1つだけになる。これではガイドとして内容が薄いということで、新ガイドではログイン履歴を記録することにした。履歴の保存先としてアクションテーブルを実装。ログインユーザを表示すると、ユーザ名やパスワードとログイン履歴一覧を表示するアプリとした。

この結果として、新ガイドでは「ログインユーザ1件についてログイン履歴がN件あるリレーショナルデータベース」を実装することになり、1対Nのリレーショナル構造を実装するためのテーブル定義と画面表示について説明することになった。

ハンズオンのステップの多くは旧ガイドから流用した。誤字脱字は訂正し、デスマス調をデアル調に変えた。よく使うキーボードショートカットキーを示したり、コラム欄を追加して、なぜそのような実装にしているかの説明を増やした。附録のデバッグの章には、4Dのデバッガでよく使う機能についての説明を追加した。

4D 自力distinct

4D 自力distinctを作ってみたので紹介する。このコマンドはv17、v18で動作確認済み。

4DのDistinctコマンド

4DにはDistinctというコマンドがある。テーブルをクエリーしてセレクションができて、そのテーブルのフィールドの重複を排除したユニークな値の配列を取得できる便利なコマンドだ。

Distinctにはフィールドを一つしか与えることができない。たとえばユニークなコードの配列をください、そのコードに対応した名前の配列(ユニークでないかもしれない)を同時にください、というときは不便。Distinctを実行してもセレクションができるわけではないので、別のフィールドの値を取得するには、得られた配列のユニーク値をもとにしてクエリーし直さなくてはならない。

自力ディスティンクト

そこで「自力ディスティンクト」を作ってみた。ディスティンクトで得られるユニークなフィールドの配列を、データベース側のセットに実現することでセレクションを作る。このモジュールを呼び出すとIDがユニークな配列が返されると同時に、その配列の元になるカレントセレクションが用意される。呼び出し元ではユニークフィールド以外のフィールドの値はSelection to arrayで簡単に持ってこれる。セットを使っているので高速に動く。

このモジュールの特徴は、テーブル名を決め打ちしていることと、ユニークフィールドを整数に限定していること。別のテーブル用とかユニークフィールドが文字列以外の場合はこのモジュールを複製・修正して使う。MVCのモデルメソッドという位置付けである。

//JO_Distinct_byAC_ID
//20200821 wat
//自力Distinct //ジャーナルの勘定科目とカテゴリー
//セレクションは上位で作成しておく
//distinctキーとなるフィールドのポインタは整数、整数の結果配列を返す。

C_POINTER($1;$keyFldPtr)
$keyFldPtr:=$1
C_POINTER($2;$outIDAryPtr)
$outIDAryPtr:=$2 //結果の、IDの配列

C_LONGINT($ac_id)
C_LONGINT($i;$numOfRecs)
C_TEXT($setOrg;$setName)
$setOrg:=”set_org”
CREATE SET([JOURNAL];$setOrg) //最初は全件、評価したら除いていく
$setName:=”result_set”
CREATE EMPTY SET([JOURNAL];$setName) //最初は0件、まだないIDを追加していく

//元セットにレコードがなくなるまで繰り返す
USE SET($setOrg)
$numOfRecs:=Records in selection([JOURNAL])
FIRST RECORD([JOURNAL])
$ac_id:=$keyFldPtr->

While ($numOfRecs>0)
//結果セットを日付でクエリして、なければ追加、
USE SET($setName)
QUERY SELECTION([JOURNAL];$keyFldPtr->=$ac_id)
If (Records in selection([JOURNAL])=0)
//DB全体をクエリして最初のレコードを取得して、セットに追加
QUERY([JOURNAL];$keyFldPtr->=$ac_id)
FIRST RECORD([JOURNAL])
ADD TO SET([JOURNAL];$setName)

End if

//元のセットを日付でクエリして、元のセットからのぞく
USE SET($setOrg)
QUERY SELECTION([JOURNAL];$keyFldPtr->=$ac_id)
For ($i;1;Records in selection([JOURNAL]))
GOTO SELECTED RECORD([JOURNAL];$i)
REMOVE FROM SET([JOURNAL];$setOrg)

End for

//リデュースされた元セットの最初のレコードを取得
USE SET($setOrg)
$numOfRecs:=Records in selection([JOURNAL])
FIRST RECORD([JOURNAL])
$ac_id:=$keyFldPtr->

End while
CLEAR SET($setOrg)

//転送
USE SET($setName)
CLEAR SET($setName)


SELECTION TO ARRAY($keyFldPtr->;$outIDAryPtr->) //カレントセレクションがあるので、呼び出し元ではお好みのフィールドの値をSELECTION TO ARRAYで取得できる

使い方

呼び出し元では次のようにコーディング。この例では元となるセレクションは全件、このように元となるセレクションを作っておいて、そのセレクションの中でユニーク評価をして新たなセレクションを作る。呼び出し後に必要なフィールドの値を転送。

READ ONLY([JOURNAL])
ALL RECORDS([JOURNAL])<;br> JO_Distinct_byAC_ID (->[JOURNAL]JO_D_AC_ID;->$aryAC_ID)
SELECTION TO ARRAY([JOURNAL]JO_D_AC_CODE;$aryAC_CODE)
// SELECTION TO ARRAY(…

4D v18で変わった「Form event」コマンド

「4Dアプリ開発ガイド v18対応版」を制作していたらコマンドの仕様変更に気づいたので報告する。これまでに気づいているのは次の2つ、「FORM Event」と「PAGE SETUP」。

FORM Event

フォームイベントコマンドの仕様が変わった。以前は次のように記述していた。

//A02_frm
// オンロードメソッド
Case of
: (Form event=On Load)
A02_frmOnload
End case

このコードをv18にペーストして実行すると、次のようなエラーになる。

関数の結果が式と一致しません。定数のタイプが無効です。変数のタイプが異なるため比較できません。

ランゲージリファレンスを見ると、v18では戻り値がオブジェクト型になっていた。

https://doc.4d.com/4Dv18/4D/18.4/FORM-Event.301-5233147.ja.html

v15とかv17のプロジェクトをv18に変換すると、次のようなコードに変換される。

//A02_frm
// オンロードメソッド
Case of
: (Form event code=On Load)
A02_frmOnload
End case

「Form event」コマンドは「Form event code」に変更されて、オブジェクト型を返す「FORM Event」が新しく追加された、ということらしい。従来取得していた整数型のイベントコードは「code」というフィールドに格納されている。もともとコードしか返さなかったを、イベントのトリガーとなったオブジェクト名も返すようだ。いいかもしれない。これまでイベントハンドラはオブジェクトメソッドに書いていたが、フォームメソッドにまとめて書いて、「もしこのオブジェクト名だったら」という記述ができるようになったってことかな。

発生したcodeだけを必要とする場合はどちらのコマンドを使っても同じみたいだけど、オブジェクト型を使ってドット表記を参照する方が流行りっぽくてかっこいいかもしれない、とか色々考えて次のようにした。

//A02_frm
//オンロードメソッド
C_LONGINT($frmEvnt)
$frmEvnt:=FORM Event.code
Case of
: ($frmEvnt=On Load)
A02_frmOnLoad
End case

修正ついでに一旦ローカル変数に取得するようにした。これでデバッグしやすくなる。Case文に何回も書くと、その数だけFORM Eventが実行されてしまい、気づかれるほどではないにしても性能的によろしくないので。

PAGE SETUP

廃止になった。プロジェクトをv18に変換すると、次のようなコードに変換されている。

_O_PAGE SETUP

代わりのコマンドが用意されていて、SET PRINT OPTION/GET PRINT OPTION、Print settings to BLOB/BLOB to print settingsを使う、とランゲージリファレンスに書いてある。

https://doc.4d.com/4Dv18R5/4D/18-R5/o-PAGE-SETUP.301-5128159.ja.html

もともと「PAGE SETUP」は、印刷ダイアログを表示することなく、用紙とか印刷設定を前回と同様またはいつも決まった所定のセッティングで印刷したいときに使うコマンドであった。ユーザが毎回印刷設定ダイアログで設定してから印刷する場合は不要だが、印刷設定ダイアログを出さずに印刷したり、前の設定を覚えておいて欲しい場合に実装することになる。v18ではまだそのような仕様を使う状況に遭遇していないので、使うことになったらまた報告する。

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

4Dでは、メソッド間で、たとえば呼び出す側が2つ引数を渡す時、呼び出される側のメソッドは第1引数を$1で、第2引数を$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の仕様に問題があるような気がする。「=」とか「-」を変数名に含めると構文エラーになるのに。

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

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

今回のハマりレベルは3、一人では抜け出せなかった。ハマりレベルとは、1:自力解決、2:ドキュメントで解決、3:他者によるサポートにより解決、4:翌日以降に解決、5:未解決。

4Dのプロセス変数にゲッターセッターを記述するのはもう古い?v18で提供されたClassesのFunctionが使えそう。

プロセス変数とはプロセス内で参照可能な変数のこと。プロセスというのは同じマシンならNew Processなどで区切られたメモリー上の作業空間とでも言えばいいか。Client/Server環境ではサーバサイドで実行などにより実行マシンが違えば作業空間は異なるので別プロセスだ。別のプロセスの変数はそれ用のコマンドを使わないと参照できない。

人それぞれ違うと思うが、ウチの開発スタイルではプロセス変数は次の2種類がある。

(1)フォームオブジェクトに割り当てるためのプロセス変数
(2)プロセス内でグローバルに参照するために用意する主として制御用のプロセス変数

(1)は4Dの仕様上必要な変数。フォームが表示されている間はメソッドからフォームオブジェクトを参照したくなるはずで、メソッドが終わってもフォームがある限り解放されないプロセス変数であることが合理的だ。個人的に、次のように名前を付けている。

・ vPL01_btnOK:PL01というフォーム上の「OK」ボタンという意味。ボタンの場合はプロセス変数に代入することはない。オブジェクト名を参照しているだけ。

・ vPL01_lstPL:PL01というフォーム上の「lstPL」リストボックスという意味。vPL01_lstPL_IDやvPL01_lstPL_NAMEなどを列として定義、DBのPLというテーブルから持ってきた値を表示する。プロセス変数はプロセス開始時に領域が確保されるが、リストボックスはOnload前は参照できないので注意。

・ vPL01_txtPL_NAME:PL01というフォーム上の「PL_NAME」フィールドで、DBのPL_NAMEから持ってきた値を表示するためのプロセス変数という意味。

変数名とオブジェクト名は別の名前をつけることもできる。どちらもプロセス開始時に領域を確保されてしまう。特に困ったこともないので「オブジェクト名と変数名はいつも同じ」にしている。同じ値のオブジェクトには同じ変数名をつければどちらも同じ値が表示される。が、別々の名前をつけて値はコードで代入し直す方が主流だ。

(2)は、フォーム上に表示されない、プロセス内の制御用の変数。例えばよく使う変数としては、ダイアログを表示するメソッドの場合にどのフォームから呼ばれたかを示すモードのような変数「vPL01_varMode」とか、一覧で選択されていたIDを詳細画面で保持するための変数「vPL_varPL_ID」とか、印刷時に現在のページ数を印字するための変数「vP01_varPageNr」など、がある。

このような変数にはいわゆるゲッター/セッターを用意して直接参照はしないようにする。フォームオブジェクト以外は、基本的に変数はローカル変数にすべきで必要な関数に引数で渡して使う、という考え方がまずあって、オブジェクト型の変数が無かった時代は多くの引数が必要になってしまって面倒すぎるのでグローバル変数を使いたい、という時代背景がある。例えば「vPL01_varMode_get」と「vPL01_varMode_set」である。次のように使う。

//PL01_DefInit
・・・
C_TEXT(vPL01_varMode)
・・・

//vPL01_varMode_get
C_TEXT($0)
$0:=vPL01_varMode

//vPL01_varMode_set
C_TEXT($1)
vPL01_varMode:=$1

//PL01_SetContorolsValues
・・・
//新規追加モードの場合、削除ボタンは非表示にする
C_TEXT($mode)
$mode:= vPL01_varMode_get
if ($mode=“add”)
 OBJECT SET VISIBLE(*;”vPL01_btnDelete”;False)
end if
・・・

このように記述していると、メソッド内にはフォームオブジェクト以外のプロセス変数が現れなくなる。このやり方は、まだ4Dに不慣れな頃に師匠から伝授されたものだ。初めはなんでこんな面倒なことをするのだろうと思っていたが、今でもこのやり方を踏襲している。実はこの種のプロセス変数はそんなに多くない。メソッド数が増えてしまうが、たいして手間ではないし、このようにすることでデバッグタイムが少なくなっていると感じている。教えてくださった先輩に感謝!

この方法の欠点としてメソッド数が増えてしまうと書いた。わずか2行のコードのために新しいメソッドを作る手間も感じていたがv18で改善された。ClassesのFunctionを使えば、オブジェクト表記の延長で「vPL01_varMode.get」などとメンバー関数を記述できる。そしてなんと一つのメソッドエディタ内に複数のFunctionを定義してゲッターとセッターを記述できるようになるのだ。

Laurent Esnault氏のセッション。今年の4D Summit 2020はオンラインで無料。英語がダメでも画面見てれば大体わかる素晴らしいデモに感謝。その内容に感激!4Dライフが大きく変わること必至。

まだv13のプロジェクトもあるが、コーディング規約を改訂するときがきたようだ。