October 2008 - Wine-devel - list.winehq.org

Re: user: edit.c make sure our vlc (vertical line count) is at least 1 even if there is an oversized font in the edit control
by Juan Lang 14 Oct '08

14 Oct '08

Hi Aric, Just a suggestion: @@ -1818,6 +1818,7 @@ static void EDIT_ML_InvalidateText(EDITSTATE *es, INT start, INT end) RECT rcUpdate; INT l; + if (vlc == 0) vlc = 1; if ((el < es->y_offset) || (sl > es->y_offset + vlc)) return; @@ -2235,6 +2236,7 @@ static void EDIT_PaintLine(EDITSTATE *es, HDC dc, INT line, BOOL rev) if (es->style & ES_MULTILINE) { INT vlc = (es->format_rect.bottom - es->format_rect.top) / es->line_height; + if (vlc == 0) vlc = 1; rather than having to introduce the correction in every place it's used, replacing the initialization of vlc with a call to an inline function would reduce the new lines of code (and the probability of future error.) --Juan

2 1

Fwd: WWN 353
by Zachary Goldberg 14 Oct '08

14 Oct '08

I'm forwarding (with permission) to Wine-Devel an email I got about the most recent WWN and 'Other Platforms' support. --Zach ---------- Forwarded message ---------- From: Rodney Sparapani <rsparapa(a)mcw.edu> Date: Wed, Oct 8, 2008 at 1:02 PM Subject: WWN 353 To: zgold(a)bluesata.com Hi Zachary: I really like your column. But, I was shocked to read: The biggest issue in this area is demand. There were specific BSD builds of crossover posted sometime back after much demand and Codeweavers saw very very little response. As a result not much effort has been put into the area. In short: if you're a user of Wine on BSD, Solaris or OS X and want more support speak up! I don't know why the BSD experience with CrossOver has to have any bearing on OS X and Solaris support for Wine. Let me say it clearly: WE WANT SUPPORT! I have been trying to get Wine to work on these platforms for years. Some clever hackers created the Darwine package for OS X which has Wine in a nice installer and it has been working since about 0.9.12 (so a couple of years, I guess) and improving (which may have more to do with Wine improvements). For Solaris, Wine just started working for me with 1.1.3 (there were 3 Solaris patches in that release). Now, does this mean that I want to buy CrossOver? Not necessarily. I'm not sure if there is much to be gained. I certainly would consider it, if it was better. However, from my experience with the beta on OS X, I don't really see it as helpful at all. Maybe I'm wrong. But, if I'm wrong, then that doesn't mean that I don't want my platforms supported. -- Rodney Sparapani Center for Patient Care & Outcomes Research (PCOR) Sr. Biostatistician http://www.mcw.edu/pcor 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW) WWLD?: What Would Lombardi Do? Milwaukee, WI, USA

3 2

Re: [6/6] comdlg32: Add a basic test for IShellView2_CreateViewWindow2.
by Reece Dunn 14 Oct '08

14 Oct '08

2008/10/14 Henri Verbeet <hverbeet(a)codeweavers.com>: > + IShellView2_DestroyViewWindow(shell_view2); > + ok(SUCCEEDED(hr), "DestroyViewWindow returned %#x\n", hr); You are missing a "hr = " here, otherwise the ok check is not checking the return value from DestroyViewWindow. > + IShellView2_GetCurrentInfo(shell_view2, &folder_settings); > + ok(folder_settings.ViewMode == FVM_LIST, "view mode is %d, expected %d\n", folder_settings.ViewMode, FVM_LIST); Shouldn't this also be checking the HRESULT return value from GetCurrentInfo as per the other calls? General observation: other tests in Wine explicitly check for specific hr values, is there a reason you have used the generic SUCCEEDED here instead of that approach? - Reece

3 2

Re: comdlg32: Avoid possible NULL pointer dereference (Coverity)
by Kai Blin 14 Oct '08

14 Oct '08

On Tuesday 14 October 2008 11:10:34 Kai Blin wrote: > As the code checks for ofnW->lpstrFile not being NULL, it seems like > PathFindFileNameW() and PathFindExtensionW() don't make sense on NULL > ofnW->lpstrFile. If offset and extension are not updated, it doesn't make > sense to call UpdateResults. So just abort if ofnW->lpstrFile is NULL. > > This fixes Coverity CID 108 > --- > dlls/comdlg32/filedlg31.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) Of course I forgot to switch the logic. New patch coming up. -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: [TRY 2] user32: Add test to check the MDI child switching
by Dmitry Timoshkov 14 Oct '08

