4D Japan
テクニカルサポートブログ-
POP3で受信したGmailが削除される
Gmailの設定「メール転送とPOP/IMAP」には，「POP でメールにアクセスする場合」という項目があり，下記のオプションから動作を選択できるようになっています。
- Gmailのメールを受信トレイに残す
- Gmailのメールを既読にする
- Gmailのメールをアーカイブする
- Gmailのメールを削除する
「削除する」または「アーカイブする」が選択されている場合，POP3で受信したメッセージは（明示的な削除命令を発行しなくても）受信トレイから取り除かれます。その他のオプションが選択されている場合でも，すでにダウンロードしたメッセージは受信できないようになっています。
POP を使用して他のメール クライアントで Gmail のメールを読む
POP3クライアントでダウンロードしたメッセージにPOP3クライアントで何度もアクセスしたいのであれば，アドレスに接頭辞
recent:を追加し，recent modeでGmailにアクセスすることができます。その場合，すでにPOP3でダウンロードしたメッセージであっても，過去30日分のメールは繰り返し受信できるようになります。
-
BLOBの最大サイズ
ドキュメントには，BLOBの最大サイズが
2,147,483,647バイト（2GiB）であると述べられています。Windowsの場合，空きメモリが充分であれば，そのようなBLOBを作成することができます。しかし，macOSの場合，そこまでおおきなBLOBを作成することはできません。これはプラットフォームの制限であり，仕様です（NewHandle）。SET BLOB SIZEで検証すると，macOSにおけるBLOBの最大サイズは，空きメモリが充分であっても，1,073,741,823バイト（1GiB-1）であることがわかります。
-
ARRAY TO LISTとSAVE LIST
プロジェクトモードでは，特に指定しない限り，書き込み禁止のパッケージ（拡張子
.4DZの圧縮されたプロジェクトフォルダー）がビルドされます。ビルド後にプロジェクト（ストラクチャー）を更新することはできない点に留意してください。つまり，テーブルやフィールドを追加するようなSQL，SAVE LISTARRAY TO LISTSET PICTURE TO LIBRARYCREATE INDEXなどのコマンドは使用できません。これは仕様です。アプリケーションが内部ファイルを書き換えることは一般的に推奨されていません。これにはインストール済みアプリケーションを部分的に更新すること，たとえばビルドされたアプリ内のストラクチャーファイルを入れ替えることも含まれます。オペレーティングシステムやセキュリティソフトウェアは，そのようなアプリを「悪意のあるプログラム」とみなすかもしれません。
プロジェクトモードで開発したストラクチャーをビルド後に書き換えるのであれば，オペレーティングシステムやセキュリティソフトウェアの監視対象からアプリケーションを外すことに加え，拡張子
.4DZの圧縮されたパッケージを作成するのではなく，コンパイルコードをそのままエクスポートする必要があります。そのようなアプリをビルドするには，ビルド設定ファイルの「PackProject」キーを使用します。https://doc.4d.com/4Dv19/4D/19/PackProject.300-5447945.ja.html
しかし，セキュリティ上のベストプラクティスに倣い，アプリケーションはRead Onlyモードで配付し，部分的にではなく，全体を入れ替えるような仕方でアップデートするべきです。過去のバージョンで開発されたストラクチャーの場合，プロジェクトモードに移行した後，下記の点をチェックすると良いかもしれません。
初回データファイルをRead Onlyにする
- v15で追加されたDefault Data
最後に使用したデータファイルの場所をストラクチャーに書き込まない
- v16で追加されたアプリケーション配布のアーキテクチャー
データベース設定をストラクチャーに書き込まない
- v16で追加されたデータファイル用のユーザー設定
バックアップ設定をストラクチャーと同じ階層に保存しない
ストラクチャー書き換えコマンドを使用しない
- SET PICTURE TO LIBRARY
- SAVE LIST
- ARRAY TO LIST
- CREATE INDEX
- DELETE INDEX
- SET INDEX
- IMPORT STRUCTURE
- REGENERATE MISSING TABLE
-
ごみ箱にドラッグ＆ドロップ
v19のデザインモードでは，エクスプローラーのごみ箱にアイテムをドラッグ＆ドロップで移動することはできません。削除ボタンを使用する必要があります。これは仕様です。
v19のデザインモードは，プロジェクトモードに変換されており，内部的にJSONフォームを使用しています。JSONフォームのラジオボタンやチェックボタンは，バイナリモードのようにドラッグ＆ドロップに対応していないことに留意してください。エクスプローラーのタブは，3Dボタン（ラジオボタン形式）で構成されています。
-
4D v18.5 修正リスト
-
SET WINDOW RECTのシンタックス
SET WINDOW RECTのパラメーターは，left;top;right;bottomです。x;y;width;heightではない点に留意してください。Mac版のv18r6では，left > rightまたはtop > bottomの場合，leftおよびtopの位置にウィンドウが表示されました。v19ではこの問題が是正されています。rightbottom座標以外の値を指定しているコードは，アップグレード後に振る舞いが変わるかもしれません。これは仕様です。
-
フォームエディター設定が表示されない
プロジェクトモードでは，マーカー・境界・ルーラー表示のフォームエディター設定が個別に保存されません。これは仕様です。各フォームをエディターで開いた時にデフォルトで表示される項目は，フォームのタイプ（詳細またはリストフォーム）で決まります。
-
サーバーの検索とローカルキャッシュの仕組み
ビルド版のクライアントアプリは，公開名またはIPアドレスに基づき，自動的にサーバーを発見して接続を試みますが，
Altキーを押しながら起動することにより，「サーバーに接続」ダイアログでサーバーを指定することもできます。同一マシン上に同名のクライアントアプリがインストールされている場合，それぞれのクライアントで接続したサーバーの情報は，いずれも同じ設定ファイルに記録されるため，最後に終了したクライアントのサーバーがデフォルトのサーバーとなります。これは仕様です。サーバー側のキャッシュフォルダーパスは「アプリケーション/ストラクチャ名」です。v18r5以降，ビルドプロジェクトファイル（buildApp.4DSettings）の
ServerStructureFolderNameでキャッシュフォルダーパスのストラクチャ名を設定できるようになりました。この仕組みは，同名のサーバーアプリケーション（たとえばバージョン違い）を同一マシンにインストールするような場合に便利です。https://blog.4d.com/multiple-instances-of-merged-server-applications-on-the-same-machine/
サーバー側のキャッシュフォルダー名は，Info.plistファイルに書き込まれています。
<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.4d.ServerCacheFolderName</key> <string>myCacheFolder</string> </dict> </plist>クライアント側のキャッシュフォルダー名は「ストラクチャ名_サーバーアドレス_ポート番号_ハッシュ値」です。３桁のハッシュ値は，クライアントアプリのファイルパスに基づいて計算されます。v18r5以降，ビルドプロジェクトファイル（buildApp.4DSettings）の
ClientServerSystemFolderNameでキャッシュフォルダー名をカスタマイズできるようになりました。この仕組みは，別々のサーバーに接続する同名のクライアントアプリケーションを同一マシンにインストールするような場合に便利です。https://blog.4d.com/multiple-servers-one-shared-local-resources/
クライアントアプリは，ストラクチャ名・サーバーアドレス・ポート番号がすべて一致するローカルキャッシュを利用し，内容が変更されていない限り，サーバー側のキャッシュからリソースをダウンロードしません。この仕組みにより，後から同名の別サーバーに接続したクライアントアプリにより，キャッシュフォルダーが書き換えられてしまうことはありません。
クライアント側のキャッシュフォルダー名は，データベースリンクファイル（.4DLink）で指定することもできます。
<database_shortcut is_remote="true" server_database_name="Test" server_path=":19813" cache_folder_name="clientCacheFolderName" />つまり，ビルド版クライアントアプリのEnginedServer.4DLinkと同じ使い方ができます。
v18では，起動後，すぐにサーバーに接続するクライアントアプリ（過去バージョンの4D Client）ではなく，ビルド版のデスクトップアプリから任意のタイミングでサーバーに接続することができます。下記の要領でサーバーに接続することができます。
OPEN DATABASE("path_to_server.4dlink")起動時にサーバーを検索する代わりにローカルのデータベースプロジェクトを開始するには，ビルドプロジェクトファイル（buildApp.4DSettings）の
DatabaseToEmbedInClientWinFolderDatabaseToEmbedInClientMacFolderを使用します。これらのキーが設定されている場合，EnginedServer.4Dlink の代わりにデータベースプロジェクト（.4DC または .4DZ）がビルド版クライアントアプリの Database フォルダーにコピーされます。Default data の仕組みを併用することにより，初回起動時に「データファイルを開く」ダイアログが表示されることを回避できます。https://blog.4d.com/deployment-made-easy-with-4d-v18/
-
DELETE SELECTIONは中断しない
DELETE RECORDとDELETE SELECTIONでは，レコードロックの仕組みが異なるため，トリガの振る舞いに違いが存在します。後者の場合，複数のレコードがロックされている可能性があるため，LockedSetシステムセットに削除できなかったレコードの情報が記録され，レコード毎にエラー処理メソッドが実行されることはありません。これは仕様です（v2004以降）。v2003では，削除できなかった最初のレコードでON ERR CALLメソッドが実行され，DELETE SELECTIONの処理は中止され，以降のレコードすべてがLockedSetシステムセットに追加されました。現行バージョンでは，レコードが削除できなかった場合，ON ERR CALLメソッドは実行されず，LockedSetシステムセットが更新されるだけで，DELETE SELECTIONの処理は継続されます。これにはトリガで削除が防止されたレコードも含まれます。下記の記述（「コマンドの実行は即座に停止し・・・」）はv2003の振る舞いを説明しています。
レコードのセレクションで動作しているコマンドのフレームワーク内のトリガーによってエラーが生成されると (DELETE SELECTIONのような) ，コマンドの実行は即座に停止し，セレクションは必ずしも完全に処理されません。この場合は，デベロッパーによる適切な処理が必要となります。例えばセレクションを一時的に保存したり，トリガーの実行前にエラーを取り除くなどの処理が必要です。
https://doc.4d.com/4Dv15/4D/15.6/Triggers.300-3817569.ja.html
現バージョンの振る舞いは下記のとおりです。
レコードのセレクションで動作しているコマンドのフレームワーク内のトリガーによってエラーが生成されると (DELETE SELECTION，APPLY TO SELECTION，ARRAY TO SELECTIONなど)レコードは処理されず，自動的にLockedSet に登録されます(セット 参照)。コマンドは終わりまで実行が続けられ，このときエラーはキャッチされません。つまりエラーハンドリングメソッドは(あったとしても)呼び出されません。このコンテキストにおいて，エラーが生成されたかどうかを確認するためには，コマンドの呼び出しの直後にLockedSet をテストする必要があります。また，トリガでは，エラーをあとで適切に管理するためには，エラーコードを例えばコレクションなどに保存する必要があります。
https://doc.4d.com/4Dv18R6/4D/18-R6/Triggers.300-5199080.ja.html
-
4D v18.4 Hotfix 3 修正リスト