板検索:
HTABOXコア Part3 (982)
まとめビュー
1
hidebou[sage]   投稿日:2012/10/08 15:12:24
HTMLアプリケーションの実行環境として、また、HTMLによるGUIと
他言語との融合アプリケーション環境としてHTABOXコアの開発を
行っています。このスレッドはHTABOXコアへのご意見、ご要望を
気軽に書き込むために存在します。現在3.00のリリースに向けて
作業を行っています。

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


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


3
デフォルトの名無しさん[sage]   投稿日:2012/10/08 15:29:48

















4
デフォルトの名無しさん[sage]   投稿日:2012/10/08 15:58:02

5
デフォルトの名無しさん[sage]   投稿日:2012/10/08 15:58:55
あらー

6
前スレ938_くさや[sage]   投稿日:2012/10/08 18:22:10
マウスオーバー属性が取得できていないのでしょうか?
マウスオーバーしたときにステータスバーの表示が元に戻らないのですが…
コメント1件

7
デフォルトの名無しさん[sage]   投稿日:2012/10/08 18:50:06



















8
hidebou[sage]   投稿日:2012/10/08 19:07:44
>6
当方の環境では体験したことの無い状態のようです。「表示が戻らない」を
もうすこし詳しく教えていただけると助かります。ツールチップが表示され
たままなのか、ボタンが押されたままなのかとかです。

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

9
デフォルトの名無しさん[sage]   投稿日:2012/10/08 19:12:37




















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

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

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

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

14
デフォルトの名無しさん[sage]   投稿日:2012/10/08 20:27:41





























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

16
デフォルトの名無しさん[sage]   投稿日:2012/10/09 18:43:17

















17
hidebou[sage]   投稿日:2012/10/09 18:54:29
<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"/>

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

18
デフォルトの名無しさん[sage]   投稿日:2012/10/09 19:31:44





















19
hidebou[sage]   投稿日:2012/10/10 02:47:12
いままで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>

20
デフォルトの名無しさん[sage]   投稿日:2012/10/10 07:52:36























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

22
デフォルトの名無しさん[sage]   投稿日:2012/10/10 09:14:04





















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

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

24
デフォルトの名無しさん[sage]   投稿日:2012/10/10 22:55:51

























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

26
デフォルトの名無しさん[sage]   投稿日:2012/10/10 23:04:30























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

28
hidebou[sage]   投稿日:2012/10/11 10:12:02
久しぶりに自分が誰なのか忘れるほど寝ていました。何かを実現できない焦
燥感だけで生きているものですから、何かにめどがつくと、その分だけ私を
起こそうとする内分泌系が低下するのかも知れません。

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

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

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

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

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

33
hidebou[sage]   投稿日:2012/10/11 22:00:28
http://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関数が
生成されますので、関数を増やしたり書き換えても動作するはずです。

34
hidebou[sage]   投稿日:2012/10/11 22:09:11
ちなみに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は当然レジストリにも、マニフェストにも存在しない訳ですが
ごく自然に動作するはずです。

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

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

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

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

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

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

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

42
hidebou[sage]   投稿日:2012/10/12 17:41:56
http://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>の中にスクリプトコードを要求するような使い方を予定しているわ
けではありませんのでご了承ください。

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

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

45
デフォルトの名無しさん[sage]   投稿日:2012/10/12 18:11:39
(^q^)
(^q^)

46
hidebou[sage]   投稿日:2012/10/12 22:22:35
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。隠蔽時に使用するサイトが表示するエラーダイアログに、
エラー発生位置コードが文字化けするバグがありましたので修正しました。

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

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

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

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

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

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

50
hidebou[sage]   投稿日:2012/10/13 11:45:50
若い頃はオートバイをいじるのが好きで、全部分解してまた組み立てること
をやっていました。さすがにクランクシャフトはプレス機がないと組めませ
んから分解できませんが。特にCBX550F2Dが好きで2台持っていました。

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

51
hidebou[sage]   投稿日:2012/10/13 11:52:13
ところが、プログラミングの世界では、どんなにバラバラにして組変えようが
何一つ消耗したり、磨耗したりしません。また、クランクシャフトのように
設備がなければ手を出せない部分というのも存在しません。

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

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

53
デフォルトの名無しさん[sage]   投稿日:2012/10/13 16:24:48
2chにスレ立ててしかもsage進行って、物好きか粘着しか来ねぇぞ、オッサン。
いまどきHTAとか、ボンクラ役場でも需要ないやろ。

54
hidebou[sage]   投稿日:2012/10/13 18:08:58
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。単独の起動では発生しないのですが、ビルド直後というよう
な厳しい状況下で稀に起動がストールすることへの対策を加えました。

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

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

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

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

57
デフォルトの名無しさん[sage]   投稿日:2012/10/13 19:56:03
何だかtest.jsが添付されるようになったあたりから正常に終了せずエラー報告が出ます
コメント1件

58
hidebou[sage]   投稿日:2012/10/13 20:30:36
>57
了解しました。非表示でHTMLインスタンスを生成し実行している部分のコード
を洗い直します。OSとIEのバージョン、それからエラーの出方(windowsシステムから?)
を教えていただけると大変助かります。

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

60
hidebou[sage]   投稿日:2012/10/13 21:01:18
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。HTABOX:Extern部の余計な記述を削除してみました。また、
終了時Beep音がしますが、これは外部JS用非表示HTMLが正常に削除された事
を報告するためのものです。

61
hidebou[sage]   投稿日:2012/10/13 21:15:54
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。終了時にDllCanUnloadNowに正しくS_OKを返さない可能性
がある部分を修正しました。

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

63
hidebou[sage]   投稿日:2012/10/13 21:47:20
当方の他の環境XPsp3 + IE8 だと現状で終了時エラーは無いのですがDLL偽装
がまったく機能していないことを確認しました。OBJECTタグ処理に関する部分
も全面的に確認することとします。

64
hidebou[sage]   投稿日:2012/10/13 21:51:15
訂正します。DLL偽装は正常に動作していますが、OBJECTタグの実験スクリプ
トエンジンが動作していないだけのようです。ちょっと肝を冷やしました。

65
57[sage]   投稿日:2012/10/13 22:02:46
環境は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音を確認しました。

66
hidebou[sage]   投稿日:2012/10/13 22:37:42
早速のご報告ありがとうございます。今後ともよろしくご指導ください。

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

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

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

69
hidebou[sage]   投稿日:2012/10/14 02:04:57
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。厳しい環境で稀に起動が遅れることへの対策を変更しました。
GUIスレッドウインドウ生成後にWaitForInputIdleを入れるとメッセージの
デッドロックを回避できるのでは?という結論に達しました。

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

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

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

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

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

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

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

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

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

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

76
デフォルトの名無しさん[sage]   投稿日:2012/10/14 11:37:42
exe(笑)

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

78
hidebou[sage]   投稿日:2012/10/14 12:27:36
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のマニフェストに定義し、中継する方向で考えています。

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

80
hidebou[sage]   投稿日:2012/10/14 16:15:48
http://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]

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

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

82
hidebou[sage]   投稿日:2012/10/14 17:44:37
http://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を受け入れざるを得ないことが不満でしたが、これで
ちょっとすっきりした気分になれました。

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

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

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

85
デフォルトの名無しさん[sage]   投稿日:2012/10/15 18:13:32
例によってXP+IE6及びXP+IE8ですが、
最小化してもタスクボタンに収納されないなど最外郭のウインドウが妙な動きをします
コメント1件

86
hidebou[sage]   投稿日:2012/10/15 20:44:09
>85
了解しました。関連部分を精査してみます。

87
hidebou[sage]   投稿日:2012/10/15 20:47:46
状態を確認しました。ディスクトップのMDI子ウインドウになってしまって
いますね。できるだけ早急に修正版をアップしたいと思います。

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

89
hidebou[sage]   投稿日:2012/10/15 22:17:51
でもActiveの委譲がまずいですね。以前のコードを参考にしながら対策を行
いますので、ちょっと時間をいただくことになります。

90
hidebou[sage]   投稿日:2012/10/15 23:00:09
http://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.....
とすれば目的を達成できるようです。

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

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

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

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

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

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

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

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

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

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

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

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

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


102
デフォルトの名無しさん[sage]   投稿日:2012/10/17 19:00:59
これって

Webプログラミング板
別板リンク(php)

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

103
hidebou[sage]   投稿日:2012/10/17 19:44:13
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。モードレスダイアログを修正しました。デフォルトマージン
を認識し、引数ディスパッチのコンテキストも正常です。

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

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

105
デフォルトの名無しさん[sage]   投稿日:2012/10/17 20:10:16
板違いの件はスルーですか。
コメント1件

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

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

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

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

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

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

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

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

113
hidebou[sage]   投稿日:2012/10/18 15:21:09
ですからウォールトーク(壁と話す)ことをプログラマーなら誰しもやると
思います。このサーバーを借りて私は見苦しいウォールトークをしてきた訳
ですが、私が語りかけているのは壁ではなく、私を気にかけてくださる方々
でもあるという、非常に恵まれた状況だったことを痛感しています。絶対に
私一人ではここまで書けなかったと思います。

114
デフォルトの名無しさん[sage]   投稿日:2012/10/18 16:08:36
水を差すようですがXP+IE6だと>97あたりのバージョンからダイアログが空になります
コメント2件

115
hidebou[sage]   投稿日:2012/10/18 19:07:45
>114
情報ありがとうございます。当方でもIE6環境で動作を確認したいと思います。

116
hidebou[sage]   投稿日:2012/10/18 19:15:39
当方のIE6環境はwindows2000なものですから、即座に状況を確認することが
できませんでした。(HTABOXはXP以上の標準DLLを条件としているため)
継続した課題とは認識しておりますが、IE6についてはマイナーなサポート
になる可能性があることをご了承ください。

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

コメント1件

118
114[sage]   投稿日:2012/10/18 20:12:40
>117を試しましたがそれ以前と変わらず
ダイアログは空(タイトルバーのアイコンはIE)で外郭ウインドウは表示されず、
return = undefinedが返ってきますね

コメント1件

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

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

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

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

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

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

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

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

124
hidebou[sage]   投稿日:2012/10/19 14:38:40
最大のポイントは本来MSHTML側から引かれる引き金をOBJECTから引いてもコ
ンテキストや、タイミング的に問題が生じないのか?でしたが、CSS用ビヘイ
ビアのように他のエレメントへ影響を与えるもので無い限り、任意なタイミ
ングで生成しても、全く問題は生じないようです。

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

125
デフォルトの名無しさん[sage]   投稿日:2012/10/19 18:10:50
現行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タグが利用可能となって無用のコードになるのを期待してます
コメント1件

126
hidebou[sage]   投稿日:2012/10/19 18:22:57
>125
VBSでsingleinstanceが実現できるとは知りませんでした。大変勉強になります。
HTAタグ互換近日中に実装しますが、既存の属性にとらわれない属性のご要望な
どありましたら、気兼ねなく書き込んでください。

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

コメント1件

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

129
hidebou[sage]   投稿日:2012/10/19 19:09:09
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パーサーに怒られる
はずです。

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

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

131
114[sage]   投稿日:2012/10/19 21:28:56
>127を試すとモーダル、モードレス、CreateDlgWindowExともダイアログは表示され、
その中のステータスバーへの文字列表示・引数ディスパッチの実行は成功されるのですが、
どのダイアログでもツールバーとポップアップメニューが生成されず、
モーダルのみreturn = undefinedが返ってくるという状態です
コメント3件

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

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

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

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

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

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

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

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

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

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

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

142
デフォルトの名無しさん[sage]   投稿日:2012/10/20 07:04:56
Bの場合は>131と同様の状況でBeep音は何れも一回のみ、
また>131では書き漏らしていましたがメインのウインドウでタイトルが空なのも変わらずです

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

143
デフォルトの名無しさん[sage]   投稿日:2012/10/20 07:05:50
以下コンソールのメッセージ

モーダル
~WrapSite()
~IHtmlWindow

144
デフォルトの名無しさん[sage]   投稿日:2012/10/20 07:06:32
モードレス及び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
コメント1件

145
hidebou[sage]   投稿日:2012/10/20 09:36:03
>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
これが存在しないということはダイアログ生成スレッド自体を認識していま
せんから、現状では打つ手がありません。

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

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

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

148
hidebou[sage]   投稿日:2012/10/20 10:51:14
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。IE6のモニカ仕様を解析し対応しましたが、これはIE6のメジャ
ーなサポートを意味するものではありません。

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

149
hidebou[sage]   投稿日:2012/10/20 11:31:14
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自体に単一抑制を行うべきなのでしょうか?これを利用されて
いる方のご意見を伺えればそれに沿った仕様にしたいと思います。

150
hidebou[sage]   投稿日:2012/10/20 11:46:17
ウインドウスタイル系については互換ではなく、直接WIN32的なスタイル定数
を指定するものとします。あらゆるカスタマイズの余地を与えるためです。

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

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

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

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

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

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

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

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

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

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

156
hidebou[sage]   投稿日:2012/10/20 18:18:32
現状での設定属性(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>

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

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

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

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

160
hidebou[sage]   投稿日:2012/10/21 00:31:56
http://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>

161
hidebou[sage]   投稿日:2012/10/21 00:40:59
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。
最小化でShowWindow(hwnd, SW_SHOWNORMAL);そうでなければ
SetForegroundWindow(h);という当たり前な動作に修正しました。

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

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

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

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

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

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

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

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

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

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

169
hidebou[sage]   投稿日:2012/10/22 01:52:03
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ダイアログ系<HTABOX:Applicationの設定が可能となりまし
た。ファイルダイアログをキャンセルした場合のエラーを修正しました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

182
hidebou[sage]   投稿日:2012/10/24 12:30:04
MSHTMLプログラミングについて私なりにまとめます。

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

183
hidebou[sage]   投稿日:2012/10/24 12:40:24
軽量なMSHTMLインスタンスとしてHTA系(HTA及びHTMLダイアログ)が挙げられ
ますが、これはMSDNでのMSHTMLにはあたりません。なぜならプログラマーが用
意したサイトではなく、既製品として用意されたものが使われるからです。振
る舞い自体をカスタマイズするのではなく、単に使ってくださいというスタン
スなわけです。

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

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

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

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

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

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

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

191
hidebou[sage]   投稿日:2012/10/25 11:07:41
ちなみにWebBrowserでセキュリティーをコントロールしても擬似HTAは生成
できるのですが、こうなるとあまりに当たり前すぎて何のために5年もの時間
を費やしたのかという自己否定に繋がりますからやりません。(笑い)

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

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

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

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

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

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

196
hidebou[sage]   投稿日:2012/10/25 22:05:02
といって実際に動かしたら、ちょっと不具合がありましたので、一旦引っ込
めます。

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

198
hidebou[sage]   投稿日:2012/10/26 01:06:07
http://kuroda.bglb.jp/htabox/htabox300b.zip
を更新しました。これはbです。ビヘイビアの再描画動作内で更に再描画の
要素となる記述があったために表示が乱れていましたので修正しました。

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

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

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

201
hidebou[sage]   投稿日:2012/10/26 10:30:57
役に立つプログラミングの話というのをたまに折り混ぜないと、クレームが
来そうですので、COMプログラミングの本質についてすこしだけ書かせてくだ
さい。

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

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

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

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

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

204
hidebou[sage]   投稿日:2012/10/26 11:14:47
消滅はRelease呼び出しの累積によってrefがゼロになった時です。

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

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

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

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

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

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

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

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

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

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

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

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

212
hidebou[sage]   投稿日:2012/10/28 12:55:49
http://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);
に変更されています。



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

214
hidebou[sage]   投稿日:2012/10/28 14:31:49
http://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);
}
ステータスバーも再定義できますが、上記コールバックの関係上先頭ページ
で定義して、そのまま使う方が無難だと思います。

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

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

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

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

219
hidebou[sage]   投稿日:2012/10/28 21:51:50
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。各タブページはdialogArgumentsで呼び出し元である先頭
ページのドキュメントを参照できるものとしました。
最終ページから先頭ページのbgColorを変更するデモを追加しました。

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

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

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

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

223
前スレ938_くさや[sage]   投稿日:2012/10/29 20:51:52
最新のhtabox300のタブを使用しないウィンドウで、
メニューをクリックした際、htaのエラーダイアログではない表示で
DateTime = 2012/10/28 21:39:03
File = .\main.cpp
Line = 1581
Description = InvokeEx : onMenuSelect
Error = メンバが見つかりません。
と出た後

224
前スレ938_くさや[sage]   投稿日:2012/10/29 20:55:25
hta標準のエラー表示で
ライン: 88
文字:  2
エラー: 'APPMENU.cells[...]title'は、Nullまたはオブジェクトではありません。
コード: 0
URL:   simple.htm
と出ます。
出来ればご検討下さい。
コメント1件

225
前スレ938_くさや[sage]   投稿日:2012/10/29 21:06:46
書き忘れましたが、OSはXPでIEは8です。

226
hidebou[sage]   投稿日:2012/10/29 21:08:03
>224
いつもありがとうございます。タブ機能の追加によってやや混乱した部分が
あると思われますので、点検を行います。つい新たな機能を追加すると、そ
れを使わない環境でのチェックがおろそかになってしまいます。

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

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

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

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

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

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

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

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

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

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

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

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

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

240
hidebou[sage]   投稿日:2012/11/01 23:36:58
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を行います。したがって
速度的には不利ですが、ソースはスクリプトそのものになります。ですから
私が書く環境においてはスクリプトのネイティブコンパイルは既に実現され
ているという言い方ができるかも知れません。

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

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

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

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

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

244
hidebou[sage]   投稿日:2012/11/02 16:16:21
尚、エレメントが表示領域にあるのかを取得するためにIHTMLPainterOverlay
を実装していますが、MSDNにこれが有効なIEバージョンの記述を発見できませ
んでしたので、IE7より前のバージョンでは機能しないことが予想されます。
コメント1件

245
デフォルトの名無しさん[sage]   投稿日:2012/11/02 18:33:57
>244
IE6でも動作するようです
コメント1件

246
hidebou[sage]   投稿日:2012/11/02 20:07:58
>245
ご報告ありがとうございます。さらに進展させればHTTP上のストリームを中継
して、表示されてない画像等のロードを保留させる事も可能かなぁなんて考え
ています。

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

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

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

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

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

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

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

253
hidebou[sage]   投稿日:2012/11/04 19:37:53
http://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関連ウインドウに
は暗黙のうちに追加されるディスパッチです。したがって軽量ダイアログと
して生成された側にも存在しています。





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

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

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

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

257
hidebou[sage]   投稿日:2012/11/04 23:38:31
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。軽量ダイアログの仕様を変更し、引数が3つ増えました。

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

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

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

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

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

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

262
いつぞやのくさや@実は毎日見てます[sage]   投稿日:2012/11/06 21:40:16
canvasがIEでは対応されていません。
VMLだけではいくらかタグが多くなってしまい、HTML中に収めると重くなる気がします。
できれば、できればですが、そちらもご検討くださるととても嬉しいです。
無理が有るとはわかっていますが…
コメント1件

263
hidebou[sage]   投稿日:2012/11/06 23:31:41
>262
Canvasという単語が初耳なほど偏った見識しかないのですが、HTML上へグラフ
ィック描画する規格のようですね。VMLは確かに一筆書き図形(ポリゴン)で
ちょっと複雑になると頭爆発しそうになりますから、対応が必要でしょうね。

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

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

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

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

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

268
hidebou[sage]   投稿日:2012/11/07 18:32:27
http://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を表示し、2つめを要求すると
シングルインスタンス機能が働きます。HTABOX:Application中の[Single#yes]
を削除すれば複数表示されるはずです。

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

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

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

272
hidebou[sage]   投稿日:2012/11/07 22:09:05
http://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

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

274
hidebou[sage]   投稿日:2012/11/07 23:20:37
こういうのを実行させると、コンピューターって奴は同じことを飽きもせず
やってくれるものだと感心してしまいます。すこしだけアーティスティック
なアルゴリズムです。現状のデモはこの関数になっています。
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();
}
単純な直線の繰り返しから、曲線のようなうねりを感じさせる模様ができます。
皆さんも何か面白い結果出る関数が書けたら教えてください。

275
hidebou[sage]   投稿日:2012/11/08 08:45:24
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。ツールバー切り替え時に一旦HIDEしたものをSHOWする記述が
抜けていましたので修正しました。

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

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

278
hidebou[sage]   投稿日:2012/11/09 22:06:55
ルーズな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);
 }
};

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

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

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

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

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

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

284
hidebou[sage]   投稿日:2012/11/12 00:26:43
拡張ダイアログがウインドウリサイズに追従していませんでした。頼みもし
ていないのにクライアント領域が角丸になるという面白い現象です。多分
コンテストを外しているところがあるんだと思いますので、修正します。

285
hidebou[sage]   投稿日:2012/11/12 04:26:53
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。さすがに疲れました。これは理屈で何が正しいという次元
ではなく、動くのが正しいという世界です。HWNDのコンテキストは、少々外
しても動いてしまうものですから、要注意です。

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

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

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

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

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

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

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

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

291
hidebou[sage]   投稿日:2012/11/14 20:11:25
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。アプリケーションウインドウとタブは実験的にWebBrowser
で生成されたものになっています。拡張ダイアログの生成機序を改善しまし
た。

292
デフォルトの名無しさん[sage]   投稿日:2012/11/14 22:25:57
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
コメント1件

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

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

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

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

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

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

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

299
hidebou[sage]   投稿日:2012/11/16 10:09:21
今日は折角「前938」さんからお題をいただきましたので、グラフィックにつ
いて考えています。まず次の3案のスクリプトを考察します。

//-----------------------------------------------------------------
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);

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

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

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

301
hidebou[sage]   投稿日:2012/11/16 10:28:05
そこで一つのアイディアが生まれます。リリースモードな場合,竜述を
にコンパイルしてしまうというものです。これはそれを解釈するエディ
タとの連携で可能になります。

#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

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

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

304
hidebou[sage]   投稿日:2012/11/16 14:44:21
一番単純そうな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

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

306
hidebou[sage]   投稿日:2012/11/17 00:43:42
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。直接埋め込みでツールバー等のメッセージが処理されていな
い部分を修正しました。

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

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

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

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

311
hidebou[sage]   投稿日:2012/11/19 20:36:38
内容エレメントは常にlastChildとして認識しています。したがって単一な親
にまとめる形で複数のコントロールを配置してください。また、表示サイズ
の決定のために内容エレメントにもCSS定義としてのwidth、heightを明示して
ください。

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

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

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

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

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

316
デフォルトの名無しさん[sage]   投稿日:2012/11/20 05:05:42
リボン風メニューだけでなく、本物のリボンも使用可能だと嬉しいなぁ、というのは高望みしすぎかな…
ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9C%E3%83%B3_%28GUI%29
コメント1件

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

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

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

320
前スレ938[sage]   投稿日:2012/11/20 21:05:39
>308
難しいのですか…
別に今すぐに使わないといけないわけでもありませんし、
今後の物として考えていただければ嬉しいです。
コメント1件

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

322
hidebou[sage]   投稿日:2012/11/20 23:26:50
いずれにせよ、「これが決定的な仕様です」を自信を持って提示できるほど
情報収集が進んでいない事が何よりの理由ですから、もうすこしお時間をい
ただいて勉強させていただきます。

323
hidebou[sage]   投稿日:2012/11/20 23:57:30
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。デザインメニューの描画を単純なBitBltとすることで描画
を安定させました。また、DrawLineのZオーダーを一つ下げた状態でのデモ
にしました。

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

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

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

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

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

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

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

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

331
前スレ938[sage]   投稿日:2012/11/22 05:45:08
マウスの動きにあわせてDESIGN:Lineを使い、マウスの跡を作ろうとしたら、
線が所々出たり消えたりして、不安定です。
onclickで明確にポイントを指定しても消えるようです。
コメント1件

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

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

333
hidebou[sage]   投稿日:2012/11/22 12:02:37
下記の単純な関数で実験しましたが、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;
}

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

335
hidebou[sage]   投稿日:2012/11/22 19:59:21
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeについて細かな修正を加えました。中にネイテ
ィブな要素を入れて安定動作を確認してから仕様を公開したいと考えていま
す。

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

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

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

339
前938[sage]   投稿日:2012/11/24 08:06:56
>338
そうだったのですか。
個人的には、速い方で作り上げる事が出来る方がいいです。
コメント1件

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

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

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

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

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

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

344
hidebou[sage]   投稿日:2012/11/25 18:17:45
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。上記問題を修正しました。

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

346
hidebou[sage]   投稿日:2012/11/25 23:57:42
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。334の修正により、全体がストールする可能性が生まれてい
ましたので、修正しました。

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

347
hidebou[sage]   投稿日:2012/11/26 00:06:57
私はこのDESIGN系エレメントをHTMLアプリケーション本体のコントロールと
しては捕らえていません。これは、複数のアプリケーション(ネイティブを
含む)を選択して実行する親コントロールとして存在するのです。

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

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

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

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

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

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

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

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

354
hidebou[sage]   投稿日:2012/11/27 00:15:38
再考してみると、拡張ダイアログについてはIE10の動作の方が正しく、私の
書き方が甘かったというのが真相なようです。ツールバーやタブを使ったダ
イアログが必要かどうかは別にして、復活させてみようと思います。

355
hidebou[sage]   投稿日:2012/11/27 00:36:39
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。
UTIL.showModalDialogExとUTIL.showModelessDialogExが復活しました。
多機能な補助ウインドウとして動作しますが、タスクバーにカウントされ
ない点がCreateAppWindowと異なります。

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

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

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

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

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

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

362
hidebou[sage]   投稿日:2012/11/27 23:09:58
このDESIGN:Nodeはとりあえず任意なURLを埋め込みモードレスダイアログと
して実行する仕様として公開しようと考えています。

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

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

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

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

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

<DESIGN:Node id="NODE1" text="ノード1" style="position:absolute;left:100;top:100"><div style="padding:16">....</div></DESIGN:Node>
<DESIGN:Node id="NODE2" text="ノード2" 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"でステータス
バーが表示されます。文字の書き込み方法はシンプルダイアログと同じです。

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

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

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

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

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

371
hidebou[sage]   投稿日:2012/11/30 01:50:06
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Node系の修正を行いました。終了時のアクティブ
委譲問題、Nodeを開いたまま終了した時の問題への対応を行いました。

372
hidebou[sage]   投稿日:2012/11/30 04:38:25
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Nodeを50%透過させてみました。アクティブな内部
HWNDは透過しない状態にしていますが、この方がむしろ自然な感じがします。

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

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

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

376
hidebou[sage]   投稿日:2012/11/30 19:48:51
すべてはCSSとしての透過度に触ったことによるものと思われます。それより
若干速度的には劣りますが、GDI+的手法の透過では問題が生じないようです
から、手法そのものを切り替えることで解決できそうです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

391
hidebou[sage]   投稿日:2012/12/07 02:01:27
素のWSH環境でこれをやろうと思うと3つの問題があります。
1.WScript.ShellのExecはSW_HIDEなウインドウ生成ができない。
2.TextStreamのWrite系はClose以外にストリームをフラッシュするすべが無い。
3.TextStreamのRead系はパイプからの取得データが空でも制御を返さない。

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

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

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

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

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

396
hidebou[sage]   投稿日:2012/12/08 01:57:54
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。DESIGN:Cmdでipconfig等のコマンドを実行した場合、出力
された文字列の改行コードを過剰に評価する事への修正を行いました。

397
hidebou[sage]   投稿日:2012/12/08 02:38:52
パフォーマンスモニタの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>

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

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

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

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

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

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

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

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

406
hidebou[sage]   投稿日:2012/12/09 16:54:39
http://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に答えるディスパッチ
でテーブルをエミュレートします。ネイティブページが混在しなければ従来の
記述もエラーとはなりませんが、混乱を避ける意味で統一した扱いとします。

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

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

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

