(resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

[Reece Dunn]

2009/5/7 Rein Klazes <wijn at online.nl>:
> On Thu, 7 May 2009 01:54:23 -0500, you wrote:
>
>>On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn at online.nl> wrote:
>>> Fixes bug 10845
>>>
>>> Changes from previous patch: menu position calculations moved to
>>> nonclient.c.
>>
>>Can you add a testcase?
>
> I don't see what you would like to test. The menu->Height == zero has
> the meaning "menusize needs recalculation" all over the code. That you
> need to have the menu size right before doing a hittest (in
> MENU_ButtonDown) is even more obvious.
>
> I expect the problem is more the form: touching sensitive nonclient
> code.

+    /* eg if the application modified the menu in the WM_INITMENU message */

Does Wine have test cases for this workflow? Also, you mention needing
it for the hit test, so can you test performing a hit test (if not,
testing that it provides sensible values is useful)?

It's not so much about touching sensitive nonclient code. It is about
being able to say something like "if a program does this, Windows
gives the menu a non-zero height, but Wine does not. This can be fixed
by ...".

The analogy I gave someone a while back is of a series of light bulbs,
switches and a black box
(http://www.mail-archive.com/wine-devel@winehq.org/msg38385.html).

You may know, for example, that a function f is generating a sine wave
(i.e. it is the sin function), but can you prove that? Tests let you
verify that behaviour. What about edge cases? Is the argument in
degrees or radians? If someone switched to an algorithm for f that
used degrees instead of radians, how would you know that f is now
broken? Or if they mistype one of the numbers, how would you know that
it is incorrect?

- Reece