WindowFromPoint and ChildWindowFromPoint Not behaving correctly

[Roger Garstang Member Find all posts View Profile Close Roger Garstang]

I'm in the process of making use of these to do multiple things. I started out looking at some old C++ code on Microsoft's website for a neat utility that gets the handle of a listview in another window, allocates a structure in that process' memory, and uses it to transfer the data to the clipboard...I had to modify it for more memory in the clipboard and made it extract two columns to a csv delimited text....but I knew it could be even better in PB of course.

I had to modify how it was getting the handles a lot since I soon found out that the way it was using lParam of the mousemove message didn't work since when the mouse went above or to the left of the window they suddenly jumped up in the 65535 range...I had got them to go correct with mod 65536, then said the heck with it and just used GetCursorPos. I even got it to where it draws a red rectangle around the control with the mouse over it like WinSpector does. I'm running into some other issues now though with getting it to "see" all controls.

Most example code I've found seems to assume WindowFromPoint only gets the Top Level Window/Frame/Form and is incorrect. When I call it I get pretty much any control or Window. WindowFromPoint also doesn't show hidden/disable controls, etc...so ChildWindowFromPoint is needed. Most example code also make another mistake in using this since they use the hWnd from the previous WindowFromPoint call that is often actually a control and not a Window...then call ScreenToClient it then maps the Point structure passed in to the Client of the child control and not the Window that is needed for the call. I can run through a loop with GetParent until I have the parent Window, but then I lose the ability to select Header Controls in a Listview, and child forms/dialogs then can't have any controls selected, etc. I can just getParent once which usually gets me the same results as just using WindowFromPoint by itself.

On top of all those issues, I also have problems where Windows with Frame Controls cause certain controls not to be seen by any of these ways of calling. I'm aware of other languages like Delphi and such hiding the controls pretty well or seeming to dynamically draw them, etc...but these are programs I made with PB and know they aren't child controls of the frame or anything special, so they should show??? I can get every other control, child of a control, window, hidden/disabled control, etc...but these still won't show. Is it a WinXP thing or are these just messed up? Anyone got any code they know works and shows all controls when frames are used?

(What is really weird is I have two frames in one window...both have Labels, Combos, a checkbox, and text boxes...in one frame I can get to all labels, in the other I can't...but can see the Checkbox while the combos and edit boxes neither one will work. Plus WinSpector will see all of them and highlight them.)

[Dominic Mitchell Member Find all posts View Profile Close Dominic Mitchell]

I also have problems where Windows with Frame Controls cause certain
controls not to be seen by any of these ways of calling.

It is because you have not taken the z-order of the controls into account.
You might want to give RealChildWindowFromPoint a shot.

If you want the handles of all windows at a specified point, you will have to use
EnumChildWindows, GetWindowRect and PtInRect. GetWindow can be used to determine z-order.

[Roger Garstang Member Find all posts View Profile Close Roger Garstang]

Awesome, RealChildWindowFromPoint was exactly what I needed! Figures it would be something I wasn't aware of. I guess the Ex functions weren't enough, they had to go and make functions with totally different names! That wasn't in the old .hlp files either, but was online. (The PB versions of the functions are confusing though where sometimes it wants the Point Struct and others it wants pt.x,pt.y format)

This also makes my other improvements work better where I layer my window and make it about mid-level alpha then have nchittest return transparent if I have the mouse captured so controls under the window can be selected...something WinSpector needs to do. Before it only worked through blank areas of my window without controls, now it works for them all. Thanks Dominic! I knew one of you guys would have a solution.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

(

The PB versions of the functions are confusing though where sometimes it wants the Point Struct and others it wants pt.x,pt.y format

So write your own DECLARE statements.

Since the compiler now supports multiple functions sharing an ALIAS, you can even write one version which wants a BYVAL pt AS POINT, and one version which wants X and Y as separate arguments.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

I'm back on my desktop computer again, so I can show what I mean re above "write a second declare"...

Here is what I have done my WIN32API.INC.

'------------------------------------------------------------------------------
'
'  WIN32API.INC -- Win32 API Declarations for PowerBASIC
'
'  Copyright (C) 1997-2005 PowerBASIC, Inc.
'  Portions Copyright (C) 1985-1999 Microsoft Corporation
'  All Rights Reserved.
'
'  Last Update: 27 January 2005
' 02.02.09 MCM added
' DECLARE FUNCTION ChildWindowFromPointAPI LIB "USER32.DLL" ALIAS "ChildWindowFromPoint" (BYVAL hwndParent AS DWORD, BYVAL pt AS POINTAPI) AS DWORD

.....

DECLARE FUNCTION ChildWindowFromPointAPI LIB "USER32.DLL" _ 
   ALIAS "ChildWindowFromPoint" (BYVAL hwndParent AS DWORD,  _ 
    BYVAL pt AS POINTAPI) AS DWORD

DECLARE FUNCTION ChildWindowFromPoint LIB "USER32.DLL"  _ 
    ALIAS "ChildWindowFromPoint" (BYVAL hwndParent AS DWORD, _
         BYVAL x AS LONG, BYVAL y AS LONG) AS DWORD

...

I suppose I could have named the second one "ChildWindowFromPointXY" but since I was already used to "ChildWindowFromPoint" wanting separate "X" and "Y" params (from using prior versions of compiler which did not support "BYVAL X AS {any_udt}) I just left it as "the old name."

MCM