410
hidebou[sage]   投稿日:2012/12/10 19:00:16
現状ではHTABOXのタブにDESIGN:NodeにHTML表示要素があるとストールします
ので、HTML生成パターンを変化させながらタブ内に表示させるコードを模索
しています。この作業が終われば、単一なHTML(タブは複数ですが)で全機
能をお見せできることになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

423
hidebou[sage]   投稿日:2012/12/13 19:29:47
非力な別環境だとDLLの注入が遅れてしまう事を確認しました。どうしても
別プロセスへの介入はタイミング問題が生じるのでもう一工夫必要なようで
す。

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

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

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

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

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

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

430
hidebou[sage]   投稿日:2012/12/15 14:03:52
http://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を実
行すれば正常動作となります。

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

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

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

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

435
hidebou[sage]   投稿日:2012/12/16 14:21:14
http://kuroda.bglb.jp/htabox/wsh.zip
を更新しました。PC起動後、初回のWshEx.exe起動でフックが失敗する事に
対する修正を行いました。またWindows7での正常動作も確認しました。

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

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

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

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

439
hidebou[sage]   投稿日:2012/12/17 22:12:56
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>

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

441
hidebou[sage]   投稿日:2012/12/18 01:05:41
<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リリース時は公開されない機能となるでしょう。

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

443
hidebou[sage]   投稿日:2012/12/18 21:54:02
wsf状態でのJScriptとVBScript連携を模索しましたが、HTML中とは異なり
相互呼び出しには問題が存在し、それを乗り越えるための手立てを打つく
らいなら連携自体を行わないとした方がわかりやすいようです。

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

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

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

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

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

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

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

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

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

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

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

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

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

452
hidebou[sage]   投稿日:2012/12/21 21:09:12
http://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を
実行することになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

470
hidebou[sage]   投稿日:2012/12/29 17:54:57
HTABOXで実行するHTML中に下記ビヘイビア表記でWSFが実行されます。

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

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

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

471
hidebou[sage]   投稿日:2012/12/30 03:49:59
http://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ScriptEx.exe環境でのWScript.CreateObjectを拡張し、
レジストリ登録の有無に関わらずディスパッチを取得可能としました。
添付wsfは下記のとおりです。

<job id="main">
 <script language="JScript">
  alert("非登録COM取得");
 </script>
 <script language="VBScript">
  Set Shell = WScript.CreateObject("c:\\windows\\system32\\wshom.ocx", "{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}")
  MsgBox TypeName(Shell)
  Shell.Popup WScript.ScriptFullName
 </script>
</job>

正規な呼び出しが成功しなかった場合この機能は発動します。第1引数はDLL
パス(:が存在しなければwsfとの相対)第2引数はCLSIDです。上記の例では
低水準にWScript.Shellをインスタンス化しています。HTABOX、ScriptExの
両環境下においてレジストリ登録、マニフェストの有無とは無関係に自由な
COM運用が可能となります。これで今まで不可能だった事がいろいろ実現でき
るのではないでしょうか。

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

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

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

475
hidebou[sage]   投稿日:2012/12/31 08:37:54
個人的に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 ; :

476
hidebou[sage]   投稿日:2012/12/31 08:40:54
上記正規表現置き換えが実施される場合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;

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

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

479
デフォルトの名無しさん[sage]   投稿日:2012/12/31 20:10:59
何かこの辺↓を思い出しました

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

ここでのLOGOの実装例や

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

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

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

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

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

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

482
hidebou[sage]   投稿日:2013/01/01 04:19:48
http://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;

483
hidebou[sage]   投稿日:2013/01/01 12:32:12
http://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));

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

484
hidebou[sage]   投稿日:2013/01/01 15:24:39
http://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
'--------------------------------------------------------------------------------------------------

485
hidebou[sage]   投稿日:2013/01/01 22:40:47
http://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);
}

486
hidebou[sage]   投稿日:2013/01/02 22:39:28
http://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);
  }

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

488
hidebou[sage]   投稿日:2013/01/02 23:04:59
あぁ、while(ReadFile(h, buf, 0x800, &r, NULL))
ですね、エラーではありませんが、試行錯誤していた頃の&が残ってしまい
ました。バイナリも再コンパイルしてアップします。

489
hidebou[sage]   投稿日:2013/01/03 02:15:44
http://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);
    }      
  }

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

491
hidebou[sage]   投稿日:2013/01/03 11:47:14
http://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。windows7上での動作確認済みバイナリです。

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

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

492
hidebou[sage]   投稿日:2013/01/03 12:44:23
http://kuroda.bglb.jp/htabox/htabox300.zip
を更新しました。改めてIE10環境での全機能動作を確認しました。
HTABOXの<HTABOX:Wsf src="hoge.wsf"/>で参照されるWSFでも拡張されたVBS
を利用可能です。

493
hidebou[sage]   投稿日:2013/01/03 17:19:30
http://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の前に実験しましたが、
こちらも結局はシステムが決定してしまうようでサスペンド以外は目立った
変化が無いように見えました。

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

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

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

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

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

  //非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();
  }

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

500
hidebou[sage]   投稿日:2013/01/07 00:18:40
http://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。ScriptEx.exeを

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

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

501
hidebou[sage]   投稿日:2013/01/07 17:53:38
http://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。下記プラグマが追加されました。VBScriptを対象に行われた
プリプロセス結果を先頭エディタ上で確認することができます。

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

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

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

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

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

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

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

506
hidebou[sage]   投稿日:2013/01/10 00:44:02
http://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>

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

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

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

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

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

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

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

512
hidebou[sage]   投稿日:2013/01/14 21:25:10
http://kuroda.bglb.jp/htabox/scriptex.zip
を更新しました。このスレッドに関わってくださった皆さんへ感謝の意味を
こめて、MHTの画像HTML化機能を利用可能な状態のScriptExを一時公開します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

527
hidebou[sage]   投稿日:2013/01/28 14:18:38
test

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

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

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

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

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

532
hidebou[sage]   投稿日:2013/01/31 00:59:06
test

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

547
hidebou[sage]   投稿日:2013/02/14 07:35:23
どんな雰囲気になるんだろうと、興味がある方もいらっしゃるでしょうから、
分割して投稿してみます。

