Network Concerns

One continuing concern that I have is about the way True Basic programs run in a network environment. To a large extent some problems may not be strictly speaking a True Basic problem, but still 'other' programs run better. To be more specific:

1) Writing temporary files. According to the manual (yes I actually RTFM--sometimes) when you do a PRINT (channel number) True Basic creates a temporary Spool file so that the printing job can be sent all at once to the printer. I'm not sure if this is still how it works since there have been some updates in printing, but this is supposed to deal with networked and page-oriented printers. I also have run into cases where True Basic seems to want to write some temporary files when memory use gets high (this I think being tied to some of the 'ancient' restrictions still in the language and work arounds for these facts.) The potential problem with both of these file writing behaviors is that a network user doesn't necessarily have write permissions for the volume from which the program is being run. I'm in a College environment where I would like students to run TB bound programs from an academic server. I have recently had to have our IT people make the folder in which these programs reside write-enabled for all to avoid permissions problems. This is OK, but also leads to security concerns since students can now modify (I don't think they know how, but....) files and programs in that folder.

2) Printing is STILL a problem and has now become a 'random' problem in that from any given computer to any given printer the process works some of the time, but at other times actually crashes the program. Neither I nor our IT people can figure this out. The program crashes are a recent symptom (and happen even with older bound versions) and seem to be TB/Windows/Network related, but I haven't fully eliminated True Basic as the major culprit. However, error traps around the printing routines do no good, but I have not YET gotten much information about the crash. We get Windows notifications that the program has stopped running. [Yes, next time I'll try to get the additional info out.] The real mystery is that this is very inconsistent, but the likelihood of a crash seems to increase with repetitive print attempts.

Once again, I suspect that part of the problem is the age of the True Basic core. Examples would be memory limitations (such as program length and array sizes), the print spooling (probably dealt with today by the networked printers themselves or the OS), etc. I really have way too much software here (over a half-million lines of code) to be switching languages, but when I retire soon, may be forced into looking at doing just that.



Hardcopy printing

Hi Rick,

Indeed hardcopy printing - particularly with HP printers has always been problematic. My experience with network environments is negligible and I only have EPSON printes to work with, so my ability to reproduce the crash syndrome doesn't exist.

In an attempt to rectify this problem I have recently tried some third party freeware that claims to work on all printers and all operating system from Win95 up to Windows7. In version 6.007 I will include some code that will look for the relevant third party freeware and will use it if it exists. Hopefully this will put an end to the inconsistent problems you have experienced.

Big John


Hi Rik,

As always your analysis is probably correct. The core language system needs to be up-dated to address these issues. However I can confirm that the editor itself does create several 'temporary' files that are always kept in the same folder as the TBsystem file. In the case of printing, the editor creates a temporary file in case the user only wants to print part of a document. The temporary file contains only that part which needs printing, not the whole document.

Network Concerns

Have you looked at Decimal BASIC? It doesn't produce exe files but the language is based on the Full ANSI standard for BASIC and is so close to TrueBASIC that your changes would be minimal in most cases.

I really like TB but until the core is rewritten, there are too many problems with it for me to be able to recommend it for many purposes.

Tom L


Thanks Tom, but the executable part is pretty important as my software gets distributed throughout the world (for free) and heavily relies on the truecntrl library. At one point looked seriously into C++ but the complexity there put me off when I could do everything (at that time) that I wanted with True Basic. Even found that the graphic animations I do were no faster in C than in TB--which was the impetus for looking into a switch. Since then the machines have gotten so much faster that my main concern is 'slowing down' the animations rather than speeding them up--but today redrawing a screen in TB is 'almost' fast enough so that a pause .03 between redraws gets you pretty close to a 30 frame refresh rate!

If TB ever invests again in a core level programmer like Chris Sweeney, maybe we'll see some updating. I suspect though, that the main market for the language is introductory programming classes where it serves very well, but without enough profit to warrant much other development. Just a shame that the true power of the language is now locked up in a 20 year old package.