Re: hardcode.pgm anomaly--methodology

[Harry Binswanger hb@xxxxxxxx]

> 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 2.1.3.1 . . . 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
hb@xxxxxxxx