Behavior of EnableWindow since last MS Upgrades
Original Reporter info from Mantis: BrunoK
-
Reporter name:
Original Reporter info from Mantis: BrunoK
- Reporter name:
Description:
The recent upgrades of Windows 10 have changed the notification of WM_ENABLE by sending WM_ENABLE notification to HWND's even if their WS_DISABLED has not changed.
The new behaviour provokes an recursive avalanche of WM_ENABLE in/by TWindowProcHelper.DoMsgEnable that slows programs that have many embedded WinControl's. There we mean a FormCreate taking 10's of seconds instead of some 100's of milliseconds.
The problem is due to the way EnableWindow is called.
Steps to reproduce:
Not blocking, but annoying, when Tools->Options... is clicked. For a nastier situation see report #33705 (closed)
Additional information:
This problem appears suddenly when latest Windows 10 upgrades get applied. Any stable distribution above 1.4.4 will show this change when Upgrade Windows 10 1803 install itself.
Changing the Compatibility of the .EXE settings to XP mitigates the problem but is not a lasting solution.
The submitted patches change the way toggling TWinControl.Enabled are handled. New state in EnableWindow is proactively applied to children instead of responding to WM_ENABLE message.
It is, I think, compatible with any Windows > XP and in case of success should be also applied to the stable release and not only to Trunk.
Mantis conversion info:
- Mantis ID: 33923
- OS: Windows
- OS Build: Win10
- Build: All versions > 1.4.4 under W10
- Platform: Any compiled
- Version: 1.4.4
- Fixed in revision: 58448 (#9733fa84), 58497 (#1a0431a7), 58511 (#e1030098), 58912 (#c17527dd)
- Monitored by: » kpp (kpp), » luizamerico (Luiz Americo), » @PascalRiekenberg (Pascal Riekenberg)