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, I finished my extended tests and they are contradictory.
1. Yes, WindowFromPoint searches recursively on random depth, both in Windows and WINE. I was totally wrong about this. Excuse my ignorance.
2. But WindowFromPoint still does not work properly in my drag&drop patch. The problem is that WindowFromPoint fully ignores the STATIC controls (documented and correct behavior), but in Windows the STATIC controls are valid drop target if they have WS_EX_ACCEPTFILES set.
This way, the implemented in the patch "window_from_point_dnd" function correctly returns the STATIC windows drop targets. Comparing with the original Windows behavior, I can't see any differences.
(I will attach the improved test application I used, now it has STATIC as a drop targets and WindowFromPoint test tool as well.)
So, the question is what to do now?
Regards.