みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
テーブル構造は以下のとおりです。
受注テーブル
- 受注ID
- 受注フラグ
- 商品ID
- 個数
- 単価
レイアウトは、受注テーブルオカレンスを対象とし、全てのフィールドを配置しています。
したいこと：
受注フラグがTrueの場合に、全てのフィールドを編集できないようにしたいです。
できれば避けたい方法：
新たに全て編集不可にしたレイアウトを作成する （修正幅が広くなりすぎるため）
全てのフィールドにトリガをかけて制御する （同上）
編集を禁止するのは、アクセス権セットで行うのが簡単です。
そのためには、ユーザーをアカウントで管理することが必要です。
詳しくは、ヘルプのセキュリティーの管理、または、公式トレーニング教材 を参照ください。
Offline
> 修正幅が広くなりすぎるため
この意味が分かりませんが、、
修正の作業量が多い
ということでしたら、
一度に複数のフィールドにトリガを設定できますよ。
レイアウトを分けるのはお勧めしませんが、、
Offline
レイアウトが１つなら、レイアウト全体に透明なボタンを配置して、
not(受注フラグ=True)ならオブジェクトを隠すを設定
ボタンはカスタムダイアログでも設定して、「受注済みなので編集できません」
でもいいかもしれませんね。
Offline
フィールドを2重に作っておき、片方は編集不可能にしておく。オブジェクトを隠すで、どちらかを隠しておく、という方法も。
Offline
透明ボタンの場合の注意事項
オブジェクトフィールドがあると、ボタンをかぶせても上に表示されてしまいます。
フィールドにタブ順があると、フィールドクリックしないでTabキーで入れます。
＞himadaneeさん
あ、確かにTABで入れちゃいますね 汗
却下ですな･･･。失礼しました。
Offline
Shinさん
ありがとうございます。
全フィールドを編集不可にするのは可能そうですが、
例えば受注状態の場合、備考しか編集できない というようなことも可能にしたいのですが可能でしょうか。
チポさん
全フィールドにトリガを設置すると、今後フィールドを追加するたびにトリガを設定しないといけません。
これが手間であるということです。
さすらいのダンサーさん
ありがとうございます。編集可能の場合は編集フラグをTrueにしておき、その場合のみTAB、Enterを制御する という動きは作りましたが
イマイチスッキリしていない感じです。
Shinさん
全フィールドにそれを実施するのは、非常に修正幅が大きくなりそうです。
すみません、ハンドルネームを間違えました。
> 例えば受注状態の場合、備考しか編集できない というようなことも可能にしたいのですが可能でしょうか。
備考のみを別テーブルにおけばいいです。
または、備考フィールドをボタンにしておいて、ポップアップやカスタムダイアログなどを表示させ、その中で編集させます。そのスクリプトを管理者権限で走らせます。
Last edited by Shin (2021-12-28 08:44:10)
Offline
運用中にフィールドを増やしてゆく前提は
ファイルの設計が間違っていますよ。
Offline
Shinさん
なるほど、テーブルごとに制御をかける形になるんですね。
と、すると、例えば発注テーブルや請求テーブルが増えた際に、特定条件下で編集不可の発注テーブルと、特定条件下でも編集可の発注テーブルと、テーブル数が多くなりそうです。
ボタンにするアイデアは試しましたが、全フィールドにボタンを配置するのがなかなか苦しかったです。
チポさん
ありがとうございます。
運用中に変更を加える前提でシステムを構築すること自体、間違いだとは思いません。
業務変化に対応する中で、テーブル構造を変更することもあるかと思われます。
> 発注テーブルや請求テーブルが増えた際に
という状況が考えられませんが、それはどういうことですか。
> 全フィールドにボタンを配置するのがなかなか苦しかったです。
ボタンのスクリプトでアクセスを制御するのではないですよ。全体としてはアクセス制限されているが、特定のフィールドだけを特別にアクセスできる状態を作る、という動きです。
全フィールドを例外的に編集可能にする、という動きを作る、ということでしたら、意味無いのでは。
アクセス制限をかけていないテーブルのフィールドを配置するだけでも、目的としてはいいのかも、
https://www.dropbox.com/s/ys3xb10f5vk4z … 2.zip?dl=0
Last edited by Shin (2021-12-29 16:08:02)
Offline
> 業務変化に対応する中で、テーブル構造を変更する
もちろんこれは有りですよね。
ここでもよく見かけますが、
時系列的に毎年フィールドを増やす。
このようなのは間違いでしょうと言ったのです。
しかし、
改良の手間を心配して、設定を考えるのもいかがなものかと。。
スクリプトで制限すればフィールド個々にどうでもできまし、、
ボタンよりよっぽどスマートだと思いますよ。
Offline
色々な手法があって面白いですね。私はさすらいのダンサーさんと同じで、透明ボタンでtab順の最初と最後のフィールドにスクリプトトリガでkick outするようにしてました。
普段ほとんどオブジェクトフィールドを使用しないので、透明ボタンの弱点を知れて良かったです。
透明ボタンを使用する前は別レイアウト（原本）でスライドコントロール上にレイアウトを作成、フィールド入力の制御を変更して複数コピペ、オブジェクトを隠すで表示するスライドを決めるという手法をとっていました。
この手法は原本で修正する事を忘れると少しめんどくさいことになるので止めました。
フィールド毎にスクリプトトリガで制御する手法は、新規フィールドを追加する際に既存のフィールドをコピペして使用すればほとんど手間はかからないし、良い手法だと思いますが。
Offline
Pages: 1
[ Generated in 0.008 seconds, 9 queries executed - Memory usage: 595.13 KiB (Peak: 612.03 KiB) ]