俺たちの時代はハンドルと言えば自動車のハンドルの事を指していたのだが、本来はステアリングなので画像の検索でヒットしなかった。
ハンドルと言えば、レバーを指していた。
まぁそれは置いておいて、Windowsシステムを開発している時、このハンドルって結構重要であって便利なのだ。
自アプリからなら「Me.hwnd」で簡単にハンドルが取得できる。
全部自分で開発しているアプリなら、起動した際に、この情報をiniファイルとかに保存しておいて、他のアプリから簡単に参照できる様にしておけば、起動やら終了やら、アプリ間でのやりとりがとても簡単に制御できる。
このハンドルを全く別のアプリを制御する為に利用する場合は結構面倒でプロセスIDからハンドルを見つけ、さらにそのウィンドウのコントロールのハンドルを検索してと色々と制御する事になる。
最初、各画面のショートカット機能を追加して欲しいとの事で、自アプリで自アプリのウィンドウからの表示だったので、Showで簡単に制御できたわけだが、他の関連したアプリ、これもオリジナルではあったのだが、そこから表示させたいと言う要望があった。
そこで、別アプリのハンドルを取得するロジックを追加してその画面のコントロールを制御しようと思ったが、結構面倒で、画面の上下でコントロールのハンドルが取得出来ず、最前面の場合は取得出来るが、隠れてしまうと非アクティブとなり上手くいかなくなる。
そこで、ふと考えてみたら、制御される側も制御する側も俺の自作システムでは無いか。
であれば、とそのアプリが起動したさいに、制御したいコントロールのハンドルをiniファイルに保存して、別のアプリから参照しておけば、ウィンドウの上下にかかわらず、毎回の起動時点でのハンドルがそのアプリ自体で取得して保存しているので検索する必要もないわけだ。
まぁ切角外部アプリのハンドルを取得するロジックを実装してしまったので、それはそれでlibraryとして置いておいて、ハンドルで制御する様にすると、メモリーリーク問題も解消出来た。
時々、終了に失敗するのか、二重起動問題に遭遇して、メモリーリークすると二重起動防止ロジックの為、起動させる事が出来ない問題があって、プロセスマネージャから終了させて起動させていた。
この手動でする操作がハンドルを制御することでいとも簡単にできるようになって、二重起動状態になった場合、最初に起動しているプロセスを強制終了させて、新たなプロセスを起動させる事にしたわけだ。
これで、ユーザ負担は無くなり、特殊な操作をしてもらう事も無くなったので一安心だ。
二重でも三重でも、メモリーリークした場合のゴミを全部強制終了させてしまうので、PCも安定するわけで、良いことづくめだった。
Me.Unloadとかで、偶にメモリーに取り残されたりしていて、俺の前任がウィンドウ感のコントロールを直接操作していて、イベントドリブンを把握してなかった様でスゴく遣りにくくて、冗長な状態で大分改善したものの、全部の修正はやりきれなくて、まだ表示してないフォームのコントロールに数字を送ると言う大胆不敵なロジックの塊だったのだ。
俺からしてみれば、こいつ馬鹿かとしか思えない様なロジックの塊でその先で制御していれば良いが、それも無く、隠れたメモリー内でイベントが走りまくっていたわけだ。
なので、全く関係ないデータが偶に表示されてしまうと言うこともあって、実に不安定要素満載のロジックがいくつか盛り込まれている。
今回、ハンドルでのプロセスの完全な裁ち切りと言う方法で限りなくメモリーリークに配慮した制御を盛り込んで、かなりシステムが安定した。
隠れたフォームにデータを書き込んでいるので、全く意図しないところで突然フォームが出現するなんて事もしばしばあったのだが、ハンドル制御で回避する方法を編み出したので良かった。
ここの社長のわがままを全部システムに反映しているので、俺自身のスキルもまだまだとどまるところを知らないわけで、ソフトウェア開発において出来ないことは無いと断言できる。
妥協しないシステム開発の醍醐味を一度味わうと工数に関係なく填まってしまう。
サラリーマンエンジニアと違うところは、この拘りと妥協しない心だ。
ユーザの要望を100%満たす満足度の高いシステムをこれからも目指してやまない。
コメント