Well, folks, further coding on my editor brought yet another opportunity to use my FSA tokenizing/parsing scheme. This time it was to interpret a user-input line defining a print page header or footer, and it worked like a charm.
In adding a page setup option, I decided to go with Notepad's header/footer definition scheme, which is good enough for government work, as they say. Their syntax allows plain text which gets printed as entered, plus these special tags:
| Tag | Meaning |
| &l | Align text to left |
| &c | Align text to center |
| &r | Align text to right |
| &f | Insert name of file being printed |
| &d | Insert date |
| &t | Insert time |
| &p | Insert page # |
Took me just a few hours, from the time I sat down with paper and pencil to when I did a successful proof-of-concept run. (It would have taken even less time if I hadn't made some stupid mistakes caused by copypasta.)
The first diagram below shows the overall scheme: I decided that since I have text that aligns left, center and right, the easiest way to handle this would be to separate the text into 3 separate buffers. Which turned out to be super-simple. When it comes time to actually print the header or footer, I'll first print the left buffer with left alignment, the center buffer with center alignment, the right buffer with right alignment.
The second diagram shows the tokenizer used to accomplish this. Look how (relatively) simple it is. Again, it consists of a data table that drives code using several (8 in this case) stubs, the longest of which is less than 20 statements long; most are much shorter.
I'd like to use this as a challenge to anyone out there who's interested in taking it up: Try to do this same job using whatever method you like. Usually this is going to consist of a whole bunch of IF ... ELSEIF ... statements, and probably setting and checking a whole bunch of flags. I'd like to demonstrate how superior this method is in several ways. Try to write this same code and see how it turns out. (I'll post the code for my method in a follow-up to this.) And be sure to tell us how long it took you (including time sitting scratching your head!).
Here are the details:
- The text comes from an edit control, which has room for, let's say about 100 characters or so.
- The user can type any text, which gets put into the buffer(s) as-is.
- When one of the tags given above is encountered, the code does one of two things:
- If it's one of the insertion tags (date, time, etc.), my code just puts an encoding byte into the buffer for the printing code to substitute later.
- If it's one of the left/center/right tags, my code switches buffers to whichever one is specified.
- The tags can be entered either in lowercase or uppercase.
- Text goes into the center buffer by default, at the start of the code and if no other alignment is specified.
- The user can switch back and forth between any alignment (left/center/right) as many times as they wish and in any order.
For the encoding byte, I use 0FEh to indicate a page #, for example (I picked some high #s with no corresponding ASCII values). When the printing code scans the buffer (any of the 3), it'll substitute the text for the page # there. This isn't part of the parsing job. All you need to do is stick some byte in there.
So see if you're up to this challenge. May the best code win!