Tk Source Code

On Windows, ConfigureTopLevel(WINDOWPOS *pos) in win/tkWinWm.c appears to use pos->x and pos->y unconditionally when handling WM_WINDOWPOSCHANGED, even when pos->flags contains SWP_NOMOVE.

Microsoft documents SWP_NOMOVE as meaning that the current position should be retained and the x and y members ignored.

Tk currently does approximately:

winPtr->changes.x = pos->x;
winPtr->changes.y = pos->y;
...
GenerateConfigureNotify(winPtr);

The function does test SWP_NOMOVE later, but by then the stale coordinates have already been copied into winPtr->changes and exposed through ConfigureNotify.

I encountered this while implementing native Windows window movement from a Tk application. Aero Shake provides an unusually reliable reproduction.

During a restore shake I recorded the raw WM_WINDOWPOSCHANGED traffic and the resulting Tk <Configure> events.

A normal final movement looked like:

WINDOWPOS: (486, 177), flags=18453
Configure: (486, 177)

Immediately afterward Windows sent:

WINDOWPOS: (113, 19), flags=6163

6163 == 0x1813, which contains SWP_NOMOVE.

The physical HWND correctly remained at (486, 177), but Tk generated another Configure event reporting (113, 19). Those coordinates were from the WINDOWPOS structure that Windows had explicitly marked as not representing a move.

This can leave Tk's reported geometry inconsistent with the actual HWND position and causes dependent windows which follow <Configure> events to move to the wrong location.

The likely fix is for ConfigureTopLevel() to preserve the existing winPtr->changes.x/y whenever pos->flags & SWP_NOMOVE, analogous to how size handling respects SWP_NOSIZE.

For example:

if (!(pos->flags & SWP_NOMOVE)) {
    winPtr->changes.x = pos->x;
    winPtr->changes.y = pos->y;
}

before generating the ConfigureNotify.

This was reproduced through Python/Tkinter, but the fault appears to be in Tk's Windows window-manager code rather than _tkinter.