June 2011 - Wine-Devel - list.winehq.org

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.

by Octavian Voicu

Ah, you're right. I did look at the make_requests script, but not close enough I guess. Sorry for the noise :D Octavian On Tue, Jun 14, 2011 at 12:16 AM, Vincent Povirk <madewokherd(a)gmail.com>wrote: > As I understand it, that's done by tools/make_requests, the effect of > which I'm not meant to include in my patches. > > On Mon, Jun 13, 2011 at 5:06 PM, Octavian Voicu > <octavian.voicu(a)gmail.com> wrote: > > Hello, > > Shouldn't you also increment SERVER_PROTOCOL_VERSION > > in include/wine/server_protocol.h? > > Octavian >

June 13, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

OK, so here is my second try at some patches. These mostly implement keyboard action mapping and there's plenty of tests to go together with it. I believe the keyboard part is pretty much done, as is SetActionMap. Of course I'm ignoring the username strings and all the device ownership part, I'll leave that for later. As before I'll leave the patches here to get some feedback before I try to commit. Cheers

June 13, 2011

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.

by Vincent Povirk

As I understand it, that's done by tools/make_requests, the effect of which I'm not meant to include in my patches. On Mon, Jun 13, 2011 at 5:06 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Hello, > Shouldn't you also increment SERVER_PROTOCOL_VERSION > in include/wine/server_protocol.h? > Octavian > > > >

June 13, 2011

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.

by Octavian Voicu

Hello, Shouldn't you also increment SERVER_PROTOCOL_VERSION in include/wine/server_protocol.h? Octavian

June 13, 2011

Re: [6/6] user32: Test that QS_HOTKEY is properly set and cleared.

by 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=11709 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 13, 2011

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.

by 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=11708 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 13, 2011

Re: [2/6] user32: Add a test to find the queue containing hotkey messages.

by 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=11707 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 13, 2011

Re: [1/6] user32: Ignore painting messages in the hotkey test using a wndproc.

by 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=11706 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Dan Kegel

2011/6/13 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: >> I'd like to see the code that implements @todo_wine@ submitted >> in the same patch as the first test that uses it. > > I'll probably send them in a patch series; should be good enough, no? Yes, that's fine.

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Frédéric Delanoy

2011/6/13 Dan Kegel <dank(a)kegel.com>: > > In the meantime, please either send a separate patch > that removes todo_space, or just leave todo_space alone for now. > >>> To avoid adding dead code, it might be nice to >>> see a test that actually uses your new keyword. >> >> I've made several mkdir tests with it, and it seems to work OK. I was >> waiting to see if this patch is commited before I submit. >> You can see it here: http://pastebin.com/tnKY4Q7S > > I'd like to see the code that implements @todo_wine@ submitted > in the same patch as the first test that uses it. > - Dan I'll probably send them in a patch series; should be good enough, no?

June 13, 2011

Re: comctl32/tests: Added first TaskDialog test.

by Nikolay Sivov

2011/6/13 André Hentschel <nerv(a)dawncrow.de>: > Am 13.06.2011 00:09, schrieb Patrick Gauthier: >> - As a result of the previous comment, there would be no point to >> generate the manifest as a file, as it could be loaded from a >> resource (CreateActCtx supports this), that would seem cleaner to me >> than generating temporary files. > > IIRC the reason for the temporary file is that we can easily turn the v6 > features on and off and AFAIK we can't if we have it "hardcoded" in a resource. This is true only for predefined resource type/ID pair. It seems CreateActCtx supports creating from any specified resource that won't necessary be used by loader automatically. > > > -- > > Best Regards, André Hentschel > > >

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Dan Kegel

2011/6/13 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > But OK an array seemed odd to me as well... it was probably done so > that sizeof(foo_cmd) could be used in memcp(expected_ptr, foo_cmd, > sizeof(foo_cmd)). Nah, looking at the code, it was so that sizeof() would not include the trailing NUL. But compare_string is just ugly. Looking at it a bunch, I suspect we should factor out @keyword@ expansion into a separate function; then we could have better error messages that gave the whole expected line. I might send a patch in like that soon. In the meantime, please either send a separate patch that removes todo_space, or just leave todo_space alone for now. >> To avoid adding dead code, it might be nice to >> see a test that actually uses your new keyword. > > I've made several mkdir tests with it, and it seems to work OK. I was > waiting to see if this patch is commited before I submit. > You can see it here: http://pastebin.com/tnKY4Q7S I'd like to see the code that implements @todo_wine@ submitted in the same patch as the first test that uses it. - Dan

June 13, 2011

Re: comctl32/tests: Added first TaskDialog test.

by Patrick Gauthier

