

When writing filters and the like since the code is totally unambiguous.įilter programs which give no visual feedback to the user are veryĭisconcerting, to say the least. I have found it good practice to adopt the conventions of C programming Which is precisely the way TP/BP initialises when using the CRT unit. "stderr" on handle 2 is ALWAYS to the display and has no namedĮquivalent in TP. "stdout" or "output" is redirectable on handle 1 and is equivalent to: "stdin" or "input" is redirectable on handle 0 and is equivalent to: most common) way of handling the files is as follows: Devices in Turbo Pascal -> The System Unit. The subject of I/O redirection is fully explained in the TP manual inĢ. Additionalīill Boulton has sent me more information (), with Unit that will redirect output using variables of type text. Using an ANSI driverĪfter Osmo Ronkanen : If your screen is set to respond toĪNSI codes then you can have, for example :-īegin str(X,m1) str(Y,m2) Write(#27'['+m2+' '+m1+'H') end īegin Write(#27'[H'#27'[2J') end (* if not FAR, use bp+4 *)

Of course, TV, TD, DPMI, BREAK, CONTINUE, asm.end,Īnd other novelties. Turbo and/or TPC can even be installed as a Tool in the TP7/BP7 IDE, Turbo Pascal Version 5.0 to compile instead of TP7. (or just to be right), then it is worth considering the use of If the sole problem is that TP7 Crt initialisation fails RTE 200,Īnd it is not actually necessary for Crt.Delay to be used (c) the initialisation section, in TP7/BP7,ĭirectory) for Delay exist, and there are replacement units īut one may prefer not to use Crt if it can be avoided.įor Crt routines, including Pedt Scragg's replacement

(b) on machines which are too fast for its (version-dependent) design,

(a) it is one monolithic section, not splittable by smart linking The Crt unit, as delivered, is not altogether ideal.
