Updated 2014-01-13 19:53:58 by dkf
winfo containing ?-displayof window? rootX rootY

Returns the path name for the window containing the point given by rootX and rootY. RootX and rootY are specified in screen units (i.e. any form acceptable to Tk_GetPixels) in the coordinate system of the root window (if a virtual-root window manager is in use then the coordinate system of the virtual root window is used). If the -displayof option is given then the coordinates refer to the screen containing window; otherwise they refer to the screen of the application's main window. If no window in this application contains the point then an empty string is returned. In selecting the containing window, children are given higher priority than parents and among siblings the highest one in the stacking order is chosen.

LV 2007 Jan 31 This question relates to Tk 8.5.x.

I run the following code and don't understand the output, based on the above info.
$ tclsh8.5
% package require Tk
8.5.1b1
%     toplevel .t -width 200 -height 200 -bg green
.t
%     wm geometry .t +0+0
%     frame .t.f -width 150 -height 150 -bd 2 -relief raised
.t.f
%     place .t.f -x 25 -y 25
%     tkwait visibility .t.f
%     set result [list [winfo containing 100 100]]
.t

Shouldn't the result of the winfo be .t.f ? It is the child, which supposedly has been given a higher priority. It was created later, so it should be stacked higher. When I look at the window displayed, I see the raised frame on top of the green toplevel.

So, why doesn't winfo report back .t.f?

KD: On my system (Linux) it reports .t.f

Ah, on my Windows XP Hummingbird Exceed X server 10.x, displaying Tk 8.5 running on a SPARC Solaris 9, it does not. So, does that make the problem an X server problem?

DKF: This is invaluable when you are implementing drag and drop, as you don't get <Enter> or <Leave> events when dragging (because of the automatic pointer grab during a click).


See also edit