So-net無料ブログ作成

FSDirWalkerを公開しました (4) [ソフトウェア]

このタイトルの連載としては最後です。

内部の細かい話が中心でしたので、今回はUI周りについて書きたいと思います。

その前に、(3)の補足というか、おまけを。
ネイティブAPIにRtlGetLongestNtPathLengthという関数があります。名前からしてパスの最大値が得られるのではと期待したのですが、実際は269という値が返る(Windows 7の場合)だけです。

_RtlGetLongestNtPathLength@0:
7753D8BF  mov         eax,10Dh 
7753D8C4  ret
(Windows 7の場合)

269(0x10D)という値は何なのでしょう?他のバージョンのWindowsがどんな値を返すか確認していませんし、歴史的経緯も判りませんが(少なくともWindows2000には存在しました)当初はこの値だったのでしょうか。それともファイルパスのことではないのでしょうか?
―◇―

FSDirWalkerはUIデザインを含め仕様・設計思想自体が一回り、いや二~三回りほど古くさいと感じられるかもしれません。
書き始めたのが6年前なので仕方ないといえば仕方ないのですが(6年間と言っても連続してずっとという訳ではありません。時間があり、思い出した時に少しずつという感じでしたが、1年ぐらい間が開いたこともあります)。
その間にWindows Vista,Windows 7の”ゴージャスな”デスクトップからWindows 8/8.1のMetro(あえてメトロと呼びます)とフラットデザイン、そしてWindows 10のUWPとどんどん変化してますが、FSDirWalkerの基本はWindows XP、いやWindows 2000/NT4スタイルのままです。

まあ、これは私自身が時代に追いつけない「ロートル」だからですが、他にも多少の理由があります。

扱う対象がファイルシステムでしたのでWin32ベースになることは必然なものの、UIまで生のWin32で書くのはもはや厳しい。しかしMFCは避けたい。
極初期の頃はProcessWalker系列が使っている「フレームワーク」(Win32ベースで独自に起こしたUIライブラリ)を使用していたのですが、しばらく使ってみると今回のアプリケーションの目的に対しても、保守の面からも「重量級」に感じられす様になったのです。
そこで元々興味があったWTLが良いのではないかと思いつき、試しに使ってみたところ比較的使いやすく、使えそうなクラスも多かったのでUI部分を中心に採用することにしました。
その後、ファイル処理コアやネイティブAPIを扱うライブラリなどを残して「独自フレームワーク」を使っていた部分を捨て、UIを一から書き直して全面的にATL/WTLに移行した経緯があります。

その上で、ATL/WTL以外はWPFや.NETも含め可能な限り外部のランタイムライブラリに依存しない様に意識しました。そのため、.NETがインストールされていない環境や、Windows保守モードのコマンドプロンプト(最小限のGUI環境)からも実行可能となっています。

(余談ですが、Windows 10や8/8.1の保守モードであっても、コマンドプロンプト環境では「Windwos 7 ベーシック」のウィンドウテーマが適用されています。Windows 8のプレビュー時代の話ですが、なにかの拍子にデスクトップが壊れてフラットデザインだったウィンドウフレームが「Windwos 7 ベーシックに戻った」事もあります。
ということは、いつでも「ベーシック」に戻れるのではないでしょうか?10や8のデザインの使用を強制させることはせず、「ベーシック」に戻すオプションを設けても良いのにと思います。MDIの子ウィンドウは未だに「ベーシック」―それはMDIを使わせたくないという意思の現れでしょうか―なのですから)

とは言え、WTLもパーフェクトではなく、好みのデザインするためにいろいろ回避しなければならなかったのですが、その辺はいずれ機会があれば記したいと思います。

とりあえず連載形式は今回で終わりにしますが、今後も引き続きトピックを見つけて記事を載せる予定です。

コメント(0) 

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。