ウィンドウを閉じると自動で削除されるフォルダ

一時的なファイルの置き場所（用が済んだら削除したい）が欲しい時があります。
ウィンドウを開くと自動で専用のテンポラリフォルダが作成され、閉じると削除前の確認メッセージを経て削除される、というプログラムを作成しました。

miniライブラリをもう少しminiにしつつデバッグ

関数リストと動作確認用サンプルをセットで保存するminiライブラリを先日公開しましたが、これが思いのほか使いやすくて気に入っています。
少し改良しました。

テキストエリア内でのタブキー操作

先日「textareaでタブスペースを入力できるようにする」という記事を作成しました。
その後、そのサンプルを使っていたら「選択範囲末尾の改行がうまく制御できていない！」ということに気が付きました。

末尾の改行にも対応するサンプルを作成しました。

テキストエリア内のカーソル行、列を取得・設定する

テキストエリア内でカーソルが何行目の何列目にあるのかを取得したり設定するためのサンプルを作成しました。

HTA専用（クロスブラウザにしようと思えばできることだけど、難解なのでHTAに特化することで少しでも分かり易くしたい）です。

相対的日時を取得する関数

用途・目的

「来月１日」とか「先週火曜」のような相対的日時を取得するための関数を作成しました。

日時の省略表記を解釈してDateオブジェクトを返す関数

例えば「1110」は「2017/03/26 11:10」と解釈します。
「11/10」の場合は「2017/11/10 00:00」と解釈します。
解釈に失敗した場合でもDateオブジェクトを返しますが、その場合は年月日時分秒のすべてが「NaN」になります。

日時を指定フォーマットの文字列に変換する

用途・目的

Dateオブジェクトを「str = dat+''」のように文字列化すると「Fri Mar 3 11:05:46 UTC+0900 2017」のような形式の文字列になります。
「2017/03/03 11:05」のような形式で取得したいときは「obj.getStr('Y/MM/DD hh:mm')」で取得できるようにするための関数を作成しました。

getChildsを修正

「<button>開始</button>」を「obj.btn開始」のように参照できるようにするための、getChildsを先日公開しましたが、以下の問題がありました。

１．「obj.btn開始.removeNode(true)」のようにするとbtn開始のエレメントはリムーブされますが、エレメントへの参照用プロパティ「obj.btn開始」は残ってしまい、参照が残っているのでエレメントもメモリ上に居座り続けてしまう。
２．「tableメイン」のようなエレメントをリムーブした場合、そのエレメントに含まれる子孫エレメントへの参照も残ってしまう。

上記の問題を解消するためのメソッドを追加しました。

参照渡しでも数が多ければそれなりにメモリを使用する

情報のコピーは値渡しよりも参照渡しの方がメモリ使用量が少ない、というのはイメージできますが、実際に参照用プロパティを増やしまくるとどれくらい使用量が増すのか確認しました。

参照用プロパティを10000個作成する前後のメモリ使用量の差の平均が982KBでした。

１個あたり0.1KBくらいのようです。

「innerText = ''」にしても元の中身を参照している変数があるとメモリ解放されない

エレメントに限りませんが、メモリ上に展開しているデータはどこからも参照できない状態になると始末されてメモリの空き容量が増えます。
document.body以下のDOMエレメントは「document.body.innerText = ''」とすることで画面上からは消え去りますが、innerTextを変更する前に「var elem=document.body.firstChild」などを実行していた場合は、innerText変更後でも「elem」変数の中には元のエレメントが存在します。つまり、メモリは解放されていません。

意図せず参照が残って解放されないものが溜まっていくとメモリ不足になってPCの動作がモタついてしまいますが、具体的にどのくらい消費してしまうのか確認しました。

メモリ解放のタイミングと解放量のデータ

プログラムで使用するメモリはその他のプログラムなどと共有していて、そのメモリを管理するシステムが状況に応じて色々と処理するので、自身のメモリ使用量を確認するプログラムを作成しても結果がいつも同じということはなく、バラつきがあります。

複数の条件の試験結果を比較したい場合はそのバラツキも考慮しなければいけませんので、どの程度ばらつくのか確認しました。
その過程でHTAでのメモリ解放のタイミングと解放される量が少し分かりましたので試験データと併せて記録・公開します。

setTimeout(func,0)を複数回連続実行した場合のfuncの実行順

setTimeoutを使うと任意の関数を任意の待ち時間後に実行させるよう予約できますが、以下のようにした場合実行順は予約順になるのか確認しました。

setTimeout(funcA,0)

setTimeout(funcB,0)

