知人のWindowsXP Home Editionが起動しなくなり、何とかOSの再インストールをしないで修復・復活出来ないものかと、手を尽くして悪戦苦闘している。

事態は深刻で、回復コンソールを使って修復オプション付きでチェックディスクを掛けても、またＭＢＲを書き換えても、セーフモードでさえ立ち上がらない。つまり、OSのシステムファイルのいくつかが破損してしまったために、起動しないものと推測される。

修復インストールという手があるが、購入したパソコンは最初からＯＳが組み込まれており、添付していたリカバリーディスクでは修復インストールが出来ない。（EPSON Direct社に電話にて確認）。原因はハードディスクの部分的損傷と考えられ、衝撃を与えたこともないため経年劣化による「自然な」破損と考えられる。

そこでせめてデータだけでも救出できないものか、と初めてLinuxデストリビューションの１つである KNOPPIX を使ってみた。KNOPPIXは雑誌「PC JAPAN」が本格的に取り上げ、付録のCDまたはDVDによく掲載されているので、以前からその存在は知っていたが、本格的に利用するのは今回が初めてである。

さて、データをUSBフラッシュメモリに待避させたいわけであるが、そこで新たな問題が生じている。

KNOPPIXがUSBフラッシュメモリを認識しないのだ。自宅のマシンで試したところ、それは問題なくUSBフラッシュメモリを認識した。しかし、どういうわけか、当該の問題のマシンではそれが出来ない。USBフラッシュメモリから立ち上げられるKNOPPIX迄作り、それから問題のパソコンを起動し、それは成功したのだが、データ待避用として当該のUSBフラッシュメモリを使えないのである。

USBフラッシュメモリのマウントをコマンド入力によって試みたが、それも拒否された。

どうしたものかと、この年末に途方に暮れた一日であった。

追記

• 「イベント」関連エントリイ in this Blog

コンテンツ改訂履歴

• 初稿：2006/12/26
• 第１回改訂：2008/02/26……続きが書いてなかったので加筆した。
  またイベントバインド方法に関する視点を抜本的に改訂し、DOM レベル2 で推奨された「面妖な」方法を王道的手法として位置づけ、逆に簡易な方法として自らも好んで使用してきた DOM レベル0 による２つの方法の推奨度を低下させた。

WEB上での様々なイベント発生をJavascriptに「認識させ」、認識した当該イベントに対応して、WEB上で何らかの処置を行う───これはクライアントサイドJavascript（※）の基本中の基本だ。

「クライアントサイドJavascript」とはWebブラウザに組み込まれたJavascriptインタプリタのことを指すらしい（←「JavaScript」第３版：David Flanagan著）

ところがイベントの諸情報（イベントの種類、発生位置、発生要素等）を Javascript に認識させる方法が大変複雑で、それで結構「疲れてしまう」のである。

イベントハンドラ関数を HTML タグの属性として記述する方法が最も早くから行われている（上記書籍より）とのことだが、その場合に関数の記述はたやすいことだが、当該イベントの発生元要素を Javascript に認識させるには、ちょっとしたコツが要る。

例えば、マウスクリックが発生した時に、今そのイベントが発生した要素を Javascript が認識するには、単にマウスクリック時に起動する関数を記述するだけでは用を為さない。よく知られているように this キーワードを用いることが一般的になっているが、その場合であっても、発生したイベントそのものを Javascript に知らせることはブラウザ毎に方法が異なり結構面倒だ。

オブジェクトとしてのイベント

そこでまず、果たしてブラウザは、Javascriptは一体イベントをどう処理しているのか？　それをしっかり抑えておく必要が生じる。

Javascript ではイベントを抽象的なオブジェクトして位置づけ、イベント発生時にブラウザに組み込まれた Javascript インタープリタにそれを認識させるようにした。例えば、Mozilla系ではイベントハンドラー関数の引数に、暗黙かつ自動的にイベントオブジェクトを渡し、IEでは当該イベントオブジェクトを window のプロパティとして（window.event）補足する。

イベントハンドラーのバインド

次に、作者は意図した要素に意図したイベントを結びつけねばならない。つまりイベントのバインド対象を設定する必要がある。そこで、W3Cでは addEventListener()メソッドによってイベントを「監視する」ことにした。こうすることにより、或るイベントとイベントハンドラーを、或る要素に緊結（バインド）させ、かつ当該イベントにより呼び出されるイベントハンドラー関数には、その唯一の引数としてイベントオブジェクトを自動的に渡すようにした。

よく知られているように、windowオブジェクト上でマウスクリックイベントが発生したときに、anyfunction 関数を起動させる場合には、Mozilla系、Opera、safariなどでは、targetElement.addEventListener("click",anyfunction,false) メソッドにより、targetElement にクリックイベントをバインドする。

他方、常に W3C 勧告に逆らうことが使命と思い込んでいるとしか思えない MS 社の IE においては、attachEvent メソッドでほぼ同様の処理を行う（ targetElement.attachEvent("onclick",anyfunction) ）

ところで、W3C 勧告及び IE におけるこの面妖で「厳格な」手法より遥か以前から、次の２つの方法によってイベントのバインドが行われてきた。

