Hello, this issue
is still present in mIRC 7.58.
Depending on how you press the two keys (which order), you can trigger this, I'm not so sure it's the same way as the original way described in this thread.
There is another problem, which may be related, if I let mIRC freeze until windows says 'not responding', then I can no longer break, at all (unless I type control + break from a different application).
I'm on windows 10 and my keyboard is a Logitech K120
Thanks for your bug report. I'm afraid the current behaviour is as good as it can get due to how Windows reports the keys being pressed.
As for your second issue, this was reported here
recently and that too is limited by how Windows reports keys pressed in busy windows.
i realize the issue of freezing has probably come up a lot in the history of mIRC scripting,
and at this point you are probably just done with changing anything about it, because of how
finicky of an issue it is.
However, i still believe we could address the issue in another way... I mean, the core reason for
why we get "Not responding" issues at all, (if i understand it correctly), is that we're not giving a
chance for the Windows API to "breathe", which is why someone had come up with a DLL several
years ago, that would make a periodic call back to Windows API and it seemed to fix the freezing issue.
I think the best solution though, would be to have an internal counter for each `While` function, and after
every 10 or 50 calls, just do a callback to the Windows API, and in this way, i think it would throttle the
and if you don't have to worry about the scripting environment crashing mIRC, then you can go back to your
original method of locally checking for Ctrl+Break (instead of globally)
an alternative might be, you could set something up in "Options", to let users decide how mIRC
will handle the ctrl+break, whether they want to sacrifice scripting speed, for scripting stability.
i understand though, if you don't consider this issue a priority.
Thanks for your comments. Your suggestion has indeed been discussed before.
It is not possible to implement what you are suggesting because the scripting language is tied directly into the GUI. If a GUI event is triggered, the scripting language must be triggered immediately because GUI events must be processed at the moment that Windows sends them.
If a PeekMessage() (or any API is called that allows Windows messages to "breathe") is called (which is something that was done some versions ago for Control+Break and was reverted due to this exact issue) this causes Windows messages to be processed, resulting in the above issue.
There is no way to trigger a script immediately if one is already running as that would then lead into the far more complex issue of running multiple scripts simultaneously. This is not possible because the scripting language was intended to be single-threaded.
Multi-threading requires a completely different mindset when developing software and needs to be implemented from the ground up. There is no way to retro-actively change the scripting language to be multi-threaded.
All of this means that mIRC cannot process GUI events while a script is running.
In fact, no windows events of any kind can be processed while a script is running because many of them can trigger other script events.
It is also not possible to selectively process specific windows events without causing other issues.
And this in turn means that mIRC must process Control+Break the way that it does currently.
To summarize, so that we don't go around in circles: when mIRC, a single-threaded application, is running a script, Windows freezes its GUI and prevents it from detecting whether it has focus or not. While a script is running, the only way for Control+Break to work is for mIRC to poll the keyboard state (using GetAsyncKeyState() and not Windows messages, which cannot be used due to re-entrant threading) for Control+Break, regardless of whether mIRC has focus or not, as there is no way to detect this.
I hope that answers your question.