v16プロダクトレンジで廃止予定または削除された機能

4D の 64-bit版は最近のテクノロジーを多分に採用しており、以前のバージョンの4Dで廃止予定と宣言されたテクノロジーについては通常サポートしていません。64-bit版の4Dのプロダクトレンジでサポートされていない機能の完全な一覧については、デザインリファレンスマニュアルの64-bit版のみの機能の章を参照して下さい。

関数型プログラミングコンセプトに影響されたXSLTランゲージは、XMLデータをあらゆるフォーマット(XML、HTML、または他のどんなタイプ)へと変換します。全ての主要なWebブラウザと4Dソフトウェアは、XSLT 1.0使用を実装しています。

現 在XSLTは使い方もデバッグも難しいとデベロッパが感じるために、徐々に使用されない傾向にあります。このトレンドと、デベロッパからフィードバックを 加味し、4Dの64bit版ではXSL変換機能は開発されないことになりました。しかしながら、4DでXSLTを引き続き使用しているお客様をサポートす るために、PHP XSLライブラリーを使用する代替方法を用意しました。これは包括的なAPIを提供し、XSL変換に必要なすべてオペレーションを実行可能にするもので す。このライブラリーは効率的なツールで、_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コードをフォーマットされていないテキスト として扱っている場合には、多くの場合こちらの方が簡単だからです(MissingRef コマンドも参照して下さい)。

注: GoogleにおけるXSLT 検索のトレンド: http://www.google.com/trends/explore#q=xslt       

互換性のために、XSL変換は4Dにおいてまだサポートはされていますが、これからの使用は推奨されません。XSLT処理のサポートは将来の4Dのリリースにおいて削除されます。

64-bit版に関する注意: XSLTはOS X用およびWindows用の64-bit版4Dと、OS X用64-bit版4D Serverではご利用になれません。結果として、XSLT コマンドのどれかをこれのアプリケーションで使用した場合にはエラー33「未実装のコマンドまたはファンクションです」が生成されます。

注: Macの"PICT"フォーマットは、既にAppleによって数世代前のMac OSのバージョンから廃止予定になっています(詳細に関しては、WikipediaのPICTフォーマットの項をご覧ください)。

‘PICT’フォーマットはMacのとても古いフォーマットです。バージョン11より前の4Dでは、全てのピクチャーを(Windows上でも)このフォーマットで保存してきました。PICT フォーマットは2005年にQuickDrawが廃止予定になったのに伴い廃止予定になっていました。

PICTを理解するためには一つ重要な点があります。2種類の情報を保存(または"格納"と言ってもいいでしょう)できるということです:

• 描画の基本要素そのもの(ビットマップまたはヴェクター)、または
• QuickTimeを使用してPICTに保存したより現代的なフォーマット(例えばJPEGなど。通常、デベロッパは_o_QT COMPRESS PICTURE コマンドに QT Photo compressor 定数を用いて使用していました)。

これはつまり、以前、全てのデータファイルに保存されていたピクチャーがPICTで保存されていた時代から、そのPICTには実はJPEG(または他のフォーマット)を保存することができたということです。4Dのカスタマーとって、PICTの使用を中止することはとても大事なことです。それはPICTが既に廃止予定であるというだけではなく、PICTをWindowsで読み込むためには4DはAltura(+_o_QT COMPRESS PICTURE が使用されている場合にはQuick Time)も必要になるからです。これは非効率的で、またQuickTimeのインストールも必要になります。

v11より前のバージョンのデータを変換する際には、デベロッパはデータ内の全てのピクチャーフィールドに対してCONVERT PICTUREコマンドを使用する必要があります。さらに、もしピクチャーフィールドが4D Write/4D Viewエリアを格納していた場合には、CONVERT PICTUREを特定のコーデックで使用する必要があります(コマンドのドキュメントを参照して下さい)。それより新しいバージョンからデータを変換する際には、 GET PICTURE FORMATS コマンドを使用して変換が必要なピクチャーをデータファイルより検出することが推奨されます。

v16以降では Maintenance & Security Center (MSC) を使って、データベースストラクチャーに含まれる、廃止された PICT フォーマットのピクチャーを検出できます。アプリケーションの検証 機能を使用したときに PICT フォーマットのピクチャーを検出した場合、生成されるログファイルにはその旨の警告が含まれます。これらの警告は静的なピクチャーのほかにも、ピクチャーライブラリおよびフォームオブジェクトに含まれているピクチャーが対象となります。

注: 廃止された PICT フォーマットが使用されているピクチャーの削除・置換は別途行う必要があります。MSC でストラクチャーファイルの修復 処理を行っても、"廃止" ピクチャーは影響されず、ログファイルには引き続き警告が記録されます。

QuickTimeに関連したピクチャーコーデックのサポートは廃止になりました。

デフォルトでは、QuickTimeの使用は4D v14では無効化されています。しかしながら互換性のために、SET DATABASE PARAMETER、Get database parameter コマンドの新しいQuick Timeサポートオプションを使用することによって有効化する事ができます (64-bit 版の 4D では QuickTime がサポートされていないため、有効化できません)。