On 06/13/11 06:54, André Hentschel wrote: > IIRC the reason for the temporary file is that we can easily turn the v6 > features on and off and AFAIK we can't if we have it "hardcoded" in a resource. I did not mean to hardcode as a resource of type RT_MANIFEST id 1, but rather some random id, then we can still manually load v6 using CreateActCtx, only we don't have to create a temporary file. On this page: http://msdn.microsoft.com/en-us/library/aa374149%28v=vs.85%29.aspx I point to you the members lpResourceName and hModule. That is what I was talking about. Sorry for the misunderstanding! - Patrick

June 13, 2011

Re: wineboot: Add a command line option to suppress the GUI window.

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > --- > programs/wineboot/wineboot.c | 15 +++++++++------ > 1 files changed, 9 insertions(+), 6 deletions(-) That's not going to do anything useful. -- Alexandre Julliard julliard(a)winehq.org

June 13, 2011

Re: user32: Handle SC_SCREENSAVE in DefWindowProc. (try 2)

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -1606,6 +1607,12 @@ LRESULT NC_HandleSysCommand( HWND hwnd, WPARAM wParam, LPARAM lParam ) > FreeLibrary( hmodule ); > } > } > + else > + { > + const char *argv[3] = { "xdg-screensaver", "activate", NULL }; > + spawnvp( _P_NOWAIT, argv[0], argv ); > + } This should be consolidated with the support in explorer, and probably moved to the graphics driver. -- Alexandre Julliard julliard(a)winehq.org

June 13, 2011

Re: [PATCH 2/4] shell32/tests: verify known folders available in system

by Alexandre Julliard

Mariusz Pluciński <vshader(a)gmail.com> writes: > + StringFromGUID2(folderid, sGuid, sizeof(sGuid)/sizeof(sGuid[0])); > + hr = IKnownFolderManager_GetFolder(mgr, folderid, &folder); > + ok(hr==S_OK, "cannot get folder (id: %s, hr: 0x%08x)\n", wine_dbgstr_w(sGuid), hr); > + > +#define CHECK_KNOWN_FOLDER(id, csidl) \ > + check_single_known_folder(__LINE__, mgr, folderid, &id, csidl, # id, # csidl); > + > + CHECK_KNOWN_FOLDER(FOLDERID_AddNewPrograms, NO_CSIDL) > + CHECK_KNOWN_FOLDER(FOLDERID_AdminTools, CSIDL_ADMINTOOLS) > + CHECK_KNOWN_FOLDER(FOLDERID_AppUpdates, NO_CSIDL) ... This should be a loop over an array. -- Alexandre Julliard julliard(a)winehq.org

June 13, 2011

Re: [2/8] dxdiag: Introduce the file output infrastructure.

by Alexandre Julliard

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > programs/dxdiag/Makefile.in | 3 +- > programs/dxdiag/main.c | 39 +++++++++++++++++++++++++++--- > programs/dxdiag/output.c | 54 +++++++++++++++++++++++++++++++++++++++++++ > programs/dxdiag/output.h | 49 +++++++++++++++++++++++++++++++++++++++ > 4 files changed, 140 insertions(+), 5 deletions(-) Please don't add so many new files. A single header for the whole program would do, and a couple of source files should be enough considering the amount of code you have. -- Alexandre Julliard julliard(a)winehq.org

June 13, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

> What does keybd_event() do? It seems to send WM_KEY and WM_KEYDOWN events to a window http://msdn.microsoft.com/en-us/library/ms646304%28VS.85%29.aspx > I suspect that Windows might not hooking the keyboard for DirectInput > usage, but attaches to some lower layer in the input stack. I'm not finding the exact paragraph now, but I remember reading something along this lines in MSDN.

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Jacek Caban

On 06/13/11 14:02, Frédéric Delanoy wrote: > On Mon, Jun 13, 2011 at 13:48, Jacek Caban <jacek(a)codeweavers.com> wrote: >> Hi Frédéric, >> >> On 06/12/11 23:01, Frédéric Delanoy wrote: >>> - >>> + is_todo_wine = is_todo_wine_line(exp_ptr, exp_nl); >>> + >> There is no need to add such logic directly to test_output, this can be >> returned from comare_line. > Do you mean as an extra parameter to compare_line? > e.g. > > static const char *compare_line(const char *out_line, const char > *out_end, const char *exp_line, const char *exp_end) > > becoming > > static const char *compare_line(const char *out_line, const char > *out_end, const char *exp_line, const char *exp_end, BOOL* > is_todo_line) Yes, something like that. Jacek

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Frédéric Delanoy

