Hi all
My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out.
I've also added more bugfixes to the patch: Now WINE supports the (very rare) case where a menu is assigned to multiple windows. To test this, I'll attach a program which displays two windows using the same menu. The windows are from different window classes in order to test if WINE sends the ownerdraw messages to the correct window.
Please test this patch and tell me if I should send it to wine-patches.
Regards
Michael
Index: dlls/user/menu.c =================================================================== RCS file: /home/wine/wine/dlls/user/menu.c,v retrieving revision 1.1 diff -u -r1.1 menu.c --- dlls/user/menu.c 31 Aug 2004 01:10:08 -0000 1.1 +++ dlls/user/menu.c 7 Sep 2004 21:17:43 -0000 @@ -83,15 +83,14 @@ HWND hWnd; /* Window containing the menu */ MENUITEM *items; /* Array of menu items */ UINT FocusedItem; /* Currently focused item */ - HWND hwndOwner; /* window receiving the messages for ownerdraw */ BOOL bTimeToHide; /* Request hiding when receiving a second click in the top-level menu item */ /* ------------ MENUINFO members ------ */ - DWORD dwStyle; /* Extended mennu style */ - UINT cyMax; /* max hight of the whole menu, 0 is screen hight */ - HBRUSH hbrBack; /* brush for menu background */ + DWORD dwStyle; /* Extended menu style */ + UINT cyMax; /* Max height of the whole menu, 0 is screen height */ + HBRUSH hbrBack; /* Brush for menu background */ DWORD dwContextHelpID; - DWORD dwMenuData; /* application defined value */ - HMENU hSysMenuOwner; /* Handle to the dummy sys menu holder */ + DWORD dwMenuData; /* Application-defined value */ + HMENU hSysMenuOwner; /* Handle to the dummy system menu holder */ } POPUPMENU, *LPPOPUPMENU;
/* internal flags for menu tracking */ @@ -171,6 +170,10 @@ * be tracked at the same time. */ static HWND top_popup;
+/* Use a global owner window while tracking the menu. + * This window receives ownerdraw messages. */ +static HWND owner_window; + /* Flag set by EndMenu() to force an exit from menu tracking */ static BOOL fEndMenu = FALSE;
@@ -181,6 +184,7 @@ /********************************************************************* * menu class descriptor */ + const struct builtin_class_descr MENU_builtin_class = { POPUPMENU_CLASS_ATOMA, /* name */ @@ -1405,8 +1409,9 @@ UINT u;
for (u = menu->nItems, item = menu->items; u > 0; u--, item++) - MENU_DrawMenuItem( hwnd, hmenu, menu->hwndOwner, hdc, item, - menu->Height, FALSE, ODA_DRAWENTIRE ); + + MENU_DrawMenuItem( hwnd, hmenu, owner_window, hdc, item, + menu->Height, FALSE, ODA_DRAWENTIRE );
} } else @@ -1473,10 +1478,6 @@ menu->FocusedItem = NO_SELECTED_ITEM; }
- /* store the owner for DrawItem */ - menu->hwndOwner = hwndOwner; - - MENU_PopupMenuCalcSize( menu, hwndOwner );
/* adjust popup menu pos so that it fits within the desktop */ @@ -2837,7 +2838,11 @@ */ static BOOL MENU_InitTracking(HWND hWnd, HMENU hMenu, BOOL bPopup, UINT wFlags) { + POPUPMENU* menu; + TRACE("hwnd=%p hmenu=%p\n", hWnd, hMenu); + + if (!(menu = MENU_GetMenu( hMenu ))) return FALSE;
HideCaret(0);
@@ -2849,9 +2854,8 @@
if (!(wFlags & TPM_NONOTIFY)) { - POPUPMENU *menu; SendMessageW( hWnd, WM_INITMENU, (WPARAM)hMenu, 0 ); - if ((menu = MENU_GetMenu( hMenu )) && (!menu->Height)) + if (!menu->Height) { /* app changed/recreated menu bar entries in WM_INITMENU Recalculate menu sizes else clicks will not work */ SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | @@ -2859,6 +2863,13 @@
} } + + /* Multiple windows can use the same menu. + * The menu needs to know its owner window for the + * current tracking operation. */ + owner_window = hWnd; /* for DrawItem */ + menu->hWnd = hWnd; /* for MENU_TrackMenu and many other functions */ + return TRUE; } /*********************************************************************** @@ -2970,6 +2981,8 @@ { BOOL ret = FALSE;
+ if (!IsMenu( hMenu )) return FALSE; + MENU_InitTracking(hWnd, hMenu, TRUE, wFlags);
/* Send WM_INITMENUPOPUP message only if TPM_NONOTIFY flag is not specified */ @@ -3554,6 +3567,36 @@ DestroyWindow( lppop->hWnd ); lppop->hWnd = 0; } + + /* Check if the menu is still in use by a window + * (fix for bug 1486) + * + * FIXME: - A menu used by multiple windows is not removed + * from all windows, but only from the window that + * used the menu most recently + * - Update or remove this code if you move the menu + * code to WineServer + */ + if (lppop->hWnd && IsWindow(lppop->hWnd) && + GetMenu(lppop->hWnd) == hMenu) + { + /* Handle this situation in the same way as Windows 9x. + + Windows 9x destroys the menu and sets the window's + menu handle to NULL, without repainting the menu bar. + The application has to call SetMenu or DrawMenuBar + afterwards. + + FIXME: Windows 2000 returns TRUE, but doesn't destroy + the menu immediately. It waits until the menu + is not used anymore. */ + + WARN("The menu %p is still in use by window %p\n", + hMenu, lppop->hWnd); + + MENU_SetMenu(lppop->hWnd, NULL); + lppop->hWnd = 0; + }
if (lppop->items) /* recursively destroy submenus */ { @@ -3728,7 +3771,6 @@ if (!hMenu || !(lppop = MENU_GetMenu( hMenu ))) return FALSE;
lppop->Height = 0; /* Make sure we call MENU_MenuBarCalcSize */ - lppop->hwndOwner = hWnd; SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE; Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.33 diff -u -r1.33 win.c --- dlls/user/tests/win.c 26 Aug 2004 18:33:40 -0000 1.33 +++ dlls/user/tests/win.c 7 Sep 2004 21:17:45 -0000 @@ -1606,7 +1606,7 @@ { HWND child; HMENU hMenu, ret; - BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; + /* BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; */
hMenu = CreateMenu(); assert(hMenu); @@ -1619,9 +1619,12 @@ ok(DestroyMenu(hMenu), "DestroyMenu error %ld\n", GetLastError()); ok(!IsMenu(hMenu), "menu handle should be not valid after DestroyMenu\n"); ret = GetMenu(parent); - /* This test fails on Win9x */ - if (!is_win9x) - ok(ret == hMenu, "unexpected menu id %p\n", ret); + + /* FIXME: This test fails on Win9x and WINE + WINE will pass this test after the menu + code has been moved to WineServer */ + /* if (!is_win9x) + ok(ret == hMenu, "unexpected menu id %p\n", ret); */ ok(SetMenu(parent, 0), "SetMenu(0) on a top level window should not fail\n"); test_nonclient_area(parent);
#include <windows.h>
LRESULT CALLBACK WndProc1 (HWND, UINT, WPARAM, LPARAM); LRESULT CALLBACK WndProc2 (HWND, UINT, WPARAM, LPARAM);
char szAppName1[] = "MenuDemo1"; char szAppName2[] = "MenuDemo2";
#define MENU_FILE 0 #define MENU_QUIT 1
char* MenuStrings[] = {"File", "Quit"};
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { HWND hwnd1; HWND hwnd2; MSG msg; WNDCLASSEX wndclass; HMENU hMenu; HMENU hMenuPopup;
// Window 1 with WndProc1
wndclass.cbSize = sizeof (wndclass); wndclass.style = CS_HREDRAW | CS_VREDRAW; wndclass.lpfnWndProc = WndProc1; wndclass.cbClsExtra = 0; wndclass.cbWndExtra = 0; wndclass.hInstance = hInstance; wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION); wndclass.hCursor = LoadCursor(NULL, IDC_ARROW); wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH); wndclass.lpszMenuName = 0; wndclass.lpszClassName = szAppName1; wndclass.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
RegisterClassEx (&wndclass);
// Window 2 with WndProc2
wndclass.lpfnWndProc = WndProc2; wndclass.lpszClassName = szAppName2;
RegisterClassEx (&wndclass);
hMenu = CreateMenu(); hMenuPopup = CreateMenu(); AppendMenu(hMenuPopup, MF_STRING | MF_OWNERDRAW, 1, (char*) MENU_QUIT); AppendMenu(hMenu, MF_POPUP | MF_OWNERDRAW, (UINT)hMenuPopup, (char*) MENU_FILE);
hwnd1 = CreateWindow (szAppName1, "Red Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 50, 50, 300, 150, NULL, NULL, hInstance, NULL);
SetMenu(hwnd1, hMenu);
ShowWindow (hwnd1, iCmdShow); UpdateWindow (hwnd1);
hwnd2 = CreateWindow (szAppName2, "Green Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 350, 50, 300, 150, NULL, NULL, hInstance, NULL);
SetMenu(hwnd2, hMenu);
ShowWindow (hwnd2, iCmdShow); UpdateWindow (hwnd2);
while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); }
return msg.wParam; }
LRESULT CALLBACK WndProc1 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC;
switch (iMsg) { case WM_COMMAND:
switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break;
case WM_DESTROY: PostQuitMessage (0); return 0;
case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20;
return TRUE;
case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam;
savedDC = SaveDC(d->hDC);
brush = CreateSolidBrush(RGB(255, 0, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush);
SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER);
RestoreDC(d->hDC, savedDC); DeleteObject(brush); }
return DefWindowProc (hwnd, iMsg, wParam, lParam); }
// Only the brush color differs from WndProc1
LRESULT CALLBACK WndProc2 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC;
switch (iMsg) { case WM_COMMAND:
switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break;
case WM_DESTROY: PostQuitMessage (0); return 0;
case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20;
return TRUE;
case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam;
savedDC = SaveDC(d->hDC);
brush = CreateSolidBrush(RGB(0, 255, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush);
SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER);
RestoreDC(d->hDC, savedDC); DeleteObject(brush); }
return DefWindowProc (hwnd, iMsg, wParam, lParam); }
"Michael Kaufmann" hallo@michael-kaufmann.ch wrote:
My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior.
That's a very bad idea, then you need to comment out half of the test cases in Wine. The tests show *the real* behaviour, it doesn't really matter whether it's documented or not, it's known that MSDN has lots of misleading and missing information.
We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out.
Then it has a good chance that the bug will be never fixed at all. A commented out test does not differ from a not existent one, and has zero chance to be revived.
I've also added more bugfixes to the patch: Now WINE supports the (very rare) case where a menu is assigned to multiple windows. To test this, I'll attach a program which displays two windows using the same menu. The windows are from different window classes in order to test if WINE sends the ownerdraw messages to the correct window.
First I'd suggest to add another test to the set of existing menu tests. Next, a fake fix is not going to help as all previous attempts didn't, especially when a proper way to fix the problem is known.
Hi Dmitry
My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior.
That's a very bad idea, then you need to comment out half of the test cases in Wine. The tests show *the real* behaviour, it doesn't really matter whether it's documented or not, it's known that MSDN has lots of misleading and missing information.
How do you define the "real behavior" ? The behavior of Windows XP? Have you checked that Windows 2003 still passes this test? You can't be sure. There's no real behavior in this case.
We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out.
Then it has a good chance that the bug will be never fixed at all. A commented out test does not differ from a not existent one, and has zero chance to be revived.
I promise that I'll remember you to reactivate this testcase. If we don't modify DestroyMenu NOW, there's also a good chance that this bug will never be fixed. Remember, a lot of Delphi applications don't work because of this bug which is simple to fix and breaks only one single testcase. Is is really more important that WINE passes this test but fails on Delphi apps again and again? What will the users of WINE think?
To fix it properly, we have to move the menu code to WineServer. When will this happen? In a year? In two years? Never? Until then, many Delphi apps won't work. For me, this is not acceptable.
Regards
Michael
"Michael" == Michael Kaufmann hallo@michael-kaufmann.ch writes:
...
Michael> I promise that I'll remember you to reactivate this Michael> testcase. If we don't modify DestroyMenu NOW, there's also a Michael> good chance that this bug will never be fixed. Remember, a lot Michael> of Delphi applications don't work because of this bug which is Michael> simple to fix and breaks only one single testcase. Is is really Michael> more important that WINE passes this test but fails on Delphi Michael> apps again and again? What will the users of WINE think?
Micheal,
can we perhaps create a test case, that mimics the Delphi behaviour and succeeds on WinXX but fails on Wine? Then the behaviour is well documented and there is less reason to not fix it while breaking another test.
Michael> To fix it properly, we have to move the menu code to Michael> WineServer. When will this happen? In a year? In two years?
Well, if you look at Alexandre's and other codeweaver patches, a lot is happening in the area of window management and the server. But one step at a time...
Michael> Never? Until then, many Delphi apps won't work. For me, this is Michael> not acceptable.
There are other things that seem (on the first glance) " not acceptable" to me, when problems I try to pinpoint are not solved. But hey, we are an open project, and as long as nobody pays for the Delphi fix, nobody has a "right" on a fix. We have to work together to get it right...
Bye
Hi Uwe
Micheal,
can we perhaps create a test case, that mimics the Delphi behaviour and succeeds on WinXX but fails on Wine? Then the behaviour is well documented and there is less reason to not fix it while breaking another test.
Yes, that's a good idea! I've attached a test case that fails only on WINE. It doesn't really imitate Delphi's behavior, but it tests the root cause of the bug.
Delphi basically executes this code:
DestroyMenu(GetMenu(myWindow)); HMENU newMenu = CreateMenu(); /* WINE creates a menu with the same handle as the deleted menu! */ if (GetMenu(myWindow) != newMenu) { SetMenu(myWindow, newMenu); }
SetMenu never gets called on WINE! The menu is not initialized properly.
Windows 9x doesn't have this bug because it returns NULL on GetMenu(WindowWithDestroyedMenu). My patch does this too. Windows 2000 doesn't have this bug because it deletes the menu when it's not needed anymore and so doesn't create a new menu with the same handle.
Regards
Michael
Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.33 diff -u -r1.33 win.c --- dlls/user/tests/win.c 26 Aug 2004 18:33:40 -0000 1.33 +++ dlls/user/tests/win.c 8 Sep 2004 16:57:12 -0000 @@ -1605,7 +1605,7 @@ static void test_SetMenu(HWND parent) { HWND child; - HMENU hMenu, ret; + HMENU hMenu, hMenu2, ret; BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0;
hMenu = CreateMenu(); @@ -1622,6 +1622,12 @@ /* This test fails on Win9x */ if (!is_win9x) ok(ret == hMenu, "unexpected menu id %p\n", ret); + + hMenu2 = CreateMenu(); + ok(ret != hMenu2, "hMenu is deleted but still assigned to a window, CreateMenu should return a different handle"); + ok(GetMenuItemCount(ret) == -1, "hMenu is deleted and should be non-existent from the application's point of view"); + DestroyMenu(hMenu2); + ok(SetMenu(parent, 0), "SetMenu(0) on a top level window should not fail\n"); test_nonclient_area(parent);
"Michael Kaufmann" hallo@michael-kaufmann.ch wrote:
How do you define the "real behavior" ?
That's a behaviour of an existing product that could be tested and confirmed.
The behavior of Windows XP?
Including it as well.
Have you checked that Windows 2003 still passes this test?
No, I don't. For exactly that reason we have http://test.winehq.org where the results of the current test suite are posted.
You can't be sure. There's no real behavior in this case.
You are mistaken. See above.
I promise that I'll remember you to reactivate this testcase. If we don't modify DestroyMenu NOW, there's also a good chance that this bug will never be fixed. Remember, a lot of Delphi applications don't work because of this bug which is simple to fix and breaks only one single testcase. Is is really more important that WINE passes this test but fails on Delphi apps again and again? What will the users of WINE think?
Ask users. But I, as one of the developers, think that there is no any hurry in fixing any, even very critical bug. The only requirement which should be fulfilled is the correctness of the fix, nothing else. As Uwe has pointed out Wine is an open source project, and anyone welcome to work with us to fix the bugs and improve compatibility with applications. We are working towards that goal, but we have very constrained resources.
To fix it properly, we have to move the menu code to WineServer. When will this happen? In a year? In two years? Never?
I'll reword your question: "How much time will it take for an open source project to fix a bug?"
Nobody would tell you, that's a rhetorical question.
Until then, many Delphi apps won't work. For me, this is not acceptable.
For me, it's not acceptable to debate an inclusion of a not acceptable solution, there were enough explanations why it's not acceptable. You are welcome to fix it properly though.
Please don't take my words offensively, Wine is a huge project, and it's very critical to do the right things in the long run. Last time I heared, Ulrich Czekalla had a preliminary patch which has moved menu handle allocation to wineserver. I'm not sure in what state the patch is currently.
Until then, many Delphi apps won't work. For me, this is not acceptable.
For me, it's not acceptable to debate an inclusion of a not acceptable solution, there were enough explanations why it's not acceptable. You are welcome to fix it properly though.
Please don't take my words offensively, Wine is a huge project, and it's very critical to do the right things in the long run. Last time I heared, Ulrich Czekalla had a preliminary patch which has moved menu handle allocation to wineserver. I'm not sure in what state the patch is currently.
Michael,
When this sort of thing happens, it boils down to a judgement call on the part of Alexandre. He has to decide:
- What is the cost of putting in this known-incorrect fix? - What are the benefits?
Now sometimes Alexandre does allow in incorrect fixes because the cost is low and the benefit is high, or because he knows a correct fix is a long time away (maybe never). Most of our DCOM code falls into this category :)
In this case, he has to decide:
- Will this fix actually break other programs? - Will its presence make development of a correct fix more unlikely? - Are the programs it fixes popular enough to warrant it?
This is all part of figuring out the cost and the benefit. In this case, I have no idea what he will think. Alexandre does tend to be conservative - ie dropping patches he isn't sure about rather than accept them and hoping for the best.
Wine has been around for a very long time, and correctness is very important simply because if you don't consider it, nearly every fix you make will break something else and you end up going round and round in mad circles constantly moving but never getting nearer to the goal of 100% compatibility.
Even given a large and growing test suite, huge numbers of testers, a conservative maintainer and so on, Wine still suffers a high rate of regressions.
Now, I don't know anything about the menu code, so I'm not going to comment on whether the patch should go in or not. I think given how popular Delphi is for writing apps the cost of not including it is quite high but if the fix is clearly going to cause problems then we have no choice but to wait for Ulrichs menu->wineserver patch.
So hopefully you understand better the factors that go into these decisions. I know what you must be thinking, I've been there before with things like the system tray patch which is still not committed because it extends incorrect code rather than rewrites it but eventually you realise that in the long term it's for the best.
thanks -mike
On Wed, 8 Sep 2004, Dmitry Timoshkov wrote:
"Michael Kaufmann" hallo@michael-kaufmann.ch wrote:
Have you checked that Windows 2003 still passes this test?
No, I don't. For exactly that reason we have http://test.winehq.org where the results of the current test suite are posted.
And where something has got broken or like:
* Forbidden * * You don't have permission to access / on this server. * Apache/2.0.40 Server at test.winehq.org Port 80
When can we expect it to be up and running? TIA
On Wed, Sep 08, 2004 at 06:32:31PM +0200, Saulius Krasuckas wrote:
When can we expect it to be up and running?
It is up and running, we're just missing an index page. Until that gets created, use this link instead:
Unfortunately, the testing process has been broken lately, for unknown reasons.
Hi Dmitry
How do you define the "real behavior" ?
That's a behaviour of an existing product that could be tested and confirmed.
So is there an existing third-party program that depends on the "real behavior" ?
Have you checked that Windows 2003 still passes this test?
No, I don't. For exactly that reason we have http://test.winehq.org where the results of the current test suite are posted.
I get an "403 Forbidden" for this page.
Ask users. But I, as one of the developers, think that there is no any hurry in fixing any, even very critical bug. The only requirement which should be fulfilled is the correctness of the fix, nothing else. As Uwe has pointed out Wine is an open source project, and anyone welcome to work with us to fix the bugs and improve compatibility with applications. We are working towards that goal, but we have very constrained resources.
I have created a testcase that works on Windows 95 - Windows XP. ( http://www.winehq.org/hypermail/wine-devel/2004/09/0260.html )
As WINE can't pass both testcases without moving the menu code to WineServer, we now have to decide which of the two testcases we want to break.
To fix it properly, we have to move the menu code to WineServer. When will this happen? In a year? In two years? Never?
I'll reword your question: "How much time will it take for an open source project to fix a bug?"
Nobody would tell you, that's a rhetorical question.
That's right: We don't know how long it takes. And that is a part of the problem.
Until then, many Delphi apps won't work. For me, this is not acceptable.
For me, it's not acceptable to debate an inclusion of a not acceptable solution, there were enough explanations why it's not acceptable. You are welcome to fix it properly though.
The only explanation was "it breaks the testcase X", where X is a testcase that doesn't even pass on Windows 9x. I think the patch won't break any real application.
Please don't take my words offensively, Wine is a huge project, and it's very critical to do the right things in the long run. Last time I heared, Ulrich Czekalla had a preliminary patch which has moved menu handle allocation to wineserver. I'm not sure in what state the patch is currently.
It's nice that you want that the quality of the WINE code is good. But sometimes we have to compromise. Ulrich's patch was already mentioned in 2002, I don't think it will be ready soon.
Regards
Michael
Michael Kaufmann hallo@michael-kaufmann.ch writes:
The only explanation was "it breaks the testcase X", where X is a testcase that doesn't even pass on Windows 9x. I think the patch won't break any real application.
Famous last words. There have been a number of similar hacks done in the menu code already, but they all had to be removed because they broke too many things; I have no reason to believe your proposed fix will be any different. The issue is a fundamental problem with the way menus are implemented, and it can't simply be hacked around, it has to be fixed right.
Hi Alexandre
The only explanation was "it breaks the testcase X", where X is a testcase that doesn't even pass on Windows 9x. I think the patch won't break any real application.
Famous last words. There have been a number of similar hacks done in the menu code already, but they all had to be removed because they broke too many things; I have no reason to believe your proposed fix will be any different. The issue is a fundamental problem with the way menus are implemented, and it can't simply be hacked around, it has to be fixed right.
OK, so I've lost this battle and accept your decision. I have sent the non-disputed part of the patch to wine-patches. It allows a menu to be displayed in multiple windows.
Regards
Michael
-
Alexandre Julliard -
Dimitrie O. Paun -
Dmitry Timoshkov -
Michael Kaufmann -
Mike Hearn -
Saulius Krasuckas -
Uwe Bonnes