programing」カテゴリーアーカイブ

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のプロジェクトもあるが、コーディング規約を改訂するときがきたようだ。

4DのDrug and Drop

4D Drug & Drop

ひとつの画面に複数の画像を表示する仕組みを考えていた。画像は外部ファイルを想定、多くて10個くらいあるのだが、要望としては代表的な画像を2個登録したい、ということだった。例えば画像は2個と限定してピクチャー変数を2つ配置しておけば、ドラッグ&ドロップを2回やれば画像登録ができる。操作も実装も簡単だ。しかしプログラマーとしては、3個以上の画像がありうるのに2個に制限して良しとするのは敗北感がある。

そこで考えた。リストボックスがいいんじゃないか?リストボックスなら画像をいくら追加しても大丈夫。行が増えていけば勝手にスクロールしてくれる。画像の数を制限しなくて済む。画像は別テーブルに保存すれば良い。

いつものようにリストボックスの上に[+]と[ー]のボタンを置いて、[+]クリックで表示されたダイアログにピクチャー変数を配置してドラッグ&ドロップしてもらって、という仕様で実装した。

これだとダイアログボックスを開いて閉じるのが面倒。もともとの要望の通り、ピクチャー変数を2個、配置しておけば、ドラッグ&ドロップを2回やれば画像登録ができる。その方がユーザは簡単だ。同じように簡単な操作で複数の画像を登録する方法はないのだろうか?

リストボックスに画像をドロップすればいいのでは?

リストボックスに画像をドロップしたら行が増えていくようにすれば操作性は悪くない。ドロップのたびに行を追加、削除するときは[ー]ボタン。増やしたり減らしたり、縦スクロールなら実装も簡単そうだ。

ただリストボックスに画像をドロップしても標準的な機能では受け取ってくれない。リストボックスのOnDropイベントにコードを書くことになる。OnDropで配列要素を増やして、画像列に取得した画像を代入すればいい。と、ここまでわかったところで気がついた。一般に4DでDrug&Dropをい実装する場合は、フォームオブジェクトが勝手に処理してくれるからコードを書く必要がない。マニュアルサイトを見ても、イベントを取得したあと、ドロップされたコンテンツをどうやって受け取るか、よくわからない。

とりあえずリストボックスにイベントハンドラを書いて。

ドロップされた画像はドラッグ&ドロップ専用のペーストボードから取得するそうです。

GET PICTURE FROM PASTEBOARD($picture)

OnDropで呼ばれるコードはこれ。

リストボックスに行を追加したり、自動スクロールさせたり、ついでにドロップされたファイルのパスを取り出したり、している。

ドロップされた直後に行を選択して、自動スクロールさせていてる

4D v18のテキストベースプロジェクトでgit

4Dはv18から、プロジェクト全体をテキストファイルに書き出してgitで管理できるようになった(涙)。これまでは自力でメソッドを外部テキストファイルに書き出して共通ライブラリメソッドだけgitでバージョン管理していた。フォームはテキストに書き出すことができないし、データ構造は別の仕掛けで書き出していたり面倒だし、なんといっても自力で書き出した情報は一体として動くプロジェクトを保証するものではなかった。

早速やってみよう。今回の目的は、半年間の間に行われたあるプロジェクトの変更内容を調べるというものだ。ローカルリポジトリを使って半年前のプロジェクトと今のプロジェクトを比べる。リモートのリポジトリは不要だ。

ステップ1 プロジェクトに書き出し

20190530のソースv17をv18で開いて「ストラクチャーをプロジェクトに書き出し」を実行。パッケージの中に「Project」フォルダができている(A)。

「Sources」フォルダを見てみると感動。フォーム、メソッド、テーブルフォームとそれらやオブジェクトのメソッドが並んでいる。フォームには「.4DForm」メソッドには「.4dm」という拡張子がついているのですぐわかる。

20191217のソースv17をv18で開いて「ストラクチャーをプロジェクトに書き出し」を実行。同じように「Project」フォルダができている(B)。

ステップ2 gitリポジトリを作る

次にgitフォルダを作る。ここでは「git_work」というフォルダを作っておく。ここにgitのリポジトリを作るのだ。gitのコマンドラインツールを使う方法もあるけど、差分をグラフィカルに見たいので今回は「GitHub」アプリを使った。

File -> New Repositoryを実行。リポジトリ名「dcc_git」、git_workを選択する。

ステップ3 リポジトリに「Project」ファイルを保存してコミット

(A)を「dcc_git」フォルダにコピー。GitHubでリポジトリを開くとソースが並んでいる。

SummaryとDescriptionをタイプインして[Commit to master]をクリック。これで最初のテキストファイル群がgitリポジトリに書き込まれた。

ステップ4 比較対象の「Project」ファイルを保存

最初にコピーした(A)を(B)で上書きして(A)がなくなってしまうのだが、ご心配なく。すでに(A)の内容はgitのコミットコマンドによって.gitファイルにコピーされているのだ。.gitは隠しファイルなのでターミナルアプリを使って確認できる。さあ(A)を上書きして(B)を置き換えよう。

ステップ5 GitHubで変更箇所を確認

GtHubアプリを起動して、リポジトリ「dcc_git」を見ると...。48箇所変更されていると表示されている。4dFormをクリックすると...うう感動。フォームの修正箇所、この場合座標値が変更されているのがわかる。うれしい。

