Write Proに幅が120pxの列5個で構成されるテーブルを挿入した場合,テーブル全体の幅は600pxを超えることになります。これは仕様です。
wk width
およびwk height
はHTMLやCSSと同じ仕方で要素のサイズを定義します。つまり,セルのサイズには,パディングやボーダーが含まれません。テーブルの正確な幅は,セル・ボーダー・パディングの幅を合計した値になります。行の中間に位置するセルのサイズは,下記の計算式で求めることができます。
wk width+(wk border width left+wk border width right)*0.5+wk padding left+wk padding right
セルとセルの間にあるボーダーは,幅が半分にカットされる点に留意してください。左端のセルはwk border width left*0.5
,右端のセルはwk border width right*0.5
をこれに加える必要があります。両端のセルだけは,ボーダーがカットされないためです。なお,ボーダー幅の計算には,複雑なレンダリングルールが関係しており,ボーダーの幅とスタイルが揃っていない場合,この計算式だけでは多少の誤差が生じるかもしれません。
例題:
C_REAL($widthFull)
$widthFull:=0
For ($i;1;$NbCol)
$Col:=WP Table get columns($Tableau;$i;1)
WP SET ATTRIBUTES($Col;wk width;120)
$cells:=WP Table get cells($Tableau;$i;1;1;1)
C_REAL($width)
C_REAL($borderWidth;$padding)
WP GET ATTRIBUTES($cells;wk border width;$borderWidth;wk padding;$padding)
//full cell width = wk width+(wk border width*2)/2+wk padding*2 (only if all cells have same padding and border widths)
//for interior cells borders are collapsed
$width:=120+($borderWidth*2/2)+($padding*2)
$widthFull:=$widthFull+$width
If (($i=1) | ($i=$NbCol))
//for row first and last cell, exterior borders are not collapsed
$widthFull:=$widthFull+($borderWidth*0.5)
End if
End for
ALERT("full table width in px="+String($widthFull))
ORDAのエンティティセレクションには,ordered(順序あり)とunordered(順序なし)が存在します。前者は従来の命名セレクションに,後者は従来のセットに似ています。
デスクトップ版,あるいはサーバー側でORDAのquery()
を使用した場合,データストアds
はローカルなので,デフォルトでunordered(順序なし)のエンティティセレクションが返されます。ordered(順序あり)のエンティティセレクションが必要であれば,newSelection()
にdk keep ordered
オプションを渡すことができます。
クライアント側でORDAのquery()
を使用した場合,データストアds
はリモートなので,常にordered(順序あり)のエンティティセレクションが返されます。つまり,クライアント側でORDAを実行した場合,entitySelection.isOrdered()
は常にTrue
を返しますが,同じコードをデスクトップ版で実行した場合,False
が返されるかもしれません。これは仕様です。
タブコントロールオブジェクトは,フォームページの切り替えに適しているため,標準アクションの「ページ移動」がデフォルトで設定されています。フォームオブジェクトには,標準アクションとオブジェクトメソッドの両方が設定できますが,「ページ移動」アクションが設定されているタブコントロールの場合,On Clicked
でFORM GOTO PAGE
コマンドで指定したベージに移動することはできません。標準アクションは,オブジェクトメソッドの後に実行されるためです。
v16まで,一部のアクションはオブジェクトメソッドの前に実行され,他のアクションはオブジェクトメソッドの後に実行されるといった具合に振る舞いが一貫していませんでした。v17では,標準アクションは常にオブジェクトメソッドの後に実行されるよう,仕様が統一されています。
macOS MojaveでPHP Execute
を実行すると,「アプリケーションはお使いのMac用に最適化されていません」というアラートが表示されます。17r4と一緒に配付されているphp-fcgi
が32ビット版のアプリケーションであるためです。このメッセージは,30日に1回,リマインダーとして表示されます。
注記: 32ビット版アプリケーションは,17r4が最後のリリースとなります。17r5以降,4Dおよび4D Serverは64ビット版アプリケーションのみのリリースとなり,PHPも64ビット版のバージョン7.3.1
にアップデートされる予定です。
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
のドキュメントには,コマンドが絶対パスを受け入れると明記されており,相対パスを渡した場合の処理は定義されていません。振る舞いは仕様です。
4D Writeドキュメントには,フィールド・変数・メソッド・関数などのフォーミュラを挿入することができます。想定されているのは,カレントセレクションから差し込み文書を出力したり,日付や時刻などの文字列を動的に挿入することでしたが,文書にQUERY
を埋め込むことにより,ドキュメントの表示や印刷と同時にクエリが実行されるようにする,といった用途にも利用することができました。しかし,そのようなドキュメントを4D Write Proに変換した場合,フォーミュラが埋め込まれた箇所に「未定義」という文字列が表示されるかもしれません。
4D Write Proでは,セキュリティのルールが見直され,ドキュメントにコマンドを挿入できるコマンドや関数が限定されていますが,データベース設定で制限を解除すれば,これまでどおりQUERY
も挿入することができます。
参考:4D Write Pro ドキュメントに含める式の制限
QUERY
は値を返す関数ではなく,コマンドなので,実行後,ドキュメントには「未定義」という文字列が挿入されます。仕様どおりの動作ではありますが,4D Writeからのスムーズな移行をサポートするため,値を返さないフォーミュラは空の文字列として評価される,という仕様に改定されました。改定のビルド番号は,リリースノートで確認してください。