Edit:Find fails to find!

[Uriel]

Both Word 2000 and Word 2003 seem to have a bug whereby they can fail to
find occurrences of--

"</h1>^p" (without the quotes)

(i.e., "</h1>" followed by a paragraph mark)

--when the user searches via Edit:Find.

The problem is illustrated in bug1a.txt, a plain text file with no special
characters that is contained in ftp://ftp.urielw.com/bug1.zip .

bug1a.txt contains 94 instances of the above string. Somehow, Word misses
one of them. You can see the missed instance by opening the file (using
"Plain Text" conversion option) and searching for "Recalcitrant" (without
the quotes). The instance Word misses is immediately after that word.

bug1a.txt contains only normal ASCII characters. I wrote a program to list
all characters occurring once or more. This is the list (decimal
representations shown):

10, 13, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86,
87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104,
105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119,
120, 121, 122, 123, 125, 126

Also, I confirmed there's no carriage return (13) or line feed character
(10) other than the standard carriage return, line feed combination at the
end of each line.

The above bug is the reason, incidentally, that an MS Word document I offer
for download at http://urielw.com/china2/ , namely
ftp://ftp.urielw.com/uwchina2.doc , is inadvertently messed up.

 

[Uriel]

Is there a live person at MS who might be interested in looking into this
bug? This is not a new-fangled advanced esoteric feature, it's elementary
SEARCH, a feature that's been in the product for a couple of decades.

Both Word 2000 and Word 2003 seem to have a bug whereby they can fail to
find occurrences of--

"</h1>^p" (without the quotes)

(i.e., "</h1>" followed by a paragraph mark)

--when the user searches via Edit:Find.

The problem is illustrated in bug1a.txt, a plain text file with no special
characters that is contained in ftp://ftp.urielw.com/bug1.zip .

bug1a.txt contains 94 instances of the above string. Somehow, Word misses
one of them. You can see the missed instance by opening the file (using
"Plain Text" conversion option) and searching for "Recalcitrant" (without
the quotes). The instance Word misses is immediately after that word.

bug1a.txt contains only normal ASCII characters. I wrote a program to list
all characters occurring once or more. This is the list (decimal
representations shown):

10, 13, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86,
87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104,
105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119,
120, 121, 122, 123, 125, 126

Also, I confirmed there's no carriage return (13) or line feed character
(10) other than the standard carriage return, line feed combination at the
end of each line.

The above bug is the reason, incidentally, that an MS Word document I offer
for download at http://urielw.com/china2/ , namely
ftp://ftp.urielw.com/uwchina2.doc , is inadvertently messed up.

 

[Tony Jollans]

I have looked at this but have nothing helpful to say unfortunately.

I get the same odd result that you do and can't, at the moment, explain it.

 

[Tony Jollans]

I just went back and looked at this and have a couple of observations -
don't know that it helps but ...

1. Searching for </h1>^13^10 is successful - although it is theoretically
specifying the same search.

2. Open the .txt file, Save As a .doc file - then it works.

I have seen some posts about the conversion of plain text into Word having
some 'funnies' but don't really have much experience of it myself.

 

[Uriel]

Thanks kindly for looking at this, Tony.

2. Open the .txt file, Save As a .doc file - then it works.

Yes, that's consistent with what I'd found: Copy a small portion of the area
surrounding the problem to clipboard, do File:New, paste into the new
document -- the problem's still there. But when you SAVE, prob's gone. The
saving process seems to fix it.

"Tony Jollans" <My Forename at My Surname dot com> wrote in message
I just went back and looked at this and have a couple of observations -
don't know that it helps but ...

1. Searching for </h1>^13^10 is successful - although it is theoretically
specifying the same search.

2. Open the .txt file, Save As a .doc file - then it works.

I have seen some posts about the conversion of plain text into Word having
some 'funnies' but don't really have much experience of it myself.

 

[Cindy M -WordMVP-]

Hi Tony,

Good detective work

1. Searching for </h1>^13^10 is successful - although it is theoretically
specifying the same search.

Actually, in Word it's not. You'll only get ^10 for files converted from
text files, generated by certain programs. As far as Word is concerned,
^13^10 is NOT the same as a paragraph mark. Only ^13 equates in Find to a
"true" Word paragraph mark.

If Uriel doesn't first want to save the documents as Word documents, then
she'll need to either search as you've shown, or first do a find/Replace,
finding ^13^10 with ^p (not decidedly NOT with ^13).

Cindy Meister

 

[Tony Jollans]

^13^10 is NOT the same as a paragraph mark.

Good point Cindy.

Uriel has another thread on essentially the same issue somewhere where I
have noted that the Find fails when the chr(13) and chr(10) span a 256-byte
boundary in the original text file - and I'm sure the problem is caused by
the conversion from plain text to Word format not being complete until the
file is saved as a doc - or at least a non-plain-text style is applied (I
didn't spend long enough checking out all the options to be sure exactly
what it takes).

 

[Cindy M -WordMVP-]

Hi Tony,

Uriel has another thread on essentially the same issue somewhere where I
have noted that the Find fails when the chr(13) and chr(10) span a 256-byte
boundary in the original text file - and I'm sure the problem is caused by
the conversion from plain text to Word format not being complete until the
file is saved as a doc - or at least a non-plain-text style is applied (I
didn't spend long enough checking out all the options to be sure exactly
what it takes).

Right. Picked up on that a few minutes later (my newsreader works from the
oldest to the most recent messages).

Cindy