たぶん、見て価値があるのは2006年以降。2004年と2005年は試行錯誤した様子を日記として書いていたので、無駄な情報も多いです。
自分用の備忘録なので、細かい説明は書いていません。あしからず。
09.10.13に書いた方法は、ページを去る直前に機能が発動してしまうので、動画ページ以外へ離脱しようとするときもプレイリストに戻されてしまう。
仕方が無いのであまりキレイではないけれど代替策を講じた。具体的には、動画ページをロードする時、次に再生すべき動画ページを取得するとともに、前回保存された再生すべき動画ページと現在の動画ページを比較して違っていたら本来再生すべき動画ページへ飛ばすのだが、ただし現在のページが動画ページ以外だったら何もしない、というちょっとトリッキーなアルゴリズム。
自動ジャンプページの場合、ほぼ確実にそちらへ飛んでから、上記の機能が発動するため、見てもいない動画が一瞬再生されたこととして履歴に残ってしまうのが難点。気持ち悪いといえば気持ち悪いのだけれど仕方が無い。unload時、次に表示されるページを取得できればよかったのだけれど、それはセキュリティ上の問題で出来ないらしい。
それででは解説。
335行目付近にある playNext 関数の、以下のように「//???」となっている行をコメントアウトするとともに、直後の347行目付近へ「//???>>>>>>」から「//???<<<<<<」で囲まれたコードを追加する。
playNext: function () {
//???var video;
//???if (this.random)
//??? video = this.playlist.popRandom();
//???else
//??? video = this.playlist.pop();
if (video) {
if (this.loop) this.playlist.push(video);
this.playlist.save();
video.play();
}
},
//???>>>>>>
reserveNext: function() {
video = null;
if (this.random)
video = this.playlist.popRandom();
else
video = this.playlist.pop();
return video;
},
video: null,
//???<<<<<<
それから、ソースの最後付近に以下の「//???>>>>>>」から「//???<<<<<<」で囲まれたコードを追加する。
//???>>>>>>
window.addEventListener("load", __NicoNicoPlaylistLoad, false);
function __NicoNicoPlaylistLoad(){
var shouldBePlayedUri = GM_getValue("shouldBePlayedUri", "");
if(window.location.href.indexOf("http://www.nicovideo.jp/watch/") == 0 && window.location.href != shouldBePlayedUri && shouldBePlayedUri != "" ){
window.location.href = shouldBePlayedUri;
}else{
var reservedUri = controller.reserveNext().getPlayUri();
if(window.location.href.indexOf("http://www.nicovideo.jp/watch/") == 0){
GM_setValue("shouldBePlayedUri", reservedUri);
}else{
GM_setValue("shouldBePlayedUri", "");
}
}
}
//???<<<<<<
})();
【Firefox について】バージョン=3.5.7／ダウンロードページ=http://mozilla.jp/firefox/
【NicoNicoPlaylist について】バージョン=1.13／ダウンロードページ=http://d.hatena.ne.jp/kotas/20091219/playlist
【Greasemonkey について】バージョン=0.8.20091209.4／ダウンロードページ=
※上記情報はいずれも 2010.01.19 現在。
Visual Studio 2008 の C++/CLI でプログラムを作る場合、プロジェクトのプロパティで「共通言語ランタイムのサポート」を「安全な MSIL 共通言語ランタイム サポート (/clr:safe)」にしないと、プログラム全体で 2GB までしかメモリを使用できない。
Greasmonkey は Firefox のアドオンで、任意のページに自分で書いた Javascript を埋め込んで実行させることができるという便利ツール。
それで最近「ニコニコ動画でプレイリストが使える Greasemonkey スクリプト（NicoNicoPlaylist）」というものを使ってニコニコ動画を再生している。
ところが、動画中にニコスクリプトで自動ジャンプが設定されていると、NicoNicoPlaylist でジャンプする前に次の動画へ飛ばされてしまう。これは都合が悪い。
この対策として、NicoNicoPlaylist のコードを以下のように改変して使わせてもらっている。
//712行目付近 元コード
})(function () {
var t = setInterval(function() {
if (player.getStatus() == "end") {
clearInterval(t);
controller.playNext();
}
}, 1000);
});
}
//
// Style definitions
//
//712行目付近 改変コード
})(function () {
var t = setInterval(function() {
if (player.getStatus() == "end") {
//???ニコスクリプトによるジャンプ対策
__unloadedByNicoNicoPlaylist = true;
clearInterval(t);
controller.playNext();
}
}, 1000);
});
}
//???ニコスクリプトによるジャンプ対策
window.addEventListener("unload", __NicoNicoPlaylistUnload, false);
var __unloadedByNicoNicoPlaylist = false;
function __NicoNicoPlaylistUnload(){
if(!__unloadedByNicoNicoPlaylist){
controller.playNext();
}
}
//
// Style definitions
//
原理は単純。unload イベントハンドラ内で、フラグを使ってこのイベントが NicoNicoPlaylist によるページ遷移で発生したのかそうでないのかを判定し、そうでない場合は本来行われるべき NicoNicoPlaylist のメソッドを実行している。ただし、上記の改変はあんまり細かくチェックしていない。今のところうまく動いているけれども、これは自分用のメモなのでもしまねされる方がいれば自己責任で。
【Firefox について】バージョン=3.5.3／ダウンロードページ=http://mozilla.jp/firefox/
【NicoNicoPlaylist について】バージョン=1.12／ダウンロードページ=http://d.hatena.ne.jp/kotas/20080725/playlist
【Greasemonkey について】バージョン=0.8.20090920.2／ダウンロードページ=
※NicoNicoPlaylist のバージョンは、ダウンロードページには 1.10 と書いてあるんだけど、実際にダウンロードしてみると 1.12 になっている。
※上記情報はいずれも 2009.10.13 現在。
Visual Studio （2008 で確認） の C++ でフォームを作成すると、クラス宣言の冒頭に以下のような注意書きが書かれている。
/// TestForm の概要 /// /// 警告: このクラスの名前を変更する場合、このクラスが依存するすべての .resx ファイルに関連付けられた /// マネージ リソース コンパイラ ツールに対して 'Resource File Name' プロパティを /// 変更する必要があります。この変更を行わないと、 /// デザイナと、このフォームに関連付けられたローカライズ済みリソースとが、 /// 正しく相互に利用できなくなります。
これは名前空間でも言えることらしい。特に、名前空間を深くするときは注意が必要だ。クラス名の変更だけなら全置換で済むけれど、名前空間を深くした場合には namespace 宣言を修正したり、usingnamespace を修正したり、「::」演算子を使うように修正したりしなければいけないので、一筋縄にはいかない。そしてもっとも注意すべきが .resx の「プロパティ ページ」を開いて「マネージ リソース」という項目の「リソース ファイル名」を修正しなければいけない点だ（この項目値に合わせて .resources ファイルが作成され、最終的にアセンブリ本体へ埋め込まれる）。クラス名の全置換ならプロジェクトを管理するファイルも含めて全部修正できるからよいのだが、全置換が出来ない以上、こういった細かな修正も手動で行わなければならない。
ちなみに、名前空間やクラス名の変更が .resx に反映されていないとリソース（アイコンなど）読み込み時に以下のような例外が出る。
MissingManifestResourceException 指定されたカルチャまたはニュートラル カルチャに対して適切なリソースが見つかりませんでした。"Parof.Test.TestForm.resources" が適切に埋め込まれたか、実行時にアセンブリ "Test" にリンクされたか、または必要なサテライト アセンブリが読み込まれて完全に署名されていることを確認してください。
これは、名前空間「Test」の下に「TestForm」を作成した後、名前空間「Test」を名前空間「Parof」に入れて（コード的には入れ子でくくった）「Parof::Test」としたときにスローされた例外である。
Visual Studio が生成する .resx を使わない場合、自分で適当な .resx リソースファイルを追加してその中にリソースを埋め込んでおいて、以下のようにフォームのコンストラクタ等で呼び出す方法もある。
Assembly^ assembly = System::Reflection::Assembly::GetAssembly(TestForm::typeid);
ResourceManager^ rm = gcnew System::Resources::ResourceManager("Test.Test", assembly);
this->Icon = (cli::safe_cast<System::Drawing::Icon^ >(rm->GetObject(L"TestIcon")));
これは「Test.resx」に「TestIcon」を埋め込んでおいて、「Parof::Test::TestForm」のコンストラクタでこれを読み込んでいる例である。「ResourceManager」のコンストラクタの引数は作成した .resx の「リソース ファイル名」と合わせればよい（.resources は書かなくてよい）。
なお、.resx のプロパティとは別に、プロジェクトの「プロパティ ページ」にも、「構成プロパティ」に「マネージ リソース」がある。ここの「リソース ファイル名」との兼ね合いで、リソースファイル（.resources）が正しく作成されないことがあるようなので注意。
ちなみに！フォームエディタでフォーム上に直接は位置されるのではないコンポーネント（ContextMenu、NotifyIcon、Timer など）も勝手に .resx の「その他」に登録されちゃったりしているので、名前空間やクラス名を変更すると思わぬバグを生む原因になりかねない。結局のところ、おとなしく Visual Studio の作法に従うのが正解か・・・。全ての名前空間やクラスを Parof 名前空間に置いている私としては不服で仕方がないのだが・・・。
そして上記の記述は試行錯誤しながら行ったために正しさが保証できないので、うまくいかなければ .resx を作り直したり、いろいろなプロパティを変更したり、ソリューションをクリーンしたりいろいろ試すしかない。
「warning C4566: ユニバーサル文字名 'char' によって表示されている文字は、現在のコード ページ ('ページ') で表示できません」
って警告が出たら、文字列の先頭に「L」を付けてみると良い。「L"横浜"」みたいに。
本来、UNICODE 環境では文字列の頭に「L」を付けるのが正しい作法らしく、つい忘れるとどこかの文字操作処理で思わぬトラブルに・・・
実際、Visual C++ で UNICODE な環境においてフォームやコントロールの生成を行うと、自動生成されたコードではテキストの頭にはちゃんと「L」が付いている。
必要に迫られて Java を使わなければいけない。とりあえず基本的なところのメモ。
基本的に1ソースファイルにつき1クラスとし、ファイル名とクラス名は一致させる。そうでないと文句を言われる。1ソース内にファイル名とは異なる2つ目以降のクラスを追加するのは大丈夫らしい。ただし、これは eclipse の場合（他はわからない）。
クラス名は大文字から始めることが推奨されている。
すべてのクラスはパッケージに属していないといけない。属するパッケージの指定はソースファイルの先頭で「package」文を使う。そのソースファイルのクラスはみんなそのパッケージに含まれる。ただし、package が未定義の場合、デフォルトパッケージ（default package）と呼ばれる特殊なパッケージに含まれるらしい。
パッケージ名とソースファイルの存在するフォルダの名前は一致していないといけない。
パッケージ名は小文字から始めることが推奨されている。
eclipse でソースファイルを追加するときはパッケージを選択して右クリック、「New」から「Class」でクラスを追加するようにしなければいけない。間違って「New」から「File」でテキストファイルを追加してしまうと、プロジェクトがクラスを認識してくれない。
私の愛用しているオーディオプレイヤーソフト jetAudio は、プレイリストに Wave ファイルを登録して連続で再生していくと、どういう訳か「ザーーー」という、テレビで言うところの砂嵐みたいなホワイトノイズとして再生されてしまう。
どの曲だと、とか、どういうタイミングで、とかいうことはなく、10曲ぐらい聞いていると1度は起こる現象だ。
多分、jetAudio の内蔵コーデックに問題があるのだろう。
この問題を解決するには、「Preferences」を開いて「Advanced」の「Input」にある「WAV File」のチェックをはずしれやればよい。多分これで Wave に関しては内蔵ではなく Windows 標準のものが使用されるので、問題は解決される。
タスクバーを見ると、常時15個ぐらいウィンドウが開いていて、もう24インチディスプレイ2枚じゃ足りない・・・、ので仮想デスクトップソフトを試行錯誤。最初は「Vista/XP Virtual Desktops」が良いかな（セカンドディスプレイだけ使うとか設定できる！）と思っていたんですが、微妙に動作が重かったり、不完全だったりするので「VirtuaWin」なるものに乗り換えた。こっちの方が安定して軽い気がするのでしばらくはこれで。
で、本題。私が利用している「v4.0」以降、右クリックメニューから「Window Rules」という機能の設定ができるようになったらしいのだけれど、ネットを見ても「よくわからない」という人が多いので説明する。
まぁ、Win32 API でプログラミングしてる人じゃなきゃ「Class name」とか書かれてもわからないよな・・・。
「Window Rules」は一言で言ってしまえば「こういうウィンドウはこういうルールに従ってね」っていう設定ができる。例えば、Firefox は必ず2枚目で起動してね、とか。
この「こういうウィンドウ」というウィンドウ指定をするのが「Class name」「Window name」「Process name」になる。ちなみに、全てを埋める必要はない。また「*」記号によるワイルドカード指定が可能（もちろん使わなくてもOK）。
それで「Class name」っていうのは、簡単に言ってしまえば「どんなタイプのウィンドウか？」を指定するんだけど、このタイプの名前は開発者が自由勝手に付けることができる（Windows で共通のパーツは同じだけど）。例えば、今私が使っている Firefox は「MozillaUIWindowClass」だ。しかしやっかいなのは、何か専用のツールを拾ってこない限り見る方法がないことである。私の場合、統合開発環境である Visual Studio に付いていたツールで見ることができた。
じゃぁ、普通の人はどうすればよいの？ということなんだけど、今度は VirtuaWin の Setup 画面を開いて Modules タブから WinList の Configure を開いてみよう。私もリストの詳細な見方はわからないのだけれども、とにかく「Class」という部分に Class 名が、「Title」という部分にウィンドウのタイトルバーに表示されるべきタイトルがリストアップされる。「Tile」から目的のウィンドウを探し出して、その Class 名を見つければ OK だ。
続いて「Window name」なんだけど、これは試していないけれどもヘルプを見る限り、上述したウィンドウタイトルのことだと思われる。
最後の「Process name」は、だまされてはいけない。タスクマネージャの「プロセス」に現れる「イメージ名」を書けばよいのかなと思いきや、ヘルプを見ると「フルパスで書け」とある。おかげで30分迷った。
まぁ、後の設定は適当な翻訳サイトで翻訳してもだいたいわかると思うが、冒頭で述べた Firefox は常に2枚目で開くという設定にしたいなら次のようにしよう。
・「Class name」は空、「Window name」は空、「Process name」は Firefox.exe のフルパスを書く。私の場合は「C:\Program Files (x86)\Mozilla Firefox\firefox.exe」となる。
・「Window rule enabled（ルールを有効化）」をチェック。
・続くラジオボタンは「Always manage windows of this type（この種類のウィンドウはいつも VirtuaWin が管理するよ）」を選択。
・「Automatically move windows of this type to Desktop:（自動的にウィンドウを指定のデスクトップへ移動するよ）」をチェックして隣の数字を移動したいディスプレイ番号（今回は「2」）に設定。
・「Move windows immediately（（プログラムが起動したら）すぐにウィンドウを移動するよ）」をチェック（これをチェックしない場合は右クリックメニューから「Re-apply Rules」を実行したときに移動する）。
これで Firefox は常に2枚目で開くようになる（ハズ）。あと、ルールを新しく作ったり変更した時には「Add」や「Modify」ボタンをすのを忘れずに。
VirtuaWin を使っていて気づいたのは、ときどき VirtuaWin で管理できないウィンドウがあること。話は簡単で、VirtuaWin が一般権限で動作していて対象のウィンドウが管理者権限で開いていると管理できない。VirtuaWin も管理者権限で動かしてやろう。
だけど、スタートアップに入れている人は困ったことが起きる。管理者権限付きでスタートアップから起動しようとしてもブロックされてしまうのだ。そういう場合はタスクスケジューラを使えばよい。詳しくは拙作 KBMouse のヘルプに同種の問題が記載されているので、そちらをご覧いただきたい。
ListView のアイテム集合から、チェックされているアイテムを抜き出すには、CheckedItems や CheckedIndices を使うよりも、各アイテムの Checked プロパティを調べた方が圧倒的に早い。例えば
