May 2014 - Wine-Devel - list.winehq.org

Re: msvcrt: Don't crash on NULL struct _tm in asctime
by Marvin May 12, 2014

May 12, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6983 Your paranoid android. === w2000pro (32 bit time) === time: unhandled exception c0000005 at 78028AD5 === wxppro (32 bit time) === time: unhandled exception c0000005 at 77C4A8B6

1 0

Re: [PATCH 2/2] oleacc: Add GetStateText implementation (try2)
by Nikolay Sivov May 12, 2014

May 12, 2014

> + state_id = IDS_STATE_MIN; > + while(dwStateBit) { > + state_id++; > + dwStateBit /= 2; > + } It looks like ffs() could be used to do that. Actually it would be better to find a way to connect those resource ids with actual STATE_SYSTEM_* symbols, not sure if it's possible to do cleanly. Also I don't like formatting, especially prefixed names, but that's probably considered to be submitter choice.

2 3

Re: user32: Track the number of GL surfaces for a window rather than the pixel format.
by Alexandre Julliard May 12, 2014

May 12, 2014

Ken Thomases <ken(a)codeweavers.com> writes: > The specific pixel format was never used. It was effectively just a flag > indicating if the window had a GL surface. This generalizes it from a flag > to a count, to allow for multiple GL surfaces. I'm not convinced that the concept of multiple surfaces makes sense, except maybe as a driver implementation detail. -- Alexandre Julliard julliard(a)winehq.org

4 15

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Dmitry Timoshkov May 12, 2014

