Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.
On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)online.nl> wrote:
Fixes bug 10845
Changes from previous patch: menu position calculations moved to nonclient.c.
Can you add a testcase? -- -Austin
On Thu, 7 May 2009 01:54:23 -0500, you wrote:
On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)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. Rein.
2009/5/7 Rein Klazes <wijn(a)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(a)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.
Rein.
Even if it's obvious that this is the right behavior, it's always useful to add a test, at least to prevent regressions. -- Nicolas Le Cam
2009/5/7 Rein Klazes <wijn(a)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(a)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(a)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
participants (4)
-
Austin English -
Nicolas Le Cam -
Reece Dunn -
Rein Klazes