Open form window
で指定できるウィンドウタイプの中にToolbar form window
というものがあります。ツールバーは,常時,スクリーンの前面上部に表示される特殊なウィンドウで,メインメニューのような役割を果たしますが,Windows版のSDIモードでは正式にサポートされていません。特に,複数のモニターが接続されており,それぞれの解像度や形が違っている状況でツールバーを表示すると,ウィンドウの幅が足りなかったり,ウィンドウが間違ったスクリーンに表示されたりします。これは仕様です。SDIモードでは,ツールバーに依存せず,それぞれのウィンドウが独立して機能するようなデザインにする必要があります。
クイックレポートのHTML出力には,カスタムテンプレートを使用することができます。テンプレートは,特殊な「タグ」(PRCESS 4D TAGS
とは違うタグ)がコメント文で挿入されたHTMLテキストであり,整形されたレポートを出力するために使用されるものです。
タグを使用してテキストを挿入した場合,テンプレート内の改行コード(0x10
)は,すべて<br />
タグに変換されます。Document to text
コマンドでテンプレートをロードした場合,改行コードの数が違うために,HTML出力の体裁が変わってしまうことがあります。これは仕様です。クロスプラットフォームで改行の数を揃えるためには,Document to text
コマンドで同じ改行オプションを指定するようにしてください。
プロジェクトモードでは,フォームオブジェクトの「標準アクション」にオブジェクト毎のデフォルト値は特に設定されていません。たとえば,新しく作成したタブコントロールは,デベロッパが明示的に設定しない限り,「ページ移動」のボタンにはなりません。これは仕様です。
ビルドしたアプリケーションをアップデートするたびに,データファイルの場所を尋ねるダイアログが表示される場合,「アプリケーション配付の新しいアーキテクチャ」が有効にされているかどうか,確認することが勧められています。
以前の「アーキテクチャ」は,データファイルの場所をストラクチャファイルに記録する,というものでした。そのため,.4DC
ファイルを入れ替えるたびに,パスを再指定する必要があります。新しいアーキテクチャでは,データファイルのパスがlastDataPath.xml
という外部ファイルに記録されるので,アプリケーションをアップデートした後もデータファイルのパスを引き継ぐことができます。詳細は,ドキュメントをご覧ください。
64ビット版の統合Webエリアは,レンダリングエンジンにCEF(Chrome Embedded Framework)を採用しているため,32ビット版(WebKit)とは振る舞いが違っていることがあります。一例として,.license4D
ファイルは,内容的にはHTMLですが,特殊な拡張子が付けれらたファイルなので,ソースコードがそのまま画面に表示されます。これは仕様です。拡張子が付いていないHTMLファイルも,同様にHTMLコードがそのまま表示されます。
アプリケーションまたはストラクチャにインストールされているプラグインは,通常,すべてビルドしたアプリケーションのPluginsフォルダーにコピーされます。特定のプラグインを除外するには,アプリケーションビルド設定ファイル’(プロジェクトXML)のArrayExcludedPluginID
キーを使用します。
4D Writeや4D Viewなど,古いタイプのプラグインは,15000
よりも若い固有のIDが振られており,番号で識別されます。一方,4D Internet Commands(15010
)のように15000
以上のIDが設定されているプラグインは,番号ではなく,固有の名前で識別されます。4D Internet Commandsをビルドしたアプリケーションから除外するのであれば,ArrayExcludedPluginID
ではなく,ArrayExcludedPluginName
を使用し,名前で指定する必要があります。
(例えばEメールで)ファイルを交換する前に、転送するサイズを小さくしたくて圧縮することがよくあります。4D v18を使えば、外部ライブラリーやツールを使わずにプログラムでファイルの圧縮解凍が可能です:
新しいZip Create archivesコマンドは、ファイル、フォルダ、あるいはパラメータを使ったオブジェクト(例:アーカイブを読むためのパスワード)などを受け渡す場合にzipアーカイブを作成できます。
ファイルを圧縮:
C_OBJECT($file;$destination)
$destination:=Folder(fk desktop folder).file("MyDocs/file.zip")
$file:=Folder(fk desktop folder).file("MyDocs/text.txt")
ZIP Create archive($file;$destination)
フォルダを圧縮:
C_OBJECT($folder;$destination)
$destination:=Folder(fk desktop folder).file("MyDocs/Images.zip")
$folder:=Folder(fk desktop folder).folder("MyDocs/Images")
ZIP Create archive($folder;$destination)
パスワードとプログレスバーを圧縮:
C_OBJECT($zip)
$destination:=Folder(fk desktop folder).file("MyDocs/Archive.zip")
$zip:=New object
$zip.files:=Folder(fk desktop folder).folder("MyDocs/Resources").folders()
$zip.password:="password"
$zip.callback:=Formula(FormulaCompressing ($1))
progID:=Progress New
ZIP Create archive($zip;$destination)
Progress QUIT (progID)
FormulaCompressing メソッド:
Progress SET PROGRESS (progID;Num($1/100))
新しいZIP Read archiveコマンドはアーカイブオブジェクトを返します。このオブジェクトを操作することによって、アーカイブの中のファイルのリストを簡単に入手、特定のファイルを解凍、全アーカイブを解凍などができます。
アーカイブのコンテンツを読む
C_OBJECT($archive;$path)
$path:=Folder(fk desktop folder).file("MyDocs/Archive.zip")
$archive:=ZIP Read archive($path)
ファイルとフォルダのリストを検索する
$folders:=$archive.root.folders()
$files:=$archive.root.files()
解凍せずにファイルのコンテンツを読む
If ($files[$i].extension=".txt")
$txt:=$files[$i].getText()
Else
$blob:=$files[$i].getContent()
End if
アーカイブからファイルを解凍する
$folderResult:=$files[$i].copyTo(Folder(fk desktop folder).folder("MyDocs"))
全てのファイルを解凍する
$folderResult:=$files[$i].copyTo(Folder(fk desktop folder).folder("MyDocs"))
このシリーズのブログでは、バイナリー・データベースをプロジェクト・データベースにコンバートする方法を提示してきました。全ての準備が整い、コンバートが成功したら、プロジェクト・データベースを使って作業を始めることができます。しかし、ここでいくつかの疑問が生じるかもしれません:データベース中の全てのファイルは役に立つのか?”.4DB”ストラクチャ・ファイルがもはや不要であることは明らかです。他のファイルを消去できるのでしょうか。
バイナリー・データベースでは、アプリケーションの定義は二つのファイル (.4DBと4DIndy)に保存されます。プロジェクト・データベースでは、このファイル中の定義は「Project」フォルダに保存されることに気がつくでしょう。
であれば、変換の後に以下のファイルを両方とも消去できます:
プロジェクト・データベースのアーキテクチャについて更に詳しくは、こちらのブログをチェックしてください。
開発段階では、データをストラクチャの隣に置くのが簡単でした(例:テスティング、他のコンピュータへ移動、など)。しかし、4Dの新しい機能の多くは特定のパラメータやファイルを保管するのに「データの隣」のコンセプトを使用しているため、開発テストで、ストラクチャの横のファイルではなく、データの横のファイルを使用していることを確認するにはどうすればよいでしょうか。
新しいプロジェクト・データベースでは、4Dは「Project」フォルダと同じ階層に「Data」フォルダを作成します。したがって、開発段階でも、データの横に置かれたファイルはストラクチャの横に置かれたファイルとは異なります。
そのため、コンバージョン後には下記のことをお勧めします:
4Dは4D環境に対するユーザー・プリファレンス、データベースにタイルするユーザー・プリファレンス、データベースの設定を持っています。
要約すると、4Dは「プリファレンス」という語をお互いに関連するユーザー・パラメータに対して使用し、「設定」という語はデータベースに関連するパラメータに使用しています。
より詳しくはこちらのブログをご覧ください。
このビデオでは、前回のブログでコンバートした”Contacts”データベースを使用します。
最初に、ダイヤグラム中の上記のコンセプトを繰り返し実行し、それから”Contacts”データベースを使って結果を示します。
これまでの4Dバイナリー・ストラクチャは、macOSとWindowsプラットフォームの両方でフォーム中に使われるフォント、フォントサイズ、テキストのスタイルを特定するためのスタイルシートを定義できました。プロジェクト・データベースでは、さらに進化して4ステイト・ボタンのプロパティを定義したり、全てのライン・オブジェクトの色や境界線を特定したり、アプリケーションのリストボックス 全てのヘッダーの高さを設定することもできます!CSSの文法やシンタックスにインスパイアされて、4Dはプロジェクト・データベースのフォームの特定のニーズに合わせて改良しました。スタイルシートのおかげで、本当に視覚にアピールするフォームを作成するためのプロパティ全てを設定できます。このブログでその方法を紹介します!
プロジェクトデータベースでは、両方のプラットフォーム(WindowsとmacOS)に対して、個々のスタイルシートと「オーバーオール(全てに適用)」スタイルシートを定義できます。
なぜプラットフォームごとに異なるスタイルシートが必要なのでしょうか?それは、macOSで使われるフォント/フォントサイズはWindowsのものとは異なることがあるからです。その一方で、テキストのカラーはどちらも同じということがよくあります。
”Stylesheets.css”ファイルと独自のファイル中のプラットフォーム指定のスタイルを定義できるようになりました:”stylesheets_mac.css”と”stylesheets_windows.css”です。
プロジェクト・データベースの主な改革の一つは、フォームオブジェクトがサポートする全てのプロパティーをスタイルシートの中で使えることです。
例えば、”ボタン-アクション”クラスを作成して、”ツールボックス”状で、グレイのテキストの、フォーカス化できない4ステート・ボタンを作成することができます。
.buttonAction {
iconFrames: 4;
style: toolbar;
stroke: grey;
focusable: false;
}
これにより、同じグラフィックデザインを保持しながら、アプリケーションに対するデザインフォームを簡単に作れます。
もう一つの大きな変更は、クラス、オブジェクトタイプ、オブジェクト名、属性によってスタイルシートを作成できることです。
オブジェクトタイプ・セレクター(CSSエレメント・セレクターと同等)を使うと、データベース中の全てのオブジェクトに適用できる汎用的なプロパティーを定義できます。例えば、全てのリストボックス が2行のヘッダーを持ち、空の行は表示されない、列の背景はgainsboroとwhitesmokeにします。
listbox {
headerHeight: 2em;
hideExtraBlankRows: true;
fill: Gainsborough;
alternateFill: white smoke;
このセレクターのおかげで、フォームオブジェクトに独自の外観とフィーリングを定義できます。
アトリビュート・セレクターを使うと、プロパティの値によってスタイルシートを定義できます。
例えば、データの入力/出力フォームで、レコードの追加、編集、削除のボタンがあります。これら全てのボタンは同じアイコン、タイトル、ヘルプティップを使います。
アクションボタンにスタイルシートを作成して、アクションプロパティに特定の値を指定しないのはなぜでしょう。例えば、もしアクションプロパティが”editSubrecord”の場合:
.buttonAction[action=editSubrecord] {
icon: url(“/RESOURCES/Images/Buttons/edit.png”);
tooltip: “:Cliff:button_tip_EditRecord”;
text: “:xliff:button_EditRecord” !important;
}