May 12, 2014

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > + memset(&efnd, 0, sizeof(efnd)); > + strcpy(lf.lfFaceName, "MS Shell Dlg"); > + ret = EnumFontFamiliesExA(hdc, &lf, enum_fullname_data_proc, (LPARAM)&efnd, 0); > + ok(ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp((char*)efnd.elf[0].elfLogFont.lfFaceName, "MS Shell Dlg"); > + todo_wine ok(!ret, "expected MS Shell Dlg got %s\n", efnd.elf[0].elfLogFont.lfFaceName); > + ret = strcmp((char*)efnd.elf[0].elfFullName, "MS Shell Dlg"); > + ok(ret, "did not expect MS Shell Dlg\n"); Please add the tests for other font enumeration APIs (the may behave differently), and the tests with NULL face name (according to my tests in that case MS Shell Dlg won't be enumerated). Since that would clutter existing tests I'd suggest to move the new one into separate body and name it appropriately. -- Dmitry.

2 1

Re: comctl32/listview: Fix custom draw stage sequence
by Marvin May 12, 2014

May 12, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6975 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wxppro (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5115: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5120: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: [PATCH] gdi32: Add MS Shell Dlg tests
by Marvin May 12, 2014

May 12, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6979 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Federal circuit reverses ruling on Java APIs
by Alex M May 11, 2014

May 11, 2014

https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-fede… This is very worrying news. What are the implications for WINE if this manages to go through entirely? -- Malo periculosam libertatem quam quietum servitium.

4 3

Testbot
by Mikael Ståldal May 11, 2014

May 11, 2014

I see in the patch list http://source.winehq.org/patches/ that the testbot run on some patches, but not all. What determine if it run or not?

2 4

Re: ced401: add initial support
by André Hentschel May 9, 2014

May 9, 2014

Am 09.05.2014 14:42, schrieb Alois Schlögl: > The attached patch includes the stubs for the ced1401 driver dll. > > This is a starting point to support ced1401/spike2/signal software. > > It's my first patch submission to wine - feedback welcome. > I also doubt that this wrapper get's included as it's too special. But when you finished your work, could you please share a link to github or somewhere with me. (I'm collecting wrappers for Wine on my website: http://dawncrow.de/wine/index.html )

1 0

Re: gdi32: Report unsubstituted font face names. (try 5)
by Alexandre Julliard May 9, 2014

May 9, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I kept the full name tests, but now they make sure that the full name > is a SUBSTITUTED font name. It breaks the gdiplus tests: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:759: Test failed: wrong face name MS Shell Dlg font.c:770: Test failed: wrong face name MS Shell Dlg make: *** [font.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Fix InternetGetConnectedStateEx[A|W] (try 2, resend)
by Alexandre Julliard May 9, 2014

May 9, 2014

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -1241,8 +1250,9 @@ BOOL WINAPI InternetGetConnectedStateExA(LPDWORD lpdwStatus, LPSTR lpszConnectio > dwReserved); > if (rc && lpwszConnectionName) > { > - WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > - dwNameLen, NULL, NULL); > + if (WideCharToMultiByte(CP_ACP,0,lpwszConnectionName,-1,lpszConnectionName, > + dwNameLen, NULL, NULL) == 0) > + *lpszConnectionName = '\0'; That doesn't seem to match what the W function does, and I don't see any tests for that case. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: comctl32: Tooltip AddTool needs to support TTTOOLINFOW_V3_SIZE
by Alexandre Julliard May 9, 2014

May 9, 2014

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -1037,8 +1037,9 @@ TOOLTIPS_AddToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > infoPtr->hwndSelf, ti->hwnd, ti->uId, > (ti->uFlags & TTF_IDISHWND) ? " TTF_IDISHWND" : ""); > > - if (ti->cbSize >= TTTOOLINFOW_V2_SIZE && !ti->lpszText && isW) > - return FALSE; > + if ((ti->cbSize > TTTOOLINFOW_V2_SIZE && > + ti->cbSize != TTTOOLINFOW_V3_SIZE) && !ti->lpszText && isW) > + return FALSE; This doesn't make any sense. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ced401: add initial support
by Nikolay Sivov May 9, 2014

May 9, 2014

What does it have to do with Wine? Is it really some dll that Windows provides? > +/* > + * Use1432.dll > + * > + * Generated from/home/schloegl/.wine-1.7.17/drive_c/1401/utils/Use1432.dll by winedump. > + * > + * DO NOT SUBMIT GENERATED DLLS FOR INCLUSION INTO WINE! > + * > + */

3 3

Re: [PATCH 1/2] mshtml: Added IDispatchEx support to HTMLStyleSheetRulesCollection object.
by Marvin May 9, 2014

May 9, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6935 Your paranoid android. === w2000pro (32 bit dom) === dom.c:6245: Test failed: unexpected guid {3050f2e5-98b5-11cf-bb82-00aa00bdce0b}

1 0

Re: [PATCH 2/2] oleacc: Add Client_accHitTest implementation
by Piotr Caban May 9, 2014

May 9, 2014

On 05/09/14 10:54, Piotr Caban wrote: > --- > dlls/oleacc/client.c | 22 +++++++++++++++++++-- > dlls/oleacc/tests/main.c | 50 > +++++++++++++++++++++++++++++++++++++++++++++--- > 2 files changed, 67 insertions(+), 5 deletions(-) > This patch is wrong. I'll send a fixed version.

1 0

Can I play with the Notepad code?
by Susan Cragin May 9, 2014

May 9, 2014

Hi. I want to make Notepad remember which encoding scheme you last used. Right now it defaults to ANSI Latin when opening a new file, and saves it that way too, unless you are careful. And, if I can, I want to make the following changes: (1) use ALT-Windows-key to move lines up and down. (2) use CTL-Windows-key to move paragraphs up and down. Lines and paragraphs are defined as follows: So this is a line of text. And this is line 2 of text. And this is line three of text. But they are all part of Paragraph 1. Paragraph 2 starts after a blank line is inserted. Sort of like Emacs. I've found the source code. I'm looking at where to put things. I can do it in lisp, and I've got help for C. http://source.winehq.org/source/programs/notepad/ Can I can I can I? It's going to take me a while, so don't hold your collective breath. Susan

3 2

Re: ws2_32: Return the correct error if SO_REUSEADDR is set in bind error
by Marvin May 9, 2014

May 9, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6923 Your paranoid android. === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFFD49CD9

1 0

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 4)
by Marvin May 8, 2014

May 8, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6914 Your paranoid android. === w2000pro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === wxppro (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma Bold === w2008s64 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w8 (32 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma === w2008s64 (64 bit font) === font.c:4756: Test failed: expected MS Shell Dlg got Microsoft Sans Serif font.c:4765: Test failed: expected MS Shell Dlg 2 got Tahoma

3 2

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alex Henrie May 8, 2014

May 8, 2014

2014-05-08 2:28 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Please add tests for the full name too. I thought I did: @@ -6031,6 +6042,8 @@ START_TEST(font) * I'd like to avoid them in this test. */ test_EnumFontFamilies("Arial Black", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg", ANSI_CHARSET); + test_EnumFontFamilies("MS Shell Dlg 2", ANSI_CHARSET); test_EnumFontFamilies("Symbol", SYMBOL_CHARSET); if (is_truetype_font_installed("Arial Black") && (is_truetype_font_installed("Symbol") || is_truetype_font_installed("Wingdings"))) Is there a better way to test the full name? -Alex

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Ken Thomases May 8, 2014

May 8, 2014

On May 6, 2014, at 9:28 AM, Andrew Eikum wrote: > +static HMENU MENU_GetHandle(POPUPMENU *menu) > +{ > + return menu ? menu->obj.handle : NULL; > +} Now that DestroyMenu() really destroys the handle, any use of the handle and thus this function has to be examined very carefully. The menu pointer may be valid and menu->obj.handle may have a value, but that value may no longer be a valid handle. > menuchar = SendMessageW( hwndOwner, WM_MENUCHAR, > - MAKEWPARAM( key, menu->wFlags ), (LPARAM)hmenu ); > + MAKEWPARAM( key, menu->wFlags ), (LPARAM)MENU_GetHandle(menu) ); So, here we're passing the menu handle in the WM_MENUCHAR message. If the menu has been destroyed, that's an invalid handle. We probably need tests to verify that that's what happens on Windows. That is, maybe it passes NULL. Or maybe the handle is still valid somehow. (The existing destroyed-submenu tests suggest that the handle isn't valid anymore, but maybe magic happens.) > - drawItem.hwndItem = (HWND)hmenu; > + drawItem.hwndItem = (HWND)MENU_GetHandle(menu); > - dis.hwndItem = (HWND)hmenu; > + dis.hwndItem = (HWND)MENU_GetHandle(menu); Same for the WM_DRAWITEM message. > @@ -1845,7 +1840,7 @@ static BOOL MENU_InitPopup( HWND hwndOwner, HMENU hmenu, UINT flags ) > menu->hWnd = CreateWindowExW( ex_style, (LPCWSTR)POPUPMENU_CLASS_ATOM, NULL, > WS_POPUP, 0, 0, 0, 0, > hwndOwner, 0, (HINSTANCE)GetWindowLongPtrW(hwndOwner, GWLP_HINSTANCE), > - (LPVOID)hmenu ); > + (LPVOID)MENU_GetHandle(menu) ); This one is interesting. This is a value that's just forwarded through to the WM_CREATE message via the lpCreateParams field of the CREATESTRUCTW pointed to by the lparam. It's then stored in the window extra space using SetWindowLongPtrW(). It's then looked up elsewhere in the window proc. Some cases in the window proc try to use the handle, which will fail if it's been destroyed. I think you can pass the menu pointer here instead of the menu handle. Likewise, I think you can store the menu pointer into the window extra space. You'd have to change the size of the extra space defined in the MENU_builtin_class struct. And you'd need to change all uses of Set/GetWindowLongPtrW() on the menu's window with 0 index. MENU_DrawPopupMenu() would need to be changed to take a menu pointer instead of a handle. A couple of those uses are for the MM_SETMENUHANDLE and MM_GETMENUHANDLE messages. I believe those are obsolete Wine-internal messages. They can probably be completely removed. For the MN_GETHMENU message, you can return MENU_GetHandle(GetWindowLongPtrW(hwnd, 0)), although, again, it would be good to test what Windows does for a destroyed-but-still-alive menu. The stored value is also used in GetMenuBarInfo(), so you'd want to rework that. > @@ -2023,18 +2018,17 @@ static void MENU_SelectItem( HWND hwndOwner, HMENU hmenu, UINT wIndex, > SendMessageW( hwndOwner, WM_MENUSELECT, MAKEWPARAM(pos, > ip->fType | ip->fState | > - (ptm->wFlags & MF_SYSMENU)), (LPARAM)topmenu); > + (topmenu->wFlags & MF_SYSMENU)), (LPARAM)topmenu); Here you missed a case. The lparam should be the menu handle, but topmenu is now a menu pointer. It might be good to also review all remaining uses of MENU_GetMenu(). Again, I think it should be possible to confine uses of menu handles just to the interfacing with client code. So, uses of MENU_GetMenu() at other places indicates that you're relying on the handle being valid. For example, the call to GetSubMenu() in MENU_FindItemByKey() or the calls to EnableMenuItem() in MENU_InitSysMenuPopup(). Unfortunately, that may involve creating a lot of helper functions. I didn't review further than this. Sorry that my suggestions are creating so much work. If you haven't already done so, you should probably get input from others (i.e. Alexandre) to see if my suggestions make sense. -Ken

