みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
himadaneeさん
いつもながらご回答ありがとうございます。
Windowsでは確認することがなかったので、ご指摘は非常にありがたい情報でした。
多言語対応を考えたときに、インスペクタでの書式設定では自由度が減ってしまうので、
ロケールを取得して、自由度のある多言語対応の書式を用意できないかと考えていました。
Windowsでは、全く当てになりませんが、Macでの情報を繰り返し見ているうちに、
["M$","D#","YYYY#","D$"]
YYYY#:西暦年の数字表記
M$:月の文字列表記
M#:月の数字表記
D#:日の数字表記
D$:曜日の文字列表記
を意味し、配列の前から順に[2番目、3番目、4番目、1番目]で並べると、
ロケールに沿う表記になるものと判断しました。
(なぜ配列の4番目が1番目になっているのかは不明ですが)
また、セパレーターを意味すると思われる
[", "," ",", ",""]
については、
配列の順番通りに、それぞれ順番での表記に続く接尾語とするとロケールに沿うものと
思われました。
上記の英語で再現すると、
Thu, Oct 26, 2023
となります。
なんとなく、Mac版であれば、こんなところかな?と言うところまで行きましたが、
Windows版もとなると、有用性がかなり下がってしまいます。
誰かがこの謎を解決してくれる(倉栗鼠の中のヒトなら知っているはずだと思いますが)ことを期待して、
この質問は未解決のままとさせていただきます。
ぜひ、回答をお持ちの方は教えてください。
(macOS Sonoma 14.0 , FileMaker 20.2.1.60)
Get ( システムロケール要素 )で得られるJSONについて、キー(パス)の詳細をご存知の方はいらっしゃるでしょうか?
ヘルプを見ても、取得例が載っているだけで、各キー(パス)の意味合いが不明です。
具体的には、日本語環境(Mac)のときに、
"Date.YMD.ElementArray.NameList" → ["M#","D#","D$","YYYY#"]
と
"Date.YMD.ElementArray.SepList" → ["年","月","日 ",""]
の構成を知りたいです。
ちなみにアプリケーション言語を英語にすると、
それぞれが、
["M$","D#","YYYY#","D$"]
[", "," ",", ",""]
になります。
NameListは、#がつくと数字表記、$がつくと名称表示かと思われるのですが、D$が何を意味するのかわかりません(曜日?)。
その順番も、英語の場合だと、記載の順(月→日→年)になっているようですが(D$が曜日だとすると、慣習的には最初に来るはず?)、
日本語だと、月日、D$、年となっていて、通常の年月日の順に並んでおらず、理解ができません。
SepListは、日本語の場合だと、年月日の順でそれぞれのセパレータそのものを意味すると理解できますが、
英語の場合だと、1番目を飛ばして(最初に曜日との境界?)、2番目が月と日の間のセパレーター、3番目が日と年の間のセパレーターを意味していそうで、
相互の違いが分かりません。
英語圏でも同様の質問をされている方を見かけましたが、回答は得られていませんでした。
もし知っている方がいたら、ご教示ください。よろしくお願いいたします。
Shinさん
ご回答ありがとうございます。
他言語では使われているのですね。
私の思い出では、そのようなものを見て感じたものではないんですよねぇ。
himadaneeさん
そのような解釈もありえはしますね。
ただ、私が気づいたと思っているのは、ここ数年以内の話なので、6に関することはなさそうです。
うーん、みなさんからの意見を見ると、私の夢の中の話な感じがしてきました。
この質問は「解決」にはしないでおくので、もし、これだ、というのがあった方は、ぜひ教えてください。
よろしくお願いいたします。
himadaneeさん
ご回答いただき、大変ありがとうございます。
{{時刻}}、{{日付}}は、レイアウト上の挿入文字列ですね。
確かに、昔は、//や::が使われていたかも知れません。
いつぐらいまでだったでしょうか・・・。
私の記憶の話は、
2つのものが繋がっている場合の表記で、それがTO名とフィールド名の関係ではなかった、というものです。
もし、思いつく方がいらっしゃれば、ご回答よろしくお願いいたします。
ちなみに「リレーションシップ記号」という言葉はヘルプでの「フィールド名の指定」
https://help.claris.com/ja/pro-help/con … ields.html
に出てきます。私も、そこら辺でしか見たことないですが・・・。
もし、これだ!とお気づきの方がいらっしゃったら教えてください。
ファイルメーカーでダブルコロン「::」と言えば、リレーションシップ記号として、
テーブルオカレンス名::フィールド名
と言う使われ方が一般的だと思います。レイアウト上でリレーションフィールドであることを示すために、
::フィールド名
と表記されるのも一般的かと思います。
そこで質問ですが、
私が昔、何らかのリファレンスを読んでいた時に、上記の使い方以外で、使われるような記載を見かけた気がするのです。
どなたか、上記以外で、このリレーションシップ記号「::」をファイルメーカー上で使われることがあるか、知っている方がいらっしゃったら教えてください。
あまり、リファレンスを読んでいて自分で使うな、という印象がなかったので、ExcecuteSQL関数やData API関連で、BaseTableが絡んでくるあたりかと思い、再度リファレンスを眺めてみたのですが、見つかりませんでした。
技術的解決を求める質問ではないのですが、ふと、気になってしまい、ここならそんな知識も得られるのでは? と思い質問してみました。
そんな使われ方は存在しない、と断言いただいても構いませんし、昔は使われていた・・・と言うような回答でもOKです。
よろしくお願いいたします。
なしたまご様
37です。解決されたようで、何よりです。
該当Appは、
三条項BSDライセンス (3-clause BSD license)
「無保証」であることの明記と著作権およびライセンス条文自身の表示を再頒布の条件とするライセンス規定
で配布しておりますので、無償でOKです。
個人使用なら全く気にしなくて良いですし、配布するようなら、
私の著作権とライセンス条項を表示いただければ、ライセンス違反にはなりません。
ただし、これを利用することで生じるいかなる損害についても、開発者は責任を問わないことはご承知おき下さい。
ライセンス原文については、該当App内でも確認できるようになっています。
また、
https://licenses.opensource.jp
で確認することもできます。
よろしくお願いいたします。
なしたまご様
FMDB-blue開発者の37と申します。
ご利用いただき、大変嬉しく思っております。
ご質問に対して、簡単に説明すると、
ログを取るレコードについての固有のIDとなる、いわゆる「主キー」は、
FMDB-blue_Dataファイル内の
D_LogDataテーブル
d_DataID.textフィールド
(D_LogData::d_DataID.text)
に保存されます。
また、テーブルを指定するには、
GetBaseTableAddressFrom(%tableOccurenceName)
関数で得られる
「BaseTable名@BaseFile名」となっているデータが必要です。
※BaseTable名やBaseFile名は、ExecuteSQL関数でのみ確認できるデータです。
D_LogDataテーブルでは、
d_BaseTableAddress.textフィールドに
このテーブル指定のための「BaseTable名@BaseFile名」が
保存されてます。
SampleApp_Interface.fmp12ファイルで、
該当レコードに関連するログを表示するようにしてありますので、
ご参照ください。
説明下手で申し訳ございません。
可能な限り対応させていただきますので、不明な点がありましたら、
またお聞きください。
よろしくお願いいたします。
himadaneeさん
Shinさん
Mozさん
重鎮の皆さんにご確認いただいたようで、大変ありがとうございます。
私もMozさんのおっしゃるような印象を持っていたので、
下記のMain()、_Loop()2つのスクリプトを用意してテストしてみました。
私のESCの押し方にも問題があるのかもしれませんが、
何度試しても、Endのカスタムダイアログが表示されません。
ちなみに⌘+.でも同じ挙動でした。
一時的なバグならよいのですが、皆さんの感触だと、以前からも同じ動きを
していそうなので、あまり解決策はない、と考えた方がよいのでしょうか?
引き続き、ご意見をいただければと思います。よろしくお願いいたします。
Main()
ユーザによる強制終了を許可 [ オフ ]
カスタムダイアログを表示 [ "Start" ; "開始しました。" ]
スクリプト実行 [ 指定: 一覧から ; 「_Loop()」 ; 引数: ]
ユーザによる強制終了を許可 [ オフ ]
カスタムダイアログを表示 [ "End" ; "終了しました。" ]
_Loop()
ユーザによる強制終了を許可 [ オン ]
Loop
Exit Loop If [ Let ( [ $counter = $counter + 1; $wait = 0 ]; 1000 < $counter ) ]
Loop
Exit Loop If [ Let ( [ $wait = $wait + 1 ]; 1000 < $wait ) ]
End Loop
新規レコード/検索条件
End Loop
FileMaker Pro 19.3.2, macOS Monterey 12.0.1
ループ処理を行うスクリプト(ループスクリプト)があり、処理内容にバグ、重い処理が入っていた場合に、
ユーザーが対応できるように、そのスクリプトの最初に「ユーザーによる強制終了を許可」をオンにしてあります。
ただ、上記のループスクリプトを実行させる前に
処理用のレイアウト等の設定をスクリプト(前処理スクリプト)で行なっており、
この前処理スクリプト内で、上記のループスクリプトを実行させています。
事後処理も、この前処理スクリプトでおこなっており、
途中で終了されないように、この前処理スクリプトでは「ユーザーによる強制終了を許可」をオフにしてあるのですが、
強制終了をおこすと、この前処理スクリプトも終了となってしまい、
事後処理が行われず、ループ処理中のレイアウトが表示されてしまいます。
ユーザーによる強制終了を行わせたあとに、自動でスクリプトを実行させる方法はありますでしょうか?
ご教示よろしくお願いいたします。
himadaneeさん
ありがとうございます。
xmlとして保存
にそんな利用方法があったのかと驚きです。
(他に活用方法があるのでしょうか?)
このxmlで、
問題を表向き解決したファイルと、
解決していないファイル
の2つで比較したのですが、明らかな違いは見つかりませんでした。
あえていうならoptionタグで囲まれた数値が違っていますが、他のフォルダを見ても、
その法則は分かりませんでした。
なお、ファイルはFMP16からコピーしながら使っているものです。
ただ、フォルダ等はすべて、FMP19で作成したものだと思います。
これは、先に述べた、カスタムメニューのインポートが難しいので、
テンプレートファイルを作って、それをコピーして使い回していたと言う理由からです。
ちなみに、先に「他のファイル」と表現した、想定どおりの動きを
したDBファイルも、同じ経緯で作成されたものです。
XMLの情報を見る限りでは、ファイルに保存された情報ではなく、
クライアントのどこかに保管された情報が邪魔をしているのかも知れません。
引き続き、新情報がわかったら教えてください。
himadaneeさん
ありがとうございます。
当方は、Windowsのテスト環境がないので、他環境で調査いただけるのは、
暗中模索の中、非常に心強いです。
あれから、私も色々試して、解決が少し見えてきたので、ご報告いたします。
まず、初心に帰って、他のDBファイルでどうか? と調べてみました。
すると、他のDBファイルでは、想定通りの動きをしました。
となると、DBファイルそのものに問題あるか、
あるいは、DBファイルに基づく情報が、さらにどこかに隠されているのか?
と考え、一番の対策は、新たにDBファイルを作り直すこと、と思いました。
しかし、実際にその作業を始めて見ると、特に、カスタムメニューや
レイアウトのところで、インポート、コピーペーストができず、あまりの作業量に
断念しました。
(ちなみにファイルの修復や別名で保存、それぞれのオプション設定も
いろいろ試しましたが、どれ1つ変化はありませんでした。)
そこで、ふと思い立ち、該当DBファイルで、いくつか新しくフォルダを作成してみました。
すると、新しいフォルダの中に、開くやつと閉じるやつの2種類が作成されたので、
閉じるフォルダだけ残して、そこに元のフォルダからスクリプトを移行させてみました。
残りの開いてしまうフォルダは全部削除し、
新しく作って残ったフォルダの名前を、元のフォルダと同じにして、
ファイルを閉じたところ、
やっと、該当DBで想定通りの動きをしてくれました。
結局、どこに問題があったかも分からず、まだ気色悪さは残るのですが、
とりあえず、ファイルの動きは、希望通りになったので、これでよしとしています。
個人としては対策の目処はたったのですが、原因や対処法として正しいのかは不明なため、
解決済みにはしないので、情報をお持ちの方はご教示いただけますと大変助かります。
解決済みにしないのが問題であれば、その旨もご教示お願いします。
himadaneeさん
たびたびの検証ありがとうございます。
Appを完全終了させてからの書き換えに間違いはありませんでした。
今、当方で確認できている状況を説明すると、
PlistのScrpitWorkspaceを、すべてゼロにした状態で、該当ファイルを開くと、
2つのフォルダが開いていて、1つのフォルダが閉じています。
(毎回同じ状態で、3つのフォルダがあります)
その状態のまま変化させずに、appを完全終了させてplistを確認すると、
ScriptWorkspaceのうち2つが1に変わっていました。
その変わったもののUUIDで検索をかけると3つがヒットするのですが、
うち2つがScriptWorkspaceで、もう1つは、値がMarkerになっている
項目Markerでした。
それぞれを再びゼロに戻して、再度ファイルを開いても、元の状態のままで、
今度は、3つ全てのフォルダを開いて、appを完全終了させ、plistを確認すると、
先ほどのUUIDで4つヒットし、3つのScriptWorkspaceが1になっていました。
(もう一つは先程の項目Marker)
そのまま、再度ファイルを開くと、やはり元の状態のままで、
2つのフォルダが開いていて、1つのフォルダが閉じています。
そこで、appを完全終了させ、plistを確認し、UUIDで検索するとヒットするのが
3つに減っており、2つのScriptWorkspaceが1になっていて、ゼロになっている
ScriptWorkspaceはありませんでした。
引き続きよろしくお願いいたします。
himadaneeさん
情報提供ありがとうございます。こんな情報が分かるなんてスゴいですね。
ファイルのUUIDは分からない以上、フォルダ数等で判別つけるしかなさそうです。
それでも、その情報管理の場所がわかっただけで、非常にありがたいのですが、
その対象ものすべてをゼロにしても、結局、appを落としたあとに開いたファイルでは、
以前と特に変化がありませんでした。
バグみたいな感じなのでしょうか???
Shinさん
早速の情報提供ありがとうございます。
サーバーでも調整したいと思っておりますが、
私の気色悪く思っているところは、ローカルに置いてあるファイルで、
スクリプトワークスペースの表示を変更しても、それがappを落とした後だと、
ファイルを閉じた時の状態が再現されないところです。
しかも、開いているフォルダと閉じているフォルダ両方があるところです。
スクリプトワークスペースの「ファイルのデフォルト」というのが、
何を意味しているのか? そのデフォルトはどうやったら変更できるのか?
が分かるとよいと思っております。
引き続き、よろしくお願いいたします。
FileMaker Pro 19.3.2.206 on macOS Big Sur v11.6
スクリプトワークスペースで、フォルダの展開や折り畳みした状態が保存されません。何か解決方法を知っている方はいらっしゃいますでしょうか?
該当DBファイルを開いて、閉じて(macではファイルを閉じただけではappは落ちない)、再度、DBファイルを開く、という流れだと状態が保持されているのですが、
ファイルメーカーappも完全に閉じて、そこで再度、DBファイルを開き直すと、閉じた時の状態が保持されていません。
すべて折り畳まれている、あるいは、すべて展開されている、ならまだ挙動して理解できるのですが、この完全に閉じてから開くと、特定のフォルダは展開されて、それ以外のフォルダは折り畳まれた状態なり、どこかで、この情報が保持されているのではないかと思っております。
Web検索をして、下記の記載を見つけましたので、
https://support.claris.com/s/article/Fi … anguage=ja
--
FileMaker Pro 15では、スクリプトワークスペースによってフォルダの展開/折り畳み状態がファイルに書き込まれることがなくなり、代わりにユーザの環境設定としてクライアントコンピュータに保存されます。フォルダのデフォルトは、折り畳まれた状態です。
FileMaker Pro 15 で作成されたフォルダを旧バージョンで開くと、まずは、折り畳まれた状態で表示されます。環境設定を削除してからもう一度開いたときも折り畳まれた状態で表示されます。FileMaker Pro 15 でフォルダを作成すると、そのフォルダは、当該のクライアントコンピュータの当該のダイアログでのみ展開された状態で表示されます。
--
FileMakerの環境設定ファイルと思われる
~/ライブラリ/Preferences/com.filemaker.client.pro12.plist
で、
ScriptWorkspace:[ファイル名]
という項目を見つけたのですが、ここのデータは、現在開いているスクリプト(のID)を記録しているもので、フォルダの開閉記録を示すものは見つかりませんでした。上記記載からも、クライアントマシンを変えると状況が変わるのでは? と思うのですが、所持しているマシンが少なく、それも試せておりません。
機能上は問題ないとは思うのですが、少し気色悪いので、解決方法をご存知の方、情報をお持ちの方に、ご教示いただければと思います。
よろしくお願いいたします。
42さん、himadaneeさん
ご意見ありがとうございました。
ヘルプは見ていたはずなのですが、意識を持って読まないと、意味が理解できていないことがよく分かりました(汗)。
仕様としてそうなっているなら、安心して空白("")を用いることもできますし、JSONオブジェクトか、JSON配列かを明確化するとの要素も、よく分かりました。
一応、下記のようなカスタム関数を考えており、ここでの引数としてキーが空白が指定されても、
エラーにならないで欲しく、その手法に迷っておりました。
仕様が分かれば、キーの最初の文字を判別して処理を分ける方法もあったのだと思うのですが、
それよりは下記例の方がシンプルかと思っております。
// JSONPushElementToArray ( %JSON; %key; %value; %type )
// Purpose
// JSON内の該当する配列にpushさせる(新しい値を最後に付け加える)。
// Parameter
// %key: 配列が格納されているJSONキー。
// %value: Pushするデータ。
// %type: PushするデータのJSONタイプ。
Let ( [
%JSON = If ( Exact ( %JSON; "{}" ) or Exact ( %JSON; "[]" );
"";
%JSON
);
%key = If ( Exact ( Left ( %key; 2 ); "['" );
"." & %key;
%key
);
%last = If ( IsEmpty ( %JSON );
0;
ValueCount ( JSONListKeys ( %JSON; %key ) )
)
];
JSONSetElement ( %JSON;
%key & "[" & %last & "]"; %value; %type
)
)
Filemaker Pro 19.3.1のリリースノートで
強化された関数
JSON 関数 – JSON 関数内のキーまたは索引またはパス引数でパスがカッコ表記で表現されていればキー名にピリオドを含めることができます。
との記載について、
ピリオドが含まれたキー名のJSONデータを作成したいと思い、
データビューアで下記計算式を試すと、
JSONSetElement ( "";
[ "['レイアウト.応答']"; "test"; JSONString ]
)
? in Json::Value::resolveReference(key, end): requires objectValue
とエラーになります。
これを正しく評価させるには、
JSONSetElement ( "";
[ ".['レイアウト.応答']"; "test"; JSONString ]
)
{"レイアウト.応答":"test"}
あるいは、
JSONSetElement ( "{}";
[ "['レイアウト.応答']"; "test"; JSONString ]
)
{"レイアウト.応答":"test"}
とする必要があります。
ヘルプを見ても、JSONSetElementで初期値として入力するのは、
"{}"
の方にするのがよいと思ったのですが、
これでルートが配列になっているデータにしようとすると、
JSONSetElement ( "{}";
[ "[0]['レイアウト.応答']"; "test"; JSONString ]
)
? in Json::Value::operator[](ArrayIndex): requires arrayValue
となり、この場合はエラーが出ます。
JSONSetElement ( "";
[ "[0]['レイアウト.応答']"; "test"; JSONString ]
)
[{"レイアウト.応答":"test"}]
こちらの方では意図した結果になります。
''{}'
の方では、意図した結果を得る方法は見つかりませんでした。
皆さんの意見を伺いたいのですが、
JSONSetElementで、空白データにデータをセットしていく場合、
初期値として、
""と"{}"
のどちらがよい、との見解はありますでしょうか?
私自身は、上記挙動から汎用性を考えて、""を選択しようかと思っております。
皆さんの意見を教えてください。
Pages: 1
[ Generated in 0.011 seconds, 9 queries executed - Memory usage: 678.19 KiB (Peak: 715.72 KiB) ]