/*******************************************************************************
拡張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);

548
hidebou[sage]   投稿日:2013/02/14 07:37:28
//報告サイトインターフェース
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;
};

549
hidebou[sage]   投稿日:2013/02/14 07:41:24
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(){}
};

550
hidebou[sage]   投稿日:2013/02/14 08:29:20
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);
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

567
hidebou[sage]   投稿日:2013/02/22 02:26:59
そういう目的で作成されているわけですから当然ですが、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, "@");

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

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

570
hidebou[sage]   投稿日:2013/02/23 00:31:18
http://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);

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

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

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

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

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

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

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

576
hidebou[sage]   投稿日:2013/02/27 23:35:49
考え方はこうです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

584
hidebou[sage]   投稿日:2013/03/06 04:01:35
もし非MSHTMLな環境で埋め込みオブジェクトを管理するコンテナが書けるか
をシュミレートしてみると、それはMSHTMLのようなボリュームになってしま
うだろうと予測します。

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

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

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

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

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

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

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

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

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

590
hidebou[sage]   投稿日:2013/03/10 07:46:00
C++で作成したモジュールを公開したいが、ソースごと渡しては意味が無いと
いう場合のDLL活用について私なりにまとめます。ここでは提供側、利用側と
もC++(VC++)であるという想定で進行します。

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

2 クラス定義

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

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

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

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

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

3 IDL手法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

607
hidebou[sage]   投稿日:2013/03/22 19:29:32
DLLは非登録で参照しますからマニフェストが必要なので追加しました。
何らかのリソーススクリプトを追加し最終行に
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "manifest.xml"
を追加する事を想定しています。

1本か2本発表するだけなら、ウインドウクラス名がHTAなのでびっくりという
だけの一発芸なのですが、10本20本を一括管理可能なシステムだと言えば納得
していただけるのではないでしょうか。手作業では不可能なことを可能にする
のがソフトウェアですから、アプリケーション作成段階でその威力を最大限に
発揮しようという発想がHTMLアプリケーションの有効活用です。

608
hidebou[sage]   投稿日:2013/03/22 20:07:20
C++用ライブラリの発想は極めて単純です。HTAまたはDLGを生成する関数に
生成されたIOleObject、IOleClientSite、FraHwnd、DocHwndの報告を受信
するクラスを渡します。それらがデフォルトな扱いを受ける前に報告は行
われますので、自由にできるということです。で、まったくゼロからホス
トしなさいというのも煩雑ですから、報告先が興味を持たない場合は既定
な動作、若しくは既定を少し拡張した動作が自動的に行われるというルール
です。

HTABOXがいかに進歩しても「プロへお勧めできるものになるのか?」疑問で
したが、これならプロに対しても自信を持ってお勧めできる環境になると考
えています。

609
hidebou[sage]   投稿日:2013/03/22 20:34:59
今のところ興味の対象は自前なHTMLインスタンスなんですが、WSHハックで
使用したDLLインジェクションと、今回のオブジェクトラップを組み合わせ
ると、既存IEのドキュメントの左半分には常にHTML構造がツリー表示されて
いてクリックしたところへジャンプするとか、アフェリ画像は原則的にブロ
ックして、ツリー上でクリックされた画像のみを表示するとかということを、
プラグインのような従属的な立場ではなく実行主体として実現できます。
IE+αをまさしくα分のコードで実現しながら「私が書きました」という実
に横着な展開が可能だと思います。

610
hidebou[sage]   投稿日:2013/03/24 11:06:57
HTABOX本体に今まで蓄積したノウハウを適用して、より簡潔な構造とする作
業を行っています。HTABOXの場合は「スクリプトからの操作を簡潔に」とい
う方向性が明確になりましたので、それに沿った改良になります。単一CPP
最強という発想で1Mbを超えるソースになっていましたが、やはり可読性が
低下するのでDLLでのカプセル化を導入したいという思惑もあります。

611
hidebou[sage]   投稿日:2013/03/26 23:22:00
HTML生成への低水準関与と基本的なOBJECTを提供するHtmlEx.dllのみを生成
するプロジェクトをルートに置き、各種EXE生成プロジェクトをその子とし、
EXE側ソリューションにHtmlEx.dllのプロジェクトを含めるという手法が最も
各ソリューションの独立性を維持しながら、各EXEの要求をHtmlEx.dllへ蓄積
しやすい状態と判断して全プロジェクトの再配置を行っています。

一旦HTML操作の大統一は無理と判断したのですが、上記手法で性質の違う両
EXEをビルドしながらDLLの内容を詰めてゆくことで完成することができました。
私とって最大の敵は私自身で、その後に手をつけたくないと感じるほど入り組
んだ構造を作ってしまうことですから、機能をCOMDLL化して外部とのインター
フェースを明確にするという作業はコメントではなくソース自体に説明させる
という理想への近道だと実感します。

612
hidebou[sage]   投稿日:2013/03/27 20:14:37
HTMLウインドウの低水準操作をIDL化することで共有可能なライブラリとして
パッケージできましたので、もうひとつの柱であるリッチエディタをIDL化し
ています。

ただしCOCLASSは継承した拡張ができません。エディタの場合A,B,C,Dくらいの
段階を踏んでメソッドを増やし必要に応じた段階のインスタンスを生成したい
のですが、IDLは型と実装を厳格に管理する事が目的ですからしかたが無いこ
となのでしょうが。

613
hidebou[sage]   投稿日:2013/03/27 20:31:32
そこで通常のC++継承の流れとIDLインターフェース継承を並列な構造とし、
IDL側は常にIUnknownを基底として、拡張されたメソッドのみを定義、型
チェック目的でC++継承時に基底クラスとIDLインターフェースを継承、
COCLASSの継承元をIDLインターフェースではなくC++クラスとすることで結果
的にCOCLASSには拡張されたメソッドのみを定義すれば足りる状態とできる
ようです。

この場合高次な派生インスタンスから低次なメソッドを呼ぶ場合はダウンキャ
ストが必要です。COCLASS自体は低次なメソッドを知らないわけですからC++
実装クラスへQueryを転送し、親側なら親へ転送、現在拡張中のインターフェー
スならstatic_castでVTBL生成インスタンスを返す事がポイントとなります。

614
hidebou[sage]   投稿日:2013/03/27 20:40:43
上記ロジックで実質的にCOCLASSの多段継承が実現できるわけで、引数型が制
限される見返りに自動的なマーシャリングが得られるとすれば、ありとあらゆ
るC++クラスを通常の継承構造のままCOMDLLとして提供できることになります。

実行時コンテキストの差異を気にすることなく、何でも提供できると同時に
手の内を明かす必要が無いとすれば、大変素敵なことだと思います。

615
hidebou[sage]   投稿日:2013/03/28 22:15:54
以前はMSHTMLに対してあれとこれができるからそれを組み合わせれば...的発想
だったのですが、いつのまにか総て可能な中から必要なものを選択する状態へ
進歩しました。統合されたHtmlEx.dllは200K強ですが、僅かこれだけのモジュー
ルでMSHTML関連の膨大なモジュールを自在に制御することが可能です。

ただ、その膨大なモジュールを書いている人間の立場になれば公開もしていない
ポイントを突いて自由にコントロールされる事を好ましくは思わないでしょう。
ですから、将来にわたってもこの内容を公開することは無いと考えます。内容
を公開すれば、たとえOLEの基本的な構造を外したとしても、回避策がとられる
可能性を生んでしまいます。非公開ならWindowsある限り動くものをみすみす自
滅に追い込む必要はないのです。

616
hidebou[sage]   投稿日:2013/03/28 22:38:46
もし私に十分に口の堅い後継者がいればこの技術は受け継がれ、HTML系のウイン
ドウはMS側の公式ドキュメントに関わらず、あらゆる操作が可能な状態が維持
されるでしょう。そうでない場合、私の生涯が終ればそのような状態も終わり
を告げることになるでしょう。私だからこそ、なし得た事がこの世にひとつく
らいあってもいいのではないかと思います。

617
hidebou[sage]   投稿日:2013/03/28 23:04:40
MSHTML由来のすべてのHTMLウインドウをプログラマーに解き放ち、あれができ
ないこれができないという事柄を無い状態にするというのが第一の目的ですし
綺麗にCOMDLLへパッケージ化できたことで、多言語へそれを提供することも可
能となりました。このパッケージにはネイティブダイアログ中にドキュメント
のみを埋め込んだ動的軽量ダイアログが含まれます。

次にHTMLと親和性の高いスクリプトでアルゴリズムまで記述した場合の対クラ
ック対策ですが、これはC++コードにおける擬似JScript手法が回答となります。
もし、スクリプトによるアクティブデバッグに魅力を感じるなら拡張VBScript
でのコーディングが安全ですし、カジュアルクラック対策としての独自エンコ
ードも選択肢の一つとして残そうと考えています。

618
hidebou[sage]   投稿日:2013/03/29 18:31:00
「あなたの書くコードは他の従業員が理解しにくい」という理由で解雇され
た元プログラマーのサイトを見ました。日本という国がすべてそうだと思い
ませんが、「誰でも書けそうなことを誰でもわかるように書く」ことが書け
ない上司にとっては都合のよいプログラマーなんでしょうし、私は腐っても
そんな身分にはなりたくないと歯を食いしばって勉強してきたと思います。

繰り返しになりますが、アプリケーションを作成する過程自体をアプリケー
ションで効率化し、個人で完結した製品を複数管理可能にする。そういった
システムが無ければ、多くの有能なプログラマーの叡智や苦労はかけもしな

619
hidebou[sage]   投稿日:2013/03/29 18:38:05
い連中の食い物にされ続けるでしょう。私はこの国に根付いている「出る杭は」
的風土にはとても疑問を感じますし、誰かがそれを打破して見せなければ、こ
の国には将来が無いとさえ思います。

620
hidebou[sage]   投稿日:2013/04/04 23:44:26
完全にスレ違いな事をご容赦いただければ、とうに50才を越えた私は、私の
半分くらいしか歳をとっていない若者達には十分に謝罪しなければならない
理由があると考えています。この世界を、この日本を良しとして黙認してき
た愚者としての責任です。

なぜ戦争が勃発し、それが誰に利益をもたらし、誰の血が流れるのか、そして
それが一握りの人間の私利私欲を発端とすることは明白であるにも関わらず、
少なくとも自身の立場が受益側にあればいかなる暴挙も犯罪とはならない世界。
縁故やコネクションで形成され、自身の儲けにつながらなければいいかなる才
能も黙殺しようとするこの国。

心から謝罪しなければなりません。こんなものを見せて夢を抱けというほうが
無理です。ただ、私は感じています。従来の資本ありきを覆す力がソフトウェア
にはあり、それがこの社会を根底から変革する起爆剤になりえることを。

621
hidebou[sage]   投稿日:2013/04/07 09:36:03
開発環境をWindows7+IE10に移行する作業をしています。WindowsXPをターゲッ
トに含めるためにはWindows7上でVS2003を実行する必要があるようです。
VS2005以降はVista以降の環境で動作させた場合にXPで実行可能なEXEを出力し
ないように見えます。サイズが小さいことから、XPまではスタティックにリン
クされるべきモジュールがVista以降では動的なロードになっているのでは
ないでしょうか。

622
hidebou[sage]   投稿日:2013/04/07 09:49:39
OSの提供元が民間企業ですから利益を追求するのはいたしかたの無いことで
しょうが、過去のOSやコンパイラを持っていなければXP用のネイティブEXEは
生成できず、どうしても必要ならMSDNへ会費を払うしかないというのは、プロ
グラミング離れの要因になっていると思います。

623
デフォルトの名無しさん[sage]   投稿日:2013/04/08 03:43:37
VS2012ならプラットフォーム ツールセットをv110_xpとかWindows7.1SDKにすればええんちゃう

624
hidebou[sage]   投稿日:2013/04/10 19:53:22
私の手元には無いのですが、新しいVSはプラットホーム指定が可能という
情報は確かに目にしています。選べるということは動作を保障するという
ことでしょうから、開発者サイドに立った前進だとは評価しています。

625
hidebou[sage]   投稿日:2013/04/10 20:52:58
http://kuroda.bglb.jp/htabox/image.zipを更新しました。
画像サイズ変更、表示倍率に対応しました。現バイナリにはなんら機能制限
を設けておりません。また、ヘルプは整備されていませんが見てのとおりに
作ってありますからそこそこ遊べると思います。

アプリケーションのイメージは下記のとおりです。
http://kuroda.bglb.jp/htabox/converter.png
尚、本アプリケーションにかかる全ソースコードを息子に譲る予定です。
たま、サイズ可変ウインドウのC++的設計から開始し、本アプリケーション
を完成させるまでの過程を「画像処理アプリケーション入門」的なサイト
に仕上げて公開したいと考えています。

626
hidebou[sage]   投稿日:2013/04/12 08:57:08
image.zipを更新しました。マイナーなバグ対策を行いました。左パネルでの
1,4,8bitによるBMPファイル生成で誤差拡散定数を3択可能にしました。

先頭の定数はごく一般的数値ですが、それ以外は素数の組み合わせによる
オリジナルな定数です。点描(1bit)でその違いを観察すると興味深いもの
があります。

627
hidebou[sage]   投稿日:2013/04/23 20:28:28
ちょっと本筋からは外れますが、ナイト巡回問題の解法についてのドキュメン
トと巡回の経緯をグラフィカルに表示するアプリケーションを公開しました。

http://webbot.web.fc2.com/

数行のJScript、又はVBScriptで各パラメータを変えた巡回シュミレーション
が可能ですから、数学好きな方は楽しめるかも知れません。
リッチエディットを拡張されたコンソールとして使い、ユーザースクリプトの
パースを独自エンジンで行う。ヘルプはMSHTMLの独自制御で行い、ヘルプ自体
はワードの2段組イメージをOLE的に画像化して生成する。僅かずつですが、
今まで蓄積してきたことの総決算的意味合いもこめられています。

628
hidebou[sage]   投稿日:2013/04/24 10:43:33
いままでブログと言われるCGIがどんな動きをするのか勉強する気もなかった
のですが、情報を効率的に拡散させるためには必要だろうという観点から調査
してみました。非常に興味深かったのはHTMLメールで画像のアップロードと
それを表示するHTMLが形成されることです。HTMLメールはMHTと同じ形式で、
画像データをエンコードした文字列で表現しますからなるほど可能な訳です。

629
hidebou[sage]   投稿日:2013/04/24 11:00:02
ということは、WEB上の情報収集と自身ブログへの情報保存をまったくロボッ
ト化できることになります。時系列で変化する情報を1時間毎に収集し、1日
に24回送信を行う。何月何日何時の情報を見たいという要求の処理は、もと
もとブログというものがそういうデザインなので考える必要が無い。また、
画像等を主たる情報とする場合、ブログサーバー上の容量制限が問題となる
が、その場合は自前サーバー、若しくは他サーバーからのGETに答えうる別
サーバー上に画像を置き、そのURLを参照するHTMLならいいという展開です。

630
hidebou[sage]   投稿日:2013/04/24 11:14:44
工業分野でのロボットは目で見ればそれが生身の人間では無いことが明らか
ですが、WEB上ではその操作が人間によって行われているのかロボットによ
って行われているのかを知る方法はありません。自動ブログ生成を考えた場
合課題となるのは収集ターゲットページ上のどの情報を収集するのかを視覚
的に表現しうるGUIのみ(マウスでポイントされたエレメントを明確にする)
ですからIE動作にインジェクションを行うまでもなくWebBrowserをOLE的に
カスタマイズすることで可能だろうと考えます。HTMLメールはCDOによりごく
当たり前に作成できるはずです。

631
hidebou[sage]   投稿日:2013/04/24 11:37:07
話は飛躍するのですが、アルゴリズムで表現できる作業というのはすべて
ロボットが行うようになりますし、人間の側というのはそのアルゴリズム
を考えることに専念するようになるはずです。ですからおおかたのWEBデザ
イナーとオペレータでしかないプログラマーは働く場所を失う運命にある
のではないかと思います。

632
hidebou[sage]   投稿日:2013/04/26 02:03:57
ターゲットURLのストリームを偽装して、独自オブジェクトが宣言されている
かのうように見せかけ、HTML側コンテキストに侵入しての操作が可能なのでは
ないかとチャレンジしていますが、iframeがらみの複雑な構造のページで成功
しません。IInternetProtocol系で探りを入れていますが、もっと低水準なス
トリームレベルでの介入が正解なのかも知れません。これが成功すると、
サーバー側に通常コネクションのまま、人間業ではないレスポンスを返すこと
ができますから、何らかの対策が施されているという可能性もあります。

633
hidebou[sage]   投稿日:2013/04/28 00:31:49
某気象情報サイトをターゲットに、サーバーレスポンスへOBJECTタグを挿入
することに成功しました。ディスパッチならWebBrpwserがインタラクティブ
を報告した時点で追加しようが、動作させようが自在に可能ですが、ページ
構造が複雑化するとディスパッチでは解決できない問題が生じるようですから
OBJECTタグの挿入が唯一の方法だと現時点では判断しています。

634
hidebou[sage]   投稿日:2013/04/28 00:47:06
モニカの基底にあるストリームを書き換えてしまうというのが、今回のキー
ポイントですが、これを悪い方向に使うと「ブラウザはレスポンスしたHTML
を素直に解釈している」というサーバー側の大前提が覆る訳ですから、混乱
の要因になりかねません。現時点ではブラウザ上にページスクロールと同期
する半透明ウインドウを置き、当該ウインドウ座標のDCイメージを取得する
ロボットを作れればと考えています。もちろんEXE全体はスクリプト等で制御
でき、定時に同じ動作を自動的に行うことになります。

635
hidebou[sage]   投稿日:2013/04/28 11:01:17
考えてみると今回成功したモニカへの介入は、ブラウジングの世界に革命を起
こす可能性を秘めています。なぜなら、サーバーとの間で行われたあらゆるデ
ータ通信をローカルに保存して再現することができるからです。たとえそれが
ストリーミングのようなものであってもです。

636
hidebou[sage]   投稿日:2013/04/28 11:08:33
また、従来ブラウザ上のマクロ動作というと「表示されていること」を前提
とした手法が主になっていますが、私のボットは定期動作時に非表示である
ことを前提として設計されています。場合によってはEXEではなくシステム
として常駐しWEB上でのロボット動作を極めて高速に処理するという構想を
持っています。

637
hidebou[sage]   投稿日:2013/04/29 12:43:27
非表示なまま、事前に定義された矩形の画像を自動取得することには成功し
ました。これはOleDrawで実現されているため、画像としての保存が抑制さ
れていても、表示されているのであれば保存を拒むことは不可能です。

もうひとつの課題である「全ストリームのローカライズ」が可能なのかを
検証したいと思います。サーバーとの交信がすべてモニカ経由であるとすれ
ば、ひとつのセッションで発生した情報をすべてファイルへ保存し、その
順序や取得元URLをXML管理して、再度同じページに対して要求が発生した場
合に偽装して再現することが可能だと考えています。

638
hidebou[sage]   投稿日:2013/04/29 17:38:21
基底のHTTP又はHTTPS動作へもぐりこめれば特定のMIMEに限定されない汎用な
情報操作が可能だと予測しますが、私が思い描いているイメージと実際との
間にかなりの食い違いがあるようです。例えばvideo/x-flvのようにMIMEが
具体的ならキャッシュはできますが、周辺データに取りこぼしが生じては完全
な偽装を単純な機構で実現するという目的から外れますので継続した課題
になりそうな気配です。

スナップショットが撮れるブラウザについては周辺機能を整備して、任意な
URLで動作する状態をお見せできると思います。

639
hidebou[sage]   投稿日:2013/04/30 22:37:48
http://kuroda.bglb.jp/vector/webbot.zipを公開します。
シンプルなWebBrowserコントロールにネイティブなレイヤーウインドウを重
ね、メニュー又はレイヤー上のsボタンで画像を保存できます。初期URLは
exeと同じ位置にurl.txtを置けば設定可能です。存在しない場合はデフォルト
ページが表示されます。動画を見ながらスナップショットを取るような用途
に大変適していると思います。

640
hidebou[sage]   投稿日:2013/04/30 22:45:30
他人様が書いたHTMLページが相手なものですから、クッキーがらみのスクリプト
が動作するページではスクリプトエラーと表示される場合を確認していますが、
表示されたページのピクセル情報取得が目的ですから、エラーダイアログを
消していただければ、本アプリケーションは問題なく動作します。
開発はIE10環境で行いIE9,IE8での動作を確認しています。本来これはロボット
として定時に動作する目的で作成されていますが、手動で操作するエディション
はフリーソフトとする予定です。

641
hidebou[sage]   投稿日:2013/05/01 00:35:56
IE7での動作も確認しました。スクロール情報と、要求矩形の精度を向上させ
るために独自OBJECTを追加しているのですが、PCのパフォーマンスやページ
の重さでたまにストールしますので、更にチューニングを煮詰める必要があ
るようです。

642
hidebou[sage]   投稿日:2013/05/03 22:29:37
自分が書いたHTMLを解釈するのがHTMLアプリケーション(HTA)手法で、他人
様が書いたHTMLを解釈するのがWebBrowserだと思ってきたのですが、WebBrowser
はインストールされたIEの切片ではなく別物なのではないかと思えてきました。

つまりWebBrowserをサーバー側に本当のIEだと思わせるのは不可能では無いに
しろ大変な労力がかかる気がします。そんな苦労と、IEバージョンが上昇する
度のメンテナンスを考えると、本物のIEを起動して憑依した方が得策という
結論に達しました。プロセスへの侵入は定石どおり成功しましたが、ドキュ
メントの生成機序がいまいち掴めません。過去に実績がある乗っ取り手法は
今のところカスリもしません。それだけ困難だということは、それを乗り越
えられる人間も少ないということですから、腰をすえて取り組みたいと思い
ます。

643
hidebou[sage]   投稿日:2013/05/04 12:35:43
IEのタブは各自別プロセスなのですが、親である起動実体が子プロセスを
起動する手段が通常のCreateProcessやCreateProcessAsUserではないように
見えるというのが問題の本質なようです。ただ、ロボット動作に必要なのは
生成に関与することではなく、通常動作させておいて適切な時期に制御を奪
うことですから、発想を変えればエレガントな手法があるだろうと思います。

644
hidebou[sage]   投稿日:2013/05/05 23:48:38
IEプロセスへの独自DLL連鎖インジェクションに成功しました。起動EXEは最初
のIEのみをケアし、DLLを注入、DLLは自身プロセスで新たなIEプロセスが生成
される場合、自身のクローンを注入という流れが最も自然なようです。これを
親EXEで全部管理しようとすると相手が非同期で複数ですから、クラッシュの
可能性が出ますし、プロセス越えのマーシャリングコストで動作の切れが失わ
れるでしょう。開発はIE10で行いましたが、結果的にはIE5以上なら動きそう
な単純な呼び出しで実現されています。

645
hidebou[sage]   投稿日:2013/05/06 00:06:01
僅か10日ほどで結論付ける事ではないのかも知れませんが、WebBrowserで汎用
なブラウザを作ろうと言う試みはやめた方が無難です。ユーザーエージェント
が正しいとするなら、WebBrowserはIE7相当のドキュメントしか生成しませんか
ら、より上位なブラウザ用に書かれたHTMLで予期せぬエラーに見舞われます。

また、IE8以降はタブを別プロセスで管理しているようですから、制御には
DLL注入が必要となります。つまりネイティブなDLLを書ける環境でなければ
ちょっかいを出すことはできません。また、DLL注入は通常のブレークポイン
トを使用したデバッグができません。データをファイルに出力するか、Beep
等で状態を推察しながらのプログラミングとなります。

646
hidebou[sage]   投稿日:2013/05/07 00:55:41
理論的には無限に連鎖してナビゲート先のドキュメントプロセスへ介入する
はずなのですが、ドメインの変移を行うと不定回数で追跡がストールしてし
まうようです。興味深い事に、最初のIEインスタンスは比較的従順で、それ
を起点に生成された方は御しにくいように見えます。しかも、既存IE実行中
に、別プロセスグループとして起動しても「最初」とは認識されていない
ようです。IEは最もいじられる対象になりやすいモジュールですから、予期
せぬ低水準な操作に対してある程度の耐性が施されているのかも知れません。

647
hidebou[sage]   投稿日:2013/05/07 20:33:21
Windows7+IE10環境ではIEが別窓で複数存在してもIE自体は同一プロセスの
ようです。つまり親HWNDは別スレッドで動作していることになります。また、
ドキュメントは必ず別プロセスですから、話がややこしくなります。この状
態で安定的にHWNDやIWebBrowser2のコンテキストを見極める事ができていま
せん。あまり深入りせず、マーシャリング経由で目的を達成できないのかを
再考察する必要があるかも知れません。

648
hidebou[sage]   投稿日:2013/05/08 22:16:59
複数プロセスに分散ロードされたDLLからの報告を表示するエディタウインドウ
というのを以前に書いていたことを思い出し、デバッガ代わりにデータを出力
させてみたところ、どんな状況で何がだめなのかが掴めたようで、IE乗っ取り
ライブラリは完成しました。

通常はIEに限らず何らかの機能追加をしようと思えばCOMDLL登録してプラグ
インするわけですが、そのような手間はまったく要らず、起動EXEがIEを包
括的に管理します。ネイティブなIEのHWND群やドキュメント群を本来の動作
の前にカスタマイズできるわけです。内容はごくオーソドックスなAPIの集積
なんですが、いかにターゲットスレッドのコンテキストに寄り添う形で全体
をデザインできるかという問題がとても難解です。難解であるが故にこの分野
でのアドバンテージとなると感じています。

649
hidebou[sage]   投稿日:2013/05/08 22:44:37
HTA系のMSHTML利用では、あらゆる生成過程に介入して、今までに見たことの
無いものを実現しようとした訳ですが、今回のIEカスタマイズでは、生成に
関与することは一切やめ、HTMLのパースで起こるエラーはIE自体のものである
という状態を作った後に適切なタイミングで制御を奪うという手法をとりまし
た。現状ではすべてのEXEインスタンスが共通なDLLを強制ロードされて動作
しますが、IDLにはHWNMDのマーシャリング機能もあるようですから、分散さ
れた各プロセスのDLLが集約DLLで定義された型へ情報をコールバックする形
にすれば汎用なライブラリとすることも可能です。

つまりカスタマイズされたブラウザを作りたい場合に、ブラウザ自体を書く
必要はなく、マイナーなバージョンアップが行われてもメンテする必要が
生じないにも関わらず、ドキュメントの左側にネイティブなツリービューを
置いたりできることになります。

650
hidebou[sage]   投稿日:2013/05/10 02:07:27
タブ操作で親HWNDが受け取るメッセージを眺めるとドキュメント生成完了
タイミングで送信される非公式なメッセージを見出すことができます。
このメッセージが確実なものであれば、ドキュメントプロセスでの生成完了
を自力で検出する必要が無くなりますから、基本動作ライブラリは20kを切る
くらい短いコードになるかも知れません。

651
hidebou[sage]   投稿日:2013/05/10 02:22:24
IEとHTA手法の融合というアイディアも面白いと考えています。つまりIEの
タブにHTAを埋め込む、又はローカルセキュリティーのWebBrowserを埋め込む
手法です。通常は例えマニフェスト定義でも、独自なCOMオブジェクトを利用
する場合は管理者権限が必要だと記憶していますが、IEを起動するEXEにその
必要が無いとすれば、IEに侵入させたDLLで、安全とマークされたCOMDLLを
インスタンス化している振りをしながらファイル入出力等のアプリケーション
動作をさせる事は十分可能だと考えます。

652
hidebou[sage]   投稿日:2013/05/10 02:45:44
上記発想をHTABOXに適用すると、EXE化されたユーザー生成ファイルを実行
すると、初期タブにEXE内リソースHTMLを表示したIEが出現する。このタブ
では何の警告も無しにアプリケーション動作が行える。メニューこそポップ
アップウインドウで無いので使用できないが、他のネイティブコントロール
、デザインビヘイビアも機能する。2番目以降のタブには自身サーバーのオン
ラインヘルプページや、試用版なら製品版購入フォームを表示する。
というような事が実現できます。まぁ外観がまんまIEですから、利用される
側の心情を考えるとデリケートな問題をはらみますが、IE自体はCOMとして
独自生成しても問題は無い訳ですから、新しい発想のアプリケーション形式
として提案する価値があると感じています。

653
hidebou[sage]   投稿日:2013/05/13 02:15:45
http://kuroda.bglb.jp/vector/iecamera.zipを公開します。名称は「IEカメラ」
動画等のスナップショットを撮る目的に特化されたIEカスタマイズアプリです。

インストールの必要は無く単にEXEを実行すればIEが起動します。使い方は
単純です。表示されるターゲットマークをクリックしてアクティブにし、
移動、サイズ変更後に、Enterで画像取得という流れになります。詳しくは
ReadMe.txtをご覧ください。動作確認は32bit環境IE10,IE9で行いました。
IE8で動作する可能性はありますが、IE7はプロセス構造が異なるため動作
対象に含まれません。

本来は非表示取得した全ページイメージから指定座標部分を抜き出すので
すが、IEに表示した場合との座標差が生じるページが散見されますので、
表示中DCの単純取得としています。本アプリケーションはこの機能のまま
フリーソフトとして公開する予定です。マクロ動作等は製品版の機能という
ことになります。

654
hidebou[sage]   投稿日:2013/05/13 02:36:14
画像キャプチャというと、全画面PrintScreenをソフトウェア的に切り出す
手法しか存在しないと思いますが、ターゲットマークがページスクロールに
同期する事で、これがIE内部への侵入で実現されていることが判ります。
もし、同期しないスクロールが必要ならCTRLキー押しでスクリーン座標に
固定されたスクロールが行えます。

私にとってこれはMSHTML.DLL解析の卒業論文のようなものです。結局IEは
コンテキストにデリケートで余計な所に触らない方がいいという結論だった
のですが、それを感じるためには他のHTMLオブジェクトとの比較を行える環
境が不可欠だったと感じています。

ここをご覧の皆さんはごく一握りの「書く側」の人間な訳ですが、世の中の
ほとんどの人間にとって開発ツールとしてミドルウェアなどは縁の無い存在
ですから、こういったすぐに使えるツールを書きながら基底ライブラリを固
めることになろうと思います。

655
hidebou[sage]   投稿日:2013/05/14 13:30:34
http://kuroda.bglb.jp/vector/iejack.zipを公開します。名称をIEジャック
に変更し、チューニングを煮詰めました。スクロール中のCTRL押しはズーム
動作となるため、Zキー押しに変更されました。

656
hidebou[sage]   投稿日:2013/05/14 13:53:56
上記バイナリはIE8で動作しない事を確認しました。今後その要因が軽微なも
のであることが判明すれば対応する可能性はありますが、積極的に旧バージ
ョンをサポートするための改良は行わない方針です。

ここで確立されたIEジャックライブラリはC++開発者向けに提供される予定で
す。プラグインでは実現できないダイナミックなカスタマイズを、ブラウザの
基本機能をそのまま流用しながら行う事ができます。

657
hidebou[sage]   投稿日:2013/05/16 01:50:04
IE8で動作しなかった原因は、試験PCが非力であるが故に、非同期な処理で
渋滞が発生しクラッシュしていたという事が判明しました。したがってIE
ジャックライブラリはIE8以降で動作する仕様に決定しました。推察するに
IE7からIE8への変更はプロセス構造に関わる根本的なものであり、WebBrowser
等の単独HTMLインスタンスはその時点で置き去りにされたのだと思われます。

IE8以降が分散プロセスを選択したのは、プロセス空間におけるメッセージの
飽和という、Windows上では避けがたい問題への対策でしょうし、その結果
外見上のHWNDとドキュメントのプロセスが異なり、ドキュメント自体も、巡航
に伴いコンテキストが変化するという状態になっていますので、過去のIE制御
手法は通用しなくなったのでしょう。

658
hidebou[sage]   投稿日:2013/05/16 02:00:50
最も劇的な効果があるドキュメント領域ウインドウ矩形の変更に成功しました。
これによって、ドキュメント下部に置かれたツールバーから、必要な追加機能
をトグルボタンで選択する事が可能となります。おそらくIEは他のブラウザ
とは異なり、プラグインのための積極的な情報公開は行っていないと思うので
すが、本ライブラリを使うことによって独自なプラグイン規格を創出すること
が可能です。しかもこのライブラリ経由での操作は通常のプラグインに課せら
れるスレーブとしての存在ではなく、APIレベルでIEの制御を奪うマスターとし
ての存在になります。

659
hidebou[sage]   投稿日:2013/05/16 22:39:18
http://kuroda.bglb.jp/vector/iejack.zipを更新しました。IE8,9,10での動作
を確認したバイナリーです。

IE8の場合タブの設定を9以降のように「現在のウインドウのタブで表示する」
に変更されていると想定しています。新たなウインドウは意図された制御の
離脱要求とみなし、通常のIEを表示します。

今回の改良でXPがをサポートできることになったのは大きな収穫だと感じて
います。操作は極めて直感的ですが、添付ReadMe.txtをご覧ください。

660
hidebou[sage]   投稿日:2013/05/16 22:59:13
通常の画像キャプチャツールとしての動作はひと段落しましたので、いよいよ
ウインドウ非表示なまま、ライブカメラ等の画像をロボット取得する部分を
書こうと思います。要は一度表示状態で取得した画像の座標とURLを記憶し、
定時に繰り返すものです。この時、IEでHTML解釈されたページ画像と、非表
示でOLE取得したページ画像に微妙な座標差が生じますので、座標決定時に
両者を比較して正確な座標を算出する部分が鍵になると思われます。

661
hidebou[sage]   投稿日:2013/05/17 21:04:20
http://kuroda.bglb.jp/vector/iejack.zipを更新しました。コンテキストを
外してしまうバグがありましたので修正しました。ヘルプのボタンが追加され
ましたが、内容は空です。

662
hidebou[sage]   投稿日:2013/05/23 01:07:29
IE制御ライブラリは名称を「Internet Explorer Wrapper Library」にしよう
と思います。同じような趣旨のライブラリやプログラムは多く存在しますが、
その更新日時から推定するにIE8以降の分散プロセスには対応しかねている場合
がほとんどですから、十分に存在をアピールできるものと考えます。

IE8以降では親プロセスのIWebBrowser2を捕まえたところで、タブ内のDocument
には触れないような構造に見えますから、そこを乗り越えたコードが書ける方
はそう多くないだろうと予測します。したがってこのライブラリはその壁を
乗り越える手法をラップして開発者に意識させないことを目標にしています。

663
hidebou[sage]   投稿日:2013/05/23 03:33:16
ことWEB上の活動において、PCの前に人間がいるのか、ボットが動作している
のかを識別不可能にする意味において、IEを包括する形での低水準制御を実現
し、低水準であるが故の、実ウインドウ生成を伴わない画像処理を実現しまし
た。これはとても大きな意味を持ちます。

従来は、既存の情報を収集して単に並べるだけでも十分に創造的な仕事と捉え
られていたでしょうが、もはやそれはボットでも可能な状態になっていると
考えます。情報の収集がWEB上で行われ、その公開もWEB上なら、後は目的や
オリジナリティーを定義するだけで、たった一台のパーソナルPCが何百、何千
人分の仕事をやってのけてしまうことになるでしょう。逆に言えば真に創造的
な仕事とは何かという問いを人間側に突きつけられる世界です。

664
hidebou[sage]   投稿日:2013/05/24 01:07:25
このInternet Explorer Wrapper Libraryは通常のプラグインとはまったく
異なる発想によってIEを制御します。通常のプラグインはブラウザの許可を
もらって活動しますが、このライブラリはブラウザを外側からコントロール
します。その最も象徴的な機能が非表示のまま、目的を達成できる点です。
現在調整中のアプリケーションは、ブラウザ上の現物DCを画像保存する動作
により、取得対象URLと、取得座標を埋め込んだスクリプトを生成します。
このWSFをクリックすれば、アプリケーションが非表示で起動され、指定され
た間隔で画像を取得し続けます。ライブカメラ等のページをロボット動作で
キャプチャし続けることができます。

665
hidebou[sage]   投稿日:2013/05/29 04:47:45
IE9,8のレンダリングエンジンはIE10と異なりデリケートであるという問題を
解決するのに数日を費やしてしまいました。興味深いことにOLEの観点から見
た場合IE10はIE7手法へ戻す改良が行われたように見えます。両者は同じコード
で動作しますが、IE9,8を対象に含めた場合は、コンテキストをロンダリングす
るような動作を加味しないと非表示状態での画像取得は成功しないようです。

666
hidebou[sage]   投稿日:2013/06/23 19:01:55
おそらくボット動作で最も需要があるであろうtwitterのボット化に取り組んで
います。1ヶ月ほど、大規模数独問題の軽量な作成という全く畑違いな分野で
一定の成果をあげることができましたので、それを画像送信するものです。
サーバー側としては、画像のアップはリソースを消費しますから、あれこれと
手を打っているようですが、IE10の場合ユーザーの代わりにボットを置くこと
はそう難しくないようです。ボットは主力ではないPCで動作させることが多い
でしょうからIE8を動作範囲に入れたいのですが、そこで苦戦しています。

667
hidebou[sage]   投稿日:2013/06/24 15:47:09
IE8以降という動作環境で完全なマクロ実行を提供できそうです。単純な動作
(クリックやフォームへの入力)であればスクリプトで可能なのではないかと
と考えたくなるのですが、画像をアップするというような動作がある場合、表
示されたファイルダイアログの制御を奪い、入力を偽装する必要が出ますので、
実際にコントロール位置へマウスを移動させたり、キーイベントを生成できる
WIN32API無しに実現することはできません。また、この時のコンテキストは
HTML側でなければ成功しませんから、実行中ドキュメントプロセスへの動的DLL
注入も必須なテクニックとなります。

668
hidebou[sage]   投稿日:2013/06/24 15:57:01
Bot動作への賛否はさておき、twitterのようなサービスを運営する側にして
みれば、Bot動作は排斥したいと考えるはずです。ですから直接なPOSTや通常
のブラウザではない反応を見せるユーザーは退場させられる運命にあります。
結論として、最も安定的にBotを実現する手法は実際に現役のブラウザを起動し、
ユーザーが行うようにマウスやキーをプログラムで操作することです。

669
hidebou[sage]   投稿日:2013/06/24 16:06:22
サーバー側にしてみれば、この手法で動作するBotを識別することは不可能です。
なぜなら、ブラウザ自体がそれを識別し得ないからです。何らかの動作を自動化
するのがPCの役目です。動作の起点が人間の暖かい指で押されたキーイベントで
なければならないなら、PCであることの意義を失うことになります。

670
hidebou[sage]   投稿日:2013/06/24 16:18:17
ただし、サーバー側で識別不能なBotがいたずらに増加すればサービス全体を
圧迫することになります。ここが実に微妙なところですが、Botはそれを使用
する「良識」を持つ人間が使用すべきです。ですからこのようなツールをフリ
ーな状態で提供することは自爆行為となります。動作が堅牢であることは容易
に確認できるものの、それなりの覚悟がなければ買えない価格を設定すべきと
考えています。

671
hidebou[sage]   投稿日:2013/06/25 01:39:31
twitterへのBOT動作を開始しました。公式twitter検索で「ナンバープレイス」
と検索すればこのBOTの出力をご覧になれます。現時点では一般的な9×9問題
を生成していますが、このBOTは100×100までの問題を現実的な時間内で生成
する能力があります。ブログ等へのボット動作でもっと大きなサイズの問題を
ご覧いただけることになろうかと思います。

672
hidebou[sage]   投稿日:2013/06/28 02:11:27
ここ数日IEによるWEBBOTとWordによるHTMLメールBOTを書きながら、長年に
わたって不思議だった事に回答が出ていることに気づきました。要は
「なぜスクリプトのSendKeyで安定したマクロ動作ができないのか?」につ
いての回答です。

673
hidebou[sage]   投稿日:2013/06/28 02:23:05
例えばファイルダイアログの文字入力コントロールがフォーカスを持って
キーを待っていた場合SendKey的な手法では成功するかもしれないし、し
ないかもしれない状態となります。一旦文字列が書き込まれても何かの拍
子に消えてしまうことも起こるでしょう。これは、各コントロールが親の
スレッドコンテキストでしか正常動作しないことに起因します。ですから
SendKeyで自分用ツールは作れても他人様に使ってもらえるものは書けない
のです。

674
hidebou[sage]   投稿日:2013/06/28 02:37:31
では、それを確実にこなす為に何が必要かですが、それは相手側プロセスの
必要とされているスレッドで自分のコードを動作させる以外に方法はありま
せん。HOOKするにしてもDLLインジェクションするにしてもDLL内で発生する
出来事(完成の直前までは大体クラッシュするのでその要因)を別プロセス
から確実に監視、分析する仕組みを書けるかが鍵を握ります。

675
hidebou[sage]   投稿日:2013/07/01 00:00:00
twitter及びブログCGIへのロボット動作は、あえて500MHzの化石ノートで
行っていますが、安定動作のポイントが掴めたようですので、IE操作ライブ
ラリのリリースに向けて行動したいと思います。肝心のHTABOX系は何とか食え
るようにならなければ先に進めないというのが正直なところです。

676
hidebou[sage]   投稿日:2013/07/01 00:00:00
IE操作ライブラリにしても、それを使ったロボットにしても、情報の収集
側機能はある程度フリーで提供したいと思いますが、送信側に関わる場合
それをフリーな状態にするのは単に「インターネット自体を壊す」ことにな
りかねませんので、用途をお伺いしてカスタムビルドすることになろうかと
思います。

このライブラリによる送信がどれほど強力かは、例えばtwitterのAPIが今後
変化した場合を考えれば明白です。そのAPIは当然ブラウザのご機嫌を損ねる
わけにはゆきませんから、どんなに変化しようとライブラリ側には影響が出ま
せん。押すボタンの位置が変わる程度のことでしょうから、マウスイベント生成
座標を変える程度で対応可能となるわけです。

677
hidebou[sage]   投稿日:2013/07/02 00:00:00
ロボットによる自動更新に向くブログサービスを選別するために、普段は一切
見ない他人様のブログを目にするわけですが、よくもまぁどうでもいいことを
わざわざ発信するものだと。一昔前は少なくともページを自前で作る必要があっ
た訳で、作り手も何かを伝えたいというビジョンがあったと思うのですが..
輪をかけてtwitterでしょ。どこまで人間は馬鹿に退化するんでしょうね。

678
hidebou[sage]   投稿日:2013/07/03 00:00:00
スレ違いなことは重々ご容赦いただいて、ロボットによるブログCGIへの定期
更新動作が、どの程度ページヒットを誘発するのか、また、Googleに対して
どの程度SEO効果があるのかについて短期的な結果が出ましたので、参考まで
に報告します。
H社:はてな L社:livedoor J社:JUGEM A社:Ameba S社:Seesaa
に対してWORDが作成したHTMLメールをOUTLOOKで送信、送信イベントをフック
してHTML内容を各社共通に認識可能なものに加工することによりブログを30分
間隔で更新。

679
hidebou[sage]   投稿日:2013/07/03 00:00:00
ページ閲覧回数
S,A,J,L,H の順で先頭ほど多い

Google検索表示順位
H,L,S,A,J の順で先頭ほど上位に表示される

したがって、内向きなコミュニティーを重視した動作を行うCGIがA, Sであり
外側への情報発信を重視しているCGIがH, Lと言えます。何かの情報を発信
する際の参考にしていただければ幸いです。

680
hidebou[sage]   投稿日:2013/07/03 00:00:00
これからの情報発信、特にプログラミング系のものなら70億人中の1億を相手
にしたところで意味が無いと思います。特にこの国の体質は「書けない人間」
が「書ける人間」を雇い、系列やブランドイメージだけでビジネスしますから
能力のある人間はたくさんいらっしゃるのでしょうが、世界的には見る影も無
い状態になっているのだと考えます。

681
hidebou[sage]   投稿日:2013/07/05 00:00:00
海外から.NETコードの保護について問い合わせをいただきました。アンマネ
ージプロセスがプライベートなマネージ環境を動的に生成し、暗号化してリソ
ース格納していたアセンブリをストリームパースして実行するという実に
当たり前で確実な逆コンパイル対策なんですが、まともに興味をもってもらっ
たのが初めてだったものですから、こちらが面食らってしまいました。

682
hidebou[sage]   投稿日:2013/07/05 00:00:00
XPが退役すれば、いよいよ.NETを標準ライブラリとして扱える訳ですが、
一旦マネージの軍門に下れば、芋ずる式に手の内が読み解かれてしまうで
しょう。アンマネージプロセスが必要な時だけマネージ環境を生成すれば、
たとえプロセスにアタッチされたとしてもネイティブなメモリ空間が見える
だけで、実行アセンブリを解析する手立てさえ与えないことにできます。

あまりに総スカンだったのでこの件についてはグレていましたが、今一度
賛同してくださる方を探してみようと思っています。認知されれば市場規模
は無限大でしょうから。

683
hidebou[sage]   投稿日:2013/07/06 00:00:00
数独問題の画像生成という毒の無い分野を利用したクライアント型BOTによる
情報発信実験は概ね成功しているようです。通常はブログ更新をTwitterに通
知させるようですが、これでは複数のブログをパラレルに持てません。逆に
Twitterを先行させ、その結果を複数のブログに反映させる。Twitter上の情報
はいわば閉ざされた世界なのでこれにより実WEB上に情報が拡散する。各社の
ブログCGIは何らかの広告をHTMLに付加するので、ロボットが生成した同一な
HTMLだとしてもクローラはスパムと認定しない。というのが私の構想です。

684
hidebou[sage]   投稿日:2013/07/06 00:00:00
私の本心又は夢は「HTMLアプリケーションの普及」なのですが、それを実現
するためには、まず食える技術、製品を確立しなければならないというのが
自分お置かれた状況です。直接HTABOXと関わりの無いことを書くことは、
自分自身「美しく無い」と感じましたので、HTABOXに関する成果が無い限り
下記開示版をお借りしての書き込みとさせていただきます。

一応「アンマネージな...」という縛りを付けて、あまり荒れないようにして
いますが、さまざまな夢を聞かせていただければ、私としても勉強になると
考えますので、遊びにいらしてください。

http://jbbs.livedoor.jp/computer/43808/

685
デフォルトの名無しさん[sage]   投稿日:2013/07/07 00:00:00
こんなマイナーシステム解析する暇な企業もいないでしょう。
誰が得するのかわからない。

686
hidebou[sage]   投稿日:2013/07/08 00:00:00
おっしゃるとおりHTABOXコアに関しては現状では「誰も得をしない」と私も
思います。むしろIEへ介入してHTA動作させた方が、Twitter等の外部WEBサー
ビスとの連携や、HTML5への対応でメリットが生まれると感じています。

WebBrowserも含めたIE以外のHTMLウインドウはIE7と同等機能に固定されて
いて、今後も手当てが行われることは無いのではないかというのが最も
大きな理由です。

687
hidebou[sage]   投稿日:2013/07/08 00:00:00
例えばHTMLで簡単にアプリケーションが書きたい。ファイルにもアクセスしたい。
という欲求がHTA手法だったと思います。ここで皆さんに励ましていただきながら、
勉強できたことで、IEを通常に起動しながら、非登録のCOMDLLだろうが、既存WEB
サービスへナビゲートしてからの独自スクリプト追加だろうが、何でもやろうと
思えばできるという結論に達しました。

688
hidebou[sage]   投稿日:2013/07/08 00:00:00
ですから目指す目的は「HTMLアプリケーション」なのですが、mshta.exeの拡張
ではなく、iexplore.exeの拡張へ方向転換すべきと考えています。この場合、
そうしてくださいとアナウスされていたのはIE7まででしょうから、アプローチ
の仕方としてクラッキングと誤解されない道筋を見出す必要があると直感します。

「IEをロボット動作させるためのライブラリ」というアプローチを模索して
います。その機能の一端としてHTMLアプリケーション動作を含めるというのが
よいのではないでしょうか。

689
hidebou[sage]   投稿日:2013/07/08 00:00:00
IE上でページをHTA動作させるデモを作成しました。
http://kuroda.bglb.jp/htabox/iedemo.zip

IEDemo.exeへtest.htmをドロップして起動すると、IEが起動し、test.htmを
表示します。test.htmではActiveXObject("Scripting.FileSystemObject")を
実行していますが、IEはなんら警告を発しません。

この制御は最初に表示されたtest.htmにのみ適用されます。新たなタブで
ナビゲートされた通常ページは通常セキュリティーです。
本デモンストレーションはIE10、IE9、IE8のみが対象です。

690
hidebou[sage]   投稿日:2013/07/08 00:00:00
実行HTMLの内容がどんなに過激でも、このデモは成功するはずですから、いつも
お使いのHTAコードを実行させてみてください。ただし、ファイル拡張子がHTA
の場合発せられる警告を回避する方法は無いようです。拡張子はあくまでもHTM
又はHTMLでお願いします。

691
hidebou[sage]   投稿日:2013/07/08 00:00:00
現在稼働中のTwitterボット @NumberPlaceBot はHTML内部にスクリプト侵入
はせず、エレメント位置を監視する程度にして、低水準なシステムイベント
を偽装することで成り立っていますが、明日は後付スクリプトによる自動
ツイートを成功させるには?というテーマでもう一押ししてみます。成功
した場合、短い時間に限定されるでしょうが、感謝の意味をこめてここで
公開したいと考えています。

692
hidebou[sage]   投稿日:2013/07/08 00:00:00
今日は自前HTMLファイルへナビゲートしてセキュリティーを緩和し、ファイル
アクセスを行ったわけですが、これは信頼のおけるサイトの場合外部に対して
も行うことができます。また、通常は使用されないwindow.externalにWIN32
ディスパッチを公開、execScriptで追加したスクリプトで既存WEBサービスを
拡張してしまう事が可能でしょう。

WEBプログラマーサイドに立ってみれば、そんなことされたらたまったもんじゃ
ないというくらいのチート技に感じるでしょうが、ブラウザを中間に挟むことに
より、ソフトウェア的な操作である痕跡は残りません。

693
hidebou[sage]   投稿日:2013/07/09 00:00:00
以前に「IEコンポーネントを...」というスレッドがあったはずですが、
さすがにIE8以降は分散プロセス化され、ディスパッチマーシャリング経由
では操作できませんから、今は存在しないようですね。でもこのライブラリ
は、もう一度そういったスレッドを活性化させるだけの力を秘めています。

フォローしてくれた人に自動的にフォローとメッセージを送るスクリプトは?
というような課題に具体的なコードを示すことが可能になるからです。

694
hidebou[sage]   投稿日:2013/07/09 00:00:00
今でもそうなんですが、分散プロセスだろうが、IEを外堀、内堀から攻めて
自由にコントロールすることくらいは、COMに対してある程度の造詣があれば
可能なことだと考えています。では、なぜそれが世に出ないのか?それが
見識のあるプログラマーの良心によって抑えられていたとすれば、私はとて
も愚かなことに手を染めようとしているのかも知れません。その迷いから
一歩踏み出す勇気を与えてくださった685さんに感謝しています。

695
hidebou[sage]   投稿日:2013/07/09 00:00:00
IE10でバイナリービヘイビアは不可能なのかについての情報収集を行って
いました。インターフェースとしては有効だが、表示されないという結果
でした。作りかけのIE画像取得ロボットでは、半透明なWS_POPUPをツール
としてドキュメント上に表示しますが、やはりこの手法が正解なようです。
バイナリビヘイビアが切り捨てられたことは、ドキュメント上で何らかの
マジックを行うときの敷居が高くなった事を意味します。

696
hidebou[sage]   投稿日:2013/07/10 00:00:00
既存WEBサービスへのユーザースクリプト追加は、どんな手法が確実か模索し
ていますが、HTMLとしてもらい、非表示又は表示モードレスダイアログとして
引数に親ドキュメントを渡す方法を考えてます。単なる感触なんですが、Twitter
のHTMLの場合、自身がオリジナルなHTMLコードかどうかを自己チェックしている
ふしがあります。ですから直接execScriptしてしまうと検出される恐れが出ます。

ドキュメントがcompleteした時、ユーザー定義HTMLがあった場合はモードレス
ダイアログとして生成されるという規格にすれば、スマートだと感じます。
万が一実在フレーム数をカウントする対策を講じようとしても、この場合あら
ゆるMSHTML系インターフェースの動作を偽装する権利を有しているのは我々の
方ですから軽くあしらうことが可能だと推察します。

697
hidebou[sage]   投稿日:2013/07/10 00:00:00
http://kuroda.bglb.jp/htabox/iedemo.zipを更新しました。今回は単にツール
バー位置を決定するにとどまりました。IEのロボットカメラ用ボタンを流用
していますが、ウインドウ下部に表示するものとします。将来はユーザー定義
となります。IE8の場合デフォでステータスバーばあるためにちょっとおまぬけ
に見えますが、IE9、IE10はステータスバーが無いのでいい感じに収まります。

また、下部に設けた理由は「単なるプラグインとは違います」という明確な
主張になるという意味も込められています。

698
hidebou[sage]   投稿日:2013/07/10 00:00:00
どうもいろんな名前が浮かんでは消えてゆくのですが、このIEがらみのライブラリ
に名前を付けたいと思います。

「Html Application Library 2013 α」の頭文字をとってHAL2013Aにしたいと
思います。HAL2013AでのGoogleヒットは7件ですから、他のものと間違うことも
ないでしょう。HAL2013Aエンジンを搭載した最初のリリースアプリケーションは
ツイートテキストファイルと画像フォルダを指定すればユーザーの代わりに
ロボット送信するものになります。これは従来のボットという概念を完全に
塗り替えるでしょう。これはソフトウエア的なロボットであり、決まりきった
WEB上の作業なら、もう人間ではなくロボットが行うべきという事を具体的に
示すものになるでしょう。

699
hidebou[sage]   投稿日:2013/07/10 00:00:00
工業的な物作り、また、情報処理においても徒党を組んだ企業が個人に打ち負
かされる時代が来ます。もし将来のある若い方がこれを読んでくれているなら
10年、20年後に「それロボットでもできるから」と言われないような、クリエ
イティブな発想、能力を身に付けてください。逆にいえばそうでなければ生き
残れないシビアな世界が待っていると私は予見します。

700
hidebou[sage]   投稿日:2013/07/10 00:00:00
今日の作業も今のところお見せするような成果には至っておりません。
さっきツイートした文字列をコピーして、私が行っていることをまとめ
てみました。

このソフトウェアロボットの試験的な一般公開へ向けた準備を開始しました。
ボット部分の開発コードはHAL2013Aこれは、IEの生成スレッドへ連鎖的にバイ
ナリコードを侵入させることにより、完全に制御を奪うと同時に、クリックや
キー入力も偽装します。

自動ツイートボットは開発コード「myna bird」つまり九官鳥です。
ユーザーの実行環境で、直にクリック位置、ツイートテキスト、アップロード
画像フォルダを指定することにより、定期的な画像付きツイートを実行します。
通常のBOTと異なりサーバーには人間が操作したログが残ります。

701
hidebou[sage]   投稿日:2013/07/17 00:00:00
HTMLアプリケーション以外の話題に移行する可能性があったために作成した
http://jbbs.livedoor.jp/computer/43808/
を閉鎖しました。IEの制御はHTABOXコアと同じ目的のためにあるからです。
モジュールの耐久テストを行いながらの開発ですので結果をすぐお見せでき
ない状態ですが、ご容赦ください。

702
hidebou[sage]   投稿日:2013/08/15 00:00:00
久しぶりな書き込みです。
ただ生きているというお知らせのみです。
ありがとう。

703
hidebou[sage]   投稿日:2013/09/06 21:58:38
すこしばかり余計なことに首を突っ込んでコードを書かない日々をすごしたのですが、
走るか走らないかという単純な事の連続であるコーディングとは異なり、
世の中にはさまざまな価値観や、人間がいるものだと至極勉強になりました。

また、ぼそぼそと呟きながら、MSHTML系のモジュールを書きますのでよろしく。

704
片山博文MZコスモ ◆T6xkBnTXz7B0 []   投稿日:2013/10/17 21:37:34
お元気?

705
hidebou[sage]   投稿日:2013/10/19 18:00:57
ご心配かけてすいません。
原点に回帰して、現状のIE,8,9,10を子プロセスとして起動し、指定URLへ
ナビゲート後、アプリケーション環境として実行するEXEを公開したいと
考えています。IE10以降はHTML5への対応を明確にしているわけですが、実行
されるHTML中スクリプトのローカルファイルアクセス等にはデフォルトで警告
が発せられます。その部分をHTAと同等な権限にしようとするものです。

706
hidebou[sage]   投稿日:2013/10/19 18:10:45
確実にそうであるというというほどの実験は行っていませんし、今後MS側が
MSHTA.EXEやWebBrowserで生成されるドキュメントをどのように考えているの
かも不明なのですが、WindowsOS上で最新のHTMLパース環境を得るためには
IEを起動する事が必要だとすれば、外向きなブラウザとしてのセキュリティー
機能を抑制することで、汎用なHTML+JavaScriptにActiveXObjectというアプリケー
ション環境を提供できるのではないかという発想です。

707
hidebou[sage]   投稿日:2013/10/19 18:20:43
欲を言えば、IEが行う分散プロセス動作状況下でのサイドバイサイドOBJECT
生成を実現したいと考えています。ポイントはスクリプトパースによる動的
なOBJECT生成でありながら、データバインドのような低水準インターフェース
を認識させることが可能なのかですし、それが不可能なら、既存CLSIDのオブ
ジェクトをダミー生成して当該インターフェースをフックするような手法を
試みたいと考えています。

708
hidebou[sage]   投稿日:2013/10/19 23:15:57
http://kuroda.bglb.jp/htabox/htmlapp.zipを公開します。
HtmlApp.exeはドロップされたHTMLファイルをHTAと同等なIEタブとして実行
します。初期URLはEXE内のリソースHTMLとし、ドロップされたファイルへの
ナビゲートを行いますがXP+IE8環境だと、表示されにくいことを確認しています。
現在はWin7+IE10での実験が主です。詳しくは添付ReadMe.txtをご覧ください。

709
hidebouu[sage]   投稿日:2013/10/19 23:38:05
IE9+VistaとIE10+Win7はほぼ同等に扱えるのですが、IE8+XPだけ対策コードが
必要となる局面が多いように感じています。初期URLをダミーとしてナビゲート
するという発想自体がIE8の要求から生まれたものです。この部分は早急な課題
として克服しなければならないと考えています。

710
hidebou[sage]   投稿日:2013/10/20 12:19:08
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
初期URLをabout:blankとして引数URLへナビゲートするものへ変更しました。
これによりIE8環境においても従前より安定した動作になると思われます。
尚、起動されたIEは新規タブを生成することも可能です。追加されたタブは
通常のセキュリティーで動作することになります。

711
hidebou[sage]   投稿日:2013/10/20 17:26:01
IEが行う分散プロセス動作状況下でのサイドバイサイドOBJECT生成にチャレンジ
していますが、実現できたとしても複雑な機序になってしまうように思われます。
管理者権限実行を前提として、実行時のみ通常手法でレジストリ登録すると
した方が、トラブル時の問題切り分けがたやすいのではという方向に傾きつつ
あります。

712
hidebou[sage]   投稿日:2013/10/20 23:31:18
IEを使った既存WEBサービスの拡張(外部ページに独自機能を付加する)とは
異なり、ローカルなHTMLアプリケーションのベースとしてIEを捕らえた場合、
解りやすさが最も重要だと考えます。ドキュメント側GUIスレッドと同期する
ファイル系コモンダイアログを提供するくらいに留めて従来のHTA手法に代わ
るHTML5アプリケーション環境としてリリースできればと考えています。

713
hidebou[sage]   投稿日:2013/10/21 12:08:27
起動時に必ずレジストリを確認し、これから実行しようとするEXEとDLLのパス
を定義するという単純な手法で、データバインド機能をIE10に追加したいと考
えています。個人としての利用はフリーとしてリリースしますが、清貧の極み
という状況ですから、ご寄付は歓迎するという姿勢を考えています。

714
hidebouu[sage]   投稿日:2013/10/21 19:04:55
独自なデータバインドOBJECTをIE10で動作させるのは、そんなに難しくないの
では?と考えていたのですが、そう甘くはなかったようです。例によって、簡
単に実現できないということは、実現できればその分だけアドバンテージとなり
ますからもうひと粘りする予定です。

715
hidebouu[sage]   投稿日:2013/10/21 19:38:50
最も素直な方法は
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
を入れることですし、これは問題なく動作します。IEが上記メタタグを認識す
るのであれば状況に応じて選択するというのが正解なのでしょう。将来下位
互換が失われた場合は埋め込みの下位互換ドキュメントを作成する必要があり
ますが、現状でそこまでやる必要は無いように思います。

716
hidebouu[sage]   投稿日:2013/10/21 20:57:21
zipを更新しました。
test.htmは独自DLLによるデータバインドデモを含んでいます。もし、下位互換
モードを嫌うなら、モードレスダイアログで下位互換を実現し、データバインド
する方法も有効だと推定されます。

717
hidebouu[sage]   投稿日:2013/10/22 15:19:36
HTMLダイアログ表示を行うと相変わらずスクリプト警告が表示されますので、
これを抑制すべく、当該ドキュメントプロセス中のあらゆるHTMLドキュメント
のセキュリティーを包括的にアプリケーションレベルとする手法について模索
しています。

718
hidebouu[sage]   投稿日:2013/10/23 14:44:12
zipを更新しました。アプリケーション動作プロセス中で後続生成される全
ドキュメントをアプリケーションのセキュリティーレベルとすることに成功
しました。test.htmではモードレスダイアログを表示していますが、警告無し
に機能します。ダイアログと言えども
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
が無いとデータバインドは機能しないという結果でした。

719
hidebouu[sage]   投稿日:2013/10/23 18:42:43
最後にexecScriptを拡張して、最終引数でエンコード済みを指定された場合
デコードしてのパース、functionオブジェクトに限定したtoStringの抑制を
提供する機能を付加して、目標達成としたいと考えています。最終的にこれ
が、HTABOXになる可能性もありますが、当面はHTMLAPPと呼称するつもりです。

720
hidebouu[sage]   投稿日:2013/10/23 19:59:48
IE7あたりからでしょうか、ローカルHTML中にスクリプトがあると警告が発せ
られるようになってからというもの、HTMLはサーバー上のものという概念が
定着し、気軽にローカルなHTMLファイルでプログラミングしましょうという
サイトも無くなっていたような気がします。HTMLAPP.EXEはIEの機能を何ら損
なわずアプリケーションとして実行可能ですから、初心者のプログラミング
入門環境として大いに活用していただければと考えております。

721
hidebouu[sage]   投稿日:2013/10/23 20:09:39
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
HTMLダイアログのキャプションにHTML中のタイトルが表示されるようにしました。

722
hidebouu[sage]   投稿日:2013/10/23 21:41:35
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
メニュー、ツールバーを非表示としてHTA風なウインドウを実験しています。
最終的にはHTML中スクリプトへIWebBrowser2を公開できればと考えています。

723
hidebouu[sage]   投稿日:2013/10/23 22:05:40
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
window.externalにIWebBrowser2を公開することでHTMLからメニュー及び
ツールバーの表示を制御しています。動作を見るとツールバーの非表示は
メニューの非表示を伴うように見えます。ツールバーの制御はint引数を
とりますので、単なる表示、非表示だけではない制御ができるのかも知れ
ません。

724
hidebouu[sage]   投稿日:2013/10/24 12:46:44
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
window.externalをIDispatchExに拡張してBrowserを子要素としました。
また、HTMLダイアログのスコープでもwindow.external.Browserを操作可能
としました。コモンダイアログ系のサービスディスパッチも子要素として
追加される予定です。

725
hidebouu[sage]   投稿日:2013/10/24 13:12:30
HTML5によるアプリケーション開発が本格化した時に、結局アドバンテージと
なるのは、WindowsOSに密着したデータバインドやバイナリビヘイビアをどう
織り交ぜるかになるだろうと思います。規格上それらは「遺産」という扱い
になりますから、当時を知る人間しかコードが書けないという状態になるの
でしょう。

726
hidebouu[sage]   投稿日:2013/10/24 17:39:58
可能な限り軽量にHTML中のスクリプトパースへ介入するには?という課題で
検討してみました。IE10からはJavaScriptエンジンが変更されて、既知の
インターフェースとは異なることから、スクリプトタグとしてVBScriptを
宣言し、そのパースを横取りすることで任意な言語のパースとアクティブ
デバッグを実現できるのではないかと考えています。

727
hidebouu[sage]   投稿日:2013/10/24 23:11:12
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。

<script type="text/vbscript">
/*JSCRIPT*/
var jsstr = "from JScript";
</script>

