[PATCH 1/5] user32/tests: Add tests for GetWindowPlacement() and SetWindowPlacement().

Zebediah Figura z.figura12 at gmail.com
Thu Feb 14 10:01:28 CST 2019


On 2/14/19 4:25 AM, Gabriel Ivăncescu wrote:
> On 2/14/19 6:17 AM, Zebediah Figura wrote:
>> On 2/13/19 2:16 PM, Alexandre Julliard wrote:
>>> Zebediah Figura <z.figura12 at gmail.com> writes:
>>>
>>>> On 2/10/19 1:39 PM, Marvin wrote:
>>>>> 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:
>>>>> https://testbot.winehq.org/JobDetails.pl?Key=47392
>>>>>
>>>>> Your paranoid android.
>>>>>
>>>>>
>>>>> === wvistau64 (32 bit report) ===
>>>>>
>>>>> user32:
>>>>> win.c:10796: Test failed: got minimized pos (0,713)
>>>>> win.c:10808: Test failed: got minimized pos (0,713)
>>>>> win.c:10820: Test failed: got minimized pos (0,713)
>>>>> win.c:10833: Test failed: got minimized pos (0,713)
>>>>> win.c:10846: Test failed: got minimized pos (0,713)
>>>>> win.c:10859: Test failed: got minimized pos (0,713)
>>>>> win.c:10872: Test failed: got minimized pos (0,713)
>>>>> win.c:10906: Test failed: got minimized pos (100,100)
>>>>> win.c:10928: Test failed: got minimized pos (100,100)
>>>>>
>>>>
>>>> *snip*
>>>>
>>>> This fails because test_shell_window(), which is pretty pathological,
>>>> kills explorer.exe, and that doesn't restart itself until the test
>>>> program terminates. What can be done about this, if anything?
>>>
>>> The obvious fix is to run your test before the one that kills the shell
>>> window. Though if the behavior depends on having a shell window, it may
>>> be interesting to test both cases.
>>>
>>
>> Thanks. I guess I wasn't sure if that was an acceptable solution.
>>
>> I guess the behaviour here makes sense—if there's no shell window, there
>> won't be a taskbar, and so windows would have no way of being restored
>> if they're minimized offscreen. But I'm also not sure it's something
>> that there's any point replicating in Wine (either windows are offscreen
>> anyway due to WM integration, or explorer.exe is necessary to run the
>> virtual desktop), so I'll leave off testing this, unless you think it'd
>> be better to do so.
>>
>>
> 
> Hi Zeb,
> 
> Just wondering, could this (missing) behavior have something to do with
> https://bugs.winehq.org/show_bug.cgi?id=15346
> 
> 

It's not immediately evident to me why it would, I guess? Does the 
program call SetShellWindow()?



More information about the wine-devel mailing list