"James Hawkins" jhawkins@codeweavers.com wrote:
According to msdn, "The foreground window can be NULL in certain circumstances, such as when a window is losing activation. " which is exactly when these failures occur.
Changelog:
- Allow a NULL foreground window in the tests.
NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground.
On Thu, May 29, 2008 at 10:07 AM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" jhawkins@codeweavers.com wrote:
According to msdn, "The foreground window can be NULL in certain circumstances, such as when a window is losing activation. " which is exactly when these failures occur.
Changelog:
- Allow a NULL foreground window in the tests.
NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground.
It's not consistent across platforms.
"James Hawkins" truiken@gmail.com wrote:
NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground.
It's not consistent across platforms.
Passing 0 for foreground will make the same thing as your patch - prevent failures when there is no consistent foreground window, i.e. when the test is useless.
On Thu, May 29, 2008 at 10:21 AM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
NULL foreground window is already allowed, you just need to fix the callers of check_wnd_state() to pass 0 for foreground.
It's not consistent across platforms.
Passing 0 for foreground will make the same thing as your patch - prevent failures when there is no consistent foreground window, i.e. when the test is useless.
Passing 0 for the foreground window essentially disables the test, whereas allowing a NULL window is testing another variation of what can happen with the foreground window, just like if a last error is, e.g., ERROR_FILE_NOT_FOUND on one platform instead of ERROR_PATH_NOT_FOUND. Your method disables the test completely.
"James Hawkins" truiken@gmail.com wrote:
Passing 0 for the foreground window essentially disables the test, whereas allowing a NULL window is testing another variation of what can happen with the foreground window, just like if a last error is, e.g., ERROR_FILE_NOT_FOUND on one platform instead of ERROR_PATH_NOT_FOUND. Your method disables the test completely.
Yes, passing foreground == 0 disables the foreground window test. That should be done very carefully for the tests that always fail. I'd expect for instance test_SetActiveWindow() and test_SetForegroundWindow() not need to disable it.
On Thu, May 29, 2008 at 8:24 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
Passing 0 for the foreground window essentially disables the test, whereas allowing a NULL window is testing another variation of what can happen with the foreground window, just like if a last error is, e.g., ERROR_FILE_NOT_FOUND on one platform instead of ERROR_PATH_NOT_FOUND. Your method disables the test completely.
Yes, passing foreground == 0 disables the foreground window test. That should be done very carefully for the tests that always fail. I'd expect for instance test_SetActiveWindow() and test_SetForegroundWindow() not need to disable it.
I've debugged this a bit more, and when running the user32:win test within the winetest.exe program, all checked calls to GetForegroundWindow return NULL. When running the user32:win test by itself from the command line, only 7 tests fail the GetForegroundWindow call (compared to 40). This makes me wonder about the behavior of GetForegroundWindow in a child process window, but I'm not really sure where to go from here.
On Tue, Jun 10, 2008 at 7:15 PM, James Hawkins truiken@gmail.com wrote:
On Thu, May 29, 2008 at 8:24 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
Passing 0 for the foreground window essentially disables the test, whereas allowing a NULL window is testing another variation of what can happen with the foreground window, just like if a last error is, e.g., ERROR_FILE_NOT_FOUND on one platform instead of ERROR_PATH_NOT_FOUND. Your method disables the test completely.
Yes, passing foreground == 0 disables the foreground window test. That should be done very carefully for the tests that always fail. I'd expect for instance test_SetActiveWindow() and test_SetForegroundWindow() not need to disable it.
I've debugged this a bit more, and when running the user32:win test within the winetest.exe program, all checked calls to GetForegroundWindow return NULL. When running the user32:win test by itself from the command line, only 7 tests fail the GetForegroundWindow call (compared to 40). This makes me wonder about the behavior of GetForegroundWindow in a child process window, but I'm not really sure where to go from here.
Some more information: these 40 GetForegroundWindow failures occur on all platforms >= win2k.
"James Hawkins" truiken@gmail.com wrote:
I've debugged this a bit more, and when running the user32:win test within the winetest.exe program, all checked calls to GetForegroundWindow return NULL. When running the user32:win test by itself from the command line, only 7 tests fail the GetForegroundWindow call (compared to 40). This makes me wonder about the behavior of GetForegroundWindow in a child process window, but I'm not really sure where to go from here.
I'd suggest to make winetest minimize itself before running the tests.
On Tue, Jun 10, 2008 at 9:36 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
I've debugged this a bit more, and when running the user32:win test within the winetest.exe program, all checked calls to GetForegroundWindow return NULL. When running the user32:win test by itself from the command line, only 7 tests fail the GetForegroundWindow call (compared to 40). This makes me wonder about the behavior of GetForegroundWindow in a child process window, but I'm not really sure where to go from here.
I'd suggest to make winetest minimize itself before running the tests.
I added the minimize call to winetest, but the win failures are still happening. Now I'm wondering if it has to do with the fact that explorer either gets restarted, or disappears or something right before the win tests and if that affects the win tests. You can see it happening during the tests. The desktop and taskbar disappear about the same time the win tests are run. That's just a guess though.
"James Hawkins" truiken@gmail.com wrote:
I added the minimize call to winetest, but the win failures are still happening. Now I'm wondering if it has to do with the fact that explorer either gets restarted, or disappears or something right before the win tests and if that affects the win tests. You can see it happening during the tests. The desktop and taskbar disappear about the same time the win tests are run. That's just a guess though.
Does it help if you comment out test_shell_window(), or make it the very last test?
On Fri, Jun 13, 2008 at 11:40 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
I added the minimize call to winetest, but the win failures are still happening. Now I'm wondering if it has to do with the fact that explorer either gets restarted, or disappears or something right before the win tests and if that affects the win tests. You can see it happening during the tests. The desktop and taskbar disappear about the same time the win tests are run. That's just a guess though.
Does it help if you comment out test_shell_window(), or make it the very last test?
Commenting the test out doesn't help.
"James Hawkins" truiken@gmail.com wrote:
Commenting the test out doesn't help.
Then I'm out of ideas, but it's clear to me that it's winetest who screws the things up.
-
Dmitry Timoshkov -
James Hawkins