フォームのサイズが「自動」に設定されている場合,ウィンドウの最小サイズは,すべてのオブジェクトが表示できるサイズになります。そのようなウィンドウに対してSET WINDOW RECT
を使用する場合,ウィンドウの最小サイズを下回るような指定をすることがないようにしてください。
コマンドで強制的に変形された「自動サイズ」のウィンドウをユーザーがマウス操作でリサイズした場合,ウィンドウの境界付近に表示された中途半端なオブジェクトが完全に表示されるよう,ウィンドウサイズの補正が試みられますが,ウィンドウの境界部はスプリッターでもあるので,同時にオブジェクトがリサイズされ,再びウィンドウサイズが不足することになります。ウィンドウとオブジェクトが互いを増幅させるため,リサイズがいつまでも終わりません。「自動サイズ」のウィンドウに対してSET WINDOW RECT
を使用する場合,ウィンドウの最小サイズに違反するような設定をしないように注意してください。
Windows版で,ウィンドウを表示する場合,編集メニュー(コピー&ペーストなど)を誤って無効化していないか,特に注意してしてください。Macとは違い,モーダル型のウィンドウがメニューバーをdisable
にするのは,仕様です。
ピクチャライブラリに登録された画像は,ドラッグ&ドロップあるいはコピー&ペースト操作でフォームに挿入し,スタティックピクチャ(ライブラリ画像)にすることができますが,ピクチャの番号(ID)が32767
よりも上だった場合,画像はエディターでもランタイムでも表示されません。これは仕様です。ピクチャライブラリのIDは,符号付き16
ビットなので,32767
が最大値となります。
v11以降,Resourcesフォルダーが画像をライブラリ管理するための標準的な手段であり,ピクチャライブラリは,役目を終えています。廃止される予定はありませんが,今後,サポートが拡張されることもありません。そのことを踏まえ,新規の開発では,フォーム画像の管理にリソースピクチャを使用することが推奨されています。
v17r5では,4D View Proのエクスポート(VP EXPORT DOCUMENT
)が拡張され,PDF形式が指定できるようになりました。
v18では,より正確なPDFドキュメントが出力できるよう,フォントの埋め込みがサポートされるようになりました。
Manage Printing and PDF export
埋め込みに対応しているのは,OpenType(.otf
.ttf
)フォントです。SpreadJSが内部的に使用しているpdfkit
の制限により,Unicodeマップを有するフォントだけが使用できます。システムにプリインストールされているフォントには,Unicodeマップを有さないものもあるため,エクスポートの前にフォントファイルがスキャンされ,埋め込みができるかどうか,判断されるようになっています(SpreadJSがデフォルトでサポートしているフォントはスキップします)。フォントファイルのスキャンは,下記の仕様に基づいて実行されます。
Font file
は,VP EXPORT DOCUMENT
が埋め込みフォントファイルを特定するため,VP EXPORT DOCUMENT
が内部的に使用するコマンドとして追加されました。4D View Proドキュメント内で使用されているフォントに対応するフォントファイルがみつからない場合,SpreadJSのデフォルトフォントが使用されます。
前述したように,PDFに埋め込むことができるのは.otf
.ttf
ファイルだけであり,フォントコレクション(.ttc
)はサポートされていないことに留意してください。たとえば「Gill Sans」フォントは,フォントコレクションなので,印刷はできますが,PDFに埋め込むことはできません。これは(SpreadJSおよびpdfKitの)仕様です。
回避策として,フォントコレクションを個別のフォントファイルに分割するオンラインサービスが使用できるかもしれません。
4Dのキーボードショートカットは,モディファイアキーとA
からZ
(文字)の単純な組み合わせで設定されています。ロシア語キーボードのレイアウトは,西欧レイアウトとは入力できる文字が違うため,ショートカットの設定ダイアログを表示している間,無効にされるべきですが,Macの場合,そのままキリル文字が入力できてしまいます。しかし,そのように設定したショートカットは無効です。ショートカットは,西欧レイアウトで設定するようにしてください。
整数の11
に実数の1.5
を加算した値は,何でしょうか。
$Int:=11
$Real:=1.5
$Int:=$Int+$Real
上記の演算は,32ビット版では13
(12.5
を切り上げた値),64ビット版では12
(12.5
を切り下げた値)となります。これは仕様です。
64ビット版の4Dでは,インタープリターモードとコンパイルモードの動きを揃えるため,インタープリターモードであっても,Intel CPUの「丸め」処理(最近接偶数丸め)で「丸め」処理が実行されるようになっています。一方,32ビット版は,従来どおり,「四捨五入」処理が実行されるため,演算結果に違いがあります。
Windows版でフォームオブジェクトを同一メソッド内で非表示に設定し,移動してから非表示を解除した場合,画面上ではオブジェクトが以前の位置と新しい位置の両方に表示されます。これはAPIの特性に由来する振る舞いであり,現状では仕様です。オブジェクトの「増殖」を防止するためには,下記のようなコードを避けてくだだい。
OBJECT SET VISIBLE (*;"object";False)
OBJECT SET COORDINATES*;"object";$left;$top;$right;$bottom)
OBJECT SET VISIBLE (*;"object";True)
4D Write ProのHTMLパーサーは,XHTML(XML形式のHTML)をインポートするように設計されています。正しくないXMLのインポートは失敗するかもしれません。たとえば,アンパーサンド記号(”&”)は&
のようにエスケープされている必要があります。WP New
で初期化するテキストは,標準テキストや不完全なHTMLコードの断片ではなく,XHTMLであるべきです。
タグが省略された標準テキストは,まずHTMLとして整形され(この時点で&
は&
になります),その後,XMLとして解析されるので,エラーになります。アンパーサンド記号(”&”)のようにエスケープが必要な文字が含まれるテキストを4D Write Proでインポートする場合,文字がエスケープされた標準テキストをWP New
に処理させようとするのではなく,文字がエスケープされていない標準テキストをWP SET TEXT
で処理するようにしてください。
v2004では,Windows版に限り,標準テキスト内のHTMLハイパーリンクがアンダーラインで装飾され,クリック操作でURLにジャンプすることができました。4Dのテキスト入力エリアがリッチテキスト入力オブジェクトで実装されていたためです。現行バージョンでは,テキスト入力オブジェクトの「マルチスタイル」プロパティが有効にされていない場合,HTMLハイパーリンクは標準テキストとしてレンダリングされます。これは仕様です。
Mac 64ビット版では,出力フォームをスクロールすると,On Header
イベントが1度ではなく,何度かコールされることがあります。これは仕様です。Mac 64ビット版(Cocoa)のグラフィック描画は最適化されており,フォームは部分的に再描画されないようになっています。
参考: v16でACI0098508が修正されるまで,300個のオブジェクトが配置されたリストフォームのスクロールおよび行の選択の反応は堪えられないほどに遅いものでした。更新のたびにフォーム全体が更新されないよう,グラフィック描画が最適化されたことにより,そのようなデザインのリストフォームでも軽快に動作するようになりました。
リストフォームが更新されると,On Header
イベントが発生します。イベントが発生したことにより,再度,リストが更新された場合,再度,On Header
イベントが発生しますが,今度はリストが更新されないかもしれず,そうであれば,そのタイミングではOn Header
イベントが発生しません。リストフォームをスクロールした場合,スクロールした行数とOn Header
イベントの回数は対応しないことがあります。言い換えるならば,On Header
イベントが余分に発生しているのではなく,フォームが再描画される回数が減っているため,スクロール中はイベントがまとめて発生したり,逆に発生しなかったりするようになった,ということです。