14 Oct '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > + trace("creating maximized visible MDI child window 3\n"); > + mdi_child3 = CreateWindowExA(WS_EX_MDICHILD, "MDI_child_class", "MDI child", > + WS_CHILD | WS_VISIBLE | WS_MAXIMIZEBOX | WS_MAXIMIZE, > + 0, 0, CW_USEDEFAULT, CW_USEDEFAULT, > + mdi_client, 0, GetModuleHandleA(0), NULL); > + assert(mdi_child3); > + > + active_child = (HWND)SendMessageW(mdi_client, WM_MDIGETACTIVE, 0, 0); > + SendMessageW(mdi_client, WM_MDINEXT, 0, 0); > + SendMessageW(mdi_client, WM_MDINEXT, 0, 0); > + ok(active_child != (HWND)SendMessageW(mdi_client, WM_MDIGETACTIVE, 0, 0), "wrong active MDI child %p\n", > active_child); > + > + trace("destroying maximized visible MDI child window 3\n"); > + DestroyWindow(mdi_child3); What's the purpose of creating the 3rd MDI child if you don't care about values returned by WM_MDIGETACTIVE, nor about intermediate results of WM_MDINEXT? Apparently you have all MDI children handles in your hands and can use them in the tests. -- Dmitry.

1 0

Re: [6/6] comdlg32: Add a basic test for IShellView2_CreateViewWindow2.
by Henri Verbeet 14 Oct '08

14 Oct '08

2008/10/14 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de>: > But there might be Win32 applications that do care about specific return > values. So the implementation in Wine has to match native in returning > S_OK or S_FALSE (the two most common success values). What is the point > in not testing your implementation in this regard? > It is pretty rare for COM interfaces to return anything other than S_OK on success, so I doubt it will make much of a difference in practice. However, if there's really an application that depends on a specific return value on success for this interface I'll be sure to modify the test. I don't particularly care though, so if people feel strongly that the test should be using "hr == S_OK" I don't mind changing that. Note that there are plenty of other tests that use SUCCEEDED/FAILED though.

1 0

Fix to exceptions in ddtest
by Chris Ahrendt 14 Oct '08

14 Oct '08

