TableViewで特定の属性を持つ行のみCheckBoxを表示したい

Question

表題の通りなのですが、TableViewにCheckBox付の列を表示するようにしていますが、データを構築する際に特定の属性を持つものだけCheckBoxを表示したいとやっているのですが、思うようにうまくいきません。

一部抜粋していますが、やり方として次のようなコードを書いています。

Callback<TableColumn<Parson, Boolean>, TableCell<Parson, Boolean>> callBackCheck = new Callback<TableColumn<Parson, Boolean>, TableCell<Parson, Boolean>>(){
	@Override
	public TableCell<Parson,Boolean> call( TableColumn<Parson,Boolean> param ) {
		return new CheckBoxTableCell<Parson, Boolean>() {
			@Override
			public void updateItem(Boolean item, boolean empty) {
				super.updateItem(item, empty);
				if (!empty && item != null) {
					TableRow  row = getTableRow();
					Parson selitem = (Parson)row.getItem();
					setVisible((selitem.getDataType() != 1)); // 属性により非表示にする
				}
			}
		};
	}
};

   ・
   ・
   ・
ObservableList<TableColumn<Parson, ?>> cols = tableView.getColumns();
TableColumn checkCol = cols.get(0);
checkCol.setCellValueFactory(new PropertyValueFactory<>("view"));
checkCol.setCellFactory(CheckBoxTableCell.forTableColumn((TableColumn<Parson, Boolean>)checkCol));
checkCol.setCellFactory(callBackCheck);

表示するTableViewのデータがスクロールしないほど少ない場合は問題ないのですが、データを増やしてスクロールさせてみるとCheckBoxが表示されているところとされてないところはあるのですが、属性と関係なく表示されたりされなかったりとなってうまくいきません。

そもそもやり方が間違っているのかもしれないと思い質問させていただきました。
よろしくお願いします。

Comments

[KSwordOfHaste]

アイテムのdataTypeプロパティーはテーブル表示中に編集したり変化することがあるでしょうか？

[XCUBE]

ありがとうございます。dataTypeは最初に表示してから変化することはないです。

[KSwordOfHaste]

あ・・・すみません、トンチンカンな質問してしまいました。

Answer 1

訂正：最初の回答は間違っていたようです。申し訳ありません。
CellのvisibilityはTableViewやCellの基底クラスの方の制御の影響を強く受けるようで、せっかくsetVisible(false)にしても直後にsetVisible(true)にされてしまうことがあるようです。多分Cell領域がTableViewの可視領域に入るとそのような動きになるのではないでしょうか（あくまで想像です）。

本件はどのような対処にするのがよいのか自分には少々難しいです。CheckBoxTableCellのようなカスタムセルの場合、setGraphic()やsetVisible()によって外観を制御しているのですが実際にどのような制御を行っているかは必ずしも明文化されてないと思います。下手に派生クラス側で制御しようとすると基底クラスに予期せぬ制御をされてしまう可能性がある以上、基底クラスの実装まで踏み込んでみないと確実な方法がわかりません。しかし本来隠蔽されているはずの実装に基づき実装するのは危険ですよね・・・。公開されている仕様のみでうまく制御できる方法が思いつけばそれはそれでよいのですが・・・

一応それらしく動くあまり乱暴ではなさそうな方法があったので一応参考までにコードを載せてみます。しかし充分にCheckBoxTableCellの振る舞いを調べた上での実装ではないのでこの実装でよいかどうかはCheckBoxTableCellがどのタイミングでsetGraphicを呼び出すかをよく調べた方がよいと思います。また、こうした対処の常でJDKのバージョンが変わる際に再度検証が必要かも知れません。JavaFXはJDK8時点では充分安定しておらずJDK9で大規模なリファクタリングが行われているようですので要注意と思います。

Callback<TableColumn<Parson, Boolean>, TableCell<Parson, Boolean>> cb2 = tc -> new CheckBoxTableCell<Parson, Boolean>() {
  @Override
  public void updateItem(Boolean item, boolean empty) {
    super.updateItem(item, empty);
    updateVisiblity();
  }

  @Override
  public void updateIndex(int i) {
    super.updateIndex(i);
    updateVisiblity();
  }

  private void updateVisiblity() {
    int index = getIndex();
    boolean visibility = index != -1 &&
        getItem() != null &&
        getTableView().getItems().get(index).getDataType() != 1;
    if (!visibility)
      setGraphic(null);
  }
};
...
checkCol.setCellFactory(cb2);

以下最初の回答

そもそもやり方が間違っているのかもしれない

個人的にはアプローチはよいと思います。ただCellの振る舞いについて注意が必要な点がありそこにはまってしまったのが原因だと思います。

