イベントをまとめる

この記事で扱っていること

を紹介しています。

注意：すべてのエラーを確認しているわけではないので、記事の内容を実装する際には自己責任でお願いします。また、エラー配線は適当な部分があるので適宜修正してください。

前の記事で、LabVIEWでプログラムを書くときに、見るべきもの、要素を少なくする、という点を意識したほうがいいことがある、ということで、ケースストラクチャを少なくするための工夫を紹介しました。

今回は、ケースストラクチャと同じく、条件が増えると項目が増える別のストラクチャである、イベントストラクチャを扱います。

まとめられるものはまとめてスッキリ書く、という工夫をすることで、複数のイベントをまとめる方法を紹介していきます。

私のブログでも過去に何度か、今回紹介する書き方をしてきましたが、これを説明している記事はなかったと思うので、改めて紹介していきます。

どんな結果になるか

例として示すのはとても単純なもので、複数のブール制御器（ボタン）や複数の数値制御器など、同じデータタイプの制御器が複数それぞれ異なる役割を持ってフロントパネルに置かれている場合を考えます。

これらに対するイベント、例えば値変更イベントを作って、どのボタンが押されたかを文字列表示器に表示するとします。

このようなプログラムを作る時、それぞれの制御器に対して値変更イベントを作るとなるとイベントの数が多くなりがちです。

似たような処理を行っているイベントは、一つのイベントにまとめることでイベントケースの数を減らし、見やすいプログラムに仕上げられます。

イベントストラクチャには、イベントごとに、イベントデータノードというノードが表れ、ここにある制御Refが使用できます。

この制御Refは、イベントが起こった対象の制御器のリファレンスを出すノードであり、同じイベントに対して複数の内容が書かれていたとしても、そのイベントが発生するトリガーになった制御器のリファレンスのみ取り出します。

これを使って識別をしていきます。

例として、5つのブール制御器が配置されている場合のプログラムの例は以下のようです。

ラベルのテキスト部分で条件分岐するためにケースストラクチャを使用し、その内容に応じて文字列表示器に表示する文字を変えています。

それぞれのブール制御器に対してイベントを作っていた場合、似たようなイベントが続くことになりますし、これ以外にもイベントがたくさんあった場合イベントの数が多くなり見にくくなるのを避けることができます。

上記ではラベルの名前で識別をしていました。

ですが、制御Refを使ってプロパティノードを眺めたとき、ラベルのテキストプロパティではなく、キャプションにもテキストプロパティがあることがわかると思います。

キャプションも、フロントパネル上に表示される制御器の上に表示される、その制御器の名前のようなものであり、ラベルと同じように見えます。

じゃあどちらのテキストプロパティでもいいのか、ですが、プログラムの機能としてはどちらでも構いません、がこれらはフロントパネルではなくブロックダイアグラム上に違いが出ます。

簡単に言うと、ブロックダイアグラム上に表示される制御器や表示器の端子名はすべてラベルです。

これら端子名はフロントパネル上でも見えるラベルの名前と一致しており、キャプションとは一致していません。

もちろん、ラベル名とキャプション名を同じにすることはできますが、異なる名前にした場合、ブロックダイアグラム上ではラベル名で表示されることになります。

ではどちらを使えばいいかということですが、ブロックダイアグラムの中で処理として推奨されるのはラベルのテキストのようです。

つまり、フロントパネルではキャプション表示をしておいて、ブロックダイアグラムではラベル表示をしている場合、同じ制御器に対して異なる文字を充てることができます。

それだとフロントパネルとブロックダイアグラムでの対応がわかりづらくなるじゃないか、と思われるかもしれませんが、利点がある場合もあります。

それは特にプログラムのローカライゼーションに関わることで、ユーザーが見える側のフロントパネルでは言語ごとのキャプションを表示しておいて、ブロックダイアグラム上では常に一つの（例えば英語の）ラベルテキストで処理を行う、という使い方です。

逆にキャプションのテキストを使って処理を行うと、キャプションの文字表記言語が変わるとプログラム上の処理もすべて変更する必要が出てくる可能性があるため、キャプションはそれぞれの言語で表示を変え、プログラム内の処理ではラベルを使うことで、ラベルの文字列を使った処理部分は変更する必要がなくなります。

本記事では、イベントをまとめる方法を紹介しました。

言われればわかるけれど、見たこと聞いたことがないと、一からこの組み方を考えつくのもなかなか難しいと思うので、見やすいプログラムを作るうえで参考になればうれしいです。

ここまで読んでいただきありがとうございました。