"Vitaliy Margolen" wine-devel@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.