Greg Maxey was telling us:
Greg Maxey nous racontait que :
JGM,
I don't consider it picking on me. I enjoy the dialog. I am
analyzing your comments regarding my last version and evaluating
yours.
First let me make sure that you know how I envision this macro
working. The user has a smattering of highlighted text (in
multi-colors) through a document. The important color is brightgreen
some of the important color text he has already reviewed and flagged
with a leading carat symbol. No the user wants to start at the
beginning of the document and step through the range stopping to
review and edit the unflagged bright green text. He put the cursor
at the start of the document and fires the macro. The IP appears at
the start of the first found unflagged brightgreen text and the macro
stops. The user edits the text and leaves the cursor to the right
(following the edited text). He fires the macro again.
Yep, I got that part, although I did not really test the code by doing a
systematic approach as you described, but this time I did.
The first thing I noticed is that your new version will not move from
one cell containing brightgreen text to the next cell or from the
first instance of highlighted text in a cell to subsequent instances.
It repeatedly goes back (loops) and stops at first found bit of text
in the cell. If the IP is at the end of a cell and the macro is
fired instead of looking forward for the next bit of text, your goes
back to the previous highlighted text in the cell.
I did not observe that behaviour. I just tried again with a 3x3 table with 5
bits of "un-careted" bright green text, with an instance of 2 of them in the
same cell separated by a few paragraphs.
I fired my macro and it found all of them in succession (after each
successful found I added a caret at the beginning of the bright green text
and then placed the IP right after the said bright green text. Maybe this is
where I get confused. I assumed that the caret was to indicate that the
bright green text had already been reviewed, so I assumed, probably wrongly,
that whenever a bit of unflagged green text is found, the user edits it and
then flags it (byadding a caret) so the macro would not found it again. If
this is not the case, then, with my version, the user has to place the IP in
the next cell before firing the macro again.).
This second version performs as well as the first, except that the first
could not handle two bits of green text in the same cell. Now, with your
input, this second version does find those instances.
Mine doesn't do that. If the cursor is to the right of the first bit
of highlighted text in a cell and I run the macro again it stops at
the next bit in that cell or at the next bit in a subsequent cell,
etc.
The only time I noticed that with my version is when you bypass a bit of
"un-careted" bright green text in a cell. So, if you place the IP after some
unflagged bright green text, the macro will find it, but if the preceding
bit of bright green text in the same cell is already flagged, the macro
ignores it and goes on to wherever the next bit of unflagged bright green
text is.
If I put the cursor between two bits of unflagged brightgreen text in
a cell and step through the code then rgeTarget consists of the range
of text between the IP and the end of the cell. In your last version
rgeTarget consist of entire cell range. Hence it "finds" the text
before the cursor.
Again, as I wrote above, I did not observe this, except when the previous
bright green text in the same cell in unflagged. (The macro does reset the
range to the entire cell, but if some of the text before the IP is already
flagged, it does not matter as it ignores it.)
To fix this I set the start range of oRng1 to the end range of oRng2
in the DO statement:
So, in my mind, this is not necessary.
But if you feel you really need this, I would suggest that you place this
in the function (probably inside the "IF range in table" bit), where all
range manipulation should be handled (in order to avoid conflicts).
Do While Not boolSearchResult
Set oRng2 = Selection.Range
oRng1.Start = oRng2.End
As for the If Not .Found Statement, without it if the IP is in a
table cell that contains no more hightlighted text and there is no
more subsequent highlighted text in the document a continuous loop
occurs.
I did not observe this behaviour. I used the same document I was referring
to above. I removed all highlighting in the table and in the text below the
table in the document. Wherever I placed the IP (Before, after or inside the
table) I still got my "Text not found" message.
So with all that said, this is what I have left:
There remains at least one issue that I haven't bothered to try to
resolve. If the IP is in a table with no more text to find and there
is no more text to find in subsequent text, the cursor rests at the
end of the Table and the msgbox doesn't pop. The users will have to
fire the macro again. Seems silly to kill brain cells over ;-)
My version does not exhibit this behaviour.
I have not observed any of the behaviours you mentioned with the latest
version.
So, how did you do it? How did you manage to get these behaviours and I
didn't? If you observe them again, send me the test document you used. I am
probably missing something really obvious!
Unless all this is related to the assumption I mentioned above. If my
assumption was wrong, then the only problem my version still displays is the
case of two bits of bright green text in the same cell, in which cases,
after editing his text, the user has to place the cursor in the next cell,
not just merely at the end of the said cell (which should not be a problem,
unless he is working with cells that span full pages...). I still did not
observe any of the other behaviours.
At least, I did practice coding for cells and increased my understanding of
cell manipulation with VBA. Thanks!
--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site:
http://www.word.mvps.org