My apologies for obfuscation through minimizing! I tried to clear away any unnecessary detail, but I may have been too exuberant in this effort. To try and answer your points:

1) The values "Sub ",Function " "Property " are in fact the (externally declared) symbolic constants synSub, synFunc and synProperty. Those declarations are as follows:
const synSub="Sub "
const synFunc="Function "
const synProperty="Property "

I guess I hoped that the name would be meaningful.It is also what's printed out in the debug statements (as CurrentProcType).



2) What I'm trying to accomplish is, pretty well, what I said. I'm searching a whole bunch of text for these values. I believe that the setting up of the Find object is accurate (in Pass1GetNextProc), and my concern is that the Find seems to fail (as shown in the debug output, where a find operation in a range from 6765 to 11702 seems to produce a result that starts at 6751 - 14 characters outside the specified range.

However - between posting (yes, cross-posting mea maxime culpa) and getting your response, I did some more research, and it seems that the Find operation behaves differently when it is inside a table structure. The range which causes the behaviour I noted is indeed in a table cell. So, trying to be more tightly focused on the actual concern, I guess I would restate the problem as:

The documentation of the Find object in Word makes no special mention of how it behaves in a table cell. Absent such alert, I believe I have a right to expect that it would behave no differently. The belief is confounded by what actually happens. I can find no way to determine if a range is within a table except by constructing a list of tables (and possibly cells) and testing every single Find operation against that list, and coding it differently when that happens.

When I perform the find manually, within the UI of Word itself (Word 365) I get all appearances of the search text, including those within a table. So it seems as Microsoft has no trouble getting past the road-bump that I've encountered. What I'd like to do is to find out exactly how they do this.

Now - in the wider context of what I'm trying to do with this code, it doesn't really matter, because the text will be a series of lines with no tables, and all nicely delimited by CR-LF. However, the phenomenom is real, and repeatable, and manifestly it has a work-around (because MS does in fact not encounter the same problem). So, at the moment this is largely of academic interest. However, it's kind of like a $0.25 discrepancy in accounting for CPU usage, which led to the unveiling of all sorts of Cyber attacks. (The Cuckoo's Egg, 1989)

Thanks for your feedback, I'd love to know if you can offer any help with this issue.

Tony