ども、一ヶ月ぐらい前に作った自作のLineChartをちまちま更新していたら、何か結構高性能になったんじゃね？ってことで、動画にとって見ましたのでご紹介。
機能としては、「データを拡大して、スライドさせることが出来る」「マウスポイントに追従してデータの位置を取得できる」「複数のLineChartの端を一致させたまま配置できる」「複数のLineChartでスクロールバーやマウスポイントを同期させられる」「大量のデータを入れてもとりあえず固まらない」あたりです。
NodamushiChart(Github)
とりあえず、動画とか初めてキャプチャして、それをそのままYoutubeにぶち込んだだけだから画質とか酷いけど、気にしないで。てか、相当昔に取ったnodamushiのアカウントに付けてた名前が田中太郎って宇宙人かよ。（ネタ分かる人居るのかな）
と、いうわけで、前回の自作LineChartに対数グラフの機能を実装しますた。
NodamushiChart
拘ったのはラベルのとこ。102みたいな感じに表示されていますが、これ、JavaFXの標準NumberAxisじゃまず無理ですよね。うぇへへへ。
LogarithmicAxisの実行サンプルはtest.Test2で見ることが出来ます。
やろーども。滅入り苦しみます。
と、いうわけで、全国約80人のJavaFXユーザーにnodamushiサンタがナイスノンケなプレゼントをもってやってきたぜぃ。
さて、妙なノリもここまでにして、JavaFXのLineChartって使いにくい、というのが私の結論です。グラフ描画領域内のマウスイベントは取れない、double[]配列でデータあるのをいちいちDataに変換しないといけない、Axisをスクロールさせて描画領域を変化させることも出来ない。複数のグラフを並べて表示させることが出来ない。その上妙なアニメーションやらまじうぜぇ。
で、これらを解決すべく色々模索した結果………
LineChart自作してまいました( ﾟдﾟ)ﾒﾘｰｸﾘｽﾏｽ
ソースコード：NodamushiChart
あ〜、車輪の再発明糞面倒くさいぜー
まだバグバグしてるし、欲しい機能（マウスイベント、表示範囲の変更など）全てを実装し終わったわけじゃないけど、こんな感じで動きます。（クリスマス前に記事を投稿したかったんじゃー(>_<) ）
図はsinc関数を表示した物です。sinc(0)=1ですが、テストでsinc(0)=∞にしています。このグラフは∞やNaNを自動的に判断して、無限だったら図のような垂直な線を描画、NaNだったら線を切断して表示してくれます。
また、JavaFXのXYChartの様にグラフの表示エリアをオブジェクトの持つGroupインスタンスの中で構築し、外に出さない様な仕様と違い、グラフ表示領域は一つのクラスとしてつくってあるので、複数のグラフを整頓して配置することも容易に出来るように作ってあります。
数値解析のような大量のデータをグラフに描画して、観察したい、という用途なら既に結構十分動きます。ソースコードは上記Githubにおいておくのでご自由に使って遊んでみてください。とりあえず、test.Testを実行すれば上の図が出てきます。ライセンスはCC0で著作権とその行使は放棄しているので、好きなように改変、利用してかまいません。
ドキュメントとかはまぁ、そのうち（気が向いたら）正月の間にやるから待ってくだしぁ。
朝から叫んでおりました内容が解決したので、記事にしておきます。
まずは、以下のようなクラスを用意します。一辺100の正方形の中心に直径60の円と長さ100の横棒を重ねたような図を表示します。
import javafx.scene.Group; import javafx.scene.shape.Circle; import javafx.scene.shape.Line; public class ShapeGroup extends Group{ private Circle circle; private Line line; @Override protected void layoutChildren(){ if(circle == null){ circle = new Circle(50,50,30); line = new Line(0,50,100,50); getChildren().addAll(circle,line); } } @Override public double prefHeight(double width){ return 100d; } @Override public double prefWidth(double height){ return 100d; } }
ちなみに、Groupを継承する場合はcomputePrefWidthとかじゃなくて、prefWidthをオーバーライドします。今日初めて知りました。
で、下図のようにこいつの棒の端っこに文字をくっつけたいと思います。
import javafx.geometry.Insets; import javafx.scene.layout.Region; import javafx.scene.text.Text; public class ClassA extends Region{ private String str; private Text text; private ShapeGroup shape; public ClassA(String str){ this.str=str; } private void initInstance(){ if(text==null){ text = new Text(str); shape = new ShapeGroup(); getChildren().addAll(text,shape); } } @Override protected void layoutChildren(){ initInstance(); Insets inset = getInsets(); double il = inset.getLeft(); double it = inset.getTop(); double textWidth = text.prefWidth(-1); double textHeight = text.prefHeight(textWidth); double shapeHeight = shape.prefHeight(-1); //ラベルのy座標はちょうど //shapeの中央に来るようにする text.resize(textWidth, textHeight); text.relocate(il, it + shapeHeight*0.5-textHeight*0.5); shape.relocate(textWidth+il, it); } @Override protected double computePrefHeight(double width){ initInstance(); Insets inset = getInsets(); double shapeHeight = shape.prefHeight(-1); return shapeHeight+inset.getTop()+inset.getBottom(); } @Override protected double computePrefWidth(double height){ initInstance(); Insets inset = getInsets(); double textWidth = text.prefWidth(-1); double shapeWidth = shape.prefWidth(-1); return textWidth+shapeWidth +inset.getLeft()+inset.getRight(); } }
実行結果
あるぇええええええ？
これの原因が全然分からなくって、Textの高さが指定したものと異なる、もしくは、描画位置が異なるのかとか勝手に思って、勝手にドツボにハマっていました。
原因はTextではなく、こいつです。
shape.relocate(textWidth+il, it);
ShapeGroup extends Group
javafx.scene.Node のrelocateには
Sets the node's layoutX and layoutY translation properties in order to relocate this node to the x,y location in the parent.
と書いてある。というわけで、私はsetLayoutXやsetLayoutYではなく、もっぱらrelocateを配置する際に使っていた。しかし、このrelocateは単にsetLayoutXやsetLayoutYの代用メソッドではなくて、割といらないことしてくれる。
//javafx.scene.Nodeのrelocate public void relocate(double x, double y) { setLayoutX(x - getLayoutBounds().getMinX()); setLayoutY(y - getLayoutBounds().getMinY()); PlatformLogger logger = Logging.getLayoutLogger(); if (logger.isLoggable(PlatformLogger.FINER)) { logger.finer(this.toString()+" moved to ("+x+","+y+")"); } }
というように、単にsetLayoutY(y)とするのではなく、getLayoutBounds().getMinY()という値を引いてしまっている。
そして、今回、ShapeGroupは高さ100の正方形の中心に直径60の円を描くという前提でプログラムを書いた。すなわち、ShapeGroupの上下にはそれぞれ長さ20の空白がある。getLayoutBounds().getMinY()はこの20を返す。従って、高さ100の正方形をy座標が0の位置に表示したつもりでも、高さ100の正方形をy座標が-20の位置に表示することになる。これが表示しているテキストの位置と横棒の位置がずれた原因である。
relocateをsetLayoutX,setLayoutYに置き換える、もしくはGroupを継承するのではなく、RegionやPaneなどを継承するように変更すると、私が意図したような正しい表示がされる。
というわけで、Groupを使うときは要注意と言うことと、relocate(またはresizeRelocate）はsetLayoutXで設定するのと結果が異なる場合があると知っていないといけない、というのが今日の教訓でした。
いい加減、何となく動作してるからいいやじゃなくって、中で何やってるのか理解しておくかと、ソースコード読んできたのでまとめておくよ。
ついさっきまで挙動の差とか、全く理解していなかったほど、違いがよく分からんこの二つ。ソースコードを読んでも差が分からなかったので櫻庭さんに解説していただいた。
@nodamushi 値が変更されるとXPropertyBaseのmarkInvalidが2回コールされます。InvalidationListenerだけだと1回目validがtrue、2回目falseになってfireValueChangedEventがコールされないのです。
— Yuichi Sakuraba (@skrb) 2014, 10月 13@nodamushi 逆にChangeListenerが入っていると、1回目も2回目もvalidがtrueなのでfireValueChangedEventがコールされます。
— Yuichi Sakuraba (@skrb) 2014, 10月 13@nodamushi InvalidationListnerが登録されている時は、本当にinvalidな時だけ、validが1回目も2回目もtrueになるようです。
— Yuichi Sakuraba (@skrb) 2014, 10月 13//DoublePropertyBaseのmakrInvalidとgetメソッド private void markInvalid() { if (valid) {//←ここと valid = false;//←ここと invalidated(); fireValueChangedEvent(); } } @Override public double get() { valid = true;//←これ return observable == null ? value : observable.get(); }
つまり、getを呼び出さない限り、2回目以降のfireValueChangedEventは呼び出されない。
で、私がInvalidationListenerとChangeListenerの違いが分からなかった理由は次のコード。
//ExpressionHelper.GenericのfireValueChangedEventメソッドの一部抜粋 //InvalidationListenerの呼び出し for (int i = 0; i < curInvalidationSize; i++) { curInvalidationList[i].invalidated(observable); } //ChangeListenerの呼び出し if (curChangeSize > 0) { final T oldValue = currentValue;//currentValueはフィールド変数 //***↓ここでvalidがTrueになる** currentValue = observable.getValue(); final boolean changed = (currentValue == null)? (oldValue != null) : !currentValue.equals(oldValue); if (changed) {//値が変更されたときだけ呼び出す for (int i = 0; i < curChangeSize; i++) { curChangeList[i].changed(observable, oldValue, currentValue); } } }
櫻庭さんの言うChangeListenerを登録しているからInvalidationListenerも呼び出されるというのは、ChangeListenerを呼び出す前にgetを呼び出すからということみたい。
違いが細けぇっ( ﾟдﾟ)
ということは、InvalidationListenerのみの場合でも、毎回getをしてしまえば二つの呼び出しに差がなくなる。テストするときなんかにSystem.out.println(get)なんてやっていると私のように何の違いがあるのかさっぱり分からん！となる。「変化した」というフラグだけ残しておいて、実際に処理するのは描画直前とか、そういう使い方をしたい場合はInvalidListenerの方が効率的という事の模様。
ちなみに、InvalidationListenerもしくはChangeListenerのどちらか一つしかないような場合は、GenericじゃなくてSingle〜っていう名前のクラスで特別に場合分けされている。一つのリスナしか登録しないなんて場面は多々あるから、合理的だね。
JavaFXで使う機会の多いのがFXCollections.observable(Array)Listかな。observableListでは、渡されたListをラップするOvservableListを返す。従って、渡したリストの中身を変更すると、ObservableListの中身も変わる。作られるObservableListの種類は、Listがランダムアクセスに対応しているかどうかで場合分けされている。
さて、ObservableListの変更がリスナに通知されるのはやっぱり、fireValueChangedEventメソッドだ。ただし、今回はListListenerHelperというクラスのfireValueChangedEventメソッドだが。あと、追加削除等の変更から、実際に通知を行うところまでソースコードを読もうとすると結構長い道のりを辿る。割と面倒くさかったけど、ざっくりというと、配列のいったいどこからどこまでが変更されたのかを記録するクラス（ListChangeBuilder）があって、そいつにここ変更したよとか、終わったよと通知することで、今までの変更を勝手に処理してくれてChangeを作成し、fireValueChangedEventを呼び出してくれる。で、そのfireValueChangedEventの中身を以下に示す。
for (int i = 0; i < curInvalidationSize; i++) { curInvalidationList[i].invalidated(change.getList()); } for (int i = 0; i < curChangeSize; i++) { change.reset(); curChangeList[i].onChanged(change); }
結論としてはListChangeListener使っとけって話ですね。change.reset()は何もしないか、単に内部のカウンタを-1にセットするだけなので重たい処理ではありません。なので、色々情報取得できるListChangeListenerを使っておけば何の問題もないと言うことですね。普通のObservableとどっちも同じリスナで監視したいときなんかはInvalidationListenerの方が良いのかな？
あと、注意点としてはfireValueChangedEventはaddやaddAllを呼び出すたびに実行される。中身のArrayListは十分な容量取ってるから一個一個追加していってもメモリ的に無駄がないはずと思っていても、結構無駄が多い。基本的には、他のArrayListや配列にいったん保存しておいてから、addAllで一発で全部追加するのが効率が良さそうだ。（個人的には、ObjectListenerにbeginChangeとendChageを追加してくれれば良いと思ってる。）
Bindingって何となく使ってるけど、いったい何で変化を検出してるのか、いつ計算するのか、GCの動きとかどうなってるのかよく理解してないよね。
まず、イベントの検出の仕方はInvalidationListenerを使っている。つまり、値が変化したかどうかは見ていない。さて、気になるメモリ管理だが、このInvalidationListenerではWeakReferenceを用いてインスタンスの保持をしている。つまり、Bindしている状態であっても、GCの動作を阻害しない。
//BindingHelperObserverの一部抜粋 private final WeakReference<Binding<?>> ref; public void invalidated(Observable observable) { final Binding<?> binding = ref.get(); if (binding == null) { observable.removeListener(this); } else { binding.invalidate(); } }
refの中にバインドされている対象が入っている。(＝refの内容がobservableの値によって変化する。） バインドされている対象がGCで消されてしまったら、自動的にリスナの登録を解除してくれる。つまり、Bindしたものに関しては基本的に自分でunbindしなくても大丈夫と言うことだね。
で、observableの内容が変化した（可能性がある）場合には、上のソースコードで見て分かるように、invalidateメソッドを呼び出す。これが何をするかというと、変更されたというフラグを立てるだけで、値の再計算は実行されない。実際に値が再計算されるのはgetメソッドを呼び出したときになっている。
//DoubleBindingのgetメソッド @Override public final double get() { if (!valid) {//変化フラグが立っているかどうか value = computeValue();//値の再計算及び保持 valid = true;//フラグを消す } return value; }
実際にgetメソッドを呼び出さない限りはcomputeValueは呼び出されないので、無駄な計算コストを支払うことはない。つまり、いつgetを呼び出すのかということが重要になってくる。変更されるたびに必要もないのにとりあえずgetしていると、無駄な計算コストを支払うことになる。描画直前とか、本当に必要なときだけ呼び出すようにすると良さそう。
JavaFXの何かよく分からんな〜と放置していたブラックボックスがだいぶん見えてきました。やっぱり、中の挙動が分かってる方が、プログラム書いてるときも安心できるよね。
JavaFXのChartって使いにくいなこんちきしょう。グラフ内部のマウス座標とか、全然取れないし 。(グラフ内部というのは、本当にグラフの表示領域内部だけでの座標ね。あと、根性で取れるようにしたよ、ちきしょう。Javaのバージョンアップとかで、もしかしたら駄目になるかも。）
そんななか、私を丸1日悩ませたのは、MinorTickにおける背景の線を描けないこと。ちょっと特殊な目的でMinorTickでも線が欲しい。（下図参照。通常では線が描画されるのはMajorTickだけ。しかし、MajorTickの数は増やしたくない。）
まず、前提条件として、AxisはValueAxisを拡張したクラス（NumberAxis）を利用するとします。また、たぶんどのChartでも同じように出来ると思いますが、今回はLineChartを対象とします。
最初に、MinorTickの線を引くには、MinorTickがどこに表示されているのか知る必要がある。それはValueAxisのcalculateMinorTickMarksで取得が可能だ。
しかし、calculateMinorTickMarksは可視性がprotectedで見えない。さらに困ったことに、NumberAxisはfinal宣言されてて、可視性の上書きも出来ない。
というわけで、こうしました↓。
package javafx.scene.chart;//←これ import java.util.List; public class CallProtectedMethod{ public static <T extends Number> List<T> calculateMinorTickMarks(ValueAxis<T> axis) { return axis.calculateMinorTickMarks(); } }
javafx.scene.chartパッケージ下で新たにクラスを作成して、それを介して無理矢理呼び出します。
今回はわかりやすい名前にしたけど、絶対に衝突しないような名前にしとくと良いでしょう。
で、次に背景に線を引く処理ですが、困ったことにXYChartで実際に線を引いている背景の領域というのは取得できない。一応、内部の構造を理解した上で、子ノードを辿り、取得は出来るが、その座標系は表内部だけの座標系にされていないので、細かい調整がよく分からん。ていうか、本来ブラックボックスのはずの内部処理を理解した上での実装だから、バージョンアップでちょっと処理を書き換えられたらすぐに使えなくなる。それはしたくない。
そこで、妥協としてグラフの値を描画する領域（Group）において、グラフの線を描く前に描画をします。線の更新処理はlayoutPlotChildrenの処理に追加することで実装します。layoutChildrenだと、Axisの大きさがまだ設定されていないので上手くいかない。いや〜、layoutPlotChildrenがfinal宣言されてなくて良かった。
グラフの表示領域の大きさと、Axisの長さが同じに設定されているので、線の長さはAxisの長さと同じにすれば良い。次に、線の位置はAxisのgetDisplayPositionから取得できる。以上をまとめると次のようになる。
package nodamushi.jfx.chart; import java.util.*; import javafx.collections.ObservableList; import javafx.scene.chart.*; import javafx.scene.shape.*; public class LineChart2<X extends Number,Y extends Number> extends LineChart<X, Y>{ private Path xMinorPath,yMinorPath; public LineChart2(ValueAxis<X> xAxis,ValueAxis<Y> yAxis){ super(xAxis,yAxis); init(); } public LineChart2(ValueAxis<X> xAxis, ValueAxis<Y> yAxis, ObservableList<javafx.scene.chart.XYChart.Series<X, Y>> data){ super(xAxis, yAxis, data); init(); } private void init(){ Path xMinorPath = new Path(); Path yMinorPath = new Path(); this.xMinorPath=xMinorPath; this.yMinorPath=yMinorPath; //グラフよりも先に描画されるように //0に挿入します getPlotChildren().addAll(0, Arrays.asList(xMinorPath,yMinorPath)); //CSSの設定 xMinorPath.getStyleClass().add("chart-vertical-grid-lines"); yMinorPath.getStyleClass().add("chart-horizontal-grid-lines"); } @SuppressWarnings({ "unchecked", "rawtypes" }) @Override protected void layoutPlotChildren(){ super.layoutPlotChildren(); final ValueAxis xa = (ValueAxis)getXAxis(), ya = (ValueAxis)getYAxis(); final Path xpath = this.xMinorPath, ypath = this.yMinorPath; final List<Number> xminor = CallProtectedMethod.calculateMinorTickMarks(xa), yminor = CallProtectedMethod.calculateMinorTickMarks(ya); xpath.getElements().clear(); double h = ya.getHeight(); for(Number o :xminor){ double display = xa.getDisplayPosition(o); xpath.getElements().addAll( new MoveTo(display,0), new LineTo(display,h) ); } ypath.getElements().clear(); double w = xa.getWidth(); for(Number o :yminor){ double display = ya.getDisplayPosition(o); ypath.getElements().addAll( new MoveTo(0,display), new LineTo(w,display) ); } } }
で、実際に使ってみると以下のように描画されました。問題なさそうですね。
もっと良い方法があるという場合は是非教えてください。
みなさんはキーボード何使ってますか？私は東プレのRealForceを………という話ではなくて、JISキーボードですか？USキーボードですか？ US!US!なギーク（笑）には関係ない話ですが、私はJISキーボードです。前の研究室はUSキーボードだったので両方使えますが、JISのがしっくりきます。
で、JISは世界の標準ではないので、色々問題起こります。
「Ctrl+@」
このキー操作を定義しようとしたときに問題が発生しました。我々JIS民は@って@を押せば出るんですよ。でも世界民はShift+2なんですよね。で、世界民はJIS民が@と呼ぶキーは[と呼ぶんですよね。
なるほど、じゃぁ、JavaFXも@は[と呼ぶから困ると私は言いたいのか。残念ながらもっと面倒で、何故か`と判定されました。KeyCodeにATって定義されてるくせに…
これだと、ユーザーが柔軟にキーバインドを定義するようなアプリケーション作れねーじゃん、ということで、emacsのキーバインドのように柔軟な表現で表せるようにしようと思ったわけです。柔軟な、というのは例えばJISで「C-S-@」または「C-`」は「Control+Shift+@」であり、USなら「C-S-@」は「Control+Shift+2」である等、柔軟な対応がしたいということです。
キー入力「Ctrl+@」をKeyCodeという列挙型で判断しようとすると、Ctrl＋バッククォートになる為、KeyCodeのみに頼ることは出来ない。しかし、KeyEventのgetText()を利用すると、このKeyCodeはバッククォートでも「@」という文字列が返ってくる。これとKeyCodeの二つ両方利用して何とかしようとした。
これでかなり柔軟に対応するところまでは出来ました。しかし、「Ctrl+Shift+@」というショートカットを定義することが現状できないという結論に至りました。Shift+@によりgetText()の値は「`」になり、@かどうか判別することが出来ない為です。
キーボードがJISなのか、USなのか（はたまた別の言語なのか）判断して処理を分けれればいいのですが、私にはやり方分からないし、っていうか分かっても全部やるとか面倒くさくてあり得ないし。
というわけで、私のもくろみは散ってしまったとさ。
でもまぁ、使い方を気をつければ、JavaFXのKeyCombinationよりは柔軟な物を作ることは出来たんじゃないかな。↓
package nodamushi.event; import javafx.scene.input.KeyCode; import javafx.scene.input.KeyEvent; public class MyKeyCombination implements Cloneable{ //修飾キーの値 private static final int CONTROL=1,ALT = 1<<1,META = 1 << 2,SHIFT = 1 << 3; //よく分からんキーのコード private static final int UndefinedKeyCode = -10000; private static int getModifiers(boolean control,boolean alt,boolean meta,boolean shift){ return (control?CONTROL:0) | (alt ? ALT :0) | (meta?META:0) | (shift? SHIFT:0); } private int modifiers; private int keycode=UndefinedKeyCode; public boolean match(MyKeyCombination kc){ return modifiers==kc.modifiers&&keycode==kc.keycode; } @Override public boolean equals(Object obj){ return (obj==this)?true:(obj instanceof MyKeyCombination)? match((MyKeyCombination)obj):false; } //for clone private MyKeyCombination(int modifiers ,int keycode){ this.modifiers=modifiers; this.keycode=keycode; } public MyKeyCombination(boolean control,boolean alt,boolean meta,boolean shift,String key){ if(key.length()==1){ int ch = key.charAt(0); keycode = ch; if('A'<=ch && ch<='Z'){ shift = true; keycode = ch+'a'-'A'; } modifiers = getModifiers(control, alt, meta, shift); }else{ modifiers = getModifiers(control, alt, meta, shift); switch(key.toLowerCase()){ case "enter": keycode = 13;break; case "tab": keycode = 9;break; case "space": case "sp": keycode = 32;break; case "pageup": case "pgup": case "pup": keycode = -33; break; case "pagedown": case "pgdown": case "pdown": keycode = -34; break; case "end": keycode = -35; break; case "home": keycode = -36;break; case "left": keycode = -37;break; case "up": keycode = -38;break; case "right": keycode = -39;break; case "down": keycode = -40; break; case "f1": keycode=-112;break; case "f2": keycode=-113;break; case "f3": keycode=-114;break; case "f4": keycode=-115;break; case "f5": keycode=-116;break; case "f6": keycode=-117;break; case "f7": keycode=-118; break; case "f8": keycode=-119;break; case "f9": keycode=-120;break; case "f10": keycode=-121;break; case "f11": keycode=-122;break; case "f12": keycode=-123;break; case "f13": keycode=-124;break; case "f14": keycode=-125;break; case "f15": keycode=-126;break; case "f16": keycode=-127;break; case "f17": keycode=-128; break; case "f18": keycode=-129;break; case "f19": keycode=-130;break; case "f20": keycode=-131;break; case "f21": keycode=-132;break; case "f22": keycode=-133;break; case "f23": keycode=-134;break; case "f24": keycode=-135;break; default: keycode = UndefinedKeyCode; modifiers=0; break; } } } public boolean match(KeyEvent event){ KeyCode code = event.getCode(); String text = event.getText(); boolean isC=event.isControlDown(); boolean isA=event.isAltDown(); boolean isS=event.isShiftDown(); boolean isM=event.isMetaDown(); int modifiers,keycode=UndefinedKeyCode; if(code.isModifierKey() || code == KeyCode.UNDEFINED){//shiftなど return false;//常にfalse } if(code.isLetterKey()){//a-z modifiers = getModifiers(isC, isA, isM, isS); keycode = code.ordinal()-KeyCode.A.ordinal()+'a'; }else if(code.isFunctionKey()){//F1,F2,F3....,F24 keycode = -112 - (code.ordinal()-KeyCode.F1.ordinal()); modifiers = getModifiers(isC, isA, isM, isS); }else if(code.isNavigationKey()){//homeや矢印など if(code.isArrowKey() && code.isKeypadKey()){//キーパッドの矢印 keycode = -33 - (code.ordinal()-KeyCode.KP_UP.ordinal()); }else{//それ以外 keycode = -33 - (code.ordinal()-KeyCode.PAGE_UP.ordinal()); } modifiers = getModifiers(isC, isA, isM, isS); }else if(code.isWhitespaceKey()){//enter,tab,space switch(code){ case ENTER: keycode = 13;break; case TAB: keycode = 9;break; case SPACE: keycode = 32;break; } modifiers = getModifiers(isC, isA, isM, isS); }else if(code.isMediaKey()){//音量上げ下げのボタンとからしい //よく分からんから現状放棄 return false; }else if(code.isDigitKey()){//数値 if(code.isKeypadKey()){ keycode = '0'+(code.ordinal()-KeyCode.NUMPAD0.ordinal()); }else{ keycode = '0'+code.ordinal()-KeyCode.DIGIT0.ordinal(); } modifiers = getModifiers(isC, isA, isM, isS); if(keycode==this.keycode && modifiers==this.modifiers) return true; //↓例外処理。例えばShift+1はjisでは「!」など数字ではない。 if(text.length()==1 && keycode!=text.charAt(0)){ isS=false; keycode = text.charAt(0); } modifiers = getModifiers(isC, isA, isM, isS); return keycode==this.keycode && (modifiers|SHIFT)==(this.modifiers|SHIFT); }else{//わからん //TODO ここどーしよう。 //現状の問題 //たとえば、jis配列でCtrl+Shift+@を判定したい場合 //KeyCodeはback_quoteが返ってくるし、textは`になってしまっている //要するに、Shift+@は取得できない //（↑が実装できた上での話） //↓マッチしなかった場合、Shiftにより文字が変わっていることを考慮する int tlength = text.length(); if(tlength == 1){ char ch = text.charAt(0); keycode = (int)ch; modifiers = getModifiers(isC, isA, isM, isS); return keycode==this.keycode && (modifiers|SHIFT)==(this.modifiers|SHIFT); }else{ //それでも判別できない物は扱わない。 return false; } } return keycode==this.keycode && modifiers==this.modifiers; } public MyKeyCombination clone(){ return new MyKeyCombination(modifiers, keycode); } }
