Community
Participate
Working Groups
Build Identifier: 20100617-1415 in an editable Combo (not READ_OLNY), set a list of items (ex: "1", "8", "16", "32") type or set 3 in the combo text, when the combo is repaint by resizing the windows by example, the combo value is changed to value 32 from the given list ? instead of 3. when binding a model on combo, displayed value is incoherent with model one... Reproducible: Always Steps to Reproduce: 1. run the given testCombo initialized with setText("3") 2. at startup 32 is display in combo instead of 3 ? 3. fill again 3 in combo 4. change windows with (or click button "re-layout") 5. 32 is selected again in combo ?
Created attachment 178053 [details] test combo case
Works for me. > Steps to Reproduce: > 1. run the given testCombo initialized with setText("3") > 2. at startup 32 is display in combo instead of 3 ? for me, 3 shows > 3. fill again 3 in combo > 4. change windows with (or click button "re-layout") > 5. 32 is selected again in combo ? for me, it still shows 3 after clicking the "re-layout" button. Tested on Xp and Windows 7 please, try with the latest version: http://www.eclipse.org/swt/cvs.php
This same defect occurs in Eclipse 3.6.0, Windows XP, Windows 7. Create dialog with editable combo. In the createDialogArea() method, set the combo items list to items such as {"test1", "test12"}. After that use setText() to set the combo value to value that is not in the items list but matches the beginning of an item from the combo; example - "test". Open the dialog. The text is set properly. But later when the shell calls layout() and sets the controls size, the combo value will be changed to "test1". So when the dialog is displayed, the value will be "test1". This is known issue with Windows combo. In the Combo class there is comment: /* * Feature in Windows. When an editable drop down combo box * contains text that does not correspond to an item in the * list, when the widget is resized, it selects the closest * match from the list. The fix is to lock the current text * by ignoring all WM_SETTEXT messages during processing of * WM_SIZE. */ In the Combo class they use lockText flag to avoid such problems. I compared the Combo code in Eclipse 3.5.1 and 3.6 an saw that setting lockText is done on one more place in Eclipse 3.6. ---------------- long /*int*/ callWindowProc (long /*int*/ hwnd, int msg, long /*int*/ wParam, long /*int*/ lParam) { if (handle == 0) return 0; if (hwnd == handle) { switch (msg) { case OS.WM_SIZE: { ignoreResize = true; if ((style & SWT.READ_ONLY) == 0) lockText = true; long /*int*/ result = OS.CallWindowProc (ComboProc, hwnd, msg, wParam, lParam); if ((style & SWT.READ_ONLY) == 0) lockText = false; ignoreResize = false; return result; } } --------------------- My guess is this setting lockText to false there is somehow causing the problem. This is very annoying problem, because in our RCP we use editable combos that have history and this bug causes false values to show up when the user opens a dialog. One workaround is to add the new value to the combo before using setText(), but it is hard to do it everywhere in the code where combo is used. Please give some workaround for Eclipse 3.6.
I'm 99.9% sure this problem is already fixed. I believe it was fixed along with bug 240657 or 277618 or 240657. As a matter of fact, I was able to see the problem you described by removing the fix for bug 240657. Please get the code from HEAD and try your code again: http://www.eclipse.org/swt/cvs.php
(In reply to comment #4) > I'm 99.9% sure this problem is already fixed. True. I got the SWT plugins from one of the latest 3.6.1 milestone builds and it is fixed. Sorry about the confusion.
(In reply to comment #5) sorry I was in vacations... Thanks for the tests ! Is there a workaround for my RCP application still based on Galileo (3.5) ? as installing swt jar of the latest 3.6.1 milestone builds or it's incompatible/risky on Galileo ? I have to close this bug ?
(In reply to comment #6) > (In reply to comment #5) > sorry I was in vacations... Thanks for the tests ! > Is there a workaround for my RCP application still based on Galileo (3.5) ? as > installing swt jar of the latest 3.6.1 milestone builds or it's > incompatible/risky on Galileo ? It would probably work but it is hacky (and unsupported). The best option is to upgrade your RCP app to 3.6.1. > I have to close this bug ? done *** This bug has been marked as a duplicate of bug 240657 ***