でJScriptパーサーを内部起動するデモになっています。つまり、vbscript
を宣言したスクリプトタグ中であれば、任意な言語(.NETや暗号化JScript)
を記述できると考えます。IE9までならJavaScriptタグでも同じことが可能
なのですが、VBScriptタグとすることで全バージョン共通な動作を狙ったも
のです。

728
hidebouu[sage]   投稿日:2013/10/24 23:29:53
尚、上記機能は初期リリース時には説明しない予定です。HTMLはどこまでも
ソースが見渡せるという大原則には賛同します。悪意のあるコードが含まれる
可能性を小さくできるからです。しかしながら、「販売」できるほどの完成度
を持つコードの場合、コードが見えるということは類似な製品が即座に出現す
ることを意味しますので、そういった要求があるユーザーにのみ提供される
ことになろうかと思います。

729
hidebouu[sage]   投稿日:2013/10/25 12:46:03
VBScriptタグ偽装はF12のデバッグだとVBScriptを解釈される点、またHTML
ダイアログのスレッドでスクリプトエラーが発生した場合のハングなど問題
があるようです。エンコード済みでVB構文的に全文字列がコメント状態の独
自コードをデコードしてパースする目的に使用するというのが正しいかも知
れません。

730
hidebouu[sage]   投稿日:2013/10/25 18:52:19
真っ当にIActiveScriptを実装するOBJECTタグによる独自スクリプトパースを
検証しています。プログラミングというのは99%デバッグ環境とのお付き合い
になりますから、エラーのあるコードでもハングせず、要修正箇所が明確に
ならなければなりません。また、バグが枯れたと判断したら、エンコードで
きることを目指しています。

731
hidebouu[sage]   投稿日:2013/10/25 22:08:10
独自パース用OBJECTの基本設計は終了しましたが、いつものように手抜きで
本体HTMLをそのままダイアログで使用する場合、ハングするようです。つまり
HTMLダイアログ中の各種オブジェクトはできる限り本体で生成済みなものの
クローンを使おうとしているように見えます。CLSIDだけ違う別物を生成すれ
ばこの問題は回避できると思いますが、興味深い仕様だと感じました。

732
hidebouu[sage]   投稿日:2013/10/27 20:06:15
独自パース用OBJECTにwscript.exeを別プロセス起動し指定されたWSFをパース
しながら全インターフェースをフックして内部拡張する機能を追加しました。
IE8以降の分散プロセス指向はプロセス中メッセージの飽和対策と解釈してい
ますので、長大で複雑なスクリプトの場合、別プロセスでのパースは効果的だ
と予測します。

これによりスクリプトライブラリとしてWSFを持ち、GUIに集中したコードのみ
HTML中に置くことができます。また、WSFの言語に.NET等を加えればIEのバー
ジョンに関わり無く、統一した多言語の導入が行えるはずです。

733
hidebouu[sage]   投稿日:2013/10/27 20:42:35
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
添付WScript.wsfはHTML中の<object data='WScript.wsf'...>の指示により
wscript.exeでパースされHTML側ではwindow.scriptletでWSFを参照可能です。
またWSF側には省略可能な名前空間としてwindowが追加されています。

<job id="main">
<script language="JScript">
function WshTest(str){alert(str);}
</script>
<script language="VBScript">
WScript.Quit 0:
</script>
</job>

上記WSFの関数をHTML側で
scriptlet.WshTest('3456');
と呼び出す事ができます。また、WScript.Quitは拡張されていて、親IEが存在
する間は自動的に待機します。

734
hidebouu[sage]   投稿日:2013/10/27 22:51:14
考えて見るとWSF側への参照がIDispatchExであるだろうscriptletに集約され
ていることは、そこに追加されるインスタンスが何であろうとバリアントで
表現できるれば構わないことを意味しますから、非常に柔軟な拡張が可能です。

HTMLが実行されているプロセスやスレッドと関わり無く別プロセスでのパース
、デバッグであることも問題の切り分けを容易にします。ひと踏ん張りして
WSH系操作を完全に見直しましたが、とても有意義なコードを得たと思います。

735
hidebouu[sage]   投稿日:2013/10/28 11:46:28
WSH環境で.NETコードをパースする手法について考えています。従来はJSやVB
のスクリプトで実現できないことはCOMDLLを書いて提供するしかなかった訳で
すが、それを.NETのクラスライブラリで実現することを目指します。つまり
.NETコードは.NETのクラスライブラリのラッパーで主役はJSまたはVBというの
が最も親しみやすい状態ではないかと考えます。

736
hidebouu[sage]   投稿日:2013/10/29 00:27:09
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
WSH中の.NETコードは<resource>として定義し、WSH.CreateObjectを拡張して
コードのパースを行い任意なクラスを生成するディスパッチを返すものと
しました。単一なクラスの生成な場合、省略した書き方ができますので、
var Beep = WSH.CreateObject(getResource("vcode"), "VB").Create("Beep");
という記述でVB.NETのコードをコンパイルしてBeepクラスを利用可能です。

737
hidebouu[sage]   投稿日:2013/10/29 08:54:46
WSHに.NETコードが書けるということは、アンマネージプロセス中にマネージ
空間を生成して、メモリ中でコンパイルし、生成されたクラス定義をこんどは
アンマネージ空間で生成可能としなければなりません。この辺は公式には解説
されていない部分だと思いますが、見ての通り実現可能です。ただし、実行可
能となるまで、ユーザーの気をそらして時間を稼ぐ必要があるでしょう。

738
hidebouu[sage]   投稿日:2013/10/29 11:30:44
WSH主導でIEを外部のURLへナビゲートし、正しくドキュメントスレッドの
HWNDへ低水準イベント発生メッセージを出せば、ブラウザ型ロボットの動作
をWSHで記述できる状態となります。定時な監視も、定時な送信(書き込み)
も可能となるわけです。ただし、これには倫理的な問題が絡んできます。

739
hidebouu[sage]   投稿日:2013/10/29 18:24:22
とりあえずWSH中から
var browser = WSH.CreateObject("InternetExplorer.Application", "about:blank");
var document = WSH.CreateObject("Html.Application", "about:blank");
を可能にして実験しています。後者はmshta.exeを起動しドキュメントを返す
仕様ですが、アプリケーションセキュリティーのWebBrowserを独自EXEで生成
した方が、マニフェストにCOMDLLを定義できる分だけ有利かも知れません。

740
hidebouu[sage]   投稿日:2013/10/29 18:43:26
1.EXE起動->DLLレジストリ登録->拡張IE起動->(必要なら拡張WSH起動)
これをHTML5を意識したHtmlApp手法として

2.EXE起動->拡張WSH起動->通常IE起動->WSHによってIE操作
これをブラウザ型ロボットとします。また、

3.EXE起動->拡張WSH起動->EXEによるWebBrowser生成->WSHからWebBrowser操作
この手法をHTABOXとするのがいいと思います。3つの手法のうちレジストリに
DLLの登録が必要なのは最初のものだけで、後はサイドバイサイドが可能です。

741
hidebouu[sage]   投稿日:2013/10/30 09:56:31
重箱の隅をつつくような技術的な追求を繰り返しましたが、おぼろげながら
イメージしている目標はHTMLとスクリプトでアプリケーションを生成し必要
によっては、コードを隠蔽できる環境なわけです。それを一方向なツールで
提供するよりも、複数のツールの組み合わせで柔軟な使い方ができるとした
方が理解しやすいでしょうし、提供もしやすいと考えています。

HTML Application System というような総合的な概念を提供する方向で考えて
います。HTML+Scriptにこだわる理由の一つに、プログラム自体をプログラム
が生成する試みへ最も順応性が高いのではないかというもくろみがあります。

742
hidebouu[sage]   投稿日:2013/10/31 09:26:00
メニュー等のネイティブコントロール定義をXMLで記述する方式に改めようと
考えています。HTML中に記述するとコードが混乱する点、IEを含めて一般化
した場合、HTMLドキュメントと、コントロールを乗せる親フレームが別プロセ
スであるために細かな通信が困難である点からです。メニュー、ツールバー、
ステータスバーをXML定義したHTABOX手法(HTA互換ウインドウ)のデモを本日
中に公開できればと考えています。

743
hidebouu[sage]   投稿日:2013/10/31 10:03:18
昨日は本物のHTAウインドウをプロセス内に生成してドキュメントウインドウ
の位置を親フレームに対して任意な相対位置へ表示するコードを研究しました。
これによりsingleInstance以外はHTA:APPLICATIONで定義された設定がそのまま
反映されることになります。

結局、それがウインドウである限り逃れられないAPIのメモリアドレスを特定
し、独自コードにジャンプさせる方式が最も普遍的且つ高速であるという結論
に達しました。このテクニックであらゆるHTMLウインドウ上で、追加したネイ
ティブコントロール分だけドキュメントを逃がした表示が可能となります。

744
hidebouu[sage]   投稿日:2013/10/31 21:19:28
http://kuroda.bglb.jp/htabox/htmlapp2.zipを公開します。これは単独HTA
によるメニュー、ツールバーに特化したデモンストレーションセットです。

HtmlApp.exeを起動すると、ファイルダイアログが表示されますから、添付
test.htaを選択してください。XMLディレクトリのXMLファイルを参照して
メニューとツールバーが生成されます。メニューは階層構造と、ラジオチ
ェックをサポートします。ツールバーもラジオチェックをサポートします。

ステータスバーは土壇場でボツとなりました。HTAのウインドウとステータス
バーは相性が悪いというのが原因です。ステータスバーを重視しるなら、別
手法のウインドウとすればいいのですが、今回はHTAにこだわってみました。

745
hidebouu[sage]   投稿日:2013/11/01 10:17:56
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。
HTAウインドウにおけるステータスバーに対応しました。XMLディレクトリの
Stat.xmlにより任意な分割が可能です。現状ではツールバーのツールチップ
を先頭領域に表示しています。最新IEを使わないHTMLアプリケーションのベ
ースウインドウはHTAを採用する可能性が強くなりました。

746
hidebouu[sage]   投稿日:2013/11/01 21:12:12
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。
HtmlApp.exe起動後のファイルダイアログでdemo.wsfを選択するか、HtmlApp.exeへ
ドロップして起動してください。このWSFは単純に同じHTMLファイルを3種類の
異なるHTMLウインドウで表示します。最後のIEはメニュー、ステータスを表示
せず、ウインドウ下部に独自ツールバーを出すものみとしています。

WSHは起動時にDLLのインジェクションで拡張されていますからコードは単純です。

var WSS = new ActiveXObject("WScript.Shell");
var DIR = WSS.CurrentDirectory; var HTML = "test2.htm";
if(WSS.Popup("HTAウインドウの起動", 0, "", 1) == 1) WSH.CreateObject("Html.Application", DIR + "\\" + HTML);
if(WSS.Popup("WebBrowserの起動", 0, "", 1) == 1) WSH.CreateObject("Browser.Application", DIR + "\\" + HTML);
if(WSS.Popup("InternetExplorerの起動", 0, "", 1) == 1) WSH.CreateObject("InternetExplorer.Application", DIR + "\\" + HTML);

747
hidebouu[sage]   投稿日:2013/11/01 21:21:06
結果的にHtmlApp.exeは、独自にCOM拡張されたcscript,wscript環境、HTA,
WebBrowser環境、IE実行環境を提供します。また、WSH側から3つのウインドウ
を自由に生成可能で、HTMLウインドウ側のスクリプト起点でWSHを外部スクリプト
として実行することも可能です。この内、レジストリにCOM登録が必要なのは
IE起点でWSHを実行する時のみで、ほかのパターンはサイドバイサイドで実行
可能です。

748
hidebouu[sage]   投稿日:2013/11/01 22:17:32
いつもながら手前味噌ではありますが、包括的で柔軟性に富むWindowsOS上の
HTML操作ライブラリを確立できた気がしております。遅々として進まず、この
板趣旨にそぐわないのではない局面もあったと思いますが、暖かく見守ってい
ただいた事に、心より感謝申し上げます。

