therefore it is impossible, under any version of Windows, for mIRC to see the WM_CLOSE while the loop is running, is that not correct?
That should be the case but... I just checked and it isn't. mIRC is actually processing SendMessage()s, even during a busy script. After looking into this a little more, I found the cause: some versions ago, a user reported that when mIRC was busy, eg. running a long script, for more than a few seconds, Windows 10 was treating mIRC like a hung application and was preventing users from minimizing mIRC. This is different to how previous versions of Windows behaved. To get around this, I tried a number of different methods, all of which had side-effects, and finally settled on using PeekMessage() with PM_NOREMOVE and PM_NOYIELD to let Windows know that mIRC was still "awake".
17/07/2015 - mIRC v7.42
15.Changed script processing method so that Windows no longer thinks mIRC has stopped responding during long loops.
Unfortunately, it turns out that calling PeekMessage(), even without processing messages, causes Windows to trigger SendMessage()s processing. So it now looks like I will have to revert this change.