setTimeout(funcC,0)

結論としては、予約順でした。

エレメント追加によるメモリ使用量の変化を調べるサンプル

経験的に、よほど大規模なアプリケーションを作るのでなければ気にするレベルではないとは思っていますが確認しないと気が済まないので確認用サンプルを作成しました。

結果としては「<div></div>」１つを追加すると250バイトぐらい増えるようです。

innerTextプロパティを書き換えることで対象エレメントの子要素を削除する方法でもメモリ使用量が低下することが確認できました。

textareaでタブスペースを入力できるようにする

プログラムを書く人にとってはインデントするために必要なタブスペースですが、ブラウザ上でのタブキーの役割はフォーカス移動なので、デフォルト状態ではタブスペースを入力できません。

入力できるようにするサンプルを作成しました。

インクリメンタルサーチ式ミニライブラリ

プログラミングの際に利用する定型文とそれを識別するためのキーワードをセットにして保存・検索するためのプログラムを作成しました。
サンプルプログラムもセットで保存することができ、動作確認が容易にできます。

メソッドの上書きによる高速化

先日、メソッド自身を上書きして次回呼出し時は初期化処理を省くという記事を作成しましたが、実際にどれぐらいの差がでるのか検証していませんでした。
その検証を行いました。

結論としてはメソッドの上書きは効果アリでした。
初回起動時のみfunction自身にメソッドを追加して以降はそのメソッドを呼び出す方法と比較して３倍の速度が出ました。（とは言え、遅い方でも１回あたり3マイクロ秒程度ですが。。）

正規表現の動作テスト用hta

正規表現を使うとテキストに対して複雑な検索・置換ができるのでとても便利ですが、構文が記号だらけで意味不明になりがちです。
正規表現を利用するプログラムを作る時は、正規表現の部分だけで意図した通りの動作をするか確認してからプログラムを作ると作業がスムーズに進みます。

正規表現だけで動作確認するためのプログラムを作成しました。

メソッド自身を上書きして次回呼出し時は初期化処理を省く

例えばメソッドの内部で正規表現を扱う場合、その正規表現のパターンが毎回同じならメソッドが呼ばれる度に正規表現の再コンパイルするのをやめて、以下のようにするとコンパイルは初期化時一回のみになるので次回呼出し以降の実行速度が向上します。

	<job>
	<script>
	obj={
	abc:function(){
	// この部分は「obj」にオブジェクトが代入される前に実行される
	var reg=/\d+/
	// 下記functionが「abc」プロパティにセットされる
	return function(str){return str.match(reg)}
	}()
	}
	// 123
	WScript.Echo(obj.abc('adqq123qr'))
	</script>
	</job>

view raw object作成時に初期化.wsf hosted with ❤ by GitHub

しかし、だからといって初期化とメイン処理を分けられるものを何でも上記のようにしてしまうとローディングにかかる時間が伸びてしまいます。

フレームワーク級のオブジェクトの中身でこれを多用されると待ち時間が酷いことになります。初期化しても実際には呼ばれないメソッドなども多々あると思いますので、そういう意味でもムダです。

上記のような問題を解決するために「初回呼出し時に初期化して自身をメイン処理用functionで上書きする」ための関数を作成しました。

一次元配列内の数値を補正する

用途・目的

折れ線グラフを表示して、山の頂点から下までの高さの数値が欲しい時があります。
しかしデータの取り方によってはそのグラフが傾いていて、そのままでは知りたい部分の数値が分からないことがあります。
グラフの両端の値が等しくなるように傾きを計算して補正するサンプルを作成しました。

オブジェクト作成と関数呼び出しの時間を比較

オブジェクト型の引数を扱う関数をコールする際、あらかじめ用意しておいたオブジェクトの一部だけ変更して渡すのが速いか、オブジェクトを都度リメイクしても変わらないのか比較してみました。

リメイクするオブジェクトの規模にもよりますが、今回の条件ではリメイクすると一回あたり50～80%ぐらい余分に時間がかかります。

3D等高線グラフデータの傾きを補正するHTA

こんなヤツ（↓）を


こんな風（↓）にするために


三角関数を駆使するサンプルを作成しました。

小数点以下の桁を含む数値を一時的に整数化する

例えば「(-20.41) - (-43.3)」をJScriptで実行すると、答は「22.89」になる筈ですが実際には「22.889999999999997」という結果になります。そういう仕様ですが、もちろんこれでは困ります。
計算中のみ一時的に10とか100などの数字をかけて整数にして、最後に桁を元通りにすれば上記の問題を回避できます。

