Apache OpenOffice (AOO) Bugzilla – Issue 80701
combo boxes not drawn correctly
Last modified: 2009-02-10 08:05:16 UTC
m225 / Aqua / Intel combo boxes are not drown correctly: the bottom part is missing ( size or refresh issue ? )
set keyword
This issue is not the same as issue 80704. This time, it's question of font metrics: default values are wrong under some values depending on the display (not obligatory resolution, but probably pixel size or something I'm not sure to get yet), and some controls (probably not only combos are not correctly drawn) The problem is, a lot of things depends on font metrics, including native controls dimensions. I did several tests: Test 1: iMac20" : 1680x1050, and other résolutions. No problem, combos are correctly drawn. Test 2: Mac book pro (1440x900, and other résolutions): Problem : the bottom of combos is missing Test 3: Powerbook G4(1280x854) Problem: the bottom of combos is missing Test 4: In Tools -> Options ->View a) uncheck Use System Fonts for User Interface, validate with ok b) check it again, validate => combo are corectly drawn for ALL machines previously tested Test 5 After the issue being workarounded with test4, open a new frame in whatever machine previously having the trouble. e.g. : open tools options again, or a new Writer sheet => the issue appears again To fix that issue, I suggest: - we should modify the default value ( piwel size or the constant characterizing the screen resolution) - we should try to check and apply _sooner_ the font metrics we retrieve from the system, to avoid new frames using wrong values. I'll try to find where in the code the problem stays, but maybe Herbert will fix that more fastly than me ?
Set target
The root cause of this problem is that ComboBox::ImplCalcEditHeight() in vcl/source/control/ combobox.cxx doesn't take the native widget size into account properly. Since this method the magic number "4" must have made some sense sometimes and the method contains new code updates to handle the mbNoFocusRects&&noDropDown case I'm afraid that the simple fix to just take the bigger of textheight and native widget height would need some regression testing by someone who is familiar with the background of the original code.
I commited the fix to CWS aquavclcarbonfixes. @PL: please verify
Set me in the CC
Issue verified fixed in aquavclcarbonfixes
Closing resolved issue.