###原因
Cellは特定のアイテムに結び付いているのではなく特定のプロパティの「値」に結び付いているだけなので、表示対象のBoolean値が変化した場合ならupdateItemが呼び出されますが、そうでない限りは例え別のインスタンスのプロパティーに再割り当てされたとしてもupdateItemは起動されないのです。

これは自分も全く同じことで過去にはまったのですが、ご質問を拝見したときすぐに気づけませんでした。自分にとってそれほどに勘違いしやすい仕様に思えますが、よーく考えてみると妥当な仕様だと納得した覚えがあります。表示内容は基本的に「表示しようとしている値に依存する」という考え方がベースのため「別のインスタンスに切り替わったからといってupdateItemを呼び出す必要はない」という設計なのでしょう。

###対処
updateItemによって状態を変化させるのではなく、表示対象のアイテムが切り替わったタイミングで変化させるという方法が考えられると思います。例えばソート順を変化させないならこのCellが置かれているTableRowの変化タイミングを検知すればそれができると思います。

return new CheckBoxTableCell<Parson, Boolean>() {
  {
    tableRowProperty().addListener((observable, oldRow, newRow) -> {
      Parson item = (Parson)newRow.getItem();
      setVisible(item.getDataType() != 1);
    });
  }
};

しかしソート順が変化した場合はどうなるでしょうか・・・やってみてないので実験してみるとよいと思います。ちゃんと調べてないのですが最新のJDK8ではソート順が変化してもtableRowとアイテムの対応関係は変化しないのではないかと思います。

ただJDK8の途中でTableViewのソートの実装が変わったという情報を見たことがあるので念のためtableRowプロパティーとtableRowプロパティーのitemプロパティーの両方を監視した方がよいのかも知れません。（その点は自信ないので確認した方がよいと思います）
もしそこまで配慮するなら以下のようにできます。

return new CheckBoxTableCell<Parson, Boolean>() {
  ChangeListener<Parson> itemListener = (observable, oldItem, newItem) -> {
    // newItemに従ってセルの状態を変更する処理
      Parson item = (Parson)newRow.getItem();
      setVisible(item.getDataType() != 1);
  };
  { // Cellインスタンスの初期化ブロック(無名クラスにはコンストラクターが書けないので...)
    tableRowProperty().addListener((observable, oldRow, newRow) -> {
      if (oldRow != null) oldRow.itemProperty().removeListener(itemListener);
      if (newRow != null) newRow.itemProperty().addListener(itemListener);
    });
  }
};

---

(ご質問のコードではlambda式ではなく無名クラスが使われていたりしますね。でもJavaFXなのでJava8前提でよい気がします。そこでlambda式を用いたコード例にしました)

Comments

[XCUBE]

ご回答ありがとうございます。

投降後に色々試行錯誤していました。
質問にも書いていましたか、スクロールしないような恰好で表示すれば問題なかったので、一旦TableViewを非表示にしてHeightを極端に高くしてデータを投入後にまたHeightを元に戻すという姑息な手段で逃げようとしましたが、ご指摘の通りソート時に表示がおかしくなりました。

初歩的な質問で申し訳ないのですが、ご回答いただいたラムダ式を使用した場合、CheckBoxをどのように参照すればよいかわかりません。
CheckBox.setVisible(newItem.getDataType() != 1);
で表示/非表示をしたいのです。

[KSwordOfHaste]

無名クラス内での書き方と同じです。最初のコード例でtableRowPropertyのChangeListenerをラムダ式で表現していますが{}の中身は同じですよね？後のコード例で

// newItemに従ってセルの状態を変更する処理

とコメントになっている部分に同じコードを書けばよいです。
---
はっきりさせるために解答のコードに上記を反映しておきました。

[XCUBE]

ほんとうにありかどうございます。

教えていただいたもので以下のようなコードに変更してみましたが
thisが親クラス(実行クラス)を指してしまいnewItemもParsonを指すようです。
何かお気づきの点などご指摘いただいたら幸いです。

Callback<TableColumn<Parson, Boolean>, TableCell<Parson, Boolean>> callBackCheck
= new Callback<TableColumn<Parson, Boolean>, TableCell<Parson, Boolean>>(){
@Override
public TableCell<Parson,Boolean> call( TableColumn<Parson,Boolean> param ) {
return new CheckBoxTableCell<Parson, Boolean>() {
ChangeListener<Parson> itemListener = (observable, oldItem, newItem) -> {
// newItemに従ってセルの状態を変更する処理
Parson item = (Parson)newItem.getItem();
setVisible(item.getDataType() != 1);
};
{ // Cellインスタンスの初期化ブロック(無名クラスにはコンストラクターが書けないので...)
tableRowProperty().addListener((observable, oldRow, newRow) -> {
if (oldRow != null) oldRow.itemProperty().removeListener(itemListener);
if (newRow != null) newRow.itemProperty().addListener(itemListener);
});
}
};
}
};

