[Bug 33235] New: WM_NOTIFY receive problem

http://bugs.winehq.org/show_bug.cgi?id=33235

Bug #: 33235
           Summary: WM_NOTIFY receive problem
           Product: Wine
           Version: 1.5.26
          Platform: x86-64
        OS/Version: Mac OS X
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: comctl32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Created attachment 43955
  --> http://bugs.winehq.org/attachment.cgi?id=43955
source code of bug example application

I have wine 1.5.26 compiled with ./configure && make && make install

I found a problem and for example create an example program.

It looks like, that when I create tab control with HWND_MESSAGE parent and
lately change parent with use SetParent function to window parent (line 79 in
attachment) and show it, it isn't posting WM_NOTIFY message to actual parent.

Example program work good on MS Window XP. I tested it myself.

My command for compile example appliaction:
i686-w64-mingw32-gcc -o main.exe main.c -luser32 -lgdi32 -lcomctl32

pastie of source code (this is in attachment too):
http://pastebin.com/YdFbZGxa

[Bug 33235] WM_NOTIFY receive problem

http://bugs.winehq.org/show_bug.cgi?id=33235

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #43955|application/octet-stream    |text/plain
          mime type|                            |

[Bug 33235] WM_NOTIFY receive problem

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #1 from Nikolay Sivov  2013-03-17 15:17:57 CDT ---
It doesn't send it to new parent cause it keeps notification handle passed on
creation and it's never updated. Similar issue for user controls is described
here http://support.microsoft.com/kb/104069. Did you verify that it works with
native comctl32 in wine?

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|WM_NOTIFY receive problem   |Tab control doesn't notify
                   |                            |new parent set with
                   |                            |SetParent()

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |testcase

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #2 from Martin Štrympl  2013-03-18 12:04:11 CDT ---
Hmm.
Yeah. It looks like a reason for this problem.
But it isn't exmlain, why it works diffrent in native MS Window XP instalation
in my Virtual Box and in wine on my Mac OS X system.

May be HWND_MESSAGE window in MS Window XP do automaticaly resend message to
new parent. And not in wine. I have no idea.

May be it is some bug in my MS Window XP instalation that it receive WM_NOTIFY
from both window correctly. Can you check it on some other window instalation?
If it really work diffrent it is really wine bug, I think.