749
hidebouu[sage]   投稿日:2013/11/02 10:24:22
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。
NULL親のHtmlDialog生成機能を追加しました。HTAほど大きなウインドウではなく
センタリングされている事が好ましい場合には重宝するかも知れません。

var document = WSH.CreateObject("Html.Dialog", DIR + "\\" + HTML + " resizable:yes");

CreateObjectの第2引数URL後のスペース以降にスペース無しでオプションを
記述します。返却値はHTAと同様にdocumentインスタンスです。

750
hidebouu[sage]   投稿日:2013/11/03 23:28:38
IE以外のトップレベルHTMLウインドウ生成はデフォルトでメニュー等のコント
ロールが生成されますが、自身でサイトをカスタマイズ可能なようにDLL内の
関数として提供する実験を行っていました。

//基底オブジェクトとサイトの報告を受けるメソッドを義務付ける型定義
__interface __declspec(uuid("E04D655B-B119-49FB-AE85-78542ACA9312")) IOleClientSiteWrap : public IOleClientSite
{
public:
virtual HRESULT STDMETHODCALLTYPE SetBaseObjectAndSite(IOleObject *object, IOleClientSite *site) = 0;
};

_COM_SMARTPTR_TYPEDEF(IOleClientSiteWrap, __uuidof(IOleClientSiteWrap));


extern "C" __declspec(dllimport) int HTMLApplicationWithSite(WCHAR*, IOleClientSiteWrap*);
extern "C" __declspec(dllimport) void WebBrowserWithSite(WCHAR*, IOleClientSiteWrap*);
extern "C" __declspec(dllimport) HRESULT STDMETHODCALLTYPE ShowHTMLDialogWithSite(WCHAR*, WCHAR*, VARIANT*, IOleClientSiteWrap*);

#pragma comment (lib, "HtmlLib.lib")

呼び出しEXE側には上記コードを前置宣言するだけで利用可能となります。

751
デフォルトの名無しさん[]   投稿日:2013/11/03 23:51:26
hidebouu、uが1つ増えたな。ところでRAD開発環境を作るつもりはありませんか?

752
hidebou[sage]   投稿日:2013/11/04 18:07:39
お気にとめていたいだいて感謝申し上げます。GUI設計の効率化にRAD開発環境
は必須な存在だと認識しています。ただ、正直申しましてMSE7.EXE(office2003付属)
や、Visual StudioのHTML向けRADを見ますと、これで十分ではないかと感じて
しまいます。独自エンコード機能を含んだソースエディタまでは予定しており
ますが、そこまでの根性は今のところ無いというのが本音でございます。

753
hidebou[sage]   投稿日:2013/11/04 18:31:46
従来、拡張ディスパッチの追加にはwindow.externalを使う手法で来ましたが、
子ダイアログにとってwindow.externalはdialogArgumentsの実体であること
から、execScriptを低水準フックして任意なディスパッチを提供する手法に
変更する実験を行い、おおむね良好な結果を得ました。

たとえばIEのツールバー制御は
window.external.Browser.ToolBar = false;
であったものが
execScript('GET_BROWSER').ToolBar = false;
に変更されます。

754
hidebou[sage]   投稿日:2013/11/05 14:37:22
IEのダイアログだけ前記の手法が通用しないものですから分析したところ、
ダイアログの生成自体が保護された特殊なモードで行われるようです。親
ウインドウには有効ですから取得したUTILにraw_showModelessDialogのよう
に本来のダイアログ生成を行うサービス関数を用意するのが最もスマートと
いう結論に達しました。本来の動作を強引に上書きするよりも選択可能な状
態が望ましいという判断です。

755
hidebou[sage]   投稿日:2013/11/05 17:41:03
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
添付AllDemo.wsfをHtmlApp.exeへドロップすると全種類のウインドウが生成
され、機能を確認できます。この実行には管理者権限が必要です。詳しくは
添付ReadMe.txtをご覧ください。

解説は不十分ですが、WSH連携により.NETコードがパース可能なHTML5環境と
して十分使用に耐えると予測しています。

756
hidebou[sage]   投稿日:2013/11/05 17:49:45
バイナリのサイズでも判りますが、主役はHtmlLib.dllとScriptLib.dllです。
HtmlApp.exeはそれらを適切に呼ぶにすぎません。したがって今後HtaBox.exe
が提供されても2つのDLLは必須となります。デモでIEを起動しない場合レジス
トリには関与しません。HtmlApp.exeにはマニフェストが存在し、非登録なCOM
を使用できるからです。IEのディレクトリにマニフェストを置けば同じ効果が
あるかも知れませんが、あまり美しい選択ではないと考えています。

757
hidebou[sage]   投稿日:2013/11/05 22:07:07
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
HtmlApp.exeで実行する拡張子HTAでのシングルインスタンスに対応しました。

例 <HTA:application ID="hta" singleInstance="yes"/>

ドキュメント生成後のエレメント、アトリビュート判断としましたので、瞬間
的に後続側ウインドウが表示されますが、その方が重複を警告している感じが
出ますし、好ましいのではないかと考えています。添付test.htaを複数回ドロ
ップすれば、動作を検証できます。

758
hidebou[sage]   投稿日:2013/11/06 19:03:40
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
HTMLダイアログでのネイティブコントロール使用を可能としました。HTML中
にコントロール定義XMLの位置を<HTML>タグの属性として明示することにしま
した。

<html ctrl="xml">

はHTMLファイル存在位置にxmlというサブディレクトリがあると解釈されます。
ダイアログは定義XMLを別位置としてデモしています。IEのモードレスが、親
の最小化に同期しないのが要修正点ですが、思いのほか軽量に書けたと感じて
います。

759
hidebou[sage]   投稿日:2013/11/06 20:41:59
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
IEのモードレスダイアログ問題を解決しました。また、test.htmに誤りが
あった部分を訂正しました。

760
hidebou[sage]   投稿日:2013/11/06 22:42:16
HtmlApp.exeのポリシーは既存HTA環境用コードがそのまま動くこと、HTMを与え
られたらインストールしてある最新IEでセキュリティーを抑制したHTAモードで
動くことです。拡張子HTA、HTMのファイルをドロップされた場合、または引数
無しで開くファイルダイアログからファイルを選んだ状態がそれにあたります。

761
hidebou[sage]   投稿日:2013/11/06 22:46:17
IE10を分析することにより分散プロセスの優位性、問題切り分けに冠する利便
性を痛感しました。低水準な操作の場合ジャンプすべきアドレスのワンミスで
プロセスはクラッシュし、それに関わるコード全体に嫌疑がかかりますが、そ
ういった憂鬱な状態を回避することができるのです。

762
hidebou[sage]   投稿日:2013/11/06 22:54:42
HTMLによるアプリケーションで最大の問題はスクリプトで実現できない低水準
な動作をどう実現するかですが、.NETクラスライブラリのディスパッチラッパー
としてのJS.NET、また、APIを実装したクラスをディスパッチとして呼べるVB.NET
をスクリプト実行できることは最も現実的な解決策だと自負しています。
拡張子WSFをドロップするか、ファイルダイアログから選べば、子プロセスと
して機能拡張したcscript.exeを実行できます。この機能拡張には各種HTML系
ウインドウを孫プロセスとして呼び出したHtmlApp.exeにより表示する機能が
含まれます。

763
hidebou[sage]   投稿日:2013/11/06 23:02:52
この拡張WSH環境はHTML中のOBJECTタグでも実現できます。この場合コンソール
は不要でしょうからwscript.exeを拡張して起動します。公開されているデモの
独自パースはこれにあたります。既存スクリプトエンジンの拡張にはCOMやAPI
のアドレスを突いた偽装が必須となりますが、デリケートなIE本体プロセスと
は別にスクリプト専用プロセスを持つことは必然的な構造だと考えます。

764
hidebou[sage]   投稿日:2013/11/06 23:15:25
これらの機能を実現しているHtmlApp.dllとScriptLib.dllはC++開発環境へ
向けて開発用ライブラリとしても提供される予定です。また、その使用を
前提とした本格的COMプログラミング解説サイトも構築してゆきたいと考え
ています。

765
hidebou[sage]   投稿日:2013/11/08 08:56:20
IE10のテスト時にcontent="IE=EmulateIE9"を付けたまま行っていたという
単純ミスがありました。これを除いた状態だとexecScriptで蹴られるようで
す。今気づいたのですが、IE10でもHTMLパース時にビヘイビア用名前空間を
無視するだけで、機能としては有効であることが判明しました。UTILという
IDを持ったエレメントを記述するだけというシンプルな規則に変更できると
考えています。

766
デフォルトの名無しさん[sage]   投稿日:2013/11/08 22:58:55
インターネット ゾーンにおける Internet Explorer 11 エッジ モードでの VBScript のサポート停止
http://msdn.microsoft.com/ja-jp/library/ie/dn384057.aspx

http://vbscript.g.hatena.ne.jp/cx20/20130801/1375380329
> 以下のコードは、IE10 では動作しますが IE11 では動作しません。
  略

> これを回避する為には、明示的にドキュメント互換モードを指定する必要があるようです。
> <meta http-equiv="x-ua-compatible" content="IE=10">

ドキュメントモード
↓  VBS  JS  Canvas WebGL
7.0  ○   ○   ×   ×
9.0  ○   ○   ○   ×
10.0  ○   ○   ○   ×
11.0  ×   ○   ○   ○

767
hidebou[sage]   投稿日:2013/11/09 23:31:59
判り易い情報をありがとうございます。大変参考になりました。VBSは事実上
イントラネットかHTAにしか使われていないでしょうから、当然な流れかも知
れません。私の環境ではWSH経由になりますが、外向きURLをパースしてVBSを
追加パースすることも可能ですのですこしアドバンテージとなるかも知れま
せん。

768
hidebou[sage]   投稿日:2013/11/09 23:39:42
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。これはバイナリ
ビヘイビアによるツリーとエディットの連携により、3分割されたフレームHTML
のうちtop.htmをbottom.htm内のエディタで編集し、Updateボタンによりleft,
topのHTMLを即座に表示更新するデモです。エディタはIE10対応ですが、ツリー
が未対応なのでWebBrowserを使用しています。

添付main.htmlをHtmlApp.exeへドロップしてください。left.htmのツリーは
top.htm中の見出し(Hnタグ)の階層構造を表示し、クリックした場合の表示
位置ジャンプを行います。

769
hidebou[sage]   投稿日:2013/11/09 23:50:46
IE10はおそらくセキュリティー関連の要求からだと思われますが、自作COMに
よるOBJECTタグに対するReleaseが正しく行われない現象を確認しています。
また、プライマリースレッド上でのHWND生成は行えない仕様となっているよう
です。ところがIHTMLElement2::addBehaviorが有効であることに気づき、バイ
ナリビヘイビア内で低水準な事を行えばよいという結論に達しました。

770
hidebou[sage]   投稿日:2013/11/10 00:42:59
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。今のところ
拡張子HTMでIE、HTMLでWebBrowserという規則にしていますが、main.htmを追
加しました。アプリケーションセキュリティーのIE10はツリーコントロール
とリッチエディットコントロールを内部で生成されたバイナリビヘイビアと
して表示してます。OBJECTではありませんので、レジストリに関与せず、完全
なサイドバイサイドで実現されています。

771
hidebou[sage]   投稿日:2013/11/10 00:54:26
今回のデモはHTMLの編集とプレビューという目的としていますが、IEにエディ
タを埋め込む最大の目的は、外部URLをフレーム中に埋め込みながら、下部フレ
ームHTML中にマクロ動作を記述することを想定しています。つまりそのフレーム
セットをパースすれば自動的にマウスが動き、キーボードが文字を打つために
の試行錯誤としてスクリプトを書いては動かし、修正しては動かす環境という
ことです。

772
hidebou[sage]   投稿日:2013/11/10 11:44:10
非フレームHTMLなら独自ビヘイビア追加は失敗しないのですが、フレームとなっ
ている場合、親が子フレーム数を正確に把握するためにはドキュメント全体の
完成を待つ必要があり、完成してしまってはビヘイビアの追加ができないという
ジレンマに陥る可能性があります。いろいろと調べてはいますが、最も確実な
手法はフレームな場合に一つだけOBJECTを宣言して生成タイミングを監視し、
フレームが自律的にビヘイビアの追加を行うことかも知れません。

773
hidebou[sage]   投稿日:2013/11/10 13:55:39
http://kuroda.bglb.jp/htabox/htmlapp2.zipを更新しました。
main.htaはHTA、main.htmlはWebBrowser、main.htmはIE用です。
left,top,bottomの各HTMLにはOBJECT宣言により独自ビヘイビアが確実に追加
される構造としました。このオブジェクト宣言はフレーム構造のみに必須と
なる予定ですから、単一HTMLな場合は単に
<div id="EDIT" class="EDIT" style="width:100%;height:100%"></div>
でclassを認識して自動的にビヘイビアが起動しエディタが出現します。

774
hidebou[sage]   投稿日:2013/11/10 17:49:10
ちなみにHTAとHTMLモーダルダイアログ上のリッチエディットへフォーカスを
当て、キーでスクロールしようとしてもウインドウ全体がスクロールしてしま
う現象は避けがたい気がします。スレッドが内部でブロックされているからで、
WebBrowserとIEでは発生しません。

また、Win7+IE10の環境だとフレーム分割したHTML上で右マージンが制御できな
いように感じています。これはIE本体では発生せず、それ以外のウインドウで
共通な現象に見えます。

775
hidebou[sage]   投稿日:2013/11/10 21:08:35
IEには埋め込み用の起動オプションが存在するようですので、外郭HWNDを自前
で用意して、シンプルなHTA風なんだけど中身はIEという状態が可能だと考えて
います。本物IEのメニューとツールバーを隠せば等価という考え方もあります
が、現状では後続起動した素のIEが外郭プロセスを共有してしまうためにストー
ルしやすい面がありますので、実験してみたいと考えています。

776
hidebou[sage]   投稿日:2013/11/11 13:30:45
プロセス分離は-nomergeオプションだけで有効なようですから、デフォルトで
これを採用することにしました。埋め込みは-embeddingなようですが、いまいち
動作が安定しない印象がありますので、通常起動してツールバーを非表示とする
手法が適切と考えています。

777
hidebou[sage]   投稿日:2013/11/13 11:08:05
単に-newオプションで起動したIEが共有するプロセスは親フレーム側だけと
考えていたのですが、ドキュメント側プロセスでも発生するという事実に気
づいていなかったのが、たまに発生するエラーの原因だと思われます。

-nomergeは一切共有が発生しませんからHTA的な動作には最適なのですが、外
部URLをナビゲートしながら自由な追加機能を実現するには、ここの対策が重
要になると考えています。

778
hidebou[sage]   投稿日:2013/11/13 19:12:17
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
総合的なデモを行うファイル群です。添付ReadMe.txtにもありますが、
AllDemo.wsfをHtmlApp.exeへドロップすると、全種のウインドウで2通り
のHTMLを表示します。現状では開発環境WIN7+IE10でしか検証を行っていませ
んが、IE9、IE8での動作を確認してリリースする予定です。

779
hidebou[sage]   投稿日:2013/11/15 09:48:49
XP+IE8への対応をほぼ終了しました。XPの場合、管理者権限実行が明確にされ
ていませんから、たとえ全権を持ったアカウントでもIEだという理由で特定の
動作が蹴られるケースを体験しました。その場合でも起動親であるHtmlApp.exe
へ依頼すれば要求が実現できますので、機能が削がれることにはなりません。


780
hidebou[sage]   投稿日:2013/11/15 23:21:45
IE8への対応を完了しました。バージョンによる若干の差異はあるのですが、
それよりもスペックの異なるPCで動作を検証することにより、CPUパワーで
見えなかった不安定要素が浮き彫りとなったことが収穫でした。公開は明日
行いたいと思います。

781
hidebou[sage]   投稿日:2013/11/17 15:31:15
素なIEが既存した場合の動作がすっきり解決できていないことに気づきました。
試さなければならないケースが多岐に渡りますので、すこし時間がかかるかも
知れません。最も単純な解決策は「既存IEを一旦閉じてください」という警告
を出すことですが、それはできる限り避けたいと考えています。

782
hidebou[sage]   投稿日:2013/11/22 21:25:15
IE8,9,10での動作検証を終了しました。既存IEの問題は私の勘違いで独立
プロセスを宣言する-noframemergingが正しく認識されていないという落ち
でした。デモをすこし実用的なエディタとして、それを使いながらヘルプ
の草案を書いています。機能が多岐にわたりますので、混乱を生じさせない
説明が何より重要になるだろうと考えています。

783
hidebou[sage]   投稿日:2013/12/02 14:06:41
ついでですから、Win7の32bit環境ではありますが、IE11での動作実験を行って
います。ユーザーエージェントに例のMSIEという文字が無いのでバージョン識別
に工夫が必要ですが、概ねIE10から大きな変更は無いものと判断します。

HTMLアプリケーションはIE5からIE6の規格で書かれているといると思いますが、
OSのサポート切れでIEは8,9,10,11となり、まもなく9,10,11になるでしょう。
頑としてMSHTAを使うのも手ですが、最新のUIを見慣れたユーザーには古臭く映
るかも知れません。このライブラリを使えば現状のIEを使ったHTMLアプリケー
ションを動作させることが可能です。

784
hidebou[sage]   投稿日:2013/12/02 14:18:07
HTMLページまたはエレメントが非表示な状態でもその描画結果が欲しい時に
IHTMLElementRender::DrawToDCが存在しますが、これはIE10,11でも有効です。
ただし、呼び出しコンテキストがシビアなだけです。本来描画を要求すべき
コンテキストに侵入して呼び出すことがポイントになります。ですから外部
からの呼び出しでは成功しないというのが事実だと推定します。

785
hidebou[sage]   投稿日:2013/12/02 19:59:28
<!DOCTYPE html>を付加してHTML5を明示してもIE11は想定どおりカスタムエレメン
トを描画しますが、MSHTAとWebBrowserに上記HTMLをパースさせると予測を裏切ら
れる結果となります。そこに<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
を追加すると話はもっと複雑になります。まだ詳細な検証を行っててはいませんが、
異なるレンダリングエンジンに対して同じルールを適用しようとして動作が混乱し
ているようにも見えます。

786
hidebou[sage]   投稿日:2013/12/02 21:17:04
IE11がインストールされた環境においてHTAとWebBrowserがcanvasを処理するか
否かをテストしました。

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9"> の場合は
冒頭に<!DOCTYPE html>が存在しないと処理しません。EmulateIE10、11とした
場合は<!DOCTYPE html>なしでも処理するようです。結果的にHTAとWebBrowser
の場合<!DOCTYPE html>はあまり意味を持たず、エミュレート対象のバージョン
指定が重要なように見えます。

787
hidebou[sage]   投稿日:2013/12/02 22:17:26
ちょっと不思議だったので復元ポイントでIE10環境へ戻した場合前述とは異
なる結果となりました。HTA、WebBrowserとも<!DOCTYPE html>は必須で、
EmulateIE9または10とした場合のみcanvasが機能します。恥ずかしながら今
までまじめにこの設定について情報収集したことが無かったので、大変勉強
になりました。

788
hidebou[sage]   投稿日:2013/12/02 22:44:18
SVGにしてもcanvasにしても外部とのイベント伝達はディスパッチ経由となら
ざるを得ません。当然といえば当然でスクリプトスコープでそれを拾う必要が
あるからです。しかし、ボタンクリックのような意思決定ならまだしも、カス
ケードメニューの変化のようにマウス位置へリアルタイムに連動するようなケ
ースでは所詮スクリプトというレスポンスから逃れなれないことを意味します。

789
hidebou[sage]   投稿日:2013/12/02 22:49:47
ですからHTML5によるアプリケーションを目にするようになった場合、決定的
なアドバンテージはマウス等のイベントをいかに低水準なまま処理し、確定し
た場合にディスパッチへ情報を伝達する仕組みになります。それが可能なのは
OBJECTでありバイナリビヘイビアによるカスタムエレメントの設計であるとい
う構図は将来も変わらないと考えます。

790
hidebou[sage]   投稿日:2013/12/04 00:18:05
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。HtmlApp.exeは
単に最新のIEを間接的に起動します。セキュリティー等はデフォルトのまま
ですから外部へのアクセスも安全です。

すべてのページにおいて、ページのロードが完了した時点でマウス位置のエレ
メント枠が赤く表示されます。これは低水準なマウスイベントを起点としてい
ますからスクリプトでonmouse系を拾った場合とは異次元なレスポンスを見せま
す。

いずれかのエレメント上にマウスがある状態のCTRL + Zキーによりexeが存在
するディレクトリに画像がemfとして保存されます。これは意地悪くウインドウ
を小さくした状態でも正確にエレメントの全画像となります。youtube等のサイト
で動画をキャプチャすることも可能です。この際動画を含むエレメントを的確に
指定しなければなりません。youtubeの場合ページ上部の横に長いエリアとなる
ようです。

791
hidebou[sage]   投稿日:2013/12/04 00:30:19
たとえば画像ファイルは右クリックにより保存できますが、ニュース画像と文
章を狙って画像をキャプチャしようとすると、通常は骨の折れる仕事になりま
すが、これを使用すれば一発でエレメント領域を画像として保存できます。
勿論BODYまたはHTMLを選択すればページ全体が保存されます。

現状ではIE11による動作を確認していますが、明日IE8までの検証を行う予定
です。例によってよそ様がどんな機能のソフトを書いているか不勉強なのです
が、安定度が増せば十分に世界を驚愕させる可能性のある機能だと予測します。

非表示で画像取得ができますから、マクロによる定時取得にも対応できます。

792
hidebou[sage]   投稿日:2013/12/04 12:36:46
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
既存ドキュメントプロセス内でのHWND生成に対応しました。従来は同一タブ内
でドキュメントが変移した場合補足しきれないケースがありましたが、その点
を改善しました。また、youtubeサイトの全体画像を取得した場合はブラウザの
表示と異なった内容となりますが、これはサイトのHTML側に要因があると判断
しています。エレメントのDOM階層とゼットオーダーが一致しない場合、そうい
った事がおこるかも知れません。

793
hidebou[sage]   投稿日:2013/12/04 20:08:32
非表示エレメント描画の技術的ボーダーラインはIE9とIE8の間にあるようです。
描画とスレッドに関する考え方が異なるように見えます。先を見据えた設計と
しますので、IE8の場合は機能が限定されるという仕様になりそうです。非表示
で全画像を生成し、部分を切り出すこともやぶさかではありませんが、この画像
キャプチャ機能はIE9以上を推奨する予定です。

794
hidebou[sage]   投稿日:2013/12/05 08:43:46
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。
IE9までの動作を確認しIE8向けに直接DC取得モードを追加しました。
CTRL + Z は通常の画像取得コマンドです。
CTRL + X は表示されているHWNDのDCからエレメント領域を切り出します。
CTRL + C は前記動作で枠表示が邪魔な場合に枠を一時的に非表示とします。

IE9以降でもフラッシュのレイヤーが多重な動画は素直に画像が取得できない
ようですのでCTRL + Xを活用することにより取得できます。ただし、これは
非表示での定時取得には向かないことになります。

795
hidebou[sage]   投稿日:2013/12/05 09:03:14
以前からそう感じていましたが、ネイティブな言語以外は気の利いたことを書
けば書くほど重くなります。これは原理上いたしかたの無いことです。ですか
ら「他人ができないこと」イコール「動作が重い」になります。DHTMLや.NET
で独自なメニューを書くことを想定すれば理解できると思います。結果的に
ソフトウェアは横並びな状態となり、その分野でフリーなものが存在すれば
それだけでビジネスにつながりにくいという現象が起こります。

796
hidebou[sage]   投稿日:2013/12/05 09:12:03
私の目指すところは、「優秀なサンデープログラマーの量産」ではなく、自身
の努力と叡智で「ビジネスできる独立したプログラマー」の誕生ですから、
そういった風潮を利してネイティブならではのパーツを提供することにより
誰でも書ける領域に対して決定的なアドバンテージを確立することにあります。

やや過激な表現になりましたが、そうでなければ「ソフトにお金を払う」とい
う行為は起こらないからです。ソフトウェアなど黙って眺めていればそのうち
フリーで優秀なものが出るに違いないという考えを打ち砕くことが重要です。
コメント1件

797
◆QZaw55cn4c [sage]   投稿日:2013/12/05 12:34:39
>796
うーん‥‥

798
hidebou[sage]   投稿日:2013/12/05 22:43:36
私の考えはピントがずれていると考える方が多いと思います。それは正常な
反応です。Javaや.NETの場合はかりそめにも逆コンパイルをしなければその
構造を分析することはできませんでしたが、純粋なHTML5となれば難読化程度
しかオリジナリティーを守る手段はありません。つまりスタンドアロンなア
プリケーションとしてはビジネスにつながりにくい宿命を背負います。

単に利用する側にとればメリットなのですが、作る努力を考えた場合、その
努力に見合う報酬無しに人は育たないだろうというのが私の直感です。

799
hidebou[sage]   投稿日:2013/12/05 23:41:34
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。IE8への対応に
気をとられてIE9以上で動画のスナップショットが取れない状態となっていま
した。その点を修正すると同時に、生成画像をPNG形式へ変更し、ファイル名
は日時を表現したものとしました。

800
hidebou[sage]   投稿日:2013/12/06 00:00:13
話題は恐ろしく飛躍してしまうのですが、ことパーソナルコンピューターと
人間の係わり合いを考えたときに「個々の人間の知力は退化した」ことを明
確に感じます。便利になる->ただ利用する->退化するの図式です。

オリンピックの大会記録は更新され続けるでしょうが、人類全体を考えた場
合の運動能力は退化し続けるでしょう。HTML5で大抵の目的が達成されるとす
ればそれ自体は喜ばしいことですが、プログラミングの本質的な部分、知的財
産としてのプログラミングという領域はOS提供側の秘密になり、多くのプログ
ラマーは決められた砂場でお砂遊びをさせられたあげく、使い捨てられるとい
うことにならないでしょうか?

私がいささか考えすぎているとしても、このように斜めに世に中を見る人間が
いることも、バリエーションの一つとして意味があるのではないか程度には思っ
ています。

801
hidebou[sage]   投稿日:2013/12/06 10:00:15
HtmlApp.exeはIEブート時にHtmlLib.dllをインジェクションします。また、
HtmlLib.dllは生成されるIEの新たなプロセスを自動識別し自身をインジェ
クションします。これによりIEは自由に制御可能なCOMオブジェクトとして
扱うことが可能になりました。

で、今回付け足したキャプチャ機能をDLLとしてパッケージ化すべきなのか、
EXEとしてブートインスタンス側で表現可能なのかを検討しています。これは
このライブラリをC++環境で利用する場合の約束事(インターフェース)を決
定することに他なりません。

802
hidebou[sage]   投稿日:2013/12/06 22:29:20
http://kuroda.bglb.jp/htabox/htmlapp.zipを更新しました。キャプチャ機能
をCapture.dllに集約することにより3つのファイルで構成されています。

異なるプロセス間でHWNDのサブクラスが成立するかが焦点でしたが、これは
やはりコンテキスト的に無理があるようですから、DLLによるユーザーコード
の追加となりました。DLLはCOMとしてドキュメントの生成過程にコンストラク
トされる必要がありますので、スクラッチIDLによるCOMDLLとしています。

803
hidebou[sage]   投稿日:2013/12/07 10:26:52
あらためてIEの優位性を確認してみました。単純にGoogleをホームページと
して、各ブラウザが占有するメモリ量を比較してみます。(Win7 32bit)
Google Chrome 3プロセス構成 85Mb
Mozilla Firefox 1プロセス構成 64Mb
Internet Explorer 2プロセス構成 40Mb
これは当然といえば当然でIEは非公開なAPIを使って、またはOSの特性を利して
他社では実現できないコンパクトさを実現しています。これは時間の揺らぎに
敏感な音楽を再生したときに顕著に現れます。ですからHTMLによるアプリケー
ションの環境として最も高性能なのはIEだと推定します。

