Go to English page.

NS Basic/CEはevent drivenです。すなわち、メインラインとされるコードの外でイベントが発生します。イベントを割込み（interrupt）として考えて下さい。イベントはあなたのプログラムに割込み、あなたのプログラムはそれに応える訳です。NS Basicではイベントを"テスト"することは出来ません。NS Basicはイベント待ち行列（event queue）のコンセプトはありません。ですからこのように考えて下さい。GUIをデザインする際、初期化の他に、全てのコードはユーザが引き起こすイベントに応えなければなりません。しかしイベントはそれが起こる時に発生します。どのイベント（どのボタン、リスト、グリッドがタップされるか）が起こるか、またはいつイベントが起こるかは予想出来ません。あなたのプログラムは、いつ、どんなイベントが起こってもそれに応えなければなりません。多くの重要でないユーザインタフェース処理をせずに、イベントを押し進めることは出来ません。

重要なのは、プログラムに応答するようにユーザを強いることは、するべきでないでしょう。プログラムをユーザに反応するよう作るべきです。もしユーザに特定の順序で何かをさせるようなプログラムを書いているようでしたら、それは多分、user-event-drivenシステム（ WindowsCE, Windows95/98/NT, MacOS, PalmOS等）としては間違ったデザインでしょう。現代のシステムは、、ユーザに自由を持たせ 、プログラムがユーザに何をさせたいかではなく、ユーザがしたいことが出来るようにさせます。考え方の違いですが、長期的にみた場合、簡単で優れたプログラムになるでしょう。

あるシステム (Windows95/98/NT, MacOS, etc.) は、イベント待ち行列のコンセプトを持っており、イベントのテストも可能でしょう。これらのシステムの多くは、このメソッドを使ったイベント処理から、離れてきています。イベントループの為に、なぜCPUサイクルを使わなければならないかということです。オブジェクトを使用することで、イベントが発生する時いつでも、オブジェクトがそれに応答出来ます。これがオブジェクト指向プログラミングにつながります。オブジェクトはどうイベントに応答するかが分かっています。プログラムはオブジェクトをセットし、初期化する為に使われます。プログラムはイベントの事を気にするべきではないでしょう。listboxはlistboxのイベントにどう対応するかを知っています。gridはgridイベントについて知っているでしょう。コマンドボタンは、gridboxがgridboxイベントをどう処理するかを心配する必要はありません。コマンドボタンは、gridboxがgridboxイベントに応答すると認識しているかもしれませんが、他のオブジェクトによって処理されるイベントに応答するべきではありません。

イベントがある時、何も起こらない間、ループを回して待ち続けることはするべきでないでしょう。タイマーが必要な時は、直接または間接的に何かを計る時です。ループを使用する時は、何かをカウントする時で、何かが起こるのを待つ時に使うべきではないでしょう。

event-drivenシステムにおける、ループを使用してアプリケーションをコントロールする時の他の問題は、ユーザインタフェースで起こっていることとは独立していることです。すなわち、（CPUを独り占めしない限り）それらは平行して行われます。ループの使用は何かが起こるまで、CPUを占有するでしょう。ですから、これはWinCE上では良い考えとは言えず、簡単でもないでしょう。

Serge Koren