今日のバックアップ。
そういえば書き忘れていたけど現在 Vista 専用である。
細かいトコは休日にやる。
とにかく現在存在するスクリーンショットアプリでの我不満を全部コイツで解決する！
それが目的、ビューア機能なんてオマケ！
で、窓のなんとかから辿っていたら某氏が生き残っていたのを見つけたのが少し嬉しかった。
けど…相変わらず目的が全然見えないんだよなぁこの人の場合、名前は書かないが。
たとえば PhotoShop 以外のレタッチソフトは全部「貧乏人の PhotoShop 」なのよね。
そうじゃない理由が無いとどうなるかなんて先人が証明しているわけで。
私自身 Petrushka が一年半も止まっていた理由も Cinema が止まった理由もソレだったりするし…
なんか急激にコイツの方向が決まった。
何故二年近くもトップページに置いているのか謎なアプリでありますが…
方向が決まらず何も進まないのはそれだけ作者にとって重要ということで…
まあソレは戯れ言になるので割愛、とにかく今はコイツを仕上げる。
ということで今日中に最低限の使える機能を作って出そうと…
思ったけどそんなレベルに仕上がらないっぽいので現在までのバックアップだけ。
Wordpress の「メディアを追加」ってこういうバックアップにも使えるんだね。
Hotkey の設定 UI はどうやれば秀丸みたくできるのかな？
秀丸も EmEditor も IrfanView も全部同じなので共通にしたいんだが方法が解らない…
ソコが俺らしくないんだけど、だからこそ重要なんだよね。
せっかくなので BitmapEffect がどれだけ負荷が高いのか実験。
手持ちで一番巨大な 3072x2304px の画像を使って BlurBitmapEffect を掛けてみる。
2 ミリ秒…
BlurEffect にしてみる。
1 ミリ秒…
こりゃ差が全然解らないわけだわ。
この程度の BitmapEffect なら体感するような違いは無いってことなのね。
どういう使われ方を想定して BitmapEffect を無くす方向になったの？
解ったのは WPF で画像ビューアは一瞬で作れるということだけだった。
XAML に Image を配置して image1 という名前を付けたとして
private void Window_Drop(object sender, DragEventArgs e)
{
string[] drags = e.Data.GetData(DataFormats.FileDrop) as string[];
image1.Source = new BitmapImage(new Uri(drags[0]));
}
これだけ…後はプロパティを弄くるだけ。
せっかくだから何か作ろうか。
SeeMe のソースを少し弄くって sp1 にしてから初コンパイルしたら…
「BitmapEffect プロパティが古い！」
と怒られた、なんやねんまったく。
てか俺って気がつくの遅！VS2008 を sp1 にしたのは何時や！
とにかく BitmapEffect は檄負荷だから近々無くなるので使うなということらしい。
BitmapEffect がハードウェア アクセラレーション化されたはずなんだけーがなぁ。
川西 裕幸のブログ : .NET Framework 3.5 SP1 Beta
しかたがない、更新しよう（そんな理由で…）
てゆーかオープンソースなんだから放置はマズイわな。
using System.Windows.Media.Effects; img1.BitmapEffect = new BlurBitmapEffect(); ↓ img1.Effect = new BlurEffect();
と Bitmap を取っ払って書き換えるだけでよさそうだが。
こうしないとアクセラレーションが使えないってことなのか？よく解らないけど。
負荷の違いは私の Athlon 64 x2 4200+ ＆ AMD 690G のショボいマシンでも解らんぞ！
で
そういえば Drag and Drop での並べ替えをいいかげんに復活させなければ。
以前は全く見つからなかったがそろそろサンプルコードがネット上に上がっているかな？
CodeProject: Drag and Drop Items in a WPF ListView. Free source code and programming help
あぁ、これでなんとかなりそうだ。
ちなみに WindowsForm にあった listView1.GetItemAt みたいなメソッドは無い。
たかが ListViewItem 取得にこんな処理を自前で書けということらしい。
メソッドくらい用意してよまったく。
WPF がちっとも普及しない最大の理由はソレなんだから。
でも並べ替え自体は RemoveAt と Insert メソッドのみで簡単に終わる。
それもバインディングならもちろん元の ObservableCollection を並べ替えるだけ。
異様に簡単になったり異様に難しくなったり本当に面倒だなぁ WPF って奴は。
何を今頃の話。
Visual Studio Tools の Spy++ でちっとウインドウ検索していた。
これって UAC に引っかかるのよね、そんな大げさなアプリとも思えないけど。
ちっと思いついて SeeMe にファインダツールをドロップ。
えっ！WPF で作ったアプリには親ウインドも子ウインドも何も無いってこと？？？
意味不明の若い人へ説明すると…解説が難しいなぁコレ。
Win32 API で作ったウインドウはボタンやラベルも全部ウインドウである。
なのでメインウインドウにボタンがあったらボタンは子ウインドウということです。
ウインドウハンドルを持つモノは全部ウインドウ…ということで解るかな？
ソレが一つも無いということは全部ペンやブラシで描写しているのと同じコト。
ちなみに Y901 のコントローラボタンがそうやっているのでコレも当然ウインドウではない。
そういえば WPF は DirectX で描写していたんだっけ、これは「なるほど」という感じ。
.NET Framework が一番の親に居ると思っていたんだけど違っていた。
いったいドコまで今までと考え方を変えなければいけないのだろう？
もう一つ思いついて Explorer のリストビューにファインダツールをドロップ。
あれ？このリストビューって SysListView32 クラスってことなの？？？
解る人には解るとおり Win32 での「今までの ListView 」と同じっていうこと。
なのにこの描写、あぁワケワカになってきたぞ！
てっきり WPF と同じ方法で描写を実現かと思っていたが普通のウインドそのもの。
「何か」をやれば Win32 で作った ListView もこの「なめらか描写」に出来るってことみたい。
公開されなきゃどうにもならんが、なんか Vista って本当に難しい。