804
hidebou[sage]   投稿日:2013/12/07 10:34:27
COMプログラミングの本質は既存バイナリコードを再利用することです。もっと
極端な言い方をすれば「できるだけコードを書かずに他人のモジュールを操る」
ことです。ですから、何をターゲットとして書くのかによりまったく異なる内容
となります。したがってCOMでのHello Worldは存在しません。そのことが、C
は書けるけどC++は...につながりC++は書けるけどCOMは...を生む要因になって
いるのでしょう。

805
hidebou[sage]   投稿日:2013/12/07 10:49:53
ですからMSHTMLをターゲットとしたCOMによるHello Worldを提示することは
意義のあることだと考えます。IEさえ新しければ<!DOCTYPE html>とEmulateIE9
でHTML5を認識したパースとなるはずですので最も単純なモーダルHTMLダイアログ
の生成とその拡張を題材として入門者向けな解説が書けるのではないかと考えて
います。

ただし、COMプログラミングの強力さは既存VTBLのすり替えによるCOM的フック
に代表されるように高い倫理感が求められますので、それを理解できる方に
見ていただけるような工夫が必要になるだろうと思います。

806
hidebou[sage]   投稿日:2013/12/07 11:06:37
MSHTMLを自在に操るということは、WEB経由な作業を自動化することにもつなが
ります。たった一つのPCで数十のインスタンスが自動的に情報収集を行い加工し
送信することも可能です。従来は集団でなければ成し遂げられない事が個人で
実現可能となるでしょう。サーバーという受動的な立場では従来から自動化は
行われてきましたが、クライアントという能動的な立場でもそれを実現可能に
するわけです。

807
hidebou[sage]   投稿日:2013/12/07 11:20:17
HTA環境のカスタマイズに端を発してHTABOXを書き、その行く先を定めるために
WindowsOSとその中に存在するMSHTMLについて研究を続けてきましたが、もし
4つめのスレッドを作らせていただけるとすれば、表題自体を変えようと考えて
います。私が書くのはWindowsOS上で各種HTMLウインドウを生成するライブラリ
ですので、そういったライブラリに興味をお持ちな方の目に留まりやすいもの
を考えています。

808
hidebou[sage]   投稿日:2013/12/07 17:07:41
COMによるHelloWorldを検討してみました。下記コードはHTMLダイアログを生
成し、H1タグでHelloWorldと表示します。(全角空白は半角に変換のこと)

#include <windows.h>
#include <comdef.h>
#include <urlmon.h>
#pragma comment(lib, "urlmon.lib")
#include <mshtmhst.h>
_COM_SMARTPTR_TYPEDEF(IHostDialogHelper, IID_IHostDialogHelper);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
  try
  {
    CoInitialize(NULL);
    _bstr_t url = "javascript:document.write('<html><body><h1>Hello World</h1></body></html>');document.close();";
    IMonikerPtr m; CreateURLMoniker(NULL, url, &m);
    IHostDialogHelperPtr Dlg(CLSID_HostDialogHelper); Dlg->ShowHTMLDialog(NULL,m, NULL, NULL, NULL, NULL);
  }
  catch(...)
  {
    MessageBox(NULL, TEXT("Unknown Error"), TEXT("Hello World from COM"), MB_SYSTEMMODAL);
  }
  CoUninitialize();
  return(0);
}

809
hidebou[sage]   投稿日:2013/12/07 17:14:41
IHostDialogHelper::ShowHTMLDialogはモーダルダイアログを生成します。
したがってプライマリースレッドでメッセージを拾う必要はありません。
例外処理を行わなければもっと短縮できますが、CoUninitializeは_com_ptr_t
の消滅後に行われる必要があり、親スコープに置いた方が自然なことから
例外処理を行っています。

810
hidebou[sage]   投稿日:2013/12/07 17:25:08
もしCOM無しにHTMLをパースしたウインドウを自前で生成するなら、少なくとも
10Mb程度のソースを書く必要があるのでは無いでしょうか。さらにそのバグ出し
までを考慮した場合絶望的な気分になります。しかし現実には十分に実績があり
バグの枯れたCOMインターフェースが口を開けて待っていてくれています。
しかも、Foxを書いているチームがいかに優秀だとしてもWindowsの内部情報を
知りえない限りこれを超えるHTMLウインドウを生成することは不可能なのです。

811
hidebou[sage]   投稿日:2013/12/07 17:36:56
私自身、勉強を始めて2年くらいは上記モーダルダイアログでは、カスタマイズ
の余地が無いように勘違いしていました。制御が返るということはダイアログ
が閉じられたということだからです。しかし、それは大きな間違いでした。

ウインドウの生成はWindowsのシステムインスタンスとの通信無しには成立
しません。したがってプライマリースレッドへ到達するメッセージをフック
すればWM_CREATEを監視できます。また、IOleObject::SetClientSiteをCOM
フックしておけば基底のサイトをカスタマイズすることも可能です。

812
hidebou[sage]   投稿日:2013/12/07 17:55:07
HTML5への対応をテストしてみると、IHostDialogHelper::ShowHTMLDialogでは
パースできないようですね。RunHTMLApplicationでHTAウインドウを生成すれば
<canvas/>も問題なく表示されるようです。RunHTMLApplicationの呼び出し方
を公式にドキュメントしない理由は不明ですが、そこをDLLで隠せば怒りに触れ
ることもないだろうと考えます。

813
hidebou[sage]   投稿日:2013/12/07 18:55:14
//インプロセスHTAウインドウによるHelloWorld
//HtaHelper.dllとHtaHelper.libはhttp://kuroda.bglb.jp/htabox/htahelper.zip

#include <windows.h>
#include <comdef.h>
extern "C" __declspec(dllimport) int RunHTMLHelper(WCHAR *url);
#pragma comment (lib, "HtaHelper.lib")
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
  try
  {
    CoInitialize(NULL);
    _bstr_t url = "javascript:document.write('<html><head><title>hello</title></head><body><h1>Hello World</h1></body></html>');document.close();";
    RunHTMLHelper(url);
  }
  catch(...)
  {
    MessageBox(NULL, TEXT("Unknown Error"), TEXT("Hello World from COM"), MB_SYSTEMMODAL);
  }
  CoUninitialize();
  return(0);
}

814
hidebou[sage]   投稿日:2013/12/07 19:06:26
間接的に呼び出されているRunHTMLApplicationはモーダルダイアログのように
ウインドウが閉じられるまで制御を返しません。ダイアログとの決定的な違い
はプロセスの寿命中に2回呼び出してはいけないという事です。あくまでも
メインなウインドウとして動作することを前提に設計されていることが要因
だと考えられます。

815
hidebou[sage]   投稿日:2013/12/09 11:54:20
RunHTMLHelper(WCHAR *url)をRunHTMLHelper(WCHAR *url, IUnknown *site)
に変更し、第2引数に対して必要して十分な情報が報告されるとすれば、私の
数年にわたる研究を極めて抽象的に集約することができます。これをHTMLApplicationSystsem
の中核となるインターフェースと位置づければWebBrowserもIEも同様な仕様で
情報の収集と拡張ができると考えます。

この手法のメリットはどう情報を収集しているのかを公開する必要が無いことです。
IE、MSHTMLを設計管理している側にとって見れば生成される情報を先取りされて
自由にされることを好ましくは思わないでしょうから、末永くこのライブラリが
存続するためにも適切な判断だと考えます。

816
片山博文MZコスモ ◆T6xkBnTXz7B0 []   投稿日:2013/12/20 13:55:00
hidebouさん、こんにちは。

ところでHTAアプリをJavaアプレットのように別プロセスのウィンドウに埋め込んで実行できませんか?
SetParent APIを使うなどして

817
片山博文MZコスモ ◆T6xkBnTXz7B0 [sage]   投稿日:2013/12/20 15:01:57
それと、WS_CHILDスタイルをSetWindowLong APIで設定するんだった

818
hidebou[sage]   投稿日:2014/01/26 10:40:42
片山さん、ありがとうございます。
「Javaアプレットのように」埋め込み対象がMS系HTMLウインドウなら何でも
可能です。埋め込み対象がFox等だった場合OBJECT経由とすれば可能だと推
定しますが、まだこの手の実験は行ったことがありません。

819
hidebou[sage]   投稿日:2014/01/26 10:48:37
もし、別プロセスのウインドウが、Visual StudioやofficeのようにHTML系で
なく、OLEコンテナでも無い場合は「埋め込み」ではなく、重ねることなら可
能でしょう。もうすこし具体的な要求が分かればお力になれるかも知れません。

820
hidebou[sage]   投稿日:2014/01/26 10:57:43
今のところC++系の記事がメインですが、ロボット用ではないブログアカウント
を作ってみました。お時間がありましたら眺めていただけると幸いです。
ここのブログCGIは、他社に比べCDOで生成したMHT形式メールをブログとして
再現可能ですので、従来のブログというイメージを払拭したページとできます。
いつものように「妄想爆発」してますが、ここがおろそかになっているのは
そういう理由からです。

hide-bow.jugem.jp/

821
hidebou[sage]   投稿日:2014/01/26 11:35:03
XMLとHTMLを整形したRTFファイルに変換するツールをまもなく公開します。
プログラム主体なHTA等ならVisual Studio系エディタで何の不満も生じない
のですが、ヘルプのように表示文字主体なHTMLを書く場合、編集時に一定
文字数でPタグ等の内容文字列だけが折り返されるエディタを実現しようと
いう趣旨です。RTFの規格にはテーブル、セルという概念がありますので、
それを実現できるようです。ただし、整形やノードの判断はSAXで行います
から、XMLは当然のことながらHTMLも整形XML規則であることが条件です。

822
hidebou[sage]   投稿日:2014/01/26 18:37:07
kuroda.bglb.jp/sax/saxeditor.zipをリリースします。
XML中のCDATAとHTML中のP内#textを編集しやすくしようというツールです。
フォント等の設定は投げやりなままですが、一旦RTFにすればワードパッド
でも編集できるのでいいだろうという無責任さが根底に見え隠れしています。
スクリプト主体ならこういうのは必要ないですが、取り扱い説明を書くとき
には意外と便利かも知れません。私はこれをメモ帳代わりにして、老化によ
る物忘れの激しさをフォローしようと思っています。あらゆるものを詰め込
んで「あれを見れば全部ある」というデータベースにするためです。

823
hidebou[sage]   投稿日:2014/01/26 22:10:01
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
機能的な変化はありませんが、ヘルプウインドウにメニューによる目次が付加
されました。

824
hidebou[sage]   投稿日:2014/01/27 00:21:48
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
RTFを開いてXMLにできないという初歩的なミスを修正しました。XMLエディタは
MS純正の高機能なものがあるようですが、本エディタの真の目的はプログラム
が動的にHTMLを生成するためのエンジン部分の検証です。従来ロボットがブログ
に書き込んでいたのは単純な文字列とリンク程度でしたが、動的に収集した
情報を加工して人間であるかのように振舞うには、XMLによる情報源からの
部分エレメント抽出が不可欠だろうと直感しています。

825
hidebou[sage]   投稿日:2014/01/27 07:22:52
そう書いて実現せずにはいられない性分ですので、クリップボードイーター
機能を付加したいと思います。構想としてはCF_BITMAPをGIF等の指定画像形
式ストリームでBASE64文字列に、CF_TEXTは文字列として貪欲にXMLを増殖さ
せてゆく機能です。ネットを渡り歩いている時に「コピー」という操作をす
れば、「保存」や「貼り付け」を行わずとも情報が蓄積されていることにな
ります。

826
hidebou[sage]   投稿日:2014/01/27 22:40:51
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
単に起動してツールバーにある「目」のボタンを押しておけば、文字、画像
をクリップボードから自動的に収集してXML化します。デフォはANSIですから
UTF-8変換保存すると画像が乱れるおちゃめな部分はあるのですが、一応動き
そうなので公開しました。

827
hidebou[sage]   投稿日:2014/01/28 12:25:53
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。ヘルプ用ウインドウを
スクリプトから単独利用可能としました。exe単体で動作しますから、ファイル
名を変更して自身のアプリケーションに使っていただいて結構です。詳しくは
添付HelpOnly.wsfをご覧ください。起動スクリプトの例を示します。

var WSS = new ActiveXObject("WScript.Shell");
WSS.Exec(WSS.CurrentDirectory + "\\saxeditor.exe help").StdOut.ReadLine();
var Wins = new ActiveXObject("Shell.Application").Windows();
var Disp = Wins.item(Wins.Count - 1);
Disp.OpenHelp(WSS.CurrentDirectory + "\\help", "help.rtf");

828
hidebou[sage]   投稿日:2014/01/28 12:39:36
ShellWindowsへの登録反映より早くExecが制御を返すので、EXE側がcrlfを
標準出力するのを待機していますが、その他は当たり前な展開かと思います。

単にTOMを取得してファイルを開くこともできますが、OpenHelpの場合、
メニューへの目次生成、画像埋め込み、文章中のハイパーリンクが有効
となっています。構造化されたヘルプは必要ないが、素のテキストでは...
というような局面で便利かと思います。

829
hidebou[sage]   投稿日:2014/01/28 20:18:32
画像のBASE64文字列はあくまで長い一行として処理したいのですが、UTF-8変換
時に長大な文字列が来ると一定間隔で未定義キャラクタ扱いされる部分が発生
してしまうようです。UTF-16及びANSIでは発生しませんから、最悪の場合一旦
UTF-8以外で出力して、全データをUTF-8で再評価するアルゴリズムとするかも
知れません。現状では画像取得後のUTF-8XML評価で画像データが乱れます。

830
hidebou[sage]   投稿日:2014/01/29 07:41:43
改めて考えてみるとShellWindows最終ウインドウからのディスパッチ取得手法
が失敗するのは見たことが無いので、これが最もシンプルなC++によるスクリ
プトへのCOMオブジェクト提供サンプルにふさわしい気がします。UTF-8問題
解決後に、ブログで解説をしたいと考えています。

831
hidebou[sage]   投稿日:2014/01/29 11:59:29
リッチエディットのUTF-8問題の根源はリッチエディットがUTF-8をパースする
時BOMの存在に依存しているからのように見えます。したがってUTF-8を開く
動作を自前な動作に上書きしてMultiByteToWideCharした後のUTF-16をドキュ
メントへ転送すればいいような気がします。もし、そうだとしたら常にその
動作にしたTomExというラップクラスを提供すると喜ばれるかも知れません。

832
hidebou[sage]   投稿日:2014/01/29 21:49:33
HTML系のCOMインスタンスは原則として生成時のラップを行わないとコンテキ
ストの不一致からハングしますが、ITextDocumentの場合は単純にVTBLの16番
と17番の行き先を同一型関数へ誘導するだけで、機能変更可能でした。この
てこ入れで解決してくれればいいのですが、まだ結果が出ていません。

C++の場合こうやって既存COMオブジェクトを自由にカスタマイズできますので、
私のようにあきらめの悪い人間にはぴったりな環境です。

833
hidebou[sage]   投稿日:2014/01/30 11:41:19
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
UTF-8問題を解決できたと思います。このアプリケーションのクリップボード
監視機能により、WEB上をブラウジングしながら、画像、文字列を簡単に収集
し、単一XMLファイルとして保存、管理、利用できます。IEによる画像クリップ
アプリケーションをリリースする時は、この保存エンジンが使われるでしょう。
画像がとっちらかることは無く、常にXPath検索が有効となるわけです。

834
hidebou[sage]   投稿日:2014/01/30 11:54:13
本体EXEはスクリプトからヘルプ用RTF表示ウインドウとして利用可能ですが、
DLLの方は、ウインドウレスリッチエディットを利用してスクリプトからRTFの
作成が可能となる設計としています。まだ、レジストリへの登録機能は有して
いませんが、SAX2によるXMLの整形、整形状態でのエレメント、属性、値のRTF
表現はこのDLL内で行われています。

835
hidebou[sage]   投稿日:2014/01/30 14:29:18
C++生成インスタンスをスクリプトへ提供するサンプルを公開しています。
hide-bow.jugem.jp/

また、ブログでの解説で使ったCPP、EXE、WSFをzipにして
kuroda.bglb.jp/sax/comsample.zip
に置きました。コンパイルして遊んでいただければ幸いです。動くサンプル
があると、拡張への意欲がわいてくるものです。スクリプトで無理難題を解
決しようとするより、たったこれだけのコードでC++的な解決方法へ導くこと
ができます。一見の価値はあると思います。

836
hidebou[sage]   投稿日:2014/01/30 15:08:56
プログラミングというくくりで考えると矛盾するのですが、スクリプトとネイ
ティブに分ければ、私の考えを分かりやすく説明できることに気づきました。
スクリプトは誰でも書けて、便利なように今後も進化して行くでしょうし、
結果としてJavaや.NETも必要なくなる日がくるでしょう。HTML5によってそ
れはもう来ているのかも知れませんし大歓迎なことです。

837
hidebou[sage]   投稿日:2014/01/30 15:17:40
ただし、これは根拠の無い直感なんですが、スクリプトでは飯が食えません。
「賢い人」と思われることはできても「生活の糧」にはなりにくいのです。
必ず、スクリプトの先を実現したいという要求は存在し続けるでしょうし、
実際にAとBのアプリケーションを比較する場合、純粋なスクリプトでは不可能
な事を実現している方に軍配が上がるでしょう。そういったニーズのために
スクリプト自体を拡張できるプログラマーが必要とされるでしょう。

838
hidebou[sage]   投稿日:2014/01/30 15:31:08
スクリプト自体の拡張というのは多くの場合スクリプトを実行しているエンジン
より上位な権限で行われます。なぜそうできるのかといった情報を広く流布して
しまえば、コンピューターとアプリケーションの世界に混乱を招いてしまう
かも知れません。ですから、後者はしっかりとした倫理観を持った人間でなけれ
ばなりません。そして後者を目指す若者が夢を持ってプログラミングに取り組め
る環境作りが必要なのではないかというのが偽らざる心境です。

839
hidebou[sage]   投稿日:2014/01/30 19:03:55
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
UTF-8指定の開く動作でファイルの冒頭しか認識しない現象を確認して修正
しました。

840
hidebou[sage]   投稿日:2014/01/30 20:16:32
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
CF_TEXTでの生成エレメントをCDATAに変更しました。万が一文字列中に]]>
が存在した場合は}}>に強制変更するルールとし、あらゆる文字列の取得で
XML評価が成功するものとしています。

841
hidebou[sage]   投稿日:2014/01/30 21:32:59
C++生成インスタンスをスクリプトへ提供するサンプルを更新しました。
hide-bow.jugem.jp/

また、ブログでの解説で使ったCPP、EXE、WSFをzipにして
kuroda.bglb.jp/sax/comsample2.zip
に置きました。コンパイルして遊んでいただければ幸いです。従前の物は単に
TOMを提供しましたが、独自にTypeInfo主導型ディスパッチを生成し、その
DISPATCH_PROPERTYGET要素としてTOMを渡しています。つまり、メソッドとして
あらゆるWINAPI処理を提供する原型になり得ます。

842
hidebou[sage]   投稿日:2014/01/30 21:59:45
もう十年くらいスクリプトとCOMについて考えてきましたが、もし誰かこれと
同じサンプルを提示してくれたら、3年くらい早く現状に到達できたのではな
いかと思います。気づいてしまえば見てのとおりなのですが、なかなかこの
ように簡潔なサンプルを目にすることは無いと思います。

843
hidebou[sage]   投稿日:2014/01/30 23:57:50
健全でない言葉が含まれているため表示しません 内容を確認する

844
hidebou[sage]   投稿日:2014/01/31 10:00:12
スクリプトからリッチエディットへハイパーリンクを設定し動的ダイアログ動
作を行うソースコードを公開しました。

hide-bow.jugem.jp/

また、ブログでの解説で使ったCPP、EXE、WSFをzipにして
kuroda.bglb.jp/sax/comsample2.zip を上書きしました。
C++に興味が無い方でもこのEXEを使えばサンプルWSFのように動的な文字列の
選択を促すことができますので、自由に使用してください。本zipは本日中に
公開を終了する予定です。こんな私のことを気にかけてくださる方々へのせめ
てもの御礼と考えております。

845
hidebou[sage]   投稿日:2014/01/31 11:20:39
最終的にはWindows上のHTMLインスタンス制御で「世界で最も巧妙」を目指し
ますが、プログラミングには興味がない一般ユーザーへいかにアピールして
ゆくかという戦略の中で、今回リリースするクリップボードデータベースは
大きな意味を持つと考えます。XMLとして蓄積されたデータの検索、抽出を
使いやすいものとして、その先にあるIEによる自動収集、IE動作をプログラ
ミングすることの利便性、最終的にはHTMLによるアプリケーション競争にお
いてカスタマイズされたHTMLインスタンスを使うアドバンテージを認識して
いただくという展開を考えています。

846
hidebou[sage]   投稿日:2014/01/31 19:29:47
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
実際に数メガ程度の画像データを蓄積して動作させると、よくこんなものを
人に見せていたものだと赤面するほどのプログラムでしたが、各部の見直し
でスムーズな動きになったかと思います。もうすこし軽量化の余地はあるも
のと判断しています。

847
hidebou[sage]   投稿日:2014/01/31 23:03:59
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
変換で負荷がかかっている時の操作を抑制する意味をこめて画像パース時の
プログレスダイアログを追加しました。RTF、XML変換時も同じようなダイア
ログを出す予定です。また、連続動作時のメモリ開放にも潔さがありません
ので、プロセスチェインで抜本的解決を図るかも知れません。

848
hidebou[sage]   投稿日:2014/02/01 22:12:26
kuroda.bglb.jp/sax/saxeditor.zipを更新しました。
データ検索はまだ実装していませんが、クリップボードデータ収集機能は
仕様どおり動くと判断しています。UTF-8はBOM無しに統一していますから
BOM付きをXML変換させると冒頭にエラーを報告しますがこれは仕様です。

849
hidebou[sage]   投稿日:2014/02/01 23:12:44
そういえば、MHTでのHTA動作ができないかと発言された方がいらっしゃたので
すが、WebBorowserをHTAセキュリティーで動作させれば可能です。MHTはCDOで
HTMLから生成できます。ただし、IMGのSRCは添付ストリームのIDに入れ替わり
ますから、扱いにくいかもしれません。単に画像をHTMLファイルに埋め込むな
ら、SRCをBASE64文字列ストリームにする手法の方が扱いやすいと思います。

850
hidebou[sage]   投稿日:2014/02/02 11:44:18
ComSampleとしてソース公開していたExec呼び出しウインドウを機能的に拡張
して永続的に提供することとします。XMLを中軸に置くとUTF-8でのファイル
入出力が多くなりますが、それを軽量にこなす為にリッチエディットは例に
よってBOM非依存に、スクリプトから直接ReadAll、WriteAllでコードページ
指定ファイルIOを可能にします。ヘルプを書くのが面倒なのでIDLのTypeLIb型
ディスパッチとし、タイプライブラリを公開しますが、ソースコードは非公開
とする予定です。

851
hidebou[sage]   投稿日:2014/02/02 17:02:36
http://kuroda.bglb.jp/sax/richconsole.zipをリリースします。
「リッチコンソール」名前です。現在の実装メソッドは下記のとおりです。
FUNC CRichConsole.About() return VT_VOID//ビルドに関する情報の表示
FUNC CRichConsole.AddLinkText(string as VT_BSTR) return VT_VOID//コンソールへリンク文字列を追加します
FUNC CRichConsole.AddText(string as VT_BSTR) return VT_VOID//コンソールへ文字列を追加します
FUNC CRichConsole.ReadAll(path as VT_BSTR, cp as VT_I4) return VT_BSTR//ファイルを指定コードページで読みUTF-16変換して返します
PROPERTYGET CRichConsole.TextDocument return VT_DISPATCH//ITextDocument2インスタンスを返します
FUNC CRichConsole.WaitForLink() return VT_BSTR//リンク文字列がクリックされるのを待ち、クリックされたリンク文字列を返します
FUNC CRichConsole.WriteAll(path as VT_BSTR, string as VT_BSTR, cp as VT_I4) return VT_I4//ファイルをへ指定コードページで作成して書き込んだバイト数を返します

852
hidebou[sage]   投稿日:2014/02/02 17:12:00
http://kuroda.bglb.jp/sax/richconsole.zipには各機能をチェックするWSFが
添付されています。
http://hide-bow.jugem.jp/
ではこのコンソールを使った実用的なスクリプトをご紹介できればと思って
います。自分用ツールを作る場合はHTAよりWSH+リッチコンソールの方が軽量
ですし、是非、活用していただければと思います。 

853
hidebou[sage]   投稿日:2014/02/02 21:00:17
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
JScriptでのSAXによるXML整形をテーマとしたデモが添付されています。
SAXの出力先はIStreamであることから、下記メソッドが追加されました。
FUNC IRichConsole.CreateStreamOnFile(path as VT_BSTR) return VT_VARIANT//ファイルを生成しIStreamのVARIANTを返します
FUNC IRichConsole.StreamCommit(stream as VT_VARIANT) return VT_VOID//IStreamをコミットします

このデモ作成時にリッチエディットのUTF-8BOM除去はかえってエラーの元にな
りましたので、暫定的にTOM経由でのUTF-8入出力はデフォルトの動作です。

854
hidebou[sage]   投稿日:2014/02/02 21:28:28
EXEC経由でのディスパッチ取得では、起動されたEXE側の終了が早期に行われ
た場合、どうするか?とう悩ましい問題があるのですが、現時点では呼び出し
元プロセスを強制終了させるという動作にしています。つまり、クリック待ち
だったwscript.exeはその後動作せずに終了しています。なぜ、BOM除去でエラ
ーとなったのかは、この仕事に対して神様がくれた素敵なヒントだと解してい
ます。原因が単純ミスでなければ、またひとつ賢くなれるかもしれません。

855
hidebou[sage]   投稿日:2014/02/03 00:10:11
ITextDocumentのVTBLハックは生成プロセスでは問題が無いものの、さすがに
異なるプロセスを起点とした要求ではコンテキスト差を吸収しきれず、内部
でのAPIが挙動不審になるといういうのが原因なようです。最も妥当な解決策
はリッチエディット生成をwscript側に送りつけたDLL内で行うことですが、
そんなことをするよりは、まともにCOMDLLとすればいいわけで、簡便な呼び
出しと引き換えに、細かなコントロールはできないと結論付ければ納得でき
そうです。もし、本システムでBOM無し入出力行いたければ、TOM経由ではなく
一旦全文字列取得後にReadAll、WriteAllとすればいいと考えます。

856
hidebou[sage]   投稿日:2014/02/03 08:50:48
WSHの制御については、独自EXE側を起点とし何が可能かは徹底研究済みですか
ら、やや物足らない感はありますが、ファイル系顧問ダイアログ、.NETパース、
画像挿入、HTML挿入くらいは追加しようと考えています。今回は異プロセスと
いう足枷をわざと受け入れた場合の限界を探るということでしょうか。
DLLを送りつけずIShellWindows経由にこだわれば、WSH以外のあらゆるスクリプ
トで、同じように利用できることが約束されるわけですから。

857
hidebou[sage]   投稿日:2014/02/03 11:06:56
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
画像埋め込み、HTMLダイアログ表示を追加しました。メソッド一覧はタイプ
ライブラリ解析結果を添付していますので、そちらをご覧ください。
HTMLの埋め込みは感触がぬめっとしてたのであっさり引き下がりました。

