riched20: add tests for EM_FORMATRANGE

[Paul Vriens]

Paul Vriens wrote:
> James McKenzie wrote:
>> Lei Zhang wrote:
>>> On Fri, Mar 13, 2009 at 12:01 PM, Paul Vriens
>>> <paul.vriens.wine at gmail.com> wrote:
>>>  
>>>> Lei Zhang wrote:
>>>>    
>>>>> Hi,
>>>>>
>>>>> In my last attempt, I submitted Troy Rollo's EM_FORMATRANGE
>>>>> implementation and with my test cases. I'm not sure what was wrong
>>>>> with the implementation, but the test cases should be ok.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>>
>>>>>       
>>>> Hi Lei,
>>>>
>>>> Pretty old patch. (June 2007)
>>>>
>>>> I just moved some of my VMware 'boxes' to my new laptop (laptop 
>>>> resolution
>>>> 1024x800) and I suddenly had some failures. The resolution that 
>>>> VMware can
>>>> use (with all those borders and the sidebar) is 1044x574. Running 
>>>> the tests
>>>> fullscreen makes them pass again.
>>>>
>>>> You can replicate this by playing with the screen resolution. The 
>>>> smaller
>>>> the resolution the more test failures.
>>>>
>>>> Any idea where I need to look?
>>>>
>>>> -- 
>>>> Cheers,
>>>>
>>>> Paul.
>>>>
>>>>     
>>> Is this on Windows in VMWare? I'm not getting any riched20 crosstest
>>> failures here at 800x600.
>>>
>>>
>>>
>>>   
>> Interesting that this should fail on a VMWare workstation setup.  The
>> tests are pretty straightfoward.
>>
>> Also, I have not worked on this due to other pressures of life.  Would
>> someone like to take this over and finish it?  This would solve a couple
>> of open bug reports and fix some complaints about text rendering.
>>
>> James McKenzie
>>
>>
>>
> As said before, this issue can be seen on both VMware and real boxes. 
> It's much easier of course to play around with resolutions on VMware.
> 
> I'm currently trying loads of different resolutions to see if there is 
> some logic. I do see that when I'm reducing just the horizontal 
> resolution for example that the result of the EM_FORMATRANGE message 
> changes at certain intervals (no logic found yet though).
> 
> The number that keeps coming back is '15' :
> 
> Hor    Vert    EM_FORMATRANGE
> 
> 1040    800    20
> 937    800    16
> 832    800    15
> 712    800    14
> 652    800    13
> 547    800    12
> 517    800    9
> 412    800    7
> 382    800    6
> 
> The difference between the horizontal resolution when the results change 
> is always a multiple of 15 (can't check the first one as 20 is the 
> maximum returned).
> 
> The same behavior can be seen with a vertical resolution of 600:
> 
> Hor    Vert    EM_FORMATRANGE
> 
> 1238    600    20
> 1222    600    18
> 1057    600    16
> 1012    600    15
> 937    600    9
> 547    600    7
> 517    600    6
> 
> And with a horizontal resolution of 979 (yeah I know):
> 
> Hor    Vert    EM_FORMATRANGE
> 
> 979    724    20
> 979    712    15
> 979    472    7
> 
> So any idea about that number '15'? Maybe once I've figured out where 
> that comes from the logic makes more sense.
> 
The magic number '15' is 1440/96(dpi). And sure enough the magic number changes 
to '12' on 120dpi.

If I read MSDN correctly 
(http://msdn.microsoft.com/en-us/library/bb787911(VS.85).aspx) the rc and rcPage 
area should be in twips not pixels.

If I change the code to do exactly that (multiply by 1440/dpi) the tests succeed 
on all resolutions I've checked.

Another thing I found but I'm not sure it's relevant here is that fr.rc.bottom 
is changed after a EM_FORMATRANGE message.

-- 
Cheers,

Paul.