I've done some tests. I think you can use _SCREEN.Top, Left, Width, Height. Please tell me when it doesn't work, if it doesn't.

Vlad

>Vlad,
>
>Thanks for your suggestion. I suspect that this will be the best approach I can find until Microsoft gives us the VFP function I'm asking for (I don't think I'll hold my breath). There is a further complication, however, because FoxPro's system toolbars don't show up in _screen.forms collection. Now I realize that I can test for each one by name to cover these cases, but this is getting pretty involved and inefficient. Performance is important here, because I need to do this calculation in response to frequent form.moved events.
>
>Mike
>
>>I don't know a simple solution. But if you can get the ClientRect coords regardless of toolbars, you can write your own function to calculate the real ClientRect with toolbars. Toolbars appear in the _SCREEN.Forms collection. There are some test to do/code to write, but I think is doable without many complications.
>>
>>Vlad
>>
>>>(I also posted this message to newsgroup microsoft.public.fox.programmer.exchange)
>>>
>>>Visual FoxPro appears to provide no easy way to determine the "real" width of the borders of the main VFP window or a top-level form. Futhermore, the Win32API functions (e.g. ClientToScreen, GetClientRect, etc.) don't solve the problem either. What would really help here is a VFP function that returns the displacement of a window's interior origin relative to its exterior origin. (I hope someone at Microsoft is listening.)
>>>
>>>The sticking point is the problem of dealing with toolbar docking variations. In VFP, the intra-window coordinates are automatically adjusted to compensate for toolbar docking. I.e. the origin moves when a toolbar is docked at the top or left edge of a window. As far as I can tell, there is no simple, general way to determine the top or left border width in such a way as to account for toolbar docking. I can determine the extent of a window's interior by using WROWS() and WCOLS() + FONTMETRIC(), but this doesn't tell me the displacement of the interior origin, because toolbars may or may not be docked on any side of the window.
>>>
>>>It looked as though the Win32API function, GetClientRect, was just the ticket. It converts intra-window coordinates to absolute Windows desktop coordinates. Unfortunately, my tests indicate that GetClientRect doesn't take VFP toolbar docking into account! This is easy to confirm by seeing if the interior origin (0,0) moves when a toolbar (e.g. VFP's Standard toolbar) is docked or undocked at the top or left edge of the main VFP window. It doesn't. Here is the code I used for a VFP wrapper function on Win32API's GetClientRect to test this:
>>>
>>>********************************************************************
>>>
>>>function hwtodesk
>>>* returns a success flag.
>>>
>>>parameters hwnd_arg, x_arg, y_arg && takes 3 required arguments
>>>* hwnd_arg: the (top-level) window handle, as returned by hwget.prg.
>>>* x_arg: input value is the horizontal intra-window coordinate.
>>>* This must be passed by reference, so that it can receive the
>>>* output value, giving the x coordinate relative the Windows desktop.
>>>* y_arg: input value is the vertical intra-window coordinate.
>>>* This must be passed by reference, so that it can receive the
>>>* output value, giving the y coordinate relative the Windows desktop.
>>>
>>>DECLARE INTEGER ClientToScreen IN win32api INTEGER, STRING @
>>>
>>>local result, pointstruc
>>>
>>>* set up structure to be passed to ClientToScreen by assembling proper sequence
>>>* of bytes, with least significant bytes first on Intel processors
>>>pointstruc = chr(mod(m.x_arg, 256)) + chr(mod(m.x_arg, 65536)) ;
>>> + chr(mod(m.x_arg, 16777216)) + chr(mod(m.x_arg, 4294967296)) ;
>>> + chr(mod(m.y_arg, 256)) + chr(mod(m.y_arg, 65536)) ;
>>> + chr(mod(m.y_arg, 16777216)) + chr(mod(m.y_arg, 4294967296))
>>>
>>>* invoke the ClientToScreen Win32API function, passing structure by reference
>>>result = ClientToScreen(m.hwnd_arg, @pointstruc)
>>>
>>>* unpack results that were put into the supplied structure into args passed by ref
>>>x_arg = asc(substr(m.pointstruc,1,1)) + asc(substr(m.pointstruc,2,1)) * 256 ;
>>> + asc(substr(m.pointstruc,3,1)) * 65536 + asc(substr(m.pointstruc,4,1)) * 16777216
>>>y_arg = asc(substr(m.pointstruc,5,1)) + asc(substr(m.pointstruc,6,1)) * 256 ;
>>> + asc(substr(m.pointstruc,7,1)) * 65536 + asc(substr(m.pointstruc,8,1)) * 16777216
>>>
>>>return (m.result # 0) && return success flag result - other results returned by ref
>>>
>>>********************************************************************
>>>
>>>To get the window handle, I used this:
>>>
>>>function hwget
>>>* returns the window handle (HWND) numeric value for the active top-level window.
>>>
>>>DECLARE INTEGER GetActiveWindow IN win32api
>>>
>>>return GetActiveWindow( )
>>>
>>>********************************************************************
>>>
>>>If anyone can suggest a reasonable solution to my problem, it would be much appreciated. Otherwise, I hope that Microsoft will take note of this omission and provide suitable VFP function(s) to make this possible. It should be easy for VFP to do this internally, and it's practically impossible to compute this basic window attribute as it stands.