User forum-FC2BLOG-Info-Edit Template-Post-Edit-Upload-LogOut
HDDの崩御が間近いかも知れない、そんな状況下なので、当然デーバックアップが不可欠となる。
BartPEは作ったし、trueImage のブータブルディスクも作ったし、HD革命６によってC：ドライブ全体のイメージバックアップも取ってある。しかし、作成したデータのバックアップは今のPC購入後３年間ずっとさぼり続けてる。従ってHDDが崩御すればデータは損失してしまうかも知れない。この年末にそんな恐怖に襲われている。また同時に、職場のパソコンも危ない状況にある。
そこで、出来るだけ自動的にバックアップを取ろうと思い、いくつかのその種のアプリを検討した結果、Allway Sync（ダウンロード | Allway Sync 5.0.10 - フリーのファイル/フォルダ同期ソフト） が最適ではないかとの結論に至った。
このアプリは「パソコンの電源を切る時にバックアップ元と先を同期させられるだけでなく」（←これは大きな間違いであった。ログオフ時にはバックアップを取ってくれるが、電源オフ時にはそれは行ってくれない。しかもログオフ時にバックアップする指定を行っておいて、ログオフではなく電源を切るとAllway Syncの日本語設定さえキャンセルされてしまうようだ。1月下旬に追記）、TaskManage との連携も可能だから、様々な設定による自在なバックアップが可能と思われるからである。
もちろんTaskManagerとの連携は任意のソフトで図れるし、一定時間毎の自動バックアップ機能を備えるバックアップアプリは沢山ある。しかし、ログアウト時の自動バックアップ機能を有するものは他に知らない。細かくあれこれと設定せず、ログアウト時に一括して同期するのが最も簡単な設定であり、その設定のしやすさにおいて他を引き離しているだろう。
そこで、ここにAllway Syncの多機能ぶりを確認するために、以下にバックアップ機能を列挙しておく。まさしくAllwayの名に相応しい豊富な同期が図れることが分かるはずだ。
左記の設定を行うオプション画面
これを職場の「普通の人」がどれだけ使いこなせるのか、という問題があるが、ログアウト時に自動バックアップしてくれるというのは、素人的には使いやすいのではないだろうか？ 何も考えることなくフォルダの同期が自動実行されるのだから。但し、そのように対象フォルダを選択・設定することの手間をかけられるか、あるいはその手間の内容が理解されるか、そこに問題があるだろう。
メニューバーは日本語化されるが、随所に英語が残っているのも嫌悪される所以となりかねない。それでもこれにまさる自動バックアップソフトは知らない。
BartPE と True Image LE のマルチブータブルディスクの作成（ISOファイル）最終作業は結構手間取ってしまった。
１つにはヴァーチャルマシンの使い方を十分に分かっていないことから、１つは手持ちのWindowsXP ProSP1 CDからsp+メーカーを使って作成した、sp2適用済みオリジナル WindowsXP が、Bart's PE biulderのビルド作業を受け付けないため、結局sp1 CDからsp2適用を経由してビルドせざるを得なかったためである。
しかし、試行錯誤を経てやっとBartPEとTrueImageLEのマルチブートISOファイルが完成したので、ここではバーチャルマシン上における完成マルチブートディスクのテスト状況をまとめておこう。
なお一連の作業は全てPCJapan2007年１月号に基づいて行ったことを付言しておく。
BartPE と True Image LE のマルチブータブルディスクの動作チェックマルチブータブルCD起動画面 on バーチャルPC
BartPE起動 on バーチャルPC
右半分でSleipnirを起動させつつ、左上部でバーチャルマシンを起動してBartPEを起動してみた。
BartPE A32ファイルマネージャー起動 on バーチャルPC
右半分でSleipnirを起動させつつ、左上部でバーチャルマシンを起動してBartPEのファイルマネージャーA32をを起動してみた。
True Image起動 on バーチャルPC
直前のエントリイに書いたように、この年末年始の間にイメージバックアップソフトのブータブルCDを作ろうとしている。・・年賀状には全く着手してないけど（苦笑）。
３年前、自宅PCにWindowsXP Proを導入した時から、再インストールに費やす膨大な時間のロスを避けるために、いの一番に購入したソフトがイメージバックアップソフトであった。その後様々なWindowsXPチューニングを試みる中で、何度も繰り返しWindowsXPが立ち上がらなくなる事態に陥ったが、バックアップしてあるC:ドライブのイメージをリストアすることにより、通常のWindowsXP再インストールに費やすはずの膨大な時間、労力を省き、気力、気分の落ち込みを最小限に留めてきた。
それにも拘わらず何故今になって、改めてイメージバックアップソフトのブータブルCDを作ろうというのか？
それは、職場PCのハードディスクドライブが経年劣化しつつあり、近い将来に複数台のpcにおいてHDDの換装が予想される事態に陥ったからである。イメージバックアップソフトを組織で購入するだけの財力と知識があれば、個人が悩む必要はないが、残念ながら多くの組織において、イメージバックアップソフトそのものの存在すら知られていないのが、日本のIT化の現状だろう。
HDDの死亡、危篤などの事故が起こってからの事後の対症療法、つまり再インストールの愚は絶対に犯したくない。対象となるPCは１、２台ではないので、是が非でもイメージバックアップソフトによって、元気な状態のHDDをバックアップしておき、HDD換装に備える必要があるのだ。
そこに偶々PCJapan新年号で、True Imageの提供が行われた。この機会にこそ、ブータブルCDを作成しておき、全PCのイメージバックアップを励行させると共に、今後発症するであろう危機に対処したいのである。
さて、経過と置かれている事情などどうでも良いことであった（苦笑）。ここに進行中の一連の試みを跡づけておきたい。
行った、また行うことは以下の通りである。
当然、既に上記ソフトのインストールは完了しており、順次作業を進めている。その進捗に応じてエントリイを書き綴っていくことにする。
予備的試み(1)───Microsoft's バーチャルPC のインストールと利用
全くマニュアルレスであったが、インストール、起動、バーチャルマシンの作成と順調に流れた。そして早速LINUX 1CDディストリビューションの１つである Acceleratded Knoppix CDをバーチャルマシン上で走らせてみた。（これもまたPCJapanのDVDROMから入手したものである。）その状況を参考に画像として掲載しておこう。
予備的試み(2)───sp＋メーカーによるWindowsXP Pro SP2 CDの作成この作業は呆気にとられてしまうほど余りにたやすかった。これ程の容易さならばもっと早くやっておけば良かった、と、今更ながらに後悔した程たやすかった。
さて、このソフトは作業過程も簡単であるが、操作方法もまた容易い。まず、必要なソフトは次の２つだけだ。
次に、作業は次の２つのサイトを見れば直ぐに出来てしまう。
最後に、3年前に購入したWindowsXP Pro SP1 CDを取り出し、それをソースにしてsp+メーカーを適用し、出来上がったSP2適用済みISOファイルを、早速バーチャルＰＣでチェックした。WindowsXPのロゴがバーチャルPC上に展開し、インストール／回復インストールの選択画面が出たときには、狂喜乱舞したい思いであった！
残る作業はISOファイルをCDに焼くだけであり、これで万が一の再インストールに対する、原始的な１つの備えが出来たわけだ。
True Image LE のブータブルディスクの作成この作業自体は、True Image LE を起動し「ブータブルメディアの作成」をクリックするだけで出来てしまうから、改めて記すまでもない。しかし出来上がったブータブルメディアをエクスプローラで開いてみると、何と１つのファイルしかなく、それも僅か10kbのread.meファイルではないか。あれ？、果たしてこれで良いのか？、本当に true Image のブータブルメディアが作成できたのか？───それを検証する必要に迫られた。
もちろん、PCを再起動してCD起動を試してみれば良いことだが、PCの再起動をしなければ確かめられないブータブルCD作成作業というのも、余りに情けないではないか！
かくしてここでも Virtual PC に登場して貰い、その上でCDを起動してみた。その結果、reamd.meしかなかったはずのTrue Image Bootable CDから、見事にTrue Imageが起動したので、ここでもまた狂喜乱舞したい思いを抑えるのに苦労したのだった（苦笑）。
BartPE の作成Bart's PE Builder による起動可能 WindowsXP ＝ BartPE 作成は、PCJapan が数年前から繰り返し取り上げてきた話題であり、BartPE はWindowsXPが起動しない場合に実に重宝するツールである。
以前は、HotFixの適用に苦労した。必要な Windows Update データを一つずつダウンロードし、そのリストに抜けがないかどうかチェックし、手探りでビルドしていたものだ。しかし、最近のBart's PE biulderは実に簡単にビルド作業をしてくれるので、非常に助かる。
今回は、たいした苦労もなくBartPE＝起動可能なWindowsXPが作成出来た。またもちろんISOファイルも同時作成し、バーチャルPCで結果を検証したことは言うまでもない。
BartPE と True Image LE のマルチブータブルディスクの作成（ISOファイル）いよいよ最終作業である。
───次のエントリイに続く───
Microsoft Virtual PCは、一つのマシン上で仮想の複数台マシンをOSを選ばずに実現する素晴らしいソフトである。
大変便利なので、使いたくて仕方なかったのだが、登場当初は一ヶ月間だけの無料利用の後に有料となってしまったので、使う気をなくしていた。
しかし、2006/08/30から無料化された（Microsoft ダウンロード センター検索結果）ので、それ以来早く使ってみたいと思いながら、時間が取れずにいた。
他方、PCJapan2007年１月号においてAcronis True Image LE PCJapan Edition が特別付録として提供されたことから、ブータブルCDを作りたい、とずっと思っていた。
しかも、或るきっかけからHDD Healthを自宅pcにインストールしたのだが、導入直後から「近日中に壊れる」との警告が毎日出ているため、早急にブータブルCDを作る必要に迫られていた。
取り合えずC:ドライブのイメージバックアップはとったのだが、仮にHDDを換装するとなれば、ブータブルCDがないとC;のイメージリストアが面倒だ。6枚のxp起動FDから立ち上げるのはウンザリだから・・。
そして年末年始休暇が訪れた。
今この時こそ、と意気込んで昨晩から、悪戦苦闘してブータブルCDを作成しているのであるが、そこで何枚も失敗CDを作ってしまう愚を犯したくない、と思うのは自然だろう。
そこで、作成したisoファイルをバーチャルpcで試してみて、見事に動いたら最終的にCDに焼こうというわけである。
かくして２年余の時を経て、バーチャルPCを今こそ積極活用する機が到来したのである。
───つづく───
FC2ブログへのログイン機能が不安定だ。一週間ほど前までの一週間ほどの期間は、新しいエントリイの作成中でさえ、直ぐにログアウトされてしまうことがあった。かと思えば数日前から今日までは、ずっと何も作業しなくても、丸々一日以上ログインし状態が継続され、随時過去記事の編集や新記事投稿が出来る状態にある。
セキュリティ上は、編集作業をしていないときにもログイン状態が保持されることにより、他社による編集などを許してしまうのかもしれないから、好ましくないかも知れないが、使い勝手上aは、現在のようにログイン状態が継続してくれた方が楽でよい。
とはいえ、ログイン状態の継続性と短時間遮断の不安定さは、ブログサービスとしていかがなものか、と言わざるを得ない。
FC2ブログ登録ユーザー数が100万人を突破したのは数ヶ月前だったが、それ以降も飛躍的拡大を遂げているのだろうが、ユーザー登録数の拡大に目を奪われて、既存ユーザーをなおざりにだけはしないで欲しい。
昨日ハードディスク診断ソフトについて、急遽まとめた。それは職場でそれを必要としているからであった。そして試しに自宅のマシンにも入れてみた。
すると何と、早速「今年の12月31日に壊れる」（Nearest T.E.C）とのご神託が下された。インストール後数日にして、まるで「待ってました」とばかりに突如警告が発せられたのだから、驚いたことは言うまでもない。そしてまさか、と思い別の診断ソフトでチェックしたら、何てことはない健全そのものだというのだ。
使用した前者の診断ソフトは HDD Health であり、後者は HDD Life Pro である。前者は無料、後者は２週間後以降も使い続けようとすれば有料に切り替わる。
さて、本日職場で確認したところ、HDD HealthをインストールしておいたWebサーバーに、警告が表示されていることに気がついた。昨晩の今日のことだから、その警告が HDD Health から発せられたことは直ぐに理解した。その警告によれば来年の10月にぶっ壊れるのだそうだ。（Nearest T.E.C）
自宅のマシンは既に３年余が経過したが、職場のそれはまだ２年弱だ。
まるで「３年目の浮気」はバレル、と言わんばかりのタイミングの悪さ（良さか？）！
しかも本日帰宅してPCの電源を入れたところ、何やら雑音がするではないか。
耳を澄ませば、外付けの２台のハードディスクからではなく、そのゴロゴロと石を転がすような雑音は、PCケース本体の中から聞こえてくる。明らかにハードディスクが喘いでいるらしいのだ。昨日とは違う意味で吃驚して、早速チェックディスクを掛け、かつＣドライブのイメージバックアップを取る必要がある、と判断したのは当然の成り行きであった。
HDD Lifeの予測が正しければ異音はおかしい。一方、HDD Healthの診断が正しければ異音は理解できるが、では、全世界で75万人に活用されているというHDD Lifeの診断は当てにならないのか？ 果たして予言は正しいのか、はたまたそれは藪医者の誤診だったのか？───悩ましい日々が続いている。年末年始休暇を利用してハードディスクの換装をやってしまうのが最善の道ではあろうが、80GBものMyDatano待避のために更にHDDを買い足さねばならない・・・。
HDDメーカー各社のFDベースで利用するソフトはあるが、やはり常時WindowsXP環境下で診断を行って、事故に備えたいものである。
pantera soft社製の無償ソフトである。このソフトが最初に検索に引っかかり、無料に惹かれてインストールしたのだった。ところが本日「12月30日で壊れる」との警告を発した。余りのタイミングの悪さ（良さか？！）に、他の診断ソフトで改めて診断したところ、安全であることが分かり、HDD Health が藪医者であって欲しいと願わざるを得ない、切ない年末を過ごしているのである・・。
それでも無料は魅力であり、日本語化パッチ（[日本語化のRiKu's On-Line]－英語版ソフトの日本語化やフリーソフトの公開－）迄存在しているから、当面はこれを主軸に使っていこうと思う。
BinarySense社製品。窓の杜サイトにはフリーソフトとして掲載されている（窓の杜 -【NEWS】S.M.A.R.T.対応HDDの“健康度”をパーセント表示できる「HDDlife」が公開）。有名な製品なのかも知れない。しかし、実は14日間だけフリーの、その後有償（$22）になるFOR FREE版なるものをつかまされる。（ファイル名はHDDlife Pro 2.9.109.exe、と HDDlife 2.9.109.exeの２つあるが、どちらも無料体験・期限後有償版のようだ。BinarySense社サイトは詐欺的な情報掲載をしている！）
一方、PROTON 社サイトには、HDDLife JEなる製品が掲載されている（HDDlife JE - ハードディスク健康診断ツール）。しかし、おそらくこれは BinarySense 社からOEM供給されたものだろう。同じく14日間だけのフリー版である。
interCOM 社製品。14日間無償で体験版が利用できる。
同種の国内市販ソフトとしては初めて外付けハードディスクについての診断をサポート（※）した、とのこと。確かに他社の製品では外付けHDDは検証すらしてくれないので、大きな魅力と言えるだろう。（※ 2006年9月現在、株式会社アイ・オー・データ機器製の一部のUSB接続による外付け型ハードディスクについてのみ対応）
ワイ・イー。データ社が無償で提供する診断ソフト。ＦＡＴシステム専用で、独自OSでフロッピーベースで動作するようだ。電話回線経由で接続して復旧を行うらしく、余り実用的とは言えない過去の遺物かもしれない。───と思いきや、次のようなサイト【ハードディスク診断ソフト「Data Advisor」の使い方 - GIGAZINE（生々しい使用体験談が大変興味深かった）】に遭遇し、かなり使えるかも知れないと得心したのであった。
知人のWindowsXP Home Editionが起動しなくなり、何とかOSの再インストールをしないで修復・復活出来ないものかと、手を尽くして悪戦苦闘している。
事態は深刻で、回復コンソールを使って修復オプション付きでチェックディスクを掛けても、またＭＢＲを書き換えても、セーフモードでさえ立ち上がらない。つまり、OSのシステムファイルのいくつかが破損してしまったために、起動しないものと推測される。
修復インストールという手があるが、購入したパソコンは最初からＯＳが組み込まれており、添付していたリカバリーディスクでは修復インストールが出来ない。（EPSON Direct社に電話にて確認）。原因はハードディスクの部分的損傷と考えられ、衝撃を与えたこともないため経年劣化による「自然な」破損と考えられる。
そこでせめてデータだけでも救出できないものか、と初めてLinuxデストリビューションの１つである KNOPPIX を使ってみた。KNOPPIXは雑誌「PC JAPAN」が本格的に取り上げ、付録のCDまたはDVDによく掲載されているので、以前からその存在は知っていたが、本格的に利用するのは今回が初めてである。
さて、データをUSBフラッシュメモリに待避させたいわけであるが、そこで新たな問題が生じている。
KNOPPIXがUSBフラッシュメモリを認識しないのだ。自宅のマシンで試したところ、それは問題なくUSBフラッシュメモリを認識した。しかし、どういうわけか、当該の問題のマシンではそれが出来ない。USBフラッシュメモリから立ち上げられるKNOPPIX迄作り、それから問題のパソコンを起動し、それは成功したのだが、データ待避用として当該のUSBフラッシュメモリを使えないのである。
USBフラッシュメモリのマウントをコマンド入力によって試みたが、それも拒否された。
どうしたものかと、この年末に途方に暮れた一日であった。
追記
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メソッドによる登録も含む ）以外でイベントを登録する場合、１つの要素オブジェクトの同一タイプのイベントに対して、異なる複数のハンドラー関数を登録できない欠点がある。またバブリングや伝搬の制御も出来ない。
バインド対象の設定方法に次いで、第三にイベント発生要素と発生したイベントそのものをいかにして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 キーワードの登場である。
ここで問題にしたいのは、呼び出された関数側ではなく、ハンドラー関数を呼び出す側の関数におけるイベントオブジェクトについてである。
ある解説書に拠れば、「W3C DOM イベントオブジェクトをハンドラ関数に渡すには、明示的に引数の１つとして event キーワードを記述しなければなりません。」（『JavaScript ＆ DHTML クックブック』p.243）
つまり、起動される側の関数において、いつでも受け取れるように function(e){･･･}と待機していても、呼び出す側で event キーワードを使用しないと呼び出した関数に当該イベントオブジェクトを渡せないようなのだ。
つまり、呼び出す側の、HTML文の属性に記述されたイベントハンドラーの引数に function(event) のようにevent キーワードを記述する必要があるのである。
正確に言えば、Mozilla 系ブラウザの場合、呼び出す側の関数の引数に、明示的に event キーワード（オブジェクトではない！）を記述しないと、呼び出された関数側に W3C 仕様の当該イベントオブジェクトが渡されない場合があるようなのだ。ここに、断言を避けたのは「渡されることもある」からであり、絶対に event キーワードを必要とするわけでもないからである。上述の引用でも「W3C DOM イベント」とわざわざ断っているように、イベントオブジェクトの様々なプロパティやメソッドを利用しないのであれば、event キーワードを記述しなくても動作するようなのである。
以上の記述については、以下を参考にすべし！
cancelBubbleプロパティについて 、MSDN ライブラリ アーカイブ＞Web開発（全般）＞Scripting＞SDKドキュメント＞Internet SDK＞ダイナミックHTML＞ドキュメントオブジェクトモデル＞イベントモデルの理解 を踏まえて考えてみたい。自らの理解を深め正確にこのプロパティを認識して活用したいからである。なお、MSDNの「イベントモデルの理解」は、全てInternet Explorerに関する記述でしかないが、ここではMozilla系ブラウザでも動作するようにコンテンツを編集拡張した。（Operaやsafariには非対応・・だと思う。(・_・)(._.)）
さて、例１では当該コンテンツを囲むDIV要素及び文字shortを含む段落部分に、それぞれイベントハンドラーが設定されている。そして２つ共イベントのバブリングは抑止していない。
This is a very short document.
例１では、ユーザーが"見出し１"をクリックすると、"I was clicked h5"というメッセージが表示され、ユーザーが"short"という単語をクリックすると、２つのメッセージ（まず、"You clicked me SPAN"が表示され、OKボタンをクリックするとその後に、"I was clicked SPAN"）が表示される。(h5 や SPAN はクリックイベントが発生元のソースエレメントを示す)
最初の「見出し１」クリックでは、そのクリックによりonclickイベントが発生し、イベントのソース エレメントとしてh5エレメントを設定する。このエレメントに対するイベントハンドラはないので、イベントは階層の親エレメント（DIV）までバブルアップし、そのイベントハンドラであるwasClickedが呼び出される。
次に、ユーザーが"short"をクリックすると、onclickイベントが再び発生する。このとき、SPANエレメントがソース エレメントとして設定される。 SPANに対するイベントハンドラはないので、そのイベントはイベントハンドラーが設定されているＰエレメントまでバブルアップし、そのイベントハンドラ関数：wasAlsoClickedが呼び出される。wasAlsoClicked呼び出しが終わると、当該のonclickイベントは次の親エレメント（DIV）まで階層をバブルアップし、wasClickedが呼び出される。
なお、DIVエレメントより更に上層のエレメントから最上層のHTMLエレメントまでの要素には、onclickイベントは設定されていないので、このエントリイのDIVエレメントまででonclickイベントの遡上は終わる。
ここにタグ要素の階層構造は次のようになっている。
div ├─h4 ├─h5 └─p └─span
２つ目はイベントのバブリングを抑止した例である。
This is a very short document.
例２では、２つのイベントハンドラ─が、───SetDivStyleが例２の全体を包含するDIV要素に、また、setParaStyleが「This・・」のP要素に───それぞれ定義されている。ユーザーが「見出し２」をクリックすると、他のブロック要素内の「見出し１」も含めてh5タグ内の文字の色がライムに変わる。ここに、見出し２にはイベントハンドラーは設定されていないが、その親要素であるDIV要素にsetDivStyle()イベントハンドラーが設置してあり、これにより呼び出される関数において、h5タグの色を変えるようにしているので、このエントリイ内のh5タグ（見出し１と見出し２）内の文字の色が変化する。
一方、ユーザーが太字shortをクリックすると、イベントが直上のPタグに到達し、そこに設定されているsetParaStyleハンドラーにより、対応する関数が呼び出され、当該段落にアンダーラインが引かれる。
ここに、setParaStyleイベントハンドラ関数には cancelBubble＝true が設定されているので、当該イベントはこれ以上遡上しない。このためDIVに設定されているイベントハンドラー関数は作動しない。
（もし見出し１や見出し２をクリックした後にこのことを確認するには、イベント効果を取り消しボタンをクリックして、見出し１と見出し２の双方のクリック効果を取り消してから、shortをクリックすれば良い。）
Javascriptによるマウス位置取得マウス位置の取得については様々なサイトで語られている。だから屋上屋を重ねて述べることはない。
しかし、昨日触れたようにそれはそれなりに面倒である。特にIEの場合には様々な要因がマウス位置取得に関わるため、単純には行かない。
とはいえ、その煩雑さを理解してしまえば、マウス位置取得そのものは、どうってことはない単純なことだ。
Javascriptによるpopupコメントの位置取得マウス位置が取得できれば、あるマウスイベント（onclick、onmouseover、onmouseout、onmousemove、etc.）が発生した場合に、絶対配置要素であるポップアップコメントブロック（以下PopupBlock）を、そのイベント発生位置の右上に、あるいは右下に等々、お好みの位置に表示させるが出来るようになる。
Javascriptによるpopupコメントの表示位置修正さて、今回記録しておきたいことは、このPopupBlockの表示位置に関わる問題である。マウスイベント発生位置は当然、画面右や画面下に近い場合もある。その時Popup When Here is MouseCursorは（左の緑色で表示されている文字列にマウスカーソルを合わせると、テストコメントが表示される。）所定の右上や右下に表示したのでは、隠れてしまうから、画面の右にピタッと寄せて、あるいは下に寄せて表示させることが好ましい。
では、どのようにしてピタッと画面右や画面下にPopupBlockを表示させるか？ 自ずからそれが問われることになるが、今回このことにちょっと苦労してしまったのだ。
とっくの昔に解決したと思いこんでいたが、IE７正式版登場に伴うmyblogデザイン見直し作業の中で、改めてこれまでスクリプトが不完全であったことに気がつかされてしまったのだ。☆=>=>=>(+_＋。）
マウスイベントに係る位置を示すプロパティは沢山ある。x、pageX、layerX、clientX、screenX、pageXOffset、OffsetX、scrolLeft、clientLeft・・。これらのマウスポインタイベントプロパティとPopupBlockの横、縦の外枠サイズ、並びにスクリーンのinnerWidth とinnerHeight ───これらの３つの関係を関数として整理することによって、初めてPopupBlockを画面右や下に隠れないように設定することになる。
Amazonおまかせリンク（TM) ベータ版をmyblogに貼り付けた。Google AdSenceに次ぐ広告掲載第二弾である。
今回もまた、これで儲けようなどという意図は微塵もなく、やってみた、たったそれだけのことである。
それでも、関連する書籍を探したい需要は私自身に良くあることだから、決して無駄にはならないだろう、と慰めている。（苦笑）
それにしてもGoogle AdSenceと同一のボックスサイズを採用したのは、先行したGoogle AdSenceの影響の大きさを雄弁に物語っているといえるだろう。
「Javascript & DHTML クックブック」を何気に見ていたら、マウスイベントの位置取得に係わって、IEの場合にはボディに自動的に小さなパディングが入ってしまうこと、更に「CSS互換モードで動作してるIE６の場合には、HTML要素の小さなパディングも計算」に入れる必要があることが記されていた。
そもそもイベント位置取得がIEでは単純ではないこと、つまりbodyコンテンツのスクロール距離も考慮しなければならないことは知っていた。
また、そう言えば「bodyに小さなパディングが入ってしまう」こともどこかで読んだ記憶があった。だからこそmyblogにおいては、CSS文にてbodyのpadding値を四方ゼロに設定したのだった。
しかし、互換モードの場合にHTML要素に小さなパディングが入ってしまうことまでは全く知らなかった。
かくして、スクロール、body要素のパディング、互換モードにおけるHTML要素のパディングの３つを考慮して計算させないと、正確なイベント位置が取得できないことになるわけだ。
その結果IEにおける位置取得は更にスクリプトを変更して次のように改変した。
ここにおいて、body要素のpadding値はCSSにてゼロに設定してあるから、body要素の既定padding値への配慮を、イベント位置取得時のJavascript文で行う必要はない。それでも一般的なスクリプト文として敢えて書いておいた方が、後々のために良いと考えた。
blockとinlineについてちょっと語ってみたい。
2005年7月5日初稿、2006年12月14日改訂
それは良くあることだろう、と思う。
本来block要素でありながらinlineにしたり、その逆だったり・・・。段落要素内のAタグなどそのような例の最頻度の例だろう。
さて、LIブロック内でA要素をcssでblock要素にすると、IE６後方互換モードにおいては奇妙な現象が起こる。それはブロック要素内において二重にブロック要素を配置した場合のIE６後方互換モードの一般的法則なのかもしれないが、ブロック内ブロックはそれぞれにブロックであることを主張する！
それにより二つのブロックが形成されることになり、予期せぬ改行あるいは段落が挿入されてしまう！
発端イベント発生位置を取得するためには、ブラウザ毎にそれぞれの方法でこれを行わねばならない。
IEの場合には、今開かれている画面上のx,y位置とスクロールしたx,y長さとを加算したものが、Window左上隅からのx、yそれぞれの座標となる。そしてスクロールした距離はこれまでdocument.body.scrollLeftと、document.body.scrollTopしか知らなかった。
さて、IE７に切り替えこれまでHtml文、CSS文、そしてJavascript文と見直しを掛けてきた。
そこである奇異な現象に遭遇したのだ。スクロールしてからpopup表示させる場合に、思った位置にpopupしないのである。下にscrollしていればいるほどそのスクロールの距離に応じて、popupは正規の位置よりもますます上に展開されてしまうのである.
つまりスクロールの分だけ上にずれてしまうのだ。
これは明らかにIE７に移行してから初めて発生した事態であり、IE７に原因があるに違いない。───こう推測するのは致し方ないことだろう。
そこで原因を究明するべく、ネットサーフィンしてみたところ、いくつかのサイトを行ったり来たりしている内に、原因がやっと解明でき、myblogにおける問題の改善を行うことも出来たのである。
なお原因はIE7にあったわけではないことを断っておかねば失礼だろう。
document.documentElement.scrollTop何と、HTML文におけるDOCTYPE宣言の有無によって値が変わってしまうプロパティがあるとのこと。scrollTop がまさにそれに該当するため、DOCTYPE宣言をきちんと定義したmyblogの場合、これまでは有効であったscrollTopが無効（正確にはゼロ値）になってしまったのだ。
そのため適切な対応を講じなければならないことが判明し、その対応をこちらのサイト（ブラウザのスクロール量を取得するには？ | Diaspar Journal）を参考にして行った次第である。
document.body.scrollTop だけではなくdocument.documentElement.scrollTopなるプロパティも活用して対策することになったのだが、それにしてもCSSやJavascriptによるHomepageカスタマイズとは何と疲れる作業であろう！
改訂前後の比較はこのエントリイの継続部分に書いておく。
前回の(3)において、dynamis さんの JavaScriptによるブラウザの種類とバージョン判断 サイトでブラウザ判別のテクニックを十二分に学習したことを書いた。
今回は、どの様にIE7/IE6の判別をJavascript文において行ったのか、具体的にその内容を記しておく。今後の備忘録として残しておきたいからである。
関連する基本的な変数の定義まず、IE7/IE6の判別に係るGlobal変数を以下のように定義した。
IEかどうか、またIE７かどうかの２つの判別変数があれば、後はこれらを使って場合分けをするだけである。
IE６におけるボックスの罠と正常に描画するIE7の場合分けの例myblogでは、ある箇所の説明文を当該箇所のonmouseover時に、小さなpopup窓で表示するようにしている。この場合を例にとって、ボックスの罠対策を掲載しておく。
頁上の任意の位置のマウスカーソルに対して適切な位置に説明文を表示させるためには、表示するpopup窓がブラウザのスクリーンからはみ出さないように調整しなければならず、そのためにはpopup窓の外枠の幅と高さを取得しなければならない。
そして、ここでボックスの罠に直面し、故にIE7/6対策が必要となる。
以下にpopup窓に関するJavascript文からボックス対策部分を抜粋する。ここに「blnWidth」、「blnHeight」とは別途Javascriptによって取得したpopup窓のボックスサイズである。この値はよく知られているように、モダンブラウザとIE7においては左右または上下のパディング値とボーダー値を含まず、IE6の後方互換モードとIE5.5以下ではこれらを含んでいる。
また、blnOuterwidth と blnOuterheight は当該ボックスの左右又は上下のボーダー幅を含む外枠サイズである。
四字熟語が別にブームな訳ではないだろう。
しかし、「四字熟語カレンダー」まで製品として出回っているとは、驚きである。
毎日毎日、異なる四字熟語を眼にすることによって、果たして新鮮さが日々に付け足されるのだろうか？
なお、こうした製品があることを知ったのは、一昨日myblogに設置したGoogle AdSenceの情報による。AdSence設置が早くも自らに対して効果を発揮したと言える（苦笑）。
特にこれでお金を儲けようなどと思ったわけでは毛頭ない。
これを設置してアクセス数が増えると思い立ったわけでもない。
Google calenderを共有で利用し始めて、改めてGoogle社のサービスに惹かれている自分を再発見し、「ならばこの際」と思い立ったに過ぎない。
今やAdSenceはサイトの"常備品"として、かなり一般化しているから、それがmyblogにあっても何ら不思議ではないし（新鮮味もないけど）、関連情報としてどんな広告が"選択"されるのか、一興と言えないこともないだろう（苦笑）。
さて、組み込みに当たって、AdSence貼り付けHtmlはJavascript組み込みだけの本体であり、そのためにwidth値を自由に設定出来そうにもない（※未確認）。偶々myblogのwidthが750pxであり、これにぴったりのwidth値指定フォーマットがあったから、安易にそれを採用してみた。
解明すればおそらく任意のwidth値に設定することも可能なのだろうが、それも面倒だから既成品で間に合わせたわけである。
結果として財布が少しでも膨らむならば、それはそれとして歓迎すべきことではあるが、毎日100人ちょっとしかアクセスがない中では、財布が重たくなることもないだろう（アッハッハ）。
IE7対応のmyblog Javascript文の改訂内容を備忘録としてまとめておくことにする。今回の改訂作業の要はブラウザ判定にあり、その該当箇所の全てを改訂した。なお、HtmlとCSSについては、IE7/IE6以下対策を敢えてまとめる必要性はないと思う。
昨日書いたように、ボックスの罠対策を講じてある箇所の全てを見直す必要があり、各該当箇所についてIE７の場合とIE６以下の場合について、ブラウザ判定を行って分岐する必要がある。
そのため、まずブラウザ判定について学習しなければならない。
ここで非常に参考になったのは、 JavaScriptによるブラウザの種類とバージョン判断 である。
このサイトは「ブラウザ判定の全てが述べられている」と言っても過言ではない程に詳述されており、大変勉強になった。
このサイトがあったからこそ、実に容易にmyblogのjavascriptによるIE７とIE６以下の判別を行うことが出来たのである。
訳者の dynamis さんに感謝！
さて、次回にはIE7/IE6判別のための、具体的なJavascript文改訂内容を書くことにする。
経過IE７日本語正式版登場を受けた、myブログデザインの変更について、遅ればせながらも、既に次の方針を打ち出している。
anything from here IE7日本語正式版とCSS──MyBlogの改訂(1)
しかし、方針は打ち出したものの、さりながら・・。業務多忙、カスタマイズのための諸言語知識の忘却、面倒くささを前にした躊躇等々から、一向に方針の具体化に踏み出せないでいた。
そして、昨日。やっと仕事が一段落して、僅かながらも時間が出来たので、重い腰を上げて、ついに必要な改訂作業に踏み出し、そして作業を完了した。
改訂作業の具体的な内容
HTML文においてCSS文においてJavascript文において
90％近いシェアを握っているインターネットエクスプローラの描画エンジンを利用したタブbrowser。沢山のタブbrowserがあるが、多機能、カスタマイズフリー、スクリプト利用等で一日の長がある。Gekkoエンジンへの対応も行われ、IEからの自立独立の方向に向かっている。2005年7月にはIE7が登場する見通しの中で、今後の発展が望まれる。
多様なCSS作成支援機能を備えた、タグ入力式 HTML&CSS作成支援エディタ。スキンデザインもすっきりしている。テキストエディター上で作成するよりも確実で安全にタグ打ちが出来る。
文字コードを選べないのが欠点。
StyleNote同様のタグ入力式 HTML&CSS 作成支援エディタ。長年使用してきたが現在StyleNoteに乗り換えつつある。
クリップボード履歴情報を活用する為のソフト。画像まで履歴を取ってくれるのが嬉しい。このソフトを使わない日は絶対ない程に重宝し、愛用している。
起動中のウィンドウの「コピーできない」説明文などの文字列を取得し、コピー可能な文字データにするツール。何かと便利。
ストリーミングデータを保存することが出来るソフト。動画利用には不可欠なソフトだ。
無料ながらレイヤー機能を有し、スクリプトによる拡張も可能な、sleipnir作者が提供している優れもの画像編集ソフト。
画面キャプチャソフトと言えばこれに勝るものなし、ではないだろうか？ 様々な取得方法を有しており、ブログ作成にもHomepage作成に不可欠だ。Jtrimと並んでWoodyBellsの作品。
複数ファイルの同時編集は出来ないが、透過pngも作れる画像編集ソフト。
（以下当該サイトから抜粋）初心者にも簡単に操作が出来るフォトレタッチソフトです。多くの加工機能で画像に様々な効果を与えることができます。非常に軽快に動作するため、ストレスなく操作できます。
Animation Gifファイルを作れる無料ソフト。
キャプチャソフト。画面内にサイト全体が表示しきれない場合でも、これを使えば全体をキャプチャすることが出来る。
画像処理。画像のフォーマット変換のみならず、色数やサイズ、圧縮率の変更まで一括処理できてしまう『BatchGOO!』は、大量の画像をまとめて処理したいときに大変便利なソフト。BMP, TIFF, JPEG, PCX, PNG の相互変換をはじめ、色数・サイズ・解像度の統一、JPEG圧縮率の調節など、ホームページ用の画像や携帯電話用の壁紙を揃えるのに抜群の相性を見せる。（Vectorの当該ソフト紹介頁より抜粋引用）
名前から直ぐに想像が付くように画像のサイズを測るためのソフトだ。Homepage作成には欠かせない。2カラム、3カラムのレイアウトを行う場合に大変重宝する。
ランチャーソフトは沢山あるが、中でもこれが一押しだ。２年以上使ってきたがその操作性には毎日満足している。これを使い始めてからデスクトップには一切のアイコンを表示することをやめてしまった。
AdobeReader7によって、起動時間が長すぎるという長年のユーザーの不満はある程度解消した。そのためこの高速化ソフトは存在価値が低下してしまったかもしれない。AdobeReader6迄はこのソフトによる起動高速化で恩恵を受けてきた。
IE専用が難点だが、様々なサイト内でIDやパスワードを入力するのに重宝するソフト。コンテキストメニューから簡単に起動できるのがGood！ sleipnir等のIEの描画エンジンを利用しているブラウザでも使える。
利用しているパソコンの諸元値を取得するには、このソフトがベストだ。インストール済みソフトの一覧が取得できるのも嬉しい。
WMPは機能が豊富なだけ重い。RealPlayerも同様だ。そこでMedia Player Classicを使いたい。動作が軽快なだけではなく、対応しているファイル形式もすこぶる多く、これひとつで、wmvもrmも表示できてしまうのだから凄い！ 数多あるMedia Playerの王様と言えるだろう。
自宅でPCを起動しているときには必ず起動しているメディアプレーヤー。何かと過剰なWinampよりも、起動も速くスキンはシンプルだ。
DivX, Xvid, Mov, Vob, Mpeg, Mpeg4, avi, wmv, dv, などの動画をDVD-Video形式に変換できるフリーソフト。クリックするとDVD関連ソフト紹介サイト＝「DVDなToolたち」なるHomepageが開きます。
