 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / January 2005Loop Through Document
Hello Group! I'm trying to write a subroutine that will examine the first several characters of each line in a Word document and take some action based on the value. I'm having difficulty with coding a loop that will cycle through each line until it reaches the end of the document. I'm fairly new to vba and was wondering if someone could explain why the following code doesn't reach the end sub when the cursor is at the end of the document: Sub AutoExport() Selection.HomeKey Unit:=wdStory Selection.HomeKey Unit:=wdLine Do Until ActiveDocument.Bookmarks("\Sel") = _ ActiveDocument.Bookmarks("\EndOfDoc") Selection.MoveDown Loop End Sub Many thanks! ~ Dave It doesn't work because you're simply moving downwards: if the last line isn't empty, you'll end up at its start, which is not the end of document. In any case, this is absolutely the wrong way to approach this. Don't use the Selection object if you can avoid it, and you nearly always can. To iterate the paragraphs of a document, use something like -- Dim pPar as Word.Paragraph For each pPar in ActiveDocument.Paragraphs ... do whatever with pPar Next > Hello Group! > [quoted text clipped - 22 lines] > > ~ Dave Jezebel, Thanks for the speedy reply. I'll post a follow-up if I have problems. Getting back to the example I posted, my last line was, indeed, not blank. However, even when I added a blank line I couldn't get it to exit the loop. It still doesn't exit the loop if I add a selection.endkey unit:wdline within the loop, nor even a selection.endkey unit:wdstory. I ran across this method of looping through documents many times after googling for solutions, and I'd like to understand why it isn't working. The original example was: Loop: Do Until End of Document Do Until ActiveDocument.Bookmarks("\Sel") = _ ActiveDocument.Bookmarks("\EndOfDoc") '(Do something) Loop I thought I could simply add code to move down a line each time through the loop and look at the start of each line of text, and exit the loop when I got to the last line. Obviously I'm missing something or don't understand the real purpose of the example. Thanks, ~ Dave > It doesn't work because you're simply moving downwards: if the last line > isn't empty, you'll end up at its start, which is not the end of document. [quoted text clipped - 39 lines] >> >> ~ Dave I was quite wrong about the reason for the code failing. The point is that a bookmark is an object, not a simple variable. If you refer to an object in a context that requires a simple variable (such as the equality test in your code), VBA uses the default property of that object (if it has one -- if it doesn't have one you get an error). The default property of a bookmark object is its Name. You can check this by typing, into the immediate window: ? ActiveDocument.Bookmarks("\sel") ... as you'll see, the result is: \sel So obviously your test will always fail. What you want to test is whether the two bookmarks are referring to the same document range -- this is true if their Start and End properties match. In this context it would be enough to test the Start properties (because, by definition, \EndOfDoc's Start and End properties are always the same) -- If ActiveDocument.Bookmarks("\sel").Start = ActiveDocument.Bookmarks("\EndOfDoc").Start then ... > Jezebel, > [quoted text clipped - 67 lines] > >> > >> ~ Dave DJ, Here are a few examples for you to look at. Type a word or two in a document and then run these test. Use F8 in your VBA editor to step through the tests. Sub Test1() Dim i As Long Selection.HomeKey Unit:=wdStory i = 0 Do Until ActiveDocument.Bookmarks("\Sel") = _ ActiveDocument.Bookmarks("\EndOfDoc") Or i = 1000 i = i + 1 'Do something Loop MsgBox """i"" = " & i & " . This test shows that \Sel isn't" _ & " going to be equal to \EndOfDoc anytime soon! In" _ & "fact it never will. You are spinning your wheels." End Sub Sub Test2() Dim i As Long Selection.HomeKey Unit:=wdStory i = 0 Do Until ActiveDocument.Bookmarks("\Sel") = _ ActiveDocument.Bookmarks("\EndOfDoc") Or i = 1000 i = i + 1 'Do something Selection.Move Unit:=wdCharacter, Count:=1 'Do something else Loop MsgBox """i"" = " & i & " . This test shows that while you can move" _ & " the selection towards \EndOfDoc, you can't get there." End Sub Sub Test3() Dim i As Long Selection.HomeKey Unit:=wdStory i = 0 Do Until ActiveDocument.Bookmarks("\Sel") = _ ActiveDocument.Bookmarks("\EndOfDoc") Or i = 1000 i = i + 1 'Do something Selection.GoTo What:=wdGoToBookmark, Name:="\EndOfDoc" Loop MsgBox """i"" = " & i & " . This test shows that while you can go" _ & " directly to the \EndOfDoc bookmark, the \Sel bookmark" _ & " and \EndOfDoc bookmarks are still not equal." End Sub Sub Test4() Dim i As Long Selection.HomeKey Unit:=wdStory i = 0 Do Until i = ActiveDocument.Characters.Count Or i = 1000 i = i + 1 'Do something Selection.Move Unit:=wdCharacter, Count:=1 Loop MsgBox """i"" = " & i & " . This test meets the first condition" _ & " and moves the IP to the end of the document and exits" _ & " the loop." End Sub While these tests fail to explain why the two bookmark values will never be equal, they offer proof and provide an alternative.  SignatureGreg Maxey/Word MVP A Peer in Peer to Peer Support > Jezebel, > [quoted text clipped - 66 lines] >>> >>> ~ Dave DJ, In view of Jezebel's enlightening post, we can add a new Test2A. Sub Test2a() Dim i As Long Selection.HomeKey Unit:=wdStory i = 0 Do Until ActiveDocument.Bookmarks("\sel").Start = _ ActiveDocument.Bookmarks("\EndOfDoc").Start Or i = 1000 i = i + 1 'Do something Selection.Move Unit:=wdCharacter, Count:=1 'Do something else Loop MsgBox """i"" = " & i & " . This test shows that when the two" _ & "bookmarks are referring to the same range then equality" _ & " can occur and meet the condition." End Sub - Greg Maxey/Word MVP A Peer in Peer to Peer Support > Jezebel, > [quoted text clipped - 66 lines] >>> >>> ~ Dave Jezebel, The snippet you suggested is working good, but not great :) Thank you! I find it appealing because it's clean and simple. I don't know what advantages it has over the Selection object, or if there are any pitfalls to the Paragraph object approach. Perhaps you could comment if and when you have a moment. One thing that I'm finding is that the "learning" loop I've coded using your suggestion (see below) fails to reach the end of some of my documents. The documents I'm running it against consist of simple lines of text terminated with a carriage return (ENTER key, Chr(13), etc.) There's no special formatting, graphics, idents, tabs, etc. After running the macro the IP is positioned at the start of line 39 on page ten of an eleven page document (there are 347 paragraphs and 547 lines in the document). If I copy the offending section, and include a couple lines of text above and below line 39, into a new document as unformatted text and run the macro, the IP is at the end of the document. If I copy the entire document and paste it into a new document as unformatted text, the IP is at line 40 on page ten after running the macro. If I do this again and run the macro, the IP is at line 41 on page ten. Can you provide any insight on what may be causing this? Sub IterateDocLines() Dim result As String Dim pPar As Word.Paragraph Selection.HomeKey Unit:=wdStory Selection.HomeKey Unit:=wdLine stepnumber = 0 For Each pPar In ActiveDocument.Paragraphs Selection.MoveRight Unit:=wdWord, Count:=1, Extend:=wdExtend result = Selection.Text Selection.MoveDown Next End Sub Thanks again for you suggestion, explanations (and patience)! ~ Dave > It doesn't work because you're simply moving downwards: if the last line > isn't empty, you'll end up at its start, which is not the end of document. [quoted text clipped - 39 lines] >> >> ~ Dave OK, the problem is that you've misunderstood what's going on with the code snippet I posted. The code is iterating the paragraphs (rather than the lines, but since your doc consists of lines ending with vbCR, that amounts to the same thing). In each iteration, pPar refers to the paragraph itself. So you don't need to use any selection statements at all. Try this, just as an experiment: Sub IterateDocLines() Dim pPar As Word.Paragraph For Each pPar In ActiveDocument.Paragraphs debug.print pPar.Range Next End Sub I'm not clear on what you actually want to do with each line or paragraph, but if you want to replace the first three characters, you could use something like pPar.Range = "XXX" & mid$(pPar.range,4) Put this in place of the Debug.Print line. There are numerous reasons for avoiding the Selection object, including -- 1. Your code runs MUCH faster if you refer to the objects directly. Moving the selection and updating the display are by far the slowest things Word does. 2. The Selection relies on the actual display at the time the macro is called (some things work differently or not at all according to whether you are in normal view, print view, outline mode, etc, and according to the type of selection (is the cursor in the body of the document, or in a header, textbox, footnote, etc). Error-handling gets very complex! 3. Trying to move the selection around the document gets problematic if the document is contains more than plain text. With your current code, moving through the document by using MoveRight ...what happens if you meet a table, or a textbox, or a frame, etc? (I actually don't know what happens -- there are likely to be conditions under which ExtendRight will fail. If you work directly with the objects you don't have to think about this.) 4. Moving the selection annoys the user. 5. Code that doesn't touch the selection still runs correctly even if Word is hidden. 6. As you've already noticed, the code is cleaner and simpler, and you need less of it. > Jezebel, > [quoted text clipped - 85 lines] > >> > >> ~ Dave Jezebel, Your suggested code: Sub IterateDocLines() Dim pPar As Word.Paragraph Dim myRange As Range For Each pPar In ActiveDocument.Paragraphs myRange = "XXX" & Mid(myRange, 4) Next End Sub Seems to create a circular loop. It changes the first paragraph but then goes no further. I can't figure out why. SignatureGreg Maxey/Word MVP A Peer in Peer to Peer Support > OK, the problem is that you've misunderstood what's going on with the > code snippet I posted. [quoted text clipped - 146 lines] >>>> >>>> ~ Dave Jezebel, Ignore my last in part. What I provided as your suggested code was an aborted attempt of mine to get some code to work. Sub IterateDocLines() Dim pPar As Word.Paragraph For Each pPar In ActiveDocument.Paragraphs '1 pPar.Range = "XXX" & mid$(pPar.range,4) '2 Next ;3 End Sub Loops continuously between lines 2 and 3 SignatureGreg Maxey/Word MVP A Peer in Peer to Peer Support > Jezebel, > [quoted text clipped - 162 lines] >>>>> >>>>> ~ Dave Greg, it does indeed. Serves me right for writing aircode. Some odd things have happened to VBA in the latest revision. The VB documentation on collections swears on a stack of bibles that For...each is guaranteed to iterate the entire collection regardless of what you do to the collection members within the loop. In this case there's something very strange happening ... as if redefining the paragraph range is rebuilding the collection. I wonder if it's something to do with the bizarre 'Smart Selection' options introduced in W2003? It does work correctly coded like this -- For i = 1 to ActiveDocument.Paragraphs.Count Set pPar = ActiveDocument.Paragraphs(i) pPar.Range = "XXX" & mid$(pPar.range,4) Next > Jezebel, > [quoted text clipped - 178 lines] > >>>>> > >>>>> ~ Dave Jezebel, I was on the road all day today (450 miles to attend a 1 hour meeting) :-( I meant to try your range method on my Word2000 program at work this morning before I left, but didn't have time. Have you discovered a reason for the odd behaviour in Word2003 SignatureGreg Maxey/Word MVP A Peer in Peer to Peer Support > Greg, it does indeed. Serves me right for writing aircode. > [quoted text clipped - 199 lines] >>>>>>> >>>>>>> ~ Dave Commiserations with the travel. I've got clients like that too. I haven't solved the problem (not that I've researched it very far) but it seems that re-defining the paragraph range resets the For ... Next loop to the first paragraph. Perhaps I'm missing something obvious ... I hope so, because if this change carries across to other VBA collections it has some seriously nasty implications. Code like this works as expected -- For each pPar in ActiveDocument.Paragraphs pPar.Range.InsertBefore "XXX" Next So what the hell's going on with this one? Set pPar = ActiveDocument.Paragraphs(1) Do i = i + 1 pPar.Range.Text = String$(i, Chr$(64 + i)) & vbCr Loop Until pPar Is Nothing Originally I had "set pPar = pPar.Next" before the Loop statement ... but try it for yourself. Use F8 to step it ... it doesn't stop by itself > Jezebel, > [quoted text clipped - 207 lines] > >>>>>>> > >>>>>>> ~ Dave Jezebel, I see the same odd behaviour using Word2000. I tried both of your examples that it doesn't perform as you expect in Word203 and the behaviour is identical. I am just a novice and have no clue what is going on. I will be watching to see if someone comes around wiht an explanation. Hi Greg, hi Jezebel, >Set ppar = ActiveDocument.Paragraphs(1) >Do > i = i + 1 > ppar.Range.Text = String$(i, Chr$(64 + i)) & vbCr >Loop Until ppar Is Nothing may I add my own decent bit, in former times, until Word 6.0, I think, there was an end-of-doc-mark, represented by a diamond. This symbol vanished in the windows-versions of word, and was replaced by an ordinary paragraph symbol, but only on the surface. The end-of-doc-mark is still there, but hidden. It can't be replaced and can't be overwritten. So ppar.Range.Text = String$(i, Chr$(64 + i)) & vbCr results in an additional paragraph at the doc's end, like replacing all ^p by ^p results in an additional paragraph. The end-of-doc-mark can't be deleted, too, in way, of course, as then the doc would be endless, in Word's way of thinking. ;-) You could delete the last paragraph mark, if there is an immediately preceding paragraph mark, but then the underlying end-of-doc-mark jumps to the immediately preceding paragraph mark and hides there. A rather naive way of explanation, I admit, but there may be something to it. Greetings from Bavaria, Germany Helmut Weber, MVP "red.sys" & chr(64) & "t-online.de" Word XP, Win 98 http://word.mvps.org/ >Jezebel, > [quoted text clipped - 3 lines] >going on. I will be watching to see if someone comes around wiht an >explanation. Jezebel, Thanks for your valuable input. It dawned on me that I was moving through the document by "lines" but iterating "paragraphs" shortly after submitting this post. Turns out that the docs I was having issues with contained a few sentences that wrapped to the next line and terminated with the soft return instead of vbCR. I created a test doc with several single lines and several wrapped lines then looked at the doc properties and saw it contained seven paragraphs. Light dawned on Marblehead after I compared the number of lines my macro was advancing (hmmm...... 7) to the number of paragraphs in the doc. I modified the Selection.MoveDown and changed it to "Selection.MoveDown Unit:=wdParagraph, count:=1" and it's working much better. What I'm trying to do is prepare Word documents for easy exporting into TestDirector (I detest writing scripts in TD's interface). I have is a doc consisting of step numbers, actions and results that look like this: 1 Action Result 2 Action Result etc..... The macro will create sequentially numbered bookmarks (using specific names for steps, actions and results) at the beginning of each sentence, as well as insert a specific, corresponding bitmap image. Since I do a lot of cut and paste between scripts, the macro will also renumber the steps in sequential order. This is all working well. The only challenge I'm faced with now is that while there is usually only a single action, there can be multiple results. So I need a way to differentiate between actions and results. What I've decided to do is base the division on line placement; multiple actions and multiple results will be separated by a blank line, while the first result will follow actions on the next immediate line. As the paragraphs are iterated I need a way to determine if and when a blank line exists (or does not exist) between paragraphs so I can create the necessary bookmark. Any ideas? Thanks again, ~ Dave > OK, the problem is that you've misunderstood what's going on with the code > snippet I posted. [quoted text clipped - 155 lines] >> >> >> >> ~ Dave You'll make life easier for yourself if you can work entirely with paragraphs rather than lines. As you've seen, the Word object model doesn't actually include lines as such. Unless your paragraphs include hard returns - chr(11) - the line breaks are an artefact of the font, font size, and margin settings. If they DO include hard returns, use the split() function on the paragraph.range to get the individual lines. As for 'blank lines between paragraphs' -- there is really no such thing in Word. Your 'blank lines' are just empty paragraphs. You can test for them by checking the length: If Len(ActiveDocument.Paragraphs(3)) > 1 then .... paragraph is not empty (the one character is the paragraph mark) For a completely different approach: try pasting the whole document into Excel and see what it looks like. This kind of processing is often simpler using Excel's functions. But above all, stop using the Selection object! it's a quick path to strabismus, insanity, and death. > Jezebel, > [quoted text clipped - 40 lines] > not exist) between paragraphs so I can create the necessary bookmark. Any > ideas? Jezebel was telling us: Jezebel nous racontait que : > You'll make life easier for yourself if you can work entirely with > paragraphs rather than lines. As you've seen, the Word object model > doesn't actually include lines as such. Unless your paragraphs Until recently, this is what I also thought... The other day I stumbled upon something. There are Page and Line collections in Word... The page collection is under the Pane object, and the line collection is under the rectangle collection which is under the page object from the page collection. Play around with this code: '_______________________________________ Sub Test() Dim MyPane As Pane Dim MyPage As Page Dim MyRect As Rectangle Dim MyLine As Line Dim PaneCount As Long Dim PageCount As Long Dim RectCount As Long Dim LineCount As Long Dim i As Long PaneCount = ActiveWindow.Panes.Count Set MyPane = ActiveWindow.ActivePane PageCount = MyPane.Pages.Count Set MyPage = MyPane.Pages(1) RectCount = MyPage.Rectangles.Count Set MyRect = MyPage.Rectangles(1) LineCount = MyRect.Lines.Count Set MyLine = MyRect.Lines(1) For i = 1 To RectCount Set MyRect = MyPage.Rectangles(i) MsgBox MyRect.RectangleType '0 = Text range '1 = Shape '7 = System > Drawing layer??? Will generate an error on the next line. MyRect.Range.Select Next End Sub '_______________________________________ Just type gibberish for a few pages, and try the code. Then add an autoshape. You will go from 1 to 3 rectangles. One for the text on the page, one for the shape itself and a mysterious one that belongs to the System type. Then add a text box. You will now have 5 rectangles, as above, plus one for the textbox autoshape and one for the textbox text. Interestingly, it does not matter how many shapes/textboxes you add to the page, the system rectangle type is always the last one of the collection and it does not appear if you have only text on the page. Having just discovered those collections and never really having used them in "real life," I was wondering if you, or anybody else reading these lines, might have used them before, and thus could comment on their usefulness or drawbacks. If there are no real drawbacks, I think they offer interesting solutions for certain problems we might sometimes face. One drawback I can see is that these are new to Word 2003, so there might be problems with backward compatibility... SignatureSalut! _______________________________________ Jean-Guy Marcil - Word MVP jmarcilREMOVE@CAPSsympatico.caTHISTOO Word MVP site: http://www.word.mvps.org Interesting indeed. I've only just moved to W2003, so this is all new to me too. A couple of observations: - You have to be in Print Layout view for it to work. This could be a problem with remote automation. - There's something mysterious about these rectangles. I tried it with a plain page of text and got three rectangles all of type wdtextrectangle -- header, footer, and body in that order. Presumably there's some way to work out which is which but it doesn't leap out. Checking the .Top property, I guess. - As you observe, adding a textbox adds three more rectangles. The text box, its content, and this wierd wdSystem rectangle, which the documentation helpfully describes as 'Not applicable'. It seems to be a non-object -- in the collection, but not retrievable and none of the properties are valid. So you can indeed iterate the document's lines, using code like -- Sub IterateDocLines() Dim pPage As Word.Page Dim pLine As Word.Line For Each pPage In ActiveWindow.ActivePane.Pages For Each pLine In pPage.Rectangles(3).Lines Debug.Print pLine.Range Next Next End Sub (.. Rectangles(3) in my case because the documents have headers and footers.) Strange things are going to happen if you change the lines as you go (unless they are discrete paragraphs anyway) because changes will affect the following lines. In all, an interesting new feature. I'd suggest its value is for automated formatting rather than automated editing. Need to think about it some more. Thanks for pointing it out. > Jezebel was telling us: > Jezebel nous racontait que : [quoted text clipped - 70 lines] > One drawback I can see is that these are new to Word 2003, so there might be > problems with backward compatibility... Jezebel was telling us: Jezebel nous racontait que : > Interesting indeed. I've only just moved to W2003, so this is all new > to me too. A couple of observations: > > - You have to be in Print Layout view for it to work. This could be a > problem with remote automation. Right! You could force it with ActivePane.View... > - There's something mysterious about these rectangles. I tried it > with a plain page of text and got three rectangles all of type > wdtextrectangle -- header, footer, and body in that order. Presumably > there's some way to work out which is which but it doesn't leap out. > Checking the .Top property, I guess. Good catch, I had not tested it with headers/footers. It seems that header/footer always come before body text in the index enumeration. So that could help, if you knew there was a header/footer... > - As you observe, adding a textbox adds three more rectangles. The Slight correction: adding the *first* shape adds the extra "system" rectangle, all subsequent shapes do not. But this special rectangle is always the last one in the collection. > text box, its content, and this wierd wdSystem rectangle, which the > documentation helpfully describes as 'Not applicable'. It seems to be [quoted text clipped - 24 lines] > automated formatting rather than automated editing. Need to think > about it some more. Thanks for pointing it out. I think you are right about line editing... it would quickly become a mess. But I like the Page collection, you can now get a page range in a range object without using the selection object (.Bookmarks("\Page").Range ...etc.). SignatureSalut! _______________________________________ Jean-Guy Marcil - Word MVP jmarcilREMOVE@CAPSsympatico.caTHISTOO Word MVP site: http://www.word.mvps.org > Jezebel was telling us: > Jezebel nous racontait que : [quoted text clipped - 7 lines] > Right! > You could force it with ActivePane.View... Indeed. but that requires that you make the document visible, which slows things down and for some kinds of automation is precisely what you don't want to do. Jezebel, The snippet you suggested is working good, but not great :) Thank you! I find it appealing because it's clean and simple. I don't know what advantages it has over the Selection object, or if there are any pitfalls to the Paragraph object approach. Perhaps you could comment if and when you have a moment. One thing that I'm finding is that the "learning" loop I've coded using your suggestion (see below) fails to reach the end of some of my documents. The documents I'm running it against consist of simple lines of text terminated with a carriage return (ENTER key, Chr(13), etc.) There's no special formatting, graphics, idents, tabs, etc. After running the macro the IP is positioned at the start of line 39 on page ten of an eleven page document (there are 347 paragraphs and 547 lines in the document). If I copy the offending section, and include a couple lines of text above and below line 39, into a new document as unformatted text and run the macro, the IP is at the end of the document. If I copy the entire document and paste it into a new document as unformatted text, the IP is at line 40 on page ten after running the macro. If I do this again and run the macro, the IP is at line 41 on page ten. Can you provide any insight on what may be causing this? Sub IterateDocLines() Dim result As String Dim pPar As Word.Paragraph Selection.HomeKey Unit:=wdStory Selection.HomeKey Unit:=wdLine stepnumber = 0 For Each pPar In ActiveDocument.Paragraphs Selection.MoveRight Unit:=wdWord, Count:=1, Extend:=wdExtend result = Selection.Text Selection.MoveDown Next End Sub Thanks again for you suggestion, explanations (and patience)! ~ Dave > It doesn't work because you're simply moving downwards: if the last line > isn't empty, you'll end up at its start, which is not the end of document. [quoted text clipped - 39 lines] >> >> ~ Dave DJ, I am fairly new to this VBA business myself. Your code continues to run because your condition: ActiveDocument.Bookmarks("\Sel") = ActiveDocument.Bookmarks("\EndOfDoc") is never met. While your IP is moved down the page end line, it is never moved to the end of the document. I don't know why an error isn't generated when selection can not move further down. Perhaps one of the heavy hitters will be along to enlighten us. I don't know what you are trying to do exactly, but here is a example of code that will move down the document line by line until the last line is met then exit: Sub AutoExport() Dim numLines As Long Dim oBM As Bookmark Dim i As Long Set oBM = ActiveDocument.Bookmarks("\EndOfDoc") numLines = oBM.Range.Information(wdFirstCharacterLineNumber) i = 1 Selection.HomeKey Unit:=wdStory Do While i < numLines Selection.MoveDown Unit:=wdLine i = i + 1 Loop End Sub SignatureGreg Maxey/Word MVP A Peer in Peer to Peer Support > Hello Group! > [quoted text clipped - 22 lines] > > ~ Dave Hi, a million ways to do that. Here comes just one: Sub test666() Dim P1 As Long ' position 1 Dim P2 As Long ' position 2 Selection.ExtendMode = False Selection.HomeKey Unit:=wdStory P1 = Selection.Range.Start ActiveDocument.Bookmarks("\line").Select If Left(Selection.Text, 3) = "abc" Then MsgBox "gotcha" Exit Sub Else Selection.MoveDown Unit:=wdLine P2 = Selection.Range.Start While P1 <> P2 ActiveDocument.Bookmarks("\line").Select If Left(Selection.Text, 3) = "abc" Then MsgBox "gotcha" Exit Sub End If P1 = Selection.Range.Start Selection.MoveDown Unit:=wdLine P2 = Selection.Range.Start Wend End If MsgBox "nothing found" End Sub Greetings from Bavaria, Germany Helmut Weber, MVP "red.sys" & chr(64) & "t-online.de" Word XP, Win 98 http://word.mvps.org/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.