user32/tests: Add test for SetFocus() (with few todo)(Try 2).

2012-09-18 Thread Sergey Guralnik

Alexandre Julliard writes:


Not really. If you want to test purely the Wine behavior, then you
shouldn't be waiting for window manager events. If the window manager 
is

involved then you can't guarantee that a given window will always get
focus.


If your app breaks because the window manager doesn't give it focus 
at a

certain point, then pretty much the only solution is to change the wm
policy, or use a different wm.


Thanks for explanations.

--
Sergey




Re: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

2012-09-17 Thread Sergey Guralnik

Alexandre Julliard wrote:


Sergey Guralnik serhio at etersoft.ru writes:


I've sent next patch more than month ago, and have no comments about
it.

From 57adc6991431cd765dcdb97082263db834e4b533 Mon Sep 17 00:00:00 
2001

From: Sergey Guralnik serhio at etersoft.ru
Date: Thu, 9 Aug 2012 17:12:56 +0400
Subject: user32/tests: Add test for SetFocus() (with few todo)(Try 
2).


Is anything wrong with this one?


That's mostly testing the window manager focus policy, I don't think
that makes sense. What are you trying to demonstrate with this?


I try to show that some applications rely on finishing all side focus
switching, which are result of call to some window management function,
before this function returns.
For example my app hopes that result of call to SetFocus() will not be
distorted in message loop due call to DestroyWindow(), that made before
call to SetFocus().
Is my explanation clear enough?

--
Sergey




Re: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

2012-09-17 Thread Alexandre Julliard
Sergey Guralnik ser...@etersoft.ru writes:

 That's mostly testing the window manager focus policy, I don't think
 that makes sense. What are you trying to demonstrate with this?

 I try to show that some applications rely on finishing all side focus
 switching, which are result of call to some window management function,
 before this function returns.
 For example my app hopes that result of call to SetFocus() will not be
 distorted in message loop due call to DestroyWindow(), that made before
 call to SetFocus().
 Is my explanation clear enough?

Not really. If you want to test purely the Wine behavior, then you
shouldn't be waiting for window manager events. If the window manager is
involved then you can't guarantee that a given window will always get
focus.

If your app breaks because the window manager doesn't give it focus at a
certain point, then pretty much the only solution is to change the wm
policy, or use a different wm.

-- 
Alexandre Julliard
julli...@winehq.org




Re: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

2012-09-14 Thread Alexandre Julliard
Sergey Guralnik ser...@etersoft.ru writes:

 I've sent next patch more than month ago, and have no comments about
 it.

 From 57adc6991431cd765dcdb97082263db834e4b533 Mon Sep 17 00:00:00 2001
 From: Sergey Guralnik ser...@etersoft.ru
 Date: Thu, 9 Aug 2012 17:12:56 +0400
 Subject: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

 Is anything wrong with this one?

That's mostly testing the window manager focus policy, I don't think
that makes sense. What are you trying to demonstrate with this?

-- 
Alexandre Julliard
julli...@winehq.org




Re: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

2012-09-13 Thread Sergey Guralnik
I've sent next patch more than month ago, and have no comments about 
it.


From 57adc6991431cd765dcdb97082263db834e4b533 Mon Sep 17 00:00:00 2001
From: Sergey Guralnik ser...@etersoft.ru
Date: Thu, 9 Aug 2012 17:12:56 +0400
Subject: user32/tests: Add test for SetFocus() (with few todo)(Try 2).

Is anything wrong with this one?

--
Sergey