0

I am trying to get a list of the currently existing TreeCells out of my TreeView. My current attempt looks like this:

private Set<MyTreeCell> getMyTreeCells(){
    try {
        @SuppressWarnings("unchecked")
        Field f = ((VirtualContainerBase<TreeView<myNode>, TreeViewBehavior<myNode>, MyTreeCell>) myTreeView.skinProperty().get()).getClass().getDeclaredField("flow");
        f.setAccessible(true);
        @SuppressWarnings("unchecked")
        Field g = ((VirtualFlow<MyTreeCell>) f.get(((VirtualContainerBase<TreeView<myNode>, TreeViewBehavior<myNode>, ProofTreeCell>) proofTreeView.skinProperty().get()))).getClass().getDeclaredField("cells");
        g.setAccessible(true);
        @SuppressWarnings("unchecked")
        ArrayLinkedList<MyTreeCell> l = (ArrayLinkedList<MyTreeCell>) g.get(((VirtualFlow<MyTreeCell>) f.get(((TreeViewSkin<myNode>) myTreeView.skinProperty().get()))));
        Set<myTreeCell> s = new HashSet<>();
        s.addAll(l);
        return s;
    }
    catch (NoSuchFieldException e) {
        e.printStackTrace();
    }
    catch (SecurityException e) {
        e.printStackTrace();
    }
    catch (IllegalArgumentException e) {
        e.printStackTrace();
    }
    catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    return null;
}

Unfortunately it throws java.lang.NoSuchFieldException: flow. But why? Clearly the Field flow exists in the Class VirtualContainerBase.

Please note that I only wrote this for fun, and not to actually be used in productive code. I already have a cleaner solution for the problem.

spilot
  • 625
  • 1
  • 7
  • 20

1 Answers1

1

VirtualContainerBase declares flow, but myTreeView.skinProperty().get().getClass() does not return VirtualContainerBase.class, it returns TreeViewSkin.class. Since getDeclaredField() only returns fields declared in that class, not inherited fields, you get the exception.

I think you can just do

Field f = VirtualContainerBase.class.getDeclaredField("flow");
Field g = VirtualFlow.class.getDeclaredField("cells");

You can also eliminate much of the casting you have, as in this example:

import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;

import com.sun.javafx.scene.control.skin.VirtualContainerBase;
import com.sun.javafx.scene.control.skin.VirtualFlow;

import javafx.application.Application;
import javafx.geometry.Insets;
import javafx.geometry.Pos;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.TreeCell;
import javafx.scene.control.TreeItem;
import javafx.scene.control.TreeView;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;

public class GetTreeCellsByReflection extends Application {

    @SuppressWarnings({ "restriction", "unchecked" })
    @Override
    public void start(Stage primaryStage) {
        TreeView<Integer> tree = createRandomTree(100);
        Button findCells = new Button("Find cells");
        findCells.setOnAction(e -> {
            try {
                Field flowField = VirtualContainerBase.class.getDeclaredField("flow");
                flowField.setAccessible(true);
                Field cellsField = VirtualFlow.class.getDeclaredField("cells");
                cellsField.setAccessible(true);
                Object flow = flowField.get(tree.getSkin());
                ((Iterable<TreeCell<?>>) cellsField.get(flow)).forEach(System.out::println);;
            } catch (Exception exc) {
                exc.printStackTrace();
            }
        });

        BorderPane root = new BorderPane(tree);
        BorderPane.setAlignment(findCells, Pos.CENTER);
        BorderPane.setMargin(findCells, new Insets(5));
        root.setBottom(findCells);

        Scene scene = new Scene(root, 600, 600);
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    private TreeView<Integer> createRandomTree(int numItems) {
        Random rng = new Random();
        TreeItem<Integer> root = new TreeItem<>(0);
        List<TreeItem<Integer>> items = new ArrayList<>();
        items.add(root);
        for (int i = 1 ; i < numItems ; i++) {
            TreeItem<Integer> item = new TreeItem<>(i);
            items.get(rng.nextInt(items.size())).getChildren().add(item);
            items.add(item);
        }
        return new TreeView<>(root);
    }

    public static void main(String[] args) {
        launch(args);
    }
}
James_D
  • 201,275
  • 16
  • 291
  • 322
  • Now I am unsure whether to use this for accessing the Cells or my other solution: http://stackoverflow.com/questions/32335015/get-a-list-of-all-treecell-objects-that-currently-exist-in-a-treeview/35121956#35121956 – spilot Feb 01 '16 at 02:03
  • This solution would break if the underlying implementation changed; it would be quite feasible, as one of very many examples, for the JavaFX designers to extract a superclass of `VirtualContainerBase` and move the declaration of `flow` there. – James_D Feb 01 '16 at 02:10
  • True, thank you. Do you know if there is a specific reason TreeView does not provide getCells()? I can imagine a huge amount of use cases for it. – spilot Feb 01 '16 at 02:12
  • Honestly, I can't see a real need to get the existing cells. Cells are views of the data which observe the data; so modifications to the data are reflected in the cells. So you should really just interact with the data (i.e. the `TreeItem`s and the wrapped value). There is some functionality that's missing that could be useful (e.g. which *items* are currently visible, etc), but accessing the cells is not something you should need if the application is properly designed, imho. – James_D Feb 01 '16 at 02:17
  • That's right, I used the Cells as a vehicle to find out which and how many items currently are visible. – spilot Feb 01 '16 at 02:22
  • I answered a similar question on this regarding a list view recently. It uses a slightly different approach to either approach you propose. http://stackoverflow.com/questions/35076272/javafx-listview-retrieve-position-of-a-row/35076915#35076915 This approach really tracks items, instead of keeping track of cells. – James_D Feb 01 '16 at 02:27