Setting some windows relations.

[John Found]

Hi All.
I am developing in Linux a GUI toolkit, that has port for Windows and I test in under WINE.
Surprisingly, I stuck on two problems that look different, but probably has the same origin.

The first is the setting of the owner window for the modal dialogs. In Windows it is common practice
to set it through SetWindowLong with GWL_HWNDPARENT and it works - the owner window stay always under the .

In WINE, setting the owner this way does not work. The owner window can be raised above the modal dialog. 
On the other hand, setting the hWndParent in CreateWindowEx works as intended.

The problem is that when I create the dialog window I don't know the owner window I will use later and it
can change during program execution.

The second problem is with the windows that have to change from WS_POPUP to WS_OVERLAPPED and back by the
same SetWindowLong.
When I create a window as WS_OVERLAPPED and then change the style to WS_POPUP, the window looks like WS_POPUP, 
but does not behave as such. For example in Linux it has override_redirect=0, steals the focus from the main window, etc.
When the window is created initially with WS_POPUP, nothing of this happens.

Again in Windows, changing the style by SetWindowLong works as intended.

Is there some simple workaround of these problems? In order to fight it I must redesign the whole library in
order to create the windows with the right parameters. Some of the features I want to make need to destroy the
windows and recreate them instead of simply change the needed parameters.

[Vincent Povirk]

> The first is the setting of the owner window for the modal dialogs. In Windows it is common practice
> to set it through SetWindowLong with GWL_HWNDPARENT and it works - the owner window stay always under the .
>
> In WINE, setting the owner this way does not work. The owner window can be raised above the modal dialog.
> On the other hand, setting the hWndParent in CreateWindowEx works as intended.
> From inspecting the code (and not doing any actual debugging), I think

the issue here is that user32 doesn't notify the X11 driver when the
window owner changes. You might be able to force the X11 driver to
refresh this information by setting an icon on the window.
> The second problem is with the windows that have to change from WS_POPUP to WS_OVERLAPPED and back by the
> same SetWindowLong.
> When I create a window as WS_OVERLAPPED and then change the style to WS_POPUP, the window looks like WS_POPUP,
> but does not behave as such. For example in Linux it has override_redirect=0, steals the focus from the main window, etc.
> When the window is created initially with WS_POPUP, nothing of this happens.
>
> Again in Windows, changing the style by SetWindowLong works as intended.

We have a mechanism for changing an override_redirect window to
non-override_redirect, but I don't see anything for the other
direction. You might be able to work around this by setting the
window's parent (using SetParent) to something other than the desktop,
then setting the parent back to the desktop (which should mean
destroying the X11 window and recreating it).

I'd suggest using a virtual desktop for testing, but I know at the
moment this has z-order problems as well. While user32 has an internal
notion of z-order that should be consistent with real windows, that's
not 1:1 with what's in virtual desktops or X11. (In the Mac driver, it
is 1:1, but I know that's not any help. I don't know any good reason
we couldn't change this in virtual desktops at least.)

[Dmitry Timoshkov]

John Found  wrote:
> The first is the setting of the owner window for the modal dialogs. In Windows it is common practice
> to set it through SetWindowLong with GWL_HWNDPARENT and it works - the owner window stay always under the .
>
> In WINE, setting the owner this way does not work. The owner window can be raised above the modal dialog. 
> On the other hand, setting the hWndParent in CreateWindowEx works as intended.
>
> The problem is that when I create the dialog window I don't know the owner window I will use later and it
> can change during program execution.

Is the parent window you assign GWL_HWNDPARENT to visible at that point?
If it is not then that might be the source of the problem.
> The second problem is with the windows that have to change from WS_POPUP to WS_OVERLAPPED and back by the
> same SetWindowLong.
> When I create a window as WS_OVERLAPPED and then change the style to WS_POPUP, the window looks like WS_POPUP, 
> but does not behave as such. For example in Linux it has override_redirect=0, steals the focus from the main window, etc.
> When the window is created initially with WS_POPUP, nothing of this happens.
>
> Again in Windows, changing the style by SetWindowLong works as intended.
>
> Is there some simple workaround of these problems? In order to fight it I must redesign the whole library in
> order to create the windows with the right parameters. Some of the features I want to make need to destroy the
> windows and recreate them instead of simply change the needed parameters.

Do you have a simple application that reproduces this?

[John Found]

On Fri, 20 Nov 2015 07:42:14 +0800
Dmitry Timoshkov  wrote:
> Is the parent window you assign GWL_HWNDPARENT to visible at that point?
> If it is not then that might be the source of the problem.