ここ数年、WindowsでのQuickTimeの画像管理はあまり進化していません(進化がみられるのは動画部分のみです)。4Dでは、次のリリースにおいて特にこれらのAPIのサポートを打ち切る予定です。

Windows版の4Dでは、もともと全ての主要な画像フォーマット(JPEG、PNG、GIF、TIFF、等)に加え、WIC(Windows Imaging Component)をサポートしてきました。もしあなたのデータの中に、QuickTimeにしか対応していない特定のフォーマットでWindows環境下において保存されたピクチャーがあった場合、変換することが可能です(CONVERT PICTURE)。

またQuickTimeピクチャーフォーマットは4D v12以降のWindows版4D Serverの64-bit版においてサポートがされていないことに注意して下さい。

以前のバージョンの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変数に値を自動的に代入する」のオプションを使用して無効化する事ができます。

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

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

Altura Mac2Win は4DをWindowsに移す際に使用されてきました。これはAPI(ファイルシステム、QuickDraw、リソース、PICTなど)を翻訳することによって、(OS X以前の)Mac OSのコードをWindowsへと移行するのを補助するためのAPIのセットです。これはかつてはとても有効で、例えばMacのプラグインデベロッパが開発したプラグインを容易にWindowsへと移行したりもできたのですが、古い(あるいは廃止された)Mac OS APIを翻訳してしまい、モダンなネイティブWindows APIを使用しません。4Dは、そのコードからMac2Winを極力除去しなければなりません。これは長く険しい道のりであり、4Dのそれぞれのバージョンにおいて、少しずつ依存性が除去されていく見込みです(そして少しずつモダンなAPIによって置き換えられていきます)。

現時点では、4Dは依然として一部をこれに依存しています(主に古いデータベースとの互換性を維持するためです)。リソース、PICT、ユーザーイベント管理の一部、Alturaを使用してビルドされたサードパーティープラグインのサポート等のために必要です。

"Resources"フォルダを内のファイルを分けるために.RSRファイル内のリソースを削除し、CONVERT PICTUREをPICT以外のフォーマットに変換することで、4Dデベロッパにとって4DからAlturaが除去される準備は完了します。しかしこの大変革が最も関係するのはプラグインのデベロッパです。彼らは可及的速やかにAlturaの使用をやめなければならず、これはつまり彼らのWindows用のソースコードの一部を書き換えなければいけないということです(4Dでは数年前からこれについての警告してきました)。

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

ASCII モード(この場合”非Unicodeモード”と同義)をサポートしている限り、テキストを操作する際のパフォーマンスにはあまり期待はできません。なぜなら、変換された古いストラクチャーで使用する場合は毎回 Mac-Roman へと(または Mac-Roman から)変換されなければならないからです。4Dでは将来のメジャーバージョンにおいてACIIモードを除去する予定でいます。

ASCII モードは、Windows用4D Server 64-bit 版のコンパイル済みストラクチャでは既に除去されている点に注意して下さい。
4Dデベロッパは、変換された古いストラクチャーにおいて、Unicode モードを起動して下さい。この点に関するヒントは、Conversion to 4D v14 PDFドキュメント内にあります。

64-bit版に関する注意:また、ASCII モードは、64-bit版の4Dおよび4D Serverでは利用できない点にも注意して下さい。

これもまた古い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 ファイルとして保存します。
  • ICON またはカラー付きアイコンの代わりに、icns を使用します(Mac)。
  • 他のプライベートリソースを、適切な形で保存します(多くの場合、特定の拡張子付きのバイナリーファイルとして保存します)。
• "Resources" フォルダにリソースを保管します。リソースの親のパスを動的に取得する場合には Get 4D folder(Current resources folder) コマンドを使用します。

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

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

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

新しいツールボックスを使用するプラグインに関しては、その新しいツールボックスのみが使用され、QuickDraw は使用されません(http://sources.4d.com/trac/4d_4dpluginapi/wiki/native_drawing を参照して下さい)。

これまでの異なるバージョンを経てきた中で、有用な4D Packルーチンは徐々に4D自身へと統合される一方、古くなった機能は削除されてきました。4D Pack v16にはごく少数のルーチンのみが含まれ、これらは今後開発が進められることはありません。4D v16以降、4D Pakプラグイン全体が廃止予定となり、今後のバージョンにおいては提供されなくなります。残りのルーチンに対して利用可能な代替ソリューション(あれば)については、以下の表を参照してください。

OLE_Tools プラグイン(Windowsでのみ利用可能)は4D 32-bit 版では廃止予定となり、4D 64-bit 版ではサポートされません。この旧式のプラグインで提供されていた機能は、場合にもよりますが、Webエリア 、LAUNCH EXTERNAL PROCESS 、あるいはPHP などで置き換えることができます。

4Dランゲージの分かりやすさのため、4D v15以降、廃止予定のコマンドには全て"_o_"が接頭辞として付けられる事になりました(まだ付けられていないものや4Dリスト(コードエディター、タイプアヘッド機能、他)に含まれていない場合)。

これらのコマンドは既存のコードからは削除されず、サポートされる限りは通常通り動作します。廃止予定のコマンドであっても、その名前に"_o_"を頭に付けることで廃止伊予定のコマンドをメソッドに追加することは可能です(ただし推奨されません)。このときこれらは正常に解釈されます。