UserControlを含んだクラスライブラリ(dll)を動的にロードするサンプルコードです。 ユーザーインターフェース付きのプラグインに対応したソフトを作ることを考えて組んでみました。
各プラグインとのやり取りをするときに使う共通処理を本体側のinterfaceで定義しておきます。 プラグイン側はそのinterfaceを実装したクラスを作成。 本体はSystem.Reflection.Assembly.LoadFromでプラグインのdllを読み込み、そのクラスのインスタンスを作成してプラグインの機能を使用します。
コーディングのとき、プラグインから本体のアプリケーションで定義されたクラスを扱うには本体.exeファイルの参照を追加するだけでOKです。 本体のアプリケーションからプラグイン内のクラスを扱うときは、あらかじめ本体側で用意したinterfaceを実装したものに限るのが現実的。 各プラグイン共通のデータ構造を決めておきましょう。 それ以上のことをやりたい時はリフレクションでゴリゴリ、かなぁ?
wpfでUserControlを含んだクラスライブラリを作ったときのメモです。 最初は空プロジェクトにUserControlを追加してやってみたんですが、そのままではデバッグできませんでした。 デバッグ用に別プロジェクトでウィンドウを作って、そこでAssembly.LoadFrom → UserControlを貼り付けでデバッグしようとしたらUserControl内のコードでステップ実行ができませんでした。 困りますよね?
少々試行錯誤したところ、MainWindow付きの「wpfアプリケーション」でプロジェクトを作って、後で出力をクラスライブラリに変更する方法を発見。 作成&デバッグはMainWindowに貼り付けてやって、リリース時にdllを作る方法がわかりました。 これでUserControlのデバッグができます。 未確認ですが、カスタムコントロールとかを作るときにも同じようにできそうです。
最初にC#について勉強したときに見たはずのことなんですけど、確認しようとして検索してもすぐにはヒットしなかったのでデバッガで見てみました。
enum TestEnum : int
{
A = 3,
B = 5,
C
}
int t1 = 16;
int t2;
TestEnum t3; // t3 : 0
t3 = TestEnum.A; // t3 : A
t2 = (int)t3; // t2 : 3
t3 = TestEnum.B; // t3 : B
t2 = (int)t3; // t2 : 5
t3 = TestEnum.C; // t3 : C
t2 = (int)t3; // t2 : 6
t3 = (TestEnum)t1; // t3 : 16
t2 = (int)t3; // t2 : 16
enumの中身は、ただのintですよねぇ。 それだけ。 検索のキーワードがすぐに思いつかなくて、やってみた方が早いってことは多々ありますよね。
PCを買い換えてOSがWindowsXPからWindows7に変わったとき、program filesのアクセス権管理が厳格になったことに気付きました。 Vista以降で厳格になったようです。 それについて解説してあるページはいくつかあります。 たとえば、
セキュリティを考慮してこうなったようですね。
たま～に使っているドローソフトのinkscape、いつのまにかファイル保存ダイアログが開かなくなっていました。 環境はこんな感じ。
1度保存してファイル名を付けてある画像の場合、上書き保存をするときに保存ダイアログは必要ありません。 そのため、上書き保存だけですんでいる間はこの不具合の影響はなし。 新規画像を作った後に保存しようとして気付きました。
2018/11/08 追記) WindowFromPointが動かないのは引数の間違いでした。 補足情報を投稿しておきます。
以降、過去の投稿に関しては書き換えていません。
前の投稿「wpf : マウスキャプチャとマウスカーソルの変更」の続きです。 コードは前の投稿のMainWindow.xaml.csを見てください。 ここでは「マウスキャプチャ中にマウスが指しているウィンドウの情報(タイトル、ウィンドウクラス、実行ファイル名)を得る」という部分について書きます。 前回書いたとおり躓きました。 「win32sdkの時代の定石コードを探してきてDllImportしてアレコレ」で済むかと思ってたんですが、64bitの壁に阻まれました。
サンプルコードを試した環境はwindows7 64bit版です。 で、その64bit環境で試したら、アプリケーションをx86(32bit)でビルドしたのとx64(64bit)でビルドしたのとで挙動が違ってました。
この部分のコードは次のような手順になっています。
躓いたのは「1:WindowFromPoint」と「4：プロセス操作」です。 構成をx86(32bit)にして動作させると「4：プロセス操作」で64bitプロセスの実行ファイル名が得られませんでした。 構成をx64(64bit)にして動作させると「1:WindowFromPoint」が動いてくれませんでした。
wpfでマウスキャプチャをするサンプルプログラムを作ってみました。 キャプチャするには、
とやります。 LostMouseCaptureイベントはユーザーの操作でキャプチャーが終了したときも、他の原因(他のウィンドウがアクティブになるなど)でキャプチャーが終了したときにも発行されます。 キャプチャーの結果をもとに行いたい処理はMouseLeftButtonUpイベントのタイミングでやって、LostMouseCaptureイベントではマウスカーソルの切り替えだけ行います。 マウスカーソルの変更は、
mainWindow.Cursor = Cursors.なんたら;
です。 これだけ。
これだけでは何なので、
昨日の投稿、今読んだら日本語になってないところがあって訳分かりませんなぁ。 まぁ、書き直すのは面倒なのでコードを読んで察してください。 今回の投稿はその続きで、MainWindowの表示中の領域にマウスカーソルがある場合反応して、他のウィンドウの上にマウスカーソルがある場合除外するというヒットテストのコードを作成します。
昨日、「これやったら、もしかしたら他のウィンドウを除外できるかもしれないね?」ということで挙げた3点を試してみました。
1はUIElement.InputHitTestと同じ動作でダメでした。 2のクリッピング領域も用途が違うらしくダメ、レンダリング領域の取得方法は検索で見つかりませんでした。 3のWindowFromPointは成功。 このやり方が最善なのかはわかりませんが、とりあえず3のやり方でヒットテストのコードを書いて整理してみました。
ペンタブレットでペイントソフトを作ったときの事を空想して、wpfのヒットテストを試してみました。 使ったのはUIElement.InputHitTestです。
wpfのマウスイベントは基本的にイベントハンドラを登録したコントロール上にカーソルがあるとき発行されます。 しかしwintabでペンタブレットの入力処理をする場合、イベントにはそういう制限がありません。 アプリケーションがアクティブならカーソルがどこにあってもイベント(メッセージ)が発行されます。 アプリケーションがアクティブでなくても、場合によってはイベントが発行されます。 イベントハンドラで自分でヒットテストをして、対象のコントロール上にカーソルがあるか、イベントを処理するべきかを判断しなければなりません。 今回はそのヒットテスト部分だけ試作しました。
サンプルコードでペンタブを使ってコーディングミスをし、座標がズレてしまったら確認の意味がないので、今回はとりあえずマウスのグローバルフックで試しました。 何かのマウスイベントがあるたびにフックの中でHitTestをして、UIElement.InputHitTestがどのコントロールを返すのか確認します。 これで目的のコントロールを検出できるか確認。
ニコニコ動画のネット世論調査を見ました。 なかなか偏った結果ですね。
ニコニコ動画にアクセスするのは若い世代に偏っていると言われています。 参加人数の関係からか、50代以上がひとまとめにされています。 少子高齢化の今、世論調査としての体をなしてないません。
じゃあマスメディアの世論調査はまともか?っていうとそんなことはないです。 未だに電話を使ったRDD方式とかやってるようですしね。 ずっと前から言われている
っていう事柄への対策はどうなったんでしょう? 世論調査の電話に出る人は、知らない人からの電話に抵抗が少ない高齢者に偏ってそうです。
今使っているPC、Firefoxを使用中にモニタが数秒間真っ暗になる不具合をかかえています。 どうやらGeForce GTX 560とFirefoxの相性問題の模様。 「GeForceのベータ版ドライバ(285.27)でそれを解消できるかもしれない」とインストールしてもだめ。 ブラウザをFirefoxからGoogle Chromeに変更して様子を見ていました。
しばらくChromeを使っていたけど、こちらのブラウザを使っている間は同様の不具合はありませんでした。 これで、自分の中ではGeForceとFirefoxとの相性問題が原因ってことで確定に。
以前VC++で作った「グローバルフックでランダムな文字列を挿入するプログラム」をwpfでもやってみました。 目的は、
の2点です。
そういえば、最初の投稿で「C#でのグローバルフックは色々と面倒くさそう」と書きましたが、ここを見るとそうでもないようですね。
dllを作るのとC#だけでやるのに手間の差はさほど無いようです。 けど、まぁいいや。
アプリケーションを起動するとタスクトレイにアイコンが表示されます。 その状態で別のアプリケーションを操作中にショートカットキー(デフォルトでCtrl+Alt+F)を押すとランダムな文字列が挿入されます。 ランダムな文字列は大文字小文字のアルファベットと数字です。 タスクトレイを右クリックすると設定、終了のメニューが出ます。 設定ダイアログはxamlで作成。 ショートカットキーと文字列の長さを変更可能。 「自分でも使うかどうか?」っていう機能を適当に実装しただけなので色々不親切になっています。
前に作った「グローバルフックでランダムな文字列を入力させるdll」、C#から呼び出すのを試してみました。 dllを無駄にx64で作ったのでwpfのテストコードの構成も無駄にx64に。 簡単なコードしか書いてないんですが、わけのわからないエラーが出ました。
エラーが出たのはdllを呼び出す部分ではなくxamlです。 曰く。
clr-namespaceのまわりは以前作ったコードのコピー&ペーストだし、プロジェクトの名前空間を見つけられないなんていう状況がわかりません。 しばらく足止めをくらいました。
ブログにxmlやプログラムのコードをそのまま載せると表示が崩れてしまいます。 崩れないようにするにはちょっとした変換が必要です。
他のやり方もありますが、このブログではこんな感じでやっています。 タブ→スペースの変換はやらなくてもブラウザ側で対応されてますが、一応htmlの仕様らしいので変換。 実体参照を変換せずに投稿してもbloggerが変換してくれるっぽい(うろ覚え)ですが、一応自前で変換です。 順番を間違えると、投稿後の文字列の「<」と「>」が「<」や「>」になってしまうので注意。
この手順の変換はよくやるのでサクラエディタのマクロに登録してしまいました。 マクロのコードはコレです。
S_ReplaceAll("\t"," ",14);
S_ReplaceAll("&","&",10);
S_ReplaceAll("<","<",10);
S_ReplaceAll(">",">",10);
S_ReDraw(0);
1回作っておくと便利ですね。
BBSによく投稿する人はタブ文字を全角空白にして、「&」、「<」、「>」を全角に変換するマクロとかを用意しておけば便利かもしれません。 ↑をちょっと替えればすぐ出来ます。
でお買い物
