mIRC Home    About    Download    Register    News    Help

Print Thread
Ctrl+break issue #266791 06/02/20 01:05 AM
Joined: Jul 2013
Posts: 25
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 25
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

Re: Ctrl+break issue [Re: kikuchi] #266793 06/02/20 11:09 AM
Joined: Dec 2002
Posts: 4,655
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,655
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.

Re: Ctrl+break issue [Re: Khaled] #266795 07/02/20 10:09 PM
Joined: Dec 2003
Posts: 47
N
NrWarren Offline
Ameglian cow
Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 47
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
scripting environment.

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.

Re: Ctrl+break issue [Re: NrWarren] #266796 08/02/20 07:40 AM
Joined: Dec 2002
Posts: 4,655
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,655
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.

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 globally.

I hope that answers your question.

Re: Ctrl+break issue [Re: Khaled] #266840 Yesterday at 12:32 AM
Joined: Dec 2003
Posts: 47
N
NrWarren Offline
Ameglian cow
Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 47
Thank you for the detailed description. It does make sense.

I have done enough with multithreading myself to know it can be a bother to implement, but does have its rewards.

There is one solution though, i see, that makes sense... and that would be, what if you gave the option, in a
mIRC command-line to remove (or just not add) (or not process) the global CTRL+BREAK hook/procedure.

so like you did with -noreg and -portable :
Code
 mirc.exe -nobreaks


That way we could have the best of both worlds... typical users will be able to enjoy the soft breaks offered by
ctrl+break in its default state.

and then, more advanced users, would have the warning and expectation, that if anything does go wrong in their
script, that they can expect a hard close of the mIRC program. (and to be more careful)

I did manage to circumvent this issue using Windows 10's sandbox, but that it is far from an ideal solution.
as the vm sandbox is a bit clunky to work with.

If none of this is possible, and you still can't entertain the idea above... could you tell me what C function/hook or
registry modification is involved with the global break ?

[Optional Reading, about my mIRC project]
My script i've created, it scans through all the lines in a "workspace folder" , and then it determines how many (if any)
lines have been appended, to give a rough determination of code lines changed. I'm sure i could program all of this in
low-level languages, but i really do enjoy the ease of use of the mIRC interface you've created, and you've made file
handling operations a comfort. All of this comes crashing down though, if when i am working in python and i have to
CTRL+break out of the program, and while i have already setup key handling to work with Ctrl+C , there are inevitably
times that Ctrl+Break is the only way out.

It is curious though that....while you say that mIRC has "global breaks" in the desktop environment, i've noticed that
when certain windows are open, it doesn't seem to be registering the ctrl+break outside of those programs, probably
due to some internal key handling of those particular programs.

Either way, i know this issue has been a pain, but i do think there has got to be a simple fix that would satisfy everyone.
a simple command-line option to remove the training wheels, is one quick fix.

Keep up the good work khaled, lol sorry to bring such an annoying issue to you.
really respect and enjoy what you've created here. Have enjoyed mIRC for almost 20 years now. smile