On Mon, Jun 13, 2011 at 13:48, Jacek Caban <jacek(a)codeweavers.com> wrote: > Hi Frédéric, > > On 06/12/11 23:01, Frédéric Delanoy wrote: >> - >> + is_todo_wine = is_todo_wine_line(exp_ptr, exp_nl); >> + > > There is no need to add such logic directly to test_output, this can be > returned from comare_line. Do you mean as an extra parameter to compare_line? e.g. static const char *compare_line(const char *out_line, const char *out_end, const char *exp_line, const char *exp_end) becoming static const char *compare_line(const char *out_line, const char *out_end, const char *exp_line, const char *exp_end, BOOL* is_todo_line)

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Jacek Caban

Hi Frédéric, On 06/12/11 23:01, Frédéric Delanoy wrote: > - > + is_todo_wine = is_todo_wine_line(exp_ptr, exp_nl); > + There is no need to add such logic directly to test_output, this can be returned from comare_line. Jacek

June 13, 2011

Re: GSoC: dinput8 Action Mapping

by Marcus Meissner

On Sun, Jun 12, 2011 at 10:45:38PM -0300, Lucas Zawacki wrote: > I'm having some issues with test that inject input. For instance this > code ( http://pastebin.com/gan0Niqj ) works as expected under wine and > wine with dinput8.dll , but fails in every windows version... I tried > a version with SendInput and had the same results... > > Anyone has some insight on this? What does keybd_event() do? I suspect that Windows might not hooking the keyboard for DirectInput usage, but attaches to some lower layer in the input stack. Ciao, Marcus

June 13, 2011

Re: comctl32/tests: Added first TaskDialog test.

by André Hentschel

Am 13.06.2011 00:09, schrieb Patrick Gauthier: > - As a result of the previous comment, there would be no point to > generate the manifest as a file, as it could be loaded from a > resource (CreateActCtx supports this), that would seem cleaner to me > than generating temporary files. IIRC the reason for the temporary file is that we can easily turn the v6 features on and off and AFAIK we can't if we have it "hardcoded" in a resource. -- Best Regards, André Hentschel

June 13, 2011

Re: cmd: add support for todo_wine constructions in testing infrastructure

by Frédéric Delanoy

2011/6/13 Dan Kegel <dank(a)kegel.com>: > I agree @todo_space@ should go; it's never used, so it's dead code now. > Tempting to say that removing it should be a separate patch, > rather than combining that with adding a new feature. Well, maybe but I didn't see its usefulness when @todo_wine@ is introduced. It could help for regression testing, admittedly > Since all the @keywords@ are poorly documented, > I'm glad to see an unused one go. > > Your generic @todo_wine@ keyword seems useful. > > The current code is a bit ugly. If you're going to add a > nice is_todo_wine_line() helper, it might make sense > to do a cleanup patch that cleans up the @keyword@ > recognition in general first. (Why the verbose array > declaration instead of a "constant"? etc.) Those keywords can appear anywhere on the line and act basically as a search&replace (except @or_broken@) while the @todo_wine@ must be used at the start of a line to be recognized, and doesn't generate any text. But OK an array seemed odd to me as well... it was probably done so that sizeof(foo_cmd) could be used in memcp(expected_ptr, foo_cmd, sizeof(foo_cmd)). Maybe it was done to optimise stuff since sizeof(foo_cmd) would be computed at compile time, but I don't see why strlen() would not be for static string constants. As for the helper, I originally thought about adding a param to compare_line so that static const char *compare_line(const char *out_line, const char *out_end, const char *exp_line, const char *exp_end) becomes static const char *compare_line(const char *out_line, const char *out_end, const char *exp_line, const char *exp_end, BOOL* is_todo_line) There would then be no need of a is_todo_wine_line() helper. Would that be better? > I see you're making every line of the .exp file count as > a test. That seems ok. That's actually how it currently works: I didn't change that behaviour, but added a check fo > There's a fair bit of code duplication; I wonder if you > could avoid that by refactoring things a bit. Maybe but I wanted to keep this patch as > To avoid adding dead code, it might be nice to > see a test that actually uses your new keyword. I've made several mkdir tests with it, and it seems to work OK. I was waiting to see if this patch is commited before I submit. You can see it here: http://pastebin.com/tnKY4Q7S >Dan Frédéric

June 13, 2011

Re: comctl32/tests: Added first TaskDialog test.

by Nikolay Sivov

On Mon, Jun 13, 2011 at 2:09 AM, Patrick Gauthier <webmaster(a)korosoft.net> wrote: >> 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. > > Thanks for the information. I have redone my patch using it. > > I looked at v6util.h and could not help but notice two things though: > > - There is no need to set processorArchitecture to "x86" or "amd64" > as far as I know, Windows will happily take "*" to mean "whatever > the currently applicable architecture is". > - As a result of the previous comment, there would be no point to > generate the manifest as a file, as it could be loaded from a > resource (CreateActCtx supports this), that would seem cleaner to me > than generating temporary files. Sure, improvements are always welcome. As separate patches of course. > > - Patrick > > >

June 12, 2011