Ok I have threaded through ddraw_test adding as I had them fail a check and a fix in dsurface.c test. The test now fails when the CreateSurface fails. Before this there were several point in the test where the return status was not checked. As I encountered them and they failed with an exception I added the failure I found at other parts which did the create surface. For some reason a 3rd and 4th surface fails on ATI. Addached you will find the proposed fix. I also found a point where the code did not skip but did a goto to the error point with the variables unitialised. Chris >From 52071bddae683a1964d64be0acbfec8d7b2c2c5e Mon Sep 17 00:00:00 2001 From: Chris Ahrendt <celticht32(a)aol.com> Date: Sun, 12 Oct 2008 21:44:21 -0400 Subject: [PATCH] Fix to ddtest to fail test if IDirectDraw_CreateSurface failed. Create Surface was failing and setting the handle to the surface to null. So when the free / release was called it threw an exception instead of failing the test. --- dlls/ddraw/tests/dsurface.c | 92 ++++++++++++++++++++++++++++++++++--------- 1 files changed, 73 insertions(+), 19 deletions(-) diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c index fc7bb88..4f545d9 100644 --- a/dlls/ddraw/tests/dsurface.c +++ b/dlls/ddraw/tests/dsurface.c @@ -198,7 +198,10 @@ static void MipMapCreationTest(void) ddsd.dwHeight = 32; rc = IDirectDraw_CreateSurface(lpDD, &ddsd, &lpDDSMipMapTest, NULL); ok(rc==DDERR_INVALIDPARAMS,"CreateSurface returned: %x\n",rc); - + if (FAILED(rc)) { + skip("failed to create surface\n"); + return; + } /* Destroy the surface. */ if( rc == DD_OK ) IDirectDrawSurface_Release(lpDDSMipMapTest); @@ -1004,7 +1007,10 @@ static void EnumTest(void) ddsd.dwHeight = 32; rc = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface, NULL); ok(rc==DD_OK,"CreateSurface returned: %x\n",rc); - + if (FAILED(rc)) { + skip("failed to create surface\n"); + return; + } memset(&ctx, 0, sizeof(ctx)); ctx.expected[0] = surface; rc = IDirectDrawSurface_GetAttachedSurface(ctx.expected[0], &ddsd.ddsCaps, &ctx.expected[1]); @@ -1055,7 +1061,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = 128; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface\n"); + return; + } /* ROOT */ num = 0; IDirectDrawSurface7_EnumAttachedSurfaces(surface1, &num, SurfaceCounter); @@ -1092,7 +1101,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = 16; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface2\n"); + return; + } hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2); ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching a 16x16 surface to a 128x128 texture root returned %08x\n", hr); hr = IDirectDrawSurface7_AddAttachedSurface(surface2, surface1); @@ -1112,7 +1124,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = 16; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface\n"); + return; + } hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2); ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching a 16x16 offscreen plain surface to a 128x128 texture root returned %08x\n", hr); hr = IDirectDrawSurface7_AddAttachedSurface(surface2, surface1); @@ -1136,7 +1151,10 @@ static void AttachmentTest7(void) ddsd.dwBackBufferCount = 2; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface\n"); + return; + } num = 0; IDirectDrawSurface7_EnumAttachedSurfaces(surface1, &num, SurfaceCounter); ok(num == 1, "Primary surface has %d surfaces attached, expected 1\n", num); @@ -1149,13 +1167,20 @@ static void AttachmentTest7(void) ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FRONTBUFFER; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL); ok(hr==DDERR_INVALIDCAPS,"CreateSurface returned: %x\n",hr); + if (FAILED(hr)) { + skip("failed to create surface1\n"); + return; + } memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_BACKBUFFER; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL); ok(hr==DDERR_INVALIDCAPS,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface2\n"); + return; + } /* Try a single primary and two offscreen plain surfaces */ memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); @@ -1163,7 +1188,10 @@ static void AttachmentTest7(void) ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface1\n"); + return; + } memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; @@ -1172,7 +1200,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface2, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface2\n"); + return; + } memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; @@ -1181,7 +1212,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface3, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface3\n"); + return; + } /* This one has a different size */ memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); @@ -1191,6 +1225,10 @@ static void AttachmentTest7(void) ddsd.dwHeight = 128; hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface4, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); + if (FAILED(hr)) { + skip("failed to create surface4\n"); + return; + } hr = IDirectDrawSurface7_AddAttachedSurface(surface1, surface2); ok(hr == DDERR_CANNOTATTACHSURFACE, "Attaching an offscreen plain surface to a front buffer returned %08x\n", hr); @@ -1334,7 +1372,7 @@ static void AttachmentTest(void) ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FRONTBUFFER; hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface1, NULL); - ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); + ok(hr==DD_OK,"CreateSurface return ed: %x\n",hr); IDirectDrawSurface_Release(surface1); /* Try a single primary and two offscreen plain surfaces */ @@ -1344,7 +1382,10 @@ static void AttachmentTest(void) ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface1\n"); + return; + } memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; @@ -1353,7 +1394,10 @@ static void AttachmentTest(void) ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface2, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface2\n"); + return; + } memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; @@ -1362,7 +1406,10 @@ static void AttachmentTest(void) ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface3, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface3\n"); + return; + } /* This one has a different size */ memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); @@ -1372,7 +1419,10 @@ static void AttachmentTest(void) ddsd.dwHeight = 128; hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &surface4, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - + if (FAILED(hr)) { + skip("failed to create surface4\n"); + return; + } hr = IDirectDrawSurface_AddAttachedSurface(surface1, surface2); ok(hr == DD_OK, "Attaching an offscreen plain surface to a front buffer returned %08x\n", hr); /* Try the reverse without detaching first */ @@ -2208,6 +2258,10 @@ static void SizeTest(void) desc.dwWidth = 128; /* Keep them set to check what happens */ ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL); ok(ret == DD_OK, "Creating a primary surface without width and height info returned %08x\n", ret); + if (FAILED(ret)) { + skip("failed to create surface\n"); + return; + } if(dsurface) { ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc); @@ -2491,9 +2545,9 @@ static void PaletteTest(void) hr = IDirectDraw_CreateSurface(lpDD, &ddsd, &lpSurf, NULL); ok(hr==DD_OK, "CreateSurface returned: %x\n",hr); if (FAILED(hr)) { - skip("failed to create surface\n"); - goto err; - } + skip("failed to create surface\n"); + return; + } hr = IDirectDrawSurface_SetPalette(lpSurf, palette); ok(hr == DDERR_INVALIDPIXELFORMAT, "CreateSurface returned: %x\n",hr); @@ -2503,7 +2557,7 @@ static void PaletteTest(void) hr = IDirectDrawSurface_GetPalette(lpSurf, &palette); ok(hr == DDERR_NOPALETTEATTACHED, "CreateSurface returned: %x\n",hr); - + err: if (lpSurf) IDirectDrawSurface_Release(lpSurf); -- 1.5.5.1

