[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 ≪NM1≫...≪NM0≫ 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