Interesting issue. I was able to reproduce this by clicking in the editbox first. As far as I can tell, it's a Windows 10/11 bug.
In Windows 10/11, when you click in an editbox, Windows highlights the border of the editbox (and in the case of Windows 11, it displays a blue underline in the editbox as well). When the editbox loses focus, such as when EnableWindow() disables the control, there is a small delay before Windows removes the highlight/underline. The highlight/underline theming feature in Windows 10/11 seems to work independently from the APIs and repaints the editbox a short time after the window is loses focus.
When an application uses EnableWindow(), even if it resets focus to another control first or forces a control redraw/repaint, this makes no difference. Even redrawing the entire dialog makes no difference. The control is still updated incorrectly N milliseconds later by Windows. An application would have to set up a timer for every call to EnableWindow() to redraw the control after N milliseconds, which is whatever delay that Windows uses before adding/removing the highlight/underline when focus is gained/lost.
This issue needs a Windows fix.
