印刷コマンドでPDFまたはXPS形式のドキュメントを出力した場合,プリンターのように印刷ができない領域というものは存在しないため,SET PRINTABLE MARGIN
に-1
(プリンターのマージン)や0
(用紙マージン)の指定は無視されます。PDFまたはXPS形式のドキュメントがプリントプレビューとおなじようなレイアウトになることを望むのであれば,用紙およびプリンターを設定した後,GET PRINTABLE MARGIN
で理論マージンを取得し,SET PRINTABLE MARGIN
で出力に反映させる必要があります。
Microsoftの実装により,一部のWin32 APIは,プリンター名の31
文字目以降を切り捨てるようです。従来のバージョンでは,この振る舞いを看過していましたが,Windows 24H2で発生するようになったMicrosoft Print to PDF印刷の不具合(ACI0105743)を調査する過程でエラー処置が強化されたことにより,特定のビルドではカレントプリンターの名称が30
文字を超える場合に初回だけエラーが返されるようになりました(ACI0105792)。後者のエラーは,以前から潜在していた制限が修正の過程で浮かび上がったものであり,リグレッションではありません。
Windows版のMDIモードで最大化することができるのは,最前面ウィンドウだけです。最前面ではないウィンドウを最大化することはできません。これは仕様です。最前面であっても,フォームのサイズがプロパティで制限されているために最大化できない場合,そのウィンドウは最大化モードが解除された状態で表示されます。
アプリケーションをコンパイルせず,プリエンプティブモードのプロセスやワーカーを活用しなかった場合,すべてのメソッドは原則的にメインアプリケーションのコオペラティブスレッドで実行されます。つまり,複数のスレッドで同時に複数のプロセスが実行されるのではなく,メインアプリケーションのコオペラティブスレッドで少しずつ順番に実行されることになります。
コオペラティブモードでは,特定のプロセスが長時間にわたってCPUを独占するようなことを避け,プロセス同士でCPUを譲り合うことが重要です。たとえば,ループ処理中にDELAY PROCESS
を呼び出すことができます。DELAY PROCESS
が呼び出されると,一旦,スケジューラーに制御が返され,順番を待っている他のプロセスにメソッドを実行する機会が与えられます。プロセスを遅延することは望まず,単純に「息継ぎ」をしたい場合には,遅延時間に0
を指定します。遅延時間に0
を指定した場合であっても,必ずスケジューラーに制御返されるからです。
最近,新しいデータベースパラメーターUncooperative process threshold (132)
が追加されました。このパラメーターはメインアプリケーションのコオペラティブスレッドを「独占」しているプロセスを特定するのに役立ちます。閾値(デフォルトは500
㍉秒)を超えてプロセスがCPUを独占した場合,
Cooperative process doesn't yield enough
という警告が診断ログに出力されます。閾値はカスタマイズすることができます。また,このメッセージはエラーではなく警告なので,データベースパラメーターDiagnostic log level (86)
でログレベルを「エラー」に設定することにより,抑制することができます。
エンティティのロックは,参照カウントをインクリメントする操作なので,entity.unlock()
の呼び出し回数はentity.lock()
のそれと対応していなければなりません。
in order to actually unlock your entity you must call unlock() as many times as you called lock() in the same process 4D Forums
この点を明確にする説明がドキュメントに加えられました。
v12以降,4DはオープンソースのMeCabライブラリを使用して日本語テキストをキーワードのリストに分解することができます。20 R9では,この機能が廃止予定となりました。20 R10以降,4DのインストーラーにMeCabは含まれないようになります。
MeCabは,広く使用されている日本語形態素解析ライブラリです。4Dは,キーワード分解にICUライブラリのワードバウンダリー処理を使用しますが,わかち書きをしない日本語だけはICUの代わりにMeCabを使用しました。初期のICUは,カナと漢字の切り替えなど,単純なルールでテキストを分解することしかできませんでしたが,現在はMeCabに匹敵する形態素レベルの分解ができるため,今後,日本語の処理にMeCabを使用する必要はないと判断しました。
Windows版は,インストール時に日本語版を選択した場合にのみ,MeCabがインストールされます。macOS版は,常にMeCabがインストールされます。4D 20 R10以降,MeCabが含まれないことにより,アプリケーションのサイズを約80 MB節約できます。
MeCabは下記の条件が満たされている場合に使用されます。
いずれかの条件が満たされない場合,キーワード関連の処理には,一貫してICUライブラリが使用されます。20 R10以降,常にこの動作となります。
%
) 演算子を使用した場合GET TEXT KEYWORDS
DISTINCT VALUES
を使用した場合
GET PICTURE KEYWORDS
はMeCabを使用しません。
以下の表は,それぞれのアルゴリズムによって日本語の文章がどのようにキーワード分解されるのかを示しています。
Algorithm | Keywords |
---|---|
MeCab | キーワードインデックス,使用,しています |
非文字・非数字のみをキーワード区切り文字とする | キーワードインデックスを使用していますか |
ICU | キーワード,インデックス,を,使用,し,てい,ます,か |
4Dは,MeCabの形態素分解に基づき,連続する特定の品詞を結合したり,特定の品詞を除外することにより,自然な検索に適したキーワードリストを独自に作成するようになっています。
まず,アプリケーションがMeCabを使用しているかどうかを確かめてください。データ言語が日本語ではない場合、あるいはデータベースにキーワードインデックスが設定されていない場合,インデックス構築にMeCabは使用されていません。ただし,文字列比較には使用されている可能性があります。
If (Get database localization(Internal 4D localization)#"ja")
return //データ言語が日本語以外なのでmecabは使用されていない
End if
$keywordsIndexedFields:=[]
For each ($dataClassName; ds)
$dataClass:=ds[$dataClassName]
For each ($attributeName; $dataClass)
$attribute:=$dataClass[$attributeName]
If ($attribute.kind="storage") && ($attribute.keywordIndexed)
$keywordsIndexedFields.push($attribute)
End if
End for each
End for each
%
演算子を使用したクエリを実装している場合,キーワード検索がMeCabの有無に左右されないようにしてください。たとえば,下記のコードは,検索文字列がキーワードであるという前提で書かれているため,MeCabの有無によって動作したりしなかったりする恐れがあります。
$source:="キーワードインデックス"
$selection:=ds.Table_1.query("Field_2 % :1"; $source)
//MeCabではOK・ICUではNG
データベースエンジンと同じアルゴリズムを使用して検索文字列を事前にキーワード分解することにより,ライブラリの切り替えに備えることができます。
$source:="キーワードインデックス"
ARRAY TEXT($array; 0)
GET TEXT KEYWORDS($source; $array)
$keywords:=[]
ARRAY TO COLLECTION($keywords; $array)
$queryParams:={parameters: {}; arguments: {}}
$criteria:=[]
$i:=1
For each ($keyword; $keywords)
$arg:="arg"+String($i)
$queryParams.parameters[$arg]:=$keyword
$criteria.push("Field_2 % :"+$arg)
$i+=1
End for each
$selection:=ds.Table_1.query($criteria.join(" and "); $queryParams)
//どちらのモードでもOK
//つづいてシーケンシャルクエリを実行
$selection:=$selection.query("Field_2 == :1"; "@"+$source+"@")
開発中に20 R8から20 R10の間を頻繁に行き来することが予想されるのであれば,その都度,大量のキーワードインデックスを再構築することがないよう,カレントデータファイルの容量に注意すると良いでしょう。
運用中のデータベースを20 R10に切り替えるときは,キーワードインデックスの再構築が必然的に発生するため,時間に余裕を持って移行の計画を立てるようにしてください。