17r4では，DRAG AND DROP PROPERTIESコマンドが正式に廃止予定となり，名称が_o_DRAG AND DROP PROPERTIESに変更されました。このコマンドは，ポインターを使用した独自の面倒なメカニズムに基づいており，v11以降，推奨されていません。
フォームオブジェクト間のドラッグ＆ドロップ，外部アプリケーションまたはファイルシステムからのドラッグ＆ドロップ，テキストやピクチャのネイティブドラッグ＆ドロップは，すべてペーストボードを使用したコードでシンプルかつ一元的に処理することができます。
廃止予定コマンドのリストは，各バージョンのランゲージリファレンスに掲載されています。廃止予定の機能と削除された機能もご覧ください。
現在ベータ公開中の17r4では，Begin SQL/End SQLがプリエンプティブモードをサポートするようになりました。
4DのSQLサーバーは，v11からスレッドセーフ（マルチコア対応）であり，以前から個別のリクエストをCPUコアに分散して処理できる設計でした。今回，コマンドがアップデートされたのは，最小限の書き換えでBegin SQL/End SQLが記述された既存コードをプリエンプティブモードで実行できるようにするためです。SQL言語の使用を促進するためではありません。
カレントレコードやカレントセレクションを変更せずにテーブルをルックアップする目的でSQLを使用しているデベロッパーは少なくありません。今回のアップデートにより，メソッドをスレッドセーフにするため，そのような処理をORDAに書き換える必要がなくなりました。
データベースにアクセスするため，必要であれば，SQL言語を使用することができます。しかし，4Dが力を注いでいるのは，ORDAのほうであり，SQLは互換性のためにサポートされている，ということに留意してください。たとえば，SQLのネストはサポートされていないため，トリガにSQLが記述されたテーブルにSQLでアクセスすると，エラーが返されます。この制限が取り払われる予定はありません。トリガで，カレントレコードやカレントセレクションを変更せずにテーブルをルックアップしたいのであれば，SQLではなく，是非，ORDAを使用してください。
Windows版の4D Serverは，サービスとして登録することができます。
サービスのプロパティで，「ログイン」で管理者権限のあるアカウントを設定し，アプリケーションが自動的に起動するようにサービスを設定すれば，コンピューターにユーザーが誰もログインしていなくても，4D Serverが起動するようになります。
そのようなサーバーを自動アップデートを実行した場合，アップデートの入れ替えには成功しますが，以前のバージョンが~app~_old0001のような名前の一時的なフォルダーにそのまま残された状態になります。これは仕様です。
自動アップデートの仕組みは，内部的に「ごみ箱に移動」コマンドを実行しています。アップデートを取り消したい場合，以前のバージョンにアプリケーションを戻すことができるようにするためです。この操作は，ログインユーザーのセッションが必要なハイレベルコマンドであるため，条件によっては失敗することがあります。「ごみ箱に移動」コマンドが完了できなかった場合，エラーコードの1018 (PW32)および661 (xbox)がアップデーターのログファイルに記録されます。
17r3の新しいビルド（232314）が1月18日にリリースされました。以前のビルド（231689）は取り下げられています。
新しいビルドは，17r2で追加された4D Write Proインタフェースウィジェットが内部的にコールしているコンポーネントメソッドWP_SwichToolbarの名称がWP SwitchToolbarに変更されています（ACI0099141）。標準オブジェクトライブラリから4D Write Proエリア（ツールバー付き）ウィジェットを17r2のフォームにコピーしたのであれば，オブジェクトメソッドに記述されているメソッド名を17r3で修正する必要があります。
以前のビルドは，コンポーネントメソッドのスペルミス（Swich: “t”が抜けている）が一方的に修正されていたため，4D Write Proエリア（ツールバー付き）ウィジェットを17r3でフォームにコピーした場合，シンタックスエラーになりました（17r2で作られたフォームはそのまま使用することができました）。
macOSは，ファイルやフォルダーのパスをPOSIX形式で管理しています。スラッシュ（/）はフォルダー区切り記号として予約されているので，ファイルやフォルダーの名称に使用することはできません。ファイルやフォルダーのパスをHFS形式で管理するアプリケーション（Finder，32ビット版の4Dなど）は，スラッシュの使用が許されているような印象を与えますが，これはアプリケーションが自動的にスラッシュをコロン（:）に変換し，HFSの区切り文字であるコロンをスラッシュに変換しているためです。
4Dの64ビット版は，Mac OSのレガシーなAPIではなく，macOSのPOSIX APIを全面的に使用しています。古いAPIの使用を中止し，標準的なAPIに移行したことは，アプリケーションを将来のOSアップデートに備えさせただけでなく，ファイルの読み書き速度と全体的なパフォーマンスの引き上げに役立ちました。一方，これまでのようにスラッシュ記号をファイルやフォルダーの名称に使用することはできません。
すでにスラッシュ（実体はコロン）が使用されているファイルやフォルダーのパスは，引き続き取得することができます。ただし，初期のリリースでは，下記のケースで問題があるかもしれません。
DOCUMENT LISTおよびSelect document
ファイル/フォルダー名の冒頭にあるスラッシュが省略されます（ACI0097745）
ファイル/フォルダー名の中間にあるスラッシュがコロンに変換され，区切り文字との見分けがつきません（ACI0098921）
Convert path POSIX to system
注記: Convert path POSIX to systemのドキュメントには，コマンドが絶対パスを受け入れると明記されており，相対パスを渡した場合の処理は定義されていません。振る舞いは仕様です。