858
hidebou[sage]   投稿日:2014/02/03 11:37:18
http://hide-bow.jugem.jp/で実行結果をご覧いただけます。
HTABOX系の思想根底には「商品としてのアプリケーション」があるのですが、
「自分用ツールとしてアプリケーション」を追求すればこのコンソールのよう
な補助アプリケーションが最もふさわしいのではないかと考えます。その延長
上に「本当は自分用なんですけど、便利だったらどうぞ」という展開があっても
いいでしょうし。

859
hidebou[sage]   投稿日:2014/02/03 12:49:29
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
JS.NET、VB.NETパース機能を追加しました。ファイル、フォルダダイアログ
を追加して、初期リリースとしたいと思っています。

860
hidebou[sage]   投稿日:2014/02/03 20:06:29
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
実装関数を確定し、初心に戻った初期設定デモが添付されています。
フォント、色を関数から設定し、フォント、カラーの各ダイアログを使った
設定も提示しています。TOMは個々のRangeでFont設定可能ですが、デフォルト
の設定をすれば、いちいち設定する必要はありません。

861
hidebou[sage]   投稿日:2014/02/03 20:34:11
メソッドの一覧や、ソースサンプルをこちらに書き込もうとすると、最近は
「長すぎ」と拒否されますので、http://hide-bow.jugem.jp/をご覧ください。
zipにはTypeInfo情報も含まれていますので、動かしながら概ね理解していた
だけると思っています。

862
hidebou[sage]   投稿日:2014/02/03 21:04:31
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
WSHからのPopupは親HWNDが無いのでMessageBoxをラップしたMsgBox関数を追加
しました。引数省略は出来ませんが、確実に表示されます。

863
hidebou[sage]   投稿日:2014/02/03 23:36:13
今までは、HTMLエンジン経由で外界を見てきたのですが、コンソール的手法
によるHTTPやFTPによるデータ取得について、考えて見たいと思っています。
最近のWEBサービスはブラウザのユーザーエージェントを判別して蹴ったり
しますから、ブラウザ経由の方が確実ですが、高速な自動巡航などはこちら
の方が向いていると思います。

864
hidebou[sage]   投稿日:2014/02/04 08:42:38
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
単純なCMD.EXEの出力リダイレクトサンプルを追加しました。
いつも「自分しか見ていないかも?」という閑散としたブログのログがやや
にぎやかになったことに感謝しています。重箱の隅をつつくような一般受け
しないツールでも、多くの方が知るところとなれば、必要と感じていただける
ケースも生まれると思います。

865
hidebou[sage]   投稿日:2014/02/04 10:03:58
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
フォルダ中のファイル列挙による動的生成文字列クリックのデモを追加し
ました。http://hide-bow.jugem.jp/で内容をご覧いただけるようにします。

866
hidebou[sage]   投稿日:2014/02/05 00:24:05
やっぱりリッチエディットコントロールのUTF-8変換は長大なBASE64文字列で
変換不能と判断する文字を一定間隔で報告してくるものですから、その対策
に一日を費やしてしまいました。「結論は自前で書くべき」でした。
引数CP_UTF8で読みに来たら、自前でUTF-16変換した一時ファイルを読ませ、
引数CP_UTF8で書きに来たら、UTF-16で書かせて自前UTF-8で上書きするとい
う手法が正解と判断しています。これらは、内部で自動的に処理されますの
で、ユーザーがそれを意識する必要はありません。

867
hidebou[sage]   投稿日:2014/02/05 09:23:12
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
SAXによるHTML整形のデモを追加しました。これはこのコンソールが生まれる
原因になった動作ですので歴史的に意味があります。(内輪の話ですが)
内容はhttp://hide-bow.jugem.jp/で内容をご覧いただけるようにします。

UTF-8問題の解決は、私に勇気をもたらしました。おそらくこの問題を解決
できていないリッチエディットコントロールを使っているプログラマーに対
して明確なアドバンテージとなるからです。

868
hidebou[sage]   投稿日:2014/02/05 11:21:00
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
ユーザーの文字列入力取得用にプロンプトダイアログを追加しました。

[helpstring("プロンプトダイアログを表示します")]
HRESULT STDMETHODCALLTYPE ShowPromptDialog([in]BSTR msg, [out,retval]VARIANT *v);

これに伴い添付005.wsfの内容を更新しました。エディタ上のカーソルは途中
経過の取得等で頻繁に使用されるでしょうから、文字列入力という致命的な
操作はダイアログで行うことにしました。

869
hidebou[sage]   投稿日:2014/02/05 13:21:46
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
IStreamのファイル保存機能を追加しました。結果的にあらゆるコードページ
のサーバーレスポンスをコンソール上に表示できます。表示できるということ
は、スクリプトから加工、抽出できるということです。前段は省略しますが、
添付サンプルWSFは下記の動作を行い、当該URL上のレスポンスを表示します。

DISP.MsgBox("GETを開始します", VER, 0);
var HTTP = new ActiveXObject("WinHttp.WinHttpRequest.5.1");
HTTP.Open("GET", "HTABOXコア Part3 ", false);
HTTP.Send();

DISP.AddText("サーバーステータス = " + HTTP.StatusText);
DISP.AddText("\n");

var data = HTTP.ResponseStream;
var path = CUR_DIR + "\\temp.txt";
DISP.StreamSave(data, path);
TOM.Open(path, tomOpenExisting, CP_ACP);

870
hidebou[sage]   投稿日:2014/02/05 16:58:29
上記サンプルはtext/htmlを返すURLへのGET要求ですが、当然画像に対して
GET要求も出せます。その場合、StreamSave関数により画像ファイルが生成
されることになります。ただし、HTMLソースからIMGのSRCを的確に抽出し、
相対URLを解決して自動的なローダーにするまでには、かなりのスキルが
必要になるでしょう。もし世界中のHTMLが整形XMLで出来ていれば一発で
抽出できますから素敵なんですけどね。

871
hidebou[sage]   投稿日:2014/02/05 19:49:08
非整形XMLなHTMLをDOM参照するだけの目的で鈍感なブラウザを作成するのも
いいかも知れません。スクリプトの無効化は簡単にできますし、画像をロード
しない設定もあったように記憶しています。そういったものを用意すれば、
DOMを巡航して要点をXMLに再編成することも容易でしょう。

872
hidebou[sage]   投稿日:2014/02/05 21:52:10
やっと自身の中でもHTML系とTOM系の住み分けができてきた気がします。HTML
系はIE乗っ取り+独自隠蔽スクリプト or ユーザーマクロでロボット動作を
主眼とし、TOM系はWSH等のスクリプトを起点とした自分用スクリプトを軽量
に拡張するツールを目指します。WSH乗っ取りもやりましたが、あれは書いて
いる側の人間(MS)がどのAPIをどの順で呼ぶかの駆け引きが必要ですので、
苦労のわりにはメリットが小さいと考えています。

873
hidebou[sage]   投稿日:2014/02/06 07:01:14
あくまでも私的見解なんですが、やっぱりきちんと技術を買ってもらうという
体勢ができないと開発側の生産性は上がらず、結局サービス自体が消滅すると
感じます。例えばTwitterサービスは同見てもお金にはなりませんから、自身
を維持できずに消滅する運命に見えます。長い目で見ればGoogleもそうでしょ
う。たくさんのアクセスや、知名度がお金に化けるかもしれないというのは
バブリーな発想であって、WEB上では「誰もできないことが出来る」以上に
確かな力は存在しないように思います。

874
hidebou[sage]   投稿日:2014/02/06 07:20:59
例えば数学の世界では新たな定理は無償で公開されます。これ自体は素晴らし
いシステムです。数学者は単に「○○の定理」に自分の名が冠されることを
夢見て没頭する。でもプログラミングの世界はそれとは異なる気がします。
○○のアルゴリズムを発表し、世界中の処理速度が向上したとしても彼か
彼女が天才プログラマー扱いされることは無いと直感するからです。その根源
はプログラマーとは「創造者」ではなく「従業員」であるべきという暗黙の
社会的圧力かも知れません。書けない人間にとって書ける人間ほど恐ろしい
存在はないのですから。

875
hidebou[sage]   投稿日:2014/02/06 07:40:14
とても大袈裟な表現を用いれば「知は誰のもか?」の変革期が訪れていると
思います。「知は公のもの」を推し進めるJavaや.NETは結局主役にはなれず、
AとBを動作させた時の決定的差異を生むネイティブな非公開部分が、コード
量は少ないかもしれませんが主役になっています。
「知は私的なものであるべき」少なくとも、公開の意志が無ければ非公開と
できるということを受け入れて初めてプログラマーは単なる「従業員」ではな
く「創造者」たる地位を確立できるように思います。

876
hidebou[sage]   投稿日:2014/02/06 09:50:58
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
内部でのUTF-8 -> UTF-16変換が洒落にならないほど間違っていましたので
修正しました。コンソールウインドウ自身に「開く」「保存」機能を追加
しました。

877
hidebou[sage]   投稿日:2014/02/06 15:24:54
今回、使われてるUTF-16 <-> UTF-8のコードを公開しています。
http://hide-bow.jugem.jp/

変換自体は単なるビットシフトなんですが、あわててサンプルコードを眺め
にWEBを彷徨ったら、あまりに各人各様な書き方があるのもですから、自分
自身めまいがしましたし、C/C++に不慣れな方はまして悩まれるんじゃない
かと思ったからです。なぜそうなのかという理由も含めて説明しています。

878
hidebou[sage]   投稿日:2014/02/07 10:28:57
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
エディタを経由しない文字列変数のファイル入出力でもUTF-8の場合は独自
関数で処理するものとしました。string.wsfは単純なそのサンプルです。
HTTPやFTPには深入りせずにヘルプを書いて、これでよしとする予定です。
このコンソールは名刺代わりのフリーソフトと位置づけていますから、
すっきりして清潔感あふれる?展開が望ましいと直感します。

879
hidebou[sage]   投稿日:2014/02/07 11:37:17
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
リッチコンソールとは直接関係ありませんが、CDOによるメール送信サンプル
WSFを添付しました。
http://hide-bow.jugem.jp/
でもご覧いただけます。

880
hidebou[sage]   投稿日:2014/02/07 17:38:42
現在パブリックリリースに向けてリッチコンソールのヘルプファイル作成を
行っております。従来、引数なし起動を、スクリプト由来の子プロセス起動
と認識していましたが、引数"CONSOLE"を与えた起動に変更します。

ヘルプは本日中に完成の予定です。
ご迷惑をおかけしますが、ご了承ください。

881
hidebou[sage]   投稿日:2014/02/07 20:03:55
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
リッチコンソール1.00を公式にリリースします。取り扱い説明は単独起動後に
メニューのヘルプからご覧になれます。起動の仕様が変更されましたので、
過去のファイルは破棄してここからスタートと認識してください。
謝辞にも書きましたが、こんなわがままを許していただいていることに感謝
申し上げます。このツールをHTML方向に発展させることは考えていませんが、
お気づきの点がございましたらお気軽にご連絡ください。

882
hidebou[sage]   投稿日:2014/02/08 19:27:52
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
IStream系サンプルが無かったので追加されました。関数の対称性から下記
メソッドが追加されました。

[helpstring("メモリ中にIStreamを生成しVARIANTを返します")]
HRESULT STDMETHODCALLTYPE CreateStreamOnMem([out,retval]VARIANT *v);

SAXを使ったサンプルはブログでもご覧になれるよう、更新します。
http://hide-bow.jugem.jp/

883
hidebou[sage]   投稿日:2014/02/09 12:18:46
.NETのJScriptコンソールEXEを生成し、リッチコンソールを利用するサンプル
を公開しました。デバッガとしてはMSE系の方が高性能なんですが、柔軟に使
えるということを示す意味で意義があると思っています。
http://hide-bow.jugem.jp/

884
hidebou[sage]   投稿日:2014/02/09 22:08:47
ScriptControl互換COMDLLを独自に開発するならというテーマで書きかけの
ソースコードを公開しています。いつも私がどんなコードを眺めているのか
という雰囲気だけでも感じていただけると思います。当該ページは本日中に
削除する予定です。

885
hidebou[sage]   投稿日:2014/02/10 08:00:55
今日は実際にスクリプトエンジンを書いてその基本的なソースを公開しながら
COMの基礎である寿命管理について説明することができればと考えています。
いかなる状況でもそれが可能なわけではありませんが、すっきりとしたCOM
プログラミングのポイントはインスタンスの消滅を確認しながら書き進める
ことだと思います。つまりデストラクタにBeep等を置いて、それが鳴らない
場合はどこかが間違っているというような推理をすることです。

886
hidebou[sage]   投稿日:2014/02/10 19:24:31
人数は少ないのですが、リッチコンソールに興味をもっていらっしゃる方の
アクセスに感謝しています。誰かのアプリケーションに身を委ねるというこ
とは、PC一台あずけるのと同じ信頼関係がなければなりません。私ごときを
応援して下さる方々のおかげで、今日があることをかみ締めております。

ブログに画像GETサンプルを公開しました。これは添付されていませんから、
http://kuroda.bglb.jp/sax/httpget.zip としてアップしておきます。

887
hidebou[sage]   投稿日:2014/02/11 14:53:24
http://kuroda.bglb.jp/sax/scex.zip
MSScriptControl拡張計画中間報告
レジストリ登録はreg.batへDLLをドロップ登録解除はunreg.batへDLLをドロップ
SAMPLE.WSFの内容を書き換えて実行してください。現時点は基本動作のみです。

888
hidebou[sage]   投稿日:2014/02/11 20:55:56
http://kuroda.bglb.jp/sax/scex.zip を更新しました。タイムアウト設定以外
は全関数、中身がある状態にしました。スクリプトのタイムアウトはレジストリ
がらみですので、単にプロセスが読みに行く時に騙せるのか、システム側が
認識していて当該プロセスを止めるのか勉強不足ですので、中身は空です。
現状は32bitコンパイルです。このまま64bit環境でも動く気がするのですが、
64bit機というのを持ってないので、動作実験はできていません。

889
hidebou[sage]   投稿日:2014/02/11 21:13:15
ちょっとスクリプトコントロールに寄り道してしまいましたが、リッチコンソ
ールを多方面に紹介してゆきたいと思っています。また、リッチ系の本筋だっ
たXMLの高速整形、クリップボードの監視と、BASE64文字列化等の機能を持っ
た方は、リッチコンソールが受けいれられれば、その上位バージョンとしての
位置づけでリリースできるのではないかと思っています。ちょっと方向性がぼ
やけていましたので、スクリプトからの起動を主としたエディタという色付け
は新鮮かも知れません。

890
hidebou[sage]   投稿日:2014/02/11 22:29:23
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
NET言語パース機能を付加しました。
タイプライブラリを公開しています。ブログをご覧ください。
http://hide-bow.jugem.jp/

891
hidebou[sage]   投稿日:2014/02/11 23:59:19
本家のスクリプトコントロールもそうだと思いますが、このスクリプトサイト
にはデバッグインターフェースの無いことが欠点だと感じます。まぁ、十分に
デバッグされたコードを実行するものという位置づけなのでしょうが、ここに
非表示な何らかのHTMLインスタンスを生成、そのスクリプトエンジンに侵入、
アクティブディバッグ用インターフェースのみ抽出して、エラー時にデバッガ
を起動するというのが、私らしい展開かも知れません。副産物としてHTMLダイ
アログを表示できることにもなりますし。

892
hidebou[sage]   投稿日:2014/02/12 12:55:33
HTMLインスタンスはアプリケーションセキュリティーのWebBrowserとし、
スクリプトコントロールインスタンス毎に非表示生成、スクリプトへの
準備完了通知を待ってスクリプトインスタンスを外部へ公開、当該スク
リプトでスクリプトコントロールを形成できそうです。メリットはスク
リプトにエラーが発生した時、登録してあればMSEやVSがアクティブデバ
ッガとして起動され、現状の変数値等をビジュアルに確認可能となること
です。

893
hidebou[sage]   投稿日:2014/02/12 13:06:54
普通に考えると、同一プロセスとはいえ、呼び出し元スクリプトとブラウザ
という異なるコンテキストでIActiveScriptのような生インターフェースを共
有利用するのは無理なのですが、そこをなんとかすることを数年研究してきた
ようなものですから、克服できそうです。ただ、最終的に使いやすいのか?
必要があるのか?という疑問は残るでしょうが。

894
hidebou[sage]   投稿日:2014/02/12 18:33:55
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
添付サンプルのVB側はアクティブデバッガ有効です。(末尾のExにより)
var Vb1 = new ActiveXObject("ScriptControlEx.CScriptControlEx");
わざとパース対象コードにエラーを作ればデバッガが起動します。
また、当然ながらwindow.alert("from vb")ということもできます。
言語が決定してからHTML生成していますので、JSとVBに縛られない設計と
していますが、それ以外の言語を使ったことがないので、確認できていま
せん。タイプライブラリはブログで公開します。

895
hidebou[sage]   投稿日:2014/02/12 21:21:39
スクリプトコントロールの.NETパースは動くだろう的コピペだったのですが、
動かないようですね。考えてみれば今までよそ様のプロセスでこれを行った
ことがないようにも思います。リッチコンソールは自前プロセスですから、
全く問題が無いのですが、当面.NET機能は削除して今後の課題にしたいと
思います。

896
hidebou[sage]   投稿日:2014/02/12 21:58:40
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
.NETコンパイル部分を削除しました。CLSIDに変更がありましたので、
従来のDLLをunreg.batへドロップした後に新規DLLをreg.batにドロップして
ください。そうしなくても実害はありませんが、レジストリに数箇所、宣言
が残ります。

897
hidebou[sage]   投稿日:2014/02/12 23:57:44
C++からの利用サンプルを書こうとして、低水準インターフェースのQueryが
甘いことに気づきました。明日の更新で確認済みのものにしたいと思います。
Tlb付きですので、スクリプトでCTRL+Jが有効なように、#importが使えます。
#pragma warning(disable:4192)は今のところ必要ですが下記のように呼べます。

ScriptControlEx::IScriptControlPtr ScEx("ScriptControlEx.CScriptControlEx");
ScEx->_AboutBox();

898
hidebou[sage]   投稿日:2014/02/13 08:32:35
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
今日はブログでC++からの利用方法を解説します。私自身もそうでしたが、
いきなりC++で全部を書こうとせず、内部のスクリプトである程度のこと
をこなすという姿勢でC++と向かい合った方が動かす喜びを得やすいので
学びやすいと思います。

899
hidebou[sage]   投稿日:2014/02/13 13:44:28
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
HTMLダイアログ生成を独立関数として堅牢な動作としました。クラスに変更
がありましたので、旧DLLのunreg.bat、新DLLのreg.batドロップが必要です。
ブログで進行中の解説を実行する場合は、プロジェクトで参照するDLLも置き
換えてください。

900
hidebou[sage]   投稿日:2014/02/13 15:21:38
スクリプトコントロールにこじつけてC++によるHTMLアプリケーションを書こ
うという趣旨の記事を今日は書いていました。最後にHTMLモードレスウイン
ドウをサブクラス化して乗っ取るサンプルを公開することにしました。
特別にテクニカルな部分はないかと思うのですが、IHTMLWindow2からOLE的
手法でスムーズにフレーム側HWNDを取得する部分はちょっと美しいかも知れ
ません。

901
hidebou[sage]   投稿日:2014/02/13 23:22:43
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
スクリプト側へディスパッチを追加するAddObjectに修正すべき点がありました。
使い方の解説(C++による非IDLディスパッチ生成)をブログの記事にしました。
この手の記事は短命ですので(直ぐに書き換えたくなる)、興味のある方は覗
いて見てください。

http://hide-bow.jugem.jp/

902
hidebou[sage]   投稿日:2014/02/14 09:03:52
今回リリースする拡張スクリプトコントロールの名前を
「ActiveScriptControl」にしたいと思います。実にベタな名前ですが、
Google的にはユニークなようですし、アクティブデバッグ有効というのが
最大の特徴ですから、本日中に公式リリースにしたいと思います。尚、
リッチコンソールに当該DLLを添付してレジストリ登録無しに利用可能と
する予定です。.NETコード中に非.NETスクリプトを書けるわけです。

903
hidebou[sage]   投稿日:2014/02/14 13:38:25
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
ActiveScriptControl ver 1.00をリリースします。
説明はreadme.htmとしました。サンプルはsampleサブフォルダにまとめました。
動作確認用wsfと、ブログで解説した時のCPPファイルとなっています。

904
hidebou[sage]   投稿日:2014/02/14 20:56:28
久しぶりにhttp://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
レジストリ登録とは無関係にCOMDLLを呼び出し元へ提供する
CreateInstance関数が追加されました。
HRESULT STDMETHODCALLTYPE CreateInstance([in]BSTR path, [in]BSTR str, [out,retval]IDispatch **disp);
第一引数はリッチコンソールとの相対パス、又は絶対パス、第二引数はクラスCLSID文字列です。
ブログに使用例を書きました。本関数の実験用としてリッチコンソールに
ActiveScriptControlのDLLを添付することにしました。

905
hidebou[sage]   投稿日:2014/02/15 09:33:20
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
HTMLダイアログ生成時のスタイル文字列でhide:yesを有効としました。
これはHWNDを取得してSW_SHOWすることを前提としますので、スクリプトから
の呼び出しでは意味がありません。サンプルソースをブログに置きます。

906
デフォルトの名無しさん[]   投稿日:2014/02/15 12:23:26
http://kuroda.bglb.jp/sax/scex.zip を更新しました。
x64環境向けScEx64,dllが添付されています。
ただし、実働試験を行う環境が手元にありません。

907
hidebou[sage]   投稿日:2014/02/15 17:11:24
Windows上のすべてのHWND系操作に共通して言えることですが、その実行コン
テキストという概念を理解することは大変重要です。ブログで公開したスケ
ルトンがちょうどいいサンプルとなっていましたので、その解決法を公開し
ています。Windowsプログラミングでの「わけわかんない」はほとんどこの
問題に端を発していると言っても過言ではありません。

908
hidebou[sage]   投稿日:2014/02/15 20:46:15
公開しているHTMLアプリケーションスケルトンは実験してみるとコンテキスト
をあまり外していないことが分かりました。コンテキスト強制サンプルとして
は不適切でしたが、思いのほか容易に拡張可能だということが分かりました。
アクティブスクリプトコントロールのreg.batドロップが必要ですが、VC++用
ソースコードを公開しております。

909
hidebou[sage]   投稿日:2014/02/15 21:01:04
いつかVC++用のHTML拡張ツールをと思っておりましたが、スクリプトコント
ロール&HTML生成という発想は持てませんでした。実際に動かして見ると99%
HTML+ScriptでもOKですし、99%C++でもOKですから、とても柔軟なコーディング
が可能です。何かがこうでなければならないという縛りが多いと作っている側も
使う側もすっきりしないと思うのですが、利用する環境がC++だとすれば最低限
な拡張で「あとはお好きにどうぞ」が可能ですから、こういった方向性を主力
にすべきなのかも知れません。

910
片山博文MZ無能 ◆T6xkBnTXz7B0 []   投稿日:2014/02/15 21:18:12
はろー、こんにーちは。hidebouさんは、知ってるかな、Rubyのmechanizeとかwebkitとかですよ。
後続のものは先行のものに比較されるでしょう、おそらく。
HTABOXはキラーになれるのでしょうか、心配あるね。

911
片山博文MZ無能 ◆T6xkBnTXz7B0 [sage]   投稿日:2014/02/15 21:39:39
クロスプラットホーム対応が求められるWeb業界において、あえてWindows
限定にするのは、OS固有の機能性や操作感を実現するためでしょう。
Windows APIが呼べることはもちろん、

912
片山博文MZ無能 ◆T6xkBnTXz7B0 [sage]   投稿日:2014/02/15 21:50:58
Win32リソースの埋め込み、フルセットのウィンドウ操作が実現されてしかるべき。

913
片山博文MZ無能 ◆T6xkBnTXz7B0 [sage]   投稿日:2014/02/15 21:59:02
さらに、デバッグ機構、インテリセンスなどの開発支援は不可欠。
HTABOXはどのような開発モデルを想定しているのか?

914
片山博文MZ無能 ◆T6xkBnTXz7B0 [sage]   投稿日:2014/02/15 22:12:28
人気を高めるには初心者向けの記事とリファレンスが必要だな。

915
片山博文MZ無能 ◆T6xkBnTXz7B0 [sage]   投稿日:2014/02/15 22:26:53
そこでCHMファイルを作成するノウハウですよ

916
hidebou[sage]   投稿日:2014/02/16 18:14:06
片山様いつも有用な情報をありがとうございます。遅々として進まぬストーリー
を見守っていただいていることに感謝申し上げます。HTABOXはWindowsPCの
HTMLエンジンをカスタマイズしてアプリケーションとするというコンセプト
を明確にして行ければとは思っていますが、IEの制御に成功したことから、
より総合的なツールとしてお見せする可能性が高くなりました。
具体的には「エンジン」があり、それをC++からも、スクリプトからも利用
できるというような形式です。

917
hidebou[sage]   投稿日:2014/02/16 18:17:39
http://kuroda.bglb.jp/sax/richconsole.zipを更新しました。
ユーザー定義ヘルプファイルの表示、ヘルプウインドウのみの利用について
仕様を決定しました。単独起動して、ヘルプをご覧ください。
この変更によりリッチコンソールは1.10を呼称します。

918
hidebou[sage]   投稿日:2014/02/16 19:54:13
ブログにて1.10の変更についての説明を行いました。ヘルプがいらないほど
直感的なアプリケーションが理想ですが、なかなかそれは実現できないので
いつも悶えるのですが、構造化していない論理展開なら、画像の挿入と、見
出しの認識、認識された見出しに対する自動目次生成、引用リンクで十分だ
という思想でできています。是非、このヘルプエンジンもお試しください。

919
hidebou[sage]   投稿日:2014/02/17 22:55:30
アクティブスクリプトコントロール1.10をリリースします。
http://kuroda.bglb.jp/sax/ActiveSC.zip
DLL名をより識別しやすい名前に変更しました。CLSID等は同じですから、
単にreg.batへのドロップで機能します。旧DLLのunreg.batは必要ありません。
主にスクリプトからの利用を意識してIStream系関数、文字コード変換等が
追加されました。sampleサブディレクトリにstream.wsfを添付しました。
WSHからはリッチコンソールの使用をお勧めしますが、HTA等既にGUIがある場
合はの場合はこちらの方が使いやすいと思います。

920
hidebou[sage]   投稿日:2014/02/18 15:32:09
リッチコンソール及びアクティブスクリプトコントロールが提供するIStream
に対してスクリプトからも低水準な操作が可能なようにディスパッチでラップ
する部分を書きました。現在実験中ですが、結果が良ければ本日中にも装備
することになります。これにより、ストリームに対するすべての操作をスクリ
プトから行えますので、柔軟なストリーム操作が可能となります。現在仕様を
ブログで公開しています。

921
hidebou[sage]   投稿日:2014/02/18 20:44:31
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
バージョン1.10のまま、ストリーム系関数をASCと同一にしました。また、
リンク待機、画像挿入コードを1.10時にコピーし忘れるという凡ミスをして
いましたので修正しました。お気づきの点がございましたらお気軽にご連絡
ください。

922
hidebou[sage]   投稿日:2014/02/18 21:04:50
http://kuroda.bglb.jp/sax/ActiveSC.zip を更新しました。
アクティブスクリプトコントロールを1.10のまま修正しました。
ストリーム系関数をリッチコンソールと同一モジュールとしました。
ストリーム周りに修正すべき点が見つかると両方頻繁に更新されることに
なりますが、動作の確実性が実証されるまでご容赦ください。

923
hidebou[sage]   投稿日:2014/02/19 13:15:38
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
バージョン1.10のまま、禁断の下記関数が追加されました。

