廃止予定または削除された機能

30年以上にわたり、私たちのゴールは(新しい概念やテクノロジーを用いて)製品を改善していきつつも、4D アプリケーションの互換性を確保することにありました。4D 初期の頃からのユーザーはご存知かもしれませんが、私たちは互換性のためにおおくの労力をさいてきました。そして、古い4D のバージョンやOS を使用して何年も前に作成された4D アプリケーションが、現在も最新バージョンの製品で動作しているケースを、世界中で見つけることができます。

残念ながら、以下のような理由から、旧式のテクノロジーを新しいものと組み合わせるのが困難になる場合もあります:

• 4D では常に新しいテクノロジー、新しいAPI、そして新しい方法論をデベロッパーに届けなければなりません。
• OS は毎日のように変化しています。そして時にはOS が持つ古いAPI が廃止予定となってしまうことがあります。

このため、4D では時として一部のコマンドや機能を廃止予定に分類する必要があります。これはつまり、これらのコマンドや機能は将来のメジャーバージョンにおいて削除される予定であるということを意味します。

何が廃止予定となっていて、代わりにどんな代替機能が利用可能なのかをデベロッパーに知らせることは、その変化をコードに実装するのを手助けするために必要なことです。あらかじめ予告することで、デベロッパーは慌てず焦らず、十分な時間を持って必要な変更を行うことができます。

"状況"カラムの値についての説明です:

• 削除済み: カレントのバージョン(または記載されたバージョン)では使用できなくなっています。
• 廃止予定: 今後使用されるべきではなく、将来のメジャーバージョンにおいて削除される予定です。
• OS: OSにおいて廃止予定のテクノロジーの状況に拠ります(例:PICT フォーマット)。状況としては"廃止予定"と同等ですが、4Dがそれを削除する前にOSが除去することが有り得ます。

廃止予定のコマンドは全て"_o_" の接頭辞がつけられ、4D リスト(コードエディター、タイプアヘッド昨日、等)には表示されません。廃止予定コマンドは、既存のコードから削除されることはなく、サポートされる限りは通常通りに動き続けます。廃止予定のコマンドをメソッドに追加することは(推奨されていませんが)可能であり、コマンド名の頭に"_o_" をつけて入力するだけです。これによって正常に解釈されます。

ランゲージリファレンスの廃止予定のコマンド付録内に、これらのコマンドのアルファベット順の一覧があります。

以前は廃止予定であった以下のコマンドは、4D からは削除され今後コードで使用してはいけません。呼び出された場合には、エラー(エラー33 - 未実装のコマンドまたは関数です) がトリガーされます。

警告: 削除されたコマンドへの呼び出しは、シンタックスチェックやコンパイル機能などでは検知されません。ご自身のコードはご自身でチェックし、削除されたコマンドに対して如何なる呼び出しも含まれていないようにしてください。

プロジェクトモードは4D データベースアーキテクチャーにおいて重要な進化の表れです。4D プロジェクトは最新のソフトウェアインターフェース要件と最も現代的なテクノロジーに依存するため、以下にあるような一部の旧式テクノロジーはサポートしません。これらの昨日は現在は廃止予定となっており、将来のプロジェクトアーキテクチャーとより合致するためには今後データベースの中で使用されるべきではありません。

4D のプロジェクトモードアーキテクチャーの詳細な情報については、developer.4d.com の4D projects documentation を参照してください。4D では.4db データベースをプロジェクトモードへと変換する自動書き出しツールも提供しています。書き出しの過程において、旧式の機能は自動的に変換されるか、削除されるか、またはエラーが生成されます(データベースをプロジェクトモードに変換する を参照してください)。

以下のフォームオブジェクトとプロパティは、カレントのインターフェース要件とは合致しないため、廃止予定となっています。これらはダイナミックフォーム ではサポートされず、プロジェクト変換ログファイル内に警告またはエラーを生成します(以下の表のコメントを参照してください)。

