Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: First of all, a little background. I display in a combo widget the contents of a database field with a relatively small domain of values. The Combo is populated with the eligible values and the user is not allowed to write in the combo text input, but can only choose from the available options. So far it looks like a perfect candidate for the SWT.READ_ONLY style. Unfortunately, the fact is that I must display precisely the value found in the database even if it does not belong to the discrete domain. In short, I need the Combo.setText() method to work, but the user disallowed to type anything. The obvious solution is to reject all Verify events by setting the "doit" field to false. The Selection events will still occur, but the combo text won't change! Say I use a SelectionListener which employs Combo.setText() to actually change the displayed text. It turns out that Combo.setText() issues a Verify event which must not be rejected - this can be achieved with a helper boolean field. The problem is that setText() puts the currently selected index to -1, which is not correct and messes the keyboard navigation in the list of values (with up and down arrows). The last resort is to call Combo.select() from the SelectionListener, but the call is rightly discarded since the selected index would be the same as the current one. Ok, let's mimic what happens during a Combo.select() and issue a corresponding Verify and subsequent Modify events. No luck - the combo text remains unchanged. I hope that I made myself understood; if not, I'm attaching a toy class used for the above experiments made on SWT 3.3.2. I'm pretty sure the same happens on 3.4.
Created attachment 111013 [details] Test class
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.