2 3

Re: [PATCH] gdi32: Report unsubstituted font face names. (try 3)
by Alexandre Julliard May 8, 2014

May 8, 2014

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4741,6 +4741,17 @@ static void test_EnumFonts(void) > ret = EnumFontFamiliesA(hdc, NULL, enum_all_fonts_proc, (LPARAM)&lf); > ok(ret, "font Arial Italic Bold should not be enumerated\n"); > > + /* MS Shell Dlg and MS Shell Dlg 2 must exist */ > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg"); > + ok(!ret, "expected MS Shell Dlg got %s\n", lf.lfFaceName); > + > + ret = EnumFontFamiliesA(hdc, "MS Shell Dlg 2", enum_fonts_proc, (LPARAM)&lf); > + ok(!ret, "font MS Shell Dlg 2 is not enumerated\n"); > + ret = strcmp(lf.lfFaceName, "MS Shell Dlg 2"); > + ok(!ret, "expected MS Shell Dlg 2 got %s\n", lf.lfFaceName); Please add tests for the full name too. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] comctl32/tests: Fix propsheet and listview tests which depend on being in foreground.
by Bernhard Übelacker May 7, 2014

May 7, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, the comctl32:propsheet and comctl32:listview are regularly failing on the Windows testbots. This is visible in these test runs with an "empty" patch to these tests: https://testbot.winehq.org/JobDetails.pl?Key=6828 https://testbot.winehq.org/JobDetails.pl?Key=6829 This is because windows forbids them to get into foreground. This patch is working around this by simulating an ALT key press and then calling SetForegroundWindow. These are the results with an earlier revision of this patch: https://testbot.winehq.org/JobDetails.pl?Key=6832 https://testbot.winehq.org/JobDetails.pl?Key=6833 Kind regards, Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaVcbAAoJEOlvol+DpkHmDb8IAKD/G0FWgDP8v44SpfqhHY2W 0g8fCzJY6/GhjweV6Mybwqx/YmeBwmc8qvRuHshDUm8WWZbI6yH14LEGz5GwbccI XH/kJgiqqaJH8AiCQM6chF+JBAz3URf9SsAsuDKBjNmpHSMkPAhC/JXecI43GMyX E2AoggKh6DXtEq3yOnGJIRSMAhGPJGYP1Vny5+rq6+rvg2DpNdGI11Xk4oCVgJvc cYCk3yVNKquv4JW8vg80ZJboglDff7omTBLJdF5Nkk5xSGY4iV7amp9CChEJN33N lsohSyvIXeDWegeCWaXGNGhTPXwuTb56tQG22uR7IxJscT8/cXsDQ4jYvuTHoXM= =hTJp -----END PGP SIGNATURE-----

