Forums Bug Reports Style editbox enable/disable

Hi Khaled,

When we have an edit box, it can be enabled/disabled via code, e.g.:

I found something that I'm not sure if it's a bug. When the edit box is enabled and we have the cursor inside that window, if we disable the edit box, the style of the edit box changes.

I also discovered that whether we leave the edit box empty or not, the style also changes. Sometimes it's random, the style sometimes doesn't change, sometimes it does.





The same happens with the mIRC edit boxes:

When dialog is opened::



Dialog box with edit boxes enabled:



Dialog box with edit boxes disabled:



Dialog that appears when the cursor is active in the last edit box:



Dialog box displayed when we disable the edit boxes:



Sometimes it's random. It changes the style in some edit boxes and not in others:



I'm using beta version 7.83.3857, but I checked the released version 7.83 and some previous versions, and this problem occurs in all versions.

Thanks for your bug report. I have not been able to reproduce this here so far. I tested your script, and the Options dialog Nickname section, on several different Windows installations. mIRC is using the EnableWindow() API, which is a basic API used to enable/disable controls. The way the control is re-drawn in this case is handled by Windows. This API is used in many places in mIRC, and has been for decades, and I have never heard of an issue with it before. I cannot think of a reason why this would happen, apart from perhaps a Windows graphics driver issue.

Unfortunately, it's not a driver issue, because I've already tested it on 2 different PCs with different hardware, and the same thing happens. I detected this problem more than 3 years ago, but I never reported it because I hoped that one day you would notice the problem.

To reproduce the problem correctly, you need to enable the edit box, place the mouse cursor in the edit box, and then disable the edit box.

Sometimes it can happen randomly, but most of the time it does.

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.

This display issue is also present in my Windows 7 Ultimate x64 install but to a much lesser extent as it only affects the edit box if it has focus (is showing the caret) when its disabled, the system seems to be drawing the control in a `disabled with focus state` which is odd.

A possible fix is simply removing focus before disabling control.

(Microslop appears to have made things worse in 10/11)

I can reproduce this issue on win10 mIRC 7.82

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.

The only way I found that works and solves the problem is this:

However, this is not a perfect solution and may fail in some circumstances.