複数の画面があるが、イベントは１つの関数（メソッド）に全部来る場合の制御(BREWを例に）

　たぶん、何回か続くと思うけど、ＢＲＥＷなどで知られてないことなどなどを、書こうとおもいます。
　今回は、ＢＲＥＷに限らないけど、画面制御などで、複数画面あったとしても、イベントはすべてひとつのメソッドや関数にきてしまう場合、どーしたらいいかという方法。

　ＢＲＥＷの黄色と赤の本、BREWプログラミング実践バイブル　ＩＳＢＮ 4-8443-1947-7では、Ｐ９０の「ＢＲＥＷダイアログの悲しい現実」で、いろいろ問題点をあげているのはいいんだけど、その解決策が
・ダイアログを使わない（これはいい、ウィリアムのいたずらもそうしてる）
・退屈なコードをならべる（これは、ウィリアムのいたずらは、これ以外の方法で逃げている）
・IHtmlViewerを使う
　という３つしか、あげていない。とくに、最後のIHtmlViewerは、マニュアルに書いてあるだけでは、たいした操作ができない。

　それについて、２ちゃんねるとかで、確か質問が出ていたり、このアメリカ人が、「はあ？」ということを書いていたりするんだが（Are there any other properties that I am missing???って、おまえ、そこで、そーさする気だったんかい、input modeを（＾＾；）、さらにコメントのinlineフラグの設定、おまえ、本当にそれ試して、そのコメントかいてるんかい！っていう、お間抜けさ２５０％のブログが、へーきでかかれたりする。。相手が日本語読めないと思って、言いたいことかいてます）、まあ、それについては、後日、覚えていたら、ちゃんとした、操作ができる方法を書く。

　しかし、しかしだ。IHTMLVIEWERでちゃんとした操作をするにしても、IHTMLVIEWERを使わないにしても、まず、複数画面があるとき（複数のＨＴＭＬを使って画面を切り替えるとき）、１つの関数にみんなはいってきてしまうのを、どーするかを書かないと、話すすまないんで、そっから今日は片付けます。

---

　ＢＲＥＷを知らない人へ。
　画面のイベントは、すべて、アプリ名_HandleEvent()という関数にきます。
　なので、１つのアプリで、複数の画面を使う場合、どうしたらいいかという問題が出ます。

　これは、かんたんです。

１．画面に番号をふりましょう。

２．画面ごとに
　　画面名_InitAppData()
　　画面名_HandleEvent()
　　画面名_FreeAppData()
　という関数をつくり、そこに、その画面にたいして「だけ」の、起動時、イベント処理、最後のフリー処理をかきます。
　ここで、上記の関数の引数に、アプリの構造体(pMe)を、必ずわたし、
　pMeに　int gamen_bango; という、
　現在表示している画面番号を入れるもんをメンバーに追加してください。

３．そして、画面名_InitAppData()で、gamen_bangoに自分の画面番号を、セットするようにしてください。

４．アプリの起動時にはしる、アプリ名_InitAppDataでは、まず初めに起動する画面の画面名_InitAppData()を呼び出します。

５．アプリ名_HandleEvent()では、すべての画面のイベントがきますので、
　ここで、VC++が、ウィザードで作成したソースを、すかっと削除し（その内容は、各画面の画面名_HandleEvent()に書かれる）
　switch(画面番号）
{
case 1: // １番の画面のHandleEvent()よびだし
return 画面１_HandleEvent();
case 2: // 2番の画面のHandleEvent()よびだし
return 画面2_HandleEvent();
case 3: // 3番の画面のHandleEvent()よびだし
return 画面3_HandleEvent();
　　　：
　　　：
（最後の画面までこれをかく）
}
return FALSE;
}

みたいなかんじで、ここでは、各画面のHandleEventをよびだすだけにする。
そうすると、あとは、各画面で、自分のHandleEventを処理すればいい。

６．画面を切り替えるときは、
　今表示している画面の_FreeAppData()を呼び出し、フリーをしたあとで、
　次に表示する画面の_InitAppData()を呼び出し、次の画面処理をします（この中で、３により、画面番号が書き換わり、イベントがきたときに、どの画面が表示されているか分かる）

７．アプリを終わらせたいときは、ISHELL_CloseApplet(pMe->pIShell,FALSE);を呼び出す。

８．画面間のデータわたしとか、画面内で使うデータは、pMeの中に書く。
　だけど、その道方について説明すると長くなるので、今度、気が向いたときに、どっか（このブログか、ウィリアムのいたずらのＢＲＥＷホームページ）に、書くかもしれない。

---

こんなかんじかなあ。。
ウィリアムのいたずらの場合、画面だけでなく、項目についても、これをやっていて、カーソルを、どこにでも飛ばせるようにしている。

　で、問題は、IHTMLVIEWERだよね。それは、覚えていて、時間が合ったらかくよ。

　こんなかんじ
１．IHTMLVIEWER内の項目のカーソルとフォーカスの制御
２．入力規制
１が、２ちゃんの答え、２がアメリカ人への答え（ごめん、英語なんで、アメリカ人と思っているだけで、違う国の人かも（＾＾；））

ケータイで使うＨＴＭＬのありか

　ケータイで使うＨＴＭＬは、普通のＨＴＭＬと、ちょっと違う（たとえば、inputのtext項目で、istyleやmodeを使って、字種の入力規制ができる）。そこで、そのマニュアルが必要になったりする（のは、ウィリアムのいたずらだけか？）
　ということで、それのありかのメモ。


■■　ボーダフォンのＸＨＴＭＬ，ＨＴＭＬ
ボーダフォンの技術資料
http://developers.vodafone.jp/dp/tool_dl/web/tech.php
からダウンロードできる。

■■　Ｄｏｃｏｍｏ
　Docomoの技術資料のうち
　iモード対応HTMLは、ここ　http://www.nttdocomo.co.jp/p_s/imode/make/tag/index.html
　iモード対応XHTMLは、ここ　http://www.nttdocomo.co.jp/p_s/imode/make/xhtml/index.html

■■　ＫＤＤＩ
　ＫＤＤＩは、そもそもＨＴＭＬでなく、ＨＤＭＬ
　HDMLは、ここ　http://www.au.kddi.com/ezfactory/hdml.html
　auで動く XHTMLはここ　http://www.au.kddi.com/ezfactory/xhtml.html
　

---

あれ、これ、昔このブログに、書いたっけ？？
でも、新しく「リンク集」っていうカテゴリつくって、調べやすくしたので、二重に書いても、ま、いっか（＾＾）

場の空気を読んで、コンテンツを紹介する技術があるらしい。ならそれをトラバに応用すると？

　ＫＤＤＩ研究所と、産業技術総合研究所の共同研究で、ユーザ個人の特徴情報と気分や場所などの状況情報を総合的に考慮する（つまり、場の空気を読むってこと？）新たなコンテンツ推薦方式を開発したそうな
ここ（ＰＤＦ）に詳しく書いてある（上記の斜体は、そこからの引用）

　図をみると、状況やプロフィール、コンテンツ状況から感じ方を判断し、そこから評価し、コンテンツが好まれるかどうかを評価するらしい。

　じゃあ、これを応用して、自分の書いたブログや自分のプロフィールなどから、トラックバック依頼が来たブログの内容の感じ方を判断し・評価し、好まれる場合のみ、トラックバックするとか言うのもできるのかなあ。。

　いや、こういうのをやるとしたら、２つのブログの関係が近いかどうかを、キーワードの類似性などをみてやるのかなあ。。って、これを見る前は思ってたんだけど。。
　で、つーと、ＮＡＩＳＴか、東工大あたりの自然言語畑の人？？なーんつうふうーにかんがえておったが。。

　そーだよねー、ブログもコンテンツだもんねー、コンテンツを管理・販売している人たちが、ブログの管理（トラックバックの管理）とかに乗り出しても不思議はないよね。。

　って、これってべつに、トラックバックしていいかどうか決める技術じゃないだろって（＾＾；）
　つーか、そもそも、これをトラックバックしていいかどうかにつかったりしたら、サーバー負荷が大きすぎるだろーから、やっぱ無理か（＾＾）