I tried that. The problem is that the floating trap used to get the date on at the top also picks up the 'Month Ending...' part. The first couple of statements in the file are ok, but then it loses synch and the output is garbage. It will eventually resynchronize, but that doesn't last long.
Any other thoughts?
You have not mentioned it so I guess it's not there but my favoured trap for a page header normally uses something connected with the Page Number.
Of course there are examples where the reports don't have a page number or at least not a trappable one.
If there really is nothing (spaces, dashed lines, anything really) that might help here - and a variable length page header is no help either - then you may be looking for some form of pre-process to transform that first line date into something more uniquely identifiable as a starting point.
The downside of that idea is, of course, finding a way to uniquely identify that line without using a floating trap.
For example - and this is just 'thinking aloud' - if you were to select all of every line (i.e. no trap) and could then pick any lines starting with a month name then a space then one or two numerics followed by a comma then a space and then a valid year number AND if you could be sure that such a combination would not occur anywhere else (unless that could be dealt with by further conditional processing) THEN you could transform the line by inserting something unique at the begining of the line, for example, and making an easy trap.
All other lines would be written as they are to a calculated field. The transofrmed line would be written to the same field and you now have a revised version of the report. Print it or export it and run another model against that version.
There may be some potential for dealing with the variable number of lines problem in the page header at the same time (or at least in a similar way).
Does that spark any ideas?
I mocked up a report file by copying your sample a few times, and inserting different dates and varying the address lengths.
I got a trap to work on the first line of the address, instead of the dates, so using a non-floating trap, with plain A alpha traps in columns 1 and 37 on line 4 of 10 (you might want to increase this if you have very long addresses), of an append template.
To capture the Month Ending you will need both "After last defined field" and "Blank field values" selected on the advanced tab, then a calculated field in the table to clean up the result.
Grant and Olly,
Thanks for your thoughts on this.
First, pre-processing the file as Grant describes is an option that I hadn't thought of, but may work well. I may be able to clean up a number of things by doing this. I will look into it.
With regards to the solution proposed by Olly, I will give it a try and see if there is anything else in a full length file that might interfere. The snippet that I provided is real - I just changed the names, etc. - but it is also only a single case in a variety of possibilities.
As a side note, I recently posted a note in the Monarch future improvements thread suggesting adding the ability for use of Regular Expressions for trapping and extracting. I have used Regular Expressions before with good results, and believe that some of these kinds of difficulties could be more easily delt with using that technique. I don't know if I am unique in my view on this, but it was a thought.
Thanks again. Let me know if you have further thoughts.