他言語との融合アプリケーション環境としてHTABOXコアの開発を
行っています。このスレッドはHTABOXコアへのご意見、ご要望を
気軽に書き込むために存在します。現在3.00のリリースに向けて
作業を行っています。
現行バージョンサイト
ttp://kuroda.bglb.jp/htabox/
ttp://kuroda.bglb.jp/htabox/htabox300.zip
ネイティブモジュールにより、メニュー、ツールバー、コンテキストメニュー
ステータスバーを生成し、いづれもHTML中のタグ、スクリプトで簡単に制御
可能です。DHTML手法によるGUIとは一味違うレスポンスを体験できます。
ね
ボ
け
マウスオーバーしたときにステータスバーの表示が元に戻らないのですが…
ッ
ポ
ー
ー
ン
当方の環境では体験したことの無い状態のようです。「表示が戻らない」を
もうすこし詳しく教えていただけると助かります。ツールチップが表示され
たままなのか、ボタンが押されたままなのかとかです。
尚、ツールバーはHTMLオブジェクトではありません、本物のWIN32ツールバー
ですから、そこにあるマウスはHTMLのコントロール下にはありません。
パ
ニ
ー
ト
例えば、createElementでもOBJECTは指定できますし、実際に追加できます。
これと、パース初期からCLSIDで生成されたOBJECTはまったく別物であると
いうのがポイントなんだと感じました。
に大別できます。ひとつはIUnknown系でもうひとつはIDispatch系です。
前者はHTMLをホストする側のメンバーとみなされCOM的な機能の拘束がありま
せん。例えばデータバインドはOLEDB系インターフェースが有効な環境でなけれ
ば機能しません。このDLLにprogidを与え、ActiveXObjectでインスタンス化
しても本来の動作ができないのはこれが原因です。
ースを提供できる言語なら、面倒なCOM登録動作無しに、HTMLをホストする側
のコードが書けるようにするためです。どんな言語での拡張も、後者のディス
パッチ系とみなされた場合、提供モジュール内の動作は高速かも知れませんが、
肝心のHTMLインスタンスとの通信はすべてディスパッチ経由となり基本的に通
常のスクリプトと大差ないものとなる可能性が高いのです。
ビヘイビアやActiveXコンポーネントに必要な中間手続きを一切引き受けて、
その先に集中できる環境を用意することだと考えています。そのために欠かせ
ない用件をクリアしたと考えています。
<OBJECT ID="HOGE" CLASSID="clsid:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">
<PARAM NAME="ref" VALUE="hoge.dll">
</OBJECT>
でまったく任意なDLLをIUnknownベースとして機能させることができます。
ャ
ポ
ニ
ー
ル
自己増殖はちょっと無理があるようです。実際にHTML書かれている宣言で生
成されたインスタンスと例えホストコンテキストとはいえ動的に生成された
インスタンスでは細部の動きに違いが見られました。GUIDの偽装そのものは
まったく安定していますので、現時点で考えうる最善の方法は、先頭の偽装
で以降の転送先DLL、呼び出し関数をPARAMとして全てセットし、ここでは何
も生成せず、2つ目以降のOBJECT宣言からインスタンス化を実行することです。
ロ
パ
ニ
ア
<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"/>
という書き方にすればいかなる条件下でも実際にレジストリ登録されている
ものと同一な動作になるだろうと推定します。
ニ
モ
ニ
ル
ア
が、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>
エ
ヒ
ソ
ー
ル
原理的にはあらゆるブラウザ対してに有効です。こうされることを想定して
対策されたDLLロードの方法をとれば別ですが、普通そんな面倒くさいことは
書かないでしょう。これは余りにも飛躍しすぎる機能拡張ですので、当面先送
りされますが、原理的にはあらゆるブラウザをHTMLアプリケーションのベース
として借りることができます。もしかして、「うちのPCにはIEないんだよね」
という状況が生まれても、WindowsOS上であれば動作可能なアプリケーション
になるわけです。
ニ
バ
ニ
ア
やスクリプトのエラーとは違い手がかり無く全体がストールすることになり
ます。情報収集はほぼ完了しましたので、しばらくの間はHTABOXのヘルプ等
内部で使用して厳しい条件にも耐えうるかを試験しますので、一般に公開す
る機能として、このレジストリフリーなOBJECT宣言を提供するのはまだ先の
ことになります。
今回決定したかったのはデバッグ用外部JS、VBSの実行エンジンをビヘイビア
階層とすべきかオブジェクト階層とすべきかでしたが、当初のままビヘイビア
で行きます。
ェ
フ
ェ
フ
ェ
フ
ェ
予定です。従来の動的マニフェスト管理は残します。また、以前話題になっ
た、強行実行時のインターネットアクセスについては、今回検証したのAPI
フックによる要求時DLL置き換えで無害なものに置き換え抑制することが可能
だと考えられます。
ホ
ル
イ
ア
というのが正直な感想です。「これが可能です」と一つ機能を提供するだけ
では事態を収拾できなくなる可能性があります。広範囲な機能をHTABOXとい
う一つの看板に盛り込むよりも、べつなアプローチのライブラリとして提供
した方が受け入れられやすいのかもしれいと思います。
燥感だけで生きているものですから、何かにめどがつくと、その分だけ私を
起こそうとする内分泌系が低下するのかも知れません。
ビヘイビアの導入がそうであったように、低層でいかに面倒な事が起こって
いようが、ユーザー側にはそれを意識させないという事が実現できなければ
ソフトウェアとして意味がないわけですから、HTMLやスクリプトに軸足を置
いたコンセプトとして、プラスアルファで何でもありにすべきですね。
ら、IDispatch系はHTMLインスタンスのエラートラップが有効な状態で活性化
しているという表現ができると思います。したがって、総てがストールするよ
うな状態にはならず、エラーダイアログが表示されるわけです。これは速度的
には不利な状況ですが、なぜHTMLアプリケーションが作成しやすいのかという
根幹に関わる特性ですから、やたらと低水準を目指してそこを踏み外しては本
末転倒になります。
スタンス生成前にホスト側として介入する手法、レジストリフリーなOBJECT
としてHTML生成初期に介入する手法を提供すれば、納得していただけるんじ
ゃないかと思います。
わせる動作もしますので、ここでインターフェースを返すと、独自スクリプト
エンジンをHTML側のスクリプトサイトと共有する状態で追加することができま
す。ここで単にJScriptをパースした結果を渡してもメリットは望めませんが、
VBScriptエンジンを初期化し、JScriptパース結果をVBの空間へ転送した後に
HTML側へ公開できれば、かなりの高速化と堅牢なソース隠蔽が実現できるので
はないかと考えています。
事になります。もし動的な変更が必要なオブジェクトがあれば、それだけ直
接HTMLへすればいいですし、逆にアンダーバーで開始する単純関数だけを非
公開な高速動作関数としてVB化するという選択肢もあると思います。勿論開
発時は単なるJScriptとしてブレイクできなければなりませんが。
を更新しました。デュアルスクリプトエンジンデモを追加しました。
ソースの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関数が
生成されますので、関数を増やしたり書き換えても動作するはずです。
{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が提供するサイトを使っているから、このようにデバッグが可能
となると推定されます。もしこの状態でデバッガの追跡が好ましくないなら
スクリプトサイトを自分で構築する。それでも追跡されるならコンテキストを
変える。という流れになるはずです。
へ置き換えられると思います。しかもコンストラクタとデストラクタを定義
できます。ただし、コンストラクタとデストラクタに引数は許されません。
まぁこれはオブジェクト指向的には当然な事で、引数のある初期化が必要な
時は初期化関数を用意して、その返却値で生成の是非を確認すべきです。
ましたが、やはりコンストラクタへの引数は受け付けないようです。コンス
トラクタ引数がないことがオブジェクト指向的には当然なわけは無くて、
当たり前に引数付きでコンストラクトしますよね。ただ、コンストラクタは
できるだけ軽量な設計として、何らかの初期化動作が必要な場合は、初期化
関数を用意すべき。と言うのが正しい言い方です。お詫びして訂正します。
VBSのクラスではPROPERTYGET、PROPERTYPUT、PROPERTYPUTREF用のメソッド
を明示しなければならないようです。もし、まだnewされていない擬似クラス
をVBS側へClass定義だと思わせれば、なんの苦も無いのですが、さすがにそ
れは通らない要求のようです。まだnewされていないfunctionのメンバーは
当然ディスパッチ的には列挙できません。従来のJS->JS転送ではその問題を
インターフェースのラッピングで乗り越えるのですが、JS->VBでもそれが必
要となると、なんらメリットを見出せないことになります。ちょっと休んで
考えてみます。
テクニックであるJS->JS中継を行いながら、アタッチしてのデバッグ、長大
なソースコードを想定した別スレッドパース等を検証して外部スクリプト仕
様を決定したいと思います。
ようです。つまり開発モードではHTMLが提供するサイトを使用し、リリース
時(隠蔽が必要なら)従来の独自サイトで動作させます。独自サイトも全くエ
ラーに無関心では困りますので、エラー行とエラーの原因だけは表示させて
います。リリース後にユーザーからバグ情報があっても迅速に対応できると
思います。
せんでした。このままでは数百kみたいなソースが来たときにもたつきますの
で、非表示ウインドウ生成によるPost動作で克服できそうです。今回のように
動作をブロックしたくないが、別スレッドでは実現できない局面は結構頻繁に
訪れます。そんな時このPostトリガー用ウインドウは有効な解決策だと思いま
す。これはあくまでも推測ですが、Internet Explorer_Hiddenもそういった
必要から生成されるウインドウではないでしょうか。
を更新しました。従来型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への動的な要素の追加
PUT|PUTREFは無視されます。本体の関数機能要求のMETHOD呼び出しにしか応答
しないと言ったほうが早いかもしれません。ただ、軽量化のためにJS->JSで
はなく単独JSを試していますので、まだ十分な防御力があるとは言い切れませ
ん。
に"function"という文字があればそれを強制置き換えすることで隠蔽が破綻す
ることを狙うでしょう。現時点のバイナリでそこまでの配慮は行っていません
から試してみてください。リリースする段階ではそういったクリティカルな
静的文字列は総て暗号化され実行時の必要な瞬間だけメモリ中に生成されるこ
とになります。
(＾ｑ＾)
を更新しました。隠蔽時に使用するサイトが表示するエラーダイアログに、
エラー発生位置コードが文字化けするバグがありましたので修正しました。
のスクリプトタグです。単体ファイルとして取り扱いも楽ですし、コード全体
が大規模でない場合、外部スクリプトを使う必要は無いでしょう。
2つ目は非表示なスクリプトパース専用HTMLを併用する方法です。デモではjs
ファイルとしましたが、結局HTML実行しますので、スクリプトタグに各種言
語を記述できるものとします。この非表示HTMLのパースは本体のパースを阻
害しません。本体スレッドはこの補助HTMLへモニカをセットして即座にリタ
ーンし、本体HTMLの構築を続行します。
通常はこの2種類で十分だと思います。それぞれで.NETパース、隠蔽機構は
有効とする予定です。
DLL等を直接埋め込むための手法と捕らえています。今回の実験ではDLLを作る
のが面倒なので、スクリプトをパースしたディスパッチを模擬DLLとして情報
収集しましたが、スクリプトの利用では、機能と速度において顕著なメリット
が見られません。またOBJECTタグは記述にミスがあると全体がすっ飛ぶにも
関わらずなんのエラーも表示されないわけですから、高度な利用法として一線
を隔した扱いにする予定です。
ホストサイト入れ替えによるビヘイビア拡張、APIフックによるロードDLL偽
装の2つを解決した事で動作コンテキストを完全に統一することができました。
別コンテキストから何かを待って横槍を入れる必要がまったく無くなったこ
とにより、見てのとおりスムーズな動作が実現できました。
取り説を書いては消しがいやなので書き直す必要が無い土台を作る為の技術
の方へつい向かってしまいましたが、今はこの軽快さを一人でも多くの方に
見ていただきたい気持ちでいっぱいです。
をやっていました。さすがにクランクシャフトはプレス機がないと組めませ
んから分解できませんが。特にCBX550F2Dが好きで2台持っていました。
そこですごく細かい話なんですが、ネジというのはいかに適正なトルクで締め
付けても、少しずつ破壊されてしまうんです。ネジが緩まないということは、
ミクロな観点から見れば不可逆的な破壊が起こっているからで、双方とも何
の変化もしないのであれば、するっと抜けてしまうはずです。
何一つ消耗したり、磨耗したりしません。また、クランクシャフトのように
設備がなければ手を出せない部分というのも存在しません。
また、型式が登録されていなければ公道を走れなかったり、ライセンスや
レギュレーションが適合しなければサーキットを走れなかったりという制約
は一切ありません。なんと素晴らしいことでしょう。
低層での面倒を包み隠すことにあった訳ですから、取り説にはレジストリ
とかマニフェストという言葉が出現しない状態としなければ意味がありま
せん。つまり「隣に置いてください」で総てが解決できる完全なサイドバ
イサイドのモジュール連携をHTABOXが提供するというコンセプトです。
いまどきHTAとか、ボンクラ役場でも需要ないやろ。
を更新しました。単独の起動では発生しないのですが、ビルド直後というよう
な厳しい状況下で稀に起動がストールすることへの対策を加えました。
であるMSHTMLをいかにコントロールできるか？という事が今より重要視され
る時が来ると考えています。ユーザーにとって重要なのは四角い窓がどんな
テクノロジーで生成されているかではなく、その内容です。ならば作る側は
最短の労力で内容に集中できる環境を選択すべきです。
HTABOXはHTMLアプリケーションをリリーする段階でEXEファイルを生成します。
ユーザーはその四角いウインドウがHTMLアプリケーションであることを知る
ためにはSPY++でウインドウクラス名を確認する必要があります。
こそ最高のもの」という考えがあります。誰しもが自分の経験やアイディア
をできるだけ低い敷居でアプリケーションとして公開できれば、それを使用
する側にもメリットが生じるわけです。
HTABOXはアプリケーションを書く人のための参入ツールであり、HTMLのGUIを
C++等と癒合したいエキスパートのためのツールでもありたいと考えています。
了解しました。非表示でHTMLインスタンスを生成し実行している部分のコード
を洗い直します。OSとIEのバージョン、それからエラーの出方（windowsシステムから？）
を教えていただけると大変助かります。
<body bgColor=#9999ff>
<HTABOX:Extern id="JS" src="test.js"/> ＜−この行を削除
した場合にエラーが発生しなければtest.jsがらみな事が確定しますので、
ご多忙でしょうが、確かめていただけるとなお助かります。
を更新しました。HTABOX:Extern部の余計な記述を削除してみました。また、
終了時Beep音がしますが、これは外部JS用非表示HTMLが正常に削除された事
を報告するためのものです。
を更新しました。終了時にDllCanUnloadNowに正しくS_OKを返さない可能性
がある部分を修正しました。
を更新しました。HTABOXは例外を最終的にcatch(...)で受け、総ての例外を
捕捉する設計としていますが、DllMainにこの記述がありませんでした。何
らかの内部例外はすべてダイアログで報告されます。ただ、今回の件は終了
時ということですので、メモリ又はCOMインスタンスの開放不十分、または
重複した開放動作が疑われますから、あまり関係ないかも知れません。
がまったく機能していないことを確認しました。OBJECTタグ処理に関する部分
も全面的に確認することとします。
トエンジンが動作していないだけのようです。ちょっと肝を冷やしました。
「問題が発生したため、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回だけのほうが理にかなっているのですが、これを何らかの形で
吸収しなければなりません。
を更新しました。実験的な試みという位置づけではありますが、OBJECTタグ
によるJScript隠蔽デモをIE8に対応させました。前述のとおりIE7は2回呼び
出してくるのですが、SCRIPTSTATE_STARTEDで開始せずSCRIPTSTATE_CONNECTED
が発生するかを待つと2回目を正しく認識できるようです。
十分に枯れた規格なのですが、普通の人はMSDN見てもvンカンプンだと
思います。かくいう私もハァ？だった部分が多かったのですが、埋め込みOBJECT
として動作させると、なぜそういう設計なのか納得できます。HTML側はエンジン
に対してwindowをグローバルに追加したいからよろしくと報告してきます。
エンジン側は動作中にwindowが必要になったらHTML側サイトへ取りにゆきます。
実にごく自然な流れです。これが、自前でサイトを作った場合、エンジンに
名前だけ教えて、サイト側にIUnknownを待機させるというハァ？なことになる
理由です。
を更新しました。厳しい環境で稀に起動が遅れることへの対策を変更しました。
GUIスレッドウインドウ生成後にWaitForInputIdleを入れるとメッセージの
デッドロックを回避できるのでは？という結論に達しました。
て抱くアプリケーションのイメージは様々な業務に直結するビジネスアプリ
ケーションです。私が救急統計を一つの題材としているように、各人がそれ
ぞれの業務を通じてノウハウを持っているわけですし、エクセルのマクロみ
たいな従属的手段ではなく、堂々EXEで発表、発売できる環境をイメージして
います。はっきり行って日本の業務用ソフトウェアは誰でも書けそうなレベル
のものを、相手が書けない（理解できない）ことをいいことに法外な値段で
売りつけているイメージを持っています。
前職の場合そこで拠出されるお金は「血税」な訳ですから、微力ながらそうい
った「作る側の体質」、「買う側の無知」を正すべく行動しているわけです。
保てる時代はとっくの昔に終わっています。物を削り、加工する作業は寸分
たがわず、工業用ロボットが行えるのです。新しい技術さえそれが「物」で
ある以上、即座に模倣され、より低いコストで競争相手として現れます。
物に変わる商品それが「情報」や「テクニック」や「叡智」です。それらは
まさしくコンピューター上のアプリケーションで表現できる商品です。そし
てその知的財産を保護するために提供媒体でソースが見えない事は絶対条件
となります。
これについては様々な言い訳を用意しているに違いありませんが、用は書
いている人間を使い捨てたいからです。「貴方じゃなくてもその続きは書
ける」という状態を「生産性」と表現しているだけにすぎません。
私は個人のオリジナリティーの延長として完結したアプリケーションを提供
できる環境が生まれなければ、そのことに対する労力を軽減してくれるツー
ルが存在しなければ、本当に汗したものが報われる世界は訪れないとさえ思
います。
置き換えることです。これは、一旦自分が書いたものを完全にバラして、再
構築する大手術になりますが、書いたのは誰でもなく自分ですから不可能な
ことは何も存在しません。
HTABOXAPP.exeは、単に実行された場合、自身と同じディレクトリにあるHTML
系ファイルを列挙して、テキストベースの対話型ダイアログを表示します。
ここで特定のHTMLを選べば実行します。この段階ではEXE側もHTML側もファイル
名には縛られないものとします。同時実行する外部ファイルはHTABOX:Extern
で定義されていますので、HTABOXは実行対象HTMLファイルの指定だけで動作
するというシンプルな状態に回帰します。
生成ファイルは実行HTMLの拡張子をexeに変更したものになり、QuickのEXE生成
がそうであったように、同一ディレクトリにあるHTABOXAPP.exe以外の全ファイ
ルがテーブル形式で一覧され、リソースへ格納するのか、出力先ディレクトリ
は何処かを選択可能とします。
未格納EXEを単にクリックで列挙後実行、HTMLドロップでEXE生成です。
はこのままでは機能しないようです。固定マニフェストによるHTABOXからの
動的中継とした方が自然かも知れませんので、もう一度この辺の機構を見直
したいと思います。
{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のマニフェストに定義し、中継する方向で考えています。
というのは、教科書的にはいかがなものか？なのかも知れませんが、動きを
見る分にはなんの問題も起こらないようです。そこに数個のGUIDを宣言し、
そのうち一つを中継DLLリスト作成用に、もう一つを実際の中継用にしてIE9
のご機嫌を伺ってみることにします。
を更新しました。IE9での動作を確認しました。
考えてみればAPIフックのDLL置き換えというのは本当に置き換えたい対象が
存在する場合の手段ですし、普通にマニフェストで自身EXEへ誘導し、あとは
内部のClassFactoryでいかようにも、というのがごく自然です。
自前のDLLをOBJECTとして埋め込みたい場合は、実行HTMLファイルとの相対パス、
ClassFactoryとして認識させるExport関数名、オプションとして、同一Factory
へCLSIDによる識別が必要な場合のCLSID文字列という事になるだろうと思います。
区切りのマークとしては#を採用したいと考えています。
[hoge.dll#factory#71650000-E8A8-11D2-9652-00C04FC30871]
のような文字列を先頭オブジェクト宣言の内部コメントとして書けばレジストリ
とかマニフェストとかとは無関係に埋め込まれる仕様になります。
要求をマニフェストによって自身へ転送するという手法は実に軽量で、エレガ
ントなんですが、このEXEがサーバーとしてレジストリ登録される場合は自己
参照しているマニフェストを削除しないと無限ループします。（たぶん）
なぜそうなのかを、順序だてて考えたことはありません。
を更新しました。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を受け入れざるを得ないことが不満でしたが、これで
ちょっとすっきりした気分になれました。
気分が落ち込んでいる日だったのですが、そこを乗り越えることができただけ
でも良かったと思うことにします。これから余計な既存コードをバッサリ切る
作業になりますので、プロジェクト全体をコピーして気分を変えなければなり
ません。
改めて書きますが、HTMLアプリケーションの最大のメリットはアプリケーショ
ン実体（実行HTML）をサーバーサイドに置けることです。これはブラウザベー
スでのWEBアプリケーションとは別物の自由度を持っています。起点がアプリ
ケーションですから「何でもあり」になります。何処までがローカルにある
コードで何処までがサーバーサイドなのかということを全く意識させません。
ローカルに空なページを置いて総てサーバー側で動的に生成することも可能
なら、99%ローカルのライブラリを使い、ユーザー認証だけサーバーサイドで
行うというような事がごく自然に可能です。
最小化してもタスクボタンに収納されないなど最外郭のウインドウが妙な動きをします
了解しました。関連部分を精査してみます。
いますね。できるだけ早急に修正版をアップしたいと思います。
を更新しました。タスクに入らないバグを修正しました。GUIスレッド対策
ウインドウの子にすればActiveの委譲がスムースかなぁという書き方にして
いましたが、GUIスレッド対策ウインドウはタスクに加わる条件を満たして
いないため結果的にタスクバーへ入れなかったというストーリーでした。
以前と同じようにWS_EX_TOOLWINDOWのウインドウとして、最外郭とは無関係
な状態としました。
いますので、ちょっと時間をいただくことになります。
を更新しました。コンテキスト統一のために最外郭ウインドウも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:Application/>を認識するようです。ならば、両者を統一
した書き方ができるのではないかと考えています。処理的に早くなる部類
の改良ではないのですが、全方位なHTMLアプリケーション用ウインドウシ
ステムになるだろうと思います。
がありました。結果としてドキュメントインスタンスのアドレスを変化させ
ないまま、内容とサイトを変更することには成功しましたが、途中に待ち構
える関門は「そうされたくない」という意思による「トラップ」のような気
がしました。結局こういったアンドキュメントな部分を探求し始めると、私
のように時間ばかり費やすことになりますから、とてもお勧めできません。
を更新しました。何かが追加された訳ではありませんが、最も心を痛めていた
「拡張ダイアログのデバッガアタッチ」を可能としました。結果として拡張ダ
イアログは親HTAと同じく3重なHWND構造となりました。まだその部分を書い
ていませんが、HTMLダイアログ的表示スタイル指定ではなく、サイズとウイン
ドウスタイルを指定した生成関数を予定しています。このダイアログはヘルプ
等の補助アプリケーションを実行する目的で存在します。単に複数から択一す
るような動作の場合は通常ダイアログの方が扱いやすいと思います。
状態なのではないかと思います。ドキュメントを押しのけてネイティブなHWND
を配置しようとすると全体が不安定になったと記憶しています。以前までの
拡張ダイアログはその結合を強引に引き剥がすことで2重構造のままでしたが、
その弊害としてソースが見えない（デバッグできない）状態となりました。
今回は、HTAと同じように2重構造内部にはタッチせず外郭のウインドウを生
成することでメニュー等のコントロールを共存させています。正直言ってHTA
やHTMLダイアログが消費するメッセージを監視して、その中のどのコンテキス
トで何をやったらうまく行くのかという推理ゲームは終息したと思います。
WIN32的には山ほど課題はあるのですが、それはさて置いといて、全体として
の手法や構造を軽量で、揺ぎ無いものとするために多くの時間を費やしてし
まいました。動かして「あぁちょっと無理があるな」というのは感覚として
判りますし、そういうものを世に出すくらいなら、その先を書くべきだろう
というのが私の小さなプライドでした。
プログラムのすっ飛び方で、「あぁたぶんあの辺が」という感覚は異常に研
ぎ澄まされましたが、それ以外の事では「変人」を通り越して「廃人」状態
です。もし何も成就しなかったとしてもそれは私の器なのだと諦めます。
自分としてはとても美しいモジュールが書けたのですが、何なんでしょう
この虚しさは。
を更新しました。ダイアログ生成機序を見直しました。若干スムースだと思
います。HTML系ウインドウ全般に言えることだと思うのですが、表示されて
いるということと、生成されるということには密接な関係があるようです。
したがって表示しないと生成されなかったり、表示しないと変更ができなか
ったりします。このダイアログも出現時若干白いバックが気になりますが、
これはすばやい生成を重視した結果です。
を更新しました。ダイアログ系の動作を見お直しました。従来モードレスは
親の背後に回りこめる仕様としていましたが、常に親の前面に表示すること
とし、WIN32.CreateDlgWindowExで生成された場合のみ背後に回りこみます。
また総てのダイアログは親の消滅と同時に消滅するものとしました。
を更新しました。昨日の改良でドキュメントのコンテキストが更に安定しまし
たので、ステータスバーのSBARS_SIZEGRIPを復活させてみました。また、ダイ
アログでもその試験ができるようにWS_THICKFRAMEを付加しています。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Win32API質問箱 Build112 (698)
【SICP】計算機プログラムの構造と解釈 Part3 (472)
VisualBasic6.0 対 VisualBasic .NET 2003 (460)
【C++】高速化手法【SSE】 (867)
サウンドプログラミング5 (666)
テストしにくいコードをテストする方法教えて下さい (398)
--log9.info------------------
パークを作ろう !!! (703)
★ トリック決めるときのかけ声 ★ (341)
おまえら今までにどんなケガしましたか？ (540)
ＡＴＢユーザーはその魅力を語ってみれ。 (486)
■服部緑地万博公園長居公園等■ (400)
なんか良い雑誌ないですか？ (224)
ビデオの曲について語ろう！ (472)
新X-sports考えてプロ第１号にならんかね？ (204)
車車車車！！あなたの愛車 in x-sports板 (272)
千葉マリーンズPart1259 (312)
【マリーンズの】岡田幸文応援ｽﾚ3刺殺【エリア66】 (631)
【試しただけ】日ハム斎藤佑樹 97【監督批判】 (860)
【剛裕】中日・堂上兄弟応援スレPart8【直倫】 (226)
背番号について語るスレ 31番 (316)
東京ヤクルトスワローズpart773 (702)
【捕逸王】嶋基宏スレ９【盗塁フリーパス】 (304)
--log55.com------------------
【ピンクソ】ピンクリボン軍【ボングソ】
【潜在的】DER ZIBET7枚目【メンバーとファン】
PIERROT Part1
the Pete Best
【柏原】Gクレフ II【剛也】
【走り続ける】小田和正【レジェンド】
【ヴィーナス】venus peter【ペーター】
【総合】X-JAPANの場合【収益】
