イベント初心者講座 その6 または The Compleat Angler For Kiri 桐V8の釣魚大全

「かっこう」掲示板の投稿記事から、主に藤野さんとONnojiの問答集を作りました。何か役に立つ話が見つかるカモ?

トップページに戻る あらすじ その1 その2 その3 その4 その5 その6 その7 その8 その9

表示のON/OFFは利用者を戸惑わせます - ONnoji 2002年02月18日 22時02分
大成功です。(^o^)丿 - 藤野 2002年02月18日 23時25分
ユーザーインターフェースの出発点は、 - ONnoji 2002年02月19日 00時03分
うーん、考えさせられますね。 - 藤野 2002年02月19日 22時53分
説明不足でした - 藤野 2002年02月20日 00時05分
利用者が満足感を得られるデザイン - ONnoji 2002年02月20日 12時50分
男は黙って[ソース値更新]イベント! - ONnoji 2002年02月20日 16時22分
Re:男は黙って[ソース値更新]イベント! - 藤野 2002年02月20日 22時23分
第3関門難航中 - 藤野 2002年02月21日 22時40分
ただいま第三関門突破作戦立案中です。 - ONnoji 2002年02月22日 20時53分
第三関門 試してみました - 藤野 2002年02月23日 19時51分

表示のON/OFFは利用者を戸惑わせます - ONnoji 2002年02月18日 22時02分

藤野さんへ

> やはり勘違いでした。
> 早速、ラベルで貼り付けました。

