Re: comctl32/tests: Added first TaskDialog test.

2011-06-11 Thread Nikolay Sivov
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

2011-06-11 Thread Patrick Gauthier
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

2011-06-11 Thread James McKenzie

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

2011-06-11 Thread Tom Wickline
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.

2011-06-11 Thread Maarten Lankhorst
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)

2011-06-11 Thread Henri Verbeet
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

2011-06-11 Thread Scott Ritchie
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

2011-06-11 Thread André Hentschel
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.

2011-06-11 Thread 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.
Regards.
Stéphane.



Re: [PATCH 1/4] Check for null pointers before strcmp. (LLVM/Clang)

2011-06-11 Thread David Laight
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)

2011-06-11 Thread Stefan Dösinger
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)

2011-06-11 Thread Marvin
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

2011-06-11 Thread 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.