以下のデータベースストラクチャーオプションは廃止予定となっており、編集されるか、プロジェクト変換ログファイル内にエラーを生成します(以下の表のコメントを参照してください)。

以下のツールボックスエディターや機能は、廃止予定となっており、プロジェクトではサポートされません:

旧式の互換性モードはプロジェクトではサポートされません。互換性の設定はプロジェクトへの書き出しの過程で新規データベースと同様にリセットされます。お使いのデータベースが互換性設定に依存している場合、アップデートを検討してください。

4D では互換性の設定をどのように取り除いたらいいのかという点に特化したブログ記事の一連 を読むことを強く推奨します。

4D v17 R5 以降、32-bit 版の4D および4D Server は製作も配信もされません。 今後は64-bit 版のみが利用可能となり、これによって4D アプリケーションはこの強力なアーキテクチャーの利点を全て活かしきることができるようになります。

64-bit 版では旧式の4D の機能をほぼサポートしていますが、64-bit 版では最新のテクノロジーを採用しており、以前のバージョンで廃止予定と宣言されていたものに関してはサポートしません。32-bit 版で開発されたデータベースをアップグレードする場合にはいくつかの調整が必要になる場合があります:

• 4D v18 ではサポートされていない旧式の昨日の一覧については、このマニュアルの早見表 のページを参照してください。
• データベースを調整するには、v17 への変換マニュアルの"32-bit 版から64-bit 版への変換について"を参照して下さい。

XSLTは4D では使用できなくなりました。XSLT コマンドを呼び出した場合、エラー33 "未実装のコマンドまたは関数です"が返されます。

しかし4D 引き続きXSLT をお使いのお客様のために、PHP XSL ライブラリーに依存する決定をしました。これはXSL 変換に必要なオペレーションを全て実行できる包括的なAPI を提供しています。このライブラリーは効率的なツールで、_o_XSLT APPLY TRANSFORMATION、_o_XSLT SET PARAMETER および _o_XSLT GET ERROR が削除されたあと、簡単に置き換えることが可能です。4Dでは、4D XSLT コマンドの代わりにPHP XSLを代用するための詳細をまとめたドキュメントをご用意しています: Download XSLT with PHP technical document (PDF).

ま た、HTMLページの動的な生成を扱う際には4Dタグの使用を検討することが推奨されます。何故なら、HTMLコードをフォーマットされていないテキスト として扱っている場合には、多くの場合こちらの方が簡単だからです(PROCESS 4D TAGS コマンドも参照して下さい)。

(database parameter を通しての)QuickTime のサポートは、4D v17 R5 以降では削除されます。QuickTime に関連したピクチャーコーデックは今後macOS においてもWindows においてもサポートされなくなります。

4D v18 以降、フロート型フィールドは4D データベースではサポートされません。この型のフィールドは4D SQL エンジンでしか使用されていませんでした。データベースの中でフロート型フィールドを使用している場合、これらはデータベースがv18 以降のバージョンで開かれる際に自動的に実数型へと変換されます。既存のデータについては、圧縮をかける、またはレコードを再保存しない限りは変換はされません。

ASCII モード(この場合”非Unicodeモード”と同義)のサポートは4D v17 R5 以降では削除されます。Unicode モードに設定されていない変換されたデータベースを開いた場合、4D は以下のようなダイアログボックスを表示します:

このアラート画面は、データベース設定の"互換性"ページのUnicodeモードがチェックされていない限り、毎回開始時に表示されます。変換されたデータベースにおいては、必ずUnicode モードを有効化する必要があります。Conversion to 4D v14 のPDF ドキュメントがこの件についてのヒントを提供しています。

PICT フォーマット(Appleが2005年に廃止予定としたフォーマット)は、v17 R5 以降、4D ではサポートされなくなります。これはPICT フォーマットのピクチャーはどのような手段でもレンダリングされないため、変換される必要があるということです。GET PICTURE FORMATS コマンドを使用して、データファイル内からPICT フォーマットを検知してフィルタリングしましょう。

