>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, etc). >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 did. 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. James
ascii box.pas
Description: Binary data
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