[helpstring("HTMLを埋め込み表示します(第2引数をwindow.externalで参照可")]
HRESULT STDMETHODCALLTYPE InsertHtml([in]BSTR url, [in]IDispatch *ext);

[helpstring("HTMLを埋め込み表示し、window.closeを待機します(返値はwindow.returnValue)")]
HRESULT STDMETHODCALLTYPE InsertHtmlWait([in]BSTR url, [in]IDispatch *ext, [out,retval]VARIANT *ret);

現時点でのドキュメントセキュリティーはIEデフォルトです。

924
hidebou[sage]   投稿日:2014/02/19 17:49:28
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
重くなるのを嫌って埋め込みHTMLのUpdateをサボったのですがやはりWM_PAINT
時にUpdateを行うものとしました。またInsertHtml系は入力操作を期待して、
何らかのフォームがあるものとすれば、スクリプト終了後に当該フォームを
操作できるとエラーとなる可能性があることから、window.colose時にドキュ
メント側HWNDをEnableWindowで操作不可とすることにしました。

尚、埋め込み画像、HTMLを削除する方法は極めて単純でその位置の文字を
削除するだけです。TOM経由で全選択し空文字をセットすれば全部消えます。

925
hidebou[sage]   投稿日:2014/02/19 18:20:35
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。

InsertHtml、InsertHtmlWaitのアプリケーションセキュリティーバージョン
InsertHta、InsertHtaWaitが追加されました。この埋め込みドキュメントは
{3050F5C8-98B5-11CF-BB82-00AA00BDCE0B}HTAドキュメントです。

926
hidebou[sage]   投稿日:2014/02/19 19:00:51
片山様、「どんな環境を?」に対する明確な回答を申し上げられませんでした
が、私がイメージする環境とはVisual Studioのようなものではありません。
そのモジュールを使うことで圧倒的優位に立てるバイナリー群とそれをコール
する小規模なバッチ的GUIというイメージです。例えばMSHTML.DLL無しにWindows
は動きませんが、私が書いたMSHTML2.DLLに置き換えるとやれなかったことが
全部できるようになるというようなイメージです。

927
hidebou[sage]   投稿日:2014/02/19 19:06:38
私が不勉強なのか、いままでそういった発想の拡張手法を目にしたことがあり
ませんので、何かと比較される部類のものではないと認識しております。
実行側プロセスがC++由来バイナリだろうが、スクリプトエンジン由来だろうが
Windows上で動作する限り避けられないポイントがございます。それを利用し
すりかえて、よりユーザーフレンドリーなものにするのが私の手法です。

928
hidebou[sage]   投稿日:2014/02/19 19:13:32
例えばブラウザに関しても、自分が書くのは滑稽なことです。優秀なMSのスタ
ッフが、最新のIEを用意してくれます。スクリプトエンジンもしかりです。
私はIEやJavaScriptは十分に現在の人類の英知を代表するものだと考えていま
す。したがってそこに関与するつもりはありません。それ自体と競争したとこ
ろで、労力ばかりがかかりますし、一人の人間が太刀打ちできるものではない
からです。

929
hidebou[sage]   投稿日:2014/02/19 19:19:59
MSの優秀なスタッフが育てた果実を、お客様の待つテーブルへ運ぶ前にやや
スパイシーな味付けに変更する役目と申し上げたら理解していただけるでしょ
うか。最小の労力で、最大の効果を生むには、戦わずして勝つには、そんな
事を日夜考えているのでございます。

930
hidebou[sage]   投稿日:2014/02/19 19:50:11
もし、私の短い余命を維持するだけの蓄えができたならば、志を同じくする
若い方たちにすべてのノウハウを伝えたいとも考えています。勿論既存バイ
ナリの再利用とは、言うは易く行うは難しなのですが、アプリケーション開
発が持つ本当のパワーで互助会的なこの国の業界を改革し、ひいては世界を
リードできる人材が育てばと夢想しております。

931
hidebou[sage]   投稿日:2014/02/20 18:31:42
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
添付hello2.wsfは複数画像をセットし、クリックイベントで切り替える例です
表示されているHTMLに応答すると呼び出し元スクリプトが終了しますから
その前に画像をクリックすれば左右が反転した画像となります。まだ、選択
状態で画像がネガになる局面がありますが、克服できると考えます。

932
hidebou[sage]   投稿日:2014/02/20 22:21:24
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
リッチコンソール1.20をリリースします。

画像埋め込み時に返されるディスパッチを使って画像クリック時に内容を切り
替えることができます。これは、簡単なカードゲーム等を作る時に便利です。
HTML上のように反応の鈍いものではなく、ネイティブならではの反応速度で
画像が切り替わります。また、HTML、HTA埋め込み関数もドキュメントを返す
仕様に変更しました。

933
hidebou[sage]   投稿日:2014/02/21 13:37:08
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
画像イベント動作時にスクロールバーの状態によってハングする場合がある
部分を修正しました。

934
hidebou[sage]   投稿日:2014/02/21 15:11:27
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
独自ヘルプ動作時の文章内ハイパーリンクを修正しました。

935
hidebou[sage]   投稿日:2014/02/21 19:27:37
リッチエディット上の埋め込みオブジェクトはクリックされると選択状態
になるのがデフォルトだと思うのですが、それを回避する方法にまだ改善
の余地があるようです。現状ではヘルプの画像クリックでカーソル位置が
飛んだりしてしまいます。

936
hidebou[sage]   投稿日:2014/02/22 07:13:43
http://kuroda.bglb.jp/sax/RichConsole.zip を更新しました。
画像のクリック問題はシンプルな方法で解決できたと考えています。

937
hidebou[sage]   投稿日:2014/02/26 00:04:39
ずいぶん前にそう判っていたのですが、忘れていました。UAC有効だとWSH
はまともに使えないほどOSに迫害されていたんでしたね。強力なので素人は
触るなということなんでしょう。当然の展開としてリッチコンソールはメニュー
からファイルを選択してWSHを起動する機能を持つことになります。危ないから
といって法定速度でリミッターが発動する乗り物に乗りたいとは思いません。

938
hidebou[sage]   投稿日:2014/02/26 18:37:39
HTMLのタブコントロール集約によるプロパティーページのデモを公開します。
http://kuroda.bglb.jp/sax/Property.zip
アプリケーションにユーザーがカスタマイズすべき項目がある場合、その設定
用GUIを構築し、更にデータ形式を設計するのは極めて面倒な作業です。ここ
ではGUIをHTMLに、データ形式を複数HTMLを管理可能な単一XMLとすることで
上記問題を解決しようとするものです。技術的に新しいことろは無いのですが、
自身HTMLを自身が置き換える為に独自プロトコルによるシステムとしています。

939
hidebou[sage]   投稿日:2014/02/26 20:23:19
HPPD (Html Property Page Dialog) 1.00をリリースします。
http://kuroda.bglb.jp/sax/Property.zip
個人利用はフリーです。カスタマイズも承りますが、その場合はご相談の上
ということにいたします。

940
hidebou[sage]   投稿日:2014/02/26 20:47:55
MSDNのCOM入門の題材が「ATLでプロパティーページを表示しよう」だったので
すが、まったく理解できませんした(しようとしていない)。そんなの非ATL
で斜め上を飛ぶやつが書けるんじゃね?という発想で生まれたのがHPPDです。
昔は確実なデータ受け渡しはインターフェース経由だったのでしょうが、XML
の利便性を最大限に活用して各ページGUIとデータの保存、取得を一元化して
しまう発想は手の抜きどころに敏感な私らしい展開だと思っています。

941
hidebou[sage]   投稿日:2014/02/27 07:36:12
HPPDを書く前にもHTMLダイアログをネイティブアプリケーションから使うこと
は行っていましたが、OKボタンでreturnValueを作成し、C++側では返された
_variant_tから値を取得する。場合によってはIDispatchExとみなして子を
列挙するような動作は避けがたかったわけです。呼ぶたびにその面倒が発生
すると同時にその処理は個別な局面に依存しますので、何種類も書かなければ
なりませんでした。

942
hidebou[sage]   投稿日:2014/02/27 07:46:41
健全でない言葉が含まれているため表示しません 内容を確認する

943
hidebou[sage]   投稿日:2014/02/27 08:00:46
改めてHPPDのコードを眺めてみると、各動作の組み合わせに精妙さが要求され
ますから、XMLや動作を分析しただけで同じものを作ることは困難でしょうが、
分析に時間を要したアンドキュメントなテクニックは存在していませんので、
コードを公開する可能性があります。ただし、単に公開しても食べて行けませ
んので、C++によるCOMプログラミング手法の解説ドキュメントとして販売し、
その最終目標として本ソースコードが存在するというような形が望ましいと
考えています。

944
hidebou[sage]   投稿日:2014/02/27 10:11:11
http://kuroda.bglb.jp/sax/Property.zip を更新しました。
HPPDのCOMDLL版が添付されています。reg.batへDLLをドロップ後sample.wsf
を実行すればexeと同等のダイアログが表示されます。ただし、スクリプト
がインスタンスを開放した時点でウインドウは閉じる仕様ですから、注意
してください。HTAからの利用ならその配慮は必要ありません。

945
hidebou[sage]   投稿日:2014/02/27 11:55:05
http://kuroda.bglb.jp/sax/Property.zip を更新しました。
COMDLL版のダイアログ生成関数を見直して、モーダル、モードレスを指定可能
としました。これによりスクリプトからも簡便に呼び出すことができます。
添付sample.wsfはDoModalによって表示を行う例となっています。ちなみに
exeを子プロセスとして起動した場合はモードレス動作を採用しています。

946
hidebou[sage]   投稿日:2014/02/27 14:00:50
http://kuroda.bglb.jp/sax/Property.zip を更新しました。
動作速度を目的とした最適化を行いダイアログのスクロールは自動としました。
親HWNDはHTML系ではなくネイティブですからあらゆるオプションが可能ですが
やたら引数の複雑な関数の説明だけで萎えると思いますので、深入りしません。

947
hidebou[sage]   投稿日:2014/02/27 21:22:22
http://kuroda.bglb.jp/sax/Property.zip を更新しました。
今のところあまり意味は無いのですが、HTMLフォームでのpost動作に対応しま
した。将来ローカルな画像送信を行い、XML中にBASE64エンコードして保存、
画像つきのデータベースとするような使い方ができると思います。

948
hidebou[sage]   投稿日:2014/02/28 08:56:59
リッチコンソールは今までプログラミングに興味の無かった方にその楽しさ
を理解していただくための窓口という役割を持たせたいと思っています。
そのために、お硬い話では食いつきが悪いので簡単なカードゲームを作れる
機能を用意し、その構築過程をチュートリアルにする予定です。
メニューからのスクリプト実行、登録画像の加工、WAVデータバッファリング
によるリアルタイム再生を簡単な関数で表現し、バージョン2.00となる予定
です。

949
hidebou[sage]   投稿日:2014/02/28 19:14:07
リッチコンソール2.00のコーディングを終了しました。変更点については
ブログをご覧ください。変更点を反映したヘルプが完成したら、リリース
いたします。HTML系を主体に研究していましたが、HTMLウインドウの場合
僅かながらネイティブより切れの悪い動作となってしまいます。リッチエ
ディットコントロールはもうひとつの柱ですので、目の黒いうちはこれを
更新し続けると思います。 http://hide-bow.jugem.jp/

950
hidebou[sage]   投稿日:2014/03/01 12:38:37
HPPD (Html Property Page Dialog)1.01をリリースします。
http://kuroda.bglb.jp/sax/Property.zip
機構が単純なのでたいした量ではありませんが、readme.htmに詳細な説明を
添付しましたので、ご覧ください。汎用なタブ付きHTA的使い方もできます
から、プロパティー設定だけではなくメインなウインドウとしても使えると
考えます。1.01は複数HTMLで参照されるCSSやスクリプトも単一XMLに記述可
能としています。欲を出さなければこれはこれで完成されているシステムの
ように感じています。

951
hidebou[sage]   投稿日:2014/03/01 16:12:51
と書いてreadme.htmが置き換わっていないミスがありましたので、zipを更新
しました。正直、リッチコンソールのように複雑な構造となると、全スレッド
が綺麗にゼロを返して終了する状態にはなりにくいのですが、HPPDは単純です
から切れ味鋭い終わり方を見せます。ついその気持ちよさを体験したくて眺め
てしまいます。

952
hidebou[sage]   投稿日:2014/03/01 18:03:50
http://kuroda.bglb.jp/sax/Property.zip を更新しました。
WIN7環境で初期タブ表示が行われないことへの対応を行いました。

953
hidebou[sage]   投稿日:2014/03/01 21:53:38
http://kuroda.bglb.jp/sax/trump.zip を公開します。
リッチコンソール2.00を使ったトランプゲームデモです。

リッチコンソールを起動して、メニューの[スクリプト実行]->[WSH環境]から
trump.wsfを選択して実行してください。従来のWSF先行では無いことに注意
してください。2.00ドキュメントは後ほど公開します。

954
hidebou[sage]   投稿日:2014/03/01 23:38:05
http://kuroda.bglb.jp/sax/trump.zip を更新しました。
凡ミスがあったのですが、JScriptの寛容さに救われていた点を改善しました。
ソースは当然添付されていますが、ブログでもご覧になれます。

955
デフォルトの名無しさん[sage]   投稿日:2014/03/02 03:27:42
ブログでも作って一人でやれば?
固定ハンドルによるスレッドの占有は専門板だと
削除対象ですよ。
コメント1件

956
hidebou[sage]   投稿日:2014/03/02 08:15:50
http://kuroda.bglb.jp/sax/trump.zip を公開します。
スクリプト側の待機関数仕様を変更し、スクロールを抑制しました。

>955 ご忠告は真摯に受け止めておりますが、リソースを占有する
意図はございません。

957
デフォルトの名無しさん[sage]   投稿日:2014/03/02 08:42:56
うるさいこといわんでもええがな

958
デフォルトの名無しさん[sage]   投稿日:2014/03/02 12:40:20
いままでどおりまったりいきまひょ

959
hidebou[sage]   投稿日:2014/03/02 15:45:51
いつも独りでボソボソやっているものですから、どんなご意見でも私以外の
書き込みがあると、それだけでちょっとなごみます。

http://kuroda.bglb.jp/sax/trump.zip を更新しました。
画像再描画動作の見直し、終了リンクからの終了時に未開放BSTR領域がある
部分の訂正を行いました。

960
hidebou[sage]   投稿日:2014/03/04 01:22:09
http://kuroda.bglb.jp/sax/trump.zip を更新しました。
添付trump.jsは同じ内容ですが、アクティブスクリプトコントロール環境
で動作するデモです。この場合リッチコンソールはレジストリとは無関係に
DLLをロードしますので既存のレジストリ登録状態とは無関係です。当然
WSHを子プロセス起動しない分だけ軽量だと思います。

961
hidebou[sage]   投稿日:2014/03/04 16:15:55
http://kuroda.bglb.jp/sax/trump.zip を更新しました。
画像更新処理をOLE的手法で確実なものとし、マウスカーソル形状操作をより
現実的なものに変更しました。一応これでバグの無い状態になったと予測しま
すが、世の中そんなに甘いもんじゃないですよね。ちなみにtrump.jsの方は
シャッフルコメントアウトの快感モードです。

962
hidebou[sage]   投稿日:2014/03/04 20:48:18
http://kuroda.bglb.jp/sax/trump.zip を更新しました。
埋め込みマニフェストが無いとアクティブスクリプトコントロールの拡張側
が動かないことを忘れていました。今度はASC非インストール状態でもスクリ
プトを実行可能となっています。ASCは営利非営利を問わず個人利用はフリー
で提供と考えていますので、それと結合しているリッチコンソールも同じ
考え方にしようと思います。アプリケーションをスクリプトで簡単に作成し、
ヘルプもRTFで作成できますから、ひょっとしたら売れるかもしれないという
夢を持ちながらプログラミングしていただければ幸いです。当然、将来は
独自エンコードによるスクリプトコード隠蔽機能が追加される予定です。

963
hidebou[sage]   投稿日:2014/03/06 19:11:12
http://kuroda.bglb.jp/sax/trump.zip を更新しました。
細部の動作を見直し、より軽量にしました。DirectSoundの再生が込み入ると
マウスを喪失するのでは?という想定の元に正解時もWaitを入れてみました。
風邪を引きまして、悪寒と闘いながら生きております。すこし進行が遅れます
が、ご容赦ください。

964
hidebou[sage]   投稿日:2014/03/12 22:13:10  ID:3ii3KDww.net
リッチエディットのヘルプエンジンを手直ししながらヘルプを書いています。
RTFを基本とした、高速で軽量な情報の閲覧、検索やスクロールを、今後の
アプリケーションに共通して搭載可能なものとするためにすこし時間をかけて
います。次期HTABOX系は総合的なMSHTML拡張環境となりますので、説明の構造
と、その伝達効率は生命線になるでしょう。その日までこの指が動くことを
祈りながらコーディングしております。

965
hidebou[sage]   投稿日:2014/03/13 19:19:22  ID:rnCjgJhU.net
自分の頭を整理する意味も込めてヘルプエンジンのみなデモを公開します。
http://kuroda.bglb.jp/sax/helponly.zip
helponly.wsfを実行すると、コンパクトなRTFによるデモが表示されます。
現状ではCSS+HTMLは色物的存在ですので、あまり細かなエラーチェックを
行っていません。

966
hidebou[sage]   投稿日:2014/03/14 12:27:40  ID:HjzLMfFa.net
http://kuroda.bglb.jp/sax/helponly.zipを更新しました。
リッチコンソールを単独ヘルプエンジンとして使うために必要な情報をデモ
として表示しています。多くの機能は独自タグによって実現されていますから、
ヘルプとして表示すると同時に、ワードパッドでRTFを直接眺めていただけば
理解が早いかと思います。

967
hidebou[sage]   投稿日:2014/03/21 13:34:31  ID:MxIKoi1W.net
http://kuroda.bglb.jp/sax/helponly.zipを更新しました。
RTFに付加的な機能を提供する独自タグを一般的な属性="値"形式に変更しまし
た。また、&lt;&gt;での説明用タグ表記にも対応しました。
納得できないとチマチマ書き直してしまうものですから、本体のリリースが
遅れていることをお詫び申し上げます。

968
hidebou[sage]   投稿日:2014/03/25 16:36:38  ID:3HwvfoHq.net
http://kuroda.bglb.jp/sax/helponly.zipを更新しました。

プレビュー機能を追加しました。起動時にRTFと同名なPNGが無い場合、
画像が自動生成されます。また、生成済みのPNGよりRTFの更新日時が
新しい場合も画像は自動更新されます。

プレビューのクリック、表示領域矩形ドラッグでドキュメント側ウインドウ
がスクロールします。

969
hidebou[sage]   投稿日:2014/04/20 17:16:21  ID:leh7uq87.net
http://kuroda.bglb.jp/sax/ClipEncoder.zip を公開します。
取り説作成時にオフィスで作成された図表をEMFデータの状態で取得する目的
で作成したモジュールを汎用化したものです。

オートシェイプの曲線を滑らかなままPNG等のファイルに変換して他アプリで
使用する目的にも使えます。

また、本アプリケーションのC++ソースコードは公開する予定です。

970
hidebou[sage]   投稿日:2014/04/25 20:04:28  ID:3js/+4Qs.net
リッチコンソール2.00のヘルプエンジン部分をRDFビューアーとして公開
しました。
http://kuroda.bglb.jp/sax/richconsole.zip

添付されている「RDF仕様.rdf」をRichConsole.exeへドロップすればそれ自体が
解説となっています。まだ完結していない解説ですが、RDFビューアーはテキスト
で作成したドキュメントを自動的にWEBサイト化機能も有しています。

971
hidebou[sage]   投稿日:2014/05/01 17:16:30  ID:bu847GcF.net
スクリプトへDirectX Transform機能を提供する小品を書きました。
http://kuroda.bglb.jp/sax/DispImage.zip
DirectX TransformはIE独自のCSSフィルタとしても使われていましたので概ね
の機能は想像できるかと思います。エフェクト結果はスクリプトから保存可能
です。また、2画像切り替え時のエフェクトも実装していますから、スライド
ショウをスクリプトで制御可能です。

972
hidebou[sage]   投稿日:2014/05/06 20:20:56  ID:hYHM6Vsb.net
MIDLコンパイラに依存しないタイプライブラリ付きCOMDLL作成環境を
BTLシステムとして公開しました。現在ヘルプを更新中ですが、ファイル群は
ダウンロード可能としています。

http://kuroda.bglb.jp/sax/BtlTest.zip

973
hidebou[sage]   投稿日:2014/05/10 18:13:54  ID:PRUTW2bS.net(2)
日ごろの感謝を込めてこのスレッド専用バイナリを用意しました。

http://kuroda.bglb.jp/sax/fsoex.zip

Build TypeLib System で作成されたタイプライブラリ付きFileSystemObjectラップDLLです。
拡張された機能はOpenTextFile関数最終引数に任意なコードページ(65001等)を指定可能なことです。
レジストリ登録、解除はバッチファイルへのDLLドロップで行えます。
登録後、添付WSFを動作させて確認してください。

974
hidebou[sage]   投稿日:2014/05/10 18:20:03  ID:PRUTW2bS.net(2)
尚、前述のDLL作成に使用されたC++コードは
http://kuroda.bglb.jp/sax/BtlTest.zip
にFSO拡張サンプルとして添付されています。
FSO自体のインテリセンスはOKなのですが、TextStream側がNGなのは私の
勉強不足が原因?なのかも知れません。

975
デフォルトの名無しさん[sage]   投稿日:2014/05/10 21:23:43  ID:O2yhZ3ex.net
続きはブログか夢独り言板で。
コメント1件

976
hidebou[sage]   投稿日:2014/05/11 04:58:39  ID:yVpTLNKX.net(5)
>975
ここにスレッドを作って何年になったのか忘れてしまいましたが、はたして
2chで純粋なプログラミングの話(ネタとして面白くない)をしたら、はたして
どうなるんだろうということに興味があったように思います。

ユーモアのセンスみたいなものは全く持ち合わせていませんから、どうせボコボロ
だろうと思っていたのですが、そうではありませんでした。

977
hidebou[sage]   投稿日:2014/05/11 05:08:58  ID:yVpTLNKX.net(5)
何人かの方には継続して興味を持っていただき、あれやこれやと移ろうテーマ
に付き合っていただいたことで、今日に至ることができたと感謝しています。

おそらく、固有のハンドルネームを使ってリソースを占有しているように感じる
方がいらっしゃるのだと思いますが、WEBアプリケーションと違いローカルで
動作するアプリケーションを匿名で公開したところで誰も信用はしません。
少なくとも私はそういった公開の仕方をしているバイナリには触れません。
それが間接的であれ、どこの誰がどういう目的で作成し、それが信用に値する
かを確認した後でなければ危険だからです。

978
hidebou[sage]   投稿日:2014/05/11 05:15:31  ID:yVpTLNKX.net(5)
したがって、この場でローカルなアプリケーションを公開することには無理が
あるというのが結論です。また、このCGIも以前は小規模なソースコードなら
投稿できたのですが、いつのまにか文字数制限が厳しくなり数十行程度のスク
リプトでさえ投稿できない仕様になっているのもこの掲示板の方向性を示唆する
要因と考えています。

979
hidebou[sage]   投稿日:2014/05/11 05:24:53  ID:yVpTLNKX.net(5)
HTA互換のHTMLアプリケーション実行環境に端を発しているわけですが、HTML
を解釈し、スクリプトへ拡張された機能を追加する段階で非常に広範囲な分野
の知識と研究が必要でした。すこは解からないから手を付けずにおこうという
手抜きは、それを使っていただく方に対して何より失礼なことですから、書き
込みの内容も多岐にわたり、「スレッド名」に対する話題を原則とするここの
ルールから見てもイレギュラーなものでしょうし、私自身としても心苦しく感
じていました。

980
hidebou[sage]   投稿日:2014/05/11 05:37:01  ID:yVpTLNKX.net(5)
ここは、大変気軽に誰でも自由に意見を書き込めるステキな環境です。特に
このプログラミング分野では、いたずらに他人を誹謗中傷するようなことは
めったに起こらず、私自身過去のスレッドから有用な情報を得た時期もあり
ました。黙々とした書き込みも、非常に奥まった分野でヒントを求めている
方の目に留まればという想いでしたが、情報として、ソースコードとして、
誤りが無いことを目指した場合「送信後に訂正できない」というここの性質
はそういった観点からも私のようなおっちょこちょいにはふさわしくありま
せん。

981
hidebou[sage]   投稿日:2014/05/11 05:47:55  ID:h1VLXjzF.net(2)
本来は自身のサーバーを整備し、早期に情報を集約すべきでしたがさまざまな
分野に目が行き、それぞれを納得行く形で解決する作業の連続からなおざりに
なってしまったことを反省しています。私という人間をよくもわるくも気に留
めていただけだことは、私にとって貴重な財産です。

982
hidebou[sage]   投稿日:2014/05/11 05:59:53  ID:h1VLXjzF.net(2)
たまには音楽でも、名演だと思います。

http://www.youtube.com/watch?v=vKye6tLyxu4
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

プログラム板 タイトル検索

このスレッドが人気です(実況系)
実況 ◆ 日本テレビ 54688 (211)NTV実況
実況 ◆ フジテレビ 82969 損得 (559)フジ実況
連続テレビ小説 べっぴんさん★245 (742)NHK実況
羽鳥慎一モーニングショー★4 (131)テレ朝実況
白熱ライブ ビビット★1 (514)TBS実況
NHK総合を常に実況し続けるスレ 132231 スーパー主婦 (746)NHK実況
実況 ◆ テレビ朝日 47321 てる美倶楽部 (549)テレ朝実況
おはよう!時代劇 暴れん坊将軍3 #101(第107話)[字][再] (813)テレ朝実況
このスレッドが人気です(ニュース系)
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★225 (635)ニュー速+
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★224 (1000)ニュー速+
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★223 (1000)ニュー速+
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★222 (1000)ニュー速+
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★221 (1000)ニュー速+
【辻元氏今日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★220 (1000)ニュー速+
【辻元氏明日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★219 (1000)ニュー速+
【辻元氏明日会見】辻元清美氏に関する記述、民進「事実に反する虚偽」と否定 メディア各位に拡散しないよう要求★218 (1001)ニュー速+
プログラム板の人気スレ
オブジェクト指向って自然な文法だな 2 (408)
オブジェクト指向って不自然な文法だよな (1000)
【統計分析】機械学習・データマイニング14 (347)
スレ立てるまでもない質問はここで 146匹目 (1000)
Excel VBA 質問スレ Part47 (368)
くだすれPython(超初心者用) その32 (1001)
Visual Studio 2017 (831)
C言語なら俺に聞け 139 (575)
次世代言語議論スレ[Go Rust Haskell Scala]第3世代 (361)
C#, C♯, C#相談室 Part92 (726)
C++相談室 part129 (916)
推薦図書/必読書のためのスレッド 81 (579)
ふらっと C#,C♯,C#(初心者用) Part127 (134)
【PHP】下らねぇ質問はここに書き込みやがれ 8 (113)
Swift part10 (311)
Pythonのお勉強 Part52 (707)
Visual Studio 2015 Part8 (554)
ねねっちと一緒にプログラムを勉強するスレ第2話 (76)
Xamarin Part3 (656)
Java入門・初心者質問スレ Part.2 (920)
Git 15 (356)
HSP総合スレ【part 10】 [無断転載禁止](c)2ch.net (249)
クラス名・変数名に迷ったら書き込むスレ。Part27 (929)
ドルオタワイ、1からプログラミングを学びたい (130)
Ruby 初心者スレッド Part 59 (924)
☆★Java質問・相談スレッド179★★ (829)
プログラミング言語 Rust 2 (704)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 新着書き込みなし(304)