「4D」タグアーカイブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


4D notarizeその２

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

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

（レベル１）

xcrun altool –notarize-appが失敗。

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

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

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

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

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

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


（レベル２）

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

–options=runtime

６）32bitコードが承認されない

→ ここからの話は長い。

Uploadedになると、notarizeの結果がメールで送られてくる。すぐに結果が見れないのはnotarizeに時間がかかるからだが、実際には数分待たされるだけ。で、結果はログに出力される。not approvedの場合、ログに理由が書いてあるので簡単に対策が立てられるはずだ。レベル１とはハマり方が違って楽勝だろう。まず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が正しくコピペできたことがわかる。５分後くらいにもう一度実行する。審査が終わっていれば次のような結果が表示される。

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


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

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

DBを集計した結果を画面に表示して、それをそのまま印刷したいと考えた。結構複雑な集計表なので印刷用と２つ作って両方をメンテするのは面倒。複数のテーブルから情報収集しているので、この印刷フォームは特定のテーブルに帰属させたくない、ということでプロジェクトフォームを作った。

4Dのフォームにはテーブルフォームとプロジェクトフォームがあって、前者はテーブルに帰属している、テーブルが削除されると同時に削除される。後者はプロジェクトに帰属していて呼び出し方が異なる。4Dv17

テーブルフォームを開くときはテーブル名とフォーム名を与える：Open form window([Table1];”P01_Print”)

プロジェクトフォームを開くときはフォーム名だけ与える：Open form window(“P01_Print”)

集計結果を画面に表示したところまでは順調。画面表示用なので［印刷］ボタンと［キャンセル］ボタンがある。当然だ。でも印刷時にはこれらのボタンを隠したい。いつものようにフォームメソッドの「On Printing Detail」でObject set visibleしようかな、と。やろうとしたら、

◆ プロジェクトフォームのプロパティに「On Printing Detail」イベントがない！

テーブルフォームじゃないとこれらのイベントは取得できない、らしい。Object set visibleなどのコマンドはフォームオブジェクトがロードされた後でないとコマンドが無効になるので、フォームがロードされた後、印刷が始まる前までに実行したい。選択肢は次の２つ？

１）プロジェクトフォームのままで、「On Load」イベントでボタンを制御

２）テーブルフォームに変更して、「On Printing Detail」を使う

今回のケースでは、複数のテーブルからデータを集計するのだが、カレントセレクションは使わないためどちらのテーブルに帰属させても動きに問題はない。しかしどちらのテーブルにも帰属させたくない。あとでメンテするたびにどちらのテーブルか思い出す必要があったりするので。

とりあえず１）を試す。

◆ Print formコマンドで「On Load」イベントが来ない！

そうかもしれない、今回のケースでは自身のフォームが画面表示用としてすでにロードされているから。これが別のフォームを開く場合だったら［印刷］ボタンクリックのあとで別のフォームがロードされてOn Loadイベントが発生するのに。

ほかに方法もありそうだけど、このあたりで方針変更して、２）に宗旨替え。

で、どのテーブルに帰属させるか。昔プロジェクトフォームがなかった頃はすべてのがテーブルフォームだった。[Z_Dialog]とか[Z_UserInterfae]とかフォームを作るためだけのレコードのないテーブルを作ってた。これをやりたくなかったけど仕方がない。あとで探しやすいように印刷用フォーム専用の[Z_PrintForm]という名前のテーブルを作ることにした。フォームの名前はP01_のようにPで始めたり、PF01_のようにPFで始める。

以上が印刷用フォーム専用テーブル[Z_PrintForm]ができた背景。これは4Dv17の場合であり、将来の4Dでプロジェクトフォームでもテーブルフォームと同様に「On Printing Detail」がサポートされたら[Z_PrintForm]を廃止するか、というとそうでもない。印刷用フォームを１箇所に集めておく意味はありそうだし、これはこれで悪くないと思う、今のところは。

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

4D: TEXT型のフィールドにインデックスを張るときの注意

TEXT型のフィールドにインデックスを張るときの注意

フィールドに保存した文字列を検索しても該当しない、という現象にはまりました。（はまりレベル３）

テーブルHBにテキスト型のフィールドを追加しました。そのフィールドにHBのすべてのレコードについて、メソッドで求めた文字列を保存しました。その保存した文字列で検索しても該当しない、のです。

１対Ｎ構造のテーブルがあって（テーブルHBとテーブルKJ）、Ｎ側（テーブルKJ)のラインナップが同じであるテーブルHBのレコードを探す、という機能を実装していたときのことです。ロジック的には、テーブル HBの各レコードについてテーブル KJをクエリして判定すればいいのですが、テーブルHBにはレコードが１万件以上あって、遅くてとても実用になりません。テーブルKJをキャッシュして配列に持たせても同様に遅い、という状況でした。

処理の高速化を図るため、テーブルHBに「HB_KJLINE」というフィールドを用意して、KJ_IDをコンマ区切りの文字列で連結して保存します。こうしておくと上記のクエリはテーブルHBだけをクエリすればよいことになります。検索時に遅いので保存時に一つ余計なフィールドを用意して検索のための値を保存しておく、というデータベース高速化の常套手段です。

高速化のためのコーディングですから、追加したHB_KJLINEにはインデックスを作成しました。HB_KJLINEの文字列は255文字を超えるでしょうからテキスト型です。そして実行、値はHB_KJLINEに入っていますが、あるはずの文字列で検索しても該当なし、です。

カレントテーブル表示（コマンド＋Uキー）でクエリ（コマンド＋Y）して、そのフィールドに入っている文字列で検索してみても、該当しません。一つレコードを保存してみると、保存したレコードだけ正常に該当します。

（4D Japanのサポートに電話して解決しました。）

原因はインデックスにありました。テキスト型のフィールドにインデックスを作成した場合、最初の1,024文字までしか結果が保証されない、という4Dの仕様です。HBには380個以上のKJを持つものがあり、この場合KJ_IDがコンマを入れて一つ４〜５文字とするとKJLINEの文字数は1,024文字を超えます。インデックスのチェックを外したら検索できるようになりました。

教訓１：

テキスト型のフィールドにはインデックスを作成しない。高速化を図る場合は別の方法を考えること。

ここで次の教訓も覚えておきましょう。

教訓2：

4Dでは、レコード数が32000件以上の場合、FInd in Arrayの該当レコード番号が保証されなくなる。（はまりレベル５）