info.plist 内のDatabaseOutsidePackage キーを使用した、mac プラットフォーム上のシングルユーザー向け組み込み4D アプリケーションにでの特殊な配布モードは、今後サポートされません。4D v17 R5 以降、DatabaseOutsidePackage キーは無視されます。

4D v17 R4 以降、4D ではWindows のRight-to-left インターフェースに対する特定のサポートを提供しないことになりました。対応するオプションは、データベース設定からもフォームプロパティからも利用できなくなります。変換されたデータベースにおいては、Right-to-left 設定はランタイムでは無視されます。

4D v17 R4 以降、ユーザーフォームは廃止予定となります。カスタマイズ可能なユーザーインターフェースを提供するためには、今後はダイナミックフォームを使用することが推奨されます(デザインリファレンスのダイナミックフォームを参照してください)。"ユーザーフォーム"テーマ内のコマンドは全て廃止予定に指定されました。

ユーザーフォームは互換性のために引き続きサポートはされますが、今後は使用されるべきではありません。ユーザーフォームのサポートは将来のリリースで打ち切られる予定です。

4D Mobile 機能は4D v18 以降廃止予定であり、今後は使用するべきではありません。REST リクエスト経由での4D データへのアクセスは、今後はORDA テクノロジーと4D REST サーバーによってサポートされます。

以前のバージョンの4Dでは、WebフォームまたはURLを通して送られた変数の値が、4D内の変数と同じ名前であったときに、Webサーバーは自動的にその値を4D変数へと代入していました。

最適化と管理の目的から、この原理は4D v14以降は維持されていません。Web変数の値は自動的には4D変数に代入されません。POST や GET を使用して送られた変数を取り戻すためには、WEB GET VARIABLES コマンドを必ず使用して下さい。送られたファイルを取り戻すためには、WEB GET BODY PART/WEB Get body part count コマンドを使用しなければなりません。

注: 自動的な代入は、v13.4以降で作成された4Dデータベースにおいてもデフォルトで無効化されています。

しかしながら、互換性のために、この機構はv13.4より前のバージョンの4Dで作成されたデータベースにおいてはデフォルトで維持されています。この場合、データベース設定の互換性ページの「Web変数に値を自動的に代入する」のオプションを使用して無効化する事ができます。

この機構は廃止されていることから、今後の変換を容易にするためにも、変換されたデータベースにおいてこのオプションのチェックを外すこと(またそれに加えて必要であればコードを修正すること)が強く推奨されます。

これまでの複数のメジャーバージョンにおいて、4Dはデベロッパに対し、サブテーブルの使用をやめるよう忠告をしてきました。そして4D v11以降、サブテーブル型のフィールドを作成することは出来なくなりました。サブレコードにはいくつかの制約がつきます。例えば、サブテーブルは必ずメ モリーにロードされ、SEND RECORD と DUPLICATE RECORD コマンドで管理することはできません。

今す ぐサブテーブルのサポートを打ち切る予定はありませんが、デベロッパの方々にとって、そろそろ真剣にサブテーブルをN対1テーブルへと切り替えるべき時期 だと考えられます。何故なら、将来の4Dのメジャーバージョンにおいて4Dからサブテーブルが除去される予定だからです。パフォーマンスのため(リレート したレコードの読み出しが遅いなどの特定の条件下)にサブテーブルを使用していたデベロッパは、ご安心ください。スピードは(特にv12以降)N対1、1 対Nリレーションを使った方が速いです。

サブテーブルを除去するためには、主に二つのステップがあります(注:以下は完全なTech Tipsではなく、あくまで早見表です):

