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

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

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

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

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

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

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

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

一貫性の理由から、複数のコマンドが4D 20 R7 で改名されました。

4D 21 R3 以降、旧式ネットワークレイヤーはサポートされていません。対応する データベース設定 は削除されており、SET DATABASE PARAMETER のセレクターは  _o_Use legacy network layer へと名称変更されています(これは今後無視されます)。旧式ネットワークレイヤーを使用していたプロジェクトまたはバイナリーデータベースは、4D 21 R3 以降にアップグレードした際に自動的にServerNet へと設定されます。

ddd

リモート4D上のWebサーバーの使用は、4D 21以降非推奨となります。この機能は引き続きサポートされますが、今後の開発では使用しないことを推奨します。

MeCab ライブラリ（日本語でのソート/検索専用）は、4D 20 R10 で削除されました。このライブラリーは次の4D のリリースでは削除されます。今後は、日本語のデータベースにおいては、他の言語同様に標準のICU ライブラリーを使用することが推奨されます。詳細な情報については、こちらの記事 を参照してください。

4D v20 R5 以降、4D Internet Commands プラグインは4D インストーラーでは提供されなくなりました。必要であれば、4DInternetCommands.bundle を4D プロダクトダウンロードポータル からダウンロードし、プラグインファイルを プロジェクトまたはデータベースのPlugins フォルダ にインストールしなければなりません。

以下の4D Internet Commands 機能は廃止予定となっています:

4D v20 R3 およびそれ以降のリリースにおいては、ビルトインの4D PHP インタープリターは含まれなくなります。PHP が提供する大部分の機能は今では4D に実装されており、そのためPHP インタープリターを削除すると決定されました。PHP Execute および他のPHP コマンドは引き続き動作しますが、外部PHP インタープリターが必要になります。詳細な情報については4DでPHPスクリプトを実行する のページ、および こちらのblog記事 を参照してください。

SQL の複製および同期機構(SQLを使用した複製において説明あり)は、4D v20 R3 において廃止予定となります。これらは引き続きサポートはされますが、今後はORDA ベースの グローバルスタンプ機能 を使用することが推奨されます。これは4D において複製と同期を実装するための、柔軟かつ堅牢なソリューションを提供します。

PDFCreator ドライバーは4D v20 以降廃止予定となります。Windows 10 以降のリリースにはネイティブのPDFドライバーが含まれています。PDFCreator Printer name 定数は、_o_PDFCreator Printer name へと改名されました。

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

何年もサービスとして提供してきましたが、ついに表舞台から退場の時となりました: インタープロセス変数は、今後非推奨となります。4D プロジェクトにおいてインタープロセス変数の使用は、プリエンプティブプロセスにおいて利用できないばかりか、配列、(非共有)オブジェクト、(非共有)コレクションなどの複雑な値を複数のプロセスが同時に扱うことに対応していないため、推奨されません。将来的にはコードのメンテナンスを難しくしていくことでしょう。プロセス間でオブジェクトやコレクションの値を共有するためには、今後は 共有オブジェクトおよびコレクション および Storage コマンド、またはシングルトン の使用が強く推奨されます。

4D Write Pro v19 R4 以降、行ブレークを管理できるようになりました。段落ブレークと表ブレークの混乱を避けるため、全てのブレークは専用の定数と標準アクションを通して管理されるようになりました(4D Write Pro属性 と 標準アクションの使用を参照してください)。以前の汎用的な定数(_o_wk page break inside)および標準アクション(avoidPageBreakInsideEnabled)は廃止予定となり、互換性上の理由のためにのみ残されます。

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です。

これもまた古い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) コマンドを使用します。

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

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

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

4D v20 以降、データベース内のコードがオブジェクト記法に従っていることが必須となります。オブジェクト記法を使用してオブジェクトプロパティにアクセスするオプション(互換性モード、互換性ページ 参照)がチェックされていないデータベースを変換しようとした場合、4D は、開く人がデータベースが開けられるように一時的にこのオプションを有効化するためのダイアログボックスを表示します。ただし、恒久的にオプションを有効化するためには、その後でまたこれを明示的にチェックする必要があります。そして何より、事前にMSC を使用してアプリケーションの互換性を検証しておくことが推奨されます。

キャンセルをクリックする、またはデータベースが開発モードへのアクセスを許可していない場合(コンパイル済みデータベースである、デザインモードへのアクセス権がないなど)、エラー -10537 が生成され、データベースは開かれません。

注意: 互換性モードはバイナリーデータベースにおいてのみ利用可能のものです。