>>Do you happen to know why setting the .Top results in value different if you try to read out afterwards? Some kind of default offset? And assigning .Top also resets .Left to a new value ? From which point is that setting calculated after the Browse command, which in simple tests show it at 0,1 ? Seems location of _vfp.top, _vfp.Left plays a role in that calculation whenn assigning, but not tested in earnest.
>
>Actually no, didn't even try it this time, until I tried your code :). But I did try the "in macdesktop" on other windows before, e.g. tried to keep a text editor floating around, but gave up on it because it doesn't see the system menu, so keyboard shortcuts for clipboard don't work.
>
>Looks like it has an _assign method which accepts values relative to desktop itself, and _access method which returns values relative to _vfp. In my case, the difference was -95, i.e. as if there were 95 pixels above _vfp. Which is surely not the case, there's only about 20-25 px up there (I have a system toolbar of that size on top). The funny thing is that .left goes from 0 to -12 as well, and I have nothing on the left. Very weird and I wish I knew what's going on.

Don' think there is an _access, as mousemoving and assigning _vfp.top does not change reported values if no assign of oBrw is called in between
? "Screen: " ;
+ " T:" + PADL(ALLTRIM(STR(_vfp.Top)), 6);
+ " L:" + PADL(ALLTRIM(STR(_vfp.left)), 6) ;
+ ", BRow ";
+ " T:" + PADL(ALLTRIM(STR(m.obrw.Top)), 6);
+ " L:" + PADL(ALLTRIM(STR(m.obrw.left)), 6)

Repeatedly setting the same top value to the same value witout moving _vfp gives stable oBrw.top, but on each iteration recalcs .left, so by setting .top in a loop you can move the browse horizontally ;-)
same goes for .Left, it resets .Top while staying at the offsetted value
Checking top:
X-_vfp.top+parameter, with X=73 when zerobasing tests