Originally posted by qzwqzwtest at 2007-2-6 03:45 PM:
Problem of infinite loop
I tried with IE6, and indeed, I can press Ctrl+C in real time
However, switching to Opera 9.01 still ignores my keystrokes
Finally, I upgraded Opera to version 9.10 8679 multi-language version
The result didn't change much
Maybe it's because of the difference in my network or system configuration from yours
However, since it's indeed an Opera compatibility issue
We can just ignore it
Wait for Opera to improve itself...
Let me explain in detail the current handling of the problem of forcibly interrupting with Ctrl+C.
Indeed, the judgment of Ctrl+C and Ctrl+Break keys under different browsers is somewhat different under unexpected situations (not in normal states). For example, under Firefox, their key values are Ctrl+99; under Opera, the key value of Ctrl+C is Ctrl+3, and the key value of Ctrl+Break is Ctrl+67; while under IE, the key value of Ctrl+Break is Ctrl+3, and Ctrl+C does not return a key value. Therefore, in order to support browsers including IE, Firefox, and Opera, from the very beginning of adding this function, we have to detect the user's browser and judge the keys accordingly (including using some special methods), so that finally the Ctrl+C and Ctrl+Break keys can interrupt the program under my IE, Firefox, and Opera.
Theoretically, since in my Opera (version is also 9.10 8679) on my computer they can interrupt the program, they should also be able to do so on other computers. For better testing, just now I specially installed a brand-new Opera 9.10 8679 multi-language version in VMware virtual machine (my real machine has the English version), and after testing, I found that the Ctrl+C and Ctrl+Break keys can also interrupt the program normally. Therefore, for the above-mentioned problem, I don't think it's a problem with Opera itself, but may be caused by other reasons (such as setting problems? Plugin conflicts?).
However, the language version reminds me to add a new function, that is, automatically select the corresponding starting code page according to the default language of the browser. Now it supports that when the default language of the browser is zh-cn/zh-sg/zh-chs, the starting code page is 936, when it is zh-tw/zh-hk/zh-mo/zh-cht, the starting code page is 950, otherwise the starting code page will be 437. But you can still manually specify the starting code page with the?cp=xxx parameter, and you can use the %codepage% environment variable to judge the current code page.
There is no upper limit for the forum's topic subscription function, so the net file command also has no file upper limit; and the upper limit of the user's short messages and the current number of short messages can now be listed with the net user command.
Regarding the functional overlap between type and more. In fact, this is also reflected in some existing environments, and even more obviously. For example, in Windows "Recovery Console", the functions of the two are exactly the same (and the more command cannot be used for pipeline operations). Under DOS/CMD, the type command has no switches, and its more command is similar to the more command in the current command line interface (except that it does not support pipeline/redirection operations). If a switch to control pause is added to the type command, it seems to go against the original intention of the division of labor between the type and more commands under DOS/CMD. At the same time, considering that pipeline operations are quite complicated to implement, and it is difficult to guarantee whether it is feasible (note that support for I/O operations is a weak point of web scripting languages), so it may be better to adopt the current division of labor.
If there are no problems, the official version will be released within one day.