フォームの座標値が変更されたことがわかる。ピクセル単位。
メソッドはこんな風に

修正箇所がすべてリストアップされている。やってくれました4Dv18。これからの4Dライフが大きく変化しそうな瞬間でした。

思えば2014年のDeveloper Summitでフランスに行ったとき「フォームをプログラムで作成したり修正することができないの?」と質問、そのときはv15では予定なしと言われた。今回のテキストベースプロジェクトの仕組みを使えば、メソッドでフォームを生成したり、修正することができる。こんな形になって実装されてくるとは。


4D notarizeその2

2020年4月、4DでビルドしたmacOS Catalina配布アプリを作ったときのメモ。2019年からCatalina用にnotarizeして配布していたのだがそのときの手順どおりにうまくいかない。2020年2月、アップルの方針が変わったらしい。32bitコードが含まれているとnotarizeで承認されない、というのが本題なのだが、本題の前にいくつか障害があって手間取った。思えば2019年は「2ファクター認証」や「Catalinaのためのnotarize」でハマった。障害を乗り越えて安心しているとすぐにまた新たな障害が現れる、いつものことだ。次はハマりたくないと思ってこのメモを書いている。このメモも将来役に立つかどうかはわからないが、ないよりマシだろう。

4Dでビルドするアプリは、Xcodeでビルドするアプリと異なり、ターミナルからcodesign、xcrunを使う。今回のポイントは2段階あって、1段階目はxcrun altool ―notarize-appがエラーになる段階(レベル1)、2段階目はxcrunは成功してUploadedになるのだがnotarizeで承認されない段階(レベル2)。

(レベル1)

xcrun altool –notarize-appが失敗。

本当はここの話の方が長くなるけどさらっと

1)Apple Developer Connectionでライセンスを承認していなかった。 → パスワードとかやばかったけどクリア。承認はオーナーでログイン。

2)AppStore connectに署名サインが必要 You must first sign the relevant contracts online. (1048) → ログインして「有料アプリケーション契約」に署名

3)MojaveでXcode 11.2.1のxcrunが使えない? → MojaveでXcode 10.3をインストールして実行。自分のマシンをCatalinaにしたくないのだ。

4)App用パスワードが無効になっていた → 別のCatalinaマシンでビルドしようとした際にiCloudの同期でおかしくなった? → パスワード再作成

これもxcrunが失敗。「app-specific passwordでサインインしてね。パスワードはappleid.apple.comで作れるよ」と言っている
アップロードが成功した時のメッセージ


(レベル2)

5)notarizeコマンドにHardened Runtimeオプション → オプションをつけた

–options=runtime

6)32bitコードが承認されない

→ ここからの話は長い。

Uploadedになると、notarizeの結果がメールで送られてくる。すぐに結果が見れないのはnotarizeに時間がかかるからだが、実際には数分待たされるだけ。で、結果はログに出力される。not approvedの場合、ログに理由が書いてあるので簡単に対策が立てられるはずだ。レベル1とはハマり方が違って楽勝だろう。まずi386とかログに出てる。

32bitコードが含まれていると承認されない、という話を聞いて、さっそく4Dプロジェクトのデータベース設定で、マルチターゲットコンパイルのチェックをオフと思ったら、ここはチェックされてなかった。次はコンポーネントのプロジェクトをチェック。こちらはマルチターゲットコンパイルがチェックされていたのでオフに。それでも通らない。楽勝ではなさそうだ。

notarizeのlogは、たとえば次のように見る。最初はメールを待っていたのだが、ダメな時のメールにはログを見ろとしか書いてないし、メールを取るまでの手間もあるので、こちらのほうが早く結果を知ることができる。暗号のようなところがuuidで、Uploadedが成功した時のメッセージに出力されているのをコピーして使う。たとえば、

xcrun altool –notarization-info b7229996-bdb8-48d4-82d7-467d5317efdd -u “wataru@jirokichi.jp” –password “@keychain:AC_PASSWORD””

Upload成功後にすぐに実行すると初めは「in progres」、これが出ればUploadのuuidが正しくコピペできたことがわかる。5分後くらいにもう一度実行する。審査が終わっていれば次のような結果が表示される。

nortarize失敗。Package Invalid

反転箇所のURLをコピーしてブラウザで見ると、

      “architecture”: “i386”

のところが32bitコードが含まれている、という意味らしい。

ビルドしたコードに32bitコードが含まれている?もしかして4Dの4D Volume Desktop.appに含まれているのでは?と思ってnotarizeのlogをよく見てみると、そのようだ。まず引っかかったのが「php-fcgi-4d」。次に「InternetCommands」。4D v17.4 mac版には32bitコードが含まれていない、はずなのだが、なぜかビルドした結果の.appには含まれてしまっているようだ。サポートにVoumeDesktopには4D Internet Commands.bundleに含まれている。「Windows」フォルダがあってここにWin32用のコードが含まれている、と聞いてこれをappのパッケージから削除しても結果は変わらず、承認されない。

で、4D v18.1に移行した。コンパイルしてビルド。codesignしてnotarize、あっさり承認された。4D v18 + Catalinaではまた別の変更があって新たな障害となって立ちふさがってくれるのだが...その話はまた後ほど。

参考サイト:

https://miyako.github.io/2019/10/16/notarization.html