HTABOXコア Part3

HTMLアプリケーションの実行環境として、また、HTMLによるGUIと
他言語との融合アプリケーション環境としてHTABOXコアの開発を
行っています。このスレッドはHTABOXコアへのご意見、ご要望を
気軽に書き込むために存在します。現在3.00のリリースに向けて
作業を行っています。

現行バージョンサイト
ttp://kuroda.bglb.jp/htabox/

現在3.00の基本機能を確認するためのデモを公開しています。
ttp://kuroda.bglb.jp/htabox/htabox300.zip
ネイティブモジュールにより、メニュー、ツールバー、コンテキストメニュー
ステータスバーを生成し、いづれもHTML中のタグ、スクリプトで簡単に制御
可能です。DHTML手法によるGUIとは一味違うレスポンスを体験できます。

死




ね





ボ




け

う

あらー

マウスオーバー属性が取得できていないのでしょうか？
マウスオーバーしたときにステータスバーの表示が元に戻らないのですが…

ポ



ッ


ポ

ー



ー

ン

>>6
当方の環境では体験したことの無い状態のようです。「表示が戻らない」を
もうすこし詳しく教えていただけると助かります。ツールチップが表示され
たままなのか、ボタンが押されたままなのかとかです。

尚、ツールバーはHTMLオブジェクトではありません、本物のWIN32ツールバー
ですから、そこにあるマウスはHTMLのコントロール下にはありません。

ル



パ



ニ



ー



ト

昨日から今日にかけて<OBJECT/>とは何か？再検証することになりました。
例えば、createElementでもOBJECTは指定できますし、実際に追加できます。
これと、パース初期からCLSIDで生成されたOBJECTはまったく別物であると
いうのがポイントなんだと感じました。

動作しているHTML中には多くのCOMインスタンスが存在しますが、それは２つ
に大別できます。ひとつはIUnknown系でもうひとつはIDispatch系です。
前者はHTMLをホストする側のメンバーとみなされCOM的な機能の拘束がありま
せん。例えばデータバインドはOLEDB系インターフェースが有効な環境でなけれ
ば機能しません。このDLLにprogidを与え、ActiveXObjectでインスタンス化
しても本来の動作ができないのはこれが原因です。

今回、レジストリフリーな<OBJECT/>にこだわりを持ったのは、インターフェ
ースを提供できる言語なら、面倒なCOM登録動作無しに、HTMLをホストする側
のコードが書けるようにするためです。どんな言語での拡張も、後者のディス
パッチ系とみなされた場合、提供モジュール内の動作は高速かも知れませんが、
肝心のHTMLインスタンスとの通信はすべてディスパッチ経由となり基本的に通
常のスクリプトと大差ないものとなる可能性が高いのです。

HTABOXがただの手慰みではなく、実際に効果を発揮するツールになるためには
ビヘイビアやActiveXコンポーネントに必要な中間手続きを一切引き受けて、
その先に集中できる環境を用意することだと考えています。そのために欠かせ
ない用件をクリアしたと考えています。
<OBJECT ID="HOGE" CLASSID="clsid:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
<PARAM NAME="ref" VALUE="hoge.dll">
</OBJECT>
でまったく任意なDLLをIUnknownベースとして機能させることができます。

ジ




ャ



ポ



ニ



ー



ル

GUIDの偽装で、実現できれば最もエレガントだと考えていた、OBJECTタグの
自己増殖はちょっと無理があるようです。実際にHTML書かれている宣言で生
成されたインスタンスと例えホストコンテキストとはいえ動的に生成された
インスタンスでは細部の動きに違いが見られました。GUIDの偽装そのものは
まったく安定していますので、現時点で考えうる最善の方法は、先頭の偽装
で以降の転送先DLL、呼び出し関数をPARAMとして全てセットし、ここでは何
も生成せず、2つ目以降のOBJECT宣言からインスタンス化を実行することです。

パ



ロ


パ



ニ

ア

<OBJECT CLASSID="clsid:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
<PARAM NAME="001.dll" VALUE="func1"/>
<PARAM NAME="002.dll" VALUE="func2"/>
<PARAM NAME="003.dll" VALUE="func3"/>
</OBJECT>
<OBJECT ID="HOGE001" CLASSID="clsid:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"/>
<OBJECT ID="HOGE002" CLASSID="clsid:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"/>
<OBJECT ID="HOGE003" CLASSID="clsid:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"/>

という書き方にすればいかなる条件下でも実際にレジストリ登録されている
ものと同一な動作になるだろうと推定します。

パ



ニ


モ



ニ


ル



ア

いままでAPIフックというと非COMな世界の手法みたいな観念があったのです
が、MSHTMLのように数メガのDLLを抱きかかえていようが、特定のAPI呼び出
しを一括して監視し、結果を摩り替えることができるというのは、非常に大
きな武器になりました。何をインスタンス化しようとしているのかが事前に
判れば、先回りして同型インターフェースに本物を包んで渡し、動作をつぶ
さに観察できるわけです。

17に書いた手法での安定動作にこぎつけましたが、<PARAM のNAMEが同一な場
合は許されないという基本的な事に気づいていませんでしたので、<OBJECT>
内はコメント中に転送先DLLと関数を指定する仕様になる予定です。