[XCUBE]

thisが親クラスになるのは私の勘違いでした。すいません。

ご教示いただいたコードを元に再度確認し、ソートをしてみたのですが、非表示にはできませんでした。

試しにソート時に
setVisible(false);
System.out.println(isVisible());
で属性に関係なくすべて非表示にしたところ非表示にはならず、ログもすべてtrueになっていました。

一応updateItemでは非表示にできましたが、ソート後の動作がうまくいかず、ソートのイベントでのsetVisible(false)も効かずといった感じです。

もう少し試行錯誤してみます。

[KSwordOfHaste]

すみません、実際にやってみたのですが上のコードは間違ってる点がありました。また他に配慮不足の点もあるようで少し試したのですがすんなり動いてくれません＞＜
自分でも改めて調べてみます。ちなみに自分はJDK9でやっているのですがXCUBEさんはJava1.8.0_152とかですか？できるなら合わせた方がよいかも知れませんので。

[XCUBE]

ありがとうございます。
Javaのバージョンは1.8.0_151の32bit版です(お客様の環境の32bitなもので…)。

KSwordOfHasteさんの貴重なお時間を費やすのは気が引けます・・・
気持ちだけでもほんとうにうれしいです。

[KSwordOfHaste]

JDK9とJDK8ではTableViewまわりでもいくつも変更があるようなのでJDK8でやってみることにします。なんとなく原因がわかりました。visibleはTableViewがセルが見えるようになったときに制御するためのもののようなのでこれを自前で制御するのはよくなさそうな感じです。上の回答が間違っている気がしますので、自分でももう少し調べさせてください。

ちなみに、お気遣いは無用です。そもそも自分の回答が間違っていたのですし、こういう問題は自分にとっても勉強になります。

[XCUBE]

検証いただきましてありがとうございます。
本件では特定の行のCheckBoxを変更できないようにするのが本来の目的の一つでもありますが、
setVisible(false);が効かないのであればsetDisable(true);で代用すれば、その目的は一応達成できます。
これによりㇾのON/OFFはできなくなるのですが、見た目がグレーアウトにならず、利用者にON/OFFができるように見えてしまうという問題があります。
□の枠線の色を透明もしくは背景色と同じ色に変えることができれば、疑似的にsetVisible(false);にできると思うので、ちょっとその方法を模索してみます。

大変ありがとうございました。心より感謝いたします。

[XCUBE]

上記、コメントでsetDisable(true);を代用するとしましたが、それでも並び替えるとうまくいきませんでした。

ですが、結果的にsetVisible(false);でもなくsetDisable(true);でもなくsetEditable(false);で解決しました。
見た目を非表示にするため、非表示にしたいcheckboxにIdを設定し、そのIdに対して外枠、背景などを透明にしてstyleをcssに記述しました。
その結果、疑似的ではありますが、非表示にすることができましたが、ひとつ疑問ができました。
以下のように疑似要素として disabled を付加しないとstyleが適用できませんでした。
setDisable(true);にはしていないのですが、setEditable(false);も内部的にはDisable扱いなんだなということで理解することにしました。

#Id:disabled {
　　-fx-background-color: transparent;
　　-fx-border-color: transparent;
　　-fx-fill: transparent;
}

[KSwordOfHaste]

なるほど！CheckBoxTableCellの実装を気にするよりはXCUBEさんの採られた方法の方がずっと適切だと思いました。なお、そのようにするのでしたら疑似クラスを設定してもよい気がします。Cellに対して

cell.getStyleClass().add("hidden")
cell.getStyleClass().remove("hidden")

とかやるわけです。独自のスタイルクラスなのでJavaFXランタイムがそれを勝手に変更する心配はないですし・・・css上も

.hidden {
...
}

といった感じに書けますね。IDを振る必要は特にないのでは？

[XCUBE]

アドバイスありがとうございます。
TableViewクラスの不具合なのか私のやり方が悪いのか.hiddenはうまくいきませんでした。
私としてもあまりIdは付けたくなかったのですが・・・該当するcellに直接3つのstyleを追加するか迷った結果Idを付けることにしました。
hiddenという疑似クラスがあるということが判ったことだけでも収穫です。

[KSwordOfHaste]

いえ、hiddenという疑似クラスは標準にはありません。アプリケーションで独自に定義するものです。それっぽい名前として"hidden"にしたまでです。
---
もとい・・・標準にありました！申し訳ないですがhiddenではなく独自の疑似クラス名を使った方がよいと思います。

[XCUBE]

そうやって独自のセレクタを追加できるんですか、知りませんでした。
今までIDもしくは標準のセレクタで対応していました。

そういえば暫くやっていないですがHTMLを記述するときもIDとCLASSを使う方法がありましたのを思い出しました。