Bugzilla – Full Text Bug Listing
| Summary: | Selection events not being fired | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | paj262 | ||||||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | pwebster, remy.suen | ||||||||
| Version: | 4.1 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
paj262
Created attachment 195977 [details]
jar file with Eclipse Project illustrating the problem
I was able to reproduce on linux-gtk PW Created attachment 196036 [details]
exported eclipse project
This can be imported.
PW
I can't seem to be able to reproduce the problem with Paul's project on Windows XP. paj262, your editor needs to implement the setFocus() method. It is against the API contract to leave it as a no-op. Try not having it blank and see how it goes for you. Created attachment 196067 [details]
Updated project with a text control
I added a Text control onto the editor page and set the focus to that text control from setFocus().
The first editor opens normally.
When I select a different item I get 2 selectionChanged events (one for the original and one for the new) resulting in two new editors and I get a RuntimeException.
(In reply to comment #5) > When I select a different item I get 2 selectionChanged events (one for the > original and one for the new) resulting in two new editors and I get a > RuntimeException. When you click and activate the view, the workbench sees that the active part has changed so it asks the view for its selection to notify listeners about the change (first notification). Then your click goes through and the selection event is processed and the workbench is notified about the change in selection (second notification). I am not sure why you don't just attach a selection listener to your own viewer instead of putting it on the workbench window. (In reply to comment #6) > (In reply to comment #5) > > When I select a different item I get 2 selectionChanged events (one for the > > original and one for the new) resulting in two new editors and I get a > > RuntimeException. > > When you click and activate the view, the workbench sees that the active part > has changed so it asks the view for its selection to notify listeners about the > change (first notification). Then your click goes through and the selection > event is processed and the workbench is notified about the change in selection > (second notification). > > I am not sure why you don't just attach a selection listener to your own viewer > instead of putting it on the workbench window. I don't understand why the workbench would need to notify listeners of a selection change when the active part changes. This seems completely unrelated to the selection. I find it bit odd to deliver a selectionChanged event when the selection actually hasn't changed. To me this means that the name of the method is incorrect. I can easily work around the double selectionChanged events so it's not that much of an issue. We attach to the SelectionService as we are writing modular software in which we have different methods to navigate. The TableView/TreeView being only one method. Besides the editor we also have several secondary views reacting to the same selection events. (In reply to comment #7) > I don't understand why the workbench would need to notify listeners of a > selection change when the active part changes. This seems completely unrelated > to the selection. The workbench window's active part has changed, so its (the workbench window's) selection has changed. Consider you have two views, A selecting B, and C selecting D. When the workbench window's active part is A, what is its (the workbench window's) selection? B. When the user activates part C, what is the workbench window's selection? It's D now. > I find it bit odd to deliver a selectionChanged event when the selection > actually hasn't changed. To me this means that the name of the method is > incorrect. The workbench window's current selection has changed. So we notify consumers about this. (In reply to comment #8) > (In reply to comment #7) > > I don't understand why the workbench would need to notify listeners of a > > selection change when the active part changes. This seems completely unrelated > > to the selection. > > The workbench window's active part has changed, so its (the workbench window's) > selection has changed. > > Consider you have two views, A selecting B, and C selecting D. When the > workbench window's active part is A, what is its (the workbench window's) > selection? B. When the user activates part C, what is the workbench window's > selection? It's D now. > > > I find it bit odd to deliver a selectionChanged event when the selection > > actually hasn't changed. To me this means that the name of the method is > > incorrect. > > The workbench window's current selection has changed. So we notify consumers > about this. I understand that the WorkBench now has a different selection. But the selection changed method is passed a WorkbenchPart which to me indicates it is a change in that part. In practice what I get is 2 notifications from the same part (View). The documentation from ISelectionService states: "A selection service tracks the selection within an object." If the intention is to also notify which object (WorkbenchPart) becomes active then the documentation of ISelectionService should make this clear. Note I also get notification when I switched away from my application and then switch back. Again, if this is intended then that should also be made clear in the documentation of ISelectionService. Is there any way I can avoid the RuntimeException? (In reply to comment #9) > > Is there any way I can avoid the RuntimeException? The best you can do is to put your open editor call in a display.asyncExec(*). Then it won't be called until the view activation is done. I'll point out that it will make it impossible for you to ever go back to your view successfully in any useful way, as changing to your view will fire a selection event which will open an editor and activate it. As for the selection change listener API, it's quite literal. ISelectionListener will get notified when the selection changes. The fact that the part is included in the method call satisfies "the part that contains the selection". It doesn't specify that it must be a new or different part than last time. The workbench window gets to decide when its selection changes. It must change when the active part's selection changes, and when the active part itself changes. PW (In reply to comment #9) > Note I also get notification when I switched away from my application and then > switch back. Again, if this is intended then that should also be made clear in > the documentation of ISelectionService. This doesn't happen to me. I don't get extraneous print statements when I Alt+Tab from one application to another. |