4 5

Re: Try #2
by Michael Karcher 14 Oct '08

14 Oct '08

Am Montag, den 13.10.2008, 21:05 -0400 schrieb Chris Ahrendt: > Fixed a trailing space error.. Sorry to chime in so late on this patchset. First, some general remarks: The subject of your mail will be the one-line commit message. "Try #2" is not a good choice for that. Also it does not have enough context for the casual wine-patches reader, as the message overview does not show what you patch is about. The usual convention is to take the subject of the first try, and append (or prepend) "(try 2)" to that subject. > Subject: [PATCH] Pared Down Test For ddraw test... fixes error with IDirectDraw_CreateSurface > where the test is not checking the return from the call. CreateSurface is returning a null. Another convention is to *not* use the [PATCH] tag on wine-patches, as all mails on wine-patches are patches. Use "--keep-subject" with git-format-patch to prevent it. Last, but not least, your original subject was way too long. Subjects on wine-patches usually mention the component to be patched (that is usually the directory name without dlls or programs in front) followed by a short synopsis (around 40 to 60 characters, if possible). I suggest the following subject for your next try: Subject: ddraw/tests: Catch failures of CreateSurface to prevent crash I don't remember whether you had the crash on Windows or on Wine. You could put that info also into the subject. As it is more important what the goal of your patch is than how you achieve that, something like this might also be OK: Subject: ddraw/tests: Don't crash on Windows with GeForce 4399, driver 42.23 (this subject using made-up numbers on purpose, please fit in your own, and only use this line if the crash *is* on native Windows) > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index fc7bb88..21e6b15 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -1181,7 +1181,10 @@ static void AttachmentTest7(void) > ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); > hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface3, NULL); > ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); > - > + if (FAILED(hr)) { > + skip("failed to create surface3\n"); > + return; > + } > /* This one has a different size */ > memset(&ddsd, 0, sizeof(ddsd)); > ddsd.dwSize = sizeof(ddsd); return inside a test function is bad style. You may use it for try&crash debugging, but I don't see any chance to get such a patch committed. In this case, you leak one IDirectDraw7 interface, forget to restore the cooperative level and you leak two surfaces. The "goto err:" approach is preferred if a lot of cleanup is needed (like here). You either want to make a label "err2:" before the IDirectDrawSurface7_Release(surface2) and use that label (analogous for "err3:" one line before that) or use the technique of setting released or uninitialized interface pointers to NULL and NULL-Check before calling release. Same remarks for the next 3 hunks (not quoted). > @@ -2208,6 +2220,12 @@ static void SizeTest(void) > desc.dwWidth = 128; /* Keep them set to check what happens */ > ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL); > ok(ret == DD_OK, "Creating a primary surface without width and height info returned %08x\n", ret); > + /* This should be handled but CreateSurface is failing */ > + if (FAILED(ret)) > + { > + skip("Can't create cubemap surface\n"); > + return; > + } > if(dsurface) > { > ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc); The skip message is wrong. It's not about cubemap at all. Also, this hunk is unneeded. If CreateSurface fails, dsurface is unmodified or set to NULL (or CreateSurface really badly needs fixing!). As dsurface is NULL on the call to CreateSurface, it is null if CreateSurface failed. So the condition of the if statement following the CreateSurface call is false, and no crash can happen on that NULL pointer. > @@ -2492,7 +2510,7 @@ static void PaletteTest(void) > ok(hr==DD_OK, "CreateSurface returned: %x\n",hr); > if (FAILED(hr)) { > skip("failed to create surface\n"); > - goto err; > + return; > } > > hr = IDirectDrawSurface_SetPalette(lpSurf, palette); Why do you need this hunk? You talked about usage of uninitialized variables at the target of the goto, but that's not the case. The code at err looks like this (formatting adjusted for clearness): | err: | if (lpSurf) IDirectDrawSurface_Release(lpSurf); | if (palette) IDirectDrawPalette_Release(palette); So the only two variables used here are lpSurf and palette. These two variables are initialized at the point of definition. | static void PaletteTest(void) | { | HRESULT hr; | LPDIRECTDRAWSURFACE lpSurf = NULL; | DDSURFACEDESC ddsd; | IDirectDrawPalette *palette = NULL; As they are initialized to NULL, the condition of the if statement is false if these variables were not yet initialized. So no crash possible here. Your return statement leaks palette. Regards, Michael Karcher

