Re: USER32: Sysparams unit tests fixes and additions

[Paul Vriens]

On Tue, 2005-03-01 at 05:53, [e-mail] wrote:
> Changelog:
> - Created SPI_{GET,SET}KEYBOARDPREF and SPI_{GET,SET}SCREENREADER unit tests
> - Removed a trace that shouldn't have been there
> - Add return checking to SPI_{GET,SET}WHEELSCROLLLINES and
>
> SPI_{GET,SET}MENUSHOWDELAY unit tests so they no longer run on Windows 95 
> where they aren't supported
> - Changed minimum hovertime in SPI_{GET,SET}MOUSEHOVERTIME to 10 as Windows XP
>
> defaults to 10 any value below that

Hi,

the extra trace was my doing :-(. I've added this and after that I
realized that SPI_{GET|SET} doesn't clean the LastError after a correct
call. That's why I think it's necessary to do a SetLastError(0) before
every check of GetLastError.

That's the reason I had these failures on win98 and
SPI_GETICONTITLEWRAP. The Error was still set by one of the previous
called functions (I think a ..W call, the ..A call was fine).

That still leaves us with the questions, whether it would be good to
check for ERROR_CALL_NOT_IMPLEMENTED after each call?

Cheers,

Paul Vriens.

USER32: Sysparams unit tests fixes and additions

[Justin Chevrier]

Paul Vriens wrote:
> On Tue, 2005-03-01 at 05:53, [e-mail] wrote:
> > Changelog:
> > - Created SPI_{GET,SET}KEYBOARDPREF and SPI_{GET,SET}SCREENREADER unit tests
> > - Removed a trace that shouldn't have been there
> > - Add return checking to SPI_{GET,SET}WHEELSCROLLLINES and
> >
> > SPI_{GET,SET}MENUSHOWDELAY unit tests so they no longer run on Windows 95 
> > where they aren't supported
> > - Changed minimum hovertime in SPI_{GET,SET}MOUSEHOVERTIME to 10 as Windows XP
> >
> > defaults to 10 any value below that
>
> Hi,
>
> the extra trace was my doing :-(. I've added this and after that I
> realized that SPI_{GET|SET} doesn't clean the LastError after a correct
> call. That's why I think it's necessary to do a SetLastError(0) before
> every check of GetLastError.
>
> That's the reason I had these failures on win98 and
> SPI_GETICONTITLEWRAP. The Error was still set by one of the previous
> called functions (I think a ..W call, the ..A call was fine).
>
> That still leaves us with the questions, whether it would be good to
> check for ERROR_CALL_NOT_IMPLEMENTED after each call?
>
> Cheers,
>
> Paul Vriens.

I think it's a good idea really. Who knows what kind of odd configs can 
get Windows to disable certain system
parameters. I'm looking into why some NT4 systems in the conformance 
tests at test.winehq.org are returning
with an error of 5 (ACCESS_DENIED). We should give a more meaningful 
output to the user about needing
elevated privileges or whatnot (have looked into it yet) and bailing on 
the test instead of failing outright. I
hope to look into getting both issues covered after I do some tests on 
an NT4 box.

Justin