現在各種コモンコントロールを提供する3.00のリリース準備中です。
お気軽にご意見をお寄せください。
ttp://kuroda.bglb.jp/htabox/
ttp://kuroda.bglb.jp/htabox/demo.zip
開発環境途中経過
ttp://kuroda.bglb.jp/htabox/htabox3.zip
プルコードをそのまま実行して結果が即座に見れるという工夫です。ドキュ
メント自体はMSWORDで書いた方が書式として綺麗なのですが、HTML出力後で
も有効なコントロールやスクリプトをMSWORDでの編集状態で記述することは
できないような気がします。office固有のコントロールでは意味が無いわけ
ですがら。
innerTextを認識、実行用ボタンを生成する」になりました。これで興味の
あるセクションのヘルプを眺めて、即座に実行結果を見れるようになります。
また、エディタが付属するバージョンではサンプルをエディタ上で編集し、
動作の変化を即座に確認できるわけです。
ふさわしいのかを自分なりに結論付けるために重箱の隅をつつくような事柄
を解析してきましたが、すべては「簡単に結果が得られる」ためにある訳で
すから、細かなことは有る程度切り捨てて「簡単に見栄えのいいアプリケー
ションが書ける」ということを前面に押し出した方向へ重点を置くことにな
ります。
ttp://kuroda.bglb.jp/htabox/htabox3.zip
今まで分散していたリソースを単一EXEに結合しましたので一気に450kになり
ました。きちんとドキュメントを書くと全体は数Mbになるかも知れません。
ドキュメントを含んだEXEとして、クローン生成用にコンパクトなEXEを別途
用意すべきか、ドキュメントを別ファイルにすべきかを決定しなければなり
ません。
山形も風向きによっては福島の影響を大きく受けるみたいで心配です。
このプロジェクトは日本の復興のためにもなります。頑張ってください。
作すべきGUIが離れざるを得ない構造になるわけですが、HTMLアプリケーショ
ンの場合縦長のドキュメント中にボタン等のコントロールを置くことは普通
なわけですから、説明とGUIが一体となった構造とすることができます。また
、全体の見出しを俯瞰できるツリーメニューを付けているので例え長大な説明
だったとしても目的の位置へは即座に到達できるわけです。このことにでより
ユーザーフレンドリーなアプリケーションを構築できると感じます。
ありがとうございます。私のような人間が生きさらばえて、生きるべき方々
の命が奪われたことを想うと心が痛みます。
ましたが、まだβではありません。
ttp://kuroda.bglb.jp/htabox/htabox3.zip
確かに間違ったことさえ書かなければプログラムは忠実に動くわけですが、
結構複雑な処理を前から知っていたかのような速度で処理するプログラムを
見るとずいぶん遠くへ来てしまった感があります。マシンと人間の距離は広
がる一方ですから、それを埋めるプログラムは次第に複雑なものにならざる
を得ません。WIN32アプリケーションとしての機能を付加したHTABOXのコード
は良く言えば「有機的」悪く言えば「相互の依存関係が複雑」なものになり
ました。
てしまいましたが、納得のゆくモジュールが書けそうです。HTAタグと同等な
実行時ウインドウへのアイコン追加を3.00に実装する予定です。静的ファイル
を対象としたアイコンリソース置き換え機能は自分用ツールの場合必要が無い
わけですので別途なサービスとする予定です。
HELPはEXEリソースでは肥大化することからHELPディレクトリに置く方向に
しました。次に更新するときは実働するβになる予定です。
ttp://kuroda.bglb.jp/htabox/htabox3.zip
言っても表示HTMLのpathnameというごく当たり前な規則ですので通常は意識
する必要が無いと思われます。HTMLから相対パス参照で記述すれば自動的に
絶対パスへ変換して検索します。もし、about:blankに後付けされたエレメン
トを対象にコモンコントロールを生成しようとした場合はpathnameが空です
から、呼び出しスクリプトのパスを基準にします。呼び出しスクリプトが格
納されている場合はEXEのパスとなります。
C++プロセスからの実行では問題ないページャーがWSHからだとスレッドが
ブロックすることに気づき対策を模索しました。で解決策が見つかったの
ですが、なぜそうでなければいけないのかという理由は今のところ不明で
す。COMの世界では理由がわからないということはまずありえないのですが、
複数のウインドウ同士がメッセージで通信している状態というのは神のみぞ
知る領域というのが存在するような気がします。
非常に基本的なことを今更学ぶという時間を過ごしました。特にアイコンと
ビットマップについては、何度もモジュールを書き直し納得のゆくレベルに
できました。バイナリはまだなのですが、SetIcon関数でアイコンを設定し
DrawBitMap関数でウインドウ上の自由な位置へ透過ビットマップを表示した
サンプル画像を置きます。
ttp://kuroda.bglb.jp/htabox/bmp.png
でコードを打ち続けた日々が遠い過去のようにも思えます。同時に私が強く
こだわってきた事柄がとてもちっぽけなものにも感じられます。私の最大の
長所でもあり、欠点でもある「なぜそうなのか知りたい」という欲望を封印
して現状での私の仕事をより正確に把握していただけるようドキュメントの
作成に専念しなければと感じています。
な状態で放置してしまっていた事に気づきました。スクリプトからの低水準
関数を用意して、より複雑なメニューを作ってもらおうという予定でしたが、
それでは煩雑になることから従来のTABLE形式のメニュー定義に加えUL/LIに
よるメニュー定義を追加します。これによりネストしたメニューを簡単に定
義できるようになります。また、従来は文字列が表示されるメニューのみで
したが、TDもしくはLIにbackground属性を定義すればビットマップメニュー
も表示可能とします。すでにモジュールは完成していてこの拡張されたメニ
ューについてのドキュメントを作成中です。
を変える重要な作業だと痛感します。もしこれが分業化されてしまったら結果
として使いにくいものしか生まれないだろうとさえ思います。一人ですべてを
掌握するメリットは例え全体の改訂が必要な事柄でも、面倒な会議を開くこと
なく内容に反映できることです。大げさな表現かも知れませんがプログラムと
いう存在は一つの人格だと思います。ですから複数のチーム完成させる場合で
も、最終的にユーザーの前でどのように振舞いたいのかをプロデュースする一
人の人間がいないと魂の無いプログラムになってしまう気がします。
による独自ディスパッチの取得が今まで何の問題も無く安定動作していること
から当該手法を推奨し、window.onCreate()を復活させてHTML中のスクリプトか
らでも各種コントロールを生成可能とします。学習初期のプログラマーにとって
WSHファイルとHTMLファイルが別だというだけで「面倒」という印象を与えてしま
うかも知れませんから単一HTMLで完結できることは歓迎されると思います。
愚直に、例え細かいことでも妥協せず書くしかないわけです。ただし、プログ
ラムというものは細かく制御すればするほどオーバーヘッドが増えるわけで、
軽快な動作とは相反する要素となります。だからC++のように最小のオーバー
ヘッドを実現できる環境でないと愚直が鈍重に変化してしまいます。
送信を公開して実現する手法もあるわけですが、その方向に進むとDHTMLと変わ
らない重さになってしまう懸念があります。ですから途中での要素の変更のよう
な動作を切り捨てて明快で軽量なことを目指しています。そういった方向では
あるのですが、これだけはオプションとして必要と感じられる部分がありました
らその都度機能を追加してゆく予定です。
その実行結果が即座に表示されるということを目的として作業していますが、
細かな現実的問題をクリアするのに思いのほか時間を費やしてしまいました。
幸いにもその動作を想定して設計されたタイプライブラリ主導でのCOMサーバー
や.NETスクリプトエンジンは安定して動作していますので、一通りのサンプル
を格納してまもなくβと呼べるものをお見せできそうです。
4/7 予測 http://up3.viploader.net/ippan/src/vlippan198234.jpg
発表はドイツ気象庁 http://www.dwd.de/
せてはいけません。早急に一民間企業とは隔絶した処理チームを編成して事に
あたらなければ国際的に日本と言う国の信用は地に落ちるものと思われます。
天文学という見地から見れば私達の文明などほんの瞬きほどの時間しか存在し
ていません。もし人類が何万年というオーダーで存在したとすれば、今と同程
度の文明は幾度と無く存在し、その数だけ滅びがあったのだろうと推察するの
が自然です。愚かしい人類の中でも、群を抜いて愚かしい私ですが、せめて人
の役にたてるのであれば今すぐにでも福島に馳せ参じたい心境です。
今後の日本の復興のために、それぞれが持ってる能力を
得意な分野で最大限発揮するしかないんと違いますか？
山形ゆうたら福島に近いから、いてもたってもいられんのは分からんでもないが
ついこの間までキーボード打ってたオッサンが出る幕はおまへん。
日本と世界の英知が集まれば、必ず光明は見えてきますがな。
壱岐君もそう思うやろ？
ツールを公開します。
ttp://kuroda.bglb.jp/htabox/tab.zip
メニューから任意なHTMLファイルをタブに追加し、タブ表題部分（タイトル）
を右クリックすると削除します。現状では実行されるHTMLには相互を認識する
小規模なディスパッチがダイアログ引数として与えられています。
//変数TABにインスタンスを格納したとして各関数を説明します。
var TAB = window.dialogArguments;
//表示されているタブの数
var Length = TAB.Length;
//ドキュメントの追加（フルパス）
TAB.Add("c:\\hoge.htm");
//任意なインデックスのドキュメント取得
var Document = TAB.Get(index);
//任意なインデックスのタブを選択
TAB.Set(index);
//任意なインデックスのタブを削除
TAB.Del(index);
付けました。信頼済みゾーン用ブラウザという意味です。ブラウザが解釈可
能なファイルなら画像単体だろうがテキストだろうが何でも開く事ができま
す。最大の特徴は「全くセキュリティーに関心を持たない」事ですので恐ら
く世界で最軽量なブラウザだと思います。自身が作った複数のHTAのランチャ
ーとして使うのもいいかも知れません。すこし外観の微調整を行いました。
ttp://kuroda.bglb.jp/htabox/tab.zip
その半分くらいですが、さすがにこの大きさになると肩がこります。つい書い
た対症療法的記述が残らないように基本を確認する意味でコンパクトなアプリ
ケーションを書いた結果が上記ブラウザです。あまり拡張する気はありません
が、タブ表示中のファイルパス、URLを単一ファイルにテキストで保存し当該
ファイルを開いた場合は複数のタブを一気に再現する機能と、ページ上のハイ
パーリンク上で右クリックし、IEではなく本ブラウザの新たなタブとしてリン
ク先を表示する機能は是非実現したいと考えています。
習作ということになります。HTAは一つの窓で実行するものという概念を取り
払うことでHTAをモジュールとみなしたメタHTAの実行を可能としています。
例えば一番最初のタブにマスターHTAを置いて以降のタブに存在する実働HTA
へ仕事を依頼して結果を取得するというようなイメージです。また、HTMLとい
う規格そのものがマルチスレッドには不向きですが、設計の段階から別スレッ
ドは別HTAとすれば、同一オブジェクトや変数に対する競合が発生しませんか
らより明確なアルゴリズムで複雑な処理を記述可能になると思われます。
京大の専門家先生によると、もしそうなって格納容器が一気に破損した場合は、
福島原発の半径300キロを目安に退避したほうがいいそうだ。風下になったら躊躇なく逃げよう。
いままでと同じ爆発と同じように対応するわけにはいかんそうだ。
みなさんも心の準備、車やガソリンの準備、お金や身の回りの準備、遠くの親戚との連絡だけはしておいて
何事も起きないように祈りましょう。
作者さん、このスレのみなさんに大事が起きないことを祈る。
で単純に改行(\r\n)区切りにフルパスを記述してください。改行のみの行は
無視しますが、何らかの文字列が存在した場合はパス又はURLとみなして生成
を試みますので注意してください。ttp://kuroda.bglb.jp/htabox/tab.zip
にはWindowsXPに標準で存在する4枚のサンプルJPGを一括で表示する例が添付
されています。各自の環境に書き換えて当該ファイルをAppend HTMLで指定
してみてください。
http://www.jma.go.jp/jp/quake/
http://tenki.jp/earthquake/
http://weathernews.jp/quake/
というテキストを地震.tzbというファイルに保存すればいかなるブラウザより
高速に３つの情報を得ることができます。勿論、高速なのはセキュリティーな
んて言葉さえ知らないからだということを念頭に置いて使用してください。
表示ページのハイパーリンク上で右クリックした場合当該リンク先を新たな
タブで表示することができます。マウス座標からのとエレメント特定は基本
的にelementFromPointなのですが、フレーム構成の場合やや複雑な手順が必
要になるようです。また、ヒットしたエレメント自体が<A>とは限りません
ので親エレメント側を巡航し<A>を検索、存在しなかった場合子を列挙して
再帰的に<A>を検索しています。リンク手法が<A>以外だった場合の動作は
考慮していません。これで信頼すべきサイトであればネット上を巡航する
事が可能となりました。
実質80kです。MSHTA.EXE並のコンパクトなサイズでイントラネット用タブブラ
ウザを実現できたことを素直に喜びたいと思います。現在実装されていない
ツールバーとヘルプファイルを整備して企業内イントラネット専用ブラウザと
しての需要を掘り起こせればと考えています。
ヘルプは書きかけですが、実用に耐えると思います。正直HTABOX3が大きくな
ってストレスが溜まったものですから、思いっきり軽量なものを書きながら
粛然としない部分を検証しようという意図は思いがけない副産物を生んだよう
です。私はこの子が結構気にいっています。やろうと思えば各タブのHTMLイン
スタンスへHTABOX並の機能を提供することも可能ですが、このブラウザの場合
レスポンスの良さが特徴ですので、あまり欲張ったことは考えていません。
表示ページのタブ部分の右クリックでポップアップメニューが表示され、
タブの削除、HTMLソースの表示、整形XMLでの表示、を選択できます。
特に整形XMLでの表示はHTMLをXHTML化しなければならない時の変換ツールと
して有効だと思います。このXMLは単なる文字列変換ではなくHTMLのDOM
ノードを再帰巡航してXMLのDOMとしていますからコストはかかりますが整形
XMLであることが保障されています。
書けるかということは英文MSDNのどの位置に関連文章があるかを知っている
かどうかに尽きる気がします。さらに独創的なプログラムを書けるかどうか
は英文MSDNの先にある未解説な部分をいかに実験コードで解析してゆけるか
になります。この「解析」に相当する行為は実アドレスを常に参照可能な言
語でなければ困難です。ある推理の元にコードを走らせ、少しづつ変化させ
ながらどこでシステムがハングするかを観察する行為だからです。
複数習得する必要は全く無く、JScriptかVBScriptで十分に思えます。勿論
現状のJScriptかVBScriptで素敵なアプリケーションというのは書けない訳で
分かっていながら中途半端な言語の知識を習得せざるを得ない状況のように
思えます。私の仕事はJScriptかVBScriptで素敵なアプリケーションが実現で
きるようにC++で下支えをすることと表現できるかも知れません。
表示中ページのタブ右クリックでHTML/XMLを表示する簡易エディタにコード
ページを指定して入出力する機能を追加しました。せっかく整形XMLを作成し
ている訳ですからUTF-8等でも保存できたほうがよかろうという展開です。
書きすぎている部分をシェイプしてソースコードを整理しました。さっさと
ドキュメントを書いて個人アカウントの方でVectorにアップするつもりです。
名称は「TZ Browser」キャッチは「HTA用タブブラウザ」になるでしょうか。
その後にHTABOX with Editorを公開することになります。正直、開発を続け
られるかの瀬戸際を通り過ぎてしまった感もあるのですが、なんとか電気代
くらいは稼ぎたいと思っておりますのでよろしくお願いします。
自分で自分の足を踏んでいるような日です。100%成功するための秘訣は
成功するまで諦めないことなんだそうです。確かにそれなら失敗という
概念が無いので前向きに生きれるでしょうね。
ます。表示ドキュメントのAタグ上の右クリック以外はツールチップ等で動作
を案内していますので分かると思います。スクリプトからのタブ操作はここに
以前書いたとおりなのですが、詳しくはヘルプの完成をお待ちください。
http://kuroda.bglb.jp/htabox/tzbrowser.zip
世の中のサンプルコードを眺めているとどうしてそんなコストの高いことを
しているんだろう？と思うことがしばしばあります。代表的なのはイベント
シンクです。私も現在のスタイルに到達する前はイベントを拾うという実験
もしていますが、もともとCOMはスレッドやプロセスを跨いだメッセージ通信
で実現されていますので双方がCOMであればイベントという概念すら必要あり
ません。単にメソッドを公開してコールしてもらうだけだからです。
という誤解を生んでいると思うのです。COM対COMならC++でもJScriptや
VBScriptでディスパッチオブジェクトを扱うのと何ら変わらないのです。
じゃぁなぜ皆さんがそうしないのか？つまりなぜC++でIDispatch継承クラス
を書かないのか？問題はそこに帰着すると感じています。
で最短のディスパッチ継承クラス作成コードを解説しています。会員認証
はどんなメールアドレスでもサーバーが自動返信するアカウントを受信
できれば有効ですので気軽に登録してください。コードを眺めても最初は
なんのことやらと感じるでしょうが、動かしながらあちこち書き換えるうち
にCOMの本質が理解できるのではないかと思います。
↓
【政府調達】韓国ベンチャー企業が、日本政府機関のプロジェクト受注 日本で外国ベンチャー企業がプロジェクトを受注するのは極めて異例
http://toki.2ch.net/test/read.cgi/wildplus/1302842274/
1+1 ：影の軍団(第弐拾八期首席卒業生)ρ ★ [] ：2011/04/15(金) 13:37:54.21 ID:???
韓国ベンチャー企業のウィズドメインが、日本の新エネルギー・産業技術総合開発機構
（ＮＥＤＯ）の特許情報収集サービス事業を受注した。
大韓貿易投資振興公社（ＫＯＴＲＡ）が １４日、明らかにした。
ウィズドメインは昨年下半期（７〜１２月期）からＫＯＴＲＡが運営する東京の
コリアビジネスセンター（ＫＢＣ）ＩＴ支援センターの諮問を得て、
２０社が参加した 今回のプロジェクトで受注に成功した。
日本の政府調達市場で外国ベンチャー企業がプロジェクトを受注するのは極めて異例だという。
エンジニアを育成して実現することなのですが、私もかつて役人の端くれと
して感じたのは情報処理みたいに日進月歩な世界の勉強をしようとしないん
ですね。そうしなくても飯が食えるし、外注することで民間へ税金を還流し
ているというばかげた発想でいるんです。で入札を国際的に開放すれば海外
の企業が受注するのはある意味しかたのないことだと思います。
もし私が政治に関与できる立場だったら「情報処理」を統括する官庁を作って
自前で開発させますし、いいものができたら他国へ売り込んで外貨を獲得する
という発想で取り組むでしょうね。
のですが、この国の状況は将棋で言えば「詰めろ」から「必至」に変化した
と感じています。一度「参りました」というのも選択肢の一つだろうと思い
ます。私が若い方々に言いたいのはことソフトウェアの分野においてもはや
「国」を意識する必要は無く、貴方の労力は世界が評価してくれるというこ
とです。その礎を、せめて礎を置く地ならしをできればというのが私の想い
です。
細部の調整を行い、ヘルプも８割くらいは書きあがったかなぁっという状態
です。このプロジェクトは単体ファイルとしたいことからヘルプも全部リソ
ース格納していますので700kのサイズですが、本体は100k位の軽量さです。
経験した者にとっては夢のような環境だとつくづく思います。コンピューター
は今も昔も、そしてこれからも単にディスプレイのピクセルを光らせているだ
けです。プログラマーは任意なピクセルを何色に光らせるのかをコントロール
していると言えます。DOSの時代でもウインドウやボタンを表示させることは
できましたし、気の効いたアプリケーションには必須な要素でもありました。
ただし1ピクセルづつコントロールする必要があります。もし複数のウインドウ
が重なって下になった領域のピクセルデータを保存、復元しなければならない
としたら恐ろしく煩雑な処理を記述するはめになるでしょう。
タブコントロール、ツールバー、ステータスバー、任意な数のHTMLウインド
ウ任意な数のエディタウインドウとその上のリッチエディットコントロール
を制御できるのですから、感心してしまいます。欲を言えば10年前に今の
心境に到達していなかったのが残念です。私はまだ己の知力が低下してきて
いるとは思いませんが、体力のほうはもはやぼろぼろな状態です。
恐らくタブコントロールというのはサイズ可変なウインドウではなくダイア
ログ等に置くことを前提としているらしく、ウインドウのサイズを可変する
といやらしくチラついていたのでその対策を施しました。またHTMLウインド
ウのスクロールバーもサイズ可変中は領域外へ表示を逃がしています。
ボタンスタイルのタブを使っていたのですが、特定の条件下で描画の整合性
が失われますので、悩み抜いたあげく普通のタブ表示に変更しました。
HTMLウインドウのスクロールバーもサイズ変更時はチラチラしますけど隠す
ほどのことでもないという判断から元に戻しました。いずれの課題も書こう
と思えばなんでもありなのですが、余計なことを書きすぎると全体がもっさ
りしますのでご了承ください。
けられます。HTABOXの場合はメインになるHTMLインスタンスが複数という状態
は有り得ませんがこのブラウザはすべてのHTMLインスタンスが主役ですのでよ
り過酷な面があります。過酷さゆえにHTABOXを書きながら「これでいいのか？」
と感じていた部分をきっちりと指摘してくるので大変勉強になります。
タブで実行中HTMLへのファイルドロップ、ファイル選択ダイアログを追加し
ました。ファイルドロップについてはHTABOXと同等でwindow.onFileDropが
存在すれば引数としてパスが渡されます。今回はまじめにVB用として
Window_onFileDropが存在するかも検査しています。
ファイルコモンダイアログは短めの名前にさせていただいて。
var path = TZB.FileOpenDlg("タイトル", "text\\0*.txt\\0", "c:\\", "*.txt");
var path = TZB.FileSaveDlg("タイトル", "text\\0*.txt\\0", "c:\\", "*.txt");
こんな感じです。上記例のTZBはdialogArgumentsから取得してください。
扱いに苦慮するのですが、このブラウザで採用しているスレッドの設計方法は
当りだったようでHTMLウインドウの再描画を阻害することなくごく当たり前に
ダイアログを移動することができます。HTABOXの方ではもっと込み入った方法
となっていましたのでフィードバックできればより軽量なものにできそうです。
当然の展開としてフォルダダイアログを追加しました。これもオプション等
の細かいことを考えずに呼び出せるよう引数は少なく設計しました。
var fld = TZB.FolderDlg("Title", "c:\\");
「細かい事をやりたい方はHTABOXで」というすみわけを考えておりますので
TZBのHTMLへ提供すべき機能はこれくらいでいいのではないかと思っています。
表示に使っているエディタウインドウの軽量化版をスクリプトから操作でき
るようにしました。通常リッチエディットの書式設定は煩雑な操作を伴いま
すが、ラップして簡潔なものとしました。このウインドウは非表示で動作で
きます。したがって非表示のままTOM（Text Object Model）を操作すれば任
意なコードページのファイル入出力を行い文字列を取得、保存することが可
能です。追加関数は数個なんですが、ここでは見苦しい解説になりますので
サンプルソース付のβ公開をお待ちください。
EditDemo.htmをブラウザで開くとデモをご覧になれます。自分で動かしても
感じるのですが、HTMLをWIN32ウインドウで包括することによってHTML特有の
もっさりしたウインドウ構築動作を感じさせないメリットがあるようです。
何らかの連続動作を行っていて多量のログをリアルタイムで表示しなければ
ならないような局面でも威力を発揮すると思います。HTMLの場合setTimeout
等でスタックを開放した再突入を行わなければリアルタイムなinnerTextの
更新、表示はできませんのでこういうのが欲しいと考えていました。
標準のタブ外観はどれがアクティブなのか分かりにくいので非アクティブな
タブ外観だけをフラットに上書きする処理を行いました。新規ページの初期
サイズを0pxとし、タブに治まる直前のチラつきを抑制しました。
動作が欲しいと書き込むと具体的なコードを生成してくれるエディタです。
いままであらゆるプログラミング言語は実世界の問題を一旦抽象化したコード
という形にしなければなりませんが、そのステップを自動化するんです。
「言語解析」「エディタとサーバーの通信」「モジュールデータベース」
「自身のコードが再利用されても構わない多くのプログラマ」「若干のAI」
そんな要素がそろえば実現できなくもない気がします。
2ch 書き込み 保守
と検索すると、２ｃｈに書き込みするクラスと、その呼び出し方がダウンロードされて表示されるわけですね。
本当にありがとうございました。
軽量がコンセプトなのだから変に小細工しなくていいのでは……？
もし、見た目にこだわりたいのなら
・クラシック
・XPのLuna
・Vista以降のAero
この3つの環境になじむようにすべきでは……？
名前で問い合わせる決まりごとなわけです。もし、仕事の内容で「こういう
モジュールもっていますか？」になれば、あながち夢物語でもない気がする
のですが、勿論現在の私にそれを実現する力量があるわけではありません。
多くのモジュールからのチョイスなのか、もっと抽象化されたモジュールを
若干の自動化で具象化すべきなのかとか、そのへんのイメージすらありません。
Vista以降での外観はまだ確認していませんでした。Lunaではテストしていま
すが、「ダサい」の意味が理解できません。いわゆるテーマに対応した外観
を形成しなさいという意味でしょうか？
<META HTTP-EQUIV="MSThemeCompatible" CONTENT="Yes">
を入れてテストして確認しましたが、きちんと機能するようです。メニューや
タブをオーナー描画でビットマップにしなさいという意味でしょうか？
してますけど、TZBのメニューはグレイですね。動作PCのコモンコントロール
バージョンを識別した処理が必要なのかも知れません。貴重なご指摘ありがと
うございました。
メニューバーやツールバーやタブや右下のツマミがVistaでもクラシックな表示だったので気になりました。
「ダサい」とはそういう意味です。郷に入らば郷に従って欲しいと思います。
今度から具体的に書くようにします。クレーマーみたいで本当にすいませんでした。
私の欠点は「書くのは好きでも動かすのは嫌い」なことなんです。なんで2ch
に独白スレッドを作っているかと言えば、動かないとか、ショボイ場合は容赦
なく指摘されるだろうという目的なんです。今回のご指摘でテーマ、マニフェ
ストに関して本腰を入れて勉強する機会をいただきました。本当に感謝してい
ます。
マニフェストをリソース格納しコモンコントロールバージョン6に対応しまし
た。
な動作確認のためだけに動かしていましたが、あらためて眺めると結構いろい
ろと違うんですね。一番驚いたのが「特大アイコン」です。この大きさの32ビ
ットビットマップでアルファマスク付ならそれだけで1Mb近くになるんじゃない
でしょうか。
でもエラーとならないよう動的にUxTheme.dllから関数をロードしテーマが
当該アプリケーションで要求されているかを判断して非選択タブの外観変更
を行うようにしました。テーマが適用されている場合は選択、非選択の区別
が明確なので余計な動作は回避しようという意図です。
タブ上の右クリックメニューに「タブ挿入」を追加しました。
今日もサンプルスクリプトが進展しなかったことを深く反省しています。
でもHTABOX3のリリースに向けて大変有益な情報をいただいた日でした。
全表示パス又はURLの保存、再現機能にバグがあったので訂正しました。
全タブ情報TZBファイルはメニューの保存だと自動的にフルパスが保存され
ますが、手で書く場合面倒だと思うので、相対パスと判断した場合TZBファイ
ルの親ディレクトリを付加して絶対パスを合成します。URLの場合は絶対パス
で無ければなりませんが、一旦GETしての存在確認では重いので単純に存在を
信じる仕様としています。
現実にはそういう手法をとるんでしょうね。特大の世界になるとイラストレー
ターとしての才能が試されるし、私にはクールなイラストを書く才能が無いの
で衝撃でした。
まだ完成までは一息の状態ですがスクリプトからタブをコントロールする部分
の解説とサンプルソースは完成しました。Helpを表示して「タブコントロール」
の項目をご覧になるとこのブラウザの特徴が良く理解できると思います。
る造りになっていますが、HTABOX3は更に表示されたソースをその場で編集
して実行できる造りになっています。JScript、VBScript、両者の.NET言語
の4種類をパースして実行します。ただHTABOX3は私にとってフルスイングな
プログラミングとなりましたのでどこか余裕の無いものに感じられていまし
た。例えば見やすく理解しやすい説明を書く余裕が無いという懸念です。
TZBです。今日の午前中までヘルプHTMLの仕様に悩んでいましたが、決定し
てしまえば、HTABOXと比較して機能は多くありませんから半日で概ねの内容
を書き上げることができました。自分で総てを管理しているメリットとして
ヘルプを書きながら、「こういう関数が必要」に気づき、さもあるかのよう
に説明を書いた後に実装することもあります。結局、取り説を書くという作
業は使う側に立った作業でなければなりませんから、その時に心がぎすぎす
していては何も伝わらないものができてしまうと感じています。
にしても構わない設計としています。COMやHTABOXを使わなければHTMLアプリ
ケーションの姿は旧態然としたままなわけですが、私のことを気にかけてく
ださる開発者の方からバイナリ依存のHTAは検査ができないから商品にならな
いというお話を伺ったんです。まぁそう言われれば身も蓋も無い訳ですが、
もし、ソースが公開されていて安全な事が保障されているHTAの機能拡張環
境が存在すればHTAも前へ進むことができるんじゃないかという発想です。
多分非公式関数扱いなのですが、
TZB.CreateSoundBuffer(location, "test.wav");
TZB.PlaySoundBuffer(0);
をデモするsound.htmとtest.wavが添付されています。
DirectSoundの特徴はWAVバッファを事前に作成し、再生要求に対して即座に
応答することです。デモで使用しているモジュールは全WAVデータを保持しよ
うとします。しかもB級でもオーディオマニアが書いたモジュールですので
16bitステレオPCMのみ対応ですから効果音程度の大きさのファイルで遊んで
ください。
ファイルのアイコンをドロップするとすべてタブ表示しようとします。
どっさり複数のHTAでも構いませんし、複数パスを記録した拡張子TZBなら
表示順を確実にコントロールできます。DirectSound系モジュールはデモの
効果音再生用の他に長時間録音用、長時間再生用モジュールもありますので
こっそり実装するかも知れません。
ている画像を常に光っていると勘違いするほど時間にルーズなのですが、耳
という感覚器は時間にシビアです。毎秒340m進行する音波を僅か20cm間隔の
両耳で受信しその時間差とエネルギー差から音源の方向を推定するわけです
から神様にしか創れないほど精巧な器官だと思います。
ィーより高度であると言えます。ただじっと目を閉じてその音が作り出す空
間や、イメージを楽しむようなアプリケーションをいつか書きたいと思って
います。
提供関数等に関するヘルプはほぼ書き終えたと思います。
また、リッチエディットのCOMインターフェース解析結果を付録として掲載
しました。MSWORDでVBAを書いた事のある方ならその構造がそっくりなこと
に気づかれると思います。
自分の勉強にもなりますしDirectSound系関数も正式な機能として付加する
ことにしました。DirectSound.htmが添付していますのでexeへドロップすると
デモをご覧になれます。まだDirectSoundスレッドの振る舞いを理解しきれて
いない部分があって、意地悪な操作をすると止まったりするかも知れませんが
ご容赦ください。確かDirectXはスクリプト向けCOMサービスもあった気がし
ているのですが、このモジュールは考えうるかぎり軽量に仕上げました。
一般的なコンピューターのSN比はもともとたいしたものではないのですが、
それでもCPU負荷を抑えることでベストなSN比を目指そうという方向性です。
_COM_SMARTPTR_TYPEDEF(IDirectSound,IID_IDirectSound);
から書き始めると結構見てのとおりな記述ができるのですが、いままでそい
う記述をする方を見たことがありません。以前にも書きましたが、DirectX
の上層にある機能はハード依存しますので苦労の割りに得るものが少ないと
思いますが、低層な部分は今後も有効だと思われますので、機会があったら
最初からCOMとしてDirectXを扱う解説を書いてみたいと思っています。
ウインドウフォーカスが外れても再生を継続する設定としました。この辺は
目的と、好みにもよりますので将来は選択できるようにしたいと思います。
がメソッドは統一しています。比較的小規模なWAVを再生するSoundBufferで
説明します。
var TZB = window.dialogArguments;
var Sound = TZB.CreateSoundBuffer(location, "hoge.wav");
CreateSoundBufferは2つの引数を取ります。第1引数は第2引数に相対パスを
指定する場合locationでなければなりません。第2引数が絶対パスである場合
はnullを指定してください。返却値であるオブジェクトには下記のメソッド
があります。引数や返却値はありませんし、そのまんまの名前なので説明の
必要はないと思います。
Sound.Start(); Sound.Pause(); Sound.ReStart(); Sound.Stop();
ファイルを保持するのは不利ですが、一旦読み込めば再生要求へのレスポンス
は俊敏です。MusicBufferは3分割した環状バッファにより大規模なファイル
を部分的に読んで再生します。CaptureBufferも同じく3分割した環状バッファ
により再生中の音をキャプチャしてRAWPCMで保存します。Stop()関数が呼ばれ
た場合、Create時に指定されたファイルへPCMを再編しWAVファイルとして出力
します。
で認識していますので4G以上のファイルでの動作は未定義です。結構WAVデー
タは大きなサイズとなりますので、録音時の一時ファイルを分散させて再編時
に無音を検出し、適切なサイズのファイルを自動生成するというような機能
を追加すべきだろうとは考えています。
アでエミュレートしようとします。Draw系なら描画が「もたつく」という結果
になるわけですが、Sound系の場合「ノイズ」に結びつく事があります。です
から、多くのエフェクトを追加してゆこうという気はありませんが、是非こ
れだけはというご要望がありましたら気兼ねなく書き込んでください。
MusicBufferの中断、再開動作で再生位置が乱れるバグを修正しました。
録音の方は中断すると以降無音ですのでこれから原因を追求したいと思います。
CaptureBufferの中断、再開を修正しました。録音の場合はバッファ長を短く
設定し、操作と録音の開始、停止タイミングのずれを少なくしました。
あと、ボリュームとバッファが稼動しているかを問い合わせる機能は必須で
すね。欲を言えば一定時間の信号レベルを数値で返してプログレスバーのよう
に表示する手がかりを提供できればいいんですけど、その辺は今後の課題と
いうことで。
のですが、あらためて触ってみるとなかなかよくできています。特にPCMクロ
ックを再生時に可変できるのが素敵です。勿論ハードがそのクロックに対応
していることが条件でしょうが、48KHzならほぼ総てのハードが対応している
のではないでしょうか。だとすれば44.1KHzを伸張しながら補間を加え自分の
アレンジしたより高音質な音楽として再生することが可能です。これが96KHz
なら補間の仕方によっては劇的な変化を期待することもできると思います。
再生系バッファにステータス取得、クロック設定、左右バランス、ボリューム
機能を実装しました。録音バッファはステータス取得のみとなります。
var Status = Sound.GetStatus();
Sound.SetClock(48000);//48KHz
Sound.SetPan(0); //中央
Sound.SetVolume(0); //減衰なし
のような使い方になります。解説はTZBのリリースをお待ちください。
TOP カテ一覧 スレ一覧 削除依頼 ▲
・ 次のスレ
Coqスレ
xkeymacs
！世界を変える検索エンジンを思いついた
進歩しない人の特徴