[fpc-pascal] CRT unit and Windows' terminal
Stefan V. Pantazi
svpantazi at gmail.com
Sat Oct 14 20:55:53 CEST 2017
I had a similar problem when trying to represent trees using extended ASCII
characters. My solution was to adapt my character representations to UTF8.
To see what I mean you can have a look at
generate_catalan_monoid.pp contains a PrintASCIITree function that does the
obvious. The examples folder contains actual outputs (e.g.,
examples/n_5_output_example.txt) of ASCII trees such as this one (I pasted
it here but may not survive the message):
On Fri, Oct 13, 2017 at 9:39 AM, James Richters <
james at productionautomation.net> wrote:
> >I want to create console app that's using box drawing characters from
> unicode. Before CRT unit is used, it's all fine and my program could draw
> >table beautifully. But once I put CRT unit, those characters became
> garbages. But strangely, it's only happen on Windows' terminal (win10).
> >I tried the same exact program in Mac and Linux, using each CRT unit, and
> they all run fine. I need CRT unit to make my console program more
> >interactive (i.e. cursor positioning, keyboard handling, text coloring,
> >So, what's wrong with CRT unit on Windows? Can anybody explain the
> strange behaviour and how to solve the problem?
> From my own failed attempts at getting box characters to work with both
> crt and ptccrt I can confirm that it’s not working in windows, but I am
> actually very surprised to hear it’s working on Linux and Mac. Perhaps
> there is a possibility to fix the CRT unit on Windows.
> In my opinion, the CRT unit SHOULD be drawing boxes with the ORGINAL
> Extended ASCII codes, not Unicode, at least by default.
> The CRT unit is supposed to be compatible with the original turbo pascal
> CRT unit, and in turbo pascal if you writeln(Chr(201)) you get a upper left
> corner, not a funny looking E, Perhaps there could be an option to use the
> unicode characters, but displaying the correct ASCII characters should be
> the default. Unfortunatly it’s not doing either correctly… if it’s going
> to use Unicode it should use the entire character set, if it’s not going to
> do that, then it should be using extended ASCII as the original CRT unit
> The strange thing is, my ancient turbo pascal program that draws ACSII
> boxes, looks fine in the FPC Text mode IDE, (which itself uses box
> characters!) but when running the program, even while in the same console
> window that FPC text mode ide is currently running in, I get the unicode
> characters. If I’m in the textmode IDE and I enter a character sequence
> of ALT+201 I get the upper right corner symbol, not a Unicode symbol… but
> run the program, and I get the Unicode sysmbol. If I don’t use the CRT
> unit, I do indeed get the full Unicode character set, but then you can’t
> use cursor positioning etc…
> I have tried to replace the ASCII characters in my program with the
> Unicode characters, but I can’t because they are so far out in the table,
> they are beyond the 255 character limit of the CRT unit; For example an
> upper right corner character used to be #201, now it is #9556. I can’t
> find any way to display #9556 with the CRT unit, I‘ve tried
> Writeln(Chr(9556)) but chr() has a limit of 255, and I’ve tried just
> Writeln(#9556) and while that compiles and runs, it doesn’t produce the
> correct character.. I have a feeling (but have not tested it) that it keeps
> cycling around the first 256 characters if you use anything above 255…..
> pretty sure a character is defined as a byte here.
> I have attached screen shots and a sample program that demonstrates this
> frustrating situation. I have simply abandoned a quite a few really good
> console applications because of this.
> Box characters are great, I don’t understand why it’s become so difficult
> to incorporate them. But I’m really hoping a solution can be found as I
> have reports I display in console windows, even on my graphics programs
> that would be so much nicer if I could use box characters again, since I
> make use of the console window while the graphics window is also open.
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-pascal