我想将KEY_PRESSED
事件的KeyEvent
处理程序(或过滤器)添加到各种KeyCode
和修饰符(shift和/或control key down)的ListView
中。似乎JavaFX
API为大多数(如果不是全部的话)提供了默认处理,但我无法确定:
- 处理哪些事件(和类型),或者
- 它们是如何处理的("处理代码"是如何读取的?),或者
- 是否通过属性设置(例如
setOnKeyPressed(..)
与addEventFilter(..)
,或 - 是否可以覆盖/替换默认处理
这些信息是否随时可用?有没有资源可以用"通俗英语"的方式回答这些问题?还是JavaFX开发的一般政策是,这些操作是开发人员的禁区,必须在"照原样接受或放弃"的基础上接受?
提前感谢您对此提供的任何意见。
根据@Slaw编辑问题的建议,最好根据我所学到的内容提供答案。
目标是覆盖来源于ListView
级别的某些KeyEvent
的默认处理。如果这不可能,那么了解默认处理的确切会有所帮助,这样我就知道我必须解决什么问题。
JavaFX API似乎在受限制的APIListViewBehavior
类中指定了这种处理,因为它受到限制,访问它的最简单方法(根据我的经验)是通过ListViewSkin
类,该类在创建ListView
时创建并保存对行为类的引用。此引用是private
字段(没有访问方法,例如getBehavior()),因此只能在ListViewSkin
的实例中访问。
默认行为通过多个KeyMapping
对象安装在ListViewBehavior
构造函数中,这些对象通过将每个映射添加到映射的ObservableList
(命名为mappings
)而添加到InputMap
(命名为listViewInputMap
);用于添加映射的代码在作为CCD_ 22的父类的CCD_。
@Kleopatra提出了几种理论上可行的解决方案,除了ListViewSkin
以外的所有类都是受限的API。这意味着不能为了使用反射而访问该行为,也不能从openjdk/jfx访问该行为@Kleopatra的"从皮肤和行为中复制粘贴"建议应该是可行的(我还没有尝试过),但并不实用;这将涉及到至少1000行代码的堆积如山的工作(我猜),而这些代码应该不需要超过30-50行……这不值得悲伤。
由于默认处理不能被覆盖或替换(至少不能以实际方式),因此需要确定该行为的安装和操作方式。
上述KeyMapping
s的行为在ListViewBehavior
类的private
方法中指定。这些方法本身很简单,在某种程度上它们是有用的。关于行为如何运作的许多要点尚不清楚,例如:
- 没有指示是否将特定行为添加为处理器或过滤器(即
listView.addEventHandler(..)
或listView.addEventFilter(..)
?这决定了行为实际运行,这反过来影响是否有任何反要求可以安装自定义行为,如果可以,则在哪里安装 - 没有指定为其添加行为的
EventType
- 没有迹象表明行为元素的顺序也没有说明该命令是否取决于任何未披露的条件以及
- 无法保证私有中指定的行为上述方法包括所有内置行为
此列表可能并不详尽,可能存在其他人可能认为更重要的其他领域。但这些足以说明这是如何让开发人员陷入盲目的境地的。。。毫无理由。
如果不提及这样一个事实,即有一种方法可以防止默认处理支持自定义处理,那将是不公平的。这可以通过向消耗事件的ListView
添加用于KeyEvent
s的过滤器来实现。但这个解决方案并不完美,因为上面列出的不确定性仍然存在。此外,消费该活动会产生意想不到的副作用吗?它会阻止默认行为在应该运行的时候运行吗?简言之,开发人员仍然视而不见,因为只有通过设计和观察重复的试错练习来确定可能发生的事情,才能澄清这些不确定性。这是编程的好方法吗?
最后,@Kleopatra关于JavaFX行为最终如何公开以及所发生的事情的评论值得注意。根据我在这里和其他领域的观察,这些信息并不令人惊讶。事实上,这在很大程度上解释了为什么JavaFX虽然从整体上看是一个优秀的平台,但仍有许多缺点——除非得到解决——否则将阻止它有效地取代Swing(顺便提醒一下,这是Oracle很久以前宣布的目标之一)。这是一个观点,许多忘记得比我所知道的还要多的专家肯定不仅会提出异议,而且会激烈地提出异议;然而,这并不能改变事实。