LinkToPrevious

[glencoe]

Hello,

I read in the help that HeaderFooter.LinkToPrevious is supposed to be a read/write boolean. In other words, I should be able to use this to check whether a header is linked or not to the previous one, right?
I work in a Word document and move from section to section. In every section, I need to check the state of the header (when it exists). That's where I use the lines

Dim i, SectionCount as integer

SectionCount = ActiveDocument.Sections.Count
For i = 1 to SectionCount
Selection.GoTo What:=wdGoToSection, Which:=wdGoToAbsolute, Count:=i
ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageHeader
If Selection.HeaderFooter.LinkToPrevious = False Then
'Do something
end if
next i

Now, the "if" line seems to give more or less random results. So I am wondering if this property should be used only with the Headers property, but I fear it would be more difficult to do the same.
Any thought?

[fumei]

1. "the state of the header (when it exists)" Headers ALWAYS exist. It is not possible for Headers to not exist.
2. EVERY section ALWAYS has three headers and three footers. Always.
3. using Selection to work with Sections headers is a poor idea. you can action all the headers in any section directly.
4. your IF statement will only ever action the first header Selection come to. If that is the FirstPage, that is what actions; if that Section does not have FirstPage active, then Primary header gets actioned. This may explain your "random" results.

perhaps explain what it is - exactly - you are trying to do.

[glencoe]

You are perfectly correct indeed...
Is there a way to know what type of header the cursor is in? That would actually help me a lot. I read indeed about the different types of headers. Basically, I am searching for specific strings of characters in the headers and footers, but I first need to make sure the header (or footer) the cursor is in is not linked to the previous one.
Therefore, I need to:
- find out what kind of header (among the 3 possible choices) I am in
- find out the state (linked or not) of the header.

I guess that I would have to use the form .Headers() to work this out?

[fumei]

Again, please state - exactly - what it is you want to happen.

Again, using Selection is not usually a good idea. Selection means what header you are "in". If you do not use Selection, you are never "in" any of them, but you can still perform action on ANY of them directly.

With code, I am never "in" any header; I never use View. So I never need to know what type of header the cursor is in...the cursor is never "in" one.

[glencoe]

To summarize what I am trying to achieve, I need to focus on all headers/footers of the document to search for specific strings and do some actions depending on the strings I find. I only want to skip those headers and footers that are linked, to save processing time as I know they have already been processed before.
I thought that going through the different sections would be a good start, so I simply go to the header of each section to process whatever I need to do. If the header is linked to the previous one, I want to skip it. That's it.

I am perfectly that my code may not be the best, and that most of you would be able to improve it a lot. I am not a professional programmer! ;-)

Now, when the selection (i.e. the strings I am playing with) is in a header, I need to know what state the header is. I obviously got confused by the vba help, and I understand my method is completely wrong.
Please advise. What would be the best and most efficient way to do what I need?

[fumei]

How can I put this? Please state - exactly - what it is you want to happen. Exactly means...exactly. For example, you state you want to find specific strings. OK. Where are you getting those strings? Are you selecting some text elsewhere in the document and then using THAT to search for? Is the string from a different document? Is there going to be more than one string to search for?

 
Sub ReplaceStuff()
Dim strCheck As String
Dim oHF As HeaderFooter
Dim oSection As Section
strCheck = "old stuff"
For Each oSection In ActiveDocument.Sections
   For Each oHF In oSection.Headers
      If InStr(1, oHF.Range.Text, "old stuff") Then
         oHF.Range.Text = _
            Replace(oHF.Range.Text, "old stuff", "new and improved stuff")
      End If
   Next
Next
End Sub

The above goes through ALL headers and if the string "old stuff" is there, it is replaced with "new and improved stuff". No Selection. No View. Note you can also use Find\Replace. But again, what - exactly - is supposed to happen. BTW, I am not a professional programmer either. However, a basis for any code is to define - exactly - what it is that is supposed to happen.

