Community
Participate
Working Groups
I never receive notice of a CheckStateChangedEvent for my CheckboxTableViewer control. The API docs say that there is "no effect if an identical listener is already registered", but I did not register another listener, so if there is one, how did it get registered? Or more specifically, how can I find out when a checkbox inside a CheckboxTableViewer has been selected? Thanks, Sean
Created attachment 3679 [details] Source Example This is a test case inside of a Launch Configuration tab. The necessary XML for plugin.xml is commented out at the top of the source code.
In your example, you are directly creating SWT items in the widget used by the viewer. This is crossing levels of abstraction. When using JFace viewers, you should not generally manipulate the SWT control directly, except for layout. Viewers are model-based adapters to SWT widgets. You need: - your domain model (should not depend on SWT or JFace code) - a viewer of your choice to show the model - a content provider that maps between the model and the viewer - it provides the initial content of the model to the viewer; - it also tracks changes in the model, and updates the viewer accordingly - a label provider that provides labels (text and image) for elements in the model - optionally a sorter - optionally one or more filters - optionally various listeners (selection changed listener, check state listener, etc) Once the viewer is all set up, - use viewer.setInput to tell the viewer about your model - the viewer then tells the content provider about the input, allowing it to hook any listeners on the model, and gets the initial list of elements to show - the viewer passes the elements through the filters and sorter as necessary, and creates the necessary items - when the model changes, the content provider is notified via the listener it hooked, and should update the viewer using add/remove/update/refresh on the viewer
Created attachment 3896 [details] Fixed up TestLaunchApplicationTabGroup.java This configures a content provider, label provider, sorter, and sets the input to be a model. In this case, the model is an unchanging array of model elements. The model elements are two-element arrays mimicking a property object. The content provider is an ArrayContentProvider, which handles the common case where the model is a static array. The label provider just takes the strings out of the array. The sorter sorts based on the first item in the array (the property name).
Not a bug in the viewers. With the attached changes, the check state listener is now called. FYI, the reason it wasn't working is that, internally, viewers use setData() on the SWT items to remember the corresponding model element. Since you created the SWT items yourself, they did not have the model element set. CheckBoxTreeViewer.handleSelect does a null check and does not fire the event if getData() returns null. Note that viewer listeners like selection listeners and check state listeners are always in terms of model elements, not SWT widgets, preserving the abstraction.
Wow, I did not know all of this. Thanks so much for your help. -Sean