<object classid="clsid:71650000-E8A8-11D2-9652-00C04FC30871" VIEWASTEXT ID="Object1">
<!--
[hoge.dll#CssFactory]
[hoge.dll#CDataBind]
-->
</object>

ノ


エ


ヒ


ソ



ー




ル

改めて考えてみると、このOBJECTタグが生成される時のロードDLL置き換えは
原理的にはあらゆるブラウザ対してに有効です。こうされることを想定して
対策されたDLLロードの方法をとれば別ですが、普通そんな面倒くさいことは
書かないでしょう。これは余りにも飛躍しすぎる機能拡張ですので、当面先送
りされますが、原理的にはあらゆるブラウザをHTMLアプリケーションのベース
として借りることができます。もしかして、「うちのPCにはIEないんだよね」
という状況が生まれても、WindowsOS上であれば動作可能なアプリケーション
になるわけです。

バ



ニ




バ




ニ



ア

OBJECTタグ系でエラーが発生すると、コンテキストが低水準ですから、HTML
やスクリプトのエラーとは違い手がかり無く全体がストールすることになり
ます。情報収集はほぼ完了しましたので、しばらくの間はHTABOXのヘルプ等
内部で使用して厳しい条件にも耐えうるかを試験しますので、一般に公開す
る機能として、このレジストリフリーなOBJECT宣言を提供するのはまだ先の
ことになります。

今回決定したかったのはデバッグ用外部JS、VBSの実行エンジンをビヘイビア
階層とすべきかオブジェクト階層とすべきかでしたが、当初のままビヘイビア
で行きます。

フ


ェ

フ


ェ


フ


ェ


フ


ェ

HTABOXのバイナリファイルはHTABOXAPP.exeとHTABOXOBJ.dllにまとめられる
予定です。従来の動的マニフェスト管理は残します。また、以前話題になっ
た、強行実行時のインターネットアクセスについては、今回検証したのAPI
フックによる要求時DLL置き換えで無害なものに置き換え抑制することが可能
だと考えられます。

ホ




ホ



ル



イ




ア

DLL偽装は低水準な拡張方法として大変魅力的ですが「深入りするとやばい」
というのが正直な感想です。「これが可能です」と一つ機能を提供するだけ
では事態を収拾できなくなる可能性があります。広範囲な機能をHTABOXとい
う一つの看板に盛り込むよりも、べつなアプローチのライブラリとして提供
した方が受け入れられやすいのかもしれいと思います。

久しぶりに自分が誰なのか忘れるほど寝ていました。何かを実現できない焦
燥感だけで生きているものですから、何かにめどがつくと、その分だけ私を
起こそうとする内分泌系が低下するのかも知れません。

ビヘイビアの導入がそうであったように、低層でいかに面倒な事が起こって
いようが、ユーザー側にはそれを意識させないという事が実現できなければ
ソフトウェアとして意味がないわけですから、HTMLやスクリプトに軸足を置
いたコンセプトとして、プラスアルファで何でもありにすべきですね。

MSHTML中におけるIUnknown系とIDispatch系の違いで、もう一つ付け加えるな
ら、IDispatch系はHTMLインスタンスのエラートラップが有効な状態で活性化
しているという表現ができると思います。したがって、総てがストールするよ
うな状態にはならず、エラーダイアログが表示されるわけです。これは速度的
には不利な状況ですが、なぜHTMLアプリケーションが作成しやすいのかという
根幹に関わる特性ですから、やたらと低水準を目指してそこを踏み外しては本
末転倒になります。

ただし、「どうせHTMLなんだろ」と言う部類の方々に対しては、MSHTMLイン
スタンス生成前にホスト側として介入する手法、レジストリフリーなOBJECT
としてHTML生成初期に介入する手法を提供すれば、納得していただけるんじ
ゃないかと思います。

OBJECTを生成してMSHTML側のQueryInterfaceを待つとIActiveScriptを問い合
わせる動作もしますので、ここでインターフェースを返すと、独自スクリプト
エンジンをHTML側のスクリプトサイトと共有する状態で追加することができま
す。ここで単にJScriptをパースした結果を渡してもメリットは望めませんが、
VBScriptエンジンを初期化し、JScriptパース結果をVBの空間へ転送した後に
HTML側へ公開できれば、かなりの高速化と堅牢なソース隠蔽が実現できるので
はないかと考えています。

上記転送は動的な要素の追加や削除が行われなければ机上では何ら問題ない
事になります。もし動的な変更が必要なオブジェクトがあれば、それだけ直
接HTMLへすればいいですし、逆にアンダーバーで開始する単純関数だけを非
公開な高速動作関数としてVB化するという選択肢もあると思います。勿論開
発時は単なるJScriptとしてブレイクできなければなりませんが。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デュアルスクリプトエンジンデモを追加しました。

ソースのtest.htm中にスクリプトエンジン用OBJECTタグがあります。
<object classid="clsid:844F4806-E8A8-11D2-9652-00C04FC30871" VIEWASTEXT ID="Object2">
<!--
function test2(str)
{
alert("This is JScripe:" + str);
return("Return:" + str);
}
//-->
</object>
ここに記述されたfunctionは最終的にVBの関数に置き換えられます。したがって
原理的にtoString()等でのソース表示から保護されます。今回のデモでは実行速度
を向上させるまでには至っていませんが、関数名と引数の変化に対応してVB関数が
生成されますので、関数を増やしたり書き換えても動作するはずです。

ちなみにtest.htm中に出現するCLSIDは本来system32\webvw.dll用のGUIDです
{71650000-E8A8-11D2-9652-00C04FC30871}:WEBVWLib.ThumbCtl
{BCFD624E-705A-11D2-A2AF-00C04FC30871}:WEBVWLib.WebView
{844F4806-E8A8-11D2-9652-00C04FC30871}:WEBVWLib.WebViewFolderIcon
HTABOXは自身プロセス、又はフック先プロセス中の当該DLL要求を任意なもの
に置き換える能力がありますので、HTABOXOBJ.dllへの転送を実施しています。
HTABOXOBJ.dllは当然レジストリにも、マニフェストにも存在しない訳ですが
ごく自然に動作するはずです。

今回のデモで「デュアルスクリプトコード表示」を行えば必ずエラーが発生
しますが、それをデバッグするとJScriptのコードまでデバッガは追跡するは
ずです。HTMLが提供するサイトを使っているから、このようにデバッグが可能
となると推定されます。もしこの状態でデバッガの追跡が好ましくないなら
スクリプトサイトを自分で構築する。それでも追跡されるならコンテキストを
変える。という流れになるはずです。

JScriptの擬似クラスとして記述されたfunctionも機械的にVBScriptのClass
へ置き換えられると思います。しかもコンストラクタとデストラクタを定義
できます。ただし、コンストラクタとデストラクタに引数は許されません。
まぁこれはオブジェクト指向的には当然な事で、引数のある初期化が必要な
時は初期化関数を用意して、その返却値で生成の是非を確認すべきです。

36は自分で書いておいて変な文章ですね。改めてVBSでClassを書いて実験し
ましたが、やはりコンストラクタへの引数は受け付けないようです。コンス
トラクタ引数がないことがオブジェクト指向的には当然なわけは無くて、
当たり前に引数付きでコンストラクトしますよね。ただ、コンストラクタは
できるだけ軽量な設計として、何らかの初期化動作が必要な場合は、初期化
関数を用意すべき。と言うのが正しい言い方です。お詫びして訂正します。

関数の置き換えは単純なんですけど、メンバ変数の置き換えが大変そうです。
VBSのクラスではPROPERTYGET、PROPERTYPUT、PROPERTYPUTREF用のメソッド
を明示しなければならないようです。もし、まだnewされていない擬似クラス
をVBS側へClass定義だと思わせれば、なんの苦も無いのですが、さすがにそ
れは通らない要求のようです。まだnewされていないfunctionのメンバーは
当然ディスパッチ的には列挙できません。従来のJS->JS転送ではその問題を
インターフェースのラッピングで乗り越えるのですが、JS->VBでもそれが必
要となると、なんらメリットを見出せないことになります。ちょっと休んで
考えてみます。

VBS中継の決定的なメリットは見出せませんから、今回は撤退します。既存の
テクニックであるJS->JS中継を行いながら、アタッチしてのデバッグ、長大
なソースコードを想定した別スレッドパース等を検証して外部スクリプト仕
様を決定したいと思います。

JS->JS転送時にスクリプトサイトを切り替えればデバッガの追跡は及ばない
ようです。つまり開発モードではHTMLが提供するサイトを使用し、リリース
時(隠蔽が必要なら)従来の独自サイトで動作させます。独自サイトも全くエ
ラーに無関心では困りますので、エラー行とエラーの原因だけは表示させて
います。リリース後にユーザーからバグ情報があっても迅速に対応できると
思います。

別スレッドでのパースは、あまりにコンテキストが違いすぎるので成功しま
せんでした。このままでは数百kみたいなソースが来たときにもたつきますの
で、非表示ウインドウ生成によるPost動作で克服できそうです。今回のように
動作をブロックしたくないが、別スレッドでは実現できない局面は結構頻繁に
訪れます。そんな時このPostトリガー用ウインドウは有効な解決策だと思いま
す。これはあくまでも推測ですが、Internet Explorer_Hiddenもそういった
必要から生成されるウインドウではないでしょうか。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。従来型JSエンジンによるコード隠蔽デモを追加しました。
test.htm中の下記コードは独自スクリプトエンジンのOBJECT宣言ですが、パラメ
で通常と隠蔽を制御できます。
<object classid="clsid:844F4806-E8A8-11D2-9652-00C04FC30871" VIEWASTEXT ID="Object2">
<param name="hide" value="no"/>
<!--
function test()
{
alert("This is JScripe:");
return("Return:");
}
//-->
</object>
value="no"で通常、value="yes"で隠蔽です。当該位置でわざとエラーを発生さ
せた場合の挙動も当然異なります。私もこの実験ではまってしまうのですが、
<OBJECT>の中身はinnerHTMLとしてしか取得できません。つまり長い一行を解釈
されますので、JScriptコードを書き換える際は注意してください。\nを文字で
表現すればその問題は回避できると思います。あくまでもこれは実験で、実際
に<OBJECT>の中にスクリプトコードを要求するような使い方を予定しているわ
けではありませんのでご了承ください。

この隠蔽手法では、擬似クラスとしてfunctionが存在し、それが幾重にもネス
トしていたとしても、functionを認識してソース要求を拒否することです。
また、この機構を完全なものとするためにfunctionへの動的な要素の追加
PUT|PUTREFは無視されます。本体の関数機能要求のMETHOD呼び出しにしか応答
しないと言ったほうが早いかもしれません。ただ、軽量化のためにJS->JSで
はなく単独JSを試していますので、まだ十分な防御力があるとは言い切れませ
ん。

隠すということは「暴く」側に立って考えなければなりません。例えばEXE中
に"function"という文字があればそれを強制置き換えすることで隠蔽が破綻す
ることを狙うでしょう。現時点のバイナリでそこまでの配慮は行っていません
から試してみてください。リリースする段階ではそういったクリティカルな
静的文字列は総て暗号化され実行時の必要な瞬間だけメモリ中に生成されるこ
とになります。

（＾ｑ＾）
(＾ｑ＾)

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。隠蔽時に使用するサイトが表示するエラーダイアログに、
エラー発生位置コードが文字化けするバグがありましたので修正しました。

現時点で3種類のスクリプト記述方法があります。最も基本となるのはHTML中
のスクリプトタグです。単体ファイルとして取り扱いも楽ですし、コード全体
が大規模でない場合、外部スクリプトを使う必要は無いでしょう。

2つ目は非表示なスクリプトパース専用HTMLを併用する方法です。デモではjs
ファイルとしましたが、結局HTML実行しますので、スクリプトタグに各種言
語を記述できるものとします。この非表示HTMLのパースは本体のパースを阻
害しません。本体スレッドはこの補助HTMLへモニカをセットして即座にリタ
ーンし、本体HTMLの構築を続行します。

通常はこの2種類で十分だと思います。それぞれで.NETパース、隠蔽機構は
有効とする予定です。

3つめの手法は今回取り組んだOBJECTタグの利用ですが、これは本来バイナリ
DLL等を直接埋め込むための手法と捕らえています。今回の実験ではDLLを作る
のが面倒なので、スクリプトをパースしたディスパッチを模擬DLLとして情報
収集しましたが、スクリプトの利用では、機能と速度において顕著なメリット
が見られません。またOBJECTタグは記述にミスがあると全体がすっ飛ぶにも
関わらずなんのエラーも表示されないわけですから、高度な利用法として一線
を隔した扱いにする予定です。

勉強不足で時間ばかりかかってしまいましたが、既成HTMLコンポーネントの
ホストサイト入れ替えによるビヘイビア拡張、APIフックによるロードDLL偽
装の2つを解決した事で動作コンテキストを完全に統一することができました。
別コンテキストから何かを待って横槍を入れる必要がまったく無くなったこ
とにより、見てのとおりスムーズな動作が実現できました。

取り説を書いては消しがいやなので書き直す必要が無い土台を作る為の技術
の方へつい向かってしまいましたが、今はこの軽快さを一人でも多くの方に
見ていただきたい気持ちでいっぱいです。

若い頃はオートバイをいじるのが好きで、全部分解してまた組み立てること
をやっていました。さすがにクランクシャフトはプレス機がないと組めませ
んから分解できませんが。特にCBX550F2Dが好きで2台持っていました。

そこですごく細かい話なんですが、ネジというのはいかに適正なトルクで締め
付けても、少しずつ破壊されてしまうんです。ネジが緩まないということは、
ミクロな観点から見れば不可逆的な破壊が起こっているからで、双方とも何
の変化もしないのであれば、するっと抜けてしまうはずです。

ところが、プログラミングの世界では、どんなにバラバラにして組変えようが
何一つ消耗したり、磨耗したりしません。また、クランクシャフトのように
設備がなければ手を出せない部分というのも存在しません。

また、型式が登録されていなければ公道を走れなかったり、ライセンスや
レギュレーションが適合しなければサーキットを走れなかったりという制約
は一切ありません。なんと素晴らしいことでしょう。

込み入った事を、いろいろと解決してきた訳ですが、やっはりその目的は
低層での面倒を包み隠すことにあった訳ですから、取り説にはレジストリ
とかマニフェストという言葉が出現しない状態としなければ意味がありま
せん。つまり「隣に置いてください」で総てが解決できる完全なサイドバ
イサイドのモジュール連携をHTABOXが提供するというコンセプトです。

2chにスレ立ててしかもsage進行って、物好きか粘着しか来ねぇぞ、オッサン。
いまどきHTAとか、ボンクラ役場でも需要ないやろ。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。単独の起動では発生しないのですが、ビルド直後というよう
な厳しい状況下で稀に起動がストールすることへの対策を加えました。

HTML5によるアプリケーション開発が本格化すれば、windowsのHTMLエンジン
であるMSHTMLをいかにコントロールできるか？という事が今より重要視され
る時が来ると考えています。ユーザーにとって重要なのは四角い窓がどんな
テクノロジーで生成されているかではなく、その内容です。ならば作る側は
最短の労力で内容に集中できる環境を選択すべきです。

HTABOXはHTMLアプリケーションをリリーする段階でEXEファイルを生成します。
ユーザーはその四角いウインドウがHTMLアプリケーションであることを知る
ためにはSPY++でウインドウクラス名を確認する必要があります。

HTABOXの出発点には「それを必要としている人間が書いたアプリケーション
こそ最高のもの」という考えがあります。誰しもが自分の経験やアイディア
をできるだけ低い敷居でアプリケーションとして公開できれば、それを使用
する側にもメリットが生じるわけです。

HTABOXはアプリケーションを書く人のための参入ツールであり、HTMLのGUIを
C++等と癒合したいエキスパートのためのツールでもありたいと考えています。

何だかtest.jsが添付されるようになったあたりから正常に終了せずエラー報告が出ます

>>57
了解しました。非表示でHTMLインスタンスを生成し実行している部分のコード
を洗い直します。OSとIEのバージョン、それからエラーの出方（windowsシステムから？）
を教えていただけると大変助かります。

ちなみにtest.htmの
<body bgColor=#9999ff>
<HTABOX:Extern id="JS" src="test.js"/>　　＜−この行を削除
した場合にエラーが発生しなければtest.jsがらみな事が確定しますので、
ご多忙でしょうが、確かめていただけるとなお助かります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。HTABOX:Extern部の余計な記述を削除してみました。また、
終了時Beep音がしますが、これは外部JS用非表示HTMLが正常に削除された事
を報告するためのものです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。終了時にDllCanUnloadNowに正しくS_OKを返さない可能性
がある部分を修正しました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。HTABOXは例外を最終的にcatch(...)で受け、総ての例外を
捕捉する設計としていますが、DllMainにこの記述がありませんでした。何
らかの内部例外はすべてダイアログで報告されます。ただ、今回の件は終了
時ということですので、メモリ又はCOMインスタンスの開放不十分、または
重複した開放動作が疑われますから、あまり関係ないかも知れません。

当方の他の環境XPsp3 + IE8 だと現状で終了時エラーは無いのですがDLL偽装
がまったく機能していないことを確認しました。OBJECTタグ処理に関する部分
も全面的に確認することとします。

訂正します。DLL偽装は正常に動作していますが、OBJECTタグの実験スクリプ
トエンジンが動作していないだけのようです。ちょっと肝を冷やしました。

環境はXP+IE6及びXP+IE8でエラーメッセージはMicrosoft Application Error Reportingによる
「問題が発生したため、HTABOXAPP.exe を終了します。 ご不便をおかけして申し訳ありません。（以下略）」ですが
test.htm中の<HTABOX:Extern id="JS" src="test.js"/>を削除したところ正常終了できました。

また、>>62のHTABOXAPP.exeでは
test.htm中に<HTABOX:Extern id="JS" src="test.js"/>が記述されていても正常に終了でき、
その際のBeep音を確認しました。

早速のご報告ありがとうございます。今後ともよろしくご指導ください。

IE8のOBJECTスクリプトの件は原因がはっきりしました。開発機はIE7なので
すが、IE7の場合<OBJECT/>に対して2回生成が行われます。1回目は空動作に
近く、2回目で機能させなければいけないのですが、IE8はこれが1回なので
す。当然1回だけのほうが理にかなっているのですが、これを何らかの形で
吸収しなければなりません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。実験的な試みという位置づけではありますが、OBJECTタグ
によるJScript隠蔽デモをIE8に対応させました。前述のとおりIE7は2回呼び
出してくるのですが、SCRIPTSTATE_STARTEDで開始せずSCRIPTSTATE_CONNECTED
が発生するかを待つと2回目を正しく認識できるようです。

ActiveScriptテクノロジーというのも10年以上進化が見られない、逆に言えば
十分に枯れた規格なのですが、普通の人はMSDN見てもチンプンカンプンだと
思います。かくいう私もハァ？だった部分が多かったのですが、埋め込みOBJECT
として動作させると、なぜそういう設計なのか納得できます。HTML側はエンジン
に対してwindowをグローバルに追加したいからよろしくと報告してきます。
エンジン側は動作中にwindowが必要になったらHTML側サイトへ取りにゆきます。
実にごく自然な流れです。これが、自前でサイトを作った場合、エンジンに
名前だけ教えて、サイト側にIUnknownを待機させるというハァ？なことになる
理由です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。厳しい環境で稀に起動が遅れることへの対策を変更しました。
GUIスレッドウインドウ生成後にWaitForInputIdleを入れるとメッセージの
デッドロックを回避できるのでは？という結論に達しました。

アプリケーションという表現はとても広範囲なのですが、私がHTABOXに対し
て抱くアプリケーションのイメージは様々な業務に直結するビジネスアプリ
ケーションです。私が救急統計を一つの題材としているように、各人がそれ
ぞれの業務を通じてノウハウを持っているわけですし、エクセルのマクロみ
たいな従属的手段ではなく、堂々EXEで発表、発売できる環境をイメージして
います。はっきり行って日本の業務用ソフトウェアは誰でも書けそうなレベル
のものを、相手が書けない（理解できない）ことをいいことに法外な値段で
売りつけているイメージを持っています。

前職の場合そこで拠出されるお金は「血税」な訳ですから、微力ながらそうい
った「作る側の体質」、「買う側の無知」を正すべく行動しているわけです。

もうひとつ加えるなら、この国の将来です。物質としての工業製品で優位を
保てる時代はとっくの昔に終わっています。物を削り、加工する作業は寸分
たがわず、工業用ロボットが行えるのです。新しい技術さえそれが「物」で
ある以上、即座に模倣され、より低いコストで競争相手として現れます。

物に変わる商品それが「情報」や「テクニック」や「叡智」です。それらは
まさしくコンピューター上のアプリケーションで表現できる商品です。そし
てその知的財産を保護するために提供媒体でソースが見えない事は絶対条件
となります。

なぜ、.NETのアセンブリや、Javaのクラスは逆アセンブルできるのか？
これについては様々な言い訳を用意しているに違いありませんが、用は書
いている人間を使い捨てたいからです。「貴方じゃなくてもその続きは書
ける」という状態を「生産性」と表現しているだけにすぎません。

私は個人のオリジナリティーの延長として完結したアプリケーションを提供
できる環境が生まれなければ、そのことに対する労力を軽減してくれるツー
ルが存在しなければ、本当に汗したものが報われる世界は訪れないとさえ思
います。

今日の課題は、全体を単純なサイドバイサイドシステムを機軸としたものへ
置き換えることです。これは、一旦自分が書いたものを完全にバラして、再
構築する大手術になりますが、書いたのは誰でもなく自分ですから不可能な
ことは何も存在しません。

現在持っているイメージはこうです。
HTABOXAPP.exeは、単に実行された場合、自身と同じディレクトリにあるHTML
系ファイルを列挙して、テキストベースの対話型ダイアログを表示します。
ここで特定のHTMLを選べば実行します。この段階ではEXE側もHTML側もファイル
名には縛られないものとします。同時実行する外部ファイルはHTABOX:Extern
で定義されていますので、HTABOXは実行対象HTMLファイルの指定だけで動作
するというシンプルな状態に回帰します。

HTABOXAPP.exeへ実行可能HTMLがドロップされた場合、EXE生成動作を行います。
生成ファイルは実行HTMLの拡張子をexeに変更したものになり、QuickのEXE生成
がそうであったように、同一ディレクトリにあるHTABOXAPP.exe以外の全ファイ
ルがテーブル形式で一覧され、リソースへ格納するのか、出力先ディレクトリ
は何処かを選択可能とします。

未格納EXEを単にクリックで列挙後実行、HTMLドロップでEXE生成です。

exe(笑)

vista + IE9 で確認したところ内部ビヘイビアは問題ありませんが、DLL偽装
はこのままでは機能しないようです。固定マニフェストによるHTABOXからの
動的中継とした方が自然かも知れませんので、もう一度この辺の機構を見直
したいと思います。

vista環境には
{71650000-E8A8-11D2-9652-00C04FC30871}:WEBVWLib.ThumbCtl
{BCFD624E-705A-11D2-A2AF-00C04FC30871}:WEBVWLib.WebView
{844F4806-E8A8-11D2-9652-00C04FC30871}:WEBVWLib.WebViewFolderIcon
自体が存在しないというのが真相のようです。この置き換えは既存GUID
要求を摩り替えることで成り立ちますので、2,3のGUIDをHTABOX又は隣接
DLLのマニフェストに定義し、中継する方向で考えています。

EXEファイルでDllGetClassObjectをExportしてマニフェストで自身を呼び出す
というのは、教科書的にはいかがなものか？なのかも知れませんが、動きを
見る分にはなんの問題も起こらないようです。そこに数個のGUIDを宣言し、
そのうち一つを中継DLLリスト作成用に、もう一つを実際の中継用にしてIE9
のご機嫌を伺ってみることにします。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。IE9での動作を確認しました。
考えてみればAPIフックのDLL置き換えというのは本当に置き換えたい対象が
存在する場合の手段ですし、普通にマニフェストで自身EXEへ誘導し、あとは
内部のClassFactoryでいかようにも、というのがごく自然です。

自前のDLLをOBJECTとして埋め込みたい場合は、実行HTMLファイルとの相対パス、
ClassFactoryとして認識させるExport関数名、オプションとして、同一Factory
へCLSIDによる識別が必要な場合のCLSID文字列という事になるだろうと思います。
区切りのマークとしては#を採用したいと考えています。

[hoge.dll#factory#71650000-E8A8-11D2-9652-00C04FC30871]

のような文字列を先頭オブジェクト宣言の内部コメントとして書けばレジストリ
とかマニフェストとかとは無関係に埋め込まれる仕様になります。

DllGetClassObjectをEXE形式ファイルが実装し、自身プロセス内からのCLSID
要求をマニフェストによって自身へ転送するという手法は実に軽量で、エレガ
ントなんですが、このEXEがサーバーとしてレジストリ登録される場合は自己
参照しているマニフェストを削除しないと無限ループします。（たぶん）
なぜそうなのかを、順序だてて考えたことはありません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。HTABOXAPP.exeに記述されていたDLL参照マニフェストを削除
し、自己参照のみとしました。したがってzipサイズが小さくなっています。
外部実行スクリプトはother.htmのスクリプトタグ内に記述することに変更し
ました。今後は外部実行HTMLという呼称になると思います。
test.htm中のOBJECT生成用CLSIDは内部での識別に利用されるだけであること
から一見してそれと判るものに変更しました。
struct __declspec(uuid("FFFFFFFF-EEEE-DDDD-CCCC-BBBBAAAA0001")) Object1;
struct __declspec(uuid("FFFFFFFF-EEEE-DDDD-CCCC-BBBBAAAA0002")) Object2;
struct __declspec(uuid("FFFFFFFF-EEEE-DDDD-CCCC-BBBBAAAA0003")) Object3;

今まで自動生成されたGUIDを受け入れざるを得ないことが不満でしたが、これで
ちょっとすっきりした気分になれました。

IE9に今までのコードを全面否定されたら、全部投げ出してしまいそうなほど
気分が落ち込んでいる日だったのですが、そこを乗り越えることができただけ
でも良かったと思うことにします。これから余計な既存コードをバッサリ切る
作業になりますので、プロジェクト全体をコピーして気分を変えなければなり
ません。

スレッドも新しくなって、見ている方も一人か二人増えたかも知れませんから
改めて書きますが、HTMLアプリケーションの最大のメリットはアプリケーショ
ン実体（実行HTML）をサーバーサイドに置けることです。これはブラウザベー
スでのWEBアプリケーションとは別物の自由度を持っています。起点がアプリ
ケーションですから「何でもあり」になります。何処までがローカルにある
コードで何処までがサーバーサイドなのかということを全く意識させません。

ローカルに空なページを置いて総てサーバー側で動的に生成することも可能
なら、99%ローカルのライブラリを使い、ユーザー認証だけサーバーサイドで
行うというような事がごく自然に可能です。

例によってXP+IE6及びXP+IE8ですが、
最小化してもタスクボタンに収納されないなど最外郭のウインドウが妙な動きをします

>>85
了解しました。関連部分を精査してみます。

状態を確認しました。ディスクトップのMDI子ウインドウになってしまって
いますね。できるだけ早急に修正版をアップしたいと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。タスクに入らないバグを修正しました。GUIスレッド対策
ウインドウの子にすればActiveの委譲がスムースかなぁという書き方にして
いましたが、GUIスレッド対策ウインドウはタスクに加わる条件を満たして
いないため結果的にタスクバーへ入れなかったというストーリーでした。
以前と同じようにWS_EX_TOOLWINDOWのウインドウとして、最外郭とは無関係
な状態としました。

でもActiveの委譲がまずいですね。以前のコードを参考にしながら対策を行
いますので、ちょっと時間をいただくことになります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。コンテキスト統一のために最外郭ウインドウもHTAスレッド
から生成しているのですが、プライマリスレッドでないとプロセスとしての
ActiveWindow受け渡しは機能しません。ここが悩ましいところです。
プライマリ側のベースを
CreateWindowEx(WS_EX_TOOLWINDOW, TEXT("Base"), NULL, WS_POPUP|WS_VISIBLE.......
最外郭をBaseの子として
CreateWindowEx(WS_EX_APPWINDOW|WS_EX_ACCEPTFILES, TEXT("Outer"), NULL, WS_OVERLAPPEDWINDOW|WS_CLIPCHILDREN|WS_VISIBLE.....
とすれば目的を達成できるようです。

今回のバイナリには起動時の状況が過酷だった場合の対策が施されています。
これは、全くストレスが無い状況でも従来より迅速な起動を促す仕組みとして
います。私の非力な開発環境ではVisual Studioでビルド後に即実行する局面
でしばしばデッドロックぎみになっていましたが、この対策によりそういった
状況は生まれなくなりました。

まだ、HTAとダイアログの生成には改良の余地があるように感じています。
特にダイアログはドキュメント的にはHTAそのものですし、不完全ではあ
りますが、<HTA:Application/>を認識するようです。ならば、両者を統一
した書き方ができるのではないかと考えています。処理的に早くなる部類
の改良ではないのですが、全方位なHTMLアプリケーション用ウインドウシ
ステムになるだろうと思います。

「両者の統一」をもくろみましたが、生成機序を分析すると、かなりの相違
がありました。結果としてドキュメントインスタンスのアドレスを変化させ
ないまま、内容とサイトを変更することには成功しましたが、途中に待ち構
える関門は「そうされたくない」という意思による「トラップ」のような気
がしました。結局こういったアンドキュメントな部分を探求し始めると、私
のように時間ばかり費やすことになりますから、とてもお勧めできません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。何かが追加された訳ではありませんが、最も心を痛めていた
「拡張ダイアログのデバッガアタッチ」を可能としました。結果として拡張ダ
イアログは親HTAと同じく3重なHWND構造となりました。まだその部分を書い
ていませんが、HTMLダイアログ的表示スタイル指定ではなく、サイズとウイン
ドウスタイルを指定した生成関数を予定しています。このダイアログはヘルプ
等の補助アプリケーションを実行する目的で存在します。単に複数から択一す
るような動作の場合は通常ダイアログの方が扱いやすいと思います。

MSHTMLのドキュメントHWNDとフレームHWNDは通常のOLE的結合以上に強い結合
状態なのではないかと思います。ドキュメントを押しのけてネイティブなHWND
を配置しようとすると全体が不安定になったと記憶しています。以前までの
拡張ダイアログはその結合を強引に引き剥がすことで2重構造のままでしたが、
その弊害としてソースが見えない（デバッグできない）状態となりました。

今回は、HTAと同じように2重構造内部にはタッチせず外郭のウインドウを生
成することでメニュー等のコントロールを共存させています。正直言ってHTA
やHTMLダイアログが消費するメッセージを監視して、その中のどのコンテキス
トで何をやったらうまく行くのかという推理ゲームは終息したと思います。

例えばメニュー一つにしても、チェックや、動的な変更、画像の追加等々..
WIN32的には山ほど課題はあるのですが、それはさて置いといて、全体として
の手法や構造を軽量で、揺ぎ無いものとするために多くの時間を費やしてし
まいました。動かして「あぁちょっと無理があるな」というのは感覚として
判りますし、そういうものを世に出すくらいなら、その先を書くべきだろう
というのが私の小さなプライドでした。

プログラムのすっ飛び方で、「あぁたぶんあの辺が」という感覚は異常に研
ぎ澄まされましたが、それ以外の事では「変人」を通り越して「廃人」状態
です。もし何も成就しなかったとしてもそれは私の器なのだと諦めます。
自分としてはとても美しいモジュールが書けたのですが、何なんでしょう
この虚しさは。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログ生成機序を見直しました。若干スムースだと思
います。HTML系ウインドウ全般に言えることだと思うのですが、表示されて
いるということと、生成されるということには密接な関係があるようです。
したがって表示しないと生成されなかったり、表示しないと変更ができなか
ったりします。このダイアログも出現時若干白いバックが気になりますが、
これはすばやい生成を重視した結果です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログ系の動作を見お直しました。従来モードレスは
親の背後に回りこめる仕様としていましたが、常に親の前面に表示すること
とし、WIN32.CreateDlgWindowExで生成された場合のみ背後に回りこみます。
また総てのダイアログは親の消滅と同時に消滅するものとしました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。昨日の改良でドキュメントのコンテキストが更に安定しまし
たので、ステータスバーのSBARS_SIZEGRIPを復活させてみました。また、ダイ
アログでもその試験ができるようにWS_THICKFRAMEを付加しています。

IE8で見るとダイアログのフレームマージンがゼロですね、これはサブウイン
ドウとしての使用を想定していますので、デフォルトマージンを認識するよう
に修正したいと思います。今日ちょっとした発想の転換でHTAもダイアログも
軽量で確実な手法に変更できたと思うのですが、結局HTA系ウインドウの中で
最も柔軟性に富むのはモードレスダイアログであるという結論に達しました。
ただし、モードレスは新たなスレッドで生成されますから、そのスレッドへ
いかに侵入するかという課題をクリアしなければなりませんが、プロセス中
にいくつ生成しても文句を言われないHTAがモードレスダイアログです。

でもモードレスの引数ディスパッチのコンテキストが不正ですね。現状では
親documentを操作しようとするとストールしてしまいます。これにはいくつ
か対策が考えられますから、克服できると思います。本来はIHTMLDialogで
提供される引数を手動で追加する必要があるものですから、追加時のコンテ
キストが流れを外していますね。

これって

Webプログラミング板
http://kohada.2ch.net/php/

こっちでやるべきスレじゃないの。少なくとも製作日記を
垂れ流しているだけでプログラミング的な話題はないね。
しかも商用ソフトみたいだし、宣伝のために2chでスレを
立てるってどうなのよ。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。モードレスダイアログを修正しました。デフォルトマージン
を認識し、引数ディスパッチのコンテキストも正常です。

>>102
ご意見は真摯にうけとめました。HTABOX系はライセンスフリーなバージョンを
必ずご用意しています。

SBARS_SIZEGRIPで提供されるカーソルの変化は恐らく、システム中の優先度
が低いのではないかと思います。ですから、メッセージの生成と消費が健全
でない場合マウスカーソルが復元しない事態が起こってしまう。だとすれば
これは一つの試金石になるはずですし、今のところ正常ですから、いよいよ
お役に立てるレベルに達したかも知れません。

板違いの件はスルーですか。

>>105
私はこのサーバーの規約について不勉強なのかも知れませんが、
「この板はプログラムを作る人のための板です。」という言葉をそのまま
解釈しています。もし不快な想いをさせているなら、陳謝いたしますが、
ルールに反しているとは考えておりません。

現在のバイナリにあるダイアログはITargetFrameを実装しデフォルトマージン
を認識するはずなのですが、IE8環境ですと、マージンゼロな状態です。
これを強制することは容易ですが、逆にブラウザ毎の仕様に沿ったコーディン
グを阻害する恐れがありますので、このままとします。当然bodyのleft,top
各マージンを指定すればHTML的にマージンを設定できます。

IE8では依然としてダイアログのマージンはゼロですね。ITargetFrameを実装
しているのですが、これはブラウザの仕様と判断しました。ですから、強制
的にマージンを持つよりも、bodyのLeft、Top各マージンでHTML的にコントロ
ールしていただいた方が混乱しないだろうと考えます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ここにつぶやいてから実装が甘いことに気づきました。
ダイアログはデフォルトマージンを認識するようになりました。接続の怪し
い所から送信したものですから、107と108はエコーのような書き込みになっ
てしまいました。お詫びいたします。

やっと基礎が完成したと思い、非力なノートのIE8環境でコンパイルしたとこ
ろモーダルダイアログの振る舞いがIE7環境コンパイルと違い、その対策で朝
を迎えてしまいました。まったく同一サイズのEXEが生成されているのですが
何かスタティックにリンクされるものが異なるんだと思います。こういう時
は不満をぶつける先を見つけるよりも、何かを諭してしるんだと考えて対策
を模索しました。HTML自身がHTMLを置き換えるという発想で解決できました。

MSHTMLを自由にコントロールするということはIEクラックにつながるもので
すから、いつも奥歯に物が挟まった言い方しかできなくてすいません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。開発時のIE7,8,9環境差に左右されないコードとしました。
vista + IE9 での動作確認済みです。これでHTABOXのベーシックな設計は完了
したと認識しています。とりあえず、感謝の意味をこめてtest.htm以外を実行
する簡易バージョンを早急に公開したいと思います。

このサーバーでつぶやく事が始まって3年がたったのでしょうか。もう自分で
も正確には時期を思い出せないほどの過去になりました。自分で目標を定め
自分だけでコーディングする、その間何の刺激も励ましも無いとしたら1年も
たないんじゃないでしょうか。コードを書けば常にその時点でベストな選択
をしていると感じる訳ですが、バグや動作への不満が生じれば、さっきまで
ベストだと確信していた自分を乗り越えるもう一人の自分が出現しない限り
前へは進めません。

ですからウォールトーク（壁と話す）ことをプログラマーなら誰しもやると
思います。このサーバーを借りて私は見苦しいウォールトークをしてきた訳
ですが、私が語りかけているのは壁ではなく、私を気にかけてくださる方々
でもあるという、非常に恵まれた状況だったことを痛感しています。絶対に
私一人ではここまで書けなかったと思います。

水を差すようですがXP+IE6だと>>97あたりのバージョンからダイアログが空になります

>>114
情報ありがとうございます。当方でもIE6環境で動作を確認したいと思います。

当方のIE6環境はwindows2000なものですから、即座に状況を確認することが
できませんでした。（HTABOXはXP以上の標準DLLを条件としているため）
継続した課題とは認識しておりますが、IE6についてはマイナーなサポート
になる可能性があることをご了承ください。

IE6に対応可能かを判定するための専用zipを用意しました。
ttp://kuroda.bglb.jp/htabox/htabox300b.zip
ダイアログの表示を要求すると、ダイアログと外郭ウインドウが別に表示
されます。両者の内容が白く、内容が無い場合IE6は対象外となる可能性が
高くなります。拡張機能とデバッグは当初相反する要素でしたが、それを
解決する目的の変更でIE6での表示が不能だとすればIE6では通常ダイアログ
を使用していただくことになろうかと思います。

>>117を試しましたがそれ以前と変わらず
ダイアログは空（タイトルバーのアイコンはIE）で外郭ウインドウは表示されず、
return = undefinedが返ってきますね

>>118
ご報告ありがとうございます。私も長年IE6で開発を行ってき、ダイアログ内
でのURL変移は不可能だと思っていたのですが、IE7以降だとそれが実現できる
ことから、ドキュメントアドレスを変更しないまま、あらゆる拡張をスムーズ
に行うという選択になりました。

最も安全な解決策はサイト拡張ではなく、冒頭に必ず<OBJECT/>を定義して
それをビヘイビアのファクトリーとすることですが、開発環境を構築しなけ
ればなりませんので、課題とは捕らえるものの早急に取り掛かるというわけ
には行かないことをご了承ください。

と書いて、前述の動作コードが頭に浮かんで消えません。要は
「必ずGUIDが冒頭に無ければならないHTMLは興ざめだろう」というまったく
個人的な判断で、サイト拡張を選択しているわけです。もし、冒頭にあって
もかまわないなれば、さらに軽量でわかりやすい生成機序となりますから、
これも何かを諭してくれている「声」と認識してすこし書いてみます。

IE6の実験環境が無いので確認はできないのですが、モーダルの方はサクッと
書けました。ところがモードレスの場合、OBJECT生成とビヘイビア生成はド
キュメントのHWND生成より先であるというデータが出ました。サイト入れ替
えの場合は空に近いドキュメントで一旦HWNDを出してますから全く問題にな
らない部分なんですが、初期URLだとこんなに早いのは意外でした。何らかの
手法でこれをやや遅延させる事ができればコードは単純で済むように思います。

メッセージを消費しながらの遅延も試みましたが、全体の生成がブロックさ
れますからうまくゆきません。最後の手段はonloadで動的にエレメントビヘ
イビアを追加することですが、スクリプト側の記述が煩雑になると思われます。

今回のトライでは、逆に現状のシステムが理にかなっていることを浮き彫り
にしました。ネイティブなコントロールを親HWND無しに生成するためにはダミ
ーHWNDを作成するような回りくどいことになるわけです。まぁどんなに回りく
どくても不可能ではないんですが、検証環境も無いことから継続した課題と
して捕らえますが、IE6はサポートできるバージョンではないというのが現状
での回答となります。

貴重な情報をありがとうございました。今後ともご指導ください。

昨夜の課題はビヘイビアの生成タイミングが早すぎ、その生成タイミングを
遅延させられないという展開だったのですが、ビヘイビアは特定のフラグで
本来の生成をスルーしてそのアドレスをストアし、ドキュメントのインタラ
クティブで、もしストアされたアドレスが存在した場合は列挙してトリガを
引くとすればこの問題はエレガントに解決しますのでちょっと書いてみます。

最大のポイントは本来MSHTML側から引かれる引き金をOBJECTから引いてもコ
ンテキストや、タイミング的に問題が生じないのか？でしたが、CSS用ビヘイ
ビアのように他のエレメントへ影響を与えるもので無い限り、任意なタイミ
ングで生成しても、全く問題は生じないようです。

これで動作や設計の自由度は格段に上昇しますが、冒頭にGUID必須はいかがな
ものかという考えは変わりませんから、非公式な機能としてドキュメント変移
を伴わないHTABOX名前空間エレメント生成機能を実装したいと考えます。

現行HTABOXAPP.exe用にWIN32なしVBScriptで何となく書いた擬似singleinstance

Set objSell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
cmdPath = Chr(34) & objFSO.GetFolder(".").Path & "\HTABOXAPP.exe" & Chr(34) & " "
For Each oClass In CreateObject("WbemScripting.SWbemLocator").ConnectServer.ExecQuery("Select * From Win32_Process")
　If (oClass.Description = "HTABOXAPP.exe") And (Left(oClass.CommandLine, Len(cmdPath)) = cmdPath) Then
　　oinStance = CInt(oinStance) + 1
　　If (CInt(oinStance) = 1) Then oProcId = oClass.ProcessId
　　If (CInt(oinStance) > 1) Then
　　　For i = 1 to 100
　　　　If (objSell.AppActivate(oProcId) = True) Then Exit For
　　　Next
　　　Self.Close
　　End If
　End If
Next

HTAタグが利用可能となって無用のコードになるのを期待してます

>>125
VBSでsingleinstanceが実現できるとは知りませんでした。大変勉強になります。
HTAタグ互換近日中に実装しますが、既存の属性にとらわれない属性のご要望な
どありましたら、気兼ねなく書き込んでください。

IE6対応実験
ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。実働環境がないので自信はありませんが、ダイアログが表示
されるのではないかと思います。もし表示された場合このモードでのダイアロ
グ呼び出し関数を新設します。外見上位の差異はITargetFrameが実装されて
いないでのマージンがゼロな事です。

サーバーへのアップ操作に混乱が生じたようで、ファイルを更新しました。
300bの方に昨日のファイルも含まれてしまっていたようです。
実験的に親HTAの方もサイトを入れ替えない状態としていますが、モードレス
にあわせてwindow.onloadまで待つものですから、ややギクシャクするようで
す。全体の負荷としては当然軽くなりますが、サイトに介入しないとできな
い事はけっこうありますので、あくまでも非公式な動作状態となります。

300bの方のdialog.htmを見ると明らかですが、下記記述が必須となります。
<html xmlns:HTABOX>
<head>
<object id="Factory" classid="clsid:FFFFFFFF-EEEE-DDDD-CCCC-BBBBAAAA0000" VIEWASTEXT>
<!--dummy-->
</object>
<?IMPORT NAMESPACE="HTABOX" IMPLEMENTATION="#Factory"/>

GUIDは初心者を威圧する気がしますし、<?IMPORTは整形XMLとして不正な表記
ですから、 <!--[if IE ]みたいな工作をしないとXMLパーサーに怒られる
はずです。

冒頭のOBJECTでドキュメントのイベントを受信するわけですが、かなりハマリ
ました。親HTAの上にダイアログが表示される場合、こちらとしては新たなオブ
ジェクトが生成された方がいいわけですが、ドキュメントのポインターに触る
と、プロセスで共有されるインスタンスになるようです。ですからもし、親
の生成と子の生成が重なった場合破綻します。親ウインドウとダイアログとい
う関係の場合はそれが起こらないわけですからいいのですが。

じゃあということでイベントを取らずHWNDメッセージループからビヘイビア
の生成を行うと、一見動作するようでコンテキストが違うと怒られる。えっ
と思ってHWNDメッセージループのまま、空動作でイベントを取ると動くとい
う状態でした。結局最後はイベント駆動にしましたが、なぜそうなのかは神
のみぞ知る領域だと感じました。

>>127を試すとモーダル、モードレス、CreateDlgWindowExともダイアログは表示され、
その中のステータスバーへの文字列表示・引数ディスパッチの実行は成功されるのですが、
どのダイアログでもツールバーとポップアップメニューが生成されず、
モーダルのみreturn = undefinedが返ってくるという状態です

>>114
了解しました。表示されたのですから、あとは微調整で克服できるかも知れま
せん。今日はもう遅いのでお休みになった方がいいと思いますが、各段階で
Beep音の確認ができるものを用意したいと思います。私も休みますから待たな
いでくださいね。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。これはbではなくノーマルな方ですが、教えていただいた
情報から推察するに、中間にあるフレームHWNDの認識がうまくゆかなかった
とすれば、このノーマルなバイナリで動作するかもしれません。同じ修正を
加えたbの方もアップする予定です。ただ、returnが気になりますが...

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。
ダイアログ起動時に基準音としてBeep(2000, 100);が実行されます。
中間フレーム認識で同じ音程Beep(2000, 100);
ドキュメントHWND認識で高い音 Beep(3000, 100);が実行されます。

1回しか音がしないのか、2階で音程が違うのか、3回鳴るのかで状態を推察
できます。

>>131
ttp://kuroda.bglb.jp/htabox/htabox300c.zip
を用意しました。これはcです。
ノーマルHTABOXのダイアログHWNDメッセージをコンソールへ表示しています。
もし一度しか音がしなかった場合このコンソールの冒頭にFraHwndとしてフレー
ムへのメッセージ履歴が表示されますので、タイトルバーの右クリックから
選択、コピー等で20行か30行くらいここに張っていただければ原因が明確にな
ります。ノーマル、で正常動作していましたらその必要はありませんが。

いつだったか富士通のエンジニアさんが「コマンドラインかブラウザベース」
という言葉を使ったのが印象的でした。ブラウズ、閲覧ですから広義に捉えれ
ばコマンドライン以外は全部ブラウズなのかも知れませんが、私はもっと狭義
なブラウザベースのことに想いを馳せました。

プログラミングの結果を提供する手段は、物理的な媒体を渡すのではなく、
また、固定されたバイナリを渡すのでもなく、ネットワーク経由での動的な
ものにならざるを得ません。そこで多くのプログラマーは既存のブラウザの
ご機嫌を伺わなければなりません。セキュリティーがどうのこうの、クロス
ドメインがどうのこうのという問題です。

「なら、もっと自由度が高いブラウザを書きましょうよ、どうして誰も書かな
いんですか？」というのが私の考えです。ネイティブなモジュールをサイドバ
イサイドで活用でき、ディスパッチ経由であらゆるスクリプトと交信でき、軽
量なネイティブコントロールをチョイスできるブラウザをです。公衆ネットワ
ークを前提としたがんじがらめのブラウザ拡張ではなく、ローカルEXEの視点
からネットワークを有効利用するために拡張されたブラウザこそ私がこのプロ
グラムに抱く姿です。

考えてみると、このサーバーはプログラマー向けですから、たくさんのスレ
ッドで開発言語談義に花が咲くのでしょうが、言語など似たり寄ったりです
から、何より何が優れているという主張はナンセンスです。ただ人生の時間
は限られていますから、消えてしまいそうなものに時間を費やさないことで
す。少なくとも過去10年は有効であり、現在も活用されているものを選択
すべきです。

これは個人的な提言でしかありませんが、Windows上でチャレンジングなプロ
グラミングを効率よくやろうと思えば、ネイティブな言語、HTML&XML、何らか
のスクリプトの３つが必要になることを念頭において、興味のある分野から
勉強すればいいと思います。多くの場合はスクリプトでしょうか。もし、スク
リプトも上達してきて「あれができない、これも許されない」を感じるように
なったら、それは貴重な財産です。あなたの関心がネイティブな言語へ向かう
エネルギー源になりますし、あなたが感じた不満を解消するツールを書けば
多くの人に感謝されるでしょう。しかも世界中の人にです。

ただし、プログラミングは同じものが二ついらないという厳しさがあります。
あなたが苦労してAと同じようなものを書いたとしても、評価されないでしょ
う。AにA`はいらないのです。ならば、それがAを超えてSになるまで諦めては
いけません。皆さんと比べれば私にはもう時間も能力も残り少ないのですが、
まだ、若い皆さんには無限の可能性があります。原材料に資金が必要でもなく
土地や店舗に賃貸料を払う必要もありません。あなたの叡智とあなたの努力
で未来を切り開ける「プログラミング」という世界を探求してください。

Bの場合は>>131と同様の状況でBeep音は何れも一回のみ、
また>>131では書き漏らしていましたがメインのウインドウでタイトルが空なのも変わらずです

ノーマル及びCの場合、モーダル及びモーダレスではダイアログは空（タイトルバーのアイコンはIE）で、
CreateDlgWindowExはライン：171、文字：1でIEスクリプトエラー
（引数の数が一致していません。または不正なプロパティを指定しています）になります。
またモーダルのみreturn = undefinedが返るのは共通ですが、
CではモードレスとCreateDlgWindowExでタイトルがHTABOX CORE 3.00で中身なし、
OKボタンのみのメッセージが出ます

以下コンソールのメッセージ

モーダル
~WrapSite()
~IHtmlWindow

モードレス及びCreateDlgWindowEx
~WrapSite()
DispMother delete ref = 0000000a OBJECT = 0000000a
~IAutoDispatch DispHelp 00000000
~IAutoDispatch DispHelp OBJECT = 00000009
~DispResource ref = 00000000
~IAutoDispatch DispResource 00000000
~IAutoDispatch DispResource OBJECT = 00000008
~DispDotNet ref = 00000000
~IAutoDispatch DispDotNet 00000000
~IAutoDispatch DispDotNet OBJECT = 00000007
~DispWinHwnd ref = 00000000
~IAutoDispatch DispWinHwnd 00000000
~IAutoDispatch DispWinHwnd OBJECT = 00000006
~IAutoDispatch DispWshDlg 00000000
~IAutoDispatch DispWshDlg OBJECT = 00000005
~IAutoDispatch DispEncoder 00000000
~IAutoDispatch DispEncoder OBJECT = 00000004
~IAutoDispatch Script 00000000
~IAutoDispatch Script OBJECT = 00000003
~IAutoDispatch DispUtil 00000000
~IAutoDispatch DispUtil OBJECT = 00000002
~DispMlang ref = 00000000
~IAutoDispatch DispMlang 00000000
~IAutoDispatch DispMlang OBJECT = 00000001
~DispWinApi ref = 00000000
~IAutoDispatch DispWinApi 00000000
~IAutoDispatch DispWinApi OBJECT = 00000000
~IHtmlWindow

>>142
お忙しい中稚拙なアプリケーションの開発にご協力いただき、ありがとうござ
います。現状での問題点が明らかとなりました。もし、他のバージョンのIEを
お持ちで、Cを実行していただければログは次のような冒頭部分になります。
WndProc FraHwnd 00030366 0024
WndProc FraHwnd 00030366 0081
WndProc FraHwnd 00030366 0083
WndProc FraHwnd 00030366 0001
WndProc FraHwnd 00030366 0005
WndProc FraHwnd 00030366 0003
WndProc FraHwnd 00030366 000c
WndProc FraHwnd 00030366 000c
WndProc FraHwnd 00030366 0046
WndProc FraHwnd 00030366 0024
WndProc FraHwnd 00030366 0083
WndProc FraHwnd 00030366 0047
これが存在しないということはダイアログ生成スレッド自体を認識していま
せんから、現状では打つ手がありません。

以前に表示されていたバージョンでは単にモードレスな場合親を新規非表示
ウインドウとすることで、内容はモーダルを使った単純なものでした。この
場合スレッドは明白ですからメッセージも取得できていたと思われます。

現状はHTMLの標準モーダル、モードレスを活用しながらそのスレッドを検出
して操作しています。この動作にはモニカの仕様が深く関与しますが、IE6
の場合その仕様が全く異なるということです。

私としては、大変貴重な情報でしたし、サイト介入しない拡張手法等、多く
の収穫がありましたが、ご要望自体には答えることができなかったという
ことです。大変心苦しいのですが、IE6はサポート対象外であることを明確に
表明させていただきます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。IE6のモニカ仕様を解析し対応しましたが、これはIE6のメジャ
ーなサポートを意味するものではありません。

今回はモニカが原因と明確になり、モニカ仕様だけであるなら当方の環境でも
確認可能であった点、IE6に対応する記述にしても他のブラウザには悪影響が及
ばないという点、をクリアしましたので対応しました。

HTABOX:Applicationに対するHTA互換属性の付加を開始しますが、改めて
singleInstanceって何？を調べると公式ドキュメントは下記のとおりです。

When set to true, the singleInstance property checks the value of the applicationName property before launching an instance of the application.
For this check to be valid, the applicationName property must have a unique value assigned to it.
You can use the applicationName property to identify a single application, regardless of the URL used to access it.

英語力が乏しいのですが、applicationNameが同一な場合複数起動が抑制され
る仕様でよろしいでしょうか。私は今までてっきり同一URL(FILE)が単一に抑制
されるものと思っていました。applicationNameが宣言されずsingleInstance
指定な場合URL自体に単一抑制を行うべきなのでしょうか？これを利用されて
いる方のご意見を伺えればそれに沿った仕様にしたいと思います。

ウインドウスタイル系については互換ではなく、直接WIN32的なスタイル定数
を指定するものとします。あらゆるカスタマイズの余地を与えるためです。

アイコンについてはあらゆる画像をマスクデータを付加したアイコンハンドル
に変換する事も可能ですが、単に面倒なのでICO形式を想定しています。

考えてみるとscrollやscrollFlatという属性がありますから、サイト介入は
必須なんですね、この辺もDOCHOSTUIFLAG定数を直に指定するものとします。

表記方法にも若干工夫が必要だと感じます。なぜならウインドウスタイルや
DOCHOSTUIFLAG定数はHTMLがパースされる前に正確な取得が行わなければなら
ないからです。つまりファイルとして読み、正規表現で確実に抽出できるも
のでなければなりません。私は従来型のエレメントへアトリビュートが満載
されている書き方が好きではありませんから下記のような仕様を提案します。
<HTABOX:Application>
<!--
[Name#hoge]
[Instance#yes] InstanceはNameが存在すればName無ければURLが...
[Icon#hoge.ico]
[Hostui#0x00000001]
-->
</HTABOX:Application>
という形式なら見た目もスマートですし、正規表現マッチも確実です。また
HTML的にはコメントとなりますから、説明文字列を置く事も可能となります。

話は変わりますが、HTABOX内部の仕様が確定したことで、いよいよ共同開発
が可能になります。C++等でビヘイビアやOBJECTを書きたい人、JScriptや
VBScriptでユーティリティークラスや関数を書きたい人、特に後者の場合
OBJECTタグ内のスクリプトエンジンにより堅牢にソースが保護されますので
オリジナルなアイディアが盗用されない形で機能だけを公開する事が可能
です。あぁ.NETアセンブリをCOMDLLとして認識させスクリプトエンジンに
組み込む事も可能ですから.NETプログラマーの方もOKです。

152を書いて思いましたが、JSとVBSをDLL化する機能は必須ですので、今の
作業が終わったらデモしたいと思います。new ActiveXObjectで呼ばれるよ
うに後付のお客さんとしてディスパッチ追加することは単純なわけですが、
ここでは、HTML中のスクリプトサイトと結合した形のスクリプトエンジンを
DLL内に持つ事になります。勿論リリースと判断した場合はDLL内のコードを
独自エンコードしてコード参照を遮断するわけです。

HTML中のHTAタグ互換属性認識でファイルとしてデータを読む事からとても
基本的な仕様を決定します。もし、「それじゃだめだろう」というご指摘が
あれば柔軟に対応しますが、今のところ下記のように考えています。

ファイルコードページはANSI又は1200(0xfffe付きUNICODE)とする。
内部的には先頭2バイトをチェックしchar又はwchar_tとして解釈する。
正規表現文字検索は総て大文字小文字にルーズな状態(CaseInsensitive)で
行われる。パスの解釈は表示されようとしているHTMLファイルを基準とする。
したがってダイアログ中の<HTABOX:ApplicationはダイアログHTMLファイルを
基準とする。

属性抽出正規表現です。どうたら説明するより式を見ていただいた方が早いと
思います。C++内ではVBの正規表現エンジンを使用しています。再文字列評価
されるのでエスケープは余計についています。要は自由に[...#...]を書けます
が、全般にホワイトスペースは除去しません。

Reg1.Search(s, "<HTABOX:Application>[^\\x07]+?</HTABOX:Application>", "i", true);
Reg2.Match(Reg1.LastMatch, "\\[([^\\[]+)#([^\\]]+)\\]", "g", false);

先頭正規表現の[^\\x07]を謎に思われる方もいらっしゃると思いますが、HTML
中の長い範囲に及ぶ開始、終了タグマッチは普通、成功しません。しかし、キ
ーボードから絶対に打てない文字の否定を条件とするとある程度の長さでも
成功するという理由です。

現状での設定属性（commandLine当の読み取りを除く）は下記のとおりです。

<HTABOX:Application>
<!--
[AppName#hoge]-----------------アプリケーション名（タイトルではない）
[Single#yes]-------------------Nameが存在すれば同一Nameの起動を抑制
[Icon#hoge.ico]----------------ウインドウへのアイコン定義
[WindowState#0x00000005]-------SW_HIDEからSW_MAXまでの定数

//=============================================================================
[OuterStyles#0x00000001]--------外郭ウインドウWS_OVERLAPPED等の定数
[OuterStylesEx#0x00000001]------外郭ウインドウWS_EX_DLGMODALFRAME等の拡張定数
[FrameStyles#0x00000001]--------フレームウインドウWS_OVERLAPPED等の定数
[FrameStylesEx#0x00000001]------フレームウインドウWS_EX_DLGMODALFRAME等の拡張定数
上記に対応する旧HTA属性
border,borderStyle,caption,maximizeButton,minimizeButton,showInTaskBar,sysMenu

//=============================================================================
[UiFlag#0x00000001]-------------DOCHOSTUIFLAG_DIALOG等の定数
上記に対応する旧HTA属性
innerBorder,navigable,scroll,scrollFlat,selection
-->
</HTABOX:Application>

こうやってまとめてみると、「定数を直に打ってください」にすると非常に
すっきりしますね。この書き込みでは定数一覧まで含めるとPOSTできません
から省略しましたが、正規表現抽出しますから、定数のみならず、その解説
まで<HTABOX:Applicatin内に置けます。仕様が決まったら削除すればいいわ
けです。結構スマートだと思うのですが。

例えばFrameStylesはデフォでWS_CHILD|WS_VISIBLEです。けしてPOPUPでは
いけません。これはバイナリが更新されたら実行していただければ判ります。
これを安全にBorderとしているのが旧来の手法ですが、それはHTABOXの思想
とは異なります。「総ては必要とするなら許される」これを安全な枠の中に
収めるということはそのまま「できない事を生む」からです。

コンピューターは指定されたウインドウ定数を疑いません。これが本来のプロ
グラミングです。最初は不親切に感じるかも知れませんが、私とてその定数の
総ての組み合わせを試したことなどありませんから、おもがけない効果を生む
組み合わせを皆さんが発見できるかも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログの連続起動時にストールする可能性がある部分
を修正しました。また、実験的に下記設定を行っています。
<HTABOX:Application ID="WIN32">
<!--
DOCHOSTUIFLAG_THEME = 0x00040000
[UiFlag#0x00040000]
-->
</HTABOX:Application>

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。singleInstance等価設定を実験しています。先行インスタンス
が最小化状態な場合に備えてShowWindow(hwnd, SW_SHOWNORMAL);としていますが、
最大化されている場合ノーマルに戻されるのはいやだという意見があれば修正し
ます。
<HTABOX:Application ID="WIN32">
<!--
[AppName#AppName]
[Single#yes]
DOCHOSTUIFLAG_THEME = 0x00040000,
[UiFlag#0x00040000]
-->
</HTABOX:Application>

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。
最小化でShowWindow(hwnd, SW_SHOWNORMAL);そうでなければ
SetForegroundWindow(h);という当たり前な動作に修正しました。

たぶんCOMマーシャリング無しで異なるプロセスへ文字列を送れるのは
WM_SETTEXTとWM_COPYDATAぐらいだと記憶しています。今回はWM_SETTEXTの
通常は使われないwParamに-1が指定された場合lParam文字列を自身に定義さ
れたAppNameと比較し、真なら非ゼロを返すという仕組みです。後続プロセス
は先行トップレベルHWNDを列挙しOuterWindowだった場合上記の問い合わせを
行い、非ゼロが返された場合当該HWNDをShowWindow又はSetForegroundWindow
して自身は終了しています。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。外郭、及びフレームHWNDへのスタイル設定が可能です。
どんなスタイルでもコンピューターが壊れることはありませんが、見えない
又はタスクに無い、とかで終了していない場合が発生すると思います。

その場合タスクマネージャーで確認、終了させる事が必要です。シングルイ
ンスタンスもONな状態ですから、冷静さを失うと実に起こりそうな事態です。

デモでは単にOuterのWS_VISIBLEを入れず、window.onloadでAnimateWindow
しています。

あらゆる場合でウインドウが3重構造であることが確定していますので、HTML
スクリプト中からHWNDを操作するために公開されていた変数を変更します。
外郭　OutHwnd、フレーム　FraHwnd、ドキュメント DocHwndです。
JScriptにはHWNDの概念が存在しませんので内容はVT_I4の数値です。HTABOXは
スクリプトからAnimateWindow(OutHwnd.....等の要求を受け取るとアドレス
へ読み替えています。HWNDにNULLを指定する場合は0(ゼロ)を与えてください。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。Icon、WindowStateに対応し当初考えていた設定要素はすべ
て盛り込まれた状態となりました。OuterはWS_VISIBLEのままWindowStateで
WS_HIDEしAnimateWindowを機能させています。アイコンは前述したとおり単に
SHGetFileInfoでスモールアイコンハンドルを取得しているだけですから正し
いICO形式でなければなりません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。HTABOXAPP.exeを起動すると単純にカレントディレクトリを
基準にファイルダイアログが表示されます。HTABOXAPP.exeはここで指定された
ファイルを実行します。test.htmはそのまま存在しますが、全機能を点検する
ためのごちゃっとしたHTMLにいい加減嫌気がさしてきたので、simple.htmも
用意しました。基本的な機能をすっきりとご覧になれます。

[Icon#hoge.ico]が指定され、EXEにリソース格納された場合のモジュールを
書いていました。ファイルとしてのイメージはそのままリソースから復元で
きる訳ですが、メモリ上のファイルイメージから適切なアイコンハンドルを
取得する為には、複数のアイコンを列挙して...になりそうでしたから、一
時ファイルへ逃げました。EXE生成時は暗黙のうちにEXE用に格納されたアイ
コンデータとするなら普通のRT_ICONな展開ですからいいんですが。

まだ、ダイアログ側へのHTA互換属性設定は追加していませんが、ダイアログ
のシングルインスタンス設定は意味がありませんから、指定があったとしても
無視する予定です。

現在のHTABOXのコア部分の動きを眺めていると物が出来上がるってこういう
ことだなぁーっと思うんです。すごくテクニカルに感じて興奮しているうち
は、まだまだ完成していない証拠で、こんなの眺めていたって単純で面白く
無いじゃんくらいにこなれてくれば完成という展開です。ついつまらないも
のですかその先に興奮を求めてしまいますが、今度こそきちっと解説を書か
なければと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログ系<HTABOX:Applicationの設定が可能となりまし
た。ファイルダイアログをキャンセルした場合のエラーを修正しました。

確かにCOMプログラミングというのは、コンテキストという一見、目に見えな
い問題と対峙しなければなりませんし、HWNDのコンテキストに至ってはある程
度負荷をかけた状況でないと正体がつかめなかったりしますが、人様の書いた
バイナリをまるで自分が書いたかのように使える点が非常に強力です。COMの
ルールでは要求したインターフェース（同じ関数セット）を持っていれば、全
ては本物と認識されます。ですから分析したい対象と同じ関数を持ち、単純に
呼び出されたら中継するだけで全挙動を詳細に観察できます。Windowsの中で
これ無しでは成り立たないほどキーポイントとなる技術でありながら、今は
使われない的表現を見かけると単に「対クラック工作」と感じてしまいます。

プログラミングにはいろんなアプローチに仕方がありますし、最終的にCPUが
解釈するコードが生成され、その動作が要求時間内に完結すればいいわけで
すが。もし、他のプログラマーより気の利いたものを書けるようになりたいと
思ったら意識を改革することです。これは極めて簡単なことです。

「あなたはなぜ高いお金を払ってピースの多いジグソーパズルを買うんですか？」

つまり、プログラミングや既存バイナリの解析をホビーだと捉えれば対象が複雑
であればあるほど克服した時の喜びは大きいはずです。そして貴方は誰も組めない
規模のパズルを平然と組めるプログラマーになるでしょう。

HTABOX3.00の全体構造を決定します。現状のHTABOXAPP.exeは単にクリックで
ファイルダイアログが表示され、メイン実行対象HTMLファイルのドロップで
EXE生成動作を行う単純なものとします。これを「HTABOXコア」と呼称します。

HTABOXHLP.exeは同一C++コードから生成されますが、単にクリックされた場合
実行可能ヘルプを表示します。HTABOXHLP.exeは同一コードから生成されますの
で、完全にコア同等の実行能力がありますが、ドロップや引数には無関心です。

拡張DLLサンプルとして、また、HTABOXHLP.exe実行時の関数一覧表示用として
データバインドDLLが添付されます。ただし、レジストリ登録、解除機能はも
はや必要ありませんので削除されます。つまりHTABOX環境専用となります。

HTABOXは完全なサイドバイサイドでシステムが完結し、その状態でデバッグ可
能ですから、MSHTA、WSHとは無関係なものとなります。

ソースコードエンコードはHTABOXENC.exeが提供するエディタ上で行います。
このEXEは納入毎に単品でビルドされすべてが異なるバイナリイメージを持つ
ものとします。HTABOXENC.exeは原則として製品版にしか添付されませんが、
このスレッドに関係していただいた方々へのお礼として一時期公開されます。
このときサーバーはGET要求に対し、個別のzipを送信します。用意されたzip
がすべてGETされた場合この提供は終了します。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。未格納状態でのコマンドライン起動を追加しました。原則
的にHTABOXAPP.exeへの引数はEXE生成と認識する予定ですが、コマンドライン
での実行HTML指定及びHTMLへの引数を渡すルールとして最終引数に'cmd'を付
加していただくものとしました。同時にWIN32へArgc変数、Argv配列を追加
しました。HTML側には'cmd'オプションの前までが引数として提示されます。

詳しくはデモ内のcommand.bat、test.htmのコードをご覧ください。

全く説明不足で、最近HTABOXを目にしていただいた方には何のことやらとい
う感じだと思いますが、一応これで製作者自身が使用するツールとしてのHTML
アプリケーション作成、実行は行える環境がそろったと感じています。
尚、HTABOXのサイドバイサイドシステムは全く他のOBJECTタグ生成やActiveX
生成を妨げませんから、何かを捨ててHTABOXを選択する必要は無く、従来の
コードへHTABOXの機能を追加する為にそのまま移行できると考えています。

ヘルプの構造に関係するものですから、最も軽量で安定な埋め込みHTMLコン
トロールを作るには？ということを考えていました。従来はドキュメントを
直接HWNDへ埋め込むことだけをしていたのですが、常にそれ一辺倒だとコン
テキストを外す恐れがあることを痛感したものですから、最軽量なモーダル
を元に新たなHTMLコントロールを設計しました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。前述のコントロールをquick.exeとしてご覧になれます。
単一のウインドウへ単一コントロールではあまり軽量な実感が湧きませんが、
もし、アプリケーション中に数十個みたいな状況になったときにその軽量さ
が生きると思います。

あえて純粋なWIN32でアプリケーションを書く場合ウインドウ上のコントロー
ルもさることながら、ダイアログをいちいちテンプレートで定義することに
嫌気がさします。じゃぁ動的に...を試みると輪を掛けて面倒なことになりま
す。「HTMLダイアログを使う」これは正しい考えだと思いますが、もっさり
した起動感になります。これを解決する手法として枠だけのダイアログテン
プレートを用意し、内部に最軽量なHTMLコントロールを生成する。HTMLのパー
スが完了したらbody直下のtableサイズを検出してダイアログのサイズを決定
し表示する。というシステムを以前から試行しています。ダイアログテンプレ
ートと同等なレスポンスとは行きませんが、HTMLはモニカにキャッシュされま
すから2回目以降の表示は同等の切れ味となります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。quick.exeを並列2ページ構成にしてみました。spy++で見れ
ば、ダイアログでありながら総てのHWNDが同一なスレッドに整列してる事を
確認できると思います。

ヘルプはタブ2ページで、先頭ページはダイアグラム風にノードが表示されて
いて、各項目をダブルクリックすると読み取り専用エディタが出現し解説に目
を通すと同時に実行できる構造です。2ページ目は関数一覧テーブルと簡単な
著作表示、連絡先の表示にします。

HTMLを活用しましょう！と呼びかけている訳ですから、そのパワーと可能性を
ヘルプシステム自体で表現する事が目的です。ドラッグで移動できるHTMLエレ
メントからリッチエディットが出現してくる様は、なかなか次世代的で新鮮だ
と感じています。これはエレメントビヘイビアが個々にリッチエディットを
生成することで実現されます。明日はそのデモをお見せできるまで仕事を進め
たいと思います。

あぁ3ページ目が必要ですね。ヘルプを全部1ページとして閲覧するためのペ
ージ。これにはリッチエディットを使い、各項目は個別HTMLドキュメントの
連続でできているというのが、今回の技術の検証にもなります。リッチエデ
ィットへHTMLドキュメントを埋め込むと面白い現象が起こります。OLE的には
当然なのかもしれませんが、表示対象になるまでスクロールされないとパース
が保留されているんです。ですから膨大な数のHTMLが埋め込まれていたとして
も、表示されている部分のパースで制御が返ります。この3ページ目が私の集大
成になるかも知れませんね。

いつか終わりが来るとは思っていましたが、そろそろ私の情熱も尽きそうです。
ハード階層も含めたコンピューター全般の範囲から見れば私が知っている事、
私ができる事はほんの僅かなのですが、自分が「かくありたい」と考えていた
水準には達した気がします。「目標低すぎ」と言われそうですが、ブラウザを
ゼロから書くというような努力家でないことは自分自身が一番承知しています。

それにしても、ネットワークの向こう側なんて本当に人間がいるのか、犬や猫
がいるのかさえ判別不可能だというのに、私の書く役に立たないバイナリを動
かしていただけたことを想うと夢のような環境でした。同じように夢に向かっ
て孤軍奮闘している方は多いと想いますが、私のように恵まれている方は多く
ないだろうと思います。

MSHTMLプログラミングについて私なりにまとめます。

MSDNではMSHTMLという表現はIE又はWebBrowserの使用状態を指します。両者は
公衆インターネット接続を前提としているため、重いオブジェクトとなります。
もし、そういった目的のアプリケーションを開発するならこれらを選択すべき
ですが、この場合、基底にあるHTMLエンジンだけを利用することは困難です。

軽量なMSHTMLインスタンスとしてHTA系（HTA及びHTMLダイアログ）が挙げられ
ますが、これはMSDNでのMSHTMLにはあたりません。なぜならプログラマーが用
意したサイトではなく、既製品として用意されたものが使われるからです。振
る舞い自体をカスタマイズするのではなく、単に使ってくださいというスタン
スなわけです。

私がやりたいのはHTA系の振る舞いを代える。又は、その基底で行われている
動作を独自に実現するということですから、全くアンドキュメントな世界に
突入します。書きあがってみれば、こんもんなんで1年か2年で書けなかった
のかとため息が出るコードですが、これで、最も自由度が高く軽量な状態の
HTMLエンジンを手にすることができたわけです。

私はIE9あたりからMSHTA.EXEはIEに添付されなくなるのではないか、と考え
ていたのですが、添付されていたのは意外でした。現在は単に義理立てして
HTML Application Host Window Classを生成していますが、もはやそうでな
ければならない理由は消滅しました。MSHTA,EXEが無くなってもMSHTML.DLL
の仕様が大きく変更されない限りHTABOXは動作することになります。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を公開します。これはbです。脱HTAを実践した結果です。コンテキストの相違
が発生したのか、スクリプトからのwindow.resizeToでメッセージが生成され
ないところが本物と違いますが、あとはSPY++で確認しない限り、見分けはつ
かないと思います。今のところこちらをアプリケーションウインドウにする予
定はありませんが、MSHTA.exeが無くなったとしてもHTABOXがあれば大丈夫です。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。
改めて素なHTMLとダイアログでテストしてみるとダイアログ内部からのresize
要求は無視される仕様なんでね。知りませんでした。まぁそんなつまらない規
則を受け入れる必要も無いわけですからHWND操作すればいいわけです。従来の
SetWindowPosに加え、引数が単純なMoveWindowを追加しました。HTABOX上では
将来の拡張に備えMoveWindow、SetWindowPosの使用をお勧めします。

あぁ自分で書きながら「MSHTA.exeが添付されなくなったら」とMSHTML.dllに
「HTA生成関数が無くなったら」がごっちゃになった書き方な事に気づきました。
両方が一緒に無くなることを想定しての話です。もしMSHTA.exeだけが無くても
関数が存在すればHTABOXは変更すら必要なく動作します。もし、両者が同時に
無くなっても、HTABOXはHTAに依存しないウインドウへ移行する準備ができてい
るという事です。

HTMLダイアログをベースとしたウインドウにおけるresize問題はもっと当た
り前な解決策が存在しました。あんたはダイアログですか？と聞かれたら
「いいえ」と答えるだけです。IID_IHTMLDialog要求にS_OKを返さないだけで
ドキュメント側はトップレベルウインドウだと判断します。ただし、これを
行うとwindow.close()時の動作が変わってしまうことを懸念しましたが、影
響が無いことを確認しました。

189は早合点でした。コードが混乱しているだけで、IID_IHTMLDialog要求
への応答とは無関係にダイアログであることを認識してますね。まぁresize
系関数を上書きして気づかせないという方法もあるわけですし、この辺はい
つか仕様として確定させたいと思います。

ちなみにWebBrowserでセキュリティーをコントロールしても擬似HTAは生成
できるのですが、こうなるとあまりに当たり前すぎて何のために5年もの時間
を費やしたのかという自己否定に繋がりますからやりません。（笑い）

もし、HTA系{3050F5C8-98B5-11CF-BB82-00AA00BDCE0B}自体が提供されない場
合は、少々重くてもこれを使うということになるでしょう。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。各ウインドウ終了時に若干未開放なメモリ領域が存在した事
への修正を行いました。WebBrowserでのテスト後にHTA系をテストすると、明
らかにこちらのほうが切れがいいですね。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。
軽量HTMLコントロールの威力を確認するためのものです。単に実行するとタブ
コントロールで20ページ分のHTMLを切り替えるウインドウが生成されます。
面倒なので同じHTMLですが、スクロール量を変えてページを切り替えれば、
正しく再現されていることが確認できます。ここで問題なのは生成速度です。
つまり、IEを20個起動するのか、HTMLダイアログを20個表示するのかの違い
が現れるわけです。

HTABOXのヘルプ冒頭のページで実際に各機能を動かしてもらうシステムを書
いているわけですが、実際のイメージはこんな感じです。
ttp://kuroda.bglb.jp/htabox/node.png
先の機能が無い箇所を削除して実際に遊べる状態でアップする予定です。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。前述のデモです。単にクリックで動きます。
まず、メニュー兼ツールバーは既成の概念を打ち破ったものになります。
ビヘイビアで相互に表示、非表示を連携し合うDIV中にボタンを配置したテー
ブルがある状態です。これらの生成に画像は一切使わず、すべてVMLで動的に
生成しています。

BODY領域の右クリックでノードを作成できます。実際にはノードの作成は私
が行い、ユーザー側はドラッグしたりクリックしたりになりますが、開発モー
ドですから、作成してください。

といって実際に動かしたら、ちょっと不具合がありましたので、一旦引っ込
めます。

Microsoft Visual Studio上ではDebug,Releaseとも問題なく動作するのですが
、単独で起動すると、激しくメッセージ同士が衝突しているような状態なので
とてもお見せできるところに至っていませんでした。今日も眠れない夜になり
そうです。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。ビヘイビアの再描画動作内で更に再描画の
要素となる記述があったために表示が乱れていましたので修正しました。

BODY部の右クリックで新たなノードが生成されます。複数のノードがあれば、
ノード上のCTRL+クリックで子の候補としてグレーになり、次にクリックされ
たノードを親と認識してラインを締結します。ノードのダブルクリックでタ
イトル変更、エディタの起動を可能とします。

さすがに複数のエディタが活性化した状態では、重くなりすぎますし、場合
によってはクラッシュの要因ともなりますので、自身エディタが操作されて
いない場合、DCへイメージをキャッシュして単なる画像になるところがみそ
です。しかも、画像化した後で未表示だったエディタ領域が表示されなけれ
ばならない局面もありますから、単なるDCコピーではなく小規模な印刷を行
っています。

これはあくまでもデモンストレーションでエディタが機能するわけではあり
ませんが、HTMLをベースとし、ネイティブなコンポーネントを加えることで
従来のアプリケーションの概念を覆す、より直感的なインターフェースを設
計可能であることをご理解いただけると思います。

役に立つプログラミングの話というのをたまに折り混ぜないと、クレームが
来そうですので、COMプログラミングの本質についてすこしだけ書かせてくだ
さい。

>>144を見て気づく人は気づくはずですが、私はオブジェクトの消滅を常にref
レベルで監視した開発を行います。たとえ何千個のオブジェクトが生成されよ
うが、全オブジェクトがdelete thisを正しく実行しない場合どこかが間違って
いるのです。ですから参照カウンターを容易にモニタできない環境でCOMプログ
ラミングを行うのは目隠しをして森に入るようなものです。

通常の言語においてオブジェクトとは自らの環境で使う目的で生成されます。
常に主体は自身の言語です。オブジェクト（データや振る舞いが記述された
データ領域）は　String str("hoge");　のような形で生成されますし、コー
ドが生成スコープを外れた場合、自動的に破棄されます。これは大変判りや
すい機構ですが、もし他言語、又は他環境へオブジェクトを提供する場合は
足枷になります。

相手の呼び出しコンテキストでオブジェクトを生成し、相手がそれを必要と
しなくなった時点で自動的に破棄される。これがCOMの本質です。
生成について私は下記のようなコードを多用します。

return((new Hoge())->QueryInterface(riid, ppvObject));

相手呼び出しコンテキストでnewを行い要求GUIDへのQueryInterfaceを行う
ことでrefを上昇させます。

消滅はRelease呼び出しの累積によってrefがゼロになった時です。

if(InterlockedDecrement(&ref) == 0) delete this;

ここまでの話は単純ですが、現実はもっと複雑なものとなります。
もし、AとBのオブジェクトが互いを必要とし、握り合っていた場合に何が起こ
るか。単なるアドレス参照としても安全なのか。生成と消滅を繰り返すべきか。......

この何重にも夢がまた夢を見るような複雑さを持つCOMの世界で、唯一の指針
それが参照カウンターの監視です。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。ヘルプのサンプル実行部のデモです。ウイン
ドウ全体のリサイズ動作が行われた場合にフォーカスの所在が曖昧でしたが、
必ずエディタのフォーカスを奪い画像化する修正を行いました。曖昧さは排
除できたのですが、ちょっと重い方向へ向かったかも知れません。

2ページ目は関数一覧、3ページ目は単にツリー付エディタで読み取り専用
という展開で作業を進めています。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。HTA及び軽量コントロール上ではこの手法に
よって生成されたリッチエディットへ1バイト系のキーメッセージが到達し
ていないことから、直接ドキュメント埋め込み手法を再検討し、ref管理を
厳密にして採用しました。正規なフレームとドキュメントの組み合わせでは、
余計なメッセージがフィルタリングされているのかも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。直接ドキュメント埋め込み手法を改良して、
ウインドサイズ変更時の微細なガタツキを解消しました。ウインドウの描画系
メッセージ処理に無理が無いかを確認する方法は極めて単純で、シャカシャカ
サイズ変更を繰り返して、CPU稼働率が逼迫しても滑らかに表示されるかを見
ることです。従来この部分がクリアできずに本採用していなかったのですが、
そこを解決できたと考えています。従来TZB構想がありましたが、これで最軽
量にOuter->Tab->[Doc,Doc,Doc,.....]というタブスタイルのHTMLアプリケー
ションベースを設計できるでしょう。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。直接ドキュメント埋め込み手法の数量的チェックです。
ノード生成、エディタ出現可能ページを20ページ一度に表示し、各ページの
動作が円滑に行えるかを検証しています。ちなみに当環境では初期占有mem
が20Mbエディタ起動で36Mbでした。IEは単なる起動で42Mb占有しますから、
メモリー的にも軽量だと感じています。

埋め込み専用HTMLウインドウの性能が思った以上にいいものですから、本体
HTABOXにタブ機能を追加したいと思います。まず、単純化するため動作途中
の追加、削除は無しにします。ですからブラウジングではなく、複数のツール
をタブで切り替える感覚です。また、複数のファイルを引数指定するのは美し
く無いですから、主たる実行HTML中の<HTABOX:TabCtrl/>でタブが生成される
動作を想定しています。

これに伴いメニュー、ポップアップメニュー、ツールバー、ステータスバー
はアプリケーションに定義されるのではなく、ドキュメントに定義されるこ
とになります。つまりタブを切り替えると、切り替えたページ中にそれらの
定義が存在すればその内容が反映されるというルールを導入します。実際に
ページ毎に総てを再定義することは稀でしょうが、ポップアップなんかはペ
ージ固有でないと不自然ですから、いっそこのと全部を統一しようと思います。

何年も気に掛けていただいている割には、見た事のあるものが安定化してゆ
くだけでしたので、HTABOXならではの機能をお見せできればと考えています。

日付が替わる前にはめどがつくかもと思っていたのですが、あれこれと問題
を潰しているうちに、朝が来そうです。ちょっとだけ新しい試みとして、本
来フレームHWNDのメッセージが走るループにTab上のすべてのフレームメッセ
ージを走らせてみようと思います。私の予想では「スレッドが同一ならメッセ
ージループを共有しても衝突は起こらない」なのですが、どうなりますか。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。test.htmにタブコントロールデモが追加されました。
タブ生成の仕様は下記の記述で行います。
<!--タブ定義用-->
<HTABOX:TabCtrl>
<!--
[id1#tabs/Page1.htm]
[id2#tabs/Page2.htm]
-->
</HTABOX:TabCtrl>
[ドキュメントコントロールID # 相対パス]が指定する内容です。
これを定義できるのは表示開始ページのみで、当該ページスクリプトスコープ
へ指定IDのディスパッチとしてタブ表示されたdpcumentを参照可能です。
デモでは全タブページのbgColorを変更しています。

タブ側にメニュー等の定義があった場合の切り替えは今書いています。また、
この柔軟なシステムを実現するにあたりHTML側からのresize系未サポートと
なります。デモのリサイズは外郭ウインドウに対する。
WIN32.SetWindowPos(OutHwnd, 0, 0, 0, 300, 300, SWP_NOMOVE|SWP_NOZORDER);
に変更されています。

将来は総てのページを独自に生成したものにする予定ですが、今回は既存の
HTAウインドウへモーダルダイアログを非同期に生成して、同一スレッドであ
りながら、スレッドをブロックしないという発想で構成されています。まずは
既製品ウインドウでないと、予期せぬ結果となった時に混乱するだろうという
判断からです。タブを使わなければ従来のHTABOXなわけですから気が楽です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。タブページでのメニュー、ツールバー、ポップアップ、
ステータスの再定義を可能としました。test.htmを実行すると最終タブに
last.htmが表示され、当該ページ表示後、先頭ページが再度表示されるまで
再定義されたメニュー、ツールバー、ポップアップが有効となるデモです。

これに伴いメニュー系説明文字用コールバック関数にテーブルインスタンス
が渡される変更が行われました。コールバックは必ず先頭ページドキュメント
に対して行わます。（各ページに記述するのは面倒でしょうから）

//アプリケーションメニュー選択コールバック
function window.onMenuSelect(obj, i)
{
STATUS.SetText(0, obj.cells[i].title);
}
//ポップアップメニュー選択コールバック
function window.onPopupSelect(obj, i)
{
STATUS.SetText(0, obj.cells[i].title);
}
ステータスバーも再定義できますが、上記コールバックの関係上先頭ページ
で定義して、そのまま使う方が無難だと思います。

当初既存HTABOXへのタブ導入はスパゲッティな自爆パターンかなぁ？とも思
ったのですが、思いのほかスムーズに進行したと思います。タブに挿入する
HTMLインスタンス生成モジュールも、複数パターン用意し切り替えながら結
果を見るという作戦が効を奏したようです。もうこれだけCOMの参照関係が入
り組むと、だめなパターンの要因が何なのかを追求するのは時間の無駄で、
それとは性格の違うものを用意し、最終的な終了がクリーンだったらOKくら
いのアバウトさも必要だと感じました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。最終タブページタイトルがアプリケーションタイトルにな
る不具合を修正しました。非力なIE8ノートでテストを行ったのですが、思い
のほか軽量なのには驚きました。先頭ページの表示後にブロックせずタブペ
ージをパースすることろが軽快さを演出しているようです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。タブ機能追加に伴い行われたコードを再検証しメモリ開放
を厳密なものとしました。説明不足ではありますが、これまで定めた仕様は
十分に実用的と判断していますので、大きく変更されることはありません。
どうぞ、存分にHTMLアプリケーション作成をお楽しみください。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。メモリまわりは概ね良好なので、速度方向の最適化を行っ
ています。test.htmは起動時に無駄なエフェクトが入ってますから、本来の
クイックな起動を見る為のquick.htmを追加しました。開発時は途中経過を
確認するための記述が存在していますので、リリース時に無効化する#if
を整備すればさらに切れが鋭くなるはずです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。各タブページはdialogArgumentsで呼び出し元である先頭
ページのドキュメントを参照できるものとしました。
最終ページから先頭ページのbgColorを変更するデモを追加しました。

まったく手前味噌な話ですが、今回の機能追加を短時間でこなせたことで、
今までのもやもやした状態から完全に突き抜けた気がします。タブがどう
のこうのではなく、MSHTMLを利用した何らかの発想が存在し、それを実現
するための戦略を練り、効果的な実験を行って成果を得るということに必
要な要素をすべて手にできたと思います。普通は今回のような追加を行う
とソースは肥大化し、複雑になるはずですが、実際はその逆だったのです。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。機能はbではないzipと同じですが、こちらは
全ウインドウを自作HTMLウインドウとしたバージョンです。ビヘイビアでリッ
チエディットを生成した場合既成のHTMLウインドウでは何らかの制限がかかっ
てしまうと認識しています。IHTMLElementDefaultsにはcontentEditableとか
それっぽい設定項目が存在するのですが、まだ勉強不足で克服できていません。

これが既成でないHTMLウインドウだと問題なく動作することから、私個人として
はこちらを多用することになるだろうと思います。自作した場合window.closeは
空ですから、UTIL.Close()という関数を追加して対応しています。

今すぐ手をつけるわけではありませんが、ドキュメントの外側に存在する要
素については一通り完成しましたので、ドキュメント中に何でも埋め込める
状態を目指します。場合によっては別プロセスで動作しているChromeやFoxも
埋め込みの対象となるでしょう。それをタブ追加すれば統合的なアプリケー
ション環境になるわけです。そのために何でも問題なく埋め込める柔軟なHTM
Lウインドウが必要になりますから、この全自作ウインドウが何かを大きく外
していないことが判明したら、HTABOXのウインドウはこの手法に統一される
と考えています。

最新のhtabox300のタブを使用しないウィンドウで、
メニューをクリックした際、htaのエラーダイアログではない表示で
DateTime = 2012/10/28 21:39:03
File = .\main.cpp
Line = 1581
Description = InvokeEx : onMenuSelect
Error = メンバが見つかりません。
と出た後

hta標準のエラー表示で
ライン:　88
文字:　　2
エラー:　'APPMENU.cells[...]title'は、Nullまたはオブジェクトではありません。
コード:　0
URL: 　　simple.htm
と出ます。
出来ればご検討下さい。

書き忘れましたが、OSはXPでIEは8です。

>>224
いつもありがとうございます。タブ機能の追加によってやや混乱した部分が
あると思われますので、点検を行います。つい新たな機能を追加すると、そ
れを使わない環境でのチェックがおろそかになってしまいます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。タブ対応に伴いメニュー系説明文字列のコールバック関数
は第一引数にテーブルオブジェクト、第二引数にインデックスを受け取る形
式に変更されましたが、添付サンプルHTMLに従前の引数を受け取る関数が書
かれていたためと判明しましたので修正しました。ありがとうございました。

あと、ツールバーにボタンが沢山あってウインドウ幅が小さい場合、ページ
ャーコントロールが機能して自動的にスクロールマークが出るのですが、現
状のタブスタイルと併用した場合、ページャー側が機能しません。これはち
ょっと根が深い問題ですので、認識はしていますが対応は先送りしています。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。外見的な変更はありませんが、各種ウインドウの想定しうる
総ての組み合わせで、正しく開放が行われることを確認したバージョンです。
直接ドキュメント埋め込みウインドウは、MSHTMLのフック動作のようにシビア
なものですから、逆に不安定な部分を確実に指摘してきます。そこで露呈する
曖昧さを修正しましたので、全体に安定感が増したと思います。

アップした後に、動作を確認したんですが、最初の一回だけダイアログのツ
ールバーイメージを取り損ねている状態を確認しました。2回目から発生しな
いところを見ると、タイミング問題だと思われますので、確実な方向へ修正
する予定です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログ起動時に、行っていた余計な動作を排除して従前
に戻したところ良好なようです。同じような処理だと、つい内容を統一したく
なるのですが、各ウインドウにはそれぞれの性格がありますから、個別にチュ
ーンされた記述が必要なようです。

プログラムの更に上記に位置するものが「規格」や「仕様」です。特定の仕
様に依存するいうことは、最悪の場合それが破棄されればプログラムは無に
帰することになります。例えばデータバインドTDCのエキスパートだったと
してもTDC互換COMが書けない限り「キルビットしました」というアナウスだ
けで他の方法を探す必要が出たわけですし、MSHTAのエキスパートだったと
しても「危険ですから添付しません」と言われればそれまでな訳です。

今日は結局一日「低水準HTMLウインドウ」の安定化に費やしました。私は
HTAやHTMLダイアログの更に低層にある普遍的な規格の上でなければ、安心し
て開発できる環境には成り得ないだろうと考えますので、これは大変重要な
課題でしたし、それを克服できたことに安堵しています。要はそれがやりた
かっただけです。それだけの事にこれだけ時間がかかってしまいました。

長大なドキュメントの高速パースは単純なロジックで実現可能であることに
気づきました。例えばIMGタグは全画像をロードして完了を報告する訳ですが、
HTML全体の構築に必要なのはその縦横サイズだけなわけですから、さっさと
大きさだけを報告する賢いIMGタグがあればいいだけです。実際の画像データ
はバックグラウンドで読むか、ユーザーがスクロールして当該部分の表示が
要求された時点で行っても、ローカルファイルか、リソースからのロードで
したら、さしたるタイムラグにはならないだろうと思います。

今日は焦りとは裏腹に、あまり前に進めない日になりました。画像とエディタ
のプログラミングはいやというほど勉強していたつもりでしたが、インストー
ルフォントに影響されないドキュメントを目指すと勉強不足な点が露呈してし
まいました。当初は本文で使用するフォントのサイズをあらかじめ統一して、
独自プロトコルで画像転送しようとしましたが、本文のみとはいえフォントが
限定されるのはハンドリングが悪いですから、表題毎の画像として処理する
ためには？の方法論でちょっと悩んでいます。

画像処理で避けがたい問題が、画像の大きさと、確保可能なメモリだと思いま
す。録音の初期が無圧縮なPCMでなければならないように画像処理の初期段階で
は無圧縮なビットマップ領域を確保しなければなりません。ドキュメントの
ようにその大きさに制限を加えたくない対象の場合、確保できなかったらとい
う処理が必須となり、これが煩雑さを増します。

そこで画像データの蓄積が可能な拡張メタファイルを保険として導入して、
各セクションを保存し、当該領域のビットマップ用メモリが確保できた場合
はPNG変換して保存、できなかった場合はそのままEMFとして保存というよう
な考え方で当初の目的を達成できました。本当はそのままEMFを使えればもっ
と楽なのですが、再生時にGDIファンクションはインストールされたフォント
しか表示しないでしょうから、フォントも画像になっているファイルでなけ
ればならなかったのです。

HTABOXで使用している総てのHTMLウインドウはIInternetSecurityManagerで
任意なセキュリティーゾーンへ限定可能な柔軟性を持っています。タブ装備
したHTABOXを眺めていたら「いつも見るページ限定ブラウザ」としても使え
るんじゃないかと感じましたので、HTABOX:Application内にSecurity項目を
新設したいと考えています。ただし、アプリケーション用という性格を優先
させ、デフォは何でもあり、設定されたら制限というスタンスになろうかと
思います。

私は速度が要求されない部分ではC++内部でスクリプトを偽装したCOM呼び出し
を行います。理由はエラーをトラップしやすい事です。エラーが起こればその
内容をクラッシュ前に表示できますから使っている人が内容を報告してくれる
可能性が高くなります。生インターフェースによる呼び出しでも返却HRESULT
値でエラー内容は取得できますが、いきなりハングしてそれっきりという状況
を招く恐れがあります。

IDispatchPtr fso("Scripting.FileSystemObject");
if(DInvoke(fso, L"FolderExists", DISPATCH_METHOD, dir + "\\img").boolVal) DInvoke(fso, L"DeleteFolder", DISPATCH_METHOD, dir + "\\img");
DInvoke(fso, L"CreateFolder", DISPATCH_METHOD, dir + "\\img");
IDispatchPtr Fold = DInvoke(fso, L"GetFolder", DISPATCH_METHOD, dir);
IDispatchPtr Files = DInvoke(Fold, L"Files", DISPATCH_PROPERTYGET);
IEnumVARIANTPtr Enum = DInvoke(Files, L"_NewEnum", DISPATCH_PROPERTYGET);
_variant_t File; while(Enum->Next(1, &File, NULL) == S_OK)
{......}
上記で多用されるDInvoke関数は可変個のバリアント引数を受けて朴訥に
GetIDsOfNamesかGetDispIDを行いInvokeかInvokeExを行います。したがって
速度的には不利ですが、ソースはスクリプトそのものになります。ですから
私が書く環境においてはスクリプトのネイティブコンパイルは既に実現され
ているという言い方ができるかも知れません。

速さというには常に危険又は誤りの原因が不明になるリスクを伴いますから
アプリケーションの寿命中に何十回か程度した起きないだろう事の為にハイ
リスクなコードを置く必要はありません。同一な言語環境の中でその辺を柔
軟にコントロールできるC++は極めて強力です。ただし柔軟であるが故に、
「C++内に自分なりの言語を作る」くらいの覚悟がなければなりません。

IMGタグ偽装は効果的でしたので、HTABOX自体に標準装備したいと思います。
<HTABOX:SmartImg src="hoge.jpg" width="1000" height="2000"/>
を受け取ると当該エレメントは1000*2000のサイズだけを主張します。もし、
当該エレメントが表示領域にかかった場合、自身HTML中のHTABOX:SmartImgを
imgに置き換えたエレメントを内部に生成します。また、表示領域から逸脱し
たと判断した場合内部エレメントを削除します。

昔の書きかけ取り説を全項目画像化して表示すると、100Mb超のメモリを消費
していましたが、この賢いIMGタグを使うとアクティブな画像のサイズにもよ
りますが、画像なしの場合の15Mbから数Mb上昇するだけで全体を閲覧できま
した。当然高速にスクロールすれば若干読み取りラグが生じますが気になら
ない程度です。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。
HTABOXのヘルプエンジンウインドウで「高速.htm」と「通常.htm」の表示
を比較するデモです。HTABOXAPP.exeを単に実行するとファイルダイアログ
が表示されますのでいずれかを選んでください。表示される内容については
全くの実験用画像と解釈してください。「高速」は、文字通り高速に表示さ
れ、タスクマネージャで消費メモリを監視すれば20Mb程度であることが確認
できます。「通常」は全画像がパースされるまで表示されず、消費メモリは
100Mb程度になります。

とても小さなアイディアですが、長大な画像ギャラリーだとしても軽量な単
一ページにできますので、従来のHTMLの欠点を補う画期的な機能だと思いま
す。

尚、エレメントが表示領域にあるのかを取得するためにIHTMLPainterOverlay
を実装していますが、MSDNにこれが有効なIEバージョンの記述を発見できませ
んでしたので、IE7より前のバージョンでは機能しないことが予想されます。

>>244
IE6でも動作するようです

>>245
ご報告ありがとうございます。さらに進展させればHTTP上のストリームを中継
して、表示されてない画像等のロードを保留させる事も可能かなぁなんて考え
ています。

HTABOX:SmartImgを追加したことで、HTABOXという狭い範囲ではありますが、
閲覧側のインストールフォントに無関係なドキュメント表現が可能となりま
した。夢がまた一つ実現した事になります。メリットは外観が美しいだけに
留まらず、カジュアルなコピペを抑止する効果もあります。例えばソースコ
ードを含めた解説を画像化した状態で公開します。内容が確かで有用な事は
確認できますが、ソースコードはコピペできません。テキストな状態のソー
スコードは有料で提供するというようなビジネススタイルも考えれます。

HTABOX:SmartImgのデモで興味深いのは、何度も全スクロールを繰り返すと、
「どうせ削除したら、また生成するんだろ」とIEが予測してメモリが開放さ
れなくなることです。これは実にありそうな話で、確実にエレメントの削除
を反映させるためにはwindowのresizeが必要なように見えます。つまりMSHT
ML的にはresizeな状況を作り、HWND的にはサイズが変更されていないなら完
璧なシステムになりそうです。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。HTABOX:SmartImgのメモリ開放を確実なものへ
修正しました。この問題の原因はIEが賢いのではなく要求の連続でキューが飽
和しているだけだと推定されます。したがってHTML側のコンテキストからいか
なる工作を行っても効果はありません。いわば駄々をこねている状態です。

そこで大人の対応は、システムコンテキストでドキュメントの再評価を促すこ
とです。今回は１秒間隔のタイマー割り込みを設定して解決しました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。本体HTABOX側でもHTABOX:SmartImgに対応しました。表示中
ドキュメントへの割り込み間隔は10秒とし、タブで非表示となるドキュメント
は必ずエレメントの再評価が行われるものとしました。実験はしていませんが、
たとえ数千の画像が並んでいたとしてもパースは瞬間的に終了し、表示されて
いる画像の分しかメモリを消費しないと思います。

249に「駄々をこねている状態」と書いて、まさしく私の4年間はそうだった
と苦笑いしてしまいました。スクリプトをカスタマイズすることはスクリプ
ト自身にはできず、HTMLのルール自体をカスタマイズすることもHTMLからは
できません。スクリプトの言語仕様やブラウザの仕様にため息がでるならば、
それらが生成、動作する土俵の上で勝負するしかありません。それに気づい
たこの1年間はたとえ貧しくとも私にとって至高の時間だったと思います。

HTABOX既存のHTABOXが提供しているダイアログは、あくまでサブウインドウ
というコンセプトですから、ダイアログ内でのタブ表示さえ可能です。それ
が重苦しかったら標準ダイアログをどうぞというスタンスでしたが、標準ダ
イアログの人を小馬鹿にしたようなIEアイコンとステータスバーは到底許せ
ませんから、当該部分をハックした軽量ダイアログを提供できそうです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。軽量ダイアログのデモが追加されました。関数名、引数は
本当のshowModalDialog、showModelessDialogと同じですが、引数の省略は
できません。この関数はWIN32ではなく、ファイルダイアログ等を各ドキュ
メントコンテキストで実行するUTIL名前空間に存在します。デモでは下記コ
ードで呼び出しが行われています。
UTIL.showModalDialog('dialogB.htm', document, 'status:yes');
UTIL.showModelessDialog('dialogB.htm', document, 'status:yes');
status:yesでデフォルトのステータスバーが出現した場合、単一区画な
シンプルステータスバーで上書きしています。このステータスバーへ文字列
を設定する関数はUTIL.PutStatus('何らかの文字列');です。

UTIL名前空間は軽量な設計が成されていますので、HTABOX関連ウインドウに
は暗黙のうちに追加されるディスパッチです。したがって軽量ダイアログと
して生成された側にも存在しています。

今回これを書いていて気づいたんですが、別スレッドへわざわざドキュメント
を生成するモードレスダイアログは無くてもかまわないかも知れません。モー
ドレスではHWNDのコンテキストとドキュメントコンテキストが異なるような気
がしますから、カスタマイズしにくいのです。今回の軽量ダイアログでは親と
の間に非表示なWS_POPUPを一枚挟むだけでモードレスとしていますが、これで
も実用上支障がないように見えます。

この軽量ダイアログ中でもHTABOX系タグは解釈されますが、メニューやツー
ルバーは出現しません。非軽量なウインドウは外郭、フレーム、ドキュメント
の各HWNDを監視し、細かな制御を行っていますが、軽量ダイアログの場合は
外郭が存在しない2重構造のままで、フレームの終了だけを監視しています。

このダイアログの起動が十分軽量であることが証明されれば、わざわざダイ
アログテンプレート内へのドキュメント埋め込みを行う必要は無いわけです
ので、しばらく様子をみようと思います。

UTIL.showModalDialog系はプロセス中のHTMLダイアログクラス情報を置き換
えますから、一度呼び出されるとノーマルなshowModalDialogの方もアイコン
が無くなりますが、今のところ問題視していません。あれをありがたいと思う
プログラマーは居ないと思うからです。また、素のUTIL.showModalDialogは更
に何もしない軽量さを追及し、マージン等の小規模な設定が可能なEx付き関数
に分割しようと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。軽量ダイアログの仕様を変更し、引数が3つ増えました。

UTIL.showModalDialog('dialogB.htm', document, 'status:yes', -1, -1, 0);

増えた3つは左と上のマージン、UiFlagです。マージンは-1がデフォを受け入れ
ることを意味します。マージンまでは高速に設定できますので、最終引数がゼ
ロである場合サイトを置き換えません。デモではモーダルは最軽量、モードレス
は最終引数にDOCHOSTUIFLAG_THEME（0x40000）を指定してテーマを有効として
いますのでサイト置き換えが実施されています。

更に簡潔に書けないかと思い、インターフェースのラップではなく、横槍を
いれて特定の関数内容だけを置き換える実験を行っていました。これは一見
大変スマートな方法に思えたのですが、考えてみるとその型を使うすべての
インスタンスへ影響を与えますからボツになりました。つまりダイアログの
基底クラスをカスタマイズすればすでに表示されている無関係なダイアログ
までも巻き込まざるを得ないことになるのは当然の帰着です。

254は単なる私の勘違いでした。現状のHTABOXにおけるタブ生成はモーダル
ダイアログの連鎖生成で行われていますが、これは「連鎖」だから複数出現
可能なのであって、単品でモーダルを出せば1個しか表示できません。論より
証拠で現状の軽量ダイアログ、モードレスは1個しか出現しません。どうもこ
の辺の理解が足りなくて頭が混乱していたようです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。軽量ダイアログの仕様を変更し、UiFlag指定を排除しました。
通常のダイアログ引数にLeft,Topのマージンのみが拡張されていることになります。
テーマを適用する場合はUiFlagではなく
<meta http-equiv="msthemecompatible" content="yes">
を使用してください。最終的に既定のサイト構造にはタッチせず、HTABOX名前
空間のみ有効な状態となりました。同一スレッドでモードレスなら軽量だろう
というもくろみだったのですが、結局別スレッド生成ですので、デフォより
軽量ではありませんが、IEアイコン無しで、タイトルも通常ダイアログと同じ
に左端から開始されますので活用してください。

258でvtable置き換え手法を実験したわけですが、これによって既成HTMLウイ
ンドウのドキュメントインスタンスをHWNDが出現するより前に捕捉することが
可能となりました。捕捉というよりも相手側が報告してくる状態となりますの
で、何らポーリングめいたことをする必要が無く、ドキュメントの生成という
リソース的に厳しい状況下でのスムーズな動作に有効な技術だと感じました。

canvasがIEでは対応されていません。
VMLだけではいくらかタグが多くなってしまい、HTML中に収めると重くなる気がします。
できれば、できればですが、そちらもご検討くださるととても嬉しいです。
無理が有るとはわかっていますが…

>>262
Canvasという単語が初耳なほど偏った見識しかないのですが、HTML上へグラフ
ィック描画する規格のようですね。VMLは確かに一筆書き図形（ポリゴン）で
ちょっと複雑になると頭爆発しそうになりますから、対応が必要でしょうね。

統一された規格に則るべきでしょうが、自由にやっていいのであれば、GDI+
のメタファイルクラスで間接的GDIコマンドを生成し、表示部分をGDI上にPlay
する方式がいいと思います。これならどんなに長大な図形でも軽量に処理でき
ますし、そのまま画像保存や印刷も可能になります。JavaScript経由とは比較
にならない描画速度を達成できるでしょう。

結局何かが足りないとか、何かが必要という出発点から機能は生まれてゆき
ますから、「こんなふうなら」があったら気兼ねなくなくつぶやいてくださ
い。「コンピューターでご飯を炊いてください」的な要望でなければ、何で
も検討してみる価値はありますし、私には到底実現できない事であったとし
ても、それを見たもっと有能な方が実現してくれるかも知れませんし。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。外見上は何の変更もありませんが、再考してみると、やっぱり
モードレスは単にPOSTを絡めると実現できるという理論に変更されました。これ
なら。よっこらしょで別スレッドを立ち上げるより幾分軽量なはずです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。軽量ダイアログ最終引数UiFlagが復活しました。デモでは
DOCHOSTUIFLAG_THEME = 0x00040000を設定しています。この軽量ダイアログ
は既成のHTMLウインドウが必要な場合の最軽量生成手順を検証する上で重要
な存在でした。直接ドキュメント埋め込みが最軽量ですが、それでは克服で
きない場合の保険です。これはサイト置き換えではなく、サイト中の既存メ
ソッドを適切なタイミングですり替えることにより実現されています。した
がって、通常の生成手順のまま構築は進行し、いつの間にか性質が変化して
いるという状態になります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。タブ生成を軽量ダイアログ用に開発されたモジュールに変
更しました。僅か5ページでも若干クイッキーなことが感じられますので、
ストーリー性のある100ページのタブだったりすれば、かなりの違いになると
推測します。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。すべてのウインドウを軽量手法で生成しています。反応が
早い分ギクシャクして見える部分もありますが、今後調整します。
まず、ダイアログ呼び出しが単純化されました。軽量ダイアログと同じ呼び
出し方法で関数名にExが付いたものが拡張ダイアログです。パスは表示中HTML
ファイルとの相対パスと認識されます。

UTIL.showModalDialogEx('dialog.htm', document, '', -1, -1, 0x40000);
UTIL.showModelessDialogEx('quick.htm', document, '', -1, -1, 0x40000);

CreateDlgWindowExが廃止されCreateAppWindowに置き換わりました。これは
名前からも推察できるようにアプリケーション起動時に表示されているウインド
ウと全く同じものです。MSHTAと決別すれば、何個でもアプリケーション用ウイン
ドウを生成できるわけです。こちらはその性格上絶対パス指定としています。

WIN32.CreateAppWindow(Base + 'quick.htm');

尚、test.htmから上記呼び出しでquick.htmを表示し、２つめを要求すると
シングルインスタンス機能が働きます。HTABOX:Application中の[Single#yes]
を削除すれば複数表示されるはずです。

私の要望のみ書かせてもらいますと、
私は、表示されたウィンドウ内部のjavascriptで一つのオブジェクト(タグ)中のグラフィックを制御できる物が欲しいので、canvasであることは必要なく、独自の規格であっても全く問題はないです。
しかし他の人の事、汎用性の事、軽量化の事なども考えなければならないので、参考としてお願いします。

>>269
了解しました。すぐには対応できませんが、断片的なデモとして私のイメージ
したものを見ていただき、ご要望に沿うような機能として実装できるよう努力
したいと思います。時間やキーなのどのイベントでの動的な描画がメインなの
でしょうか？それともあらかじめ決まった図形をアニメーションする事がメイ
ンなのでしょうか？最終的に作成したいアプリケーションのイメージを伺った
ほうが早いかもしれませんが、その変のヒントをいただけると助かります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ツールバーの幅がウインドウより大きい場合にページャー
コントロールが機能するように修正しました。タブ対応に伴い、ページで定
義されているコントロールは一旦ドキュメントのHWNDを親として生成されま
すが、ページャーは外郭を親として待機し、ツールバーが乗るときに表示さ
れるというごく当たり前な対応で解決したようです。

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。実験的にHTABOX:DrawTestエレメントを作成
しました。添付Draw.htmを開くとボタンからGDIへの直接描画を行えます。
現時点での実装関数は3つだけです。エレメントIDをDRAWとした場合、
DRAW.CreatePen(0, 4, 0xFF0000);
これはWIN32版と同じ引数です。
DRAW.Line(0, 0, 640, 480);
先行引数ペアを開始座標、後続ペアを終点座標として線を描画します。
DRAW.LineTo(x, y);
前回の終了座標から引数座標への線を引きます。
CreatePen第一引数の定数は以下のとおりです。
#define PS_SOLID 0
#define PS_DASH 1 -------
#define PS_DOT 2 .......
#define PS_DASHDOT 3 _._._._
#define PS_DASHDOTDOT 4 _.._.._
#define PS_NULL 5
#define PS_INSIDEFRAME 6
#define PS_USERSTYLE 7
#define PS_ALTERNATE 8
#define PS_STYLE_MASK 0x0000000F

ttp://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。毎回線を引くたびに再描画を要求するのは非
効率なので、再描画要求関数を追加しました。エレメントIDがDRAWな場合
DRAW.Invalidate();
でエレメントDCの更新表示を要求します。逆に言えばこれが無いと描画は反映
されませんので気をつけてください。DirectDrawで全画面を制御するのでなけ
れば、この描画手法が最速だと思います。

こういうのを実行させると、コンピューターって奴は同じことを飽きもせず
やってくれるものだと感心してしまいます。すこしだけアーティスティック
なアルゴリズムです。現状のデモはこの関数になっています。
function test()
{
　　for(var d = 0; d < 0x1000; d++)
　　{
　　　　DRAW.CreatePen(3, 1, d * 0x1000);
　　　　DRAW.LineTo(Math.random() * 640, Math.random() * 480);
　　}
　　DRAW.Invalidate();
}
単純な直線の繰り返しから、曲線のようなうねりを感じさせる模様ができます。
皆さんも何か面白い結果出る関数が書けたら教えてください。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ツールバー切り替え時に一旦HIDEしたものをSHOWする記述が
抜けていましたので修正しました。

最終的にあらゆる状況下で生成されるHTMLドキュメントインスタンスの早期
取得に成功しました。これで何が可能かというと「何でも」という答えにな
ります。そしてWindowsある限りHTABOXは有効であることがほぼ確実になった
という意味もあります。

HTML系ウインドウを統一した構造のクラスで制御するための実験を行っていま
した。COM的には変数へ代入しない形式の new Hoge(); や delete this は当た
り前なことなのですが、ネイティブなコントロールやHWNDとの兼ね合いで、そ
う書くのが危険に思える局面があるのです。例えば通常のWIN32コードならウイ
ンドウへWM_NCDESTROYが送られた後の事は考えないと思うのですが、COM的には
インスタンスの終了処理のために何らかのメッセージが送られ続けている可能
性を考慮しなければならない気がします。ならば、真のインスタンス消滅タイ
ミングをどう決めるべきかという悩みが発生します。今のところOLE的観点から
の終了通知が最も確実ではないかと推定しているのですが。

ルーズなCOM型を宣言して、とりあえず親クラスはその派生とする。
class __declspec(uuid("D9689CB2-1A1E-4767-AA71-051EC5E14E59")) SiteCallBack : public IUnknown
{
　　public:
　　virtual void Detected(HWND fra, HWND doc){};
};
_COM_SMARTPTR_TYPEDEF(SiteCallBack, __uuidof(SiteCallBack));

class Site
{
　　//子で親型スマートポインタ宣言
　　SiteCallBackPtr CallBack;
　　public:
　　Site(SiteCallBack *p)
　　{
　　　　CallBack = p;
　　}
};

class Caller:public SiteCallBack
{
　public:
　Caller()
　{
　　　//親が子を生成する時子へ自身インスタンスを渡す
　　　new Site(this);
　}
};

上記ルールで子がドキュメントの寿命を知っていてdelete thisが発生する
場合、連鎖的に保持していたスマートポインタにもReleaseが発生し、結果
的に親のdelete thisが誘発される。したがって親は単に
new Caller();で宣言してもドキュメントの寿命でデストラクタが起動される。

とっても基礎的なことなんですけれど、子から親をdeleteしようとしたりす
るとシステムに怒られますので、COMというスマートなルールを考えた人は、
とても優秀な頭脳の持ち主だと今更ながら感心します。

最終的にたどり着いた手法は、次にOLE的に生成されるObjectを待ち構えて
ポイントとなるアドレスを偽装し自由に扱ってしまうものです。したがって
これはMSHTML上での動作に留まらず、ワードやエクセルへの埋め込みでも機
能します。もし、生成経過をコールバックして報告する必要が無いのであれ
ば、もはやHTAやダイアログの生成機序を書く必要も無く、既製品のドキュ
メントが生成される前にこのモジュールを実体化させておくだけです。

細かな実装を記述すれば（例えばブラウザをゼロから書けば）当然得るもの
は多いでしょうが、周辺仕様の変更に戦々恐々としなければならないでしょう。
最悪の場合意図的な仕様の変更によって潰される可能性も出ます。私はそれが
賢いやり方ではないと直感しますから、COMプログラミングに傾倒するわけで
す。

これでMSHTMLに関する基礎的な研究は終わりました。Windowsある限り変わり
様が無い箇所を押さえましたので、もう二度とこの機序を深く考えることも
無いでしょう。今日もへとへとになるまで書いて、さて寝る前に何か見ようか
と言う対象が「MSDN」という日々を数年続けてきましたが、食えるようになっ
たら、苦労を掛けた妻と子供たちに楽をさせてあげたい気持ちでいっぱいで
す。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。起動時のアプリケーションウインドウを新たに書いた軽量
HTAウインドウに変更しました。またHTAさんはcloseという関数名がお嫌いな
ようですのでスクリプトからのウインドウ消滅関数はUTIL.DestroyWindow();
に変更されました。

拡張ダイアログがウインドウリサイズに追従していませんでした。頼みもし
ていないのにクライアント領域が角丸になるという面白い現象です。多分
コンテストを外しているところがあるんだと思いますので、修正します。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。さすがに疲れました。これは理屈で何が正しいという次元
ではなく、動くのが正しいという世界です。HWNDのコンテキストは、少々外
しても動いてしまうものですから、要注意です。

284での教訓を元にコンテキスト統一を意識したルールが確立できました。
最終的に操作する対象はディスプレイ上のDCであり、HWNDなのですが、そ
れを操作する引き金となるものをインターフェース呼び出し、メッセージ、
コネクションポイント.....等が混在した状態とするとそのまま「混乱」が
結果に反映されるということのようです。

まず、何かの情報が欲しい時、それを持っているのは誰かを知っていなけれ
ばならず、その誰かがどういう素性（コンテキスト）であるのか、又はその
情報がセットされる元の引き金を引いたのは誰か、そのコンテキストで目的
物の操作を連続できるのか、高負荷に耐え得るのか、だめなら代替策はある
のか、が解決して一つの動作が書けます。次の動作で同じことを考えますが、
もし、前の動作と相性が悪かった時、一度考えを更にして何が最重要なのか
を再検討する。そんな事の繰り返しがCOMプログラミングだと思います。

HTMLウインドウ系の最終セッティングが終わりました。アプリケーションウイン
ドウのバリエーションはHTAベース、WebBrowserベース、ダイアログベース、
直接埋め込みの4種で、IHtaBoxインターフェースを継承すれば、タブ対応ウイン
ドウとなります。タブは直接埋め込み時のみ直接埋め込みで生成され、他は
ダイアログベースで生成されます。

ダイアログ系ウインドウは軽量な2重構造と、ダイアログベースのアプリケーシ
ョンウインドウと等価な拡張ダイアログの2種類です。

4種のアプリケーションウインドウを動作させた感触ではHTAベースが好印象
です。考えてみるとHTAの親はNULLですからHTMLダイアログの機能をさらに削
ぎ落としたウインドウという設計かも知れません。

ついでですからWebBrowserベースだった場合のタブもWebBrowserにして実験
してみました。キャッシュが利いた状態ので数ページのタブをパースする程
度なら、速度的にもたつく感はありませんから、公衆インターネット用には
使えるかも知れません。普通の方はWebBrowserイコールMSHTMLだと思うので
すが、メモリの開放機序に特有の癖が見られますから、きちんとサイトの開
放が行われているかをチェックしないとメモリリークしやすいようです。

WebBrowserベースのウインドウへリッチエディットを生成するビヘイビアを
を置くと、何の問題も無く動作するようです。つまり、HTA系は何らかのサイ
ト側インターフェースがドキュメント上のフォーカスに抑制を加えていて、
自前でインターフェースを選別するWebBrowserや直接埋め込みでは当該イン
ターフェースが存在しないので自由が利く、というのが真相のようです。

メモリ開放管理を再度検証する作業を行っていました。動くとその先へコード
を書いて、そこで動かなければ3歩くらい戻らなければならないものですから、
その時点での厳密な検証はついおろそかになってしまいます、案の定、書いて
いた当時は開放されていても、周辺の仕様が変化したことによって未開放とな
った部分がありましたので、修正しました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。アプリケーションウインドウとタブは実験的にWebBrowser
で生成されたものになっています。拡張ダイアログの生成機序を改善しまし
た。

blogs.msdn.com/b/ie_jp/archive/2011/09/02/10204807.aspx によると
IE10では
・条件付きコメント
・エレメントビヘイビア
・XML データ アイランド
が使えなくなるようです。また、
blogs.msdn.com/b/ie_ja/archive/2011/12/07/web-ie10.aspx によると
・VML
・DirectX ベースのフィルターおよびトランジション
が使えなくなるようです。

Windows 8だとMetroUI+IE10でHTML5+CSS 3+JavaScriptを利用したアプリケーションがつくれるようですね。
subtech.g.hatena.ne.jp/mayuki/20110929/MetroStyleAppsWWAHost

>>292
情報ありがとうございます、いよいよ本番ですね。エレメントビヘイビアが
具体的に何を指しているのか、以前から気になっていたので調べてみたいと
思います。全部OBJECTでもいいでしょうが、折角の軽量さが失われる気がし
ます。

現状のMSDNがIE10のインターフェースを反映しているものなら、大きな変更
は無いように見えますが、これだけは現物を分析するしかないですね。公衆
インターネット向けブラウザとして本来の規格に統合されるのは当然の流れ
ですが、アプリケーション階層にどの程度変更が及んでいるのかは、まだ情
報が十分ではないようです。

例えばフィルタの実体はdxtmsft.dllなんですが、これ自体はなくせない存
在だと考えられます。なぜならoffice系がこれを必要とするだろうからです。
そういった一見失われたように見えるものを、特定のEXE起動環境では従来ど
おりの規格で使えるようにするサービスのスタイルも考えられます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。アプリケーションウインドウとタブは実験的に直接ドキュ
メント埋め込みに変更されています。291とレスポンスを比較すればこちらの
方が迅速な事は明らかだと思います。ただし迅速すぎてコケル可能もまだあり
ます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。起動直後でキャッシュが無い状態だと見事にコケテくれまし
たので原因を修正することができました。この手の不具合はデバッグ環境のよ
うに速度が抑制された場合は発生しませんから、リリースビルドのまま、勘で
勝負する必要がありますが、今回は正解を引いていると思います。

このアプリケーション用ウインドウとして最も柔軟で軽量な直接埋め込みは
IDispatchPtr doc("htmlfile");が通るんだったら、それだけで実現できま
す。MSHTML.DLLがエクスポートする関数とは無関係でOLE的基本動作に仕様
の変更が無ければHTABOXはその動作を完全にコントロールします。

WindowsがDLLやCOMで構成されている限り、何らかのオブジェクトが活性化
していれば、その情報は取得可能ですし、振る舞いは変更可能です。まして
律儀にタイプライブラリまで付いている訳ですから、必要な部分をちょっと
操作するだけで大きな仕事をしたかのように振舞えるというのが結論です。

今日は折角「前938」さんからお題をいただきましたので、グラフィックにつ
いて考えています。まず次の３案のスクリプトを考察します。

//�@-----------------------------------------------------------------
var Color = new GDIP.Color(0xff, 0xff, 0xff, 0xff);
var Pen = new GDIP.Pen(Color, 1.0);
var Graphics = new GDIP.Graphics(GDIP.DC);
Graphics.DrawLine(Pen, 0.0, 0.0, 100.0, 100.0);

//�A-----------------------------------------------------------------
GDIP.Exec("Color:0xff,0xff,0xff,0xff");
GDIP.Exec("Pen:1");
GDIP.Exec("DrawLine:0.0,0.0,100.0,100.0");

//�B-----------------------------------------------------------------
GDIP.DrawLine(0xff, 0xff, 0xff, 0xff, 1.0, 0.0, 0.0, 100.0, 100.0);

GDIPという架空のインスタンスがあった場合どのような呼び出しが妥当なの
かを考察しています。�@から�Bになるほど高速に処理可能ですが、最終的な
描画が達成されなかった場合の原因究明手段は速度が高速になるにしたがっ
て失われます。従来のVMLというのは�B的手法だと考えます。プログラミング
という作業は99%デバッグであるという観点から、最終的に�Bを選択する余地
はありつつ、�@で開発できるというのが理想ではないでしょうか。

そこで一つのアイディアが生まれます。リリースモードな場合�@の記述を
�Bにコンパイルしてしまうというものです。これはそれを解釈するエディ
タとの連携で可能になります。

#if defined(_DEBUG)
　var Color = new GDIP.Color(0xff, 0xff, 0xff, 0xff);
　var Pen = new GDIP.Pen(Color, 1.0);
　var Graphics = new GDIP.Graphics(GDIP.DC);
　Graphics.DrawLine(Pen, 0.0, 0.0, 100.0, 100.0);
#else
　//自動生成コマンド
　GDIP.DrawLine(0xff, 0xff, 0xff, 0xff, 1.0, 0.0, 0.0, 100.0, 100.0);
#endif

ただし選択の余地はあるにせよ、これも私が思い描く理想とは異なります。
問題の本質は�@がパースされた状態をバイナリなメモリ状態のままシリア
ライズして、実行時に再現できないのか？にあると考えます。これはグラ
フィック描画に限ったことではないのですが、スクリプトコードのシリア
ライズが確立すれば、スクリプトの実行速度に係わるあらゆる問題が解決
します。その問題の鍵は実行するまで何が起こるかわからないJavaScript
をディスパッチ機構との親和性が高いVBScriptへ内部で変換しDLL化するこ
とではないかと考えます。

とりあえず、自分か必要とする機能を�@的手法で書いてみようと思います。
要はエレメントへのDraw要求で拡張メタファイルハンドルのPlayが行われ
ればいいわけですので、OBJECTでもビヘイビアでも構わないのですが、単
品な製品としてリリースすることを考慮すればOBJECTになりますし、当然
あらゆるブラウザで機能することになります。

一番単純そうなColorクラスをインターフェース化し、実装coclassのTlbを
眺めた結果は下記のようになります。Colorクラス関数がそのままスクリプト
へ公開されている様子がわかります。

//CGdipColor implements IGdipColor type coclass
FUNC CGdipColor.AddRef() return UI4
FUNC CGdipColor.GetA() return VARIANT
FUNC CGdipColor.GetAlpha() return VARIANT
FUNC CGdipColor.GetB() return VARIANT
FUNC CGdipColor.GetBlue() return VARIANT
FUNC CGdipColor.GetG() return VARIANT
FUNC CGdipColor.GetGreen() return VARIANT
FUNC CGdipColor.GetIDsOfNames(GUID as riid, I1 as rgszNames, UINT as cNames, UI4 as lcid, I4 as rgdispid) return VOID
FUNC CGdipColor.GetR() return VARIANT
FUNC CGdipColor.GetRawPointer() return VARIANT
FUNC CGdipColor.GetRed() return VARIANT
FUNC CGdipColor.GetTypeInfo(UINT as itinfo, UI4 as lcid, VOID as pptinfo) return VOID
FUNC CGdipColor.GetTypeInfoCount(UINT as pctinfo) return VOID
FUNC CGdipColor.GetValue() return VARIANT
FUNC CGdipColor.Invoke(I4 as dispidMember, GUID as riid, UI4 as lcid, UI2 as wFlags, DISPPARAMS as pdispparams, VARIANT as pvarResult, EXCEPINFO as pexcepinfo, UINT as puArgErr) return VOID
FUNC CGdipColor.QueryInterface(GUID as riid, VOID as ppvObj) return VOID
FUNC CGdipColor.Release() return UI4
FUNC CGdipColor.SetFromCOLORREF(VARIANT as rgb) return VOID
FUNC CGdipColor.SetValue(VARIANT as argb) return VOID
FUNC CGdipColor.ToCOLORREF() return VARIANT

毒を食らわば皿までと、Graphics classの全中継を書いてますが、200個弱
のメソッドですので、さすがに嫌気がさしてきました。大変なのはこれと
GraphicsPath class ですからなんとか書き上げたいとは思っていますが、
何らかのアシスト関数がないとJScriptからは手が出ない部分も散見され
ます。特にJavaScriptのArrayはいわゆる配列ではなくハッシュですから、
せめてVT_ARRAY|VT_VARIANTのバリアントを生成させる関数が必要になる
でしょう。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。直接埋め込みでツールバー等のメッセージが処理されていな
い部分を修正しました。

GDI+のディスパッチラップを行っていて、これだけは独自規格としなければ
ならない事項が「名前問題」です。ディスパッチはそのルール上同じ名前で
異なる引数の関数を存在させることができません。できるのは後方引数が省
略された場合のデフォルト値を用意することだけです。GDI+は同一名で引数
が異なる関数のオンパレードですから、これを正確に切り分けるためには別
名関数としなければ実現できないと思います。まぁGDI+互換で自分がゼロか
ら書きましたと言えば少々関数名が違ってもいいだろうという考え方もあり
ますが。

ちょっと立ち止まって現状を分析したのですが、このグラフィックのスクリ
プト向けディスパッチという課題は保留しようと思います。力づくでやろう
と思えばできることは判明しましたが、全体を網羅するためには結構な時間
が必要ですし、一旦公表してから仕様が揺らぐような状態を回避しようとす
れば少なくとも1ヶ月は要するでしょう。そんな時間はありませんし、たと
え今日完成したとしても、私自身がエレメント内でC++から行っている動作
をわざわざスクリプトへソース公開な状態で置くかと考えてみると、それは
否なわけです。HTABOX3.00がカチッと決まったら其の先の仕事にしようと思
います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。新たなUIとしてリボン風メニューが追加されました。これは
実験的にVML生成していた動的メニューを完全にGDI+で置き換えたものです。
添付DESIGN.htmを実行するとその動作をご覧になれます。

従来のHTABOX名前空間とは別にDESIGN名前空間は文字通りデザイン主体なエ
レメントを管理するために存在します。デザインメニューの生成は単純です。
<DESIGN:Menu text="単独メニュー" style="width:160;height:48">
<!--内容エレメント-->
</DESIGN:Menu>
メニュータイトルとしてのtext属性、CSS定義としてのwidth、heightだけで
生成できます。初期の閉じた状態でクリックされた場合、内容エレメントを
表示し、閉じるボタンが出現します。

内容エレメントは常にlastChildとして認識しています。したがって単一な親
にまとめる形で複数のコントロールを配置してください。また、表示サイズ
の決定のために内容エレメントにもCSS定義としてのwidth、heightを明示して
ください。

複数のメニューの連動（開く動作で他のメニューを閉じる）を行う場合は各
メニューにIDを付与し、各メニューのprev属性next属性へ前方、後方に位置
させるメニューのIDを指定してください。特定のメニューが開かれる時、前
方と後方のメニューへ閉じる命令を送信しています。まだ、色やグラデーシ
ョンの指定には手をつけていませんが、将来は定義可能となる予定です。

あぁウインドウのサイズ変更で表示が飛んでしまっていますね。ちょっと
何が原因か思い当たりませんので、すこし時間が必要かも知れません。
一旦引っ込めることはせずに、できるだけ早く修正を行うことにします。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。エレメントへ渡されるDCのアドレスは変化しないだろうとい
う書き方をしていたのですが、初期ウインドウサイズを越えたときに更新され
るというのが原因だったようです。今回は単純なBitBltではなくメタファイル
のGDIコマンドをストリーム保持して再生しようというのが中核の技術となりま
すので、まだ予期しない事実が隠れている可能性もあります。

従来のHTMLアプリケーションにはどうしても消極的イメージがあると思いま
す。「ネイティブできっちり書くのが面倒だから」という展開です。でも私
はHTMLにはネイティブで書く気にもならないほど高度な動作を極めて単純な
インターフェース(入出力形式)にまとめる能力があると考えます。つまりHT
MLアプリケーションを消極的なものから攻撃的なものへと変革させることが
重要です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デザインメニュー関連動作を開発モードのInvoke系から速度
重視の生インターフェース呼び出しに変更しました。メニューの内容エレメント
は、状況に応じて大きさが変化する可能性がありますし、それを許容できる柔軟
性が最重点テーマです。したがって特定サイズのメモリDCを確保するのではなな
く、サイズ変更の度に行われる描画コマンドを記憶し再現する方式です。ですか
ら、いかにもWIN32ネイティブという速度は得られませんが、このメニューが膨
大に存在するページでもストールしない柔軟性があるだろうと考えます。

リボン風メニューだけでなく、本物のリボンも使用可能だと嬉しいなぁ、というのは高望みしすぎかな…
ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9C%E3%83%B3_%28GUI%29

>>316
それを提供しているAPIの仕様が判れば可能です。私が勉強不足で知らないだ
けというのが真相ですから。ただこのデザインメニューは大変柔軟性が高い
構造となっています。中に別のフレームを入れる使い方もできるはずです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。まだ仕様が確定していませんが、DESIGN:Lineによる線描画
デモをDESIGN.htmに追加しました。連動メニューの各ボタンで線が描画されま
す。この線をZオーダーで下へ潜り込ませることができればいいのですが、メ
ニュー側のGDIコマンド再生が機能しなくなるという現象がおきるので対策に
悩んでいます。

IE8環境だとGDIコマンド再生自体がうまく機能していませんでしたので、
原理の部分から見直す必要があるようです。ここら辺をしっかり押さえな
いと、HTML内部でのグラフィック拡張は実現できませんから腰をすえて再
考します。

>>308
難しいのですか…
別に今すぐに使わないといけないわけでもありませんし、
今後の物として考えていただければ嬉しいです。

>>320
グラフィックに対する要求は多岐にわたる可能性がありますし、できれば既存
の規格（GDI+）を全部そのまま移植しようとすると結構手間がかかるという結
論でした。改めて考えてみると要求は２種類に大別できます。特定のエレメン
ト内への操作か、ウインドウ全体に対する操作か。後者の場合htabox300b.zip
で行ったように短時間で作成可能ですが、前者を考えた場合時間がかかるもの
になると感じました。

いずれにせよ、「これが決定的な仕様です」を自信を持って提示できるほど
情報収集が進んでいない事が何よりの理由ですから、もうすこしお時間をい
ただいて勉強させていただきます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デザインメニューの描画を単純なBitBltとすることで描画
を安定させました。また、DrawLineのZオーダーを一つ下げた状態でのデモ
にしました。

このメニューの場合、内部エレメントが表示されなければなりませんからバッ
クグラウンドを描画するわけですが、その状況でのGDIコマンド再生は確実性
に欠けると判断しました。線の描画のような場合は対角の矩形DCを確保するの
は馬鹿げていますから、GDIコマンド再生です。状況によって両者を使い分ける
必要があるということのようです。

デザインメニューの中身は何でもいいんですが、ここにコンパクトな領域で
仕事ができるHTMLアプリケーションを格納すれば、タブでの切り替えではな
く、一つのウインドウ中のコントロール選択によって複数のジョブを切り替
えることができます。また、この発展系として階層構造を表現したデザイン
メニューを書いています。これはデザインノードという名前です。ジョブ自
体が構造化されている場合、ユーザーが直感的に次のジョブへ移行できるわ
けです。また、必要によってユーザーはそのノード構造を変更することも可
能です。HTABOXの実行サンプルはこのデザインノードを開いた時に表示され
るソースコードエディタで実行を選択することによって行うというのが近々
な目標となっています。

デザインメニュー内にHTMLアプリケーションが存在する状態を想像すると、
これはもはやランチャーではなく小さなOSのような存在になると思います。
ならば、個々のHTMLアプリケーションがやんちゃな事をしてシステムから
退場を命じられても母艦は平然と動いていなければなりませんから、サブ
プロセスとして生成しながら、メニュー内に出現させる必要がありますが、
これは別に難しい事ではないと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デザインノードのデモがDESIGN.htmに含まれます。
DESIGN:LineとDESIGN:Nodeの仕様はもう少し動作がこなれてから決定したい
と考えています。ノードのドラッグ処理にもう一工夫必要なようです。
「ユーザーが自由にレイアウトできるコントロール」というのが、HTMLの威
力を発揮する象徴的な存在なのではないかと考えています。

ノードを重ねると閉じるボタンのＺオーダーが不整合ですね。また、内容を
操作したときのマウスをドラッグ操作とご認識しやすいですから、タイトル
部分のみドラッグ動作とすればいいのかも知れません。こうやって誰かが動
かすかも知れない状況を作ると、客観的に分析できるんですが、書いている
最中は気づけないものです。

325で別プロセス構想を述べましたが、そこまでやんちゃじゃない場合はこの
ノード中に別スレッドドキュメントをサイズ可変ウインドウな状態で置くと
結構使えるかもしれません。つまりモードレスダイアログの埋め込み版です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デザインノードのドラッグ動作を修正しました。コードを
カプセル化してIHTMLElementEvents2だけで処理したかったのですが、ドラッグ
移動に関しては一時的にIHTMLDocumentEvents2を監視するのが正解なようです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。BitBltからMaskBltに変更し、角丸の隅を処理しました。
何度かGDIコマンド再生を試みるのですがいまいち不安定なので、せめて隅
の未処理を隠すための修正です。上に何も乗らない×ボタンはコマンド再
生でも安定表示できていますから、ちょっと未練が残ります。

マウスの動きにあわせてDESIGN:Lineを使い、マウスの跡を作ろうとしたら、
線が所々出たり消えたりして、不安定です。
onclickで明確にポイントを指定しても消えるようです。

>>331
情報ありがとうございます。現時点でのDESIGN:Lineは点をプロットする目的
を想定していませんでしたので、思い当たる部分を修正してみますが、そうい
った目的なのであれば、線描エレメントではなく直接ドキュメントのDCへ介入
を行い軌跡を保存する手法が効率的だと思います。

例えば1px角のDIVを膨大に生成すれば何でも書けますが、存在できる数には限
界がありますし、ばかばかしいくらい遅い動作になることを考えればご理解い
ただけると思います。

下記の単純な関数で実験しましたが、DESIGN:Lineはそういう目的には不向き
だということが現時点での回答になります。
var X = 0, Y = 0;
function document.onmousemove()
{
var obj = document.createElement("DESIGN:Line");
document.body.appendChild(obj);
obj.DrawLine(X, Y, event.clientX, event.clientY, 0x000000);
X = event.clientX; Y = event.clientY;
}

「何番目に引いた線分の座標は？」という要素と、「マウスの軌跡保存」と
いう要素は相反する要因なのですが、これをスマートに解決する方法が無い
わけでは無いと考えます。通常メタファイルは書き込み動作が終わらないと
再生できませんが、もし、書き込み途中のデータを横取りして再生したり、
既存の書き込みデータを改ざんすることができれば両者を満足させられると
思います。時間ができたらその方向で開発し、今まで見た事のないマジック
をお見せできるかも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeについて細かな修正を加えました。中にネイテ
ィブな要素を入れて安定動作を確認してから仕様を公開したいと考えていま
す。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeについての修正が続いています。そろそろ問題
は出尽くしたかなぁと思います。デモのDESIGN:Nodeは内容がGRAY_BRUSHな状
態で、Ｚオーダーも未処理ですが、現実的な大きさに拡張された場合の動作を
確認する段階となっています。GDI+のグラデーションは低速ですが綺麗です。

ウィンドウ全体に関する処理ならば短時間で作成可能なのですか。
あくまで個人的意見ですが、基本的に描画が出来るならばそれがいいと私は思っております。
特定の要素に描画するかのように見せるスクリプトならユーザ側で作れますから。
また、DESIGN:NodeやDESIGN:Lineにcssで言うz-index、他のhtml要素との重なりや線同士の重なりを指定できると
使いやすいと思います。

>>337
ご意見ありがとうございます。「ウィンドウ全体に関する処理ならば」逆に
包括的なものになり時間がかかり、キャンバスのように特定のエレメント内
限定なら短時間に作成可能です。まだ、仕様を固めていませんがDESINE名前
空間にあろうともHTMLエレメントですから、原則としてCSSはいつでも操作
できますが、現在はデモの目的に合わせてＺオーダーを操作していますが、
将来はご指摘のように自由に設定可能としなければならないと感じます。

>>338
そうだったのですか。
個人的には、速い方で作り上げる事が出来る方がいいです。

>>339
速度重視な専用エレメントを設計して追加することを課題にしたいと思います。
GDI+のラップで感じたのは「苦労して書いても、結局これってVMLより遅いかも」
でした。同じようなものが存在しても意味がありませんので、速度重視でアン
チエイリアスなんて無関心だけど世界で一番軽量で速いというものを最初に手
がけるべきだと感じます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:NodeへネイティブHWNDを埋め込み、内容ウインドウ
のサイズを可変するデモが含まれます。HTMLへHWNDを埋め込んだ場合の天敵
は「スクロールされた場合」です。従来それに対する処理が複雑で自分でも
見るのがいやな状態だったのですが、実に見たとおりなコードが書けました。

DESIGN:Lineの仕様を公開します。唯一な関数は下記のとおりです。
DrawLine(0, 0, 200, 400, 0x0000ff, 1.0);
開始座標ペア、終了座標ペア、色(BGR)、線幅です。
現時点では開始座標、終了座標を対角とした矩形領域で指定幅の線を描きま
すから、広い幅を指定した場合先がとがりますが、これは仕様です。

内容ネイティブHWNDの縮小操作、ゼットオーダー処理が済めばすべての準備
が整ったことになります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeのサイズ縮小、HWND上のマウスイベントによる
最全面ウインドウ切り替えを実装しました。DESIGN.htmの3つのノードをダブ
ルクリックで開き、3つのノードが一部重なった状態を作って、マウスを通過
させると挙動を確認できます。

残念ながら重ねてから、サイズ変更を行うと下のノードのHWNDへマウスが当
たった瞬間に下が前面に出るので、表示が乱れますね。ウインドウ拡張時に
ベースを先行して拡張するとか、サイズ変更時は最前面切り替えを無効にす
るとか、複数対策は考えられますので修正します。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。上記問題を修正しました。

Windows7上のIE10での動作試験結果は概ね良好でした。修正すべき点は
拡張モーダルダイアログとモードレスダイアログのツールバー表示が確実
では無い事と、モーダル終了時に親ウインドウへのブロックが継続されて
しまう点でした。MSDNの情報どおりMSHTML的にはインターフェースの大き
な変更は無いようです。したがってHTABOX、DESIGN名前空間の生成、動作
に何ら問題は生じていませんでした。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。334の修正により、全体がストールする可能性が生まれてい
ましたので、修正しました。

DESIGN系エレメントはHTABOX系にネイティブエレメントと比べるといかにも
HTMLという速度なのですが、これはHTML中のエレメントである以上何で書こ
うが逃れられない足枷です。でも私はこの速度で十分だと思うのです。

私はこのDESIGN系エレメントをHTMLアプリケーション本体のコントロールと
しては捕らえていません。これは、複数のアプリケーション（ネイティブを
含む）を選択して実行する親コントロールとして存在するのです。

アプリケーションの実行で「あ、こりゃだめだ」と感じるのは実行してからの
操作レスポンスであって、OS上でそのアプリケーションを選択、起動するのに
要する時間ではありません。ならば、個々のHTMLアプリケーションを管理する
小さなOSとしてのアプリケーションなら、コントロールに要求されるのはレス
ポンスではなく、ユーザーを直感的に誘導する柔軟でグラフィカルなGUIになる
わけです。

「速度は要求されないけれど、柔軟でグラフィカル」というフレーズなら
誰しもが「HTML」を連想するでしょうし、ネイティブなアプリケーション
でも起動することが可能な「HTMLアプリケーション」の独壇場と言っても
過言ではありません。

もう一度「原点」に立ち返って自分のコンピューターを眺めてみましょう。
貴方の思い通りな動作をしているでしょうか？。そんなことくらい何とか
ならないのか？という不満はありませんか？それを解決する最も確実で効
果的な手段が「プログラミング」です。そのときわざわざ制約の多い環境
で書く必要はありません。新しいからと、直ぐに廃れる環境に飛び込むの
も愚の骨頂です。HTABOXはWindowsを自由にカスタマイズする最も効果的な
ツールになるだろうと思います。

IE10の分析を行っていますが、4つ用意されたアプリケーションウインドウ生
成手法のうちHTA生成は成功しないようです。これは4つの内、最も無理がある
手法ですので、今更原因を追究するまでもなく切り捨てようと思います。万が
一、HTABOXを意識した変更だったなら、私のほうが一歩先へ進んでいたことに
なります。

また、拡張ダイアログも中間にダミーHWNDをかませるという美しくない手法で
すので、IE10がそれを嫌うなら切捨てようと思います。これはデフォルトな
2重構造ダイアログの生成初期へ介入できなかった頃の苦肉の策でしたので、
補助ウインドウが欲しければCreateAppWindowを使うことに統一して、キャラ
も被りも無くしたほうがすっきりするでしょう。

ツールバー表示が確実ではない問題については、IE10に限ったことではなく
タイミングの問題で稀に発生していましたから、完全にこの問題を排除する
機序に変更しようと思います。私がHTA以外の手法を確立していなかったなら
冷や汗ものの展開でしたが、神様は私を見捨てていなかったのだと感謝して
います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。IE10での動作確認済みバイナリです。
UTIL.showModalDialogExとUTIL.showModelessDialogExは廃止しました。
各種コントロール、タブを使用する新たなウインドウが必要な場合は
WIN32.CreateAppWindowを使用してください。

ひとつだけ毛色が変わっていたHTA生成を対象外とすることで、すべてのアプ
リケーションウインドウを常に生成、消滅可能なオブジェクトとして表現でき
そうです。例えば、起動時にイニシャライズファイルを読んで、BROWSE、DIRECT、DIALOG
のいずれかでメインウインドウを生成し、後続するCreateAppWindowは先行する
ウインドウのモードを採用するというじつに当たり前な展開が可能です。

再考してみると、拡張ダイアログについてはIE10の動作の方が正しく、私の
書き方が甘かったというのが真相なようです。ツールバーやタブを使ったダ
イアログが必要かどうかは別にして、復活させてみようと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。
UTIL.showModalDialogExとUTIL.showModelessDialogExが復活しました。
多機能な補助ウインドウとして動作しますが、タスクバーにカウントされ
ない点がCreateAppWindowと異なります。

HTMLにしてもJavaScriptにしても、基底で発生するゴタゴタを大掛かりなシス
テムで包み隠していますから、ちょっとしたミスでPCの動作自体がすっ飛ぶ
危険が無いわけです。CPUコードを吐かない言語がスクリプトだとすれば更に
その上にあるメタ言語のような存在です。ですからその世界の中でもっと気の
利いた事を実現することには無理があります。メタの拡張をメタで行うわけ
ですから、書けば書くほど鈍重にならざるを得ない宿命なのです。

かと言って、いきなりカスタムエレメントを設計しましょうというのも話が
飛躍しすぎる気がします。特にOBJECTタグによるエレメント設計はその寿命
がドキュメントの管理下にないと推定されますから、不用意にドキュメント
側のインスタンスを握り続けるだけで全体のメモリ開放が阻害されかねない
リスクを背負います。

その点、IElementBehaviorをベースにしたカスタムエレメントは、そのクラス
への要求を出させるまでが複雑なのであって、クラス内の記述そのものは、
通常のWIN32プログラミングより簡潔になりますし、大概のインスタンスは
スマートポインター保持していてもクラス自体が居残ってしまう事態にはな
りません。ですから「要求を出させるまで」を請け負うモジュールがあれば
いいという結論になります。カスタムエレメントの名前文字列と、クラス
を登録しておけば後はお任せなモジュール、もしくはそういった機能を持っ
たHTMLウインドウをいつか書きたいと思います。

現状でDESIGN.htmの表示がストールすることを確認しました。昨日行った
変更は結果的に小規模でしたので、その前のコードをベースに、もう一度
変更をなぞった方が早く原因をつかめそうです。ご迷惑をおかけします。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmの表示でストールする問題を修正しました。
デバッグビルドとリリースビルドで結果が違う、つまり最適化がらみな問
題だったのですが、非常に時間を要したわりには釈然としない結末だった
ので、すこし疲れました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:NodeにいよいよネイティブHWNDが埋め込まれたデモ
をご覧になれます。私がHTMLアプリケーションでやりたい事がこのデモに凝縮
されていると言っても過言ではありません。埋め込まれたエディタは読み取り
専用としてHTABOXのサンプルコードを表示、実行する目的ですので、エディタ
間のコピペ等には対応していませんが、埋め込みエディタとしてリリースされ
る場合は画像表示、印刷等の全機能を搭載することになるでしょう。

このDESIGN:Nodeはとりあえず任意なURLを埋め込みモードレスダイアログと
して実行する仕様として公開しようと考えています。

私が「アプリケーションの書き方を変えましょう」と提唱する意味は総てを
○○で書きましょうという一本調子な主張ではなく、HTMLアプリケーション
を基調として、必要ならネイティブなコントロールを、必要ならカスタムエ
レメントを、必要なら別アプリケーションさえ埋め込んで、柔軟なアプリケ
ーションスタイルを追求しましょうというものです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeはモードレスダイアログの埋め込みに変更され
ました。添付DESIGN.htmをHTABOXAPP.exeで開いてみてください。何も難しい
ことは無いと思っていたのですが、別スレッドドキュメントのDrawが困難で
あるという問題に直面して難航しました。また、DrawはOLEだとインチサイズ
なので、ディスプレイ上のサイズとは微妙に異なります。自分のディスプレイ
限定なら補正できますが、別のマシンではもっとひどい事になる可能性が高
いですから、まぁしかたがないと妥協しました。

HTMLダイアログの場合、あまり必然性は無いのですが、DESIGN:Nodeが複数展
開されていても、本当に表示されているHWNDはひとつだけという設計にして
います。マウスがノード間を移動すると1pxくらい浮いたり沈んだりするよう
に見えますが、この時非アクティブなノードはDCを画像化して静的なエレメ
ントに変化します。したがって、アクティブなHWND間の競合は原理的に排除
されています。別スレッドで何かを動作させながらという目的には向きませ
んが、アルゴリズムが単純化すると同時に、全体の動きを軽量にできるメリ
ットを優先させています。

DESIGN:Node系で使用された具象クラスを比較して共通な動作をラップする
抽象クラスを作成しています。できるだけ両極端な2つのクラスを別々に書い
て、同じ事を2度書いていたら基底クラスにまとめるという作業です。現実に
はこの工程以外にクラスの継承機構を生成する手立ては無いのですが、教科書
には「基底クラスを設計してから」という綺麗ごとが書いてあるので「C++は
難解」と誤解される最大の要因になっていると思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmの6つのNodeはC++コードではなくHTML中のコード
で生成されています。改良の余地があるかも知れませんが現時点での生成に関する
仕様は下記のとおりです。

<DESIGN:Node id="NODE1" text="ノード１" style="position:absolute;left:100;top:100"><div style="padding:16">....</div></DESIGN:Node>
<DESIGN:Node id="NODE2" text="ノード２" style="position:absolute;left:200;top:200"><div style="padding:16">....</div></DESIGN:Node>

DESIGN:Nodeには表題textが必須です。position:absolute;left:***;top:***は必須です。
中身は何でも構いませんが、DESIGN:Htmlというモードレスダイアログを定義しています。

<DESIGN:Html src="draw.htm" style="width:300;height:200" status="yes"></DESIGN:Html>
表示すべきsrcは必須です。本体との相対パス解釈されます。styleでのwidth,heightは
省略した場合デフォルトサイズが用意されています。status="yes"でステータス
バーが表示されます。文字の書き込み方法はシンプルダイアログと同じです。

また、親子関係の締結はエレメントが提供するSetParent関数で行います。
デモでは生成時にIDを付与し、直線的に関係を定義しています。現時点では
削除には対応していませんが、ノードの生成はスクリプトから動的に行って
も問題は生じないはずです。

<script language="jscript">
NODE2.SetParent(NODE1);
NODE3.SetParent(NODE2);
NODE4.SetParent(NODE3);
NODE5.SetParent(NODE4);
NODE6.SetParent(NODE5);
</script>

これでHTMLウインドウ外部の機能拡張、HTMLウインドウ内部の機能拡張に関す
る情報収集とスケルトンモジュールが出揃いました。特にHTMLウインドウ内部
においてDESIGN:MenuやNodeのように、自由な発想で独自コントロールを生成
しながらDHTMLとは一線を隔す速度を実現するテクニックは、どこに出しても恥
ずかしくない製品作りの基盤になる部分だと感じています。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmの6つのNodeはダイアログとエディタの混在で構
成されています。DESIGN:Editの方は仕様が固まっていませんから、決定して
から公開したいと思います。このエディタでコマンドプロンプトをリダイレク
トし、簡単にコピペ可能なコンソールを作れば有益かも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN系エレメントのメモリ開放を精査して完全な開放を
確認したバイナリです。メモリの未開放はコンピューターを壊すわけではあ
りませんが、何十回か起動させると「なんか前より重いよね」という症状に
なって現れます。PCを再起動させると快適という場合、いずれかのアプリケ
ーションがメモリリークしている可能性があるわけです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Node系の修正を行いました。終了時のアクティブ
委譲問題、Nodeを開いたまま終了した時の問題への対応を行いました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeを50%透過させてみました。アクティブな内部
HWNDは透過しない状態にしていますが、この方がむしろ自然な感じがします。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeにalpha属性を負荷して透過度を指定可能としま
した。同時にノードのアクティブ、開示、非開示でzIndexを管理しました。
後ろに回り込んだノードを迅速にアクティブとできる工夫があればさらに使い
やすいとは思いますが、今のところいいアイディアが浮かびません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmはMenuとNodeの連動を模索する内容となっています。
メニューからノードの全開、全閉、移動を行っています。今日中には縦、横のツ
リー形成を完成させてサンプル実行システムにしたいと考えています。恐らく
「HTABOXって何？」なユーザーが最初に目にする生成物になりますので、新たな
アプリケーションのコンセプトを具現化したものでなければなりません。

一旦解決済みだと思っていたスクロールバー問題と、HWND非アクティブ時の
画像生成に課題が残っているようです。透過度を設定可能にした影響かも知
れませんが、原因を究明して改善する予定です。

すべてはCSSとしての透過度に触ったことによるものと思われます。それより
若干速度的には劣りますが、GDI+的手法の透過では問題が生じないようです
から、手法そのものを切り替えることで解決できそうです。

総ての透過転送をGDI+で行ってみましたが、描画速度が足を引っ張ってノード
のドラッグ反応が遅くとてもお見せできるものにはなりませんでした。平行し
て、内容HWNDのRgn領域判定を正確に行う方式も検討していましたので、再度
その方向で取り組んでいます。それにしても単なるBitBltとほぼ等価な速度で
透過転送を行っているCSSフィルタはとても優秀だと言えます。最も高度な解決
方法は自作COMインスタンスをCSSフィルタとして認識させることですが、今回
はとてもそこまで手を出す時間がありません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。なんとか納得できる仕上がりになりました。ノードはクリック
して初めてアクティブとなり、アクティブなノード内のHWND上にマウスが存在
した場合HWNDは活性化というルールにしました。透過な状態で目的ノードを選
ぶ段階からHWNDが活性化しては邪魔と判断しました。これで別に説明がなくとも
目的のサブアプリケーションを実行してもらえるシステムになったと思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmを実際にご覧になった方はお気づきでしょうが、
水平と垂直のライン描画アルゴリズムが存在しなかったので追加し、デザイン
系の開発をひとまず終結することができました。手前味噌ですが、私の予想
を上回る完成度となりました。Windowsの中の小さなOSという表現があながち
妄言でもなくなりました。

DESIGN系を使えば実際のスクリプト動作までに時間を稼ぐことができます。
表示されるノードはディスクトップのアイコンのような意味を持ちますので、
その間に.NET環境のロードを行ってもユーザーは負担に思わないでしょう。
走り出してしまえば.NETはIDispatchExの呪縛から逃れられないJScriptより
高速ですから主力スクリプトとして考えてもいい時期に来ているかも知れま
せん。

DESIGN:Nodeで無駄な領域への再描画要求が出ていましたので、修正していま
す。これが終了すれば500Mhz程度のノートブックでもストレス無く動作するも
のになるだろうと予測します。結局、私が設定した自分のハードルはとても高
いものでして、プロフェッショナルなプログラマーが一目して「書けない」と
判断するものでなければならないというものです。書けるものをわざわざ買う
人はいないでしょうから。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN.htmは表示領域以外にNodeが存在する状態で、ソフトウ
ェア的にOpen、Closeを行った場合に何が起きるかを検証した内容となっています。
Windowsプログラミング全般に言えることですが、「表示」とは要求するもので
あって、実際のハードウェア操作はシステムが行いますから、要求してもシステム
が更新の必要が無い領域と判断すれば表示内容は変化しないという結論です。
したがって、遠く離れたノードが実際に開かれるかはシステムだけが知っている
という状態ですが、実用上は支障が無いと判断します。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。こんなに単純なアクティブ委譲システムですが、ドラッグ
用のイベントとウインドウリサイズとスクロールによってフォーカスが失わ
れた後に、HWNDを復元するマウスイベント処理が思うように行かず、久しぶ
りにキーボードを投げつけそうになりましたがなんとか解決できたようです。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN系のソースを整理しながら完全な開放処理を確認した
バイナリです。私は開発中コードと省みる必要の無い言わばコンパイル済みコ
ードを明確に分けます。省みる必要が無い場合、大まかな流れが見やすいよう
に一行を長いものにします。つまりfor...if...else...のように。これは後日
見た場合に「十分検証済みだから触るな」というマークにもなります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeにサイズ縮小、拡大ボタンを追加しました。
DESIGN系の抽象化はほぼ完了し、具象関数を2,3記述するだけで、類似なカス
タムエレメントを短時間で開発できる体制となりました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Cmdが追加されました。これによりコンソールウイン
ドウを自由にHTML中に埋め込む事ができます。また、別プロセスCMD.exeとの
パイプ通信を行い、HTML中に表示されているのはリッチテキストですから、
出力結果をそのままエディタ等に貼り付けることも可能です。

いかにもコマンドプロンプトという意味で背景を黒にしてみましたが、エデ
ィタへコピペした時、リッチエディット同士なので背景色もそのまま張り付
くことから、通常の白い背景に変更すべきかも、と考えています。

このDESIGN:Cmdでcscript.exe等も動作できるはずです。つまり別プロセスCMD
が別プロセスWSHを起動している状態になりますが、アプリケーションとしては
全く単一でシームレスなものに見えるはずです。HTMLがビヘイビアの夢を見て
ビヘイビアがCMDの夢を見て、CMDがWSHの....となると私の想像力の限界を超え
ますので、どんな使い方があるのかは皆さんにお任せします。

CMD.exe中継で一番悩ましいのは、CMDが表示したい文字列が終わっているのか
まだ途中なのかの判断です。通常のパイプ通信なら終端記号を決められますが、
単なる標準出力ハンドルですから終端に特別な記号を付加したりはできません。
フックすれば何でもありですが、賢い解決策ではない気がします。

もし、コンソールが上下に２分割されていて、上部はCMDの結果、下部はコマン
ド入力とすれば、上部は保険としてタイマー割り込みによりCMD出力をチェック
できますから取りこぼしが起きないと考えます。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Cmdの結果文字取得アルゴリズムを変更しました。
読み取りを別スレッドでループさせ、取得できた文字列を表示する。終端が
ないので最終ReadFileは制御を返さないが、次回コマンド時に当該スレッド
をTerminateThreadするという単純な方式に変更しました。

従来c:\へ移動してからtreeコマンドで全ディレクトリ構造を表示させた場
合、タイムアウトと判断し、表示が完全ではない可能性がありましたが、こ
れでCMD.exeが出力する文字列は確実に表示されるはずです。

ttp://kuroda.bglb.jp/htabox/cmdhook.zip
を参考目的で公開します。これはCMD.exeを非表示中継してリッチエディット
で表示するコンパクトなEXEですが、WScript.ShellのExecと、結果として返
されるWshScriptExecの標準入出力で構成されています。CMD中継は当初この
手法で始めたのですが、なかなか落としどころがつかめずボツになっていた
ものを修正したバイナリです。

素のWSH環境でこれをやろうと思うと３つの問題があります。
１．WScript.ShellのExecはSW_HIDEなウインドウ生成ができない。
２．TextStreamのWrite系はClose以外にストリームをフラッシュするすべが無い。
３．TextStreamのRead系はパイプからの取得データが空でも制御を返さない。

でも逆に言えば問題はこの３点だけですから、wshom.ocxとscrrun.dllがマップ
しているkernel32.dllのメモリイメージを操作すればいいという展開です。

DESIGN:Cmdで採用したネイティブ手法の場合終端記号問題は、単にReadを放置
するという解決策となりましたが、こちらはReadが制御を返さない状態となり
ますので別の解決策が必要です。悩んだ末にWrite時、 echo __END__を付加し
てRead時にコマンド結果文字列に__END__が出現したらそれ以上読まない。つま
り独自な終端ルールを導入することで克服しようとしています。この終端文字
列は表には表れませんから、単に中継しているように見えます。

CMD.exeが最後に標準出力へ書き込んだタイミングが正確にわかれば、さらに
単純化できますので、パフォーマンスモニタ系で監視する実験を行いましたが、
考えてみればdirのような内部コマンドには有効ですが、treeのような外部コマ
ンドの場合CMDへの監視だけではかすりもしないわけで、現状の独自終端ルール
は意外とベストな選択かもしれないと認識するに至りました。

HTMLアプリケーションやスクリプトの最大の欠点は、一旦走り出すと全リソ
ースを独占することにあります。ループ演算しているHTMLがあれば、他のア
プリケーションの再描画さえままならなくなります。自身のCPU占有率を認識
し、必要によってスクリプトスレッドの優先勲位を下げる賢い仕組みが必要
ですし、今回久しぶりにパフォーマンスモニタ系を触ってみて、十分実現可
能だろうと確信できました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Cmdへ空のEnterを行った場合、本物CMDと挙動が異
なる部分を修正しました。表示ウインドウはリッチエディットですから書式
的には何でもありなんですが、CMDの中継を考えた場合、SYSTEM系フォントで
ないと描画レスポンスが落ちることから現在の仕様としています。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Cmdでipconfig等のコマンドを実行した場合、出力
された文字列の改行コードを過剰に評価する事への修正を行いました。

パフォーマンスモニタのMSDNを眺めていたらSystem Monitor Automation Interface
なるものがあってHTML中にパフォーマンスモニタのGUIをそのまま埋め込める
ことを知りました。確かに私の環境でHTABOXが実行するHTML中に下記コード
を追加すると表示されます。
<OBJECT
CLASSID="clsid:C4D2D8E0-D1DD-11CE-940F-008029004347"
ID="MyMonitor"
HEIGHT=80%
WIDTH=100% VIEWASTEXT>
</OBJECT>

OBJECTタグのwidth="100%"というのは「目から鱗」かも知れません。その発想
がありませんでした。HTML中にネイティブなHWNDを埋め込む場合、常にドキュ
メント内座標、スクロールバーが出現しているか、等を気にするコストが余計
にかかるのですが、width="100%" height="100%"でスクロールバー非表示なら
僅かなコストであらゆるネイティブウインドウをHTMLページとして扱う事が可
能になります。

HTABOXのヘルプを書く段階で、タブ内にHTML以外のウインドウがある場合、
新たなトップレベルウインドウを設計する必要に迫られるわけですが、上記
手法ならその必要は無くなります。ネイティブなものをわざわざOBJECTにし
てHTMLに埋め込もうなどとは誰も思わないでしょうが、これを導入すれば、
すべてのウインドウをHTABOX:TabCtrlへのURL指定でチョイスできるという
恐ろしいほど抽象化されたシステムが出来上がるでしょう。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。test.htmの先頭タブはネイティブHWNDのOBJECT埋め込みで
生成されています。思惑通りサイズ100%が指定されたOBJECTにはドキュメント
サイズの変更ごとに必ず通知が到達しますから、ほとんど何もする必要がなく
ごく自然なウインドウ表示が可能でした。どちらかをどちらかに埋め込むとい
うことばかり考えていましたので100%ならこんなに単純だということにもっと
早く気づくべきでした。

cmd.exeを使い慣れていない方にとって最も有効ななコマンドは「cmd /?」
です。つまり更に子としてcmd.exeを起動し、ヘルプ文字列を表示します。
HTABOXの場合、全文をスクロールして読み返せますから便利です。次に有効
なコマンドは「help」です。これで主要コマンドを一覧できます。各コマンド
に/?オプションを付ければ、各コマンドのヘルプ文字列が表示されます。

単純に私の思慮が足りない事が原因ですが、CMD側がマルチバイトの片方で送
信を区切った場合に文字化けがあります。CMDに/Uを付けて解決かと思ったの
ですが、そう単純には解決しないようです。wshom.ocxとscrrun.dllの方は原
理的に行末を認識した動作となりますので、場合によってはそちらへ乗り換え
るかも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。前述の部分を修正しました。ipconfigの出力には、恐らく
意図していない\rが付加されることを確認していますが、その除去部分でミス
があったと思われます。ただし、マルチバイト文字の分割が起これば文字化け
するはずなので、たまたま起きていないだけかも知れません。UNICODEへ統一
できるのであれば、そうしたいと考えています。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。少なくとも開発環境上での結果ですが、/Uでユニコード出力
されるのは内部コマンドのみで外部コマンドはマルチバイトコードを出力する
ことから、完全にマルチバイト以外である0x01から0x3fが終端である場合のみ
文字列評価し、それ以外はバイトコードを蓄積することで文字化けの可能性を
排除しました。蓄積は軽量な線形リストで行いますので速度的なデメリットも
感じられないと思います。

CMDのリッチエディット中継で次回コマンドと解釈される文字の決定方法は
最終出力文字の次からEnterが入力される間の文字列です。文字列インデッ
クスはリッチエディットが認識しているCPです。したがって、出力文字列
を切り取り、従前の最終CPより前でコマンドが入力されることを想定して
いません。リッチエディットですから自由にカーソルを移動できますが、
結果を切り取るとすれば全結果が出力された後になります。現状のエディタ
最大文字数は0x100000(約100万文字)です。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。タブにネイティブウインドウが混在していた場合のメニュー
仕様を決定しました。変更点はただ一点、メニューのヘルプ文字表示コールバ
ック関数内でcells[i]という表現を禁忌としcells.item(i)へ統一します。

STATUS.SetText(0, obj.cells[i].item.title);
この呼び出しはJavaScriptのArrayを期待するものですからエラーです。

STATUS.SetText(0, obj.cells.item(i).title);
ネイティブウインドウ側では実際のテーブルインスタンスを生成せず、
cellsというGET、itemというMETHOD、titleというGETに答えるディスパッチ
でテーブルをエミュレートします。ネイティブページが混在しなければ従来の
記述もエラーとはなりませんが、混乱を避ける意味で統一した扱いとします。

恐らく前述のエミュレートテーブルディスパッチがらみで、タブを頻繁に切り
替えた場合、ネイティブウインドウのタブの表示タイミングでストールする
ことを確認しました。ここは手を抜かずに本物のTableを生成する必要がある
のかも知れません。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。前述の不具合を修正しました。確実なインスタンスの開放
を意識するあまり、タブの切り替え時にエミュレートテーブルディスパッチ
のインスタンスが消失していたという原因でした。

ネイティブに生成されたあらゆるHWNDをOBJECTタグ経由でHTML偽装する事は
私にとって大変大きな意味を持ちます。「HTABOXのウインドウでは実現でき
ない」という理由で別なアプリケーションウインドウを書く必要が無くなり
ます。実現できなければ、実現できるようにHTABOXのウインドウへ機能を追
加する。というアプローチへ統一できるからです。

現状ではHTABOXのタブにDESIGN:NodeにHTML表示要素があるとストールします
ので、HTML生成パターンを変化させながらタブ内に表示させるコードを模索
しています。この作業が終われば、単一なHTML（タブは複数ですが）で全機
能をお見せできることになります。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。Design.htmはタブに格納されました。HTABOXの全機能は添付
test.htmで確認することができます。DESIGN.Node内のHTMLは同一スレッドの
直接ドキュメント埋め込み手法に変更されました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。一部デバッグ用機能が有効なままでしたので、修正しまし
た。技術的な情報収集は完了しました。ある方向に進展してから「実は間違っ
ていました」を回避するために多くの時間を費やしてしまいましたが、回り道
して、多くのコードを書いては捨てた分だけ、現在の手法の正しさを確信でき
ます。そして、この手法はWindowsOSが現在の姿で存在する限り有効だと推定
されます。ありがとうございました。

GUIについては十分な情報が得られたので、スクリプトの記述、デバッグ環境
に、もう一工夫する余地は無いのかと試行錯誤しています。WSHエンジンへの
介入を繰り返しましたが、どうもうまく行きません。.NETのJSCコンパイラで、
下位互換モードのソースをコンパイルするというのが、賢い選択なのかも知
れません。

HTML生成の初期に介入してスクリプトエレメントの未初期化IActiveScriptを
操作できないのか？という実験は成功しました。この辺を突破口に普通にデバ
ッグできる気軽さを持ちながら、いざと言うときはギアチェンジできるもの
が組めないかと考えています。

HTML中のActiveScript系インターフェースはコンテキストがきちんと整理され
ていて扱いやすいようです。低水準なメモリ書き換えでAPIやクラスの動作を
変更する場合、例えばモードレスダイアログのようにドキュメント自体の実行
コンテキストが異なると、レジスタを踏み外してプログラムがすっ飛ぶことも
ありますが、ActiveScript系では今のところそういった兆候はありません。

ソースコードがパースされる動作に介入してみましたが、何の問題もありませ
んでした。したがって、従来はエンコードされたコードをデコードする関数を
表しな状態で置かねばなりませんでしたが、単にパース直前で待ち構えて、デ
コードできることになります。また、サブでVBScriptエンジンを起動しておき、
JavaScriptコード内にclass 宣言が存在した場合、部分的にVBSとしてパース
して、生成ディスパッチを追加することもできます。

HTML中に何の前触れもなく onclick="HOGE.test()"が存在した場合、自動的
にHOGEの在り処を検索する動作が可能か？を課題に実験を行っています。
これがスムーズに実現できれば、未知なオブジェクトHOGEが出現した時、
同名JS、VBSが存在すればパースする。同名DLLが存在すればディスパッチ
を取得する。という柔軟性を持たせることができます。つまり、HTML側を
一文字も書き換えずに、周辺ファイルの出し入れでデバッグとリリースを
切り替えることが可能となります。

WSHの動作フックには敗北していましたが、HTMLのスクリプトエンジンを眺め
ることで、API的手法ではなく、COM的な手法で完全に目的が達成できることに
気づきました。実際にスクリプトエンジンの動作を報告するEXEを公開します。
ttp://kuroda.bglb.jp/htabox/wsh.zip

添付ReadMe.txtにも簡単な説明を書きましたが、WshEx.exeは起動するとファ
イルダイアログを表示し、指定されたファイルをcscript.exe //Dで実行し
その標準出力をリッチエディットで中継します。この時、別プロセス内で生
成されるスクリプトエンジンの動作を報告します。報告できるということは
その動作を任意なものに置き換えることも可能だということを意味します。

cscript.exe内部への侵入はdllを送りつけることで実現されていますから、
WshEx.exeを実行する場合、Wsh.dllが同一ディレクトリに存在しなければな
りません。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。少しばかりアプリケーションとして体裁を整え、Fileメニ
ューが追加されました。WshEx.exeは独自にエンコードされたソースをデコー
ドしてWSHへパースさせる能力があります。WshEx.exeはスクリプトパース時
に未エンコードソースとエンコードソースを表示します。Fileメニューから
両者のソースを別ファイルとして保存することができます。

添付test.jsは未エンコードであり、添付out.jsはtest.js実行時に表示された
エンコードソースを保存したものです。尚、現時点でのエンコードルールは単
なるBASE64です。

cscriptとwscriptは引数ファイル拡張子でエンジンを初期化するでしょうか
ら、何らかのダミーファイルはいるでしょうが、実際のパースは完全に掌握
されていますので、DLL中の文字列リソースだろうが、HTTP経由のストリーム
だろうが、何ら問題は生じません。またWSH名前空間に任意な機能を追加する
こともごく自然に行えます。スクリプトがSTARTする前に追加を完了させる事
ができますので、Just-In-Time デバッグ機能付きのスクリプトエンジンを作
成したのに等しい状態となります。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。WSH環境にHTMLダイアログ生成関数を追加して表示した場合の
スクリプトサイトを監視できるコードをtest.jsに追加しました。エンジンが2回
初期化されますので、多少見にくいですが、HTML環境の場合windowが既定名前
空間に設定される様子がわかります。HTMLダイアログを表示している
HELPER.ShowHTMLDialog(url, arg, option);
は実験的な関数ですから仕様が変更される可能性があります。

非力な別環境だとDLLの注入が遅れてしまう事を確認しました。どうしても
別プロセスへの介入はタイミング問題が生じるのでもう一工夫必要なようで
す。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。WSH側の実行優先順位を一時的に下げ、フック手法をより
穏やかなものとして妥協点を見出しました。HTABOXはWSHではなくMSHTMLの
みを対象としたシンプルな構造としていますが、やはり大規模なスクリプト
をHTML中のスクリプトタグやSRC参照先に置くのはいかがなものかという気
がします。すると、JSやVBS単体で、非登録COMを認識するデバッグ環境が必
要なわけですが、私はJust-In-Time 連携というのが面倒そうで書いていませ
んでしたから、人様が書いたWSHを自由に使わせてもらおうという展開です。

今回HTML、WSHのスクリプトエンジンを眺めてみて、やはりソースコードの
パースが必要な状態での隠蔽はあくまで「カジュアルクラック対策」だと
再認識しました。勿論対策はいくつか考えられますが、究極には隠蔽側と
クラック側のどちらが先にアドレスを書き換えに成功するかという泥仕合
になるでしょうから、エレガントが解決策は無いだろうと思います。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。command.jsとappend.jsを追加しました。前者は標準入力
をコマンドとして逐次パースします。後者は標準入力をファイルパスとみな
してパースします。execと異なるのは、従前の変数等がクリアされることで
す。ファイルパスの入力はメニューの[Append File]で行えます。

HTMLとWSHのスクリプトエンジンを見比べながら共通に使える実行時インスタ
ンス提供システムを模索していますが、両者の振る舞いは異なるようです。
WSHの方はIDispatchを基準インターフェースとしていますが、HTMLでJScript
エレメントな場合IDispatchExを常に期待しているように見えます。
ブラウザの方は他社との競争もあるでしょうから、速度向上の為に何らかの
工夫が凝らされているというのは、実にありそうな話です。

今回のスクリプトエンジン分析結果から、導き出された方向は「隠蔽された
状態を普通にデバッグするツール」の必要を指し示しているように感じます。
もし製品にこの機能が組み込まれるとすれば、ユーザー固有のキーで暗号化
されたコードであることを条件に、HTMLやWSHのアクティブデバッグを可能と
するルールになるでしょう。

スクリプトをDLL化するモジュールを書いています。と言ってもディスパッチ
のシリアライズというのは夢のまた夢ですから、DLL内のスクリプトエンジンが
パースしてディスパッチを形成する方式です。呼び出し側が取得したディスパ
ッチがスクリプトサイトを要求していた場合、サイトをセットする余地がある
という部分だけすこし賢い設計になります。また、このDLLを同名、同機能な
ネイティブDLLに置き換えても本体は動作するというところがみそです。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。JSのDLL化実験が追加されました。ReadMe.txtでも説明して
いますが概要を説明します。

CallDll.jsにはHOGE.Popup();が記述されていますが、HOGEは未知なオブジェクト
ですからそのままではエラーです。

MakeDll.batを起動するとファイルダイアログが表示されますからHOGE.jsを
選択してHOGE.dllを生成してください。もう一度WshEx.exeでCallDll.jsを実
行すれば正常動作となります。

本来はHOGEが要求され場合、HOGE.jsがあればそのままパース、HOGE.dllがあれ
ばDllGetClassObjectをコールしますが、素のjs認識を無効化してDLL認識が正常
かを確認している状態になります。現状ではWSHで実験していますが、これと同
じ機構をHTMLにも適用できます。また、DLL内に独自サイトを置き本体デバッガ
と切り離せば、より高速でソースが隠蔽を前提としたシステムとなります。

WSHからHTMLへ環境を移して実験を行っています。WSHの場合は別プロセスで
実行を開始した直後に介入するという苦しい展開ですから、PCが冷えている
場合、フックに失敗する局面もありましたが、HTMLの場合は自プロセス内に
生成できますからそういった心配とは無関係です。また、IActiveScriptへは
WSHよりも多彩なインターフェース要求が到達するようです。

WSHのプロジェクトを離れる前に、CreateRemoteThreadでの制御を試みたらこ
れが正解だったようで、プライマリースレッドをサスペンドし、送りつけたモ
ジュールを開始初期に安定して実行することができました。ディスパッチ系は
プロセス境界を越えてマーシャリングされますから、分散プロセスで目的を達
成することもできます。ただしHTABOXと関連付けると複雑になりすぎるので拡
張WSH環境として独立した製品になるだろうと思います。

cscript,wscriptを自由に扱えた事は大変大きな収穫でした。HTMLの場合、
スクリプト自体の動作よりCSSという重い仕組みが描画の足を引っ張るので、
解析系ツールのようにシンプルな情報を高速に出力したい場合は、どうも気
合が入らない動作になってしまいますが、リッチエディット＋cscriptなら
高速に出力できますし、続行しますか「はい」「いいえ」のような選択肢
をハイパーリンクで表現し、マウスで操作可能なコンソールアプリケーショ
ンを作成できます。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。PC起動後、初回のWshEx.exe起動でフックが失敗する事に
対する修正を行いました。またWindows7での正常動作も確認しました。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。たまにフックが失敗する原因は、既にメモリに浮動されている
プロセスのメモリを書き換えている訳ですから、変更をCPUへ通知する必要がある
のですが、その部分を書いていなかったというのが原因のようです。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。未知のオブジェクトが存在したら...という機能を排除し、
WSH.CreateObjectを拡張してスクリプト由来DLLをロードすることに変更し
ました。
var obj = WSH.CreateObject("HOGE");
obj.Popup("TEST");
のCreateObjectは通常失敗しますが、WshExは失敗をリカバーして同一ディレク
トリにDLLを検索し、存在した場合ディスパッチを返します。将来はCLSID文字
列を指定した汎用COMDLL呼び出しもサポートする予定です。つまりレジストリ
登録不要な状態で、マニフェストを書く必要も無く、動的に任意なCOMDLLを利
用可能となります。

概ねWSH拡張に関する情報収集も終わりました。HTMLの場合数メガ以上のDLL
がマッピングされるわけですが、WSHの場合はOCXを入れても200K程度だと推
定します。しかもエンジン自体は描画系のもたつきとは無関係ですから大変
軽量に起動します。

HTML中スクリプトでのドキュメントのようにITextDopcumentの拡張を公開し
て、レスポンスを重視したアプリケーション作成環境があってもいいと感じ
ます。

HTMLアプリケーションの発想を逆転させてWSFファイル中にHTMLを記述する
ためにはどんな追加措置が必要かを確認しています。恐らくHTML評価する
場合にWSHスクリプトが邪魔なので、独自プロトコルで</html>以降を無効
にすればいいような気がします。全体のイメージはこんな風です。

<job id="main">
<html>
<head>
<title>test</title>
</head>
<body></body>
</html>
<script language="JScript">
WScript.Echo("JScript");
</script>
<script language="VBScript">
WScript.Echo "VBScript"
</script>
</job>

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。test.wsfを追加しました。WshEx.exeで実行するとWSH環境
Jobから自身ファイルをHTMLとしてダイアログ表示します。wsfが整形XMLでな
ければならないというところが想定外でしたが、総てを単一ファイルにまとめ
尚且つ高速な起動が必要な場合はこんな手法も有効かと思います。

<job id="main">
　　<html>
　　　　<head><title>test</title></head>
　　　　<body>
　　　　　　<h1>Window Script Host</h1>
　　　　　　<input type="button" value="TEST" onclick="test()"/>
　　　　　　<script language="jscript">
　　　　　　function test()
　　　　　　{
　　　　　　　　alert("test");
　　　　　　}
　　　　　　window.returnValue = 10;
　　　　　　</script>
　　　　</body>
　　</html>
　　
　　<script language="JScript">
　　　　var WSS = new ActiveXObject("WScript.Shell");
　　　　WSS.Popup("Hello from WSF");
　　　　var ret = HELPER.ShowHTMLDialog("wsf://" + WSH.ScriptFullName, WSH, "");
　　　　WSS.Popup("Return = " + ret);　　
　　</script>
　　<script language="VBScript">
　　</script>
</job>
とういう構成でHTML側スクリプト、WSH側スクリプトを個別にデバッグ可能
なようです。これ全体をDLL化してHTABOXは前半をHTMLリソースとして表示
に使い、後半WSH部をディスパッチとしてHTML中に取り込むというのが、現在
描いている理想形態です。ただし、こなれるには2,3アプリケーションを書く
必要がありますから、3.00リリース時は公開されない機能となるでしょう。

今更なんですが、WSH拡張プログラムではVBSコードがディスパッチへ変換さ
れる機序を把握できていません。JScript的観点からは魔法のように感じられ
ます。まるでWindows自体がVBSをパースしているかのようです。もし、VBSの
構文規則をもうすこしC++風にできれば強力な武器になる気がします。

wsf状態でのJScriptとVBScript連携を模索しましたが、HTML中とは異なり
相互呼び出しには問題が存在し、それを乗り越えるための手立てを打つく
らいなら連携自体を行わないとした方がわかりやすいようです。

現状のWshExの機能をHTABOXAPPに組み込み、スクリプトから生成されるDLL
自体にWSHプロセスへのインジェクション機能を持たせた形が最終形態とな
るでしょう。

当初はWSHエンジンはデバッグ時だけ使用する予定でしたが、配布先でも利用
できればそれにこした事はないので、DLLファイルをwsfに偽装できるかについ
て検証してみました。架空のwsfパスを与え内部でのファイルチェックを総て
制御できれば可能ですが、3つくらいのAPIをたどったところでくじけました。
もっと簡単な方法は実在する空なwsfを引数にし、当該ファイルへのIOだけを
制御する事ですので、検証したところ、これは通るようです。

汎用なWSH拡張ツールとしてWshEx.exe & Wsh.dllをまとめています。面白い
ことにWSHのプライマリスレッドからのコモンダイアログ表示は成功しないか、
若しくは不安定な状態となります。これはGUIスレッドが形成されていないか
らかも知れません。

そこでWshEx.exeは空なHTMLインスタンスを生成し.......
結果としてWSHからUTIL.GetOpenFileNameを呼べるようにしました。
副産物としてwindowのメソッドは何でも可能になりました。それに伴いWSH側
に追加されるHELPERディスパッチからダイアログ表示関数は削除されます。

GUIを充実させたいなら、はじめからHTABOXを使ったもらい、高速な動作の途
中でちょっとGUI系が欲しいというニーズにはベストマッチすると思います。

WshEx.exeは単体JS、VBSを対象としません。スクリプトは総てWSF形式としま
す。これはWSF形式の場合ならスクリプトエンジンがグローバルディスパッチ
を確実に取得することによります。WSHはご存知のとおり<html></html>の代わ
りに<job></job>があって中にHTMLと同じようにスクリプトブロックを書く形
式です。また、WSF形式ならJS、VBSの混在も可能です。ただし、JS->VBS->JS
というような中継呼び出しでは予期せぬ結果を招く場合があるようです。

中継標準入力にコマンドや新たなWSFパスの入力を行うべきか？の回答を得る
ための情報収に一日費やしてしまいました。結論は否で、機構が複雑化する
割にはメリットが無いと判断しました。そのかわりメニューから新たなWSF
を選択した場合はタブウインドウを追加して実行するものとします。勿論不
要なタブを削除することも可能です。

個々のWSFは別プロセスで実行されます。出力データは各タブのエディタ間で
コピペできますし、プログラム的な連携が必要なら各インスタンスへ提供され
る非表示HTMLのwindowインスタンスを通じて通信できます。

ttp://kuroda.bglb.jp/htabox/wsh.zip
未完ですが、やろうとしていることを見ていただくために更新しました。
新たなWSFの実行は新たなタブの出現として、タブ内には純粋に標準出力だけ
を表示し、先頭タブに簡単な説明と動作ログを表示するデザインとしました。

添付empty.wsfはDLL内リソースをwsfとして実行するためのものです。現時点
ではDLLのリソースも空ですから。その旨の報告が出ます。

タブによる複数インスタンス生成を行う途中で何か踏み外しているようです。
window.showModalDialogは成功しますが、閉じた後スレッドが走り始めると
ストールします。また、独自プロトコルもなぜか機能しません。いつものこ
とですが、こういった時は一旦健全なソースへ戻って、やった事をもう一度
振り返りながら何処で破綻するのかを確認するしかありません。
誰かも言ってましたが、自分の予想を裏切る結果こそが最大の教師です。

WSF環境ではデフォルトでプロトコル系を拡張しているから、容易にてこ入れ
できないというのが真相なようです。同一WSFへHTMLを入れ込むというのが、
できたとしてもメリットが無い事ですので、深入りしないことにします。
ただ、欲を言えばHTMLファイルがとっちらかった状況は美しくありませんから
DLL内リソースへリダイレクトさせる工夫ができればと考えています。

複数プロセスが動くものですから頭が混乱していましたが、たとえWSH側での
ダイアログ表示要求であっても親HTMLドキュメントインスタンスはWshEx.exe
側にありますから、プロトコル系の制御もWshEx.exe側で可能だということに
気づきませんでした。

ttp://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。概ねやりたい事は実現できました。
wsh.iniが設定ファイルとして追加されました。cscript/wscriptを選択して
動作させる事ができます。存在しなかった場合の内容はcscript.exe //D です。
MakeDll.batは単に起動するとwsh.dllを原型とし、ダイアログで選択されたWSF
を格納するDLLを生成します。この時Hoge_dll.wsfというファイルも同時に作成
されます。このファイルは空ですが、DLLをWSFへ偽装する場合のダミーWSFとし
て使われます。したがってWSF格納済みDLLを実行したい場合は当該_dll.wsfを
実行することになります。

DLL単体でのデバッグ環境の方が先行した形になりましたが、隠蔽コードを
非デバッグな自前エンジンで実行する部分を書いています。この時スクリプ
トがHTML表示を要求した場合のURL記述が非格納状態のwsfと同一にできれば
パーフェクトです。自前エンジンには例によって.NET言語も搭載可能ですか
ら、.NETのウインドウをダイアログ代わりに表示することも可能になる予定
です。

WSHに頼らずに自前でJSとVBの連携エンジンを書いていましたが、実際の動作
実験の段階で本家WSHのように動かせない部分が散見されましたので、不本意
ではありますが、cscript/wscriptのHookをメインにした構成となりそうです。
Window標準添付ですからAPIのようなものと言えなくもないですが、他人が
作ったバイナリをHookして利用するのはあまり心地よいものではありません。

最後のひと踏ん張りで既定スクリプトエンジン全体の解析を行ったところ、
VBSの生成が見えなかったのは私の書き方が悪かっただけで、JSと同じよう
に生成へ関与することが可能でした。これで、他言語エンジンを追加したと
しても相互の連携を確実なものにできます。だたし、別プロセスWSHへ送り
込んだwindowインスタンスはJSからだと見えますが、VBSからだと見えませ
ん。JSは常にディスパッチで通信するからマーシャリングが有効で、VBSは
もっと低水準な通信手段を使っているように思えます。

前述の問題は予想通り、VBがコンテキストにシビアである事が原因でしたの
で、その部分を丁寧に書く事で克服できました。また、スクリプトを強制
中断した場合の処理にずいぶんと悩みましたが、その部分にも決着が着き
ました。これで、WSH、HTML共に、空なファイルを対象として与え、一行
のコードも晒すことなく、捕捉したスクリプトインスタンス、サイトイン
スタンス、を制御してコードを実行する体系ができました。この体制がで
きてしまえば、ソースはストリームだろうが、ファイルだろうが、リソー
スだろうが構いませんし、アクティブデバッグする事も、ソースを隠す事
も自由に選択できます。

スクリプトエンジンの最終的な構造を決定しています。従来の実行EXEは
ScriptEx.exeへ変更されます。これはWSHのみを対象としたものではなく、
実行時にWSHエンジン、HTMLエンジンを選択可能な事を意味します。また、
生成DLLは何れのエンジンでも実行可能です。

このシステムでは「呼び出し元は常にHTMLインスタンスを持っている」
というルールを導入しました。これにより呼び出し元がDLLの関数を呼んで
インスタンスを生成する必要は無くなります。DLLは環境を判断し、呼び出
し元のwindowオブジェクトへパース結果をDLLファイル名のディスパッチと
して追加します。

Windowsプログラミングにおいて、錬金術で言うところの賢者の石が存在する
とすれば、私はアクティブスクリプト系の技術だろうと思います。アプリケ
ーションの寿命中にマウスやキーといった有限回数のイベント分岐を記述する
部分までC++で書くのは、生産性を低下させます。そういった部分はスクリプト
で十分です。その先の低水準な部分をC++でコーディングし両者をスムーズに
連携させることが重要だと考えます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を公開します。添付ReadMeに説明がありますが、WSH、HTMLエンジンを選択
してWSF形式ファイルを実行できます。DLL生成はMakeDll.batにEmpty.dll
をドロップする操作に変更されました。まだVBのMsgBoxが表に出現しない
場合がありますが、これは克服できる問題だと認識しています。

両者を比較すると、やはり別プロセスなWSHは起動にタイムラグが感じられ
ます。ただし動き出してからはWSHのほうがクイッキーな印象を持ちます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。たぶんMsgBoxがウインドウの裏に出る事は回避できたと思い
ます。WSH、HTMLとも表示しているエディタへの入出力を擬似標準入出力として
スクリプトから使う事ができます。

HELPER.Print("キー入力を待機しています\n");
var str = HELPER.Input();
alert(str + " が入力されました");

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。WSHに対して架空のwsfを引数とし、DLLデータをパースさせ
る事に成功しました。これによってDLL生成は単にDLLが1個生成され、WHS、
HTMLの両モードで同じように起動できます。また、DLL作成バッチは単に起動
するとEmpty.dllを実行する事に変更しました。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。windows7 + IE10環境でのすり合わせを行っています。
WSHに対する引数偽装アルゴリズムを見直しWSHエンジンについてはwindows7
での動作を確認しました。HTMLエンジンは現時点で動作しません。

開発というのはサポートする最低ライン環境で行いますから普段はIE７し
か触らないわけですが、VBScriptの生成、HTML中スクリプトのパースタイミ
ング等で上位バージョンでは仕様変更がなされているのだと推定します。
これも空なHTMLではなくOBJECTタグを入れたHTMLにすれば生成初期に介入
できるのですが、表示を担当するHTMLとは別にスクリプトエンジンが欲しい
という目的でしたので、WSHエンジンのみを採用することにします。

当初2つの手法を並立さえた理由は恐らくWSH側は何らかの壁が存在して挫折
するだろうという予感からだったのですが、結果的にはそちらのほうが安定
していたようです。別プロセスでのスクリプト実行は起動時に若干息をつく
部分がありますが、それ以外では同一プロセスより扱いやすいと感じます。
最も端的な例は実行時にスクリプト内で致命的なエラーが発生した場合です。
インプロセスなら当然全体がストールしますが、別プロセスなら本体側にエ
ラーの要因を説明する余地が残されます。

後は総仕上げとしてHTML中のonclick="WSF.hoge()"でWSF又はDLL中のコード
が実行され、呼び出された側では呼び出し側HTML環境を正しく認識できて
いるかを確認するだけとなりました。開発中はHTML中に動作コードがあった
方がデバッグしやすいと思いますが、公開する場合は動作部のコードをその
ままWSFに保存してDLL化しHTMLにはGUIコードしかないという状態がクール
だと思います。これが成功すれば非表示HTMLをスクリプトパース用に利用
するHTABOX:Externは廃止されることになります。また、HTML中での独自エ
ンコードを廃止しソース隠蔽はDLL化に統一すれば、理解しやすいシステム
になると思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。wsh.htmはHTML中に独立したプロセスとしてWSHエンジンを
起動し、生成されたディスパッチをwindowへ追加すると同時にWSH側にも公開
し、alert等の呼び出しを可能とするデモです。

WSFファイルはMakeDll.batを起動し、wsfファイルを指定することでDLL化する
事ができます。HTABOXは指定されたWSFが存在しない場合、自動的に同名DLLを
採用します。現状でのDLL内格納ソースは単純BASE64ですが、本格的な暗号化
を行う事によりソースを堅牢に隠蔽可能です。

実WSFファイルが実行されている場合、エンジンはデバッグ要求に応答します。
しかし、DLLとして実行される場合は応答しない設定です。エラー内容は簡潔
なメッセージボックスで表示されるのみです。当然プロセスへアタッチしても
ソースは見えません。

単体アプリケーションとしてWSHを子プロセス起動する場合は表面化していま
せんでしたが、HTML生成という大仕事の途中でWSHを乗っ取る場合は呼び出し
側動作を抑制しないとハングするという現象の解決に時間がかかりました。
どんなアプリケーションでもクリーンな状態での起動は稀で、他アプリがCPU
をほとんど食い尽くしている状況もありえるわけですから、大変勉強になり
ました。

WSFは普通にJSやVBをかけますが、留意点が一つあります。コード終端に待機
命令が必要です。さもないと折角のパース結果は消失してしまいます。これ
は特別な関数を提供するまでもなく、下記ソースで実現できるようです。

WSH.Sleep(&H7fffffff) 'for VB
WSH.Sleep(0x7fffffff); //for JS

なぜ0x7fffffffが最大値なのかですが、スクリプト界では0x80000000からは
データがVT_R8に拡張されるためVT_I4を期待しているWSH.Sleepではエラー
となるからです。独自待機関数を提供すればそういったトラップが無い状態
にはできます。

尚、WSH側プロセスは親HTABOXプロセスの消失を検出し自動消滅します。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。HTMLエンジン起動は排除されました。例によって説明不足
ですが、単にwindowオブジェクトが追加されているWSH環境だと理解していた
だいて活用していただければ幸いです。
HTABOX側のモジュールもそうですが、静的文字列暗号化が開始されました。

HTABOXで実行するHTML中に下記ビヘイビア表記でWSFが実行されます。

<HTABOX:Wsf src="WSH.wsf"/>

src属性パスに:が含まれない場合、主表示HTMLとの相対パスと認識されます。
素のWSFを実行する為にはEmpty.dllが必須ですが、これはHTML側にあっても
HTABOXAPP.exe側にあっても構いません。

実行WSFをDLL化した場合もsrc属性は拡張子.wsfのままというルールです。
HTABOXは.wsfが存在しない場合.dllに読み替えて実行を試みます。

汚染を除去しました。

471のDLLパス解釈についての説明を訂正します。「:」があった場合は絶対
パスですが、無かった場合はwsfと同一位置でdllファイル名だけが指定さ
れたと解釈します。つまりwsfのファイル名部分を置き換えているだけです。
結果、sub\\hoge.dllも機能しますが、厳密に相対パス構築を行っている
わけではありません。

ものはついででWSF中のOBJECTタグ偽装も試みましたが、レジストリへの確認
動作に割り込むしか方法が見つからず、偽装できたとしても不安定で使い物
になりませんでした。こういった荒療治でも従前部分は極めて安定しています
ので、十分実用に耐えるモジュールだと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。最終的にWSF内のOBJECTタグ偽装に成功しましたが、この
場合progidかclsidかしか渡せませんから、任意なDLLを対象とする柔軟性を
持たせることはできません。今後ScriptEx側が提供するサービスディスパッ
チの種類を選択可能とするような用途には使えるかも知れません。

個人的にVBの言語仕様でなじめない部分をプリプロセスフェーズを設けるこ
とで克服しようとしています。後付でオブジェクトへ何かを追加する必要が
無いのならVBの速度的優位は明らかですから有効に活用すべきです。下記宣言
は現在試験中の#defineです。
'#define \\ \\x5c
'#define {
'#define }
'#define \(\)
'#define dim\s+(\w+)\s*=\s*new\s+ dim\x20$1:set\x20$1\x20=\x20new\x20
'#define delete\s+(\w+) set\x20$1\x20=\x20nothing
'#define dim\s+(\w+)\s*=\s*(\S+) dim\x20$1:$1\x20=\x20$2
'#define ; :

上記正規表現置き換えが実施される場合VBコードは下記のように書けます。
　　function TestFunc()
　　{
　　　　dim a = 12;　　dim b = 20;
　　　　if a = 10 then
　　　　{msgbox(a);}
　　　　else
　　　　{msgbox(b);}
　　　　end if
　　　　TestFunc = 10;
　　}
　　end function　　
　　
　　dim re = TestFunc();　　
　　msgbox(re);
　　class TestClass
　　{
　　　　public function func(str)
　　　　{
　　　　　　msgbox(str);
　　　　}
　　　　end function　　
　　}
　　end class 　　　　
　　dim obj = new TestClass();
　　obj.func("call"); delete obj;

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。添付Simple.wsfは前述のVBScriptコードとなっています。
これに軽量な配列オブジェクトを追加し、class主体な書き方をしていれば
JScriptにも増してC++へのコード移植が容易な言語になる気がします。

VBSriptの弓括弧処理ルーチンを書いて思ったのですが、これで整形したソース
をC++上でネイティブコンパイルすることはそんなに難しくないと感じます。
従来JScriptをネイティブコンパイルするためにというクラスを設計しては
「これでは速度的なメリットが無いのでは？」という感想を持ちましたが、
これならごく当たり前に超高速なネイティブコンパイルスクリプト言語が
実現できると思います。

何かこの辺↓を思い出しました

OreScript時代の幕開け - yukobaのブログ
ttp://d.hatena.ne.jp/yukoba/20071108/p1

ここでのLOGOの実装例や

wise9 > 日本語スクリプト言語JapaScript
ttp://wise9.jp/archives/1724

のように日本語プログラミング的な事も可能なので、HTMLタグを和訳して扱う

JHE日本語HTMLエディタ
ttp://www.vector.co.jp/soft/win95/net/se294408.html

の発想と組み合わせればHTABOXコアで日本語プログラミング開発環境ができそうです

>>479 情報をありがとうございます。今日も書きながら強く思ったのですが、
何かを実現するためにとても面倒な処理を行わなければならず、一文字の間
違いも許されない。しかし、一度できてしまえば二度と書く必要は無いと
いうことです。まさにアプリケーションとはそういった面倒を肩代わりする
存在ですから、母国語->メタ言語->生成物という動作もなかなか興味深い
対象ですね。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。VBS中に書かれた{}の削除と適切なEnd ***の挿入はとても
正規表現だけでは手に負えませんから、#pragma delete_braceが宣言された
場合に自動で行われるものとしました。この手の追加機能は、いろんなパタ
ーンでソースを書かないと不都合や改善点が見えてこないものですから、
今後はGUI用HTML中スクリプト以外はこの改良VBScriptで書こうと考えて
います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。条件演算子、クラスコンストラクタ、デストラクタを
C++互換で記述可能としてみました。下記はクラス宣言と利用コードです。

　　class TestClass
　　{
　　　　TestClass()
　　　　{
　　　　　　msgbox("initialize");
　　　　}
　　　　
　　　　public function func(str)
　　　　{
　　　　　　msgbox(str);
　　　　}
　　
　　　　~TestClass()
　　　　{
　　　　　　msgbox("terminate");
　　　　}
　　};
　　dim obj = new TestClass();
　　obj.func("call"); delete obj;

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。#pragma function_returnを宣言することにより値返却
を通常のreturn(n);で処理できます。下記は例です。

function other(arg1, arg2, arg3)
{
return(arg1 + arg2 + arg3);
}
msgbox(other(1,2,3));

また、どうもコメント中の文字列に反応して動作したり、しなかったりという
という事が起こる気がしますので、そういった指示の如何に関わらずパース前
にコメントと認識される文字列はすべて削除することにしました。これで例え
長大なコメントを書いてもパース時間に影響しないという副産物も生まれます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。正規表現置き換えでのコンストラクタ定義は脆弱なので
プラグマ処理することに変更しました。またVBは構文エラーを通知しない
ので、常にサイトのエラー通知を有効とし表示されるようにしました。
現時点で有効なプラグマは下記のとおりです。

'--------------------------------------------------------------------------------------------------
'c_commentはC形式コメント/*......*/をパース前に除外する
'#pragma c_comment
'--------------------------------------------------------------------------------------------------
'cpp_commentはC++形式コメント//.....をパース前に除外する
'#pragma cpp_comment
'--------------------------------------------------------------------------------------------------
'delete_braceはソース中の{}を削除すると同時に文脈から適切なend **を生成(複数行ifはコメント参照)
'#pragma delete_brace
'--------------------------------------------------------------------------------------------------
'function_returnはreturn(**)が発見された場合ソース前方にfunction定義を探し関数名への代入に置き換え
'#pragma function_return
'--------------------------------------------------------------------------------------------------
'class_constructorはクラス名と同名関数をコンストラクタ、~同名関数をデストラクタとしたコードに変更
'#pragma class_constructor
'--------------------------------------------------------------------------------------------------

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。delete_brace プラグマを拡張してforとwhileのC++的記述
を可能としました。VBには特有のループもありますが、VBコードをそのまま
C++エディタへペーストしてコンパイルする目的ですから、基本的なこの2つ
で十分だと考えます。下記は記述例です。
for(dim c = 0; c <= 5; c += 1)
{
alert(str + CStr(c));
}

dim count = 1;
while(count < 2)
{
count = count + 1;
alert(count);
}

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。具体的なツールを書いて総点検するために、選択された
ファイル内容を16進ダンプするBinary.wsfを書きました。これをJScriptで
やってできない事はありませんが、VT_ARRAY|VT_VARIANTを認識するVBScript
ならさほど余計なことを書かずとも目的を達成できます。配列生成は<object>
タグで生成されたC++コード側ですがコードは極めて単純ですみます。
　　virtual _variant_t __stdcall FileToArray(BSTR path)
　　{
　　　　_variant_t re; re.vt = VT_ARRAY|VT_VARIANT;
　　　　HANDLE h = CreateFile(path, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
　　　　if(h != INVALID_HANDLE_VALUE)
　　　　{
　　　　　　DWORD Size = GetFileSize(h, NULL); BYTE buf[0x800]; DWORD r;
　　　　　　re.parray = SafeArrayCreateVector(VT_VARIANT, 0L, Size);
　　　　　　VARIANTARG *data = (VARIANTARG*)re.parray->pvData;
　　　　　　while(ReadFile(h, &amp;buf, 0x800, &amp;r, NULL))
　　　　　　{
　　　　　　　　for(DWORD c = 0; c < r; c++) VariantCopy(data++, &amp;_variant_t(buf[c]));
　　　　　　　　if(r < 0x800) break;
　　　　　　}
　　　　　　CloseHandle(h);
　　　　　　
　　　　}
　　　　return(re);
　　}

HTMLアプリケーションは文字通りHTMLで開始できますから、非常に間口が広
い環境ではありますが、単なるWEBプログラマはCPUがどんなメモリイメージ
を保持しているかというような低層な事を考えないはずです。したがって
ブラウザに寄りかかった遅いものしか生産できないことになります。
私はHTML「アプリケーション」の方にアクセントを感じます。つまり単なる
WEBサービスでは到底成しえない速度を見せつけてこそアプリケーション
ですし、その為にはVBScriptの有効活用、VBScriptのネイティブコンパイル
が強力な武器になるだろうと思います。

あぁ、while(ReadFile(h, buf, 0x800, &r, NULL))
ですね、エラーではありませんが、試行錯誤していた頃の&が残ってしまい
ました。バイナリも再コンパイルしてアップします。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。if then処理も正規表現では正確な処理ができないことから
if_thenプラグマによる処理としました。16進ダンプ関数は下記のようにすっ
きりと記述できます。
　　public function Disp()
　　{
　　　　dim path = UTIL.GetOpenFileName("", "", "", "");
　　　　if(Len(path) != 0)
　　　　{
　　　　　　dim bytes = External.FileToArray(path);
　　　　　　dim size = UBound(bytes);
　　　　　　
　　　　　　HELPER.Print(path + " size = " + Cstr(size) + vbCrLf);
　　　　　　for(dim c = 0; c <= size; c+=1)
　　　　　　{
　　　　　　　　dim str = Hex(bytes(c));
　　　　　　　　if(Len(str) < 2) str = "0" + str;
　　　　　　　　
　　　　　　　　HELPER.Print(str + "|");
　　　　　　　　if(c mod 16 == 15) HELPER.Print(vbCrLf);
　　　　　　}
　　　　　　HELPER.Print(vbCrLf);
　　　　　　alert("Loop End");
　　　　}
　　　　else
　　　　{
　　　　　　HELPER.Print("Cancel" + vbCrLf);
　　　　}　　　　　　
　　}

実際に拡張VBScriptでソースを書いていて感じたのですが、/**/が使えるだ
けでも非常にコーディングが楽になります。私はコメント自体は//で書くの
ですが、Aモジュールを改良してBにしようという時はAをコピーし前か後ろ
へ貼り付け、元になる方をコメントアウトします。つまりB/*A*/としてBを
改良します。この時Aからコードをコピーして書きすぎた部分を戻す事は頻
繁に起こりますから/**/は必須な機能と言えます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。windows7上での動作確認済みバイナリです。

レジストリアクセスに介入しての<object>偽装を廃止しました。実験的な試
みでしたが、windows7上でこれを行う為には更なる解析が必要であり、実現
できたとしてもそれに見合うメリットが存在しないからです。

デモのExternal.FileToArray呼び出しは個々のスクリプトインスタンスへ提
供されるHELPER.FileToArrayに変更されました。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。改めてIE10環境での全機能動作を確認しました。
HTABOXの<HTABOX:Wsf src="hoge.wsf"/>で参照されるWSFでも拡張されたVBS
を利用可能です。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。親ScriptEx側のwindow.UTIL及び子WSH側のHELPERに
各プロセスのCPU占有率を取得するProcessorTimeプロパティーを追加しまし
た。添付wsfでは
dim time = UTIL.ProcessorTime + HELPER.ProcessorTime;
if(time > 90) WSH.Sleep(1);
で全体のCPU占有率を下げようとしていますが、実際にはProcessorTimeに
コストがかかるためか、顕著な低下を認めることはできませんでした。
実行速度はそれなりに遅くなるので、もうすこし賢い使い方があるのかも
知れません。ちなみにスレッド優先順位変更をSleepの前に実験しましたが、
こちらも結局はシステムが決定してしまうようでサスペンド以外は目立った
変化が無いように見えました。

EXE化規格について最終的な仕様を模索しています。DLLインジェクションに
よるWSH起動が意外と堅牢な事からDLL側に全リソースを格納し、同時に同名
EXEを生成するパターンを高度な生成、単にクローンEXEを生成してリソース
格納するパターンを標準生成とする予定です。自分用ツールな場合は標準生
成が使いやすいでしょうし、本格的なリリースでソース隠蔽及び、拡張VBSを
使用した完全ネイティブ化に備えたい方は高度な生成を行ってもらう事を考
えています。

EXE又はDLLへのリソース格納時に使用される対話型ダイアログを書いていま
した。ダイアログ中のリッチエディットにリンク表示された各ディレクトリ
をクリックすると、ファイルを列挙し格納すると同時にエディタ上の表示に
も反映されるダイアログです。これで取り説に出てくる要素はすべて確定し
たと思われます。WSHを絡めることで単に鈍足なHTMLエンジン中であれこれ
やっている訳ではないということをアピールできればと考えています。

64bit環境での実験機会がありましたので、確認したところWSHの引数ファイ
ル偽装は見抜かれてしまう事が判明しましたので、開発時でデバッグが必要
な場合のみWSH実行とし、リリース時は独自エンジン駆動とすべく書き換えて
います。本来はこうすべきなのですが、面倒なので両方WSHとしていました。
WSHで重要なScriptFullNameなどはHELPERが提供することになります。

細かな問題が複数存在して、思うように進みません。問題の本質はWSHがWSF
を実行するとき、引数WSFファイルが実在しなければならないという点だけ
ですから、実在させるのが自然かも知れません。ただし、内容はバイナリで
ファイルIOはHookされているとすれば実在チェックをクリアしながら任意な
コードを実行できそうに思います。

ttp://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DLLへの全リソース格納に備えて、EXE起動時に同名WSFが存
在していた場合は制御を委ねるルールを採用しました。HTABOXAPP.exeを実行
するとhtaboxapp.wsfによりファイルダイアログが表示されています。ソース
は下記のとおりです。３つ存在するモードを指定して表示しています。

　　//非HTML環境での起動制御WSF
　　var mode = 1;
　　var url = PARENT.GetOpenFileName("実行HTMLファイル", "HTML\\0*.htm;*.html;*.hta\\0", HELPER.ScriptDirectory, "");
　　if(url.length > 0)
　　{
　　　　switch(mode)
　　　　{
　　　　　　case 1: PARENT.CreateAppWindow(url); break;
　　　　　　case 2: PARENT.CreateDirectWindow(url); break;
　　　　　　case 3: PARENT.CreateWebWindow(url); break;
　　　　　　default: 　　
　　　　}
　　}
　　else
　　{
　　　　new ActiveXObject("WScript.Shell").Popup("キャンセルされました");
　　　　PARENT.Quit();
　　}

手元に64bit機が無いので結果は確認できていませんが,MakeDll.batはDLLでは
なく、WSFファイルを生成します。この時原版WSFを上書きしないように原版は
拡張子bakへ変更されます。再度生成する場合はWSF(内容はDLL)を削除してか
らbakをwsfへ変更することになります。万が一MakeDll.batがDLL化済みのWSF
を受け入れてしまうと原版bakも上書きされてしまいますので、ファイル先頭
2バイトがMZな場合、DLL化済みである旨を表示して離脱しています。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ScriptEx.exeを

「Windows Scripting Host Extensions version 1.00」としてリリースします。

先頭タブのエディタに全機能を説明するドキュメントを整備しました。DLL化
については個人的なツールとして使用する場合は無関係なことから割愛しま
した。バージョン1.00はフリーソフトであり、何ら機能に制約はありません。
JScript風にVBScriptを記述できますので、配列操作などでVBの軽快さを生か
すコードを書いてみてください。また、不具合がありましたらお気軽に連絡
をください。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。下記プラグマが追加されました。VBScriptを対象に行われた
プリプロセス結果を先頭エディタ上で確認することができます。

'--------------------------------------------------------------------------------------------------
'log_preprocessはプリプロセス結果を先頭エディタへログとして表示する
'#pragma log_preprocess
'--------------------------------------------------------------------------------------------------

先頭ページのヘルプが素のテキストではあんまりなので、HTML埋め込みに
変更しました。現状は単にPRE中にテキストを貼っただけなので、レイアウト
がいいかげんですが、随時整備します。従来エディタへのHTML埋め込みはサ
イズが指定された状態を想定したアルゴリズムでしたが、0px生成して要求
サイズを取得した後に埋め込むという機能に日中を費やしてしまいました。

ScriptEx.exeは製品としてリリースされる場合フリーバージョンとそうでな
いバージョンに分かれる可能性がありますのでご了承ください。

もうちょっとカラフルな説明をと思っていましたが、純粋なスクリプトの世界
は、テキストでの説明が似合いますので、PREタグ中の\tをスペース変換する
だけの整形としました。また、JS、VBSファイルへの対応も検討しましたが、
JSとVBを並べるWSF環境の方が、それぞれの長所を活かしたコーディングを
促しやすいことから従来どおりWSFのみの対応とします

64bit機が提供する32bit環境でのWSH環境においてWSFファイルさえ実在なら
内容がバイナリでもIOをHookすることで実行可能であることが判明しました。
これで、HTABOX及びScriptExでのEXE生成、DLL生成手法が確定しました。

結局WSHでもMSHTMLでも中で行っていることは大差ないのですが、HTABOXで
複雑な動作を行う場合メッセージキューの飽和、若しくはキューの処理速度
が原因の遅延が発生してしまうのではないかという懸念がありますので、
別プロセスで安定的にスクリプトを実行できるとすれば積極活用すべきと考
えています。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。メニュー、ツールバー、ステータスバーを装備しました。
ステータスバーは親プロセス以下全スクリプトのCPU占有率を合計したもの
が常に表示されるものとしました。稚拙なソフトではありますが、次回更新
からフリーバージョンは、何らかの制約が加えられる予定です。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。もう一点掘り下げたい事があってデモを追加しました。
WSH側からエディタ上にHTMLを埋め込み、そのボタンイベントに応答する
というものです。添付Embed.wsfを実行するとエディタ上に埋め込まれて
test.htmが表示されます。このボタンで呼び出し元の関数を呼びます。
WSF側コードは下記のとおりです。
<job id="main">
　　<script language="JScript">
　　　　var Document = HELPER.EmbedHtml(HELPER.ScriptDirectory + "test.htm");
　　　　function CallBack()
　　　　{
　　　　　　alert("CallBack");
　　　　　　Document.bgColor = "red";
　　　　}
　　</script>
　　<script language="VBScript">
　　　　HELPER.WaitMessage(0)
　　</script>
</job>

今日はリッチエディットへ活性化したHTMLを埋め込んだ場合に何が起きるか、
また、その結果を受けて、HTML埋め込み可能リッチエディットをパッケージ
として販売可能なバイナリに仕立てられるかが課題でしたが、何とか課題は
クリアできたようです。このエディタへのHTML埋め込みは、コマンドライン
ベースの高速なユーザーインターフェースへワンポイントでGUIを挿入できる
いう意味でとても斬新な提言になるのではないかと思います。

静的なヘルプやドキュメントであれば単一アーカイブ形式であるMHTが便利
だということで、あれこれと検証を行いました。解釈にはIEの分身である
WebBrowserが必要なようです。これなら単にMHTを食わせるだけで表示しま
す。ただし、非.NETな環境でドキュメントの要求サイズを綺麗に取得するの
は難しいと思います。どうせMSWORDでしか作成しないという想定なら、BODY
直下のSection用DIVを捕捉してサイズを決めれば、不足することはなさそう
ですが。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。機能的にはなんら変化していないのですが、ヘルプページが
MHT由来の画像に置き換わりました。このページは概要しか完成していません
ので、解説.htmが添付されています。ここでもそうですが、私は文章を書いて
いると、戻って部分的な修正をしますから「てにをは」が変になりやすいので
それを指摘してくれるワードは、公式な文章を書く場合大変頼りになります。

MHTの画像化が成功したことで、構造化の必要がない静的ドキュメントは単に
MHTで保存してデバッグビルド時に表示と画像化、リリースビルド時に生成画
像を表示という、何もしなくていい常態になりますので説明自体の質を向上さ
せることに集中できると思います。

エディタ上のHTMLには一つ弱点があって、ページ内リンクが発動してもスク
ロールは発生しません。スクロールすべきウインドウが全く別物に置き換わ
る訳ですから当然です。でも、ヘルプのように縦長なものを埋め込んだ場合
それでは不便なので、結局ヘルプは別ウインドウという展開になりました。
ただし、譲歩してばかりでは仕上がりが陳腐になりますので、ヘルプに左
メニューを設置し、メニューの文字列も抽出画像を使いHG明朝Eで統一する
という事にしました。

この裏方での画像生成時は速度が要求されませんから、現物DCは一切確保せ
ずメタDCで全体のコマンドストリームを生成しGDI+でトリミングしたストリ
ームをPNG変換しています。たぶんこの方法ならどんなに大きな画像でもメ
モリ不足が原因で分割処理を余儀なくされる事態は回避できると思います。

ヘルプドキュメント生成の改良で一日が終わりましたが、十分に納得できる
結果を得る事ができました。現状のScriptExヘルプは画像生成時にGDI+を使
用した影の追加、再生時はSmartImgタグでの自動メモリ開放を装備していま
す。ぽんと書いたワードドキュメントが全自動でこうなりますから、この部
分だけでも十分に商品として成り立つと考えます。オフィス系が内部で描画
するクリップアート系を美しく画像化するのは意外と難しいものなのです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。このスレッドに関わってくださった皆さんへ感謝の意味を
こめて、MHTの画像HTML化機能を利用可能な状態のScriptExを一時公開します。

MHTの変換機能はメインウインドウではなく、ヘルプで表示されるウインドウ
にあります。メニューからコンバートすべきMHTを指定すると、フレーム形式
の同名HTMとLEFT.HTM、RIGHT.HTM、IMGディレクトリが生成されます。画像化
はテーブル単位で行われますから添付MAIN.MHT自体とその内容を参考にして
ください。尚、WORD2003、2007が無いと原版の状態で代替フォントになりま
すから、もしMHTを編集可能なら、ご自身の環境にあるフォントを使用してく
ださい。

このMHTコンバートを製品化する段階では、現在固定されてるパラメータを
変更可能にする必要があると考えています。「背景色」「影グラデーション色」
「影のガンマ」「メニューのガンマ」「テーブルのガンマ」が主な要素です。
また、完全な画像ですから、文書として検索にヒットすることはありません。
画像化前にキーワードを抽出してSEO用に埋め込む機能も必要になると考えます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。影のグラデーション開始色、終了色をMHTの背景色を判断し
自動追従するものとしました。背景色を設定して解ったのですが、MHTエンジ
ンの発色とGDI+がPNGを生成する場合の発色には一定のガンマ比があると思わ
れます。したがって色の同期を尊重するならガンマは定数となるようです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。テーブルマージンに関与しないことで背景色とテーブル色
を個別に表現可能としました。また、見出し階層を認識し、H1〜H6までを
左メニューで識別可能としました。中小規模なヘルプ用エンジンとしてはこ
れで十二分なのではないかと重います。全く単一なワードドキュメントで、
画像ファイルの設置漏れも気にすることなく、ワンタッチでリッチな表現
のHTMLヘルプ、又はWEBページを生成することができます。

よくGDI+には角丸が無いからという表現を目にしますが、GDI+が円又は円弧
のパスを生成したときのポイントを眺めれば「無い」のではなくそう発言し
ているプログラマーに「描く能力が無い」だけだという事が解ります。レス
トランにそいうメニューが用意されていなければ無いというのなら、それは
プログラマーではなく単なるオペレーターです。メニューに無ければ厨房へ
入って、食材を組み合わせた料理を作れるのがプログラマーだと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。MHT変換時の左メニュー描画を見直しました。結局赤や黄色
な背景の文章を見たい人はいないでしょうから、テーブルの背景は原則として
白であるという想定にしました。また、冒頭以外のH1出現でHRを入れています。

ワードの各スタイルを設定する作業は大変煩わしいですが、一旦フィルタ後
HTMLに保存してCSSを操作した後に再度開くことで、短時間に制御できます。
例えば見出し１から６までを統一する場合、見出し１のみを設定して上記形
式で保存し、CSSのH1部分にH2以降を,で追加します。h1,h2,h3,h4,h5,h6
これでこの原版を開くことを起点としたスタイルは見出しが統一されたもの
となります。この手法は意味不明なスタイルが増えた場合に、スタイルを整
理する局面でも応用できます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。MHTコンバート動作を別スレッドへ移し、動作をスムーズに
しました。画像処理としてはかなりこみいっていますが、COM的にはディスパッ
チ生成物を、速度を気にせずInvokeしているだけですので、コンテキスト問題
は生じませんでした。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。MHTコンバート動作にイメージ生成のみな動作を追加しまし
た。ヘルプを表示後のFile->Convert Imageは指定MHTに隣接IMGフォルダを
生成し。全テーブルをIMAGE***.PNGへ出力します。WEBページ等にちょっと
文字入りの画像が欲しいときは便利だと思います。
尚、MHTコンバート動作の公開はこのバイナリで終了させていただきます。

頭がOLEと画像処理について慣れているついでに、DOC形式のままページを認識
した状態でOLE的に綺麗な画像データが取得可能なのではないかを検証していま
した。細かな問題はあるのですが、成功したようです。MHTな状態では段組を使
うことはできませんが、これなら可能です。また、作成時からページという概
念を意識しますから、ヘルプのように縦長ではなく、整形されたWEBサイトの
ように同じサイズのHTMLページとなるメリットがあります。2013には標準でPNG
出力機能があるようですが、リンク情報の保持、自動サイト形成、GDI+による
より細かな設定が可能あれば十分魅力ある製品になるだろうと思います。

ワードのDOC状態でのページ画像取得についてあれこれ検証しましたが、ページ
という概念が印刷を前提としているものですから、OLE手法で綺麗に切り分けた
状態をつくるのは極めて面倒だという結論に達しました。少々人様のドライバ
に頼ろうが、画像印刷した方が確実で早いようです。HTMLやNHTを前提とした
「文章の長さが不定」な状態を綺麗に画像化、サイト化するという方向性を
明確に認識しないと余計な事に首を突っ込むはめになります。

以前に書いた仮想プリンターでのワードDOC分割を動かしてみましたが、機序
からいってインストール動作が不可避であることにデメリットを感じます。
OLE的な取得で問題となったのは、ページに跨ったテーブルがあった場合のみ
でしたので、処理前にそれを警告する動作を加えWEBサイトはこちらの方で
作成したいと考えています。仮想プリンタは数多いでしょうが、インストール
の必要が無く、単に実行するだけでページ書式を認識した画像化を行えます
から、稀有な存在になると思います。

何を考えていようが、見て、読んでもらわなければ何も伝わりません。じゃあ
自分が納豆できるドキュメントのフォーマットって何？っというのが高次なテ
ーマなんですが、それに決着が着きそうです。ワードのページ単位画像化は安
定動作する状態へ持ち込めましたので、FrontPageを使った自動サイト生成を
追加しています。今時FrontPageが入っているPCは少ないでしょうから、一般
向けには階層フォルダ生成と相互ナビゲート関係構築ということになります。
当然、画像化前の文章を解析してSEO対策キーワードが付加された状態となる
予定です。

ワード文章の画像化は従来ポストスクリプト->PDF->PNGでしたがこれだと微妙
に画像劣化とピクセルずれが生じます。今回ダイレクトにTYMED_ENHMFを取得
してみるとピクセル位置の再現性に優れている事に気づきました。よくプリン
タ毎に1pxずれたりしますが、表示データを直接取得することでその手の悩みは
原理的に発生しないことになります。

包括的にMHT->HTML->WEB又はDOC->HTML->WEBの仕様を煮詰めましたが、ドキ
ュメントサイズによってはかなり重い処理となります。そこでCPU稼働率モニ
タは是非必要な機能になるのですが、考えてみるとScriptExのモニタが機能す
る為にはプライマリスレッドが空いている状態でなければなりません。つまり
重い処理を全部別スレッドで行わない限り稼働率をリアルタイムで表示するこ
とはできないことになります。プライマリスレッドで引き金だけを引き、別ス
レッドでCOM操作を整然と行うとなると、全体の設計がそれを意識したもので
ないと破綻します。具体的には仕事が終わったらdelete thisを自律的に行え
るクラスを意識しなければなりません。改めてプログラミングの奥深さにため
息が出ました。

ソースコードをVisual Studioでの編集状態のまま公開するためには何が必要
かについて検証していました。ごく小規模なソースなら単なるコピペでRTFと
して扱えますが、本格的な長さ(200k程度)だとクリップボードは素のTEXTのみ
になります。そこでoffice2003付属の仮想プリンターでMDIファイルへ印刷し、
画像として公開するシステムを書きました。このMDIファイルは面白い事に画像
ファイルでありながら画像中の文字列に対する参照ができます。つまり全部印刷
してから、その画像がソースコードの何行目から何行目までなのかをプログラム
から確認することが可能です。MDIはその後別な規格にとって替わられたと思
うのですが、使いようによっては強力なアドバンテージとなるファイル形式です。

test

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。本題とはあまり関係ないデモですが、VisualStudioで編集
中のソースコードをエディタで吸い上げ、分割画像化して公開可能にする機能
をご覧いただけます。メニューの[Convert]->[Dte]で動作を開始します。

他の環境で検証していないので断定的な事は言えないのですが、VSのエディタ
からコピペする量が多いとリッチテキストフォーマットでなくなるように見え
ますから、分割して取得しましょうという発想です。一旦取り込んでしまえば
これをMsWordへコピペするのは一発で成功します。MsWordはリッチテキストを
HTMLとして保存できますから、忠実なHTML化が行えます。

単純なHTML化はWordにお任せして、本EXEはC形式コメント部のフォント置き
換え、C形式コメント記号のみな行のグラフィック化、http://で開始された
文字列のハイパーリンク化を行い、指定行数で分割したgifを生成します。

結果としてC形式コメントで書かれた解説部分はリッチなフォントで表示され
ソース部分はVSの編集状態そのままというWEBページを自動的に生成します。
画像の分割出力時に、一覧用HTMLファイルも生成されますから結果は即座に
確認可能です。

HTML系が本職なものですからMTAとは縁が無かったのですが、VSのDTEはMTAを
期待していますので動作中に両者の使い分けですこし悩みました。リッチエ
ディットのOLE系はMTAでも動作するのですが、HWNDへのメッセージとタイミ
ングが衝突するような場合にストールすると推察されます。ですからOLE系
に触る部分はMTAを断ち切る意味で別スレッドとしなければならないようです。

test

scriptex.zip
を更新しました。エディタがスクロール動作している状態へ追い討ちをかけて
操作するとストールするという推察の元に、モーダルダイアログで進捗状況を
表示しながらエディタへのSetFocusを阻止することにしました。これで予期せ
ぬ停止は発生しないのではないかと考えます。

C++でプログラミングする時、変更や、追加が他のリリース済みアプリケーシ
ョンへどのような影響を与えるかをすばやく確認する方法は、全機能を持っ
たマスターアプリケーション上で開発を行いリリース時には#defineで機能を
制限したウインドウとすることです。さすがにHTABOXとScriptExとこれを実
現するには無理がありますが、ScriptExをベースとした各機能はこの理論で
分割リリースできそうです。たとえ何百個リリースしようが私は2つのプロジ
ェクトを管理するだけで足りることになります。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ネイティブなタブベース系アプリケーションはMasterプロジ
ェクトで開発し、機能を切り分けてリリースするシステムのテストを兼ねてい
ます。ヘルプは未完ですが、WSFのタブ実行に加え、CMD.exeのタブ実行も可能
としました。総合的なコマンドライン操作の母艦として活用していただければ
幸いです。

以前から気になってはいたのですが、GDI+で背景RGBを指定した画像を同じ
RGBを背景色としたHTMLで表示すると色差のために段が付いてしまいます。
解決策はGDI+で生成した画像ファイルをGDI+とは切り離された環境で評価す
ることなのですかが、これに結構はまりました。悩んだ末に非表示HTMLで画
像をパースしてDrawし1px読むという事になりましたが、これはもっと賢い方
法があるような気がします。

ワードの直接画像化で縦書きに対応することに成功しました。プログラミン
グ系で縦書きが必要とされることは無いのですが、日本語の美しさを追求し
たサイトなら縦書きのままページを画像化し、ブラウザとは無関係に同じ状
態を公開することができます。当然縦書き中のハイパーリンクも機能します。
この辺が一般向けには主力製品ということになるだろうと思います。

プログラムは実行パラメーターさえ決定すればあとは一本道なのですが、ユー
ザーが何を要求しているのかを得るためにGUIが必要になります。このGUIを
できるだけ簡便に構築する手法がHTMLなのですが、ダイアログだった場合、
どうしても初回表示タイムラグが発生します。これは裏で表示しておくくら
いしか対策がありません。まぁファイルダイアログだって初回はかなりもた
つくと言ってしまえばそれまでなんですが。

ダイアログテンプレートを必要とせず、クイッキーに動的なダイアログを提供
する為には？にういては私なりの回答があります。リッチエディットのリンク
を活用した対話的ダイアログ母艦です。この仕様がある程度かたまりましたの
で、通常のスクリプトからも利用できる状態で公開したいと考えています。

各種コモンダイアログは当然装備しますが、最大の特徴は、文字列の正規表現
ヒット部分をリンク表現し、クリックされた文字列を返却する子ダイアログが
あることです。つまり「数値を選択してください 1　2　3　4」という文字列
を与え条件として正規表現「\d」を与えればクリックされた数値を文字として
得ることができます。

この正規表現ダイアログが最も威力を発揮する局面は動的に生成された多くの
選択肢から的確にユーザーの指定項目を得ることです。例えば任意なディレクトリ
のdir出力をダイアログへ与え、適切な正規表現を指定すればたとえ数万要素
が存在したとしてもユーザーフレンドリーなGUIとできることです。作成側から
見れば、GUIのデザインに腐心する必要は無く、文字列と正規表現を用意して
返却文字列を得るだけになります。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。添付dlg.exeは対話型ダイアログのデモですが、汎用なツール
として抽象化するには至っていません。典型的な要素のダイアログを表示する
全くのデモンストレーションです。正直まだ理解できていない要素があるもの
ですから、皆さんに使っていただけるツールに仕上がるのは先のことになりそ
うですが、やりたい事は理解していただけると思います。

こういった軽量で柔軟性に富むダイアログシステムがあれば、アプリケーション
ウインドウ自体は最低限のGUIしか装備する必要がなくなり、同一ソースから
複数のアプリケーションを切り出すことが容易になります。また、ウイザード
形式で複数のダイアログが変移すると、果たして何処に連れて行かれるのか
不安になりますが、このシステムでは母艦の状態で全体を俯瞰していますから
ユーザーに不安を抱かせることもなく、常に決定済み要素のリセットが可能
であるというメリットを生みます。

このダイアログシステムはごく当たり前なテクニックでできていますが、重
箱の隅をつつくような狭い分野でしか物を考えてきませんでしたから、基本
的な事を見直す意味で有意義でした。もし目新しいとすれば、フォーカスを
持たせたまま、リッチエディットのキャレットを非表示とするという部分で
すが、このからくりはWM_PAINT時にキャレット位置を認識し背景と同色な子
ウインドウで覆い隠すというものです。あらゆる状況下でキャレットを隠す
にはこの原始的な方法が最も効果的であるという結論に達しました。

HTABOXは取り説や細部の煮詰めがまだなまま放置状態ですが、ご容赦くださ
い。正直ある程度書ける、又は理解している人間を相手にフリーなツールを
提供することは容易でも、ビジネスというレベルへ持ち込むのは容易な事で
はありません。それよりもプログラミングについてなど考えた事も無い一般
ユーザー向けな製品のリリースが先行することになります。

書ける又は書きたいと思っているユーザーに対しては製品よりもテクニック
を提供するというスタイルも考えています。VSプロジェクトの自動サイト化
はそれを睨んだ検証でした。画像としてある程度のコードは確認できるが、
即戦力なコードは有料で提供されるというロジックを実現できそうです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。添付Master.exeはワードドキュメントの画像変換、一覧HTML
の生成機能を持っています。動作条件はWord2003以上がインストールされてい
る事です。メニューのConvert->Docで対話型ダイアログが表示されます。
生成されたHTML群とimagesフォルダはそのままサーバーにFTPすればWEBページ
として機能します。総ては画像とクリッカブルリンクで構成されていますから
再生する端末側の仕様で見栄えが異なることは原理的に発生しません。当然、
ワード上で使用したあらゆる小技がそのままHTMLページに反映されます。
ページ毎の画像取得はOLE的に行われています。したがって仮想印刷した場合
に避けがたいフォントの変化は起こりません。ワードで編集中の画像が正確に
再現されている事も特徴となります。

従来C++で操作してもワードはVBAでの操作と同等の速度でしか反応しないと
思っていたのですが、それは私の勉強不足でした。上記EXEがページ上をスキ
ャンする速度は、明らかにVBAとは異次元な速さです。ワードが印刷等の動作
前に見せる内部スキャンと同じ速度に見えます。これは呼び出し側スレッド
モデルの違いです。2003以前がどうかは知りませんが、2003以降ならにMTA
環境でコールすることにより、VBAでは不可能な速度での操作が可能だろうと
推測します。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。MSHTML系の実行時フックは極めて安定的な状態となりまし
たので、CPP開発環境から任意なHTMLウインドウへIOleClientSiteを設定でき
出現HWNDが報告されるシステムをタイプライブラリ付きDLLにまとめてみまし
た。添付ForCppにあるexeはsample.cppをコンパイルしたものです。

どんな雰囲気になるんだろうと、興味がある方もいらっしゃるでしょうから、
分割して投稿してみます。

/*******************************************************************************
拡張HTMLダイアログシステム活用サンプル
*******************************************************************************/
#define _WIN32_WINNT 0x0501
#include <windows.h>
#include <comdef.h>
#include <shlwapi.h> //shellユーティリティー
#pragma comment(lib, "shlwapi.lib") //shellユーティリティー

TCHAR MAIN_PATH[MAX_PATH]; //自身フルパス
TCHAR MAIN_DIR[MAX_PATH]; //自身ディレクトリ
DWORD MAIN_THID = 0; //自身スレッドID
#import "DialogEx.dll" //拡張HTMLダイアログDLLインポート
//DLL公開関数型宣言
typedef HRESULT (STDMETHODCALLTYPE *_QueryDialogSystem)(REFIID riid, void **ppvObject);

//報告サイトインターフェース
class __declspec(uuid("F3B949E0-E338-4225-812A-35E9091F216A")) IHtmlSiteWithProc : public IUnknown
{
public:
virtual void STDMETHODCALLTYPE FraHwnd(HWND hwnd, WNDPROC func) = 0;
virtual void STDMETHODCALLTYPE DocHwnd(HWND hwnd, WNDPROC func) = 0;
virtual LRESULT STDMETHODCALLTYPE FraProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) = 0;
virtual LRESULT STDMETHODCALLTYPE DocProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) = 0;
};

class ReportSite : public IHtmlSiteWithProc
{
long ref;
WNDPROC FraFunc, DocFunc;
public:
ReportSite(){ref = 0;}
HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void **ppvObject)
{
*ppvObject = NULL;
if(IsEqualGUID(riid, IID_IUnknown)) *ppvObject = this;
if(IsEqualGUID(riid, __uuidof(IHtmlSiteWithProc))) *ppvObject = static_cast<IHtmlSiteWithProc*>(this);
if(*ppvObject != NULL){AddRef(); return(S_OK);}else return(E_NOINTERFACE);
}
ULONG STDMETHODCALLTYPE AddRef(){return(InterlockedIncrement(&ref));}
ULONG STDMETHODCALLTYPE Release(){if(InterlockedDecrement(&ref) == 0){delete this; return(0);}return(ref);}

//IHtmlSiteWithProc : public IUnknown
void STDMETHODCALLTYPE FraHwnd(HWND hwnd, WNDPROC func){FraFunc = func;}
void STDMETHODCALLTYPE DocHwnd(HWND hwnd, WNDPROC func){DocFunc = func;}
LRESULT STDMETHODCALLTYPE FraProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
return(CallWindowProc(FraFunc, hwnd, uMsg, wParam, lParam));
}
LRESULT STDMETHODCALLTYPE DocProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
if(uMsg == WM_NCDESTROY){PostThreadMessage(MAIN_THID, WM_QUIT, 0, 0);}
return(CallWindowProc(DocFunc, hwnd, uMsg, wParam, lParam));
}
~ReportSite(){}
};

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
HMODULE Dll;
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
try
{
//ドライブ名が開発環境では小文字、EXE実行では大文字なことに注意
GetModuleFileName(NULL,MAIN_PATH, MAX_PATH); if(MAIN_PATH[0] >'Z') MAIN_PATH[0] -= ('a' -'A');
StrCpy(MAIN_DIR, MAIN_PATH); PathRemoveFileSpec(MAIN_DIR);

_bstr_t path = "\\test.htm";

MAIN_THID = GetCurrentThreadId();
Dll = LoadLibrary(TEXT("DialogEx.dll"));
_QueryDialogSystem QueryDialogEx = (_QueryDialogSystem)GetProcAddress(Dll, "QueryDialogEx");
DialogEx::IDialogExPtr Dlg; QueryDialogEx(__uuidof(DialogEx::IDialogEx), (void**)&Dlg);
Dlg->CreateApplicationWithSite(new ReportSite(), MAIN_DIR + path, NULL, NULL, NULL);
MSGMsg; while(GetMessage(&Msg,NULL, 0, 0 )){TranslateMessage(&Msg); DispatchMessage(&Msg);}
}
catch(...)
{
MessageBox(NULL, TEXT("Unknown Error"), TEXT("Test Application"), MB_SYSTEMMODAL); return(1);
}
FreeLibrary(Dll);
CoUninitialize();
return(0);
}

呼び出し側ではHWNDのサブクラスを兼ねたサイトを用意して、DLLの#import
で取得したインターフェースに対してCreateApplicationWithSiteを呼び出し
ています。これだけでMSHTMLが生成するあらゆるHTMLウインドウをその生成
過程に介入した形で自由にカスタマイズすることができます。例えばHWNDは
CreateWindowExの処理を奪うことでMSHTMLへHWNDが返されるより前に報告さ
れます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。ライブラリ側は単にHWNDを
報告するのみとし、サブクラス化は利用者側の好みで行うものとしました。
これはアプリケーション終了とドキュメント側HWNDサブクラス終了タイミン
グによってはエラーとなりやすいことへの対策です。

添付sample.cppは他人様が書いたウインドウをサブクラス化する定石コード
だと思います。GWL_WNDPROCは当然使えませんから、SetPropでクラスをHWND
に覚えさせています。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。独自エレメント作成に対応
しました。sample.cppにはIElementNamespaceFactory、IElementBehaviorFactory
の操作コードが含まれます。通常のダイアログ生成ではIElementNamespaceTable
をこのタイミングで取得することは不可能ですが、本ライブラリでは可能と
しています。VC++をお持ちの方はぜひエレメント作成にチャレンジしてみて
ください。

C++開発者向けのライブラリを提供する手法も確立しました。要は生々しい
コードをいかにカプセル化して成果だけを公開するかに尽きるのですが、こ
の相反する要求を満たすにはIDLによるタイプライブラリ生成と#importによ
る動的インターフェース認識が最適と判断しました。引数がバリアント型に
集約されるなら、そのままスクリプト向けディスパッチとすることも可能で
す。エレメントビヘイビアもそうですが、IDLも非ATLのすっきりしたコード
というのは目にした事がありませんので、本当の意味でC++の威力を再認識し
ていただける解説サイトを作れればと考えています。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。非IDLでのインターフェース
公開を試したところ好印象でしたので採用しました。異なるコンテキスト間
ではマーシャリングが必要でしょうが、DLLロードによる直線的な機能公開で
はこちらの方が適しているように感じます。いつでもIDL化できるような書き
方を心がけてケースによって使い分けるというのが正解なのでしょう。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。再びIDLに戻っての検証コード
となりました。mshtmlは終了にも時間がかかるため確実に全スレッドの終了を
検出した後の開放とすることで、IDLの場合たまに出ていた終了時エラーを克服
できたと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。ドキュメントインスタンスの
報告手段を決定しました。interactiveを待って、コンテキストを断ち切る意味
でLRESULT値に変換して渡すものとしました。これでC++向けMSHTMLライブラリ
のベースは完成です。多分IEある限り変更の必要は無いでしょう。DEGINE系の
ビヘイビアを装備し製品化したいと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。ドキュメントインスタンスを
ユーザー側サイトへ報告すると参照カウンターが上昇し、そのままではサイト
開放が発生しないことから、IHTMLWindow2を報告することに変更しました。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの内容を変更しました。描画目的のビヘイビアにマウス
軌跡サンプルコードを追加しました。また、動作目的ビヘイビアの例として
UNICODE自動認識ファイル入出力ビヘイビアを追加しました。非ATLでこれだけ
総合的なCOM操作コードを目にする機会は他にないと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppの公開を終了しました。誰かに見られるかも知れない
というプレッシャーの中で十分に客観的な評価、検証ができたと考えます。
単に拡張子がcppなC言語プログラミングからC++言語へ誘導する教材として
再びご覧いただける日が来ると思います。

HTABOXの出発点は抽象的なウインドウやコントロールはC++で用意し、具象の
部分はスクリプトで書きましょうな訳ですが、そのさらに根源にはC++でアプ
リケーションを管理するのは煩雑という直感があった訳です。確かにJScript
でデバッグすれば、何から何まで芋づる式に見えますから楽なんですが、C++
のようにとりあえず変数を隠して、当該変数が参照されている部分をエラー
であぶりだすような事ができないのです。.NETのJScriptなら可能ですが、
こちらは起動速度が足を引っ張ります。

C++は言語を定義する言語のようなものですから、自分なりの言語仕様が確定
していない状態だと、見るたびに異なった記述を試みますから結果として汎
用なライブラリとならず、3日も目を離せば自分でも何が書いてあるかわから
ない状態になっていたのですが、数年もこのことばかり考えてると自分なりに
もうこれ以上スマートな書き方は無いという状態になり、たとえ一年前に書か
れた別分野のコードでも短時間に理解、修正できるようになります。むしろ
スクリプト中の変数名タイプミスのようなバグの方が判明しにくいと感じます。

ただ、全編をC++で記述した場合に他言語やHTML中との接点が希薄になるので
は？という懸念から徹底してIDLの検証を行った次第です。ディスパッチを生
成することは以前から行ってましたが、より実践的なスレッド構成で任意な
ブレークポイントを設定した場合に停止、再開でクラッシュを誘発しないか
が主なテーマでした。とにかくプログラミングは99.99%デバッガとの付き合
いですから、この事は大変重要です。

私自身の流れとしては、JScript離れが起きるだろうと思います。C++風VBS
は、まだ実践投入する段階ではありませんから、JScriptの柔軟性の根源で
あるIDispatchExをC++コード中で操作する。つまりfunctonやarrayをC++か
らコンストラクトして、スクリプトエンジンでのコードパースは行わない
という方向になるだろうと思います。勿論HTABOX自体はHTML+スクリプトの
ために存在しますからその方向性が変更される事はありません。

ソースコードをパースせず全要素をDISPATCH_CONSTRUCTで生成するJScript
エンジンがほぼ完成しました。これもC++用に一時公開しようと考えていま
す。速度的にスクリプト環境のJScriptよりどのくらい高速なのかは未知数
ですが、配列操作対象がArrayに縛られませんから書き方によってはかなり
の速度向上が期待できると思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。JsPlusホルダにはJScriptをそのままC++コード中に記述
してネイティブコンパイル可能なDLLとLIB、サンプルCPPが存在します。
CPPファイルを見ていただければ解りますが、_variant_tを基底とする拡張
クラスに全メソッドを実装するという形にしています。また、C++中に
function hoge(){...}を書いてパースしては隠蔽できませんから、原則と
して関数パースは使用すべきではありませんが、Functionオブジェクトを
生成して呼ぶことは可能です。この場合引数が内部コード、引数名、関数名
であることに注意が必要です。これはIActiveScriptParseProcedureを使用
するためです。したがって引数名の文字列表現は"a,b,c,d"のようになります。

そういう目的で作成されているわけですから当然ですが、JScriptをそのまま
C++中に書けます。サンプルでは以下のコードを検証しています。

CoInitialize(NULL);

//未初期化要素(VT_EMPTY)が終端を意味するので余計に確保
_variant_t list[5] = {1,2,3,4};
var vb = new VBArray(list);
var ar = vb.toArray();
var s = ar.length();

var str = new String("ab1cde2fg");
var reg = new RegExp("\\d", "g");
_variant_t ss = str.replace(reg, "@");

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。Arrayの要素参照が抜けていたので実装しました。[]演算子
オーバーロードは基底_variant_tからクレームが出ますので、item関数とし
ました。JScriptのArrayは本当の配列ではありませんから数値ではなく文字列
を引数とすることもできます。多次元配列な場合はちょっと美しくないのです
が、var data = array.item(y).item(x);になります。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。_variant_tを置き換えることで[]演算子問題を克服しました。
従来varの各メソッド等が確認しやすいように宣言コードをEXE側へ置く発想で
したが、今回の変更で長くなる為var.hとしました。ヘッダ名と統一するために
var.dll、var.libに名前が変更されました。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ActiveXObjectクラスを新設し、格納されるvarクラスに
Invokeメソッドを追加しました。結果としてWinMain中で下記のスクリプト
が動作します。
//-----------------------------------------------------------------------------
//IOMode type enum
var ForReading = 1;
var ForWriting = 2;
var ForAppending = 8;
//-----------------------------------------------------------------------------
//Tristate type enum
var TristateTrue = -1;
var TristateFalse = 0;

TCHAR Path[MAX_PATH]; GetModuleFileName(NULL, Path, MAX_PATH);
var path = new String(Path);
path = path.replace(new RegExp("\\w+$", ""), "cpp");

var wss = new ActiveXObject(L"WScript.Shell");
var fso = new ActiveXObject(L"Scripting.FileSystemObject");
var ptr = fso.Invoke("OpenTextFile", DISPATCH_METHOD, path, ForReading, false, TristateFalse);

var str = ptr.Invoke("ReadAll", DISPATCH_METHOD);
ptr.Invoke("Close", DISPATCH_METHOD);
wss.Invoke("Popup", DISPATCH_METHOD, str);

現時点での仕様ではvar path = new String(Path); 時のpathはStringですが
path = path.replace(...が行われた時の左辺pathはVT_BSTRのバリアントです。
右辺が文字列な場合Stringを自動生成することはやぶさかではありませんが、
望んでいないのにそれが内部で実行され、常に時間を費やす事は好ましくない
という思想でいます。もしStringが欲しければ右辺をnew String(path.replace(.
で実現できますが、逆におせっかいを断ち切る事は不可能だからです。

従来C++中にスクリプトを導入して楽をしようとすれば、２つの問題が生じ
ました。一つはパース動作をフックされればコードが暴かれる点、もう一つ
はC++コード中に長大な文字列は置けない、又は置きにくいという事実です。
そんなリスクがありますから、スクリプトコントロールのような機構があっ
たとしても利用する開発者は少なかったと思います。

今回の提案はコードをパースするのではなく、スクリプトが持つ個々のオブ
ジェクト動作をC++中でスクリプト文法のように記述しようとするものです。
この場合万が一スクリプトエンジンルートインスタンスが捕捉されたとして
も、そこには何も存在しませんから通常のAPIによるアプリケーションよりも
機密度の高いバイナリになるだろうと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。JsPlusフォルダを改訂しました。メモリ検証で未開放領域が
存在し、考え方自体を変更する必要がありましたのでオブジェクトの構造を変
更しました。ほんの10行か20行くらいしかスクリプトは書いていませんが、直
感としてはこれが最終形態だと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。JsPlusフォルダを改訂しました。CPPによるHTMLアプリケー
ション生成デモです。HtmlApp.exeを実行するとフレーム分割されたウインド
ウが表示されますが、下部はHTMLドキュメントへ全画面埋め込みとしたリッチ
エディタです。ウインドウやダイアログを総て拡張HTMLウインドウで生成する
システムをベースとして、必要ならネイティブな要素を埋め込むという手法
です。CPPコード中にJScriptもどきも書けますから、格納するまでもなく始め
からネイティブなEXEをHTML+スクリプト感覚で作成可能にする事が目的です。

HTABOX周辺アプリケーションを含め、今後リリースする総てのアプリケーション
の原型となるシステム構造をしています。各アプリケーションは具象DLLで表現
され、HtmlApp.exeを生成する基本プロジェクトへ一時追加する形で目的EXEを
生成し、名前を変更したhoge.exeをリリースするシステムです。これなら既存
ソースに具象を混入することなくあらゆる変化に対応できると同時に、基本
プロジェクトにはノウハウがそのまま蓄積され成長してゆくことになります。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダに私が考えるHTMLアプリケーションの原型
をHtmlApp.exeにまとめてみました。これはC++向けライブラリで構成されて
いますが、CPP向けJScript以外は他言語環境へ提供可能です。したがってHT
ABOXでも同様の形式アプリケーションを簡便に生成できるようにします。

考え方はこうです。

HTMLアプリケーションは縦長なドキュメント中にフォームとしてのコントロー
ルと説明ドキュメントが混在させる事が可能である。ユーザーは取り説を別途
参照することなく操作ができる。

そこで問題となるのが、縦長なウインドウへ見出しを付け誘導することである。
ならばHnタグを自動認識するTreeをメニューとして付加する。

動作ログやユーザーからの文字列入力手段として、HTML標準のテキスト入力系
コントロールを評価した場合、そのレスポンスからして失格であり、全体の品
位を低下させる要因となりかねない。リッチテキストエディタを付加しメイン
HTMLから操作可能とする。

モードレスはHWNDとドキュメントのコンテキストが異なるのですが、フレーム
構成とした場合も同様な事が起こるようです。しかもフレームの場合は元が
モーダルな場合でもコンテキストが異なります。そこでマーシャリングを強く
意識した構造が必要となります。C++間での受け渡しでもあえて生ポインター
に触らず、一旦_variant_tにしてしまうのが最も賢い方法だと感じました。

毒を食らわば皿までと考えて、HtmlApp.exeはアプリケーションウインドウは
総てモードレス、あらゆるビヘイビア、OBJECTはフレームにも対応という設計
思想で構築されています。

ウインドウの分割、サイズ変更ロジックは何年にも渡って改良をしていますが、
このHTMLフレームの動きを見るたびに敗北感を味わいます。それほどHTMLの
フレーム分割は軽量で洗練されています。あらゆるウインドウをHTMLウインドウ
に統一し、その上で拡張を行うべきと判断した要因のひとつです。

やってみなければ結果が出ないので3分割されたHTMLウインドウの内メインな
ウインドウへタブを導入してみましたが、さすがにツリーとの境界でサイズ変
更時の残像が出てしまいます。標準のタブコントロールはサイズ変更されない
ことを原則としているように見えますので、横方向へのサイズ変更はかなり重
い動作となります。個人的にもツーリーとタブの併用は「くどい」気がして
いますから、すでに要素が決定している場合はTree + 縦長ページとし、ユー
ザーが選んだファイルを表示するような場合はタブという使い分けが自然か
と思います。

改めてHTABOXを省みると、あくまでもスクリプトからの制御を前提としてい
ますから、可能な限り全HTMLスレッドを統一したコンテキストにしています。
これはスクリプトが能動的にスレッドを切り替える又は複数スレッドが混在
したコードを書けないことによります。結果として構造は単純で堅牢なもの
となり、幾つタブを追加しても相互に操作可能です。575にHTABOXでも同様
の...と書きましたが、積極的にフレームを導入すべきではないと感じます。

もしHTABOXでは物足らない、又はその先を書くための足がかりが欲しいとい
ったニーズにCPP向けライブラリが存在するという位置づけになります。そこ
で検証され、スレッド的にもHTABOXに組み込みやすいなら追加されて行くで
しょう。Windows上でプログラミングを学ぼうと志す方は余計な言語に惑わさ
れることなくJScript -> C++という道筋を歩めることにもなります。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。HTML中に遠回りなActiveX
ではなく、ネイティブなHWNDを埋め込むのが、私のポリシーなんですが、その
場合ウインドウのサイズ変更や、スクロール時の描画同期という根深い問題
を抱えていました。移動等の瞬間だけIViewObjectになってもらえば解決なん
ですが、複数の課題が存在したので逃げていましたが、立ち向かってみました。
これによりフレーム分割されたタブウインドウ部をサイズ変更してもまったく
ちらつきは発生しません。というか同一イメージをDrawしているわけですから、
ちらつきようがありません。C++向けライブラリもこれで製品レベルに達したと
考えます。

これとHTABOXの違いを象徴する存在がツールバーです。HTABOXはスクリプトを
主体としたネイティブコントロールとの通信がテーマですからスクリプト中の
コンテキストからバーを生成できます。CPPライブラリの場合の主体はプライマ
リスレッドであり、HTML側は自由なフレーム分割を想定してスレッドを限定
していません。HTMLスクリプトが起点となって通信可能なのは自身ドキュメン
ト中のOBJECTに限定されます。ですからほとんど埋め込みオブジェクトで構成
されている訳です。もしツールバーが必要なら、HTMLウインドウをWS_CHILD
とし、外郭ウインドウを生成して普通にバーを置くことになります。コマンド
も通常どおりWM_COMMANDで受けてHTML側へ通知するという流れになるでしょう。

わざとツールバーをHTML標準なままにして公開した場合、HTMLやスクリプトに
対して知識がある人ほど、驚嘆するウインドウになろうかと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。HTMLのフレーム分割自体
をThickFrameなOBJECTでエミュレートしてはどうか？というのがテーマです。
TABLEタグを適切に書く必要はありますが、動作すれば本物のフレームより
メモリ効率に優れ、フレームサイズ変更時のちらつきも起きないようです。

ただ、ここまでやると「親ウインドウがHTMLである必要性」が希薄になりま
すので、親を普通のウインドウにしてさらに軽量化しなければ中途半端な存
在になりかねないと感じます。

もし非MSHTMLな環境で埋め込みオブジェクトを管理するコンテナが書けるか
をシュミレートしてみると、それはMSHTMLのようなボリュームになってしま
うだろうと予測します。

C++を起点とするような低水準な観点からMSHTMLの有効利用を考えた時に、
複数の埋め込みオブジェクトのレイアウトを<frameset>や<table>で容易に
定義できる汎用OLEコンテナであると捕らえると、曖昧になりがちな両者の
コーディング上の境界線が明確になると感じます。

HTML+Scriptを補助するCOMではなく、COMコンテナとしてHTMLを位置づけ、そ
れを補助する小規模なHTMLとスクリプトが存在するというアプリケーション
モデルです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。C++環境におけるHTMLアプ
リケーションの原型が完成しました。擬似フレームの方が軽量であると判断
し、量的なテストのために複数のタブを表示しています。

モードレスダイアログを複数表示したままでの終了で、サイトの開放を捕捉で
きない事に悩みましたが、わざとメモリが圧迫される数を表示して終了しても
プロセス終了後に未開放メモリが発生しないことから、既定の動作に委ねる
ことにしています。個別にWM_CLOSEすることは可能なのですが、稀に既定動作
と衝突してデッドロックが起こることと、first-chance exceptionが避けがた
いことから、終了に介入すべきではないと判断しています。

可変サイズOBJECTをテーブルで100%配置した擬似フレームの場合、本物のフレ
ームでは不可避なスレッド問題が生じません。したがって、HTABOX上でも実現
することができます。
多分、生涯に1本か2本の製品しかリリースしない方から見ると奇異な行動に見
えるかも知れませんが、私の目指すところは1週間に1本完全なアプリケーション
をリリース可能で、メンテナンスが必要なら数分で終わるという環境作りです。
ですから走り出してからの修正は極力避けたいのです。どう考えたってこれ以上
楽にはならないでしょう？という段階にやっと到達できたと考えます。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。ツールバーを追加してみ
ました。以前からHTMLフレームHWNDとドキュメントHWNDに割って入っての制
御は苦い思い出しかなかったのですが、改めてチャレンジしてみるとあっさ
り成功しました。コンテキストという概念が身にしみると何が無理筋で、何
が通りそうかは書いて動かさなくとも想像できるようになります。これだけ
はどんなに優秀な方でも1年や2年では身につかない嗅覚だと思います。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。細部を煮詰めてゆくとフレ
ーム偽装ではHWNDコンテキスト問題が生じるのでボツになりました。やや動作
は重くなるのですが、コンテキスト的に堅牢な普通のフレーム構成を採用しま
した。C++コード内でいじってもらうモジュールに不確実な要素を混入させるわ
けにはゆきません。

それ以上考え続けたら精神状態が、元には戻れないのではないかと感じて怯む
のか、あえてそこに身を置くのかの違いだと思ってきましたが、書き終わって
みると、何に問題意識を持つのか、持たないのかは既に決まっていて、定めら
れた手順をなぞっているだけな気がします。既視感というのは一種の精神異常
だという説もありますが、私はそうは思いません。われわれが時と呼んいるも
のへの理解が足りないだけだろうと予測します。

ただ、年齢的な衰えは隠せず、これ以上細かい事には興味がありません。そう
いったタイミングさえ運命というか神様の意思というか、私の意識より上位な
部分で定められていたことなのでしょう。ありがとうございました。

C++で作成したモジュールを公開したいが、ソースごと渡しては意味が無いと
いう場合のDLL活用について私なりにまとめます。ここでは提供側、利用側と
もC++(VC++)であるという想定で進行します。

１　単純関数
定義側　__declspec(dllexport)　利用側　__declspec(dllimport)で関数を
修飾すれば実現できます。実行時のコンテキストは当然利用側です。

２　クラス定義

これも関数同様にclass定義を修飾して、利用側にヘッダ部を置けば実現でき
ますが、コンテキストには注意が必要です。特にクラスがCOMオブジェクトで
あり、DLL側の他クラスと連携している場合は、生成関数もエクスポートした
方が安全です。例えばhogeクラスを提供する場合はDLL側に

__declspec(dllexport) HRESULT STDMETHODCALLTYPE QueryHoge(REFIID riid, void **ppvObject)
{
return((new Hoge())->QueryInterface(riid, ppvObject));
}
のような生成関数を用意し、これもエクスポートするという手法です。

クラスのエクスポート、インポートは後述するIDL手法と比べると自由度が
高いのですが、例えば_bstr_t等の領域を確保してあるものを渡した場合ク
ラッシュを招く危険があります。多くの場合領域を開放しようとする時の
コンテキストが生成時のコンテキストと異なるために起こるようです。

この問題の解決策として引数を_variant_tでラップすることは効果的です。
多くの場合これで問題を解決できるでしょう。ただ提供するクラスがCOM
オブジェクトであり、場合によっては利用者が実行中EXEを更に利用する別
プロセスであるような場合には対応しきれないと予測します。

VC7以上ではソースコード中にIDLコマンドを記述することにより非ATLな環境
でもタイプライブラリ主導なCOMオブジェクト公開手法を利用できます。ただ
無料版でそれが可能なのかは検証した事がありません。

３　IDL手法

タイプライブラリは利用側にとってヘッダファイルを生成する材料となりま
すから、クラス定義をヘッダファイルとして用意する必要は無くなります。
#import "hoge.dll"という定義でIDLに記述されたインターフェース、実装
クラス情報は自動的に参照可能となります。

IDLの特徴として引数型が限定されるという事実があります。これは裏を返
せばコンテキスト差を吸収すべくマーシャリング処理が行われることを意味
しているのだと理解しています。したがってプロセスを越境するような場合
でも破綻しにくいと考えます。

IDLはウイザードで生成する解説しか目にした事がありませんが、開発途上で
メソッドや引数を変更する場合、ウイザード生成では変更箇所が分散するため
ぶちきれそうになります。これも基本を押さえればソースに見たとおりな定義
ができますので、時間があったらサイトで公開したいと考えています。

C++が難解だと言われてしまう最大の要因は型の設計と実装についての誤った
認識です。さぁこれから未知な分野のコードを書こうと思っている人が、はじ
めにインターフェースを設計できるわけがありません。前述の話を引用すれば
最初からIDLでCOMを設計しようとすれば必ず挫折します。ましてATLがらみなら
どこブレイクポイントを置いたらいいのかさえわからないまま、挫折感だけが
残る結果となるでしょう。

まずは、低水準ディスパッチAPIでインターフェースと実装が一体となったク
ラスを動かしてみる。比較が必要ならクラスのコピペでクローンを作って実験
してみる。そいういった過程で型が定まったらインターフェースと実装に分割
してIDL化する。そういった一見泥臭い手順を踏まずに降って湧いたようなコー
ドを書けるわけがないのです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。
バイナリはHtmlEx.dllとTestApp.exeという構成にまとめました。exeを介し
た複数DLLの通信という部分に破綻の可能性がありましたので、単一DLLに集
約してIDLによるCreateInstance系に統一したという流れです。C++用JSエン
ジンもIDL化され、各呼び出しコンテキスト毎に生成するものとなっています。
実働するものを書かないと問題点をあぶりだせませんが、概ねこれが私の理
想とするHTMLアプリケーションの姿です。

EXE側ではHTMLリソース、必要ならIServiceProvider実装サイトを用意してDLL
をコールすれば、細かなことは何も考えずにアプリケーションを生成可能です。

ttp://kuroda.bglb.jp/htabox/image.zip
を公開します。HTMLとは何の関係もありませんが、ここ2,3ヶ月で得た情報を
フィードバックする形で生成された画像コンバーターです。見てのとおりな
アプリケーションですので、取り説はありませんが、機能にはなんら制限が
加えられていません。点描に代表される誤差拡散処理においては速度、仕上
がりとも満足のゆくレベルだと自負しております。WEB用にちょっとエフェクト
が必要な場合や、リソースとして256色BMP変換が必要な場合には重宝すると
思います。

ネイティブなウインドウ分割手法の見直し、タブコントロールサイズ変更時の
ちらつき対策への新たなアプローチ、監視スレッドを分岐させた自身CPU占有率
のモニタが適用されています。特に最後の課題は従来プライマリスレッドに余裕
を持たせ、高負荷スレッドを分岐させていましたが、監視スレッドにステータス
バーを管理させることにより逆を行うことに成功しましたので、とても自然な
コーディングになります。占有率が90%を超えそうな場合、動的にSleep(1)を
混入させる、というような事がごく自然に行えるわけです。

ttp://kuroda.bglb.jp/htabox/image.zip
を更新しました。サイズグリップはスレッドに敏感ですから非表示としていま
したが、表示させHITTESTで抑制する方式としました。
あらゆるアプリケーションでそうですが、特に画像処理において処理進行状況
を報告しようとすると、各動作毎に報告部分を埋め込む必要があります。これ
は大変面倒です。ユーザーにとって重要なのは「仕事をしているのか」だとす
れば、自身CPU占有率の報告で足りるし、これなら同一処理でいいわけです。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。
数日前に主たる開発機だったノートが10年以上の酷使に耐えかねて不安定状
態となりましたから、500MHzという低スペックノートでの開発となっていま
すが、いつもながらこれがいろいろと勉強になります。CPUパワーに依存した
部分を修正し、自プロセスモニタを装備しました。

純粋ネイティブなImage.exeと比較すると、フレームサイズ変更時の重さが気
になりますが、多重階層OLEコンテナで構成されている訳ですから、いたしか
たない部分です。

この世の中、特にネットワーク経由では虚々実々な駆け引きが行われている
訳ですが、こと「プログラミング」という分野では「嘘」が通用しにくいと
感じます。例えばこの掲示板で「なりすまし」を行おうとしても「書けるか」
どうかで直ぐに判明してしまうでしょう。

いい歳になって「虚々実々」には飽き飽きしたのです。私は実質で物事が評価
され、その実質を生み出した人間の労苦が報われる世界を夢見ています。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。CPP向けHTMLウインドウは
フレームというのが最大のチャームポイントになるでしょうし、そこでの拡張
OBJECT提供を考えた場合ベースとなるウインドウはモーダルにならざるを得な
いという結論に達していましたので、どうせモーダルならダイアログではなく
RunHTMLApplication呼び出しにしたらどうか？を検証していました。

結果的にやや軽量になることから採用しました。また、windows7+IE10環境では
従来の手法ではドキュメント生成を先回りして奪えないことから、より根源的
な部分のアドレスを置き換えることで対応しました。CPP用HTMLモジュールは
あくまで2重ウインドウのままで行く予定ですから、HTA:Applicationも有効な
状態が維持されると考えます。

RunHTMLApplication関数というのは単に実行してもMSHTAを外部実行するのと
なんら変わらない要素しか関与できませんのでダイアログよりも面白みの無い
存在なのですが、そこで生成されるだろうドキュメントを早期にラップするこ
とで面倒な事を一切書かずに目的部分だけピンポイントで変更した実体を作る
ことができます。ドキュメントをラップしているという事はそこへセットされ
るサイトも自由に制御できることを意味するからです。

この手法なら本来のコンテキストのまま、無理なくツールバーやステータスバー
の分だけドキュメントにどいてもらうことができます。

MSHTML.DLL内での生成HTMLドキュメント早期ラップという発想を推し進めると
統一した理論に到達します。例えばWebBrowserはDISPID_NAVIGATECOMPLETE2を
待たないと通常はドキュメントにアタッチできませんからWebBrowser固有なコ
ードを排除できないわけですが、早期に捕捉できていればその他の手法と同等
なコードで処理可能です。また、今後いかなる生成関数が新たに追加されよう
が、このCOM、OLE的ルールから逸脱しない限り必ず網にかかりますから原則的
に既存ライブラリを見直す必要さえなくなります。

C++レベルでのコード、モジュール管理、DLLの構築方法、プロジェクトへの
追加パターン、呼び出し時のコンテキスト問題等を加味すると、統一理論モ
ジュールはIDL生成のDLLになろうかと思います。HTABOXの場合、可能な限り単
体EXEが美しいのではないかと考えていきましたが、HTMLEX.DLL（仮称）が常
に隣接する形に変更したいと考えています。またこのDLLを単独で機能するよ
うにはしたくないのですが、ここをご覧になっている方に限定して、レジス
トリ登録可能バージョンを公開する予定です。本DLLをレジストリ登録した場
合、素のWSH環境からRunHTMLApplicationEx関数により引数付きでHTAウインド
ウを生成できるはずです。恐らくその状況でもHTA生成はプロセス寿命中１回
でしょうから、ShowHTMLDialogExも用意してダイアログベースなHTMLウインド
ウを何度でも表示可能にできればと考えています。

実際に書いてみて解ったのですが、HTABOXはまずネイティブウインドウありき
で、追加されるHTML要素をすべてウインドウ単位で扱おうとしています。それ
に対してC++用ライブラリの場合はまずHTMLウインドウありきですから、トップ
レベルウインドウはモーダルなHTMLウインドウです。この違いはそれぞれ目的
があっての事なのですが、両者で共通に利用可能なDLLは大変つくりづらいとい
う結論に達しました。強引にDLL化することは可能ですが、結局それぞれの環境
毎のコードを書くはめになりますからやったところで意味がないのです。

HTABOXはあらゆるスクリプトスコープから共通にトップレベルHWNDを操作可能
な事が最大のチャームポイントですし、そこに複雑さを持ち込む必要はありま
せん。また、C++用ライブラリの場合は動的なタブの追加に見られるようにドキ
ュメント側スレッドが変化してもプログラマーはそれをコードで吸収する能力が
あるものとしています。

初めてC++を書いた時のコンパイラはMSC7.0Aでした。ですから20年の歳月が
流れたことになります。J++がネイティブコードを出力した時にはこれでプロ
グラミング自体が変わると感じたのですが、企業間の抗争で事態は混沌を極め
ました。でもそのおかげでここまで深く原理を掘り下げることができましたし、
アプレットという道具が与えられたらどう使うか？ではなく等価な機能を自前
で設計した方が早いでしょう。ということろまでこれました。真剣に考えた時
間はここ数年なんですけれど、20年かかりました。

ttp://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ForCppフォルダを更新しました。細部を煮詰め、添付EXEを
生成したCPPコードを公開しました。HtmlEx.dll、var.hがありますので、VC++
をお持ちの方はコードを変更してEXEを生成可能です。逆に言えばお見せでき
ない部分はDllへ格納したと表現することもできます。放置モードレスが存在
した場合、親より消滅が遅れるというMSHTMLの仕様を嫌った部分が対症療法的
で美しくないのですが、それ以外の部分はこれ以上簡潔に表現はできないと思い
ます。C++によるCOMプログラミングはリズミカルで美しい(?)事をご覧になるだ
けでも価値があるかと思います。

DLLは非登録で参照しますからマニフェストが必要なので追加しました。
何らかのリソーススクリプトを追加し最終行に
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml"
を追加する事を想定しています。

1本か2本発表するだけなら、ウインドウクラス名がHTAなのでびっくりという
だけの一発芸なのですが、10本20本を一括管理可能なシステムだと言えば納得
していただけるのではないでしょうか。手作業では不可能なことを可能にする
のがソフトウェアですから、アプリケーション作成段階でその威力を最大限に
発揮しようという発想がHTMLアプリケーションの有効活用です。

C++用ライブラリの発想は極めて単純です。HTAまたはDLGを生成する関数に
生成されたIOleObject、IOleClientSite、FraHwnd、DocHwndの報告を受信
するクラスを渡します。それらがデフォルトな扱いを受ける前に報告は行
われますので、自由にできるということです。で、まったくゼロからホス
トしなさいというのも煩雑ですから、報告先が興味を持たない場合は既定
な動作、若しくは既定を少し拡張した動作が自動的に行われるというルール
です。

HTABOXがいかに進歩しても「プロへお勧めできるものになるのか？」疑問で
したが、これならプロに対しても自信を持ってお勧めできる環境になると考
えています。

今のところ興味の対象は自前なHTMLインスタンスなんですが、WSHハックで
使用したDLLインジェクションと、今回のオブジェクトラップを組み合わせ
ると、既存IEのドキュメントの左半分には常にHTML構造がツリー表示されて
いてクリックしたところへジャンプするとか、アフェリ画像は原則的にブロ
ックして、ツリー上でクリックされた画像のみを表示するとかということを、
プラグインのような従属的な立場ではなく実行主体として実現できます。
IE＋αをまさしくα分のコードで実現しながら「私が書きました」という実
に横着な展開が可能だと思います。

HTABOX本体に今まで蓄積したノウハウを適用して、より簡潔な構造とする作
業を行っています。HTABOXの場合は「スクリプトからの操作を簡潔に」とい
う方向性が明確になりましたので、それに沿った改良になります。単一CPP
最強という発想で1Mbを超えるソースになっていましたが、やはり可読性が
低下するのでDLLでのカプセル化を導入したいという思惑もあります。

HTML生成への低水準関与と基本的なOBJECTを提供するHtmlEx.dllのみを生成
するプロジェクトをルートに置き、各種EXE生成プロジェクトをその子とし、
EXE側ソリューションにHtmlEx.dllのプロジェクトを含めるという手法が最も
各ソリューションの独立性を維持しながら、各EXEの要求をHtmlEx.dllへ蓄積
しやすい状態と判断して全プロジェクトの再配置を行っています。

一旦HTML操作の大統一は無理と判断したのですが、上記手法で性質の違う両
EXEをビルドしながらDLLの内容を詰めてゆくことで完成することができました。
私とって最大の敵は私自身で、その後に手をつけたくないと感じるほど入り組
んだ構造を作ってしまうことですから、機能をCOMDLL化して外部とのインター
フェースを明確にするという作業はコメントではなくソース自体に説明させる
という理想への近道だと実感します。

HTMLウインドウの低水準操作をIDL化することで共有可能なライブラリとして
パッケージできましたので、もうひとつの柱であるリッチエディタをIDL化し
ています。

ただしCOCLASSは継承した拡張ができません。エディタの場合A,B,C,Dくらいの
段階を踏んでメソッドを増やし必要に応じた段階のインスタンスを生成したい
のですが、IDLは型と実装を厳格に管理する事が目的ですからしかたが無いこ
となのでしょうが。

そこで通常のC++継承の流れとIDLインターフェース継承を並列な構造とし、
IDL側は常にIUnknownを基底として、拡張されたメソッドのみを定義、型
チェック目的でC++継承時に基底クラスとIDLインターフェースを継承、
COCLASSの継承元をIDLインターフェースではなくC++クラスとすることで結果
的にCOCLASSには拡張されたメソッドのみを定義すれば足りる状態とできる
ようです。

この場合高次な派生インスタンスから低次なメソッドを呼ぶ場合はダウンキャ
ストが必要です。COCLASS自体は低次なメソッドを知らないわけですからC++
実装クラスへQueryを転送し、親側なら親へ転送、現在拡張中のインターフェー
スならstatic_castでVTBL生成インスタンスを返す事がポイントとなります。

上記ロジックで実質的にCOCLASSの多段継承が実現できるわけで、引数型が制
限される見返りに自動的なマーシャリングが得られるとすれば、ありとあらゆ
るC++クラスを通常の継承構造のままCOMDLLとして提供できることになります。

実行時コンテキストの差異を気にすることなく、何でも提供できると同時に
手の内を明かす必要が無いとすれば、大変素敵なことだと思います。

以前はMSHTMLに対してあれとこれができるからそれを組み合わせれば...的発想
だったのですが、いつのまにか総て可能な中から必要なものを選択する状態へ
進歩しました。統合されたHtmlEx.dllは200K強ですが、僅かこれだけのモジュー
ルでMSHTML関連の膨大なモジュールを自在に制御することが可能です。

ただ、その膨大なモジュールを書いている人間の立場になれば公開もしていない
ポイントを突いて自由にコントロールされる事を好ましくは思わないでしょう。
ですから、将来にわたってもこの内容を公開することは無いと考えます。内容
を公開すれば、たとえOLEの基本的な構造を外したとしても、回避策がとられる
可能性を生んでしまいます。非公開ならWindowsある限り動くものをみすみす自
滅に追い込む必要はないのです。

もし私に十分に口の堅い後継者がいればこの技術は受け継がれ、HTML系のウイン
ドウはMS側の公式ドキュメントに関わらず、あらゆる操作が可能な状態が維持
されるでしょう。そうでない場合、私の生涯が終ればそのような状態も終わり
を告げることになるでしょう。私だからこそ、なし得た事がこの世にひとつく
らいあってもいいのではないかと思います。

MSHTML由来のすべてのHTMLウインドウをプログラマーに解き放ち、あれができ
ないこれができないという事柄を無い状態にするというのが第一の目的ですし
綺麗にCOMDLLへパッケージ化できたことで、多言語へそれを提供することも可
能となりました。このパッケージにはネイティブダイアログ中にドキュメント
のみを埋め込んだ動的軽量ダイアログが含まれます。

次にHTMLと親和性の高いスクリプトでアルゴリズムまで記述した場合の対クラ
ック対策ですが、これはC++コードにおける擬似JScript手法が回答となります。
もし、スクリプトによるアクティブデバッグに魅力を感じるなら拡張VBScript
でのコーディングが安全ですし、カジュアルクラック対策としての独自エンコ
ードも選択肢の一つとして残そうと考えています。

「あなたの書くコードは他の従業員が理解しにくい」という理由で解雇され
た元プログラマーのサイトを見ました。日本という国がすべてそうだと思い
ませんが、「誰でも書けそうなことを誰でもわかるように書く」ことが書け
ない上司にとっては都合のよいプログラマーなんでしょうし、私は腐っても
そんな身分にはなりたくないと歯を食いしばって勉強してきたと思います。

繰り返しになりますが、アプリケーションを作成する過程自体をアプリケー
ションで効率化し、個人で完結した製品を複数管理可能にする。そういった
システムが無ければ、多くの有能なプログラマーの叡智や苦労はかけもしな

い連中の食い物にされ続けるでしょう。私はこの国に根付いている「出る杭は」
的風土にはとても疑問を感じますし、誰かがそれを打破して見せなければ、こ
の国には将来が無いとさえ思います。

完全にスレ違いな事をご容赦いただければ、とうに50才を越えた私は、私の
半分くらいしか歳をとっていない若者達には十分に謝罪しなければならない
理由があると考えています。この世界を、この日本を良しとして黙認してき
た愚者としての責任です。

なぜ戦争が勃発し、それが誰に利益をもたらし、誰の血が流れるのか、そして
それが一握りの人間の私利私欲を発端とすることは明白であるにも関わらず、
少なくとも自身の立場が受益側にあればいかなる暴挙も犯罪とはならない世界。
縁故やコネクションで形成され、自身の儲けにつながらなければいいかなる才
能も黙殺しようとするこの国。

心から謝罪しなければなりません。こんなものを見せて夢を抱けというほうが
無理です。ただ、私は感じています。従来の資本ありきを覆す力がソフトウェア
にはあり、それがこの社会を根底から変革する起爆剤になりえることを。

開発環境をWindows7+IE10に移行する作業をしています。WindowsXPをターゲッ
トに含めるためにはWindows7上でVS2003を実行する必要があるようです。
VS2005以降はVista以降の環境で動作させた場合にXPで実行可能なEXEを出力し
ないように見えます。サイズが小さいことから、XPまではスタティックにリン
クされるべきモジュールがVista以降では動的なロードになっているのでは
ないでしょうか。

OSの提供元が民間企業ですから利益を追求するのはいたしかたの無いことで
しょうが、過去のOSやコンパイラを持っていなければXP用のネイティブEXEは
生成できず、どうしても必要ならMSDNへ会費を払うしかないというのは、プロ
グラミング離れの要因になっていると思います。

VS2012ならプラットフォーム ツールセットをv110_xpとかWindows7.1SDKにすればええんちゃう

私の手元には無いのですが、新しいVSはプラットホーム指定が可能という
情報は確かに目にしています。選べるということは動作を保障するという
ことでしょうから、開発者サイドに立った前進だとは評価しています。

ttp://kuroda.bglb.jp/htabox/image.zipを更新しました。
画像サイズ変更、表示倍率に対応しました。現バイナリにはなんら機能制限
を設けておりません。また、ヘルプは整備されていませんが見てのとおりに
作ってありますからそこそこ遊べると思います。

アプリケーションのイメージは下記のとおりです。
ttp://kuroda.bglb.jp/htabox/converter.png
尚、本アプリケーションにかかる全ソースコードを息子に譲る予定です。
たま、サイズ可変ウインドウのC++的設計から開始し、本アプリケーション
を完成させるまでの過程を「画像処理アプリケーション入門」的なサイト
に仕上げて公開したいと考えています。

image.zipを更新しました。マイナーなバグ対策を行いました。左パネルでの
1,4,8bitによるBMPファイル生成で誤差拡散定数を３択可能にしました。

先頭の定数はごく一般的数値ですが、それ以外は素数の組み合わせによる
オリジナルな定数です。点描(1bit)でその違いを観察すると興味深いもの
があります。

ちょっと本筋からは外れますが、ナイト巡回問題の解法についてのドキュメン
トと巡回の経緯をグラフィカルに表示するアプリケーションを公開しました。

http://webbot.web.fc2.com/

数行のJScript、又はVBScriptで各パラメータを変えた巡回シュミレーション
が可能ですから、数学好きな方は楽しめるかも知れません。
リッチエディットを拡張されたコンソールとして使い、ユーザースクリプトの
パースを独自エンジンで行う。ヘルプはMSHTMLの独自制御で行い、ヘルプ自体
はワードの２段組イメージをOLE的に画像化して生成する。僅かずつですが、
今まで蓄積してきたことの総決算的意味合いもこめられています。

いままでブログと言われるCGIがどんな動きをするのか勉強する気もなかった
のですが、情報を効率的に拡散させるためには必要だろうという観点から調査
してみました。非常に興味深かったのはHTMLメールで画像のアップロードと
それを表示するHTMLが形成されることです。HTMLメールはMHTと同じ形式で、
画像データをエンコードした文字列で表現しますからなるほど可能な訳です。

ということは、WEB上の情報収集と自身ブログへの情報保存をまったくロボッ
ト化できることになります。時系列で変化する情報を１時間毎に収集し、１日
に24回送信を行う。何月何日何時の情報を見たいという要求の処理は、もと
もとブログというものがそういうデザインなので考える必要が無い。また、
画像等を主たる情報とする場合、ブログサーバー上の容量制限が問題となる
が、その場合は自前サーバー、若しくは他サーバーからのGETに答えうる別
サーバー上に画像を置き、そのURLを参照するHTMLならいいという展開です。

工業分野でのロボットは目で見ればそれが生身の人間では無いことが明らか
ですが、WEB上ではその操作が人間によって行われているのかロボットによ
って行われているのかを知る方法はありません。自動ブログ生成を考えた場
合課題となるのは収集ターゲットページ上のどの情報を収集するのかを視覚
的に表現しうるGUIのみ（マウスでポイントされたエレメントを明確にする）
ですからIE動作にインジェクションを行うまでもなくWebBrowserをOLE的に
カスタマイズすることで可能だろうと考えます。HTMLメールはCDOによりごく
当たり前に作成できるはずです。

話は飛躍するのですが、アルゴリズムで表現できる作業というのはすべて
ロボットが行うようになりますし、人間の側というのはそのアルゴリズム
を考えることに専念するようになるはずです。ですからおおかたのWEBデザ
イナーとオペレータでしかないプログラマーは働く場所を失う運命にある
のではないかと思います。

ターゲットURLのストリームを偽装して、独自オブジェクトが宣言されている
かのうように見せかけ、HTML側コンテキストに侵入しての操作が可能なのでは
ないかとチャレンジしていますが、iframeがらみの複雑な構造のページで成功
しません。IInternetProtocol系で探りを入れていますが、もっと低水準なス
トリームレベルでの介入が正解なのかも知れません。これが成功すると、
サーバー側に通常コネクションのまま、人間業ではないレスポンスを返すこと
ができますから、何らかの対策が施されているという可能性もあります。

某気象情報サイトをターゲットに、サーバーレスポンスへOBJECTタグを挿入
することに成功しました。ディスパッチならWebBrpwserがインタラクティブ
を報告した時点で追加しようが、動作させようが自在に可能ですが、ページ
構造が複雑化するとディスパッチでは解決できない問題が生じるようですから
OBJECTタグの挿入が唯一の方法だと現時点では判断しています。

モニカの基底にあるストリームを書き換えてしまうというのが、今回のキー
ポイントですが、これを悪い方向に使うと「ブラウザはレスポンスしたHTML
を素直に解釈している」というサーバー側の大前提が覆る訳ですから、混乱
の要因になりかねません。現時点ではブラウザ上にページスクロールと同期
する半透明ウインドウを置き、当該ウインドウ座標のDCイメージを取得する
ロボットを作れればと考えています。もちろんEXE全体はスクリプト等で制御
でき、定時に同じ動作を自動的に行うことになります。

考えてみると今回成功したモニカへの介入は、ブラウジングの世界に革命を起
こす可能性を秘めています。なぜなら、サーバーとの間で行われたあらゆるデ
ータ通信をローカルに保存して再現することができるからです。たとえそれが
ストリーミングのようなものであってもです。

また、従来ブラウザ上のマクロ動作というと「表示されていること」を前提
とした手法が主になっていますが、私のボットは定期動作時に非表示である
ことを前提として設計されています。場合によってはEXEではなくシステム
として常駐しWEB上でのロボット動作を極めて高速に処理するという構想を
持っています。

非表示なまま、事前に定義された矩形の画像を自動取得することには成功し
ました。これはOleDrawで実現されているため、画像としての保存が抑制さ
れていても、表示されているのであれば保存を拒むことは不可能です。

もうひとつの課題である「全ストリームのローカライズ」が可能なのかを
検証したいと思います。サーバーとの交信がすべてモニカ経由であるとすれ
ば、ひとつのセッションで発生した情報をすべてファイルへ保存し、その
順序や取得元URLをXML管理して、再度同じページに対して要求が発生した場
合に偽装して再現することが可能だと考えています。

基底のHTTP又はHTTPS動作へもぐりこめれば特定のMIMEに限定されない汎用な
情報操作が可能だと予測しますが、私が思い描いているイメージと実際との
間にかなりの食い違いがあるようです。例えばvideo/x-flvのようにMIMEが
具体的ならキャッシュはできますが、周辺データに取りこぼしが生じては完全
な偽装を単純な機構で実現するという目的から外れますので継続した課題
になりそうな気配です。

スナップショットが撮れるブラウザについては周辺機能を整備して、任意な
URLで動作する状態をお見せできると思います。

ttp://kuroda.bglb.jp/vector/webbot.zipを公開します。
シンプルなWebBrowserコントロールにネイティブなレイヤーウインドウを重
ね、メニュー又はレイヤー上のsボタンで画像を保存できます。初期URLは
exeと同じ位置にurl.txtを置けば設定可能です。存在しない場合はデフォルト
ページが表示されます。動画を見ながらスナップショットを取るような用途
に大変適していると思います。

他人様が書いたHTMLページが相手なものですから、クッキーがらみのスクリプト
が動作するページではスクリプトエラーと表示される場合を確認していますが、
表示されたページのピクセル情報取得が目的ですから、エラーダイアログを
消していただければ、本アプリケーションは問題なく動作します。
開発はIE10環境で行いIE9,IE8での動作を確認しています。本来これはロボット
として定時に動作する目的で作成されていますが、手動で操作するエディション
はフリーソフトとする予定です。

IE7での動作も確認しました。スクロール情報と、要求矩形の精度を向上させ
るために独自OBJECTを追加しているのですが、PCのパフォーマンスやページ
の重さでたまにストールしますので、更にチューニングを煮詰める必要があ
るようです。

自分が書いたHTMLを解釈するのがHTMLアプリケーション（HTA）手法で、他人
様が書いたHTMLを解釈するのがWebBrowserだと思ってきたのですが、WebBrowser
はインストールされたIEの切片ではなく別物なのではないかと思えてきました。

つまりWebBrowserをサーバー側に本当のIEだと思わせるのは不可能では無いに
しろ大変な労力がかかる気がします。そんな苦労と、IEバージョンが上昇する
度のメンテナンスを考えると、本物のIEを起動して憑依した方が得策という
結論に達しました。プロセスへの侵入は定石どおり成功しましたが、ドキュ
メントの生成機序がいまいち掴めません。過去に実績がある乗っ取り手法は
今のところカスリもしません。それだけ困難だということは、それを乗り越
えられる人間も少ないということですから、腰をすえて取り組みたいと思い
ます。

IEのタブは各自別プロセスなのですが、親である起動実体が子プロセスを
起動する手段が通常のCreateProcessやCreateProcessAsUserではないように
見えるというのが問題の本質なようです。ただ、ロボット動作に必要なのは
生成に関与することではなく、通常動作させておいて適切な時期に制御を奪
うことですから、発想を変えればエレガントな手法があるだろうと思います。

IEプロセスへの独自DLL連鎖インジェクションに成功しました。起動EXEは最初
のIEのみをケアし、DLLを注入、DLLは自身プロセスで新たなIEプロセスが生成
される場合、自身のクローンを注入という流れが最も自然なようです。これを
親EXEで全部管理しようとすると相手が非同期で複数ですから、クラッシュの
可能性が出ますし、プロセス越えのマーシャリングコストで動作の切れが失わ
れるでしょう。開発はIE10で行いましたが、結果的にはIE5以上なら動きそう
な単純な呼び出しで実現されています。

僅か10日ほどで結論付ける事ではないのかも知れませんが、WebBrowserで汎用
なブラウザを作ろうと言う試みはやめた方が無難です。ユーザーエージェント
が正しいとするなら、WebBrowserはIE7相当のドキュメントしか生成しませんか
ら、より上位なブラウザ用に書かれたHTMLで予期せぬエラーに見舞われます。

また、IE8以降はタブを別プロセスで管理しているようですから、制御には
DLL注入が必要となります。つまりネイティブなDLLを書ける環境でなければ
ちょっかいを出すことはできません。また、DLL注入は通常のブレークポイン
トを使用したデバッグができません。データをファイルに出力するか、Beep
等で状態を推察しながらのプログラミングとなります。

理論的には無限に連鎖してナビゲート先のドキュメントプロセスへ介入する
はずなのですが、ドメインの変移を行うと不定回数で追跡がストールしてし
まうようです。興味深い事に、最初のIEインスタンスは比較的従順で、それ
を起点に生成された方は御しにくいように見えます。しかも、既存IE実行中
に、別プロセスグループとして起動しても「最初」とは認識されていない
ようです。IEは最もいじられる対象になりやすいモジュールですから、予期
せぬ低水準な操作に対してある程度の耐性が施されているのかも知れません。

Windows7+IE10環境ではIEが別窓で複数存在してもIE自体は同一プロセスの
ようです。つまり親HWNDは別スレッドで動作していることになります。また、
ドキュメントは必ず別プロセスですから、話がややこしくなります。この状
態で安定的にHWNDやIWebBrowser2のコンテキストを見極める事ができていま
せん。あまり深入りせず、マーシャリング経由で目的を達成できないのかを
再考察する必要があるかも知れません。

複数プロセスに分散ロードされたDLLからの報告を表示するエディタウインドウ
というのを以前に書いていたことを思い出し、デバッガ代わりにデータを出力
させてみたところ、どんな状況で何がだめなのかが掴めたようで、IE乗っ取り
ライブラリは完成しました。

通常はIEに限らず何らかの機能追加をしようと思えばCOMDLL登録してプラグ
インするわけですが、そのような手間はまったく要らず、起動EXEがIEを包
括的に管理します。ネイティブなIEのHWND群やドキュメント群を本来の動作
の前にカスタマイズできるわけです。内容はごくオーソドックスなAPIの集積
なんですが、いかにターゲットスレッドのコンテキストに寄り添う形で全体
をデザインできるかという問題がとても難解です。難解であるが故にこの分野
でのアドバンテージとなると感じています。

HTA系のMSHTML利用では、あらゆる生成過程に介入して、今までに見たことの
無いものを実現しようとした訳ですが、今回のIEカスタマイズでは、生成に
関与することは一切やめ、HTMLのパースで起こるエラーはIE自体のものである
という状態を作った後に適切なタイミングで制御を奪うという手法をとりまし
た。現状ではすべてのEXEインスタンスが共通なDLLを強制ロードされて動作
しますが、IDLにはHWNMDのマーシャリング機能もあるようですから、分散さ
れた各プロセスのDLLが集約DLLで定義された型へ情報をコールバックする形
にすれば汎用なライブラリとすることも可能です。

つまりカスタマイズされたブラウザを作りたい場合に、ブラウザ自体を書く
必要はなく、マイナーなバージョンアップが行われてもメンテする必要が
生じないにも関わらず、ドキュメントの左側にネイティブなツリービューを
置いたりできることになります。

タブ操作で親HWNDが受け取るメッセージを眺めるとドキュメント生成完了
タイミングで送信される非公式なメッセージを見出すことができます。
このメッセージが確実なものであれば、ドキュメントプロセスでの生成完了
を自力で検出する必要が無くなりますから、基本動作ライブラリは20kを切る
くらい短いコードになるかも知れません。

IEとHTA手法の融合というアイディアも面白いと考えています。つまりIEの
タブにHTAを埋め込む、又はローカルセキュリティーのWebBrowserを埋め込む
手法です。通常は例えマニフェスト定義でも、独自なCOMオブジェクトを利用
する場合は管理者権限が必要だと記憶していますが、IEを起動するEXEにその
必要が無いとすれば、IEに侵入させたDLLで、安全とマークされたCOMDLLを
インスタンス化している振りをしながらファイル入出力等のアプリケーション
動作をさせる事は十分可能だと考えます。

上記発想をHTABOXに適用すると、EXE化されたユーザー生成ファイルを実行
すると、初期タブにEXE内リソースHTMLを表示したIEが出現する。このタブ
では何の警告も無しにアプリケーション動作が行える。メニューこそポップ
アップウインドウで無いので使用できないが、他のネイティブコントロール
、デザインビヘイビアも機能する。2番目以降のタブには自身サーバーのオン
ラインヘルプページや、試用版なら製品版購入フォームを表示する。
というような事が実現できます。まぁ外観がまんまIEですから、利用される
側の心情を考えるとデリケートな問題をはらみますが、IE自体はCOMとして
独自生成しても問題は無い訳ですから、新しい発想のアプリケーション形式
として提案する価値があると感じています。

ttp://kuroda.bglb.jp/vector/iecamera.zipを公開します。名称は「IEカメラ」
動画等のスナップショットを撮る目的に特化されたIEカスタマイズアプリです。

インストールの必要は無く単にEXEを実行すればIEが起動します。使い方は
単純です。表示されるターゲットマークをクリックしてアクティブにし、
移動、サイズ変更後に、Enterで画像取得という流れになります。詳しくは
ReadMe.txtをご覧ください。動作確認は32bit環境IE10,IE9で行いました。
IE8で動作する可能性はありますが、IE7はプロセス構造が異なるため動作
対象に含まれません。

本来は非表示取得した全ページイメージから指定座標部分を抜き出すので
すが、IEに表示した場合との座標差が生じるページが散見されますので、
表示中DCの単純取得としています。本アプリケーションはこの機能のまま
フリーソフトとして公開する予定です。マクロ動作等は製品版の機能という
ことになります。

画像キャプチャというと、全画面PrintScreenをソフトウェア的に切り出す
手法しか存在しないと思いますが、ターゲットマークがページスクロールに
同期する事で、これがIE内部への侵入で実現されていることが判ります。
もし、同期しないスクロールが必要ならCTRLキー押しでスクリーン座標に
固定されたスクロールが行えます。

私にとってこれはMSHTML.DLL解析の卒業論文のようなものです。結局IEは
コンテキストにデリケートで余計な所に触らない方がいいという結論だった
のですが、それを感じるためには他のHTMLオブジェクトとの比較を行える環
境が不可欠だったと感じています。

ここをご覧の皆さんはごく一握りの「書く側」の人間な訳ですが、世の中の
ほとんどの人間にとって開発ツールとしてミドルウェアなどは縁の無い存在
ですから、こういったすぐに使えるツールを書きながら基底ライブラリを固
めることになろうと思います。