Community
Participate
Working Groups
3.5RC1 To reproduce click on File->Switch Workspace->Other. When the dialog comes up the Workspace combobox is scrolled to the right, so that the left part of the workspace path (11 characters in my case) is hidden. This problem doesn't happen on Linux, or with read-only comboboxes. Marked critical due to high visibility and large number UIs affected.
Not for 3.5 For me, the path is not long enough to fill the combobox. Even if it was, I'd rather see the right part of the path. Was this different for you on 3.4.2 ? I believe this is platform behaviour (always being like this).
Not a regression, 3.4 has the same behaviour. Combo is scrolling to show the caret. Closing as platform behaviour (wont fix).
Created attachment 137072 [details] Initial appearance of the combobox
Created attachment 137074 [details] After scrolling text into view This screen shot shows that the text is much shorter than the available width of the combobox.
Created attachment 137075 [details] In 3.4.1 combobox works as expected
works for me with 3.5 RC2. I also run Windows XP classic theme.
Few details about environment: Dialog font in Eclipse: Tahoma Regular 8 Display DPI: 120 Another observation. When a very similar workspace selection dialog is shown during Eclipse startup, the text is fully visible.
See also bug 277004 that indicates that I'm not the only one who sees the problem and that it is not limited to the workspace selection dialog.
Checked with 3.5RC2 - same problem.
Another observation. The text scrolls into view when focus moves from Eclipse to another application.
FH says "3.4 has the same behaviour." SP says" "In 3.4.1 combobox works as expected" Who is right? If the workspace text scrolls away the picture SP provides in comment #3 is right, then this is a pretty visible and bad bug. Does it only happen on non-XP theme?
This problem also occurs when an editable Combo is placed in a toolbar as a Contribution. The initial content is scrolled too far left. The problem is unique to Windows and I've observed it in 3.5.2 and 3.6M5. It does not occur on Linux. I would appreciate a work-around if anyone has come up with one. (The CCombo widget on Windows has a similar problem but manifests differently [bug #55074])
*** Bug 300587 has been marked as a duplicate of this bug. ***
The bug is reproducible on my laptop. If somebody is interested, I can bring my laptop for a debugging session during EclipseCon.
Felipe, I have Sergey's preference file which causes this to happen on a 3.6 M6. I'll send it to you.
Created attachment 163435 [details] patch for Combo
Fixed > 20100330
The issue came back in 3.6.1.
Does it work on 3.7 M2a ? I can't remember how to reprouce this problme, File->Switch Workspace->Other works for me (always did). Bog, wasn't you who helped to recreate this problem ?
CQ:WIND00189814
*** Bug 328985 has been marked as a duplicate of this bug. ***
This bug likely only surfaces if you use a non-default Dialog font. I can observe the issue on Windows 7. The issue is present even if the combo box text area has plenty of room to display the text. Steps to reproduce in workspace, also showing the now you see the defect, now you don't nature of the bug. 1) File->Switch Workspace->Other Observe combo with complete path text displayed and lots of space to have more text displayed. 2) Windows->Preferences->General->Appearance->Colors and Fonts->Dialog Font 3) Press Edit... button 4) Select the "size" that is already selected. For instance, my Dialog font is Segoie UI Regular 9 point. So I just select the already selected size 9. 5) Select Ok, Ok to close all dialogs 6) File->Switch Workspace->Other Notice that the combo box text area shows the text scrolled to the left by about 7 characters, even though there is plenty of space in the text box to show the entire text. In fact, the text is the same size since we picked the same point size. The only diference here is that Combo.setFont() is being called due to the non-default Font. Notice that if you let the Workspace Launcher dialog loose focus the combo box text springs to the correct display (all text visible). Interestingly the highlight colour is gone (no doubt since the window does not have focus) Upon returning focus to the dialog all is "normal". However, closing and reoopening the dialog will show the shifted behaviour. 7) Windows->Preferences->General->Appearance->Colors and Fonts->Dialog Font 8)Press "Restore Defaults" button and then OK. 9) File->Switch Workspace->Other Notice that all appears normal once again. When a non default dialog font is set Combo.setFont(Font) is called, resulting in a call to Combo.setScrollWidth(). I believe the error is in here where an attempt is made to calculate the appropriate scroll width. I'm not particularly familiar with the code but iteration throgh the for loop seems suspicious.
Created attachment 188001 [details] Snipit demonstrating the problem Attaching a snippet that demonstrates the problem with just a plain old combo box. Run the snippet and notice that the combo box has plenty of space to display all the text (and more). Comment out the combo.setFont() call and notice things are displayed properly. You can use even smaller fonts and see that the problem also exists. If you make the font small enough there is a cut off where everything can be displayed. I believe this is more evidence we are just getting the size calculation wrong
*** Bug 335354 has been marked as a duplicate of this bug. ***
With the defect apparently still there, and a reproducable test case, I'm cleaning the obsolete "3.6M7" target milestone and setting 3.7 optimistically. SWT team please forgive if this is not appropriate.
Ping ? Again and again I'm seeing this issue in our product, and while it does seem cosmetic at first it's REALLY annoying. Even short strings which should find ample space in a combo aren't shown entirely, forcing me to click into the combo. That's annoying. Today I've seen a funny variant of the issue: On Win7 (64bit, with a 32bit JVM), I have a dialog with a large combo. When I use the mouse to drag the right-hand border of the dialog to resize it, the behavior is completely nondeterministic: - make narrow, then wide -> Text in combo fully shown. - narrow, then wide -> First 2 characters hidden. - narrow, then wide -> First 4 characters hidden. - narrow, then wide -> fully shown. - narrow, then wide -> First half of a character hidden. ... A fix for this would be REALLY appreciated, or an explanation how we can code our dialogs to avoid the problem.
(In reply to comment #26) I'm surprised that importance was reduced so much for an issue that is so embarrassing and is a clear regression.
Created attachment 194763 [details] Patch
Fixed in HEAD. Feb/24/2009 - Bug 240657 add the lockText code (replace the old fix for combo auto matching text from the list during resize) Mar/30/2010 - Bug 277618 add lockText to callWindowProc (broke - Bug 240657 as it didn't stack the value of lockText) Jul/5/2010 - Bug 240657 (fixed lockTex to use stack, fixing the problem introduced by Bug 277618) May/4/2011 - Bug 277618 still broken. The original fix for Bug 240657 (Feb/24/2009) added the lockText code to setScrollWidth(int) (used by setFont) and WM_SIZE. That code prevent the text control from processing WM_SETTEXT when lockText == true. It seems that preventing the text from processing WM_SETTEXT after WM_SETFONT followed by a WM_SIZE leaves the h scrolling position wrong in the text. (The problem only happens when there is matching of the content in the text and an item in list) The fix is, instead of ignoring WM_SETTEXT (return false), setting the same string back in the text control.
Nice detective work, Felipe! :)
We are not able to move up to Eclipse 3.7 yet. Is it possible to port this fix back to Eclipse 3.6.2? Thanks.
