Community
Participate
Working Groups
Created attachment 287701 [details] Snippet showing the problem As identified in Bug #577857 when setting the selection of a checkbox button programmatically via setSelection() the selection listener is not called. PFA a snippet showing the problem.
You may be right Alois, with Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=577857#c3 that this is on purpose. The Javadoc says the selection listener is called when the user selects the button.
Niraj, WDYT? Should be selectionListener be called if we call setSelection on a Button?
Was to quick with pressing the submit button. What I forgot to write is that I'm not sure if it is SWT bug or not. Not having the selection listener called has also advantages.
AFAIK this is by design. Same behavior also exists in tables or trees. If you programmatically set the selection, your program knows what it set the selection to, so it can perform additional work explicitly. Triggering a listener may in fact complicate matters, and most programmatic uses would have to temporarily disable such listeners. Consider a form with several fields, and a selection listener that triggers form validation. When you're initializing the form programmatically, you probably don't want that listener to be triggered on setSelection() -- it might mark the form input as invalid unless you had set other fields in the form to consistent values, too. However, when the selection changes due to triggers outside your code, such as user interaction, then you want and in fact need listeners to be invoked.
Similar questions have been asked years ago: https://stackoverflow.com/questions/9102026/programmatically-fire-a-rcp-selection-event Though there are also questions that ask how to disable the firing of selection changed (on structured viewers): https://stackoverflow.com/questions/24245554/how-to-set-selection-for-treeviewer-without-firing-selectionchanged For structured viewers there seems to be a difference when a control has focus or not, which could be another bug.
