202008 のの会@関数Talk 23rd @function-talk-in-notesknows-workshop

@ -notes knows community- 2020/08/06 @関数Talk 第23回 公開版 @ 阿部 覚 (tw:) @abesat

@ 予告させていただいたように今回は、 @DeleteFieldと@Unavailableを扱うつもりです 先に、前座として別の関数について少し： @

@ @SetField と FIELD キーワード @ を前座あつかい

@ フィールドに値をセットする関数 いずれも機能としては 「このフィールドにあの値をセットする」 というものです このフィールド あの値 @SetField("FieldA"; ValueB); このフィールド @ あの値 FIELD FieldA := ValueB;

@ フィールドに値をセットする関数 かつては使い方の制約がありましたが 今はほぼ同じように使えると思います @SetField("FieldA"; ValueB); @ FIELD FieldA := ValueB;

@ 前座終了 @

@ @DeleteField @Unavailable @ を雑談

@ フィールドの値を削除する関数 ヘルプにはこの２つの関数が「同じです」と明記されています @DeleteField 「編集可能フィールドの値を削除します。」 「この関数は @Unavailable と同じです。」 @Unavailable @ 「編集可能フィールドの値を削除します。」 「この関数は @DeleteField と同じです。」

@ フィールドの値を削除する関数 以上の情報だけで素直に考えると こんな風に記述されそうに思うのですが 🤔 @DeleteField("FieldA"); @Unavailable("FieldA");; @

@ フィールドの値を削除する関数 以上の情報だけで素直に考えると こんな風に記述されそうに思うのですが 🤔 @DeleteField("FieldA"); @Unavailable("FieldA");; ちがいます 😲 @

@ フィールドの値を削除する関数 実際の構文を見ると、こういう使い方が正しいようです 前座の前述の、FIELDキーワードと組み合わせて使います FIELD FieldA := @DeleteField FIELD FieldA := @Unavailable @ 「フィールドの値を消す」と動きでみるより 「フィールドが消えた状態」を値として持っているのをセットする という感じですね…

@ ふつうの使い方 ヘルプによれば 「この関数は、エージェント式、ビューアクション式、ツールバーボタン 式で機能します。」 ここではビューアクション式にて実装してみます @

@ ふつうの使い方 フォームに存在するFieldA と フォームには存在しないFieldB が 文書にセットされています 文書画面はこんな感じ @ 設計で見ると FieldAは フィールド設計があるけど FieldBにはナシ 計算結果テキストで 文書にセットされた値を 表示してるだけ

@ ふつうの使い方 ビューアクション式はそれぞれ こんな感じ @ 先に書きますと、実行結果は（当然ながら）どちらも同じでした

@ ふつうの使い方 すなわちどちらを実行しても、実行後はこうでした 値が消えていますね @

@ ふつうの使い方 実行前後の 文書のプロパティを見ると Before Before @ FieldAもFieldBも 消えているのがわかります After After

@ ふつうの使い方 実行後の文書を開き、消された2つのフィールドを確認します @

@ ふつうの使い方 文書を開いてみると、あれ？ FieldAのほうは 別の値が入っています 「Domio Volt」ですと？ FieldBは FieldBは …Gone …Gone😢 😢 実は設計によるもので FieldAには デフォルトの値が 設定されていました @

@ ふつうの使い方 2つの関数のヘルプにはこうも書かれています 「フィールド値にデフォルト値がある場合は、 この関数によって現在の値が削除された後に デフォルト値が復元されます。」 復元自体は関数の働きによるものではないことがわかると思います 文書を開いたら復元したように見えるだけで、 文書を編集・保存しない限りは 本当にデフォルト値が復活するわけではなさそうです。 @

@ ふつうじゃない使い方もやってみる ヘルプによれば 「編集可能フィールドの値を削除します。」 「この関数は、エージェント式、ビューアクション式、ツールバーボタン 式で機能します。」 これを無視して、 ● ● ● ● 編集可能でないフィールドも対象に 編集中のフォーム内のアクションボタンの式として ２つの関数を実施してみます。 @

@ ふつうじゃない使い方もやってみる 実施してみるのはこんな文書の編集画面 編集可能フィールド(A_1)のほかに 計算結果(B_1)、表示用の計算結果(C_1)、作成時の計算結果(D_1) を 配置しています @

@ ふつうじゃない使い方もやってみる フォーム設計がこちら アクションボタンには、ボタン表示されているのと同じ式を入れています Targetで選択したフィールドの値を消す内容です @ 👆ヘルプに載っているFIELDキーワードの構文も無視して 👆ヘルプに載っているFIELDキーワードの構文も無視して @SetFieldを使っています…結論から言うとこれで動きました @SetFieldを使っています…結論から言うとこれで動きました

@ ふつうじゃない使い方もやってみる 編集可能フィールド(A_1)で実施した場合 ボタンを押しても、何も変わりませんでした @ ただし文書プロパティからは A_1が一時的に消えました

@ ふつうじゃない使い方もやってみる 各タイプの計算結果フィールド(B_1, C_1, D_1)でそれぞれ実施した場合 ボタンを押すと表示の値も消え @

@ ふつうじゃない使い方もやってみる 各タイプの計算結果フィールド(B_1, C_1, D_1)でそれぞれ実施した場合 ボタンを押すと表示の値も消え @ 文書を保存するとB_1, C_1は別の値になって復活しました

@ ふつうじゃない使い方もやってみる 各フィールドには、現在の「分」を入れる式が入れてあり @ 計算結果(B_1), 表示用の計算結果(C_1)ではそれが作用した形に

@ ふつうじゃない使い方もやってみる 作成時の計算結果(D_1)は最終的に""がセットされてしまっていました @ なお、表示用の計算結果(C_1)はそもそも文書に残らないので なお、表示用の計算結果(C_1)はそもそも文書に残らないので ビュー上の文書プロパティからは消えています ビュー上の文書プロパティからは消えています

@ ふつうじゃない使い方もやってみる この辺までにしておきましょう わざと仕様にないイレギュラーなことをやるのは 関数の性格を探る手掛かりさがし（と、多分に遊び心）ですが @DeleteField・@Unavailableで分かったのは、 内部のフィールドそのものを消す、という性格が クリアになったことでしょうか ただし編集画面の状態で行った場合には、 フィールド設計がなんらか作用して期待通りの結果にならない箇所がある ということでしょう @

@ 余談 ヘルプに「同じです」と書かれているのだから当然といえば当然ですが 今回確認した範囲で @DeleteField と @Unavailable の間で、機能に差は見当たりませんでした 一方で以前ご報告した @All・@True・@Yes・@Success のように ヘルプにはそうとは書かれていないものの 同じ関数と判断できるものもあります 混用されても混乱を招かないものは ヘルプで明示しているのかな？ @

@ ところで 次回以降の関数について ご希望はありますか？ 今回もお付き合い ありがとうございました 😀 @