Note that the code does not test for Link to Previous, because for what it does, that is not needed. However, maybe you DO need it, it is impossible to tell without knowing what exactly is supposed to happen.

[glencoe]

fumei,
I appreciate so much your help! Thanks also for pushing me... I don't always get the whole point, and though I know where I am heading, I don't always understand what the best path is...

I'll try to be more specific. The strings I search for are given by the user. I don't actually know what they are, since they can be different every time. I can only say that they are actually tags that surround text. I have to find 2 sets of strings, a bit like brackets (opening tag, closing tag) and if everything seems fine (those tags are found in the correct order, i.e. if 2 opening tags are found consecutively with no closing tag in-between, they are ignored), the text is processed through another function (let's say it is highlighted and tags are deleted).

As a side note, those tags have a minimum of 2 characters each (e.g. #< and #>), but they can also be the same ones (e.g. ### and ###), in which case I only make sure I have an even number of tags within the header, to avoid processing the wrong text.
The tags are sent to the function through a string, a bit like you did with strCheck (though I found it funny that you actually don't use it in your example, but I got your point).

Now, I do love your approach, but I have a few questions/concerns with it:
- inStr is a great function indeed that I could make use of in other cases (and I certainly will), but is there a way to keep track of the number of replacements your algorithm is doing, as I need to keep track of it?
- using the whole header range is very interesting, but replacing it actually overwrites the whole header, including any text box. That doesn't work in my case as I need to preserve everything but the strings I am looking for.
- though your "if" line can go fast indeed, I do have a concern with processing speed, since the documents that are used with the macro can have any number of pages/sections (from 1 to 1000's of pages), in which case I want to avoid searching those sections that are linked, since the strings have already been searched for in the parent sections. Consider the fact that if a 500 pages document has 100 different sections (i.e. say 100 different headers and 400 "linked headers"), going through each header would be time-consuming, while skipping those linked headers would help processing the algorithm faster. I assume that using the line "for each oHF in oSection.Headers" goes indeed into each header, whatever it is, and whatever its state is. So it is really great, but not perfect in my case, since it may fall in a time-consuming approach, which I want to avoid...

I hope my explanation is now clear enough. But even if that doesn't solve my issue yet, you did give me a few interesting ideas that I may use elsewhere in my macro! :-)

[glencoe]

As a side note, I found on the web (http://word.mvps.org/faqs/MacrosVBA/...placements.htm) a method that can be used to keep track of the number of replacements done through the function Replace(), so this part is not an issue anymore.
Now, I still have the same concern regarding processing speed in big documents, as all headers are checked without consideration to their state. If anyone can help on this part, it would be great...
Using the algorithm fumei wrote, I assume there must be a way to add a few lines to check if ".LinkToPrevious = False" in the different headers? I'm not quite sure how to write this, as there are 3 possible headers in a Word file...

[glencoe]

Can anyone confirm that this procedure would be skipping any linked header, and process only "parent" headers?

Dim oHF As HeaderFooter
Dim oSection As Section
Dim LinkToPreviousFlag As Integer
For Each oSection In ActiveDocument.Sections
For Each oHF In oSection.Headers
LinkToPreviousFlag = 0
If oSection.Headers(wdHeaderFooterPrimary).LinkToPrevious = True Then
LinkToPreviousFlag = 1
ElseIf oSection.Headers(wdHeaderFooterFirstPage).LinkToPrevious = True Then
LinkToPreviousFlag = 1
ElseIf oSection.Headers(wdHeaderFooterEvenPages).LinkToPrevious = True Then
LinkToPreviousFlag = 1
End If

If LinkToPreviousFlag = 0 Then 'process only the section if it is not linked to the previous one
oHF.Range.Select
'process whatever is required
End If
Next oHF
Next oSection

Please advise!
Also, I am wondering if there is a way to match the "section number" oSection with the corresponding section in Word? I noticed that this procedure gives more sections than the actual Word doc contains. I assume this is because each header/footer is considered as a unique section, which is not the same as a Word section.

[fumei]

Yikes you need to understand headers and sections! But first:

I still have the same concern regarding processing speed in big documents, as all headers are checked without consideration to their state.

Perhaps, but checking their state also takes processing. I am not sure how much a InStr test takes more than a If LinkToPrevious = False test.

- using the whole header range is very interesting, but replacing it actually overwrites the whole header, including any text box.

First of you never mentioned any text box. Second my good (sans any textbox) does not replace the whole header, only the "old stuff" string. Everything else remains.

I remain a bit off put by what SEEMS to be happening. Let me see if I have this.

You have users that will VERY OFTEN need to change existing headers. I say very often because if it is NOT often, then are you concerned about performance times. if it is a uncommon event, hey start it and go to lunch. Big deal.

The user will use RANDOM strings of text.

I don't actually know what they are, since they can be different every time.

So...there is no logic behind what the string will be. Right?

If any given section header is linked to the previous (same) header type in the previous section it is assumed that that header is correct and NO test of the current header content needs to be done. Really? Not sure why I am sceptical about that, but what do I know? BTW "for in the parent sections" - there is no such thing as "parent" sections

Somehow the user can get a search string into the procedure (although how is not stated...inputbox, the user selects some text in the document and THAT is used???), and in some manner "tags" are added to that string.

Consider the fact that if a 500 pages document has 100 different sections (i.e. say 100 different headers and 400 "linked headers"),

Umm, that is not a fact. First, the number of pages is completely irrelevant. You seem to think there is a header for each page. Not so. The number of pages has nothing to do with sections. Nothing. You can have a 1000 page document with ONE section, in which case the code will run pretty darn fast. Secondly a document with 100 sections will have 300 headers whether they are linked, or not. LinkToPrevious has NOTHING to do with the number of headers. Or the number of pages.

Anyway, you seem to be moved along fairly well. I am not sure I can help much more.

[fumei]

Can anyone confirm that this procedure would be skipping any linked header, and process only "parent" headers?

Dim oHF As HeaderFooter
Dim oSection As Section
Dim LinkToPreviousFlag As Integer
For Each oSection In ActiveDocument.Sections
For Each oHF In oSection.Headers
LinkToPreviousFlag = 0
If oSection.Headers(wdHeaderFooterPrimary).LinkToPrevious = True Then
LinkToPreviousFlag = 1
ElseIf oSection.Headers(wdHeaderFooterFirstPage).LinkToPrevious = True Then
LinkToPreviousFlag = 1
ElseIf oSection.Headers(wdHeaderFooterEvenPages).LinkToPrevious = True Then
LinkToPreviousFlag = 1
End If

If LinkToPreviousFlag = 0 Then 'process only the section if it is not linked to the previous one
oHF.Range.Select
'process whatever is required
End If
Next oHF
Next oSection

Please advise!
Also, I am wondering if there is a way to match the "section number" oSection with the corresponding section in Word? I noticed that this procedure gives more sections than the actual Word doc contains. I assume this is because each header/footer is considered as a unique section, which is not the same as a Word section.

Yikes. OK. each header/footer is NOT a unique section. Each section has three headers and three footers. Always. Two of them can used, or not. One is ALWAYS used...although its displayed name changes.

I noticed that this procedure gives more sections than the actual Word doc

Did you now? What makes you say that?

[fumei]

BTW, please use the code tags when posting code.

Also, why are you selecting ANYTHING???????

 oHF.Range.Select

You do not need to select anything, as stated previously, you can action them directly.

[glencoe]

checking their state also takes processing. I am not sure how much a InStr test takes more than a If LinkToPrevious = False test.

That's a good point indeed... One or the other does take time, it is pretty hard to calculate this. I would need to have a huge document (with a big number of different headers) in order to see if there is any difference!

First of you never mentioned any text box. Second my good (sans any textbox) does not replace the whole header, only the "old stuff" string. Everything else remains.

You're right, I never mentioned any text box. It just popped up in my mind when I did a test in a document that happened to have text boxes in the header. And as a result, I have to say (why, I am not sure) that your nice procedure did delete (or, should I say, seems to delete, as I couldn't see them anymore) those text boxes. I assume (don't get me wrong, as you understand, I am quite a beginner here) that this is due to the line "oHF.Range.Select", which selects the whole header, right?

You have users that will VERY OFTEN need to change existing headers. I say very often because if it is NOT often, then are you concerned about performance times. if it is a uncommon event, hey start it and go to lunch. Big deal.
The user will use RANDOM strings of text.
So...there is no logic behind what the string will be. Right?

One more information about what the documents are: they are translated documents and tags are added by the user in the translation software as a "comment marker". In other words, the string that is between the "tags" is something the user wants to double check later on in the final Word file. Now, why tags are chosen by the user is because there always is a risk to use an internal tag used by the translation software, that will compromise, or be confused as a "marker tag". Since the files come from different translation software (just to add to the complexity), I can't use a "fixed" tag, as it may be already used by the software (how could I guess?). I hope you get my point. Now, I assume that most of the time, tags will look similar to ## ##, #< #>, ?%$ $%? or strings like that (any combination of symbols, starting with 2 characters), since those are examples given to the users. As a side note, the editor of vbaexpress does use tags like those "QUOTES", that could be considered as "comment tags" in my situation, if you get my point.

If any given section header is linked to the previous (same) header type in the previous section it is assumed that that header is correct and NO test of the current header content needs to be done. Really? Not sure why I am sceptical about that, but what do I know? BTW "for in the parent sections" - there is no such thing as "parent" sections

My understanding was that, in a Word file, you would have headers that are either linked to the previous one, or not linked (so new, different, headers). If the algorithm checks every single header and meets a new header, it will process it, then any consecutive linked header will be processed at the same time, right? So there is no need to process them further, since what needed to be done (tags checked/deleted) is already done...

Somehow the user can get a search string into the procedure (although how is not stated...inputbox, the user selects some text in the document and THAT is used???), and in some manner "tags" are added to that string.

I guess that you now understand how tags are added to the file. Then, there is an interface that the user runs to select what function needs to be processed in the file, among which the procedure we are currently talking about (i.e. check and delete any "comment tag" and process the text in-between). So yes, there is an input box in which the user types tags that were used in the translation software to add comments.

Umm, that is not a fact. First, the number of pages is completely irrelevant. You seem to think there is a header for each page. Not so. The number of pages has nothing to do with sections. Nothing. You can have a 1000 page document with ONE section, in which case the code will run pretty darn fast. Secondly a document with 100 sections will have 300 headers whether they are linked, or not. LinkToPrevious has NOTHING to do with the number of headers. Or the number of pages.

I understand that, I was only trying to give you an example of what may happen with a big document. I do see from time to time big documents myself (say 300 pages, with different sections), so I know I have to take this into account. As for stating that there is a header for each page, I was also referring to your previous statement that

Headers ALWAYS exist. It is not possible for Headers to not exist. EVERY section ALWAYS has three headers and three footers. Always.

. Whether a header is not shown doesn't mean that it doesn't exist, so I was wondering if the code you suggested would be going through each of them, whether it is displayed or not in the file.

[glencoe]

Yikes. OK. each header/footer is NOT a unique section. Each section has three headers and three footers. Always. Two of them can used, or not. One is ALWAYS used...although its displayed name changes.

That was more clear to me indeed, though I may not have expressed myself properly.

I created a small 4 pages Word file as a test, including 3 different sections (with 3 different headers). Running your procedure (step by step) went in the loop 9 times, so I found it confusing, but thinking about it, I assume this is because each section has 3 header.

[glencoe]

BTW, please use the code tags when posting code.

I just found the tags, sorry! ;-)

Also, why are you selecting ANYTHING???????

 oHF.Range.Select

Because I took this line in your code. I thought I was selecting the whole header with it...

You do not need to select anything, as stated previously, you can action them directly.

I'd love to, but as I said, your code seems to delete text boxes, so there must be something I don't get...

[fumei]

Yes, as stated, each section has three headers: Primary, FirstPage and OddEven. If the SETTING for first page and OddEven are unchecked (in Page Setting), then Primary is displayed for all pages in the section. Obviously if First Page is checked, then FirstPage is displayed; if Different Odd Even is checked OddEven is displayed for Even pages, and Primary is displayed for odd pages.

Because I took this line in your code. I thought I was selecting the whole header with it...

It does select the whole header, but I never used that in my code

So there could be these comment tags in the header? As well as textboxes. This adds a fairly large amount of complexity. I am still confused about things. Are these `tags`to remain...or not.

[glencoe]

If the SETTING for first page and OddEven are unchecked (in Page Setting), then Primary is displayed for all pages in the section. Obviously if First Page is checked, then FirstPage is displayed; if Different Odd Even is checked OddEven is displayed for Even pages, and Primary is displayed for odd pages.

So, if I check (through the code) the page settings of the document, I should be able to find out whether First Page or OddEven is checked, and therefore use it (or not) in my code?

It does select the whole header, but I never used that in my code

Humpf... you're right, I copied the first part (oFF.Range) and selected the header instead.

So there could be these comment tags in the header? As well as textboxes. This adds a fairly large amount of complexity. I am still confused about things. Are these `tags`to remain...or not.

Basically, anything that may exist in a Word file may happen to be in the documents processed by the algorithm, so yes, text boxes should be checked in headers, BUT I am not worrying about those right now, since I already wrote a while ago a procedure that goes through each text box (in the headers/footers and in the main body), so I will implement this later on, once the main part related to the headers is fixed.
As for tags, my first point is to:
1)a) Make sure tags are found in an even number (if both opening/closing tags are the same),
OR
1b) Make sure tags are found in the correct order (i.e. opening tag, always followed by a closing tag BEFORE another opening tag is found, if both tags are different)
2) Delete those tags and highlight text in-between (I know how to do it)

