この記事では、プログラマ泣かせの操作をユーザーにさせないためのいくつかの設定やプログラム上の工夫について紹介しています。
プログラムは、これを作る人と使う人が別であるケースが多く、そういった場合に作る側が想定していなかった操作を使う人がした場合に期待した処理を進められないことが起こりえます。
やれることが限定的なプログラムであったとしても、ボタンの連打やポップアップ画面で必要なパラメータを入力するべき場面で誤って画面を消してしまうなどの操作により本来の意図と違う動作が発生してしまいます。
使う側がしうる全ての操作を想定してプログラムを組むことができればいいのですがそれも難しいことが多いのもまた事実。
アプリケーションにより、「してほしくない操作」の種類は変わるので、そのすべてを書き尽くすことはできませんが、比較的応用の効きやすい内容でとれる対策を紹介しています。
そんなことしないで！プログラマ泣かせのユーザー操作
LabVIEWはフロントパネルで簡単にユーザーインタフェースを作ることができ、プログラムを作る前から完成時のイメージを先に作っておける点が便利です。
ただ、ユーザーの操作というのは時に「プログラマが想定していなかった」状況を作り出してしまい、期待しない結果、予期しない挙動等が起こりえます。
プログラム自体への影響の度合いもバラバラですが、例えば以下のような操作は場合によって「されたくない」と思うことがあります。
- 設定をする必要がある、開いておく必要があるウィンドウをバツボタンで閉じる
- 特定のボタンを連打する
- ウィンドウのサイズを変えてしまう
- 特定のファイルの位置を変える、削除する
本来であれば、そうした事態にも対応できるようなプログラムにしておくのがいいのかと思いますがそれでも対応しきれない場合には、もういっそのこと「そんな操作ユーザーにさせない」という作りにしてしまうというのも作戦です。
やりすぎてしまえば、「決まったとおりにしか動かせない」ものになってしまうのですが、適度に実装して、想定していない状態にならない（なりにくい）作りにする方が、プログラムの役割そのものが果たせやすい分、結果的に良いことも多いと思います。
以下では、6つの場面についてプログラムや設定側でとれる対策を紹介していきます。
してほしくない操作と対応方法
ユーザー操作①バツボタンで閉じる
ウィンドウの表示をバツボタンで閉じるという操作は、ユーザー操作としてありがちだと思います。
一方で、プログラムを作る側としては、「設定してほしい値を設定してくれない」状態が発生するので、あまりしてほしくない操作だったりします。
手っ取り早いのは、VI自体の設定として、そもそもバツボタンを押しても反応（＝閉じる）させないような設定というのがまず考えられます。
VI自体の設定、ということで、VIプロパティ（Ctrl +Iのショートカット）で設定を行っていきます。
あるいは、イベントストラクチャのフィルターイベントで、バツボタンが押された時の挙動を決めるという方法も有効です。
イベントストラクチャを使用する方法の場合、プログラムの状態によってバツボタンを押すことを許可できたり、あるいは特定の警告を表示させることができるので、ユーザーに特定の操作を促すことができます。
ユーザー操作②キャンセルをする
バツボタンを押す以外でもユーザーが操作を「拒否」するようなパターンがあり、それがキャンセル操作です。
とはいえ、キャンセル操作というのはLabVIEWの仕様上そのような操作を行えるというよりプログラムの中でキャンセルボタンを用意してそれに対する処理を実装している状態なので、そもそもキャンセル操作を行えるようにプログラムを書いている時点で、ユーザーがそういった操作をしうる前提でプログラムを書いているはずです。
例えばあるポップアップ画面が複数回表示される可能性のあるプログラムにて、2回目以降はキャンセルを許すけれど1回目はキャンセルしてはいけない、といった、場合分けを行うことがよかったりします。
2回目以降に関しても、キャンセル操作をした後の出力としてデフォルト値を出すか、キャンセル操作がされたというフラグをメインVIの方に渡すか、前回値を渡すかという選択肢があります。
ユーザー操作③ボタンを連打する
ユーザーによっては不必要に、あるいはたまたま何かの原因でボタン操作の反応が鈍かったときにユーザーがボタンを連打してしまうという状況も起こりえます。
最も厄介なのは、イベントストラクチャによるフロントパネルのロックです。
効率のいいプログラムはポーリング（ユーザーの操作があるまでその操作の有無を監視し続けるためにループが無駄に回り続ける状態）させることなくイベントストラクチャで処理を始めることが少なくないと思いますが、イベントストラクチャでのフロントパネルロックは時に厄介な状態を引き起こします。
一応設定でそもそもロックさせなくするということもできますが、むやみにイベントを生成するような作りとなるので健全ではないことが多いかと思います。
そもそもイベントストラクチャを使う際にロックされることが不都合な場合には、イベントストラクチャの中に時間がかかる処理を置かないように意識する必要があります。
ただ、イベントストラクチャの中に処理があるかどうかに関係なく、ボタンが連打され、同じイベントがイベントキューにたまり続ける状態が不都合、という場合もあると思います。
このような場合には、プロパティノードで無効プロパティを使用してボタン操作を行えなくさせるという手が便利です。
その他の例では、プログラムの途中でイベント検知自体をさせなくするためにイベントのダイナミック登録/解除の仕組みを設けるのも一案となりえます。
ユーザー操作④ウィンドウの大きさを変える
フロントパネルの大きさの変化が気にならない場面もあるかと思いますが、ウィンドウで見えている範囲の外に、「プログラム的には必要だけれどユーザーに見せたくない制御器表示器」がある場合、ウィンドウの大きさを変えられてしまうのは避けたいところです。
（そのような制御器表示器はそもそも表示させておくのではなく隠す設定にするというのもありですが）
これについてはプログラム的に設定をするようにしておけば、何か理由があってプログラムの途中から変更してもOK、というような柔軟性を持たせられます。
また、VIプロパティのウィンドウサイズカテゴリで、最小のパネルサイズを決められます。
「ウィンドウを大きくすることはできるけれど、一定以上小さくはできない」ような状態となるので、不用意な操作によってフロントパネル上のボタンが押せなくなったり表示が見えなくなるといった事態を防げます。
ユーザー操作⑤ウィンドウの表示位置を変える
ウィンドウの位置を変更してほしくない、という場合もあると思います。
いくつかのVIとの表示上の兼ね合い上、この位置にウィンドウが表示されていてほしい、みたいな場面です。
ウィンドウが移動するということを検出するイベントそのものはないですが、ウィンドウを移動させるためにマウスが一度ウィンドウの外に移動してウィンドウを動かしその後操作のためにマウスがウィンドウの中に戻ってくることを利用して元の位置に戻す方法が考えられます。
ユーザー操作⑥決まった場所のファイルを移動する
プログラムでファイルを扱う際には、データを保存する以外に、プログラムで使用する設定値を読み込むという場面もあります。
このときに、例えばユーザーが知らずにファイルを移動してしまったことで、必要なファイルがプログラムが想定している場所に存在していないと、正しい処理を行えなくなり、全く予期しないパラメータで処理が始まる、というのは避けたい状態かと思います。
必要な場所にファイルがなかった場合には警告を出して、そこにファイルが存在するようになるまでその後の処理を進めることができなくさせる、という対応が考えられます。
あるいは、ファイルがないことがわかったら、ひとまず最低限のデフォルト値を渡せるようにその場でファイルをプログラム内で生成しておけば、次回以降はそのファイルを読み込ませられるようになるのでこちらの方が都合がいいということもあると思います。
本記事ではいくつかのユーザー操作に対して設定あるいはプログラムの組み方としてどのような方法で対応していくかについて例を紹介しました。
ユーザーが「変な」操作をした場合であっても、正しく動作をしていないプログラムは、ユーザーとしては「バグがある」と判断してしまうかもしれません。
プログラムを作る側としては「そんな操作するなんて思ってなかったから」と言いたくもなりますが、未然に防げる問題に対する策を実装する際の参考にしてみてください。
ここまで読んでいただきありがとうございました。
コメント