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

4DアプリをNotarizeするぞ、Catalina対応

これまで4Dアプリは、署名つきビルドをすれば、macOS Mojaveまでは、control+クリックで「開く」を選択すれば、実行することができた。

macOS 10.15 Catalinaは厳しい。Appleのいうところの「notarize」をしていないアプリをダウンロードして実行しようとすると、Controlクリックだろうが環境設定のセキュリティでなんとかしようとしても開けない。異常終了させられる。同じアプリをビルドしたマシンで起動させれば正常に動くし、USBで持っていけば別のマシンでも正常に動くのに。つまりアプリそのものは実行可能であるにも拘わらず、ネットから落としてきたというだけで悪者アプリのレッテルを貼ってくれる。

で、notarize。参考資料はここ↓、さすがです。

https://www.rk-k.com/archives/3458

xcodeでビルドするアプリはxcodeがこの辺りを上手いことやってくれるので、実際に何が行われているかはわかりにくい。アールケーさんありがとうございます。ターミナルコマンドでやってくれているのが助かります。4Dアプリにとっては必須ですので。

ここからは4Dアプリの場合:

4D v17.3で署名つきでビルド。まず拡張属性を取り除こう。特にResourcesフォルダとかにネットで管理しているテキストファイルとか画像ファイルを置いている場合は要チェック。まず

xattr -rc 「パス名」

これで「パス名」の中のフォルダの中まで拡張属性を取り除いてくれる。次に4Dをアプリケーションビルド。

治郎吉商店では、できたアプリとデータファイルなどをバンドルして出荷するので、出荷前にアプリを起動してデータファイルを作成。できた出荷用アプリを複製してデータファイル作成用アプリを作って起動。データファイル作成後は複製したアプリを削除。

この出荷用アプリはまだ実行されていないものを使う

出荷フォルダには「お読みください」などのファイルを配置。できたフォルダが次。

これが出荷イメージ

これをディスクユーティリティの機能でdmg化する。ターミナルを起動して、次を実行。圧縮のオプションを使っている。

実行すると ・・・ と表示されて実行しているのがわかる。結構時間がかかる。

ここでも拡張属性に注意。「お読みください」などのファイルを誰かに編集を依頼して、ネットで落とした場合は拡張属性がついてしまうのだ。codesignに失敗することになる。

次はnotarize

このコマンドは成功する時が長い。dmgよりも長い。何も表示されずいきなり終わる。

これでできたのをzip圧縮する。なぜかWordPressのサイトにdmgがアップできないからね。しばらくすると(数分?)Appleからメールが来る。

このケースではビルドのタイムスタンプとメールのタイムスタンプの差はおよそ8分。

ShareDocにアップして、別のCatalinaマシンで試す。Catalinaで動いた!ちなみにアップしたマシンはMojaveでした。

4Dでバーコード

4Dアプリでバーコードを作成することになった。で、調べてみるとgithubにありました。プラグインとコンポーネントの両方があったので、まずコンポーネントを試すことに。プラグインよりもコンポーネントの方が4Dのバージョンとの互換性的がありそうなので。

https://github.com/miyako/4d-component-barcode

 //JANコード(SVGピクチャ)を作成

$bar:=Barcode_create ($code;”EAN13″)

確かにできた、けどEAN13とCode_39はできたけど、他の3つはできなかった。

バーコードスキャナー opticon C-41で試したところ、画面に表示されたEAN13には反応したが、Code_39には反応しなかった。

上から2つ目がEAN13、5つ目がCode_39


会計ジロウ法人 発売開始について

ブログ 会計ジロウ法人 発売開始について

2018年3月に発売開始した会計ジロウですが、青色申告版「会計ジロウ」に加えて、法人版「会計ジロウ法人」を販売開始することができました。関係者の皆様、ご協力ありがとうございました。

青色申告版は消費税を「税込」でしか扱うことができませんでした。このため課税事業者で青色申告している方にはお使いいただけませんでした。法人版は、税込入力方式は青色版と同じですが、消費税を税抜で決算書を作成できる機能が実装されています。課税事業者、非課税事業者のどちらの場合でもお使い頂ける仕様になっています。決算書の形式は青色とは異なりますが青色申告の個人事業主の方にもお使いいただけます。なんといっても最大の特徴は消費税の自動計算&シミュレーションです。

治郎吉商店では、従来から税込入力、税抜決算書で法人税を申告してきました。簡易課税を検討することもできますが適用していません。売上が1千万円以上5千万円以下なのです。当社の場合、会計ソフトには次のような機能が必要と考えました。(Aクラス)

A1)金額を税込で確認できること
A2)税抜のBS、PLを確認できること
A3)消費税計算書

このほかに目標とした機能として次があります。(Bクラス)

B1)複数年のデータを一つのファイルに保持して、過去の仕訳を確認できる
B2)「あとで確認」の機能を設けて、未確定な仕訳があることをわかるようにする
B3)経営分析のために損益推移表を出力できるようにする
B4)BS、PL、損益推移表の項目は編集することができる

今回のリリースには間に合いませんでしたが次のもあります。(Cクラス)

C1)減価償却費の月額を自動仕訳

これらのほかに、会計ソフトとして必須な機能があります。(Zクラス)エクセルのテンプレートでは実装できない機能です。

Z1)借方貸方の合計があっていない伝票は登録できない
Z2)借方貸方の合計があっていない開始残高は登録できない
Z3)借方貸方の合計があっていない仕訳データはインポートできない
Z4)勘定科目は科目コードで指定、選択画面で選択も可能

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

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プロジェクトからの移行時の注意

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

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

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

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

コード1:
C_OBJECT($obj)
OB Set($obj;”sl_id”;String(1))

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

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

コード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でセットされたプロパティの内容は、ドット表記でも参照できるし、その逆も可能だが、混在はやめたほうが良い。たいした手間ではないのでドット表記に統一しておくことをおすすめする。