4D Japan
テクニカルサポートブログ-
PROJECT DATABASESシリーズ：スタイルシートを使ってフォームを美しくする
これまでの4Dバイナリー・ストラクチャは、macOSとWindowsプラットフォームの両方でフォーム中に使われるフォント、フォントサイズ、テキストのスタイルを特定するためのスタイルシートを定義できました。プロジェクト・データベースでは、さらに進化して4ステイト・ボタンのプロパティを定義したり、全てのライン・オブジェクトの色や境界線を特定したり、アプリケーションのリストボックス 全てのヘッダーの高さを設定することもできます！CSSの文法やシンタックスにインスパイアされて、4Dはプロジェクト・データベースのフォームの特定のニーズに合わせて改良しました。スタイルシートのおかげで、本当に視覚にアピールするフォームを作成するためのプロパティ全てを設定できます。このブログでその方法を紹介します！
プラットフォーム
プロジェクトデータベースでは、両方のプラットフォーム（WindowsとmacOS）に対して、個々のスタイルシートと「オーバーオール（全てに適用）」スタイルシートを定義できます。
なぜプラットフォームごとに異なるスタイルシートが必要なのでしょうか？それは、macOSで使われるフォント/フォントサイズはWindowsのものとは異なることがあるからです。その一方で、テキストのカラーはどちらも同じということがよくあります。
”Stylesheets.css”ファイルと独自のファイル中のプラットフォーム指定のスタイルを定義できるようになりました：”stylesheets_mac.css”と”stylesheets_windows.css”です。
プロパティー
プロジェクト・データベースの主な改革の一つは、フォームオブジェクトがサポートする全てのプロパティーをスタイルシートの中で使えることです。
例えば、”ボタン-アクション”クラスを作成して、”ツールボックス”状で、グレイのテキストの、フォーカス化できない4ステート・ボタンを作成することができます。
.buttonAction {
iconFrames: 4;
style: toolbar;
stroke: grey;
focusable: false;
}
これにより、同じグラフィックデザインを保持しながら、アプリケーションに対するデザインフォームを簡単に作れます。
セレクター
もう一つの大きな変更は、クラス、オブジェクトタイプ、オブジェクト名、属性によってスタイルシートを作成できることです。
オブジェクトタイプ・セレクター
オブジェクトタイプ・セレクター（CSSエレメント・セレクターと同等）を使うと、データベース中の全てのオブジェクトに適用できる汎用的なプロパティーを定義できます。例えば、全てのリストボックス が２行のヘッダーを持ち、空の行は表示されない、列の背景はgainsboroとwhitesmokeにします。
listbox {
headerHeight: 2em;
hideExtraBlankRows: true;
fill: Gainsborough;
alternateFill: white smoke;
このセレクターのおかげで、フォームオブジェクトに独自の外観とフィーリングを定義できます。
アトリビュート・セレクター
アトリビュート・セレクターを使うと、プロパティの値によってスタイルシートを定義できます。
例えば、データの入力/出力フォームで、レコードの追加、編集、削除のボタンがあります。これら全てのボタンは同じアイコン、タイトル、ヘルプティップを使います。
アクションボタンにスタイルシートを作成して、アクションプロパティに特定の値を指定しないのはなぜでしょう。例えば、もしアクションプロパティが”editSubrecord”の場合：
.buttonAction[action=editSubrecord] {
icon: url(“/RESOURCES/Images/Buttons/edit.png”);
tooltip: “:Cliff:button_tip_EditRecord”;
text: “:xliff:button_EditRecord” !important;
}
ボーナスとして、実際の動作をデモしています！
-
PROJECT DATABASESシリーズ：アーキテクチャ
プロジェクトデータベースは、4D v18リリースのヘッドラインで、チームがコラボレートして作業できるように、アプリケーションのコードをソース管理システムの中に保存することができます。そのテキストファイルの中には、フォーム、メニュー、ユーザー設定、あらゆる必要なリソースを含めて、データベース・ストラクチャからユーザー・インターフェイスまであります。そして、プロジェクトデータベースはテキストベースのファイルでできているため、いくつかのフォルダとファイルを一つの親データベース・フォルダの中に保存します。このブログでは、プロジェクトデータベースのアーキテクチャを見ていくことで、新しいタイプのデータベースをよりよく理解しましょう。
PROJECT DATABASEのアーキテクチャ
プロジェクトデータベースは、一つの親データベース・フォルダの中に保存された、いくつかのフォルダとファイルで構成されています。
プロジェクトデータベースを作成する時、ほとんどのフォルダが同じ伝統的なバイナリーデータベースであることに気づくでしょう：
- データ
- ログ
- リソース
- セッティング
- ウェブフォルダ プロジェクトデータベースは二つの追加フォルダを含みます：
- Project – アプリケーション・ソースコード（4DBと同等）
- userPreferences.
- このフォルダはユーザー設定（例：ブレークポイントの位置、ウィンドウ位置など）を記憶するファイルを含みます。
プロジェクトとソース管理
プロジェクトデータベースの中にフォルダとファイルがあることが分かりましたが、どのフォルダとファイルをソース管理システムにアップロードすべきでしょうか？おそらく、ResourceとProjectフォルダと考えるでしょう。では、データベースをコンパイルするときに、4Dは”Project/DerivedData”フォルダにコンパイルしたコードを保存します。従いまして、”Resources”フォルダ、”WebFolder”、”Project”フォルダ（サブフォルダの”DerivedData”は不要）をソース管理システムにアップロードすることをお勧めします。
バイナリーデータベースvs プロジェクトデータベース
このビデオでは、バイナリーデータベース(.4DB)とプロジェクトデータベース (.4DProject)のアーキテクチャを比較します。
例えば、自分のバイナリーデータベースを開くには、”.4db”あるいは”.4dc”拡張子のファイルを選択します。project データベースで同等のものは何でしょう？それは”.4DProject”拡張子のファイルです。
コンパイルされたデータベースに対して、”.4DC”に代わるものは何でしょう？バイナリーデータベースでは、アプリケーションのソースコードは”.4DB”と”.4DIndy”拡張子のファイルにありました。プロジェクトデータベースでは、ストラクチャに関係するフォルダやファイルはどこにあるのでしょう？
これらの疑問の答えは下記のビデオで見つかります：
-
PROJECT DATABASESシリーズ：バイナリからテキストベースへ
4D v17 R5で新しいタイプの4Dデータベース：プロジェクト・データベースのベータテストを開始しました。4D v18では、プロジェクト・データベースが最終リリースになったことをお知らせします。今こそ軽い分散型フォーマットの多用途性と組み合わされた4Dの開発プラットフォームのパワーを活かす時です！
プロジェクト・データベースは、伝統的なバイナリー・フォーマットではなく、テキストベースのファイルを使って4D中で開発されます。プロジェクト・データベースを作成するには：
既存のデータベースを変換
バイナリー・データベースをプロジェクトに変換するには、シンプルに”ファイル”→”書き出し”→”ストラクチャからプロジェクト”メニュー項目をクリックするだけです。
一度バイナリー・データベースの変換が完了すれば、その成功を知らせるメッセージが表示されます。4Dはまた、手を加える必要があるエラーが見つかった場合もお知らせします（例：すでにサポートされていない古いフォーム・オブジェクトがある）。
さらに詳しくはこのドキュメントを見てください。
具体的なサンプル
以下のビデオでは、4D ウェブサイトからダウンロードできる”Contacts”データベースを変換しました。
“ファイル→書き出し→ストラクチャからプロジェクト”メニュー項目の使って、バイナリーストラクチャ・ファイル(.4DB)をprojectに変換します。4Dは交換の間にエラーが発生したことを知らせてくれます。ログファイルを開いたとき、データベースがハイライト・ボタンを使うことに気づきます。上記のように、プロジェクト・データベースでは、古いオブジェクトの中にはサポートしていないものもあります。
この場合、シンプルにボタン・タイプをハイライトから非表示に変更します。データベース中では、”ボタン”にイメージ、固定テキスト、ハイライト・ボタンを含む場合、これらの３つのオブジェクトを一つのオブジェクト：3Dボタンに置き換えることをアドバイスします。もしコンテキストに従ってランタイム時にボタンを表示あるいは非表示にする場合、コードの変更が必要です。
いくつかの修正後に、”Contacts”データベースは再度書き出されて、今回は成功しています。
今度はあなたが実行する番です！
-
複数の4Dデータソースに興味がありますか？
このタイトルが既にヒントかもしれませんが、ワクワクするような新しい機能が4D v18で告知されました！
この機能はクライアント/サーバーの動作に新しい可能性を開くものです。カレントのデータベースに限定するのではなく、永続的なネットワーク接続を必要とするのもなく、4D v18のアプリケーションは4D Server上に公開された、別の、リモートの、4Dデータベースからデータを入手できます！
この機能のおかげで多くのオプションが可能になりました。例えば、オフラインで動き、リモートデータにアクセス可能な時にだけローカルデータを同期するアプリケーションを構成することができます。あるいは、複数のサーバーにデータを公開し、必要に応じて切り替えることも考えられます。別のオプションとしては、異なるデータベース（例：ローカルデータ、インターナショナルデータ）上にデータモデルを分割しすることも可能です。別の場所にデータを配信して一つの４Dクライアント・コード（プロジェクト・メソッドとフォームオブジェクト）を通じてアクセスできるようにするのはいかがでしょう？これらすべてのシナリオは実現可能で、このブログでその方法を説明します。
4D v18を使えば、他の4Dクライアントに対して、RESTサーバーとして公開できます。これは、4Dクライアントが公開したデータと相互通信（作成、読み込み、更新、削除）できることを意味します。さらに良いことに：この通信はORDAコンセプトをベースにしているので、完全にオブジェクト指向なのです！
どのように4Dデータベースをリモートアクセスに対して公開するのか？
データベース中のウェブ設定は：
-
設定タブで、HTTPポートを設定します。（セキュリティーのため、プロダクションモードではHTTPSを使うことを確認します！）
-
RESTリソース・タブ上で、「RESTサーバーとして公開」オプションを選択します。
- Webサーバーを開始します。上記のサンプルでは、データベース起動時にサーバーを開始するを選択します。
- 4D Server上でデータベースを開きます。
- おめでとうございます！あなたのデータベースが、あなたのマシンのIPと設定したポートを経由して、リモートアクセスで接続可能になりました！
注意：Webサーバーを使ってRESTサーバーへアクセスするには、Webサーバー・ライセンスは必要ありません。接続には標準の4Dクライアント・ライセンスが使われます。
リモートデータベースを使って動作する
OPEN DATASTOREコマンド
前述のように、あなたのデータベースはORDAコンセプト経由で接続可能になります：データベースはdatastoreオブジェクトを使って操作されます。従って、最初のステップは、アクセスしたいリモートデータベースに関連したdatastoreオブジェクトを得ることです。問題ありません！Open datastoreコマンドで正確なホスト名を呼び出せば動きます。
datastoreオブジェクトをローカルID “students”に関連付けます。これでORDAを使ってリモートデータベースと作業（クエリーの起動、エンティティのロード/更新など）が出るようになります。
C_OBJECT($connectTo;$schoolDS;$s)
C_TEXT($dataClass)
//The database contains a Students data class
$dataClass;="Students"
$connectTo:=New object("hostname";"school.acme.com")
$schoolDS:=Open datastore($connectTo;"students") //local id of this remote datastore is "students"
//Start working with ORDA means
ALERT("They are "+String($schoolDS[$dataClass].all().length)+" students")
//Run an ORDA query on the Students dataclass
$s:=$schoolDS[$dataClass].query("lastname=:1";"Smith").first()
If ($s#Null)
ALERT("Student "+$s.lastname+" lives in "+$s.address.city)
End ifOpen datastoreドキュメントをチェックして、安全な接続(TLS)でリモートデータベースにアクセスする方法を参照してください。
複数のリモートデータベースを使う
以下は、複数のリモートデータベースで動作させるのがいかに簡単かを説明した短い例です。二つのデータベースがあります：一つはフランス人の生徒が含まれていて、もう一つにはイギリス人の生徒が含まれています。
フランス人の生徒を見るか、イギリス人の生徒を見るか選択できます。
フォームメソッド：
Case of
:(FORM Event.code=On Load)
Form.frenchServer:="french.acme.com"
Form.englishServer:="english.acme.com"
End case「フランス人の生徒を見る」ボタンの背後にあるオブジェクトメソッドです：
C_OBJECT($connectTo;$students)
$connectTo:=New object()
$connectTo.hostname:=Form.frenchServer
$students:=Open datastore($connectTo;"french") //datastore containing French students
Form.students:=$students.Students.all()
「イギリス人の生徒を見る」ボタンの背後にあるオブジェクトメソッドです：
C_OBJECT($connectTo;$students)
$connectTo:=New object()
$connectTo.hostname:=Form.englishServer
$students:=Open datastore($connectTo;"english") //datastore containing English students
Form.students:=$students.Students.all()Open datastoreコマンドを最初に呼び出した時は、データストアオブジェクトはメモリーにロードされ、セッションはサーバーで開かれます。その後の呼び出しでは、このデータストアオブジェクトの参照を返すだけです。
リモートデータベースへのアクセスを管理
公開したデータベースを安全に保つために、アクセスにフィルターをかけることができます。Open datastoreコマンドを別の面で見てみましょう。以下のようにユーザーとパスワードを渡すことができます。
C_OBJECT($connectTo;$myStudents)
ON ERR CALL("manageErrors")
$connectTo:=New object()
$connectTo.hostname:="students.acme.com"
$connectTo.user:="mary@4d.com"
$connectTo.password:=Form.password
//local id of this remote datastore is "students"
$myStudents:=Open datastore($connectTo;"students")
ON ERR CALL("") </code>4Dは二つの方法で権限のあるユーザーのアクセスを制限できます。
4Dユーザーグループを使う
4Dユーザーグループを使ってアクセスを制限できます。データベースを公開した時に、Web設定ページのRESTリソース・タブでアクセスを許可するグループを選択します。
もしもOpen datastoreコマンドで与えられたユーザーが、選択されたグループに属している場合、アクセスは受け入れられますが、そうでない場合は承認エラーが生成されます。
ON REST AUTHENTICATIONデータベース・メソッドを使う
また、新しいOn REST authenticationデータベース・メソッドを使って、公開したデータベースへの独自のアクセスコントロールをコード化することもできます。このメソッドは、Open datastoreコマンド中のユーザーの資格を受け取ります。もしユーザーがリモートデータベースでの作業を許されている場合はシンプルにTrueを返します。
下記はサンプルです：
C_TEXT($1;$name;$2;$password)
C_BOOLEAN($0;$result;$3;$digest)
C_OBJECT($user)
$name:=$1 // The user to provide in Open datastore command
$password:=$2 // The password to provide in Open datastore command
$digest:=$3 // True if password is hashed
$result:=False
//Search for the user in our Users dataclass
$user:=ds.Users.query("name=:1";$name).first()
If ($user#Null)
// Passwords are hashed in Users dataclass
If ($digest & ($user.password=$password))
$result:=True
End if
$0:=$result注意：dsとdatastore.getInfo()コマンドは更新されて、新たに三つのメソッドが追加されました：datastore.startTransaction()、datastore.cancelTransaction()、datastore.validateTransaction()です。
では、HDI（例題）をダウンロードしてこの素晴らしい機能を学びましょう！
-
-
PROJECT DATABASESシリーズ：コラボレーション・ソリューション以上
他の人とコラボレーションしながら作業するのは理想的な方法です。世界中のどこにいても、他の場所のチーム仲間と働くことができ、誰でもファイルやプロジェクトの最新バージョンを難なく見つけられます。全ファイルのバックアップを実行する代わりに、ロールバック元のリストア・ポイントを選択できるようにしながら、新しい機能をテストして、もしそれらが機能しなければロールバックする別の方法。そんな夢が現実になりつつあります。上記のシナリオは4D v18とプロジェクト・データベースによって可能となっています。
プロジェクト・データベースとは何か
プロジェクト・データベースとはテキストベースのファイル中の4Dデータベースです。これらのファイルには、フォーム、メニュー、ユーザー設定と必要なリソース全てが含めた、データベース・ストラクチャからユーザーインターフェイスに至るまで、4Dデータベース・アプリケーションのソースコード全てが含まれます。
プロジェクト・データベースは4D Developerアプリケーションを使って作成、取り扱いをします。プロジェクト・ファイルはその後、最終的なアプリケーションの運用ファイルを構築するために使用されます。
なぜプロジェクト・データベースを使って作業するのか
- 共有：同僚と簡単にコードを交換：コードの断片をメールにコピー/ペーストしてアップロードして実行することができます。
- フレキシビリティー：複数のアプリケーションを使用していて、会社のグラフィックの権利を順守しながらダイアログを再利用したい場合。各アプリケーションにコンポーネントをインストールするか、データベース間でフォームをコピーします。
- シンプルさ：特にグラフィックの権利を順守する条件において、全てのフォント、カラー、アイコンなどを、スタイルシートを使ってアプリケーション用に全てを定義します。
- デバッグ：プロジェクト・ファイルをソース管理レポジトリ中に保存することで、支障のあるコードのソースを配置してバージョン間を簡単に比較できます。
- 運用：ソース管理レポジトリを使えば、複数のブランチ（例：開発と製造）の管理が簡単です。
このリストは表面的なものですが、これらの利点は全てプロジェクトデータベースのおかげです。
プロジェクト・データベースがもたらす全ての新しい機能と可能性は今後のブログで詳しく述べていきます。お楽しみに！
-
4D v17r6 修正リスト
-
ヘッドレス4Dアプリケーション
4D開発者として、グラフィカル・ユーザー・インターフェイス(GUI)を使わないアプリケーション、別名ヘッドレス・アプリケーション、を開発する必要に直面した経験をすでにお持ちでしょう。以前の4Dでは考えられませんでしたが・・・それも4D v18までです！このブログ記事では、新しく可能になった機能を使ってアプリケーションを”ヘッドレス”にする方法を説明します！
なぜヘッドレス・アプリケーションを作成するのでしょうか。今回はいくつかの使用例を挙げています。macOSでWindowsの動きをシミュレートする、あるいはサービス・マネージャーを使わずにWindowsのサービスの動きを実行するなどです。しかし、これら以上に、4Dでボットを開発するような新しい機会も開かれています。
どのようにヘッドレス・モードで4Dアプリケーションを起動するか？
4Dをヘッドレス・モードで起動するには、新しい”headless”パラメータとCLI（コマンド・ライン・インターフェイス）を使います。これは全てのアプリケーション・タイプで有効です：4D、4D Server、スタンドアロン、リモート、マージしたアプリケーション。下記の例では、現在のディレクトリが実行可能なディレクトリになります。
macOSサンプル（ターミナルがバンドルの”Contents/MacOS”フォルダーにある場合）：
./4D\ Server --headless MyDatabase.4DLink ./"4D Server" --headless MyDatabase.4DLink ./4D --headless MyDatabase.4DLink ./MyBuiltRemoteApp --headlessWindowsサンプル：
"4D Server.exe" --headless MyDatabase.4DLink 4D.exe --headless MyDatabase.4DLink MyBuiltRemoteApp.exe --headlessGet application infoコマンドによって返されたオブジェクトに新しい”ヘッドレス”属性を追加しました。それによってインターフェイスの有無によらず、実行モードに依存したコードを書くほうがとても簡単となりました。
注意： Windowsシステム上のサービスモードでアプリケーションが動いたとき、それは自動的にヘッドレス・アプリケーションとして実行されます。サービスを止めることで、4Dを正確な方法で終了します（例えば、macOSアクティビティ・モニターで”終了”アクションを使うように）。
実行中に何が起こるのか？
おそらく疑問に思うことでしょう、「オーケー、それは嬉しい。が、ダイアログが表示されたとしたらどうなるのだろう？」と。ランタイム時に何が起こっているのかをずっと知らせるために、4Dは自動的に診断ログをヘッドレス・モードで起動します。このログは、かつて[{applicationName}.HDLS]タグを使って表示され、ログに取られた全てのユーザーインターフェイスをキャッチします。
一般的な動作では、4Dは何かを表示しようとするコマンドをキャッチして、コマンド名とコールチェーン一緒に警告イベントをログに取り、アクションをキャンセルします。稀に特別なケースもあります：
- もし有効なライセンスがない場合、4Dはこのシステム・イベント・ログと標準的な流れをログに取り、終了します。
- データベースの変換が必要な場合、4Dはこのシステム・イベント・ログと標準的な流れをログに取り、終了します。
- もし有効なデータベースあるいはデータファイルが見つからない場合、4Dはこのシステム・イベント・ログと標準的な流れをログに取り、終了します。
- デバッガーの表示が必要なとき、4Dはエラーをログに取り、”取り消し”アクションをシミュレートします。
- アラートが表示されたとき、4Dは”OK”アクションをシミュレートします。
- 「4Dを終了」コマンドがコールされたとき、4Dはログを取り、”OK”アクションをシミュレートします。
- マージされたアプリケーションがアップデートしなければならないとき、ログが生成され、アップデートを実行し、アプリケーションはヘッドレス・モードで再起動します。
サンプル
例えば、Windowsのサービスとして起動したサーバー上で実行されたALERTコマンドは、サーバーの実行を止めることはもはやできません。4Dは自動的にコマンドをキャッチし、ダイアグノスティック・ログ中に警告行を書き込みます。次のように：
11 2019-07-11 18:53:52 [myTestDatabase Server.HDLS] WARN – (Alert: Test alert label)[{“type”:”projectMethod”,”name”:”myTestAlert”,”line”:2,”database”:”myTestDatabase”}]
このシステムはヘッドレス・アプリケーションで何が起こっているかを見るために作られていて、（必要であれば）コードを改良するためでもあります。
システムの標準ストリームを使う
新しいセレクター、
Into system standard outputs、をLOG EVENTコマンドに追加し、テキストをstdoutとstderr標準ストリームへ送ることができます。ご存知のように、LOG EVENTコマンドにはオプションの”importance”パラメータがあります。そのため、イベントの重要性によって、コマンドはテキストをInformation messageとWarning messageに対してstdoutストリームで、Error messageに対してstderrストリームで送ります。stdoutへテキストを送る：
LOG EVENT(Info system standard outputs;"This is a text for stdout";Information message)stderrへテキストを送る：
LOG EVENT(Info system standard outputs;"This is a text for stderr";Error message)そしてまた、4Dとアプリケーションによって生成された情報を検索するために、stdoutとstderr標準ストリームに対してリダイレクションを使うこともできます。デフォルトでは、これらのストリームはシステムの設定によって、一般的にコンソールに直接向かい、稀にスクリーンに向かいます。例えば、以下のコマンドラインを使って、標準ストリームをファイルにリダイレクトできます。
macOS：
./4D --headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txtWindows：
4D --headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txtストリームのリダイレクションの組み合わせのリマインダー：
- 1>outputFile：標準アウトプットストリームはシステムのデフォルトアウトプットの代わりにファイルに書き込まれます。ファイルはコマンドが起動した時に自動的に生成されます。もしすでに存在していれば、古いコンテンツは消去されます。
- 1»outputFile：上記のシンタックスと同じ動きをしますが、ファイルがすでに存在している場合、それはストリームのコンテンツに追加されます。
- 2>errorFile：標準エラーストリームはシステムのデフォルトアウトプットの代わりにファイルに書き込まれます。ファイルはコマンドが起動した時に自動的に生成されます。もしすでに存在していれば、古いコンテンツは消去されます。
- 2»errorFile：上記のシンタックスと同じ動きをしますが、ファイルがすでに存在している場合、それはストリームのコンテンツに追加されます。
- 2>&1：エラーストリームはアウトプットストリームにマージされます。
- 1>&2：アウトプットストリームはエラーストリームにマージされます。
注意：macOSシステムでopenコマンドを使って4Dパッケージを起動することはでき、ストリームは4Dアプリケーションではなくこのコマンドで生成されます！
まとめ
これらの新しい利点によって、システムの必要な使用条件に適合し、またボットのような新しい機会を作成することもできます。これをあなたのソフトウェア工場の継続的な統合(CI)や継続的なテスト(CT)工程に組み込むかはあなた次第です。あなたのイマジネーションだけが唯一の制限なのです！
-
アイドル接続タイムアウト設定はクライアント側で
Idle connections timeoutは，DB4DおよびSQLサーバーに対するアクセス（デフォルトのTCPポート番号は19814）のタイムアウトを設定するためのデータベースパラメーターです。新ネットワークレイヤーでは，アプリケーションサーバーのタイムアウトも同時に設定する役目を担っています。このパラメーターは，クライアント側だけで有効です。サーバー側でIdle connections timeoutを変更しても，動作には影響しません。これは仕様です。クライアント側で設定を変更しない限り，サーバー接続はデフォルト値の20秒が経過した後，延期（一時停止）状態になります。注記：データベース設定のクライアント/サーバー接続タイムアウト（データベースパラメーターの
4D Server timeoutおよび4D Remote mode timeout）でアプリケーションサーバーのタイムアウトを設定することができました。新ネットワークレイヤーでは，サーバー側のタイムアウトだけが設定できます。
-
Write ProでEMF画像は印刷できない
4D Write Proは，印刷バックエンドにDirect2Dテクノロジーを使用しています。
.emfイメージのレンダリングには，GDIコンテキストが必要なため，Write Proでは印刷することができません。これは仕様です。ベクター画像をドキュメントに挿入したい場合，旧来の.emf形式ではなく，標準的な.svg形式を使用してください。Microsoftは，画面と印刷でレンダリングが一致することを謳っていません。それは歴史的にAppleが強いとされる分野であり，グラフィック関係者がMacを選択する理由のひとつでした。Windowsは，基本的に画面と印刷ではまったく違う処理をしています。
v12以前のWindows版4Dは，画面と印刷の両方にAlturaライブラリを使用していました。Alturaは，Macのエミュレーションであり，Windows本来の96 DPIではなく，72 DPIの描画をします。画面と印刷の差は少なかったかもしれませんが，ネイティブ描画ではなく，Windows版の出力は必ずしも理想的とはいえないものでした。
v13以降のWindows版4Dは，画面にDirectXを採用するようになりました。ハードウェアアクセラレーターを使用した高速なレンダリングであり，全体的に従来よりも美しい出力が可能になっています。一方，印刷には，当時のプリンタードライバーで主流だったGDIが使用されています。このコンビネーションでは，画面と印刷でかなりの差があったかもしれません。
v17のWindows 64ビット版は，画面と印刷の両方にDirectXを使用しています。画面と印刷の差は再び縮まったと思われますが，Macとは違い，システムレベルで一致が保証されているわけではありません。
SET PRINT OPTIONのLegacy printing layer optionを使用すれば，強制的に以前（32ビット版）のGDIエンジンで印刷を実行することができます。v13に近い出力が得られるかもしれませんが，画面と印刷の違いは，プリンタードライバーに依存します。たとえば，Microsoft Print to PDF driverは，DirectX用に設計されており，GDIモードのサポートは貧弱です。反対に，GDIのほうが「高品質な」PDFドライバーもあります。いずれにしても，GDIモードの印刷は，互換性のために提供されているオプションであり，長期的に保証できるものではないため，使用はできる限り控えるようにしてください。
-
クエリエディターの日付フォーマット
v14以降でリニューアルされたクエリエディターは，日付型フィールドの区切り文字をシステムフォーマット（
GET SYSTEM FORMATS）に基づいて決定しています。通常の日付フィールドのように，「スラッシュ・ピリオド・ハイフン（ダッシュ）」が常に使用できるわけではありません。これは仕様です。