• v11以前のストラクチャーを変換する前に: 2004では、適当なNテーブルを作成し、1テーブルにIDフィールドを作成します(作成されていなかった場合)。その後変える必要のあるコードを全て書き換えます(以下を参照して下さい)。
• 変 換後: ここでは、4Dはサブテーブルを特殊なリレーションを使用してNテーブルに置き換え、ランゲージがサブセレクションとサブレコードに作用するようになって います。4Dデベロッパはこの特殊なリレーションを削除し、通常のリレーションと置き換えた上で必要なコードを全て書き換えます(以下を参照して下さ い)。

ここで言う"必要なコードを全て書き換える"というのは、基本的に:

• 新しいフォームを作成し、含まれるフォームをアップデート
• メソッド(プロジェクトメソッド、フォームメソッド、オブジェクトメソッド、等)において:
  
  • ”サブレコード”テーマのコマンドを全て除去し、対応するセレクションまたはレコードコマンドで置き換えます(例えば、_o_CREATE SUBRECORD を CREATE RECORDコマンドで置き換え、IDフィールドを埋めます)
  • 必要に応じてNレコードを明示的に読み出します。

注: 4D v14 R3以降、サブテーブルを含むデータベースを変換した際に4Dによって自動的に追加される特殊なフィールド"id_added_by_converter"に値を割り当てることが出来るようになります。これにより、"サブテーブルリレーション"のリンクを保ったまま、_o_CREATE SUBRECORDなどの廃止予定のコマンドを使用することなく、リレートされたレコードを追加または編集することができます。メソッドをアップデートした後、これらの特殊なリレーションは、コードを何も書き換えることなく、通常のリレーションと置き換えることができるようになります。

QuickDraw フォント(例: Geneva、Chicagoなど)は廃止予定となり、今後はフォントを指定するのにID番号を使用するべきではありません。_o_Font name コマンドは互換性のために残されていますが、今後のバージョンでは削除されます。今後はOBJECT SET FONT コマンドはフォント名のみを受け付けます。

プラグインには二つの種類があります: 新しいプラグインAPIを使用するものと、古いAPI(とQuickDraw)を使用するものです。

古いツールボックス(とQuickDraw)を使用するプラグインに対しては、互換性を維持するため、描画/レンダリングは以前のバージョンのように QuickDraw ポート内で直接行われることはありません。その代り、プラグインに割り当て有られたGWorld QuickDraw オフスクリーンエリアを通して行われます。

その結果、プラグインはコンテナ(フォームオブジェクト)によって設定されたカレントのポートを変更してはいけない、などのいくつかのルールに従う必要があります。

新しいツールボックスを使用するプラグインに関しては、その新しいツールボックスのみが使用され、QuickDraw は使用されません (https://github.com/4D/4D-Plugin-SDK を参照して下さい)。

4D v16 R6以降、Mac OS 9ベースのファイル・フォルダ管理のためのAPIは、4Dにおいては廃止予定となります。これらのAPIは既にAppleによってかなり以前から廃止予定とされていたものでした。

古いAPIに依存していた以下の4Dコマンドは、名前が変更されています: _o_Document type、_o_Document creator、_o_SET DOCUMENT TYPE、_o_SET DOCUMENT CREATOR、および_o_MAP FILE TYPES。macOS用32-bit版4D においては、これらのコマンドは互換性のために維持されていますが、廃止予定となっており、今後使用するべきではありません。 4Dではパス名とファイル拡張子を管理するための、二つの新しいコマンドが追加されました。Path to object および Object to pathです。

標準アクションは4D v16 R3において内部的に設計し直されました。今後は文字列パターンに基づき、また引数をサポートする様になります(詳細な情報については標準アクションの章を参照してください)

変換されたアプリケーションにおいては、標準アクションは透過的に新デザインへとリマップされます。しかしながら、4Dランゲージにおいては、標準アクションは以前はコードの値に基づいていました。この原理は廃止予定となり、今後は使用されるべきではありません:

• 標準アクション定数テーマ内にあるコードベースのテキスト標準アクション(以前の名前は"関連付けられた標準アクションのテキスト値")は全て接頭辞"_o_"がつき、今後は使用されるべきではありません。
• 割り当てられた標準アクションの値定数テーマは全て廃止予定となります。
• (コードを返す)_o_OBJECT Get actionコマンドは廃止予定となり、新しくなったOBJECT Get actionコマンドによって置き換えられます(こちらは名前を返します)。

これもまた古いMac OSのテクノロジーの一つで、Mac OS X 10.4(Tiger、2005年)に廃止されています。リソースは現在はテキストや文字列などの構造化されたデータ(ローカライズ用)に加え、アイコンなどを保存するために使用されています。つまり廃止されたのはリソースそのものではなくて、リソースフォークと呼ばれる、ディスク上のサポートです。リソースフォークはMac OS ファイルシステムの一部であり、Mac OS X初期から、Apple ではこのサポートを除去しようと試みてきました。これはこの仕組みがUnixやWindowsなどの他のファイルシステムとは互換性がないうえに、ファイルをネットワーク越しに転送する際に多くの問題の原因となってきたからです。

Windows上では、このメカニズムをエミュレートして、Macリソースは.RSR ファイル内に置かれてきました。

しかし、これらのリソースを管理するAPIがまだあるとはいえ(そしてMac OSではデータフォーク内に保存されているリソースをひそかに管理しているとはいえ)、以下の複数の理由からこの機構は使用されるべきではありません:

• テキストと文字列はMac-Romanになっています。TEXT または STR# タイプのリソースにはUnicodeを保存することができません。
• PICT リソースは PICT フォーマットを保存します。これは現代的ではなく、透明度もありません(上記の"PICT フォーマットのピクチャー"を参照して下さい)。
• リソースには数・サイズともに上限があります(約2,700リソース、または16MB)。

4Dからはリソースを書き込み・作成するコマンドは除去されています。

リソースを依然として使用している4Dアプリケーションの大半は、実際に使用しているのは"String List"リソース('STR#')です。4Dでは STR# を XLIFF に容易に変換するツールを提供しています:

• 4D Pop コンポーネントは、STR# ファイルの中身を読んで変換することで自動的に XLIFF ファイルを作成する事ができます。
• STR# を参照する全てのルーチンと式は、何の変換もなしにそのまま XLIFF を使用する事ができます。例えば、ボタンやメニューのラベルが“:15000,3” (＝「STR# ID 15000 の3つめの項目を取得しなさい」という意味) だった場合、4D は適切な XLIFF を(存在すれば)読み込みます。

他のリソースに関して:

• リソースをResources フォルダ内の他のファイル形式に格納します(必要であればサブディレクトリを作成して下さい):
  
  • 'TEXT' リソースを XLIFF または .txt ファイル形式に保存します。
  • 'PICT' リソースを別の.jpg/.png などのファイル形式に保存します。
  • 'PICT' + MASK’ リソースを .png ファイルとして保存します。
  • 他のプライベートリソースを、適切な形で保存します(多くの場合、特定の拡張子付きのバイナリーファイルとして保存します)。
• "Resources" フォルダにリソースを保管します。リソースの親のパスを動的に取得する場合にはGet 4D folder(Current resources folder) コマンドを使用します。

CPU優先度の変更は廃止予定の設定となりました。4Dアプリケーションのメモリ管理は異なるバージョンを経るごとに最適化されてきており、デフォルトの設定を変更することは不要であるばかりか時として非生産的な結果になることもあります。結果として:

• (データベース設定の"一般"ページ内にある)"CPU優先度"エリアは、変換されたデータベース内においてカスタムの値が事前に設定されていた場合に限り表示されます。またこの場合でも初期設定ボタンを押してこの値を初期化し、ダイアログボックスから削除することが推奨されます。
• 4D v16 R2以降、SET DATABASE PARAMETERコマンドにおける廃止予定のセレクター(_o_4D Remote mode scheduler、_o_4D Local mode schedulerおよび_o_4D Server scheduler)は改名され、今後は使用されるべきではありません。