Re: comctl32/tests: Added first TaskDialog test.
On Sun, Jun 12, 2011 at 9:32 AM, Patrick Gauthier wrote: > This patch relies on my previous patch that sets the ordinals right. > > Given that these functions would only be available on COMCTL32 v6.x, > Vista+, I added a win_skip if the APIs are not present. However unless > the test EXE has a manifest on Windows I think it might never find them. > Hey, Patrick. Look at tests/listview.c for example to see how I load version 6 with activation context API. It doesn't work for some reason for XP SP3 (a glitch I don't understand), but works fine for everything else. All you need is v6util.h. Without version 6 activation this test is useless to run in auto mode, it will never find TaskDialog entry points. Thanks for your interest.
About building test suite for Windows
Hi, As I was writing my task dialog test I ran into a few problems trying to test on Windows... First, I tried building it using make crosstest but I keep getting this: $ gmake crosstest crosstest is not supported (mingw not installed?) gmake: *** [crosstest] Error 1 I am on FreeBSD 8.2-RELEASE (i386), I have the following mingw ports installed (using pkg_add) mingw32-bin-msvcrt-r3.18.a3.14 mingw32-binutils-2.21,1 mingw32-directx-20020518 mingw32-gcc-4.5.0_1,1 mingw32-pdcurses-3.4 mingw32-pthreads-2.8.0 I deleted config.status (there was no config.cache) and re-ran ./configure, it fails to detect mingw, so I gave up on that. I then tried building them on Windows directly instead (using Visual Studio 2008 with Windows SDK v7.0) as describred there: http://www.winehq.org/docs/winedev-guide/testing-windows However, trying to compile comctl32_tests using the WINE headers would complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other hand, compiling with the MSVC headers would complain about TVIS_FOCUSED not being present. According to this: http://support.microsoft.com/kb/166471 it has been deprecated and removed from MS headers a long time ago. Eventually I would like to just be able to make crosstest so that I can stay in one dev environments and not two, so if anybody could help me about why isn't mingw32 detected, I would like it. Thanks. - Patrick
Re: Ge (Greg) van Geldorp
On 6/11/11 6:18 AM, Scott Ritchie wrote: In tragic irony, I'm dealing with a father dying of very late stage cancer at the moment, so forgive me if I'm slow for a bit. First, how sad to read this about your father. Hopefully, he is receiving the best of care and is in little or no pain. Second, thank you for taking over the testbot (or at least appearing to do so, my apologies if this is incorrect.) It will take more than one person to fill Ge's shoes for providing the testbot system and for his actions to get our efforts recognized in the Virtual community. Very respectfully, James McKenzie
Re: Ge (Greg) van Geldorp
Hi, I would like to give my condolences to the family and his many friends. Tom 2011/6/11 Paul Vriens > Hi, > > The sad news reached me two days ago that Ge (Greg) van Geldorp passed > away. Please find below the mail from his brother. > > I've briefly talked to Jeremy and Alexandre about this loss and the idea > came up to have something on the winehq frontpage for a while. Jeremey also > mentioned to mark Greg's life and contributions to Wine at Wineconf this > year. Alexandre mentioned potentially hosting the winetestbot at codeweavers > in the future. Both the frontpage remembrance and the potential hosting > somewhere else has been discussed by me and Arno and will not be an issue. > > Cheers, > > Paul. > > > > Hi all, > > > > My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. I’m > very sorry that I have to inform you that Greg has passed away almost 3 > weeks ago. 2 Months earlier he was diagnosed with cancer in a very > aggressive form. > > > > I know he made his contribution to the Wine project. And that one of them > is the WineTestBot. His passing away went so fast that he didn’t have the > time to inform me all about it. What he did ask me is to make sure that the > server where the WineTestBot is running on will be hosted for at least 2 > more years. So we will take care of that. But I don’t know if anyone took > over the administration off the server. > > > > If anyone took over the administration from Greg could you please contact > me at erven.van.geldorp at gmail.com > > > > Kind regards, > > > > Arno van Geldorp > > > >
Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
Hello, 2011/6/11 BACRI Stephane : > Hi all. > Was there something incorrect in this patch I submitted in may, or in the > way I submitted it? > Perhaps should I have mentioned that it had been tested in several ways with > hardware & software. joerg commented on this 11th may: http://wine.1045685.n5.nabble.com/winealsa-drv-midi-c-Adds-the-midi-MTC-Quarter-Frame-messages-support-td4387453.html ~Maarten
Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)
On 11 June 2011 17:26, Marcus Meissner wrote: > if (state <= HIGHEST_TRANSFORMSTATE) > + { > mat = &device->updateStateBlock->state.transforms[state]; > + } > else > + { > FIXME("Unhandled transform state %#x.\n", state); > + return WINED3D_OK; > + } > This works, so I'm not too bothered either way, but I think the following looks slightly nicer: if (state > HIGHEST_TRANSFORMSTATE) { WARN("Invalid transform state %#x.\n", state); return WINED3D_OK; } mat = &device->updateStateBlock->state.transforms[state]; multiply_matrix(&temp, mat, matrix);
Re: Ge (Greg) van Geldorp
On 06/10/2011 01:01 PM, Paul Vriens wrote: > My name is Arno van Geldorp. I’m the brother of Gé (Greg) van Geldorp. > I’m very sorry that I have to inform you that Greg has passed away > almost 3 weeks ago. 2 Months earlier he was diagnosed with cancer in a > very aggressive form. > > > > I know he made his contribution to the Wine project. And that one of > them is the WineTestBot. His passing away went so fast that he didn’t > have the time to inform me all about it. What he did ask me is to make > sure that the server where the WineTestBot is running on will be hosted > for at least 2 more years. So we will take care of that. But I don’t > know if anyone took over the administration off the server. I have the passwords, and I gave them to Maarten as well. We'll talk about this when I can. In tragic irony, I'm dealing with a father dying of very late stage cancer at the moment, so forgive me if I'm slow for a bit. Thanks, Scott Ritchie
Re: TaskDialog implementation
Am 11.06.2011 09:45, schrieb Hans Leidekker: > On Fri, 2011-06-10 at 23:29 -0500, Vincent Povirk wrote: >> Well, I think you may be right that changing it to E_NOTIMPL at this >> point would break something and might be a bad idea. Sadly, Hans >> didn't say what the stub was originally for. Hopefully, we'll soon >> have a working implementation and it won't matter. ;) > > I added it for the Internet Explorer 9 installer but it has been > broken already when someone changed it to return IDYES instead of > IDOK in pnButton. I don't know which app that was for. > Yes IE9 installer matters here and it's actually broken, so a working GUI implementation would be awesome. Am 11.06.2011 01:37, schrieb Patrick Gauthier: > What I seem to get from your input and reading SubmittingPatches, is > basically "tests, tests, tests". I thought a while about "how does one > automate tests on GUI stuff?" and "how can I ensure that my dialog > renders right in a test, short of using a flaky thing like GetPixel()?", > etc. > > Then it came to me. What I will do is first change the implementation to > return E_NOTIMPL as Vincent Povirk suggested. Then I will start writing > tests that show use TaskDialogIndirect and sends a bunch of TDM_xxx > messages and tests that the callback procedures receives all the right > TDN_xxx notifications, at least. It won't be able to test that the > dialog _displays_ right, but at least that it functions right from an > API point of view. As long as I can close the dialog when done testing, > the tests should not require any kind of user interaction. Right, you can send messages and maybe also send keys but not GetPixel(). One interessting part is the returnvalue for various "bad" inputs like NULL for pointers and so on. You can have a look at the user32 tests, maybe the file dlls/user32/tests/dialog.c is good to get inspired for some special things. > Thing is, however, that I already got the full implementation written > "as a block", short of "replaying my coding process", I don't see how I > could efficiently do that. I could always make different patches for > different parts, like, dialog creation, then layout, then message > handling, etc, but you would not get a working TaskDialog until the last > patch was integrated. It should work as your existing implementation after all patches are committed. Between the patches only the rules apply that Vincent just sent on that topic. In short it means if you send e.g. 10 patches and progressbar patch is patch 6, then Wine shouldn't suffer after patch 1-5 applied like compilation errors or at runtime crashes and the tests should still apply. But of course at this point a request to TaskDialog to display a progressbar won't show one, so it maybe should return E_NOTIMPL or something and print a FIXME. -- Best Regards, André Hentschel
Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
Hi all. Was there something incorrect in this patch I submitted in may, or in the way I submitted it? Perhaps should I have mentioned that it had been tested in several ways with hardware & software. Regards. Stéphane.
Re: [PATCH 1/4] Check for null pointers before strcmp. (LLVM/Clang)
On Sat, Jun 11, 2011 at 01:15:42AM +0300, Lauri Kentt? wrote: > > >Second, the ok output message also dereferences pdst by printing it > > That's not true. "%s" formats null pointers as "(null)" instead of > dereferencing anything. That isn't a requirement of the C language, there are many implemenations which will fault. David -- David Laight: da...@l8s.co.uk
Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)
On Saturday 11 June 2011 11:17:58 Marcus Meissner wrote: > else > +{ > FIXME("Unhandled transform state %#x.\n", state); > +return WINED3DERR_INVALIDCALL; > +} Please return WINED3D_OK, like wined3d_device_set_sampler_state and other setters. Native doesn't do this kind of consistency checking, so apps will get D3D_OK returned if they pass an out of range state(unless the setter segfaults). signature.asc Description: This is a digitally signed message part.
Re: [PATCH] user32: initialize all of msg (Coverity)
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 http://testbot.winehq.org/JobDetails.pl?Key=11625 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout
Re: TaskDialog implementation
On Fri, 2011-06-10 at 23:29 -0500, Vincent Povirk wrote: > Well, I think you may be right that changing it to E_NOTIMPL at this > point would break something and might be a bad idea. Sadly, Hans > didn't say what the stub was originally for. Hopefully, we'll soon > have a working implementation and it won't matter. ;) I added it for the Internet Explorer 9 installer but it has been broken already when someone changed it to return IDYES instead of IDOK in pnButton. I don't know which app that was for.