[Date Prev][Date Next][Subject Prev][Subject Next][Date Index][Subject Index]

Re: hardcode.pgm anomaly--methodology

No go, Harry, I tried running your program. Now first of all, I 
DO reset counters--quite often. It appears that you have to after 
a chapter counter (C0; that's zero, not oh), which doesn't reset 
automatically. And I have to after my One, Two, Three type part 
numbers too. Secondly, I got "Command not recognized," and 
nothing happened.

I've been thinking about this and on second thoughts, perhaps a printer driver and typf is the only way to go. Because whatever routine you use will have to juggle several things in memory simultaneously: the value of the next-high$est counter, the value of the one above that, and so on. Because every time you increment a counter, you reset all the counters below it in the hierarchy. BUT you don't want to change anything else.

So two possibilities present themselves:
1. You create a printer driver that changes NOTHING in the file except the autocounters. ASCII.PRN does NOT do that; it strips out all the high-ASCII/Speedos chars, not to mention formatting. But I don't know enough about printer files to know if that's possible. 2. You write an XPL routine that uses <>...<> formatter to mark off all DC and Cx commands. Then it changes all other formatting guillemets to <<>>, then it loads ascii.prn and typfs the file, then it calls fo.tmp and restores all the formatting guilements by changing <<>> back to their control char values.
Anyone know of any reason that wouldn't work?
Patricia M. Godfrey