A possible fix is simply removing focus before disabling control.
I already tried this, along with re-drawing the entire dialog, the control, changing focus, etc. It makes no difference because Windows removes the highlight/underline after a delay.
An application would need to create a timer to handle the N millisecond delay that Windows uses when applying theming once focus is gained/lost, independently from any API calls. The only solution is to wait, let's say, 500 milliseconds after EnableWindow() is called, hope that Windows has already removed the highlight/underline, and possibly caused the display artifact/glitch, and then force a redraw of the control just in case.
Which is not a practical solution :-) In other words, this needs to be fixed by Microsoft. It is, quite literally, a drawing glitch in their editbox theming.
