Re: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]

[Dmitry Timoshkov]

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote:
> According to native messages sent to app we should redraw window
> inside SetActiveWindow.

If you have a test app then it should be converted into a Wine message
test, there is no other way to prove that your patch is correct.
> @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd
>
> if (IsWindow(hwnd))
>      {
> -        SendMessageW( hwnd, WM_NCACTIVATE, (hwnd == GetForegroundWindow()), (LPARAM)previous );
> +        SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous );

Active and foreground windows in win32 are not necessary the same window.

-- 
Dmitry.

Re[2]: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]

[Vitaliy Margolen]

Wednesday, May 11, 2005, 8:08:09 PM, you wrote:
> "Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote:
> > According to native messages sent to app we should redraw window
> > inside SetActiveWindow.
> > If you have a test app then it should be converted into a Wine message
> > test, there is no other way to prove that your patch is correct.
> > I have sent a test in a separate patch. It does verify this statement. The test
> > I used is an altered version of tests\win.c dumping all messages. Then I
> > compared native and wine outputs.

As far as WM_WINDOWPOSCHANGING/ED go, it does depend on Z-order changes that
Alexandre indicated are up to wm and not critical anyway. My patch will send
more of these messages than native. But I would think they are important enough
to be sent, especially WM_WINDOWPOSCHANGED.
> > @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd
> >
> > if (IsWindow(hwnd))
> >      {
> > -        SendMessageW( hwnd, WM_NCACTIVATE, (hwnd ==
> > GetForegroundWindow()), (LPARAM)previous );
> > +        SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous );
> Active and foreground windows in win32 are not necessary the same window.
> As it was it was always sending FALSE. Not sure what the deal is here. I would
> think that active window might need to change it's icon. Considering that here
> we do activate window and it should became foreground, this change is correct.

Also SetForegroundWindow actually calls SetActiveWindow any way. So active
window _is_ foreground window.
Because earlier in that function we test for previous != hwnd this code being
reached only when we change active window.

Vitaliy

Re[2]: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]

[Dmitry Timoshkov]

"Vitaliy Margolen" <wine-devel(a)kievinfo.com> wrote:
> > > According to native messages sent to app we should redraw window
> > > inside SetActiveWindow.
> > > If you have a test app then it should be converted into a Wine message
> > > test, there is no other way to prove that your patch is correct.
> > > I have sent a test in a separate patch. It does verify this statement. The test
> > > I used is an altered version of tests\win.c dumping all messages. Then I
> > > compared native and wine outputs.

I meant a msg.c test. That's exactly the kind of the test appropriate
for the behaviour you are trying to fix.
> As far as WM_WINDOWPOSCHANGING/ED go, it does depend on Z-order changes that
> Alexandre indicated are up to wm and not critical anyway. My patch will send
> more of these messages than native. But I would think they are important enough
> to be sent, especially WM_WINDOWPOSCHANGED.

As I noted in the previous mail, all window management/message handling related
patches require a test case in order to be accepted.
> > > @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd
> > >
> > > if (IsWindow(hwnd))
> > >      {
> > > -        SendMessageW( hwnd, WM_NCACTIVATE, (hwnd ==
> > > GetForegroundWindow()), (LPARAM)previous );
> > > +        SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous );
> > Active and foreground windows in win32 are not necessary the same window.
> > As it was it was always sending FALSE. Not sure what the deal is here. I would
> > think that active window might need to change it's icon. Considering that here
> > we do activate window and it should became foreground, this change is correct.

Active and foreground windows are set per thread. If a window does not belong
to a foreground thread it can't activate a window.
> Also SetForegroundWindow actually calls SetActiveWindow any way. So active
> window _is_ foreground window.
> Because earlier in that function we test for previous != hwnd this code being
> reached only when we change active window.

Current window activation code in Wine is not entirely correct. I believe that
might be a part of WM rewrite Alexandre is finishing which at the moment.

-- 
Dmitry.

Re[2]: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]

[Alexandre Julliard]

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes:
> Current window activation code in Wine is not entirely correct. I believe that
> might be a part of WM rewrite Alexandre is finishing which at the moment.

Not really, I'm not aware of any problem with the window activation
code, and I'm certainly not working on that part of the code now. What
problems do you know about?

-- 
Alexandre Julliard
julliard(a)winehq.org

user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]

[Dmitry Timoshkov]

"Alexandre Julliard" <julliard(a)winehq.org> wrote:
> > Current window activation code in Wine is not entirely correct. I believe that
> > might be a part of WM rewrite Alexandre is finishing which at the moment.
>
> Not really, I'm not aware of any problem with the window activation
> code, and I'm certainly not working on that part of the code now. What
> problems do you know about?

I'm aware of the one problem so far: the message order in process of a window
activation/zoom/minimize is different from the Windows one. But that single
problem supposedly translates into a bunch of different small problems with
window activation.

-- 
Dmitry.