そのための関数を作成しました。

idのないiframeのlocationをgetする方法

iframeのlocationプロパティの値を取得したい場合はiframeに対応するフレームエレメントをframesから取得することが必須ですが、document.body以下のiframeとframes以下のエレメントを紐付ける方法はid以外に見つからない、という記事を先日書きました。

ページ内に存在する既存のiframeについては紐付けは無理ですが、スクリプトから新規作成するものについては可能なことに気が付きました。

以下がそのサンプルです。

ロック中のファイルアクセス回数を低減するサンプル

昨日公開した一時保留.htaでは、ファイルに対する処理をfunction形式で受け渡して、functionを配列に入れて、ロックに成功してアクセス権を取得したら配列内の関数を一つずつ実行していました。
その配列をテキスト化したものが以下になります。

fso.Read、fso.Writeはファイルに対する読み書きを行っています。
一つの関数内で読み書きを1セット行っています。

ファイルに対する処理が三回分まとまると以下のようになります。

かなり冗長な感じです。
対象ファイルのサイズが小さければ無視して良いかもしれませんが、サイズが大きいとか、ネットワーク越しで利用していてネットワークの転送速度が遅いとかいうことになると無視できない話になってきます。
この問題を解消するサンプルを作成しました。

断続的に発生しうる処理を一時的に貯める関数

一つのファイルに対して複数の読み書き要求が同時に発生しうる場合、先日公開したファイルロック.htaを使えば良いのですが、先日のソースではファイルに対する処理のタイミングが他人ではなく自分自身とも競合してしまい待ち時間が長くなってしまう状態でした。

例えばZ:\TEMP\lockTest.txtに対してアクセスしているのが自分ひとりだけだったとしても、数秒以内に複数の項目を書き換えるとそれぞれの操作に対して個別にファイルロック機能が働いていました。

連続した操作による変更なら出来るだけまとめた方が、ファイルのアクセス権獲得のためにロック試行を繰り返したりロックできなくて待機したりという時間を減らせます。

本日のソースでは変更操作を行ってもすぐにはファイルをロックせず、数秒以内に次の操作が行われればそこからまた待機時間を設けて期限が切れたらファイルをロックして変更を反映します。

プログラム終了後にファイルを削除するHTA

処理に必要な一時ファイルをプログラム起動時などに作成し、終了時に削除したい場合があります。
onbeforeunloadイベントを使えばそのようなことができますが、同様に「プログラム終了時に実行したい処理」が複数ある場合は「window.attachEvent」で各処理を登録するのが安全策ですが、各処理の実行順が重要な場合はattachEventに任せるのも危険です。

hta内で実行順などを考慮するのが面倒なので、htaのプロセスIDをwsfで監視して、プロセスIDの終了を検知したら関連ファイルを削除させるサンプルを作成しました。

ファイルロック.htaで後始末用functionに対応

先日までのファイルロック.htaではファイルのロックに成功するまでwsfが待機して、成功したらwsfが終了するだけでhta画面へのフィードバックがありませんでした。

本日のサンプルではコマンドラインのリダイレクトを使ってwsfファイルの終了を検出するようにして、wsfファイルが終了したら後始末用の関数を実行するようにしました。

scriptを共有するサンプル

「外部スクリプト.js」などの名前のファイルを作成して、「<script src="外部スクリプト.js"></script>」のようにするのが普通だと思いますが、構成ファイルが複数個になるのは少し都合が悪いです。

ブラウザでは動的にscriptタグを追加するテクニックがありますが、HTAで試したらうまく動作しませんでした。

上記２つの理由により、HTAファイル内に記載したscriptをWSFファイルなどと共有するサンプルを作成しました。

ネゴシエーション式ファイルロック（成功するまで待機）

昨日のサンプルはロック開始ボタンを押した瞬間だけロックを１回トライするものでした。
本日のサンプルは、ロックが成功するまで適当に待ち時間を挟みながら繰り返しトライして、ロックできたら編集を実行します。

ネゴシエーション式ファイルロック

複数のPCから一つのファイルに対してRead・Writeが同時に行われる可能性がある場合、誰かが更新作業中はファイルをロックして更新できない状態にしておかないとファイルの中身の整合性が失われてしまうケースがあります。

そのようなケースを回避するためのサンプルを作成しました。

SJISでWriteするとエラーになるけどReadしてもエラーにならない文字

CreateTextFileメソッドを使う際、デフォルトではASCIIファイルが作成されますが、特定の文字を含む文字列をASCIIファイルとして保存しようとするとエラーが発生します。
その具体例を作成しました。