そうそう、固定文字だからラベルオブジェクトでいいのです。(^^ゞ

> それでは、次に挑戦
> 左下にメッセージを出すにはオブジェクト操作だな
> とあたりをつけて・・・
> 下記のようにしました見事エラーでした
> 手続き定義開始 t氏名::入力前(参照 文字列 &編集文字列)
> 表 ”写真展住所録”
> オブジェクト操作  @コメント注意,画面表示=0
> if ([氏名]=#U)
>  オブジェクト操作  @コメント注意,画面表示=1
> end
> 手続き定義終了
> どうも画面表示=0
>    画面表示=1
> の後にプロパティ名を指定するらしいのです。
> プロパティ名とは何でしょうか。?

プロパティとは属性の名前のことです。

さて、入力前イベントは使わないで下さい。
代わりに、入力後とソース値更新のふたつのイベントを使いましょう。
男は黙ってサッポロビール。
まず、次のように試してください。

手順
1.局所変数をフォーム定義の変数管理でひとつ登録してください。

  mMsg 局所 文字列

2.フォームの左下にテキストボックスでオブジェクト名:txtMessageLine を作ってください。

3.txtMessageLine のソースは &mMsg を指定してください。

4.txtMessageLine の属性の[表示]タブの[フォーカス設定可能]で"禁止"を選んでください。

※ついでに、[罫線モード]を"なし"、[背景色モード]を"透明"にするといいです。

5.t氏名 の[入力後]イベントハンドラを次のように作ります。

手続き定義開始 t氏名::入力後(参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
 &編集文字列 = #trim( &編集文字列,3 )
手続き定義終了

6.t氏名 の[ソース値更新]イベントハンドラを次のように作ります。

手続き定義開始 t氏名::ソース値更新() ※ソースは半角カタカナです。一応(^^ゞ。
 if ([氏名]=#u)
 &mMsg = "氏名が入力されていません"
 else
  &mMsg = #u
 end
手続き定義終了

※ #u は #未定義と同じです。

以上ですが、

必ず[入力前]イベントをOFFにしてください。
※必要ならば[入力前]イベントハンドラは削除してください。

では、結果をリプライしてください。(^^ゞ

<追伸>

オブジェクトを表示したり表示しなかったりするのはいいことではありません。

オブジェクト操作 @オブジェクト名.画面表示 = "0"
オブジェクト操作 @オブジェクト名.画面表示 = "1"

このようにして、いままで見えていたオブジェクトが、
状況によって突然消えたり、突然現れたりするのは利用者を戸惑わせるだけです。(~_~;)

表示のON/OFFはしないというふうに覚えてください。
格好よりユーザを困惑させないことが大切です。

大成功です。(^o^)丿 - 藤野 2002年02月18日 23時25分

ONnojiさん
 黙ってサッポロビールで 
 
 大成功です、感激でした。
面白くて何度も未定義を入力してみました、ついでにメッセージ
もかえながら試しました。
色まで変えたりして・・・。さすがに色は黒に戻しましたけど。

ここまで来るといよいよ3段目の
全部が入力して名前が入力していなかったらメッセージを出して、
名前に移動するというパターンですね。

ということはこれも住所2の入力後イベント、更新イベント、
フォーカス()
という組み合わせでしょうか

でも、第2段階でメッツセージをだしているのでここでフォーカス
を氏名に戻すでも実用上は大丈夫なような、気がしますが
いかがでしょうか?

 でも、その他の項目も入力がなかったらということだとやはり
最後のチェックが必要ですね。
必ず入力が必要なのは
氏名 ふりがな 〒 住所1
です

連名や住所2は記入しないこともあるのでここはパス

すると
氏名 ふりがな 〒 住所1 のどれかが #U の時はメッツセージ
をだすということですか?

ユーザーインターフェースの出発点は、 - ONnoji 2002年02月19日 00時03分

藤野さんへ

> 黙ってサッポロビールで大成功です、感激でした。
> 面白くて何度も未定義を入力してみました、ついでにメッセージもかえながら試しました。
> 色まで変えたりして・・・。さすがに色は黒に戻しましたけど。
> ここまで来るといよいよ3段目の全部が入力して名前が入力していなかったらメッセージを出して、
> 名前に移動するというパターンですね。

そんなに急がないでいきましょう。(^^ゞ

> ということはこれも住所2の入力後イベント、更新イベント、
> フォーカス()
> という組み合わせでしょうか
>  でも、その他の項目も入力がなかったらということだとやはり
> 最後のチェックが必要ですね。
> 必ず入力が必要なのは
> 氏名 ふりがな 〒 住所1
> です
> 連名や住所2は記入しないこともあるのでここはパス
> すると
> 氏名 ふりがな 〒 住所1 のどれかが #U の時はメッツセージ
> をだすということですか?

そうですね。
t氏名 以外のところでも、未入力が困る場合には、
&mMsg = "住所1が未入力です" とかすればいいと思います。

強制的にフォーカスを移さなくても、
フォームの左下に作ったメッセージ領域に注意が表示されるだけで十分でしょう?
子供じゃないのですから、いちいち手取り足取りするのは結構おせっかいですよね。

最近読んだ本にユーザーインターフェースの出発点は、
「ユーザーを愚かに見せるな」ということが書いてありました。

ユーザー自分がプログラムに操られていると思わせるようなデザインは悪いです。
ユーザーがプログラムを操っている(支配している)のだと思うようにデザインすることが、
ユーザーに満足感を与えるということを覚えてください。

> でも、第2段階でメッツセージをだしているのでここでフォーカス
> を氏名に戻すでも実用上は大丈夫なような、気がしますが
> いかがでしょうか?

ユーザーが理解できない実用一辺倒よりも、ユーザの自尊心を傷つけないことの方が大切だと思いますが…

リプライをお待ちしています。

うーん、考えさせられますね。 - 藤野 2002年02月19日 22時53分

ONnojiさん今晩は、
ユーザーがプログラムと操っているのだと思うようにデザインする。
またしてもなるほどです。
 自分に置き換えれば、キーボードを操作することで使っている
という満足感がでてきますね、それといっしょですね。

フォーカスの件はメッセージを表示させるだけにとどめることにします。

 さて今度は50音を項目[読み1]に入れることに挑戦してみました。
ここは50音フォームでグループ設定しているので計算項目は指定でき
ないところなので、悩んでいたところですが、昨日のアドバイスで、
もしかしたらと思って書いてみました、とりあえず成功です。

[ふりがな]から先頭の文字を選び あ か さ た・・・・わ
グループ化させるためにつくりました。

手続き定義開始 t住所2::入力後(参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
if([読み1]=””)
 項目値代入 [読み1]=(#条件選択([ふりがな]<か,あ,[ふりがな]<さ,か,[ふりがな]<た,さ,[ふりがな]<な,た,[ふりがな]<は,な,[ふりがな]<ま,は,[ふりがな]<や,ま,[ふりがな]<ら,や,[ふりがな]<わ,ら,1,わ))
else
end
手続き定義終了

これでいかがですか。

説明不足でした - 藤野 2002年02月20日 00時05分

表で
氏名 ふりがな・・・・読み1

とあります。

氏名の入力で ふりがな が自動で入力になります。

読み1 は ふりかな から あ か さ た・・・
と入れるように条件選択で書いてみましたが・・・

今回はあえて フォームの最終入力場所
住所2が終了した後にイベントで代入できるように
してもました。
ふりがな 入力後でもよかったかもしれません。

尚 読み1 は 追加住所フォームには表示させていません。

これは50音 の表で グループで使用しています。

利用者が満足感を得られるデザイン - ONnoji 2002年02月20日 12時50分

藤野さんへ

> ユーザーがプログラムと操っているのだと思うようにデザインする。
> またしてもなるほどです。
>  自分に置き換えれば、キーボードを操作することで使っている
> という満足感がでてきますね、それといっしょですね。

ご理解いただいて嬉しいです。(^^ゞ
そうなんですよ〜!利用者が満足感を得られるデザインが大切です。

ということで、私が十数年前に熱心に読んだ書籍から役に立ちそうなところをご紹介しましょう。
----------------------------------------------------------------
・主体的な制御権を与える

経験の豊富な操作者は、自分がシステムを制御し、システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力、あるいは欲しい情報を得ることが不可能または困難であったり、期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
Gaines(1981)はこの原理を、「不条理を避ける」という彼の原則と、ユーザーを応答者にするのではなく主導権を与えるという提案で表現している。
----------------------------------------------------------------

また、次のようなことも書いてあります。この文章が書かれて翻訳されたのは1987年ですから、2002年の現在でも依然としてソフトウェアは技術中心に設計されていて、利用者中心に設計されていないことがよく理解できると思います。もちろんすべてのソフトウェアがそうだというわけではありませんが…
----------------------------------------------------------------
情報メディアにはコンピュータの話題があふれており、大衆の意識を向上させることなど必要ないと思われているかもしれない。しかし実際には、多くの人がコンピュータを不愉快に思っている。
しかたなく預金引き出し機やワードプロセッサを使うけれども、いつもミスを恐れ、機械を壊すのではないかと心配し、使いこなせないために無能ではないかと不安に思い、「自分より利口な」コンピュータに脅されているように感じている。
そもそもこの不安は貧弱な設計にも一因がある。複雑なコマンドを提供したり、敵対的で不明確なエラーメッセージを表示したり、素直になじめないような動作や擬人的な対話法を使っていれば当然のことである。
----------------------------------------------------------------

> フォーカスの件はメッセージを表示させるだけにとどめることにします

第二段階でフォーカスは移動させる必要はありません。
手取り足取りモードは止めましょう。

しかし、第三段階ではフォーカスを移して上げる方が親切なのです。
考えてみてください、いざ登録という段階で「未入力項目がありますよ!」と利用者に教えておいて何もしないのですか?
この場合、未入力項目へフォーカスを移してあげるのは過剰サービスでは決してありませんよ。(^^ゞ

男は黙って[ソース値更新]イベント! - ONnoji 2002年02月20日 16時22分

藤野さんへ

> さて今度は50音を項目[読み1]に入れることに挑戦してみました。
> ここは50音フォームでグループ設定しているので計算項目は指定でき
> ないところなので、悩んでいたところですが、昨日のアドバイスで、
> もしかしたらと思って書いてみました、とりあえず成功です。
> [ふりがな]から先頭の文字を選び あ か さ た・・・・わ
> グループ化させるためにつくりました。
> 手続き定義開始 t住所2::入力後(参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
> if([読み1]=””)
>  項目値代入 [読み1]=(#条件選択([ふりがな]<か,あ,[ふりがな]<さ,か,[ふりがな]<た,さ,[ふりがな]<な,た,[ふりがな]<は,な,[ふりがな]<ま,は,[ふりがな]<や,ま,[ふりがな]<ら,や,[ふりがな]<わ,ら,1,わ))
> else
> end
> 手続き定義終了
> これでいかがですか。
> 表で
> 氏名 ふりがな・・・・読み1
> とあります。
> 氏名の入力で ふりがな が自動で入力になります。
> 読み1 は ふりかな から あ か さ た・・・
> と入れるように条件選択で書いてみましたが・・・
> 今回はあえて フォームの最終入力場所
> 住所2が終了した後にイベントで代入できるように
> してもました。
> ふりがな 入力後でもよかったかもしれません。
> 尚 読み1 は 追加住所フォームには表示させていません。
> これは50音 の表で グループで使用しています。

このようなことは[入力後]イベントではなく、[ソース値更新]イベントで行うと覚えてください。

t住所2の属性の[イベント]タブの[イベント]のリストで[ソース値更新]が下に隠れて見えていなかったからでしょうか?
それとも、[入力後]という言葉に誘われたのでしょうか?

もう一度、[入力前][入力後][ソース値更新]のイベントのおさらいをしましょう。

まず、一番使用頻度が高いのは[ソース値更新]イベントです。
[入力前]と[入力後]イベントはあまり使いません。
[入力前]と[入力後]イベントは「 &編集文字列 という引数を利用する場合に使う」と覚えてください。

(例)手続き定義開始 txtObject::入力前( 参照 文字列 &編集文字列 )
(例)手続き定義開始 txtObject::入力後( 参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
 
今回の例は &編集文字列 という引数を利用することがありませんよね。
だから、[ソース値更新]イベントを使うべきなのです。

これらのイベントの使い分けはとても分かりにくいので
§1で[ソース値更新]イベントを説明し、§2で[入力前][入力後]も説明しました。
これは[ソース値更新]イベントが一番使用頻度が高いためにこういう順番で説明しているわけです。

また、これらのイベントの名前の付け方が悪いのも確かで、このために分かり難さが増幅されていますね。
特に[ソース値更新]イベントの「ソース焼き蕎麦」みたいな名前はなんだコリャ〜です。
しかし、[入浴前][入浴後]なども、まあ〜五十歩百歩ですね〜。

ですから、
入力前    … [編集初期値]イベント
入力後    … [入力値整形]イベント
ソース値更新 … [編集終了]イベント

というように別の名前に置き換えて覚えるといいですよ。(^^ゞ

[ソース焼き蕎麦]…いいえ違いました!、特に[ソース値更新]イベントは万能に使えるイベントです。
ですから、男は黙って[ソース値更新]イベント!です。
※このCM古いですね〜(T_T)

<追伸>

この投稿を書くときに桐のhtmヘルプを見ましたが、

[入力後]イベントの■使用目的に次のことが書いてあります。

(1)・[テキストボックス]に入力された文字列を検査して、添わないデータであれば再入力させます。…省略…
(2)・[テキストボックス]に入力された文字列を変更して、[テキストボックス]に戻します。…省略…

さて、(1)は以前にもお話したようにあくまでも説明であって、こう使うといいというわけではありません。
利用者の入力のテンポを邪魔するように、突然降ってわいたように、再入力を強制するのはよくないのです。
地雷がドッカーンですね。

これによく似たものに、表定義の項目属性の[制約]タブの[未定義値禁止]があります。
この[制約]タブの設定はできればすべてOFFが望ましいですが、
もしも設定するならば、項目属性の[入力]タブの[ガイドメッセージ]で注意書きをするのを忘れないことです。
「ここに地雷が埋まっていますよ!気を付けてお通りください!」と一言声を掛けるのがエチケットでしょう。

では、なぜ[制約]タブに地雷の設定があるのかというと、こういう機能がソフトの「宣伝上のウリ」になるからです。
そうです、どのソフト会社も口を揃えて、「わが社の製品はどなたでも手軽に地雷を埋めることが出来ます!」とね。

少し前ですが、桐の仕事を引き継いだばかりの人が地雷に引っかかり、困り果てて幅田さんのBBSに投稿されていました。
「訂正から表示へ移行できないので困っている」という内容だったのでご返事をしました。(^^ゞ

地雷の話はこの辺で終わりにして…(2)の使い方こそが[入力後]イベントの本当の使い方なのです。

Re:男は黙って[ソース値更新]イベント! - 藤野 2002年02月20日 22時23分

ONnojiさんこんばんは、

入力前    … [編集初期値]イベント
入力後    … [入力値整形]イベント
ソース値更新 … [編集終了]イベント

これわかりやすいですね。

私も
ソース値更新 … [編集終了]イベント
に訂正して確認しました、上手く動きます。

今から第3関門に突入します・・・・
結果は明日の晩になると思います。

第3関門難航中 - 藤野 2002年02月21日 22時40分

ONnojiさんこんばんわ

第3関門 難航中です

通常住所2でエンターを押すと通常は次行に移動します。

ここで[氏名]が#未定義だったらフォーカスを[氏名]に戻す

[〒]が#未定義だったらフォーカスを[〒]に戻す。

としようと思ったのですが

手続き定義開始 t住所2::ソース湛洪)
if ([氏名]=#U)
 メソッド呼び出し @t氏名.フォーカス設定( )

end
手続き定義終了

このようにしても次行にいってしまいました。

このときはソース値更新は使わないのですか?

ただいま第三関門突破作戦立案中です。 - ONnoji 2002年02月22日 20時53分

藤野さんへ

ただいま第三関門突破作戦立案中です。

明日リプライいたしますので、もうしばらくお待ち下さい。

第三関門 試してみました - 藤野 2002年02月23日 19時51分

下記のようにしましたが・・・。
上手く作動するのですが・・・それにはタブオーダーの設定
住所2を継続にしなければなりません。
そうするとフォームに 追加 のコマンドボタンを追加すれば
よさそうです。

イベントは下記のようにしてみました
手続き定義開始 t住所2::ソース湛洪)
if ([氏名]=#U)
  メソッド呼び出し @t氏名.フォーカス青蝓福
  項目値代入 [氏名]=””
 else if([〒]=#U)
  メソッド呼び出し @t〒.フォーカス青蝓福
  項目値代入 [〒]=””
end
手続き定義終了

これで実験は成功です、
でも、上記のようにコマンドボタンを追加していると
機能名
行追加
ではグループが上手く追加できません。

ソース値更新のあとにどうかすると
タブオーダーが次行のままで今までのように行が追加
されると思うのですが、まだ実験中です。


トップページに戻る あらすじ その1 その2 その3 その4 その5 その6 その7 その8 その9