2 2

Re: shell32: Use SW_HIDE with ShellExecuteA in tests.
by Marvin May 7, 2014

May 7, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6894 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2443: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1220: Test failed: expected 1 args, got 4 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1541: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1573: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2111: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF45.tmp\wtDFC3.tmp" Exec") succeeded: rc=42

1 0

Re: [PATCH 1/2] include: Added atlcom.h
by Vincent Povirk May 7, 2014

May 7, 2014

I think you should add this new header to include/Makefile.in.

2 1

Re: [PATCH] user32: Don't depend on HMENU being valid for popup menus
by Vincent Povirk May 7, 2014

May 7, 2014

if (menu->FocusedItem != NO_SELECTED_ITEM) { + ERR("focused: %u, nitms: 0x%x\n", + menu->FocusedItem, + menu->nItems); menu->items[menu->FocusedItem].fState &= ~(MF_HILITE|MF_MOUSESELECT); menu->FocusedItem = NO_SELECTED_ITEM; } Is this stray debugging code or a real error condition? - * Return the handle of the submenu, or hmenu if no submenu to display. + * Return the handle of the submenu, or menu if no submenu to display. Still slightly inaccurate as the returned submenu is no longer a handle. @@ -4787,24 +4770,29 @@ static BOOL SetMenuItemInfo_common(MENUITEM * menu, menu->wID = lpmii->wID; if (lpmii->fMask & MIIM_SUBMENU) { - menu->hSubMenu = lpmii->hSubMenu; - if (menu->hSubMenu) { - POPUPMENU *subMenu = MENU_GetMenu(menu->hSubMenu); - if (subMenu) { - if( MENU_depth( subMenu, 0) > MAXMENUDEPTH) { + if(menu->fType & MF_POPUP){ + if(menu->submenu) + InterlockedDecrement(&menu->submenu->refcount); + } How do we know this isn't the last reference? I'm not sure this frees submenus correctly. If I create a popup menu and add a submenu to it, that submenu has two references (one because it has an HMENU and one because it is a submenu). DestroyMenu should recursively destroy submenus. So it seems to me, destroying a menu needs to destroy the handles to submenus (if they have one) and release its references to them.

2 1