4D Japan
テクニカルサポートブログ-
4D v19r4 修正リスト
-
最大同時Webプロセス数
Webサーバーのスケーラブルセッションを有効にした場合，下記のWebオプションは無視され，同時Webプロセス数の上限がなくなります。
Web inactive process timeoutWeb max concurrent processesWeb inactive session timeout
Webサービス（SOAP）はセッション管理の対象外です。スケーラブルセッションの設定は，Webサービス（SOAP）に適用されず，「セッションなし」の最大同時Webプロセス数が適用されます。これは仕様です。
-
ローカルキャッシュ
バイナリモードのクライアント/サーバーアプリケーションは，必要に応じてサーバーからメソッドのコードを受信し，ローカルキャッシュに保存するようになっています。このため，キャッシュされていないメソッドを実行しようとすると，サーバーとの通信が発生します。対照的に，プロジェクトモードでは，すべてのリソースを１回のリクエストで受信するため，メソッド実行時に通信が発生することはありません。これは仕様です。
-
Compile projectとプラグイン
Compile projectコマンドを使用すれば，デザインモードを操作することなく，自動的にカレントプロジェクトをコンパイルすることができます。たとえば，ソースコードをGitリポジトリにコミットするたびにクラウド上で自動的にプロジェクトがコンパイルされるよう，GitHub Actionをセットアップすることができます。GitHubは最新のmacOSおよびXcodeを提供しているので，Apple Siliconターゲットもサポートできます。ブログ記事: https://blog.4d.com/how-to-automate-the-compilation/
ワークフローの例: https://github.com/4D-JP/librezept/blob/main/.github/workflows/compile.yml
パラメーターを渡すことにより，外部プロジェクトをコンパイルすることもできます。外部プロジェクトをコンパイルする場合，プラグインやコンポーネントはロードされないことに留意してください。コンパイル対象のプロジェクトがプラグインやコンポーネントに依存している場合，それらのモジュールはコマンドを実行するプロジェクトにロードされている必要があります。これは仕様です。
-
zip圧縮の落とし穴
macOSとWindowsには，システム標準の圧縮ツールが用意されており，ファイルやフォルダーを右クリックして手軽にアーカイブすることができます。作成されるのは
.zip形式のファイルです。一方のプラットフォームで作成したアーカイブは，通常，他方のプラットフォームでも展開することができますが，プロジェクトをアーカイブする場合は注意が必要です。.zip形式のアーカイブには，UTF-8エンコーディングでファイルやフォルダーのUnicodeパスが書き込まれます。MacとWindowsでは，圧縮ツールが使用するUnicodeの正規化方式が違います。MacはNFC，WindowsはNFKDです。たとえば「ä」という文字をMacで圧縮した場合，C3 A4にエンコードされ，Windowsで展開すると61 CC 88にデコードされます。つまり，Macでは文字とアクセント記号（日本語の濁点・半濁点を含む）を合成した文字が優先的に使用されますが，Windowsでは文字とアクセント記号を分解した文字列が優先的に使用されるということです。Windowsのファイルシステムは，NFCとNFKDのファイルパスを区別し，実質的に同名のファイルを作成することができるようになっています。4Dのプロジェクトモードは，メソッドやフォームをNFCパスからロードするため，NFKDにパスが変換されてしまった場合，フォームやメソッドがみつからないことになります。
MacからWindowsに
.zip形式でファイルを移動する場合，システム標準の圧縮ツールは使用しないでください。代わりに7-ZipやWinRARを使用することができます。
-
Mac版システム要件の引き上げ
追記: ビルド
278080以降，v19をmacOS 10.14.6で起動できるようになりました。今後，Mojaveは互換対応（compatible）となります。仕様上は対応しているものの，開発部で毎回の検証はしていないということです。実機による検証は，Catalina, Bug Sur, Montereyの３世代が対象となります。Bug Sur以降はIntelとApple Siliconアーキテクチャが存在するので，現在５種類のMacがサポートされています。v19の技術的な最低プラットフォームはmacOS 10.14.4です（v19.0リリース当時と同じ）。macOS 10.13.6でv19のビルド
278080以降を起動した場合，起動時にアプリケーションがプラットフォームに対応していないという警告が表示されます。以下のブログ記事は調整前の実情を反映しています。
Mac版のv19.2および19r4の対応システムバージョンは「macOS 10.15.7 (Catalina)」以降となります。初期のv19ロングタイムサポート（LTS）バージョンおよびフィーチャーリリースは，macOS 10.14 Mojaveにも対応していましたので，仕様が変更されたことになります。
19r3のシステム要件は10.15.6（リリース当時の最新版Catalina）でしたが，サポート外のMojaveでも起動することができました。19r4をMojaveで起動することはできません。
4Dは，OpenSSLライブラリを使用しています。セキュリティ対策のため，当該ライブラリは定期的にアップデートすることが求められています。v18.5, 19.1, 19r3のOpenSSLバージョンは，
1.1.1lでした。19.2, 19r4では，1.1.1nにアップデートされました。このバージョンは，macOS 10.15.7以上でなければ動作しません。結果的に4Dの最低システムバージョンも引き上げられることになりました。注記: OpenSSLのバージョンは，
Get database parameterのセレクター94(OpenSSL version) で確認することができます。OpenSSLを使用するのは，Webサーバーだけではありませんが，WEB Get server infoもバージョン情報を返します。OpenSSLのバージョンが使用できないシステムで初期のv19.2および19r4を起動しようとすると，アプリケーションがクラッシュするかもしれません。クラッシュログには，OpenSSLがロードできないためのクラッシュである，というメッセージが記録されます。
DYLD, [0x1] Library missing dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: @executable_path/../Frameworks/libssl.1.1.dylib Referenced from: /Volumes/VOLUME/*/4D.app/Contents/MacOS/4D Reason: no suitable image found. Did find: 4D.app/Contents/MacOS/../Frameworks/libssl.1.1.dylib: cannot load 'libssl.1.1.dylib' (load command 0x80000034 is unknown) 4D/4D.app/Contents/MacOS/../Frameworks/libssl.1.1.dylib: stat() failed with errno=1 4D/4D.app/Contents/MacOS/../Frameworks/libssl.1.1.dylib: cannot load 'libssl.1.1.dylib' (load command 0x80000034 is unknown) 4D/4D.app/Contents/MacOS/../Frameworks/libssl.1.1.dylib: stat() failed with errno=1v19.2 (277563) および19r4 (277561) 以降，最初にバージョンチェックが実行され，プラットフォームが対応していない場合には警告ダイアログが表示されるようになりました。
-
4D v19.2 Hotfix 1 修正リスト
-
4D v19.2 修正リスト
-
新しいテキストレンダリング
ブログで解説されているように，19r3のWindows版では，テキストレンダリングのAPIがGDIからDirectWriteに切り替わりました。よりなめらかな描画システムのおかげで，高解像度ディスプレイにおけるテキストの可読性が向上しています。
リストボックスは，v15以前に作成されたものはGDI，v16以降で作成されたものはDirectWriteを使用しています。作成された時期により，リストボックスの外観がいくらか違うことがあるのはそのためです。移行期のバージョンでは，データベースパラメーターの
107番を変更することにより，リストボックスの描画APIを切り替えることができました。0: デフォルト1: DirectWrite2: GDI
19r3では，これがフォームのスタティックテキストとテキスト入力オブジェクトにも拡大されました。レンダリングの違いによって発生する「ずれ」の度合いは，使用するフォントによって異なりますが，ほとんどの場合，それは1ピクセル程度の違いです。しかし，GDIだけでサポートされているフォントの場合，DirectWriteでは代替フォントが使用されるため，大幅に外観が変わってしまうことがあります。また，1ピクセル程度の違いであっても，わかち書きする言語では折り返し位置がおおきく変動するかもしれません。
過去のバージョンで作成されたプロジェクトの場合，新しいテキストレンダリングは無効にされており，データベース設定の「互換性」で有効にすることができます。設定はコンポーネント単位に適用されます。
19r4では，高解像度ディスプレイにおけるテキストの可読性を考慮し，
ALERTやCONFIRMなどで表示されるフォームを収録したランタイムコンポーネントのDirectWriteが有効にされています。前述した違いに加え，DirectWriteではテキストの折り返し（ラインブレーク）のルールも違っています。たとえば，GDIではアンダースコア記号（_）でブレークできるのに対し，DirectWriteではどうしても幅に収まらない場合を除き，アンダースコア記号ではブレークできません。
-
旧式プリントレイヤー
SET PRINT OPTIONのドキュメントで説明されているように，Windows 64-bit版の印刷はDirect2Dベースの新しいプリントレイヤーが採用されていますが，セレクターのLegacy printing layer optionを指定することにより，GDIベースの旧式プリントレイヤーを選択することもできます。新しいプリントレイヤーは総合的な表現力が優れていますが，あえてシンプルな旧式プリントレイヤーのほうが望ましいように思えることがあります。下記の例では，文字数に応じてテキストの配置が微妙に調整されるため，新しいプリントレイヤーでは数字の桁区切り位置が微妙にずれています。縦方向に位置を揃えたいのであれば，文字ごとにオブジェクトを配置するなど，フォームのデザインを見直す必要がありますが，それまでの間，旧式プリントレイヤーのシンプルなレンダリングに切り替えることができるかもしれません。
- 旧式プリントレイヤー
- 新式プリントレイヤー
