wine-devel June 2007

wine-devel@winehq.org

101 participants
249 discussions

Re: user32:tests:msg Add test for switch mdi childs
by Dmitry Timoshkov 03 Jun '07

03 Jun '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > +/* Switch visible mdi childs */ Please use the word 'children' to avoid confusion. > + trace("Switch child window.\n"); > + > + ret = SendMessageA(mdi_client, WM_MDIACTIVATE, (WPARAM)mdi_child2, 0); > + ok(!ret, "Child not been deactivate(Switch test)\n"); active_child == mdi_child2, so it's not clear what you try to do in the test above. Besides, you don't check any subsequences of the call. Since below starts another test 'flush_sequence();' should be added before. > + ret = SendMessageA(mdi_client, WM_MDIACTIVATE, (WPARAM)mdi_child, 0); > + > + ok(!ret, "Child not activate(Switch test)\n"); > + > + ok_sequence(WmSwitchChild,"Child not switch correctly\n",TRUE); Again, you don't check any subsequences of the call. Also if you could add comments in the added message sequence what is going on, it will help a lot later figuring out how to make the test pass under Wine. Something along the following lines present in the existing sequences: /* maximize the 1st MDI child */ ... /* restore the 2nd MDI child */ ... { WM_CHILDACTIVATE, sent|defwinproc|wparam|lparam, 0, 0 }, /* in the 1st MDI child */ { WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 1st MDI child */ { WM_MDIACTIVATE, sent|defwinproc }, /* in the 1st MDI child */ ... { WM_KILLFOCUS, sent }, /* in MDI client */ { WM_IME_SETCONTEXT, sent|wparam|optional, 0 }, /* in MDI client */ etc. I understand that this is a tedious work, but it should be done. -- Dmitry.

1 0

Re: crypt32: implement CryptSIPLoad (try 5)
by Juan Lang 02 Jun '07

02 Jun '07

> I think it's worth figuring out why native does it like this. Believe me, I've been trying to. I'm only inferring that it should be loaded because using native wintrust calls CryptSIPLoad, and my implementation makes it continue on to call other functions that seem reasonable in that context. I don't know what tests I can write to show that I should not pass the DLL's function pointers directly back to the caller. That might make sense if crypt32 were to try to unload unused function pointers periodically, since the API doesn't provide an unload function - but that seems overly complicated, and I unload them at DLL unload time instead. If you have suggestions on tests I can write, I'm all ears. > Also the dll loading part of the patch is quite confusing, hopefully > doing it closer to the native way would help make it clearer. The complication comes from the fact that the registry allows one to have a separate DLL for each function in a SIP, but CryptAddSIPProvider does not. I therefore fail if the DLL names are different. This allows me to use an HMODULE as the hSIP member of a SIP_DISPATCH_INFO, rather than invent some more complicated scheme. I can add more comments to try to explain that if you like. --Juan ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front

3 2

Re: wordpad: (1/6) Split code into set_caption function
by Andrey Turkin 02 Jun '07

02 Jun '07

Alexander Nicolaysen Sørnes wrote: > This will be useful for the file saving code. > > > Regards, > > Alexander N. Sørnes > + WCHAR wszCaption[MAX_PATH]; + + if(wszNewFileName) + { + lstrcpyW(wszCaption, wszNewFileName); + lstrcatW(wszCaption, wszSeparator); + lstrcatW(wszCaption, wszAppTitle); Looks like there are possible buffer overflow

1 0

Re: How to determine if something is "debuggable" ... ?
by Tom Spear 02 Jun '07

02 Jun '07

On 6/1/07, Marc G. Fournier <scrappy(a)hub.org> wrote: Another thing you can _try_, since it looks like it messing up in msvcrt or possibly even dbghelp, is to get msvcrt.dll and dbghelp.dll from a windows install, place them in your wine's c:\windows\system32 folder (usually ~/.wine/drive_c/windows/system32), and then use winecfg to set both dll's to run (native, builtin) for that application.. See if that helps, no guarantees tho, especially since it is FreeBSD. -- Thanks Tom

1 0

GDI+: headers and one test
by Evan Stade 01 Jun '07

01 Jun '07

Changelog: *Added public GDI+ headers in include/ *Added private GDI+ headers in dlls/gdiplus *Added small implementation of GDI+ pens in dlls/gdiplus/pen.c *Added (first) GDI+ test dlls/gdiplus/Makefile.in | 3 + dlls/gdiplus/gdip_defines.h | 43 +++++++++++++++++++ dlls/gdiplus/gdip_enumerations.h | 57 ++++++++++++++++++++++++++ dlls/gdiplus/gdiplus.c | 27 ++++++++++++ dlls/gdiplus/gdiplus.spec | 8 ++-- dlls/gdiplus/gdiplus_private.h | 43 +++++++++++++++++++ dlls/gdiplus/pen.c | 84 ++++++++++++++++++++++++++++++++++++++ dlls/gdiplus/pen.h | 30 ++++++++++++++ dlls/gdiplus/tests/Makefile.in | 13 ++++++ dlls/gdiplus/tests/pen.c | 44 ++++++++++++++++++++ include/Gdiplus.h | 10 +++++ include/GdiplusEnums.h | 39 ++++++++++++++++++ include/GdiplusFlat.h | 23 ++++++++++ include/GdiplusGpStubs.h | 10 +++++ include/GdiplusInit.h | 26 ++++++++++++ include/GdiplusTypes.h | 7 +++ 16 files changed, 462 insertions(+), 5 deletions(-) -Evan Stade

6 5

Re: Added GDI+ public headers, small implementation of pen, memory and initialization, and two tests (2nd try)
by Detlef Riekenberg 01 Jun '07

01 Jun '07

On Do, 2007-05-31 at 18:02 -0700, Evan Stade wrote: > Changelog: > *Added GDI+ public headers > *Added some implementation (pen.c, gdiplus.c, memory.c) > *Added two tests (pen.c, init.c) I good indicator, that the Patch should be split in smaller Parts, is a Changelog (Subject) that is larger than a simple Line or includes an enumeration. You already use 3 Lines in the Changelog which describe the code for a minimum of 3 Patches. The usual way is one Patch for every new header to reduce the complexity of the Patch, but your headers are really small, so 2 Patches or maybe 1 single header-Patch might be ok (this depend also on the size). Thanks -- By by ... Detlef

3 2

Re: [1/2] uninstaller: add ability to scan HKCU for uninstall entries (Try 2)
by James Hawkins 01 Jun '07

01 Jun '07

On 6/1/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Here is a 2nd attempt at the last one I sent. This time the root > field is initialized, and this part of the patch is written against > current git, not against changes to my own tree. Oh and its onl;y a > 2-parter > > This will make wine's programs/uninstaller look thru not only > HKEY_LOCAL_MACHINE for uninstall entries, but also HKEY_CURRENT_USER. > + /* Loop thru HKCU first, then thru HKLM */ + for (iRootKey=0; iRootKey<sizeof(rootKeys) / sizeof(rootKeys[0]); ++iRootKey) + { + /* If there is no uninstall info in a specific root key, + * finish this run and go to the next */ + if (RegOpenKeyExW(rootKeys[iRootKey], PathUninstallW, 0, + KEY_READ, &hkeyUninst) != ERROR_SUCCESS) + continue; This whole patch would be a lot simpler if you just used one root variable: if (RegOpenKeyExW(HKCU....) == ERROR_SUCCESS) root = HKCU; else if (RegOpenKeyExW(HKLM....) == ERROR_SUCCESS) root = HKLM; else bail out Now just use root everywhere instead of having an array of just two constants, and you get rid of the index. -- James Hawkins

3 3

Re: [2/2] uninstaller: indentation cleanups (try 2)
by Tom Spear 01 Jun '07

01 Jun '07

On 6/1/07, James Hawkins <truiken(a)gmail.com> wrote: > On 6/1/07, Tom Spear <speeddymon(a)gmail.com> wrote: > > Here is part 2 of try 2. Just cleans up the indentation of my changes > > in the previous patch in this series. > > > > I think you misunderstood what Dan meant about indentation changes. > You shouldn't have a patch that doesn't properly indent if you add a > new block, and then come in with another patch to fix the indentation. That is exactly what he told me to do, and I even submitted it to him like this and he said to send it in. -- Thanks Tom

1 0

Re: [1/2] uninstaller: add ability to scan HKCU for uninstall entries (Try 2)
by James Hawkins 01 Jun '07

01 Jun '07

2 1

Re: [2/2] uninstaller: indentation cleanups (try 2)
by James Hawkins 01 Jun '07

01 Jun '07

On 6/1/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Here is part 2 of try 2. Just cleans up the indentation of my changes > in the previous patch in this series. > I think you misunderstood what Dan meant about indentation changes. You shouldn't have a patch that doesn't properly indent if you add a new block, and then come in with another patch to fix the indentation. -- James Hawkins

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2007