Yes it is visible.
> Do you have a simple application that reproduces this?

Well, I can prepare some simple example, but it will be in assembly language (FASM).
Is it OK?

[Dmitry Timoshkov]

John Found  wrote:
> > Do you have a simple application that reproduces this?
>
> Well, I can prepare some simple example, but it will be in assembly language (FASM).
> Is it OK?

If the sample includes a compiled binary then it's OK.

[John Found]

On Fri, 20 Nov 2015 16:35:47 +0800
Dmitry Timoshkov  wrote:
> If the sample includes a compiled binary then it's OK.

In the attachment there is an archive with two projects (with the sources) and two executables:

Owner.exe demonstrates the wrong behaviour of GWL_HWNDPARENT

Popup.exe the wrong behavior of GWL_STYLE.

Readme.exe explains what is the behaviour in Linux and Windows on my tests. 
My tests are provided on Windown 7 and WINE 1.7.54

The test executables will send some debug messages to the console and will open their own
console if started from the GUI.

The sources can be easily compiled with Fresh IDE ((see my signature) out of the box), 
or with FASM (with some include files download and env variables set).

Hope this code will be useful.

Best Regards

[John Found]

On Fri, 20 Nov 2015 16:35:47 +0800
Dmitry Timoshkov  wrote:
> If the sample includes a compiled binary then it's OK.

The test examples can be downloaded from: http://asm32.info/content/_files/ExamplesForWINE.tar.gz

In the archive there are two projects (with the sources) and two compiled binaries:

"Owner.exe" demonstrates the wrong behaviour of GWL_HWNDPARENT

"Popup.exe" the wrong behavior of GWL_STYLE.

"Readme.txt" explains what is the behaviour in Linux and Windows on my tests.

My tests has been made on Windows 7 and WINE 1.7.54

The tests will send some debug messages to the console and will open their own
console if started from the GUI.

The sources can be easily compiled out of the box with Fresh IDE (see my signature), 
or with FASM (will need some include files download and env variables set).

Hope this code will be useful.

Best Regards

[Dmitry Timoshkov]

John Found  wrote:
> "Owner.exe" demonstrates the wrong behaviour of GWL_HWNDPARENT

Attached patch should fix the problem with GWL_HWNDPARENT. For some reason
Wine currently doesn't synchronize owner with USER driver (X11) backend,
previously I had strong feeling that it does.
> "Popup.exe" the wrong behavior of GWL_STYLE.

The problem with adding/removing WS_POPUP probably is window manager specific,
because it implies changing the window type to/from DIALOG and NORMAL.

[Ken Thomases]

On Nov 21, 2015, at 1:33 AM, Dmitry Timoshkov  wrote:
> --- a/dlls/user32/win.c
> +++ b/dlls/user32/win.c
> @@ -728,6 +728,8 @@ HWND WIN_SetOwner( HWND hwnd, HWND owner )
>      }
>      SERVER_END_REQ;
>      WIN_ReleasePtr( win );
> -
> - USER_Driver->pSetParent( hwnd, owner, ret );
> return ret;
>
> }

That doesn't seem right.  The owner is not really the parent (even if the hWndParent parameter of CreateWindowEx() is overloaded to mean the owner in some cases).  Telling the user driver that the owner is now the parent is likely to make it destroy the native window.  In any case, it's not right semantically.

Also, it's likely to screw up OpenGL due to the call to set_gl_drawable_parent() in X11DRV_SetParent() [or set_gl_view_parent() in macdrv_SetParent()].

This may need a new driver entry point.

-Ken

[Dmitry Timoshkov]

Hi Ken,

Ken Thomases  wrote:
> > --- a/dlls/user32/win.c
> > +++ b/dlls/user32/win.c
> > @@ -728,6 +728,8 @@ HWND WIN_SetOwner( HWND hwnd, HWND owner )
> >      }
> >      SERVER_END_REQ;
> >      WIN_ReleasePtr( win );
> > -
> > - USER_Driver->pSetParent( hwnd, owner, ret );
> > return ret;
> >
> > }
>
> That doesn't seem right.  The owner is not really the parent (even if the hWndParent parameter of CreateWindowEx() is overloaded to mean the owner in some cases).  Telling the user driver that the owner is now the parent is likely to make it destroy the native window.  In any case, it's not right semantically.
>
> Also, it's likely to screw up OpenGL due to the call to set_gl_drawable_parent() in X11DRV_SetParent() [or set_gl_view_parent() in macdrv_SetParent()].
>
> This may need a new driver entry point.

I'm fully agree on all points, the patch is just a proof of concept.