その１つは、バインド対象要素オブジェクトの、イベントタイプ名のプロパティに、イベントハンドラー関数をメソッドとして登録することにってバインドさせる方法（「プロパティとしてのイベントハンドラー」）であり、もうひとつは、最も古くからある古典的手法─── HTML タグ内にその属性としてイベントタイプとハンドラー関数を登録する方法（「属性としてのイベントハンドラー」）である。

前者の、要素オブジェクトのプロパティとして設定する方法は、例えば「document.body.onclick＝anyfunction;」とscript文内で設定する。

一方後者のタグ要素の属性としてイベントハンドラー関数を設定する方法はこうなる。<p onclick="anyfunction(argument1,argument2,････)">。

そして後者の方法こそが、最も古く（※ この方法は Javascript 誕生時にイベントをバインドする方法として用意された手法である）からあり、故にまた一般的であって、最も頻繁に見かけるものであり、Javascript 初心者が見よう見まねで容易に利用できる方法でもある。

但し、DOM レベル2 で推奨された方法（ IEのattachEventメソッドによる登録も含む ）以外でイベントを登録する場合、１つの要素オブジェクトの同一タイプのイベントに対して、異なる複数のハンドラー関数を登録できない欠点がある。またバブリングや伝搬の制御も出来ない。

イベント発生要素と this キーワード

バインド対象の設定方法に次いで、第三にイベント発生要素と発生したイベントそのものをいかにしてJavascript に知らせるか、それが問題とならざるを得ない。何故ならばどんなイベントが何処で発生したのか、Javascript がそれを知ることによって初めて、Web サイトをより良く制御しうるからである。

まず、イベント発生要素は Mozilla 系とIEとで全く異なるプロパティによって「取得」される。Mozilla系は evt.targetであり、IEは evt.srcElement である（ここに evt は発生したイベントオブジェクト。eと略されることが多いが別に表記方法はどうでも良い）。

なお、これらのプロパティはHTML内にはまず登場せず、専ら script コード内に記述されるのに対して、this キーワードを利用すると、HTML タグ内にイベントハンドラーを記述して、Javascript にイベント発生要素を知らせることが出来る。具体的には this キーワードをイベントハンドラー関数の１つの引数として記述することにより、Javascriptにイベント発生要素を明示的に「通知」するのだ。

但し、明示的に通知されなくてもJavascriptインタープリタはイベント発生要素を this キーワードによって「認識」しているので、必ずしも明示的な伝達が不可欠な訳ではない。

さてお立ち会い！（苦笑）。(1) W3Cの面妖な「イベント監視」手法でもなく、(2) script文内でプロパティにメソッドを追記する方法でもなく、(3) 最も一般的に行われているところの、HTMLタグ要素内にイベントハンドラー関数を記述する方式を採用する場合、気をつけねばならないことがある。それはイベント発生そのものを Javascript に告知する必要があるということである。

一般的に使われている方法ではイベントハンドラー関数を呼び出す時に、その引数にイベントオブジェクトは入れない。引数はあるいは初期値であり、thisであり、既定値であり、あるいはない。イベントオブジェクトそのものは引数に記述しない場合が圧倒的である。

ところが、そうすると問題が生じる場合がある。すなわち、Javascript インタープリタは或るタグ内に記述されたイベント名とイベントハンドラー関数により、イベント発生時に当該関数を実行するものの、Mozilla系ブラウザでは発生したイベントそのものを取得できないのである。

Mozilla系ブラウザでは、(1)又は(2)の方法によってイベントをバインドさせた場合には、自動的・強制的にイベントハンドラー関数に、唯一の引数としてイベントオブジェクトを引き渡す。しかし、(3)の方法の場合には、HTMLからJavascriptへの自動的なイベント「通知」は行われないのだ。

そこで event キーワードの登場である。

event キーワード

ここで問題にしたいのは、呼び出された関数側ではなく、ハンドラー関数を呼び出す側の関数におけるイベントオブジェクトについてである。

ある解説書に拠れば、「W3C DOM イベントオブジェクトをハンドラ関数に渡すには、明示的に引数の１つとして event キーワードを記述しなければなりません。」（『JavaScript ＆ DHTML クックブック』p.243）

つまり、起動される側の関数において、いつでも受け取れるように function(e){･･･}と待機していても、呼び出す側で event キーワードを使用しないと呼び出した関数に当該イベントオブジェクトを渡せないようなのだ。

つまり、呼び出す側の、HTML文の属性に記述されたイベントハンドラーの引数に function(event) のようにevent キーワードを記述する必要があるのである。

正確に言えば、Mozilla 系ブラウザの場合、呼び出す側の関数の引数に、明示的に event キーワード（オブジェクトではない！）を記述しないと、呼び出された関数側に W3C 仕様の当該イベントオブジェクトが渡されない場合があるようなのだ。ここに、断言を避けたのは「渡されることもある」からであり、絶対に event キーワードを必要とするわけでもないからである。上述の引用でも「W3C DOM イベント」とわざわざ断っているように、イベントオブジェクトの様々なプロパティやメソッドを利用しないのであれば、event キーワードを記述しなくても動作するようなのである。

以上の記述については、以下を参考にすべし！

DOM:event - MDC