Forum > General

CRT unit kills Ctrl-C - SOLVED

(1/3) > >>

The simple problem: If I add Crt to the uses list, the program does not receive Ctrl-C and hence an infinite loop cannot be stopped.

A bit more details:
I am writing a linux terminal program that first switches to an alternate screen and there runs in a loop until Ctrl-C is pressed when it returns to the normal screen. To achieve this I use the #27'[?47h' and #27'[?47l' sequences to actually switch between the normal and the alternate screens and the fpSigAction from BaseUnix to capture the Ctrl-C and do the switching back before exiting the program.
This works almost perfectly, the only problem that when I return to the normal screen then the cursor position is not where it was on the normal screen, but where it is last seen on the alternate screen. I tried to fix it, and added the Crt unit (WhereX, WhereY, GotoXY), what works as intended, but then the Ctrl-C is not working any more.
I  tried even without the fpSigAction, just a normal infinite loop and Ctr-C does not work when Crt is in the uses list.
I found in the documentation a CheckBreak variable, but it says that it is not used.

I would need a solution, either to allow Ctrl-C when Crt is used OR get and set the cursor position without using Crt at all.

I can't comment on the Crt finalisation issue (which sounds like a bug to be fixed), but the ^C problem is that the input device is being set to "cooked" mode and you need to partially undo that, i.e. take it to a state that we can usefully call "rare" as distinct from the original "raw".

See e.g.


Welcome to the weird world of CRT. CRT switches the terminal input to RAW mode and then tries to emulate buffered mode, to pretend it didn't (and this is the source of alot of confusion, by people who think they just use some "normal" functionality). This will result in hotkeys being sent to your application (as keycode, in case of CTRL+C it's #3) rather than triggering events.

I don't know how CRT passes these keycodes to your application, but you can just try to read the input


Checked it and indeed it works like that. However the control characters to switch to and back from the alternate screen do not work. I guess it is again, because it is in Raw mode, and the Crt unit does not implement the concept of an alternate screen. So, to use the alternate screen mode, I need to drop Crt, but I do not see how to get then the cursor position. (The GotoXY I can easily implement.)

As above I give up CRT for this purpose. Any other idea to "read" the cursor pos I would appreciate.

So how CRT works is that it internally creates a buffer that emulates the complete state of the terminal. Meaning if you write something, it internally emulates how this writing would change the cursor position, and uses this to track the "WhereXY". As soon as you switch the screen, the new screen does not match with the CRT buffer anymore, and therefore CRT will break down at this point.

You can checkout the XTerm ANSI Escape Codes:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---CSI Ps n  Device Status Report (DSR).            Ps = 5  ⇒  Status Report.          Result ("OK") is CSI 0 n            Ps = 6  ⇒  Report Cursor Position (CPR) [row;column].          Result is CSI r ; c R           Note: it is possible for this sequence to be sent by a          function key.  For example, with the default keyboard          configuration the shifted F1 key may send (with shift-,          control-, alt-modifiers)             CSI 1 ; 2  R , or            CSI 1 ; 5  R , or            CSI 1 ; 6  R , etc.           The second parameter encodes the modifiers; values range from          2 to 16.  See the section PC-Style Function Keys for the          codes.  The modifyFunctionKeys and modifyKeyboard resources          can change the form of the string sent from the modified F1          key.
So if your terminal supports that (most XTerm compatible terminal emulators should do), you can just send #27'[6n' and then read the output sequence


[0] Message Index

[#] Next page

Go to full version