Having just finished 3 solid days of working through printing problems, I thought I would share some of what I have experienced and found out.

1) This is about printing from within a True Basic program.

2) The standard Open #4: printer, print #4: "This is a test", close #4 method can produce complete chaos on today's computers.

3) As examples: I had inserted a simple printing test into 3 separate programs. The subroutine was basically as displayed above (printing about 10 lines), and was error trapped. The EXACT SAME routine was in each of the three programs (actually copied from one to the other).
a) Running from the EDITOR all three worked.
b) After binding all three, only one bound version worked. The other two simply stopped the running program with no errors displayed.
c) Working with the non-working programs I found that 4-5 lines would print but if another line was encountered--the whole program failed--again in bound mode.
d) Somehow I did get one of the failing programs to work in bound mode--until I moved the bound program to a desktop folder. Then it failed.
e) However, I could copy the whole folder to the C:\ drive and then it worked.
f) I couldn't get the 3rd program to print more than 4 lines (had to only have 4 lines to print). Any more and the program would quit without printing any.


4) I have found one. Abandon the printing technique above and use CALL TC_WIN_PRINT(window-id) instead, normally preceded by TC_WIN_PAGESETUP(window-id) to give a printer selection dialog. This now seems to work across machines AND EVEN ON OUR SCHOOL NETWORK (where nothing ever seems to work).

5) To use this technique there are limitations. You have to display the text you want to print in a window before making the calls above. This may necessitate multiple screens of text to get all one wishes to print done. However, it really does seem to work.

6) ADDED (2-15). A good way to do this, as I just realized, is to setup an unviewed window (do that all the time with animations) and output the material to be printed there. One call to TC_WIN_PAGESETUP might be wanted, but after that you can print a window full of material, clear that window, fill it with more, call TC_WIN_PRINT again and so on. Other than the printer selection dialog box, all the rest would be invisible to the user. The one remaining problem here is getting good formatting on the printed output. You will get a hard-copy of the screen image (including graphics by the way), but that image may be small compared to the sheet of paper. Not sure if this can be controlled.


I have one printer that currently believes that some of the ink cartridges are expired and/or empty. I CAN print with most other programs, but TRUE BASIC seems to be unable to communicate with this printer while it is in this mode. Even the EDITOR with its print utility is ignored (like nothing actually gets to the printer). So beware and change out your cartridges and for those printers that sense the age of cartridges, using expired or refilled ones may be problematic with TRUE BASIC.

(ADDED 2-15) Just replaced all cartridges in this HP printer and now printing is back to 'normal'. This was NOT the printer involved in the bizarre behavior listed in (3) above!)


Rick Tarara


Hi Rick, The reason why you

Hi Rick,

The reason why you can print from the editor but not from a bound program is that the editor uses as third party freeware program called PRfile32.exe. As you know, the editor originally had many problems with printing (mainly with HP printers) so the third party software was used to get around this problem. If the bound program chains to PRfile32.exe, then it too will print correctly.

The editor also uses another third party freeaware program called hardcopy.exe which allows users to print from the default output window (a little green icon appears in the top right corner of the output window). Hardcopy works the same way as TC_win_print, i.e. it converts the screen into an image and prints that. In this way you can print graphics too.

I have always used Epson Printers so I don't get any of these printer problems. My printer works with OPEN #1: PRINTER as well as PWlib for graphics, and of course with PEfile32 and Hardcopy.


re: printing

Hi John,

Well aware that printing program listings inside the editor uses the third party software--but I was describing printing initiated from within a program. There the OPEN #1: PRINTER technique would work when running the program from within the editor but not (consistently) when running from the bound version. As noted in my post, problems with this behavior (and yes probably with HP printers, but there are a hell of a lot of those around) seems to be avoided if one can use the TC_WIN_PRINT command.

The more limited problems with the editor printing were, I think, a problem with needing some extra communications between the printer (an HP with some expired cartridges) and with True Basic and/or the third party software. Most of my other applications would access an HP dialog that let me print anyway (in grey-scale) but I wasn't getting that dialog when using the editor--just would proceed as though it had printed even though the printer received nothing. Again, this is a very special case, my note is just a warning to keep your printer 'happy'. A potential problem there is that 'cheap' ink often uses recycled cartridges refilled, but sometimes those cartridges are seen as expired by the printers and problems such as I experienced could occur.

I plan on rewriting many of my older programs with the TC_WIN_PRINT technique as it seems more consistent and generally I'm only sending one page (screen) of text to the printer. What was really encouraging was that this worked on our network which interrupts the printing process to have students accept the $.10/page printing charge. I don't think the OPEN #1: PRINTER technique would ever work well with that.