Следуя предложению @ Slaw отредактировать вопрос, кажется, лучше всего дать ответ на основе того, что я узнал.
Цель состоит в том, чтобы переопределить обработку по умолчанию для определенных KeyEvent s, которые являются Источник на уровне ListView. Если это невозможно, то это поможет точно знать точно , как работает обработка по умолчанию, чтобы у меня было представление о том, что мне нужно обойти.
Появляется API JavaFX чтобы указать эту обработку в классе ListViewBehavior, который является ограниченным API, и поскольку он ограничен, самый простой способ получить к нему доступ (по моему опыту) - через класс ListViewSkin, который создает и содержит ссылку на класс поведения, когда ListView создан. Эта ссылка является полем private (нет методов доступа, например, getBehavior ()) и поэтому может быть доступна только в экземпляре ListViewSkin.
Поведение по умолчанию установлено в ListViewBehavior конструктор из числа KeyMapping объектов, которые добавляются в InputMap (с именем listViewInputMap) путем добавления каждого сопоставления к ObservableList (с именем mappings) для карты; код для добавления отображений находится в классе BehaviorBase, который является родительским для ListViewBehavior.
@ Kleopatra предложила несколько возможных решений, которые теоретически будут работать, за исключением того, что все классы, кроме ListViewSkin, являются ограниченный API. Это означает, что к поведению нельзя получить доступ для использования отражения, и оно не доступно из openjdk / jfx. Предложение Клеопатры «скопировать и вставить из кожи и поведения» должно быть возможным (я не пробовал), но не практично; это потребовало бы огромного количества работы, по крайней мере, с 1000 строками кода (я думаю) для чего-то, что должно требовать не более 30-50 ... не стоит горя.
Так как обработка по умолчанию не может быть переопределена или заменить (по крайней мере, на практике), затем точно необходимо определить, как это поведение установлено и работает.
Указано поведение для KeyMapping s, упомянутое выше. в private методах в ListViewBehavior классе. Сами методы просты, и в этом смысле они полезны. Ряд моментов, касающихся поведения, неясен, например:
- Нет указания на то, добавлено ли конкретное поведение в качестве обработчика или фильтра (т. Е.
listView.addEventHandler(..) или * 1040). *? Это определяет, когда на самом деле выполняется поведение, что, в свою очередь, влияет на возможность установки какого-либо противодействующего пользовательского поведения, и если да, то где; EventType s, для которых добавлено поведение, не указано ; - Нет никаких указаний ни относительно порядка, в котором добавляются элементы поведения, ни относительно того, может ли порядок зависеть от каких-либо нераскрытых условий, и
- Нет никаких гарантий, что указанное поведение в частных методах, упомянутых выше, содержится все встроенное поведение.
Этот список может быть не исчерпывающим, могут существовать другие области, которые кто-то может посчитать еще более важными. Но этого достаточно, чтобы увидеть как это оставляет разработчиков в положении, когда они должны летать вслепую, ... и без толку ason.
Было бы несправедливо не упомянуть тот факт, что существует способ предотвратить запуск обработки по умолчанию в пользу пользовательской обработки. Это можно сделать, добавив фильтр на KeyEvent s к ListView, который принимает событие. Но это решение не является идеальным, поскольку неопределенности, перечисленные выше, все еще остаются. Кроме того, будут ли у события случайные побочные эффекты? Будет ли это препятствовать выполнению поведения по умолчанию, когда это необходимо? Короче говоря, разработчики по-прежнему остаются слепыми, потому что эти неопределенности могут быть выяснены только с помощью утомительного процесса разработки и наблюдения за повторяющимися пробными и ошибочными упражнениями, чтобы точно определить, что может происходить. Это хороший способ программирования?
Наконец, замечание @ Kleopatra о том, как поведение JavaFX должно было в конечном итоге стать опубликованным c и что произошло, заслуживает внимания. Исходя из моих собственных наблюдений здесь и в других областях, эта информация не удивительна. Действительно, это объясняет, почему JavaFX, будучи отличной платформой, если рассматривать ее в целом, тем не менее имеет ряд недостатков, которые - если их не устранить - не позволят эффективно заменить Swing (что в качестве напоминания было одним из заявленных цели, о которых говорится Oracle о, так долго а go). Это мнение, что многие эксперты, которые забыли больше, чем я когда-либо узнаю, наверняка будут не только оспаривать, но и неистово; однако это не меняет фактов.