4D v17のオブジェクト、v15プロジェクトからの移行時の注意

オブジェクト型を使う際に気をつけたいことに遭遇したので記す。今回はv15以前からのプロジェクトをv17に変換したケース。

当社では「JCL4D」という共通ライブラリを用意していて、v15以降でサポートされたMETHOD xxコマンドを使って、プロジェクトに読み込んで利用している。JCL4Dは各メソッドをテキストファイルに書き出して、GitHubにて管理している。

最近このJCL4D v17版を作成した。以下「JCL4Dv17」にはフォームをリサイズする機能が含まれている。ユーザがウインドウをリサイズした際に、4Dの拡大／縮小的な動きではなく、ボタン、リストボックス、フィールドの縦横が拡大／縮小、フォントサイズも大きくなったり小さくなったりする、ズームのような機能だ。ユーザがリサイズした際のズーム比率や、フォーム上のオブジェクトの座標を覚えておいて、あとでセットするために、オブジェクト型の変数を構造体のように使って実装した。この機能をv15から変換したプロジェクトにも読み込もうとしたところ、今回のケースに遭遇。

データベース設定の互換性のところに次のオプションがある。v15から変換したプロジェクトでは、このチェックは外れている。

□　オブジェクト記法を使用してオブジェクトのプロパティにアクセスする

JCL4Dv17はこのチェックがついていることを前提にしているので、どの道チェックすることになる。チェックしてからメソッドをインポートすれば問題は起こらなかった。うっかりチェックを外した状態で、自社製インポートメソッドJCL_A_method_importを実行すると、オブジェクト参照のところに変なゴミが入る。外部テキストファイルからメソッドを読み込んでMETHOD SET CODEするメソッドだ。問題の箇所を一部抜粋したのが次のコード（A）。

このコードでは、親メソッドから第三引数にオブジェクトのポインタをもらって、そのフィールドを参照している。「$inObjPtr->rowsHeight」となっていたコードにドット（.）が挿入されて「$inObjPtr->.rowsHeight」になっている。もとの外部テキストファイルのコードは次（B）。

…
C_POINTER($3;$inObjPtr)  //リストボックス情報オブジェクト
$inObjPtr:=$3
…
  //行の高さ
C_LONGINT($rowsHeight)
$rowsHeight:=($inObjPtr->rowsHeight)*$ratio
LISTBOX SET ROWS HEIGHT(*;$inListbox;$rowsHeight)
…

データベース設定で「オブジェクト記法を使用してオブジェクトのプロパティにアクセスする」にチェックしてから、あらためて外部テキストファイルからメソッドを読み込んでMETHOD SET CODEしてみたのが次のコード（C）。

「$inObjPtr->」の後ろのプロパティ名が認識されて、カラーシンタックスが正しく適用されている。ドットは挿入されていない。

「$inObjPtr->」は実体であるため、実体にドットを付けてobject.propertyという形に勝手に変更されてしまったのだろうか。METHOD SET CODEの仕様なのか、別のコマンドによるものか確認はしていない。

いずれにしてもv17以降では、そもそもオブジェクト型の変数は、もともとポインタのようなものだから、引数に渡す際にポインタにする必要がない。C_TEXTやC_LONGINT型の変数と同じように、オブジェクト型のまま渡せば良くて、参照渡しなのでプロパティに値を代入して戻すこともできる。

だから上記のコードも次のように変更するべきだ。

【注意】この表記はv15以前ではサポートされていない。

4D v17のオブジェクト、v16プロジェクトからの移行時の注意

v16からv17に移行したプロジェクトの場合、データベース設定の「互換性」に次の項目がある。

１）オブジェクト記法を使用してオブジェクトのプロパティにアクセスする
２）オブジェクトではISO日付フォーマットの代わりに日付型を使用する

v17で新規作成したプロジェクトにこれらの項目はない。
オブジェクト型の変数はv15から使えていて、その当時は次のコード1のような使い方だった。

コード１：
C_OBJECT($obj)
OB Set($obj;”sl_id”;String(1))
…

$sl_id:=Num(OB Get($obj;”sl_id”))

ところがv17では次のコード2のように使う。

コード２：
C_OBJECT($obj)
$obj:=New object
$obj.sl_id:=1

…
$sl_id:=$obj.sl_id

両方とも使ってみたが生産性が違う。単なる表記の違いではなく機能が違う。コード1では、オブジェクトのプロパティに”sl_id”のように文字列を指定しているが、ダブルクオーツで囲むためカラーシンタックスが働かない。カッコ、ダブルクオーツ、セミコロンで囲まれているためか、フィールド名が違っていても気づきにくい。また、一部サポートされていないデータ型があるため、当社では上記のようにすべて文字列としてプロパティに値を代入していた。その結果としてオブジェクト内部ではデータ型は失われていたことになる。型チェックは働かない。

コード2では、ドットに続く表記はフィールド名になる。カラーシンタックスが働く。オブジェクト内部でデータ型が維持される。型チェックが働く。いいことしかない。

OB Setの記述を見つけたら、今のうちに全部置き換えておこう。OB Setは、コードの見た目も良くないし、v15からの実装という新しめのコマンドながら、すぐに博物館行きになりそうだ。ちなみにOB Setでセットされたプロパティの内容は、ドット表記でも参照できるし、その逆も可能だが、混在はやめたほうが良い。たいした手間ではないのでドット表記に統一しておくことをおすすめする。

リストボックスのプロパティで「セレクションハイライトを非表示」4D v17

行背景色配列（バックグラウンドカラー）、行フォントカラー配列（フォントカラー）を与えると、セレクションハイライト中のフォントカラーを制御できない、という問題が、v17で回避できるようになった。

v16以前は、次の図のように、選択行はOSで指定された色になり、文字色は黒、または指定した色になっていた。

文字色が反転しないため、これではハイライト色と文字色が近くなってしまって読みにくい。v17のプロパティで次の設定項目「セレクションハイライトを非表示」が追加された。これをチェックしてハイライトを自力で処理できる。自力ハイライトと呼ぶ。

図のようにリストボックスのプロパティで、次の3ヶ所に注目。

１）「セレクションハイライトを非表示」にチェック
２）「行背景色配列」に「vA01TB_lstBR_BakColor」を指定
３）「行フォントカラー配列」に「vA01TB_lstBR_FontColor」を指定
４）リストボックスのOn Loadで配列に色を代入
５）リストボックスのOn Selection changeで選択された行の背景色とフォントカラーを代入

すると次のようになる。

・色つきの行：文字が緑で背景が黄色　→　自力ハイライト：文字が黄色で背景が緑
・色無しの行：文字が黒で背景が白　→　自力ハイライト：文字が白で、背景が緑

勝手にハイライトしてくれないので、色を付けていない行も含めて、選択行が変化したときに常に配列に色を代入する必要がある。色は、配列に代入したときに適用されてリストボックスに表示される。