dBMAN Tutorials #3 in a Series Choosing an Editor by John C. Leon August 31, 1986 distributed through the H.A.S.T.E. BBS Houston Atari ST Enthusiasts 713-955-9532 permission granted to distribute unaltered original text I lied. This article was to address the dBMAN video commands. However, my experiences in using different editors may be extremely helpful to some of you. The subject of this tutorial may sound like a no-brainer. You know that you must own an editor (text or word processor) to write dBMAN programs, but virtually everybody owns a word processor that can fit the bill, right? Wrong. There are some interesting flukes in at least two word processors that make their output incompatible with dBMAN. I would have tested more products, but have a limited budget! I must emphasize that the problems noted here may not necessarily be apparent to you. The most sensitive dBMAN command I have found to date in this context is the SET PROCEDURE TO command. As this is an extremely valuable and frequently used command, for all practical purposes you should choose an editor that can produce files compatible with it. The Final Word I use the Final Word for 95% of my word processing. The rest of the time I use First Word. Naturally I turned to the Final Word to create dBMAN programs, with good reason. The native format of a file saved with Final Word is (almost) pure ASCII. Booting it up you can immediately begin typing your code. The saved file can be used as is in dBMAN. Kind of. Until I began using dBMAN's SET PROCEDURE TO command I had no problems. That command reads through your procedure file (a special form of command file) to locate all procedures within it. If a non-ASCII character is found anywhere in the procedure file, dBMAN will promptly crash to the desktop. All procedures created with the Final Word will bomb. Unknown to most users, Final Word uses an end-of-file marker that is not ASCII, but a control character (decimal value of that character is 26, hex 1A). You would never know this because that character never appears onscreen in the Final Word. In retrospect, I should have identified this problem sooner. Every time I loaded a straight text file into Final Word (e.g. captured messages from a BBS), Final Word gave me a message dBMAN Tutorials - 1 - Choosing an Editor saying "No EOF on read". Final Word was looking for its decimal code 26! Another indication of trouble with Final Word's saved files came with use of Solapak software. I routinely used Final Word to create lists of files to be copied from floppy to a ramdisk at boot with Solapak's COPY2RAM program. COPY2RAM worked perfectly, but after watching it copy all listed files to ram, I would get an "open error". Now I know that COPY2RAM was trying to read that odd control character as a filename! What do you do if Final Word is the only word processor you own? You could be in trouble! The shenanigans you have to go through to get rid of that one troublesome byte aren't worth it. You'd do one of two things. Either you could use a sector editor like DUST to change that last byte to something harmless, or you could create a copy of the Final Word and configure it so that you could print your files to disk. There are numerous items you would have to reconfigure, so I don't encourage that route. Not only that, but the steps to take to print to disk with the Final Word make it a less than desirable alternative for creating dBMAN programs. For what it's worth, the product is excellent for word processing and has a repertoire of formatting commands that simply don't exist in any other product on the market for ANY computer. I use it for all of these tutorials. Regent Word At first blush, this simple word processor is a great choice. Its native format for saved files is definitely pure ASCII. It's easy to use and inexpensive. It's not a really powerful word processor, but here we are only interested in its virtues as a program editor. What's my complaint with Regent Word in connection with dBMAN? Intermittently, when you save a file, it puts a bare ASCII carriage return as the first byte in the file (13 decimal, 0D hex). In most normal files, the carriage return is always part of a pair of codes: the standard carriage return and line feed combination. Despite the fact that this bare carriage return is a valid ASCII character, dBMAN's SET PROCEDURE TO command again crashes to the desktop as the carriage return is not accompanied by a line feed. For this reason, then, Regent Word is totally unacceptable as a text editor for dBMAN programs. The bug discussed above does not affect any normal word processing. The carriage return character is not seen onscreen and does not affect normal printing. The problem lies in its inherent incompatibility with dBMAN. dBMAN Tutorials - 2 - Choosing an Editor ST Writer, V1.07 This version of ST Writer was released in July, 1986, and is light years ahead of its prior incarnations in that many of the bugs plaguing it have been cured. It is public domain. Most of you own it, and those who don't can acquire it easily. Like Regent Word, it is easy to use. It is easy to adapt to the requirements of dBMAN command files. Simply change the top line of control codes to reflect bottom and top margins of zero, left margin of zero, right margin of your choosing (80, generally), page length of two (that means a page length of one line - required to eliminate the trailing blank lines that you would get otherwise to "round out" a page of paper), and single spacing. Save your files in the usual fashion. Before any such files can be used in dBMAN, they must be printed to disk. They'll work fine. Be prepared for a LONG wait when printing to disk. With the parameters suggested above, it took over four minutes for a file of 10,000 bytes to print to disk. You could leave the page length set to 132 (control-Y 132, meaning 66 lines), but then the end of your file would have extraneous CR/LF codes to round out the file to full pages. However, it would print to disk much faster. First Word I saved the best for last. Not only is First Word easy to use and perfect in all respects for use with dBMAN, but it is GEM-based, permits multiple windows to be open for easy editing of several files simultaneously, and makes cut and paste operations between files a breeze. Access to GEM is particularly important to me as I am constantly thinking ahead and often want to make notes while I am busy creating programs. Having access to desk accessories like Macro Manager is important to me. You will find it handy to create your dBMAN programs in WP mode with justification turned off. Make sure you turn WP mode off before saving your file and you will get the pure ASCII that dBMAN demands. In essence, this amounts to printing the file to disk. It is infinitely faster than ST Writer in that regard. You will probably also want to save your file while in WP mode, so as to make it easier to modify your program in the future. -------------------- I hope you have found this discussion of some of the finer points of editors to be helpful. And you thought just any editor would do! Consider this article an intermission. Next time we will get back to business with the dBMAN video commands. dBMAN Tutorials - 3 - Choosing an Editor