On 4/18/19 9:19 PM, John Found wrote:
On Thu, 18 Apr 2019 12:53:35 -0500 Zebediah Figura z.figura12@gmail.com wrote:
On 04/18/2019 12:35 PM, John Found wrote:
On Thu, 18 Apr 2019 12:09:02 -0500 Zebediah Figura z.figura12@gmail.com wrote:
Really? I'm looking at this test right here:
https://source.winehq.org/git/wine.git/blob/refs/heads/master:/dlls/user32/tests/win.c#l9398
Well, yes, I am wrong about the WindowFromPoint, but still only the first level of the children is checked.
The mentioned test checks exactly this in 3 cases:
- Main window without child created - main window returned.
- Main window with single STATIC child created - main window returned. (correct, according to MSDN)
- Main window with single BUTTON child created - the child returned.
There is no child-in-child cases (and IMHO, should not be).
Really? Why not? Our implementation is recursive, so it should return the deepest child. If it's wrong, we should add tests to prove it.
Well, if I understand correctly, WindowFromPoint in WINE should work the same way as in Windows. I don't have Windows machine right now, but will test tomorrow how exactly WindowFromPoint works. This test will show whether the discussed behavior is bug or not...
Right now, I can only say, that drop targets in WINE are searched different than in Windows (the test from my previous email) and this is what my patch fixes...
This might be an interesting read: https://devblogs.microsoft.com/oldnewthing/20101230-00/?p=11873
Do you test with disabled child windows? Because that's one case where WindowFromPoint fails, it won't check deeper child windows even if they are active in this case. Not sure if Windows treats it differently here.
BTW I'm not sure about this but I think GetAncestor(hwnd, GA_PARENT) is more appropriate since GetParent can also retrieve the owner window, not sure if that's a factor here, but seems safer to me.