ツールボックスのスタイルシートは，プラットフォーム間に存在するフォントの違いをある程度は解消することができますが，簡易的なシステムであり，できることには限界があることを理解する必要があります。たとえば，MacとWindowsで別々のフォントが割り当てられたスタイルシートをオブジェクトに設定し，Macで作成したフォームをWindowsで開くと，オブジェクトの高さが変化します。そのフォームをWindowsからMacに戻すと，再び高さが変化しますが，元の高さに戻るわけではありません。これはドキュメントに説明されていることであり，仕様です。
注: オブジェクトに他のプラットフォームのフォントが設定されている場合，その高さはカレントのプラットフォーム用に選択されたフォントに適するよう自動で調整されます。 オブジェクトを描画する際この点を考慮に入れるべきです。
UUIDでは，16進数の13桁目および17桁目にそれぞれアルゴリズムとバリアント（変種）のコードが出力される場合があります。たとえばバージョン４のバリアント１であれば，13桁目が常に4，17桁目が8からbの値になります。
Windows版の4Dでは，UUIDのバージョンコードが13桁目ではなく15桁目に出現します。Mac版は慣例どおり13桁目です。言い換えるならば，値は確かにUUIDですが，フォーマットはMicrosoftのGUIDやCLSIDのものを踏襲しており，Macと比較すると，HHHHHHHH-HHHH-HHHHグループがそれぞれバイトスワップされたような格好になっています。これはプラットフォームの設計に由来する仕様です。
128.1-128.08という数式を4Dで評価すると0.01999999999998という値が返されます。127.1-127.08であれば0.02が返されるのとは対照的です。
プログラミングで小数を扱う場合，実数は近似値を表現したものであることを憶えておきましょう。小学校で習った算数とは違うことをしている，ということです。計算の結果がぴったり割り切れるかどうかは，実数の内部的なデジタル値に左右されます。上述した例では，どちらも「およそ0.02」という近似値が返されているのであり，これを「およそ等しい」と判定するために SET REAL COMPARISON LEVELのような仕組みが存在します。これは計算間違いではなく仕様です。
通常，実数値の「丸め」処理をするにはRoundを使用します。しかし，Roundを使用していないのに数値が四捨五入されることがあります。整数型のフィールドや変数に実数値を代入した場合，暗黙的に小数値が四捨五入されるためです。小数値を四捨五入するのではなく，切り捨てるのであれば，明示的にInt関数を使用して整数部を取り出してください。
コンパイラーは定数のMAXLONGを整数としてコンパイルします。リテラル数値とは違い，定義済み定数は値だけでなく型も決まっているからです。たとえばMAXLONG+1という数式はインタープリターモードで実数値の2147483648を返しますが，コンパイルモードでは整数値の-1を返します。これは仕様です。符号付き32ビット整数値の範囲をオーバーフローするような数値をコンパイルモードで扱うのであれば，整数型の定義済み定数は使用しないでください。
SQL LOGIN, Begin SQL~End SQLのODBC接続は，外部データプロバイダーとの接続を想定しています。4DのODBC Driverを使用して4Dから4Dに接続することは想定されていません。標準SQLで4D同士のODBC接続を試みた場合，SQLコマンドは正しい結果を返さないかもしれません。これは仕様です。どうしても4D同士でODBC接続をするのであれば，標準コマンドではなく，ODBC Proプラグインを使用してください。