4D開発者として、グラフィカル・ユーザー・インターフェイス(GUI)を使わないアプリケーション、別名ヘッドレス・アプリケーション、を開発する必要に直面した経験をすでにお持ちでしょう。以前の4Dでは考えられませんでしたが・・・それも4D v18までです!このブログ記事では、新しく可能になった機能を使ってアプリケーションを”ヘッドレス”にする方法を説明します!
なぜヘッドレス・アプリケーションを作成するのでしょうか。今回はいくつかの使用例を挙げています。macOSでWindowsの動きをシミュレートする、あるいはサービス・マネージャーを使わずにWindowsのサービスの動きを実行するなどです。しかし、これら以上に、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 --headless
Windowsサンプル:
"4D Server.exe" --headless MyDatabase.4DLink
4D.exe --headless MyDatabase.4DLink
MyBuiltRemoteApp.exe --headless
Get application infoコマンドによって返されたオブジェクトに新しい”ヘッドレス”属性を追加しました。それによってインターフェイスの有無によらず、実行モードに依存したコードを書くほうがとても簡単となりました。
注意: Windowsシステム上のサービスモードでアプリケーションが動いたとき、それは自動的にヘッドレス・アプリケーションとして実行されます。サービスを止めることで、4Dを正確な方法で終了します(例えば、macOSアクティビティ・モニターで”終了”アクションを使うように)。
おそらく疑問に思うことでしょう、「オーケー、それは嬉しい。が、ダイアログが表示されたとしたらどうなるのだろう?」と。ランタイム時に何が起こっているのかをずっと知らせるために、4Dは自動的に診断ログをヘッドレス・モードで起動します。このログは、かつて[{applicationName}.HDLS]タグを使って表示され、ログに取られた全てのユーザーインターフェイスをキャッチします。
一般的な動作では、4Dは何かを表示しようとするコマンドをキャッチして、コマンド名とコールチェーン一緒に警告イベントをログに取り、アクションをキャンセルします。稀に特別なケースもあります:
例えば、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.txt
Windows:
4D --headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txt
ストリームのリダイレクションの組み合わせのリマインダー:
注意:macOSシステムでopenコマンドを使って4Dパッケージを起動することはでき、ストリームは4Dアプリケーションではなくこのコマンドで生成されます!
これらの新しい利点によって、システムの必要な使用条件に適合し、またボットのような新しい機会を作成することもできます。これをあなたのソフトウェア工場の継続的な統合(CI)や継続的なテスト(CT)工程に組み込むかはあなた次第です。あなたのイマジネーションだけが唯一の制限なのです!
Idle connections timeout
は,DB4DおよびSQLサーバーに対するアクセス(デフォルトのTCPポート番号は19814
)のタイムアウトを設定するためのデータベースパラメーターです。新ネットワークレイヤーでは,アプリケーションサーバーのタイムアウトも同時に設定する役目を担っています。このパラメーターは,クライアント側だけで有効です。サーバー側でIdle connections timeout
を変更しても,動作には影響しません。これは仕様です。クライアント側で設定を変更しない限り,サーバー接続はデフォルト値の20
秒が経過した後,延期(一時停止)状態になります。
注記:データベース設定のクライアント/サーバー接続タイムアウト(データベースパラメーターの4D Server timeout
および4D Remote mode timeout
)でアプリケーションサーバーのタイムアウトを設定することができました。新ネットワークレイヤーでは,サーバー側のタイムアウトだけが設定できます。
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
)に基づいて決定しています。通常の日付フィールドのように,「スラッシュ・ピリオド・ハイフン(ダッシュ)」が常に使用できるわけではありません。これは仕様です。