[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

Okay, that can be easily accomodated.
--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.
Yes, but why would that be a problem (given your . . . numbering
system)? I probably just don't appreciate the problem.
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?
Gosh, it seems simple to do the kind of program I'm suggesting. But what
about using Carl's HARDCODE.PGM that someone mentioned having?

Harry Binswanger