I was looking for solution of this problem etc. two days and I didn't find it
(mean http://support.microsoft.com/kb/104069). If it is my fault and not wine
fault, I am sorry for losing your time.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #3 from Martin Štrympl  2013-03-18 12:07:28 CDT ---
Did you verify that it works with
native comctl32 in wine?

I don't verify it. But I remove .wine setting after wine build and install.
I expect, it uses it.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #4 from Nikolay Sivov  2013-03-18 12:18:38 CDT ---
(In reply to comment #2)
> Hmm.
> Yeah. It looks like a reason for this problem.
> But it isn't exmlain, why it works diffrent in native MS Window XP instalation
> in my Virtual Box and in wine on my Mac OS X system.

If it doesn't work properly in wine like it does on windows it's certainly a
wine bug.
> May be HWND_MESSAGE window in MS Window XP do automaticaly resend message to
> new parent. And not in wine. I have no idea.

I don't think there's any magic going on. Wine never updates cached
notification handle and when you switch a parent it invalidates this cache.
> May be it is some bug in my MS Window XP instalation that it receive WM_NOTIFY
> from both window correctly.

I'm not sure I understand you here. What do you mean by 'both windows'?
> Can you check it on some other window instalation?
> If it really work diffrent it is really wine bug, I think.
> I was looking for solution of this problem etc. two days and I didn't find it
> (mean http://support.microsoft.com/kb/104069). If it is my fault and not wine
> fault, I am sorry for losing your time.

No, so far there's no indication it's your fault, but I have to test in myself.

By the way do I need any VB runtime redist for this application to work or
everything is bundled?

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #5 from Nikolay Sivov  2013-03-18 12:29:09 CDT ---
(In reply to comment #4)
> By the way do I need any VB runtime redist for this application to work or
> everything is bundled?

Sorry, this is from another report and doesn't belong here.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #6 from Martin Štrympl  2013-03-18 17:46:46 CDT ---
> > May be it is some bug in my MS Window XP instalation that it receive WM_NOTIFY
> > from both window correctly.
>
> I'm not sure I understand you here. What do you mean by 'both windows'?

I mean both windows from example program.

Ok. You will see after your test.
I hope that my example code will be helpful for you.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

Nikolay Sivov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #7 from Nikolay Sivov  2013-03-19 02:26:55 CDT ---
(In reply to comment #6)
> Ok. You will see after your test.
> I hope that my example code will be helpful for you.

Yes, I can see that now. Window B doesn't get notification after clicking on
tabs for example, on windows it does get it, so confirming. I'll see what I can
do to fix that. On an unrelated note - you shouldn't use PeekMessage() cause it
doesn't wait and loop is executed constantly.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #8 from Dmitry Timoshkov  2013-03-19 02:43:03 CDT ---
(In reply to comment #7)
> On an unrelated note - you shouldn't use PeekMessage() cause it
> doesn't wait and loop is executed constantly.

PeekMessage does wait.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #9 from Nikolay Sivov  2013-03-19 03:08:11 CDT ---
Created attachment 43969
  --> http://bugs.winehq.org/attachment.cgi?id=43969
patch

Martin, please try this patch.

(In reply to comment #8)
> PeekMessage does wait.
> From what I see in code it does not. It calls a waiting handler with zero

timeout which basically means return immediately if queue is empty, later on
handler calls to driver message waiter which returns on zero timeout if there's
nothing in queue. Application behavior proves that.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #10 from Martin Štrympl  2013-03-19 03:23:19 CDT ---
(In reply to comment #7)
> On an unrelated note - you shouldn't use PeekMessage() cause it
> doesn't wait and loop is executed constantly.

Yeah. You are right.
It is because of copying this code from my bigger project where I find this
wine bug and where I don't want to wait to message. I use there sleep function
after do something else after receive/not receive message by PeekMessage.

During writing example code I forgot to copy sleeping code or change
PeekMessage to GetMessage function.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #11 from Dmitry Timoshkov  2013-03-19 05:31:08 CDT ---
(In reply to comment #9)
> > PeekMessage does wait.
>
> From what I see in code it does not. It calls a waiting handler with zero
> timeout which basically means return immediately if queue is empty, later on
> handler calls to driver message waiter which returns on zero timeout if there's
> nothing in queue. Application behavior proves that.

If you mean that PeekMessage doesn't yield cpu and therefore it shouldn't be
used to write message loops, then this is not correct. Message loops that use
PeekMessage are equivalent in behaviour to the ones that use GetMessage.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

Daniel Jelinski  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #12 from Daniel Jelinski  2013-03-19 08:18:55 CDT ---
(In reply to comment #11)
> If you mean that PeekMessage doesn't yield cpu and therefore it shouldn't be
> used to write message loops, then this is not correct. Message loops that use
> PeekMessage are equivalent in behaviour to the ones that use GetMessage.

PeekMessage returns immediately, and message loop based on PeekMessage without
WaitMessage will consume all CPU cycles it can get. See also bug 30736, which
is caused exactly by this.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #13 from Dmitry Timoshkov  2013-03-19 08:44:57 CDT ---
(In reply to comment #12)
> > If you mean that PeekMessage doesn't yield cpu and therefore it shouldn't be
> > used to write message loops, then this is not correct. Message loops that use
> > PeekMessage are equivalent in behaviour to the ones that use GetMessage.
>
> PeekMessage returns immediately,

No, it doesn't.
> and message loop based on PeekMessage without
> WaitMessage will consume all CPU cycles it can get. See also bug 30736, which
> is caused exactly by this.

It doesn't mean that in Windows it behaves like this.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #14 from Daniel Jelinski  2013-03-19 09:56:10 CDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > > If you mean that PeekMessage doesn't yield cpu and therefore it shouldn't be
> > > used to write message loops, then this is not correct. Message loops that use
> > > PeekMessage are equivalent in behaviour to the ones that use GetMessage.
> >
> > PeekMessage returns immediately,
>
> No, it doesn't.

Interesting. Are you saying that the following loops are equivalent?
while (GetMessage(&msg, NULL, 0, 0))
{
    DispatchMessage(&msg);
}

while (1)
{
    PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
    if(msg.message == WM_QUIT) break;
    DispatchMessage(&msg);
}

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #15 from Dmitry Timoshkov  2013-03-19 10:02:57 CDT ---
(In reply to comment #14)
> Interesting. Are you saying that the following loops are equivalent?
> while (GetMessage(&msg, NULL, 0, 0))
> {
>     DispatchMessage(&msg);
> }
>
> while (1)
> {
>     PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
>     if(msg.message == WM_QUIT) break;
>     DispatchMessage(&msg);
> }

No, they don't. But once you add a check for PeekMessage return value
they are supposed to do pretty much the same. If you have a look at the
GetMessage implementation in Wine you will notice that it's essentially
a loop around PeekMessage.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

http://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #16 from Nikolay Sivov  2013-03-19 12:27:38 CDT ---
(In reply to comment #13)
> > and message loop based on PeekMessage without
> > WaitMessage will consume all CPU cycles it can get. See also bug 30736, which
> > is caused exactly by this.
>
> It doesn't mean that in Windows it behaves like this.

You have a test application source attached that does not wait for message, if
you run it on windows you'll see.

(In reply to comment #15)
> (In reply to comment #14)
> > Interesting. Are you saying that the following loops are equivalent?
> > while (GetMessage(&msg, NULL, 0, 0))
> > {
> >     DispatchMessage(&msg);
> > }
> >
> > while (1)
> > {
> >     PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
> >     if(msg.message == WM_QUIT) break;
> >     DispatchMessage(&msg);
> > }
>
> No, they don't. But once you add a check for PeekMessage return value
> they are supposed to do pretty much the same.

Test case does check it.
> If you have a look at the
> GetMessage implementation in Wine you will notice that it's essentially
> a loop around PeekMessage.

Yes, with infinite timeout wait.

Is it a five minute argument or a full half hour?

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

https://bugs.winehq.org/show_bug.cgi?id=33235

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download, patch

--- Comment #17 from Austin English  ---
This is your friendly reminder that there has been no bug activity for over a
year. Is this still an issue in current (1.7.37 or newer) wine? If so, please
attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

https://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #18 from Bruno Jesus  ---
Created attachment 54873
  --> https://bugs.winehq.org/attachment.cgi?id=54873
Compiled source example

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

https://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #19 from Bruno Jesus  ---
After reading the bug I can't understand anything, I compiled and opened the
program and a lot of output is printed in the console. Also tested in Windows
XP but I don't know what I should look for. Dmitry, Nikolay?

Is this still an issue in wine 1.9.13 or newer?

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

https://bugs.winehq.org/show_bug.cgi?id=33235

--- Comment #20 from Nikolay Sivov  ---
Yes, it's most likely is. As I remember the problem is that it's actually
supposed to partially break when parent changes. So some handlers are using
GetParent() and some cached window handle.

[Bug 33235] Tab control doesn't notify new parent set with SetParent()

https://bugs.winehq.org/show_bug.cgi?id=33235

Anton Romanov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]