1 0

Re: user32: Add test to check the MDI child switching
by Dmitry Timoshkov 14 Oct '08

14 Oct '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -1674,9 +1674,78 @@ static BOOL mdi_RegisterWindowClasses(void) > cls.lpszClassName = "MDI_child_Class_2"; > if(!RegisterClassA(&cls)) return FALSE; > > + cls.lpfnWndProc = DefWindowProcW; > + cls.lpszClassName = "MDI_parent_Class_def"; > + if(!RegisterClassA(&cls)) return FALSE; > + > + cls.lpfnWndProc = DefMDIChildProcW; > + cls.lpszClassName = "MDI_child_Class_def"; > + if(!RegisterClassA(&cls)) return FALSE; The above A/W mishmash can't work. > +HWND CreateNewMDIChild(HWND hMDIClient) > +{ > + HWND hChild; > + > + hChild=CreateMDIWindow("MDI_child_Class_def", "MDI child", WS_CHILD | WS_VISIBLE, > + CW_USEDEFAULT, > + CW_USEDEFAULT, > + CW_USEDEFAULT, > + CW_USEDEFAULT, > + hMDIClient, > + GetModuleHandle(NULL), 0); > + > + if(!hChild) > + { > + ok(0,"MDI child creation failed\n"); > + } It's better to not use ok(0) statements, and do the actual check inside of ok(), in this case ok(hChild != 0). > + active = (HWND)SendMessageW(mdi_client, WM_MDIGETACTIVE, 0, 0); > + SendMessageW(mdi_client, WM_MDINEXT, 0, 0); > + SendMessageW(mdi_client, WM_MDINEXT, 0, 0); > + ok(active != (HWND)SendMessageW(mdi_client, WM_MDIGETACTIVE, 0, 0), "MDI child switching error\n"); Wouldn't it be much easier to just add 4 lines above into existing tests? -- Dmitry.

1 0

Window Screensaver in Wine
by slawek 14 Oct '08

14 Oct '08

I'm working on wrapper(app) which enabled to embed Windows window into xscreensaver-demo window and in screensaver window. In last time I have worried about project state. I was starting it three months ago, but I really programme it since two-three weeks. The most weight reason is that, I don't know how prevents mouse messages and keyboard to be received by Windows app. At early state of project I have noticed, that I can give Window app /P <desktop window id received by CreateWindowEx hwnd, nor 0> instead of /S, but I guess some Windows screen saver don't like to show preview. I don't know, what I could do in this state, so I have decided to show somebody my code. Is a good think, to public my wrapper on your site(http://www.winehq.org), but it's not good point to get it inside the Wine. It's not reason to do that if Wine don't use my app in any way. Another think is that, my app depend on xlib and xscreensaver, so it's necesary to run it on Unix like systems(Wine are in the Windows too). Somebody are interested in my app? Maybe some user need them and it can be good place to make some experiments(ex. making Window flash to work under Linux version of Firefox)? What I should to do?

3 2