如何区分用户事件和合成事件？
我有一个 JFace 编辑器，主要由 TreeViewer 组成。 它连接到 ContentOutlinePage 以使大纲视图栩栩如生。
当其中一个接收到 SelectionChangedEvent 时，它们会调用其他 setSelection() 方法……这就是问题所在。 setSelection() 生成另一个 SelectionChangedEvent ...，从而加入无限循环。
有没有办法判断 SelectionChangedEvent 是否是由实际用户交互创建的，而不是由另一个对象调用 setSelection() 创建的？
还有更好的方法来阻止这种致命的拥抱吗？
欢迎提供线索。
I have a JFace editor that is mostly made up of a TreeViewer. This is hooked up to a ContentOutlinePage to bring the Outline view to life.
When either one receives a SelectionChangedEvent they call the others setSelection() method ... and therein lies the problem. setSelection() generates another SelectionChangedEvent ... and thus the infinite loop is joined.
Is there a means of telling if the SelectionChangedEvent was created by actual user interaction rather than by another object calling setSelection()?
Is there a better means still of stopping this sort of deadly-embrace?
Clues welcomed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，您会在例程开始时检查一个标志，以检查您是否处于事件处理程序的中间。 如果设置了该标志，则退出而不进行处理。
如果未设置该标志，则设置该标志，进行处理，然后重新设置该标志。
Generally, you would check a flag in the beginning of the routine to check to see if you are in the middle of the event handler. If the flag is set, then you exit without processing.
If the flag is not set, you set the flag, process, then set the flag back.
另一种有效的模式是删除事件侦听器，进行选择，然后再次添加事件侦听器。 这确保了代码中只有一个位置您必须担心这个问题 - 使用标志时您必须同时维护两个位置。
此外，SelectionChangedChanged 可能（但不确定）放在事件堆栈的顶部（即异步执行）。 在这种情况下，您还可以最大限度地缩短查看器不传播通知的时间。
总的来说，我发现令人失望的是，无论是否单击鼠标，生成的 SelectionChangedEvent 都是相同的。 我认为做到这一点并不像人们希望的那么容易。 我曾经不得不修改文本编辑器类的行为，以便它新增了两种插入事件（用户生成的和网络生成的），以便使该文本编辑器类共享。 我很乐意看到对此进行更多讨论。
Another pattern that works is to remove the event listener, make the selection, add the eventlistener back again. This ensures that there is a single place in the code where you have to worry about this - with a flag you would have to simultaneously maintain two places.
Also, the SelectionChangedChanged is possibly (not sure though) put on top of the event stack (ie executed asynchronously). In which case, you also minimise the period during which the viewer does not propagate notification.
Overall, I find it disappointing that the SelectionChangedEvent generated is the same, regardless of whether a mouse was clicked. I suppose it's not as easy to do that as one would hope. I once had to modify a text editor class behaviour so that it new about two kinds of insert events (user generated and network generated) in order to make that text editor class shared. I'd love to see more discussion of this.