Issue 80701 - combo boxes not drawn correctly
Summary: combo boxes not drawn correctly
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: 680m225
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 2.4
Assignee: ericb
QA Contact: issues@porting
URL:
Keywords: aqua
Depends on:
Blocks: 80799
  Show dependency tree
 
Reported: 2007-08-15 14:11 UTC by eric.bachard
Modified: 2009-02-10 08:05 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description eric.bachard 2007-08-15 14:11:55 UTC
m225 / Aqua / Intel

combo boxes are not drown correctly: the bottom part is missing ( size or refresh issue ? )
Comment 1 eric.bachard 2007-08-15 14:12:59 UTC
set keyword
Comment 2 eric.bachard 2007-08-20 13:44:35 UTC
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 ?



Comment 3 eric.bachard 2007-08-20 13:48:02 UTC
Set target 
Comment 4 hdu@apache.org 2007-08-22 16:29:56 UTC
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.
Comment 5 hdu@apache.org 2007-08-24 10:19:00 UTC
I commited the fix to CWS aquavclcarbonfixes.
@PL: please verify
Comment 6 Raphael Bircher 2007-08-29 16:39:10 UTC
Set me in the CC
Comment 7 eric.bachard 2007-09-04 18:21:22 UTC
Issue verified fixed in aquavclcarbonfixes
Comment 8 hdu@apache.org 2009-02-10 08:05:16 UTC
Closing resolved issue.