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

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

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

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

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

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

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

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

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

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

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

4D v19 以降、全てのプラットフォームにおいて4D ODBC Pro プラグインは今後利用できません。今後はODBC/SQL 接続機能を管理するためには、ビルトインのODBC/SQL パススルー(SQL LOGIN とSQLコマンドの概要 参照)あるいは 4D REST API を使用して下さい。

4D v19 以降、4D for OCI プラグインはmacOS では利用できなくなります。このプラットフォームにおいて接続機能を管理するためには、今後はビルトインのODBC/SQL パススルー(SQL LOGIN と SQLコマンドの概要 参照)あるいは 4D REST API の使用が推奨されます。

4D v19 以降、4D ODBC ドライバーはmacOS では利用できなくなります。このプラットフォームでの外部データアクセスのためには、 4D REST API の使用が推奨されます。

オブジェクト型フィールドに対しては、データファイルの外保存オプションはサポートされなくなりました(レコード、データファイル、外部に保存参照)。このオプションがオブジェクト型フィールドに対して選択されていた場合、それは自動的にデータファイルの中へと変換され、また新規レコードに対してもそれが適用されます。オブジェクトフィールド内にある既存のデータについては、親レコードが保存された時に、透過的に新しい保存場所へと書き写されます。全てのレコードを一斉に書き写すためには、MSCの圧縮で"レコードの強制更新"オプションをチェックしてデータファイルを圧縮してください。

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

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

以前のバージョンの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などの廃止予定のコマンドを使用することなく、リレートされたレコードを追加または編集することができます。メソッドをアップデートした後、これらの特殊なリレーションは、コードを何も書き換えることなく、通常のリレーションと置き換えることができるようになります。

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) コマンドを使用します。