So, I'd love to stick to your great procedure, but my statement in 1b) makes me think I cannot process the algorithm "blindly", without checking the order first, in which case I need to consider some extra lines for that. I already got something working, but my code is being done with selections (which you want to avoid, as I understand) rather than actioning directly all headers.
Also, because text boxes may exist in headers, I guess that I cannot use the "oHF.Range.Text" function either...

Sorry for being so picky and making things complicated, but I must say that you're really kind, trying to help me with my issue!

[fumei]

I have to take a break from this, now that I know that opening and closing tags are involved. This kind of stuff has come up many time (mostly by people who try to pretend that Word is some kind of HTML editor). It has always been a royal pain, ridiculously complicated and tricky to get right. It certainly moves it well away from the original impression of a normal string. Working with tags is not normal. They give me a headache.

I have to say that having such tags in the header at all is an abomination. Yuck. Bleeech. BTW, checking the order is not much help when you are also tossing textboxes into the mix. Bleeech.

[glencoe]

LOLLLLLLL!!!
Well, I certainly don't want to give you more headaches (at least you understand what I am going through). Trying hard to get things as simple as possible, but those text boxes + tags being potentially mixed up are definitely a pain...
I have to use those tags as some translation software don't enable the user to comment anything so far, so those tags are a trick users found to get comments through.
BTW, if you want to work with "normal strings", it would work exactly the same way, as those tags do appear as strings in Word, and not like HTML tags!

Anyway, I'll try to work from the few good tips you gave me, and we will see how things go... Thanks so much for your help!

[fumei]

Why on earth are users making any comments on what is in a header!!!! That is absurd. It is not their document, tell them to mind their own business. Just kidding.

Yes, I know the string with the tags are normal strings, it is annoying thing of having test random length starting and ending portions.