Yes, it can be done to some extent, but my point is, You can hardly compile a TP program that uses the CRT unit. You can compile these in FPC (in linux anyhow) with no problem, and in VPC, and in Pure Pascal with no problem. But delphi is another story, no textcolor, etc. Perhaps this is more of an oversight in delphi itself, than in the Win32 API, but 3rd party developers making CRT units for the win console have run into problems with the Win console API. There is even a quote on the Lazarus pages from a database developer who was trying to port a unix application (with a console interface) to windows, and had spent quit e a lot of effort, with little outcome. I have my own solution: I have a CRT unit which dummies out almost every function, just so I can compile things on Delphi 4, without having to change the source. Of course, I loce the colors, etc. this way, and some things (like gotoXY) will be very broken, but hey, it compiles ;). I hate to load up a program I did in FPC/Linux or PPC/TOS, and have it not even compile because of a few textcolor()'s I have in my source.
More to the point - Is there is a Proper CRT unit for FPK for the Win32 console that I could be using? If there isn't, I can offer my dummied out one, or one I have that uses ANSI/VT codes to do the color changes and repositioning. (that one is designed for Atari, but... may have some use on PC...).
While I'm on the subject, I have recently started to run some apps from said Atari, compiled with Said CRT unit, over telnet, from other machines, and the display gets very messed up (as the telnet client is normally not using the same emulation). Is there a better way to do this? Does anyone know how the FPC Linux CRT unit works? Perhaps I should have a look at it if nobody does. I designed my VT-CRT unit to work only locally for the standard (on that machine!) "ST52" emulation.
thanks,
noah silva
Jeff Wormsley wrote 42 lines
On 03/07/2001 at 1:19 PM Noah silva wrote:
>he he he
>I think you are going to be rather disappointed with the Windows Console
>API. It seems as if they purposely made it crappy. Just look atround for
>the better delphi 4 console libraries. You will see frustrations of
>authors, as well as what options are/aren't available.
It's not -that- bad, but it can be tedious. I ported some 16-bit BP code to a Delphi console app that used a homebrew windowing library that was based on direct screen writes. There is a windows console equivalent to direct screen writes that allows you access to the screen buffer. The important routines are:
ReadConsoleOutputAttribute
WriteConsoleOutputAttribute
ReadConsoleOutputCharacter
WriteConsoleOutputCharacter
ReadConsoleOutput
WriteConsoleOutput
GetConsoleCursorInfo
SetConsoleCursorInfo
AFAIK, all of these functions have been implemented in FPC. I did find a quirk in the Delphi implementation. The TCharInfo structure wouldn't work correctly for some of the calls, and I had to declare the following type to make it work:
TFixCharInfo = Record
AsciiChar : Char;
Dummy : Byte;
Attributes : Word;
End;
I don't know if that's the case for FPC or not.
Combined with one of the free WinCRT's out there it worked fairly well. I also had to write a translator for the keyboard scancodes, but that was fairly simple.
Unfortunately, that code is owned by my employer, so I can't release it.
HTH,
Jeff.
_______________________________________________
fpc-pascal maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-pascal