昨日の描画ルーチンの修正によって新たに発生したバグを1件Fix
それだけでは物足りないので矢印キー及びテンキーによってロジックがスクロールするようにした
テンキーの方はNumLockがかかっていれば問題ないのだが, NumLockがない状態のテンキーと矢印キーはデフォルトではKeyPressイベントに渡る前にシステムが勝手にフォーカス移動で消費してしまうので, 次のようなメソッドのオーバーライドが必要だった
protected override bool ProcessDialogKey(Keys keyData){
if (this.ActiveControl == panel1)
switch (keyData) {
case Keys.Up:
case Keys.Down:
case Keys.Left:
case Keys.Right:
return false;
}
return base.ProcessDialogKey(keyData);
}
ドキュメントを見るとキーイベントははまずアクティブなコントロールで特殊キーが処理され, その後フォームでも特殊キーが処理された後にさらに残ったものをユーザイベントで拾い, それでも拾われなかったものについては通常の入出力として扱われるという模様
この場合はNumLock時のテンキー一般キーについては最初の2つの段階ではスルーされるので普通にキーイベントを書けば良いのだが, 矢印キーは基本的にコントロールで消費され, 消費できなかったものがフォームでフォーカス移動に使われるというシナリオだったりしたので今回の場合は2つ目のフォームでの処理をオーバーライドして必要なものだけをわざとスルーさせるようにしたわけである
因みにPanelは本来フォーカスを受け取らないものを無理矢理受け取らせているぐらいなので, 当然コントロールは矢印キーを消費しないため, このためにはオーバーライドしたメソッドを持つコントロール型のextendが要る上に, それを使ったら最後フォームデザイナには認識されなくなるコントロールレベルでメソッドをオーバーライドする必要がなかったのには救われたが…
CGの課題で使うテクスチャーの座標変換行列をECCのMathematicaで求めてみた
…とはいえ, 8元1次連立方程式を解かせようとしても上手くいかなかったので変換行列の合成と簡約をやってもらったのだが…
他の人は何処かから論文を拾ってきたりして何とかしている人も要るらしいが, ここは因みにECCのMathematicaは一瞬では答えを返してくれませんでした力ずくで…
で, その入力は面倒だし長いので省略結果, 因みにアフィン変換行列の特性を生かしてその方が計算が速いから, もしOverflowしたらInt64でも使おう(逃)途中計算には除算が出ないようにしてあります
Out[9]= {{y3 (-(x4 y2) + x2 y4)
> (x4 (-y2 + y3) + x3 (y2 - y4) + x2 (-y3 + y4)),
> x3 (x4 y2 - x2 y4) (x4 (-y2 + y3) + x3 (y2 - y4) + x2 (-y3 + y4)), 0},
> {y2 (x4 y3 - x3 y4) (x4 (y2 - y3) + x2 (y3 - y4) + x3 (-y2 + y4)),
> x2 (-(x4 y3) + x3 y4) (x4 (y2 - y3) + x2 (y3 - y4) + x3 (-y2 + y4)), 0}\
> , {y3 (-(x3 y2) + x4 y2 + x2 (y3 - y4)) (x4 y2 - x2 y4) -
> y2 ((-x2 + x4) y3 + x3 (y2 - y4)) (x4 y3 - x3 y4),
> -(x2 (x4 y3 - x3 y4) ((x2 - x4) y3 + x3 (-y2 + y4))) +
> x3 (x4 y2 - x2 y4) (x3 y2 - x4 y2 + x2 (-y3 + y4)),
> -((x3 y2 - x2 y3) (x4 y2 - x2 y4) (-(x4 y3) + x3 y4))}}
本来はもうちょっと長いのだが, ちょっとだけ条件を加えて簡約化した結果, こんなのを私にどうしろと…
明日は当然このまま書いたりはせずに共通部分式を洗い出したりしながらもうちょっとマシなコードにする予定ですが…これの実装でもしようかと思います
因みにこの行列を勝手に使うのは構いませんが, レポートのネタになるしね導出過程と『本来』からどう簡約化したのか(バレバレだけど)と変数の意味を知らないと辛いかと使用方法がわからないと使い物にはなりませんのでご注意ください
Comments (0):