Automatically Assign Keep WIth Next (2003/SP2)

Topic

New Reply

I find that whenever I end a sentence with a colon it’s almost always to introduce a procedural step or a list of bullets, the first line of which I do not want to start on a new page. Rather than having to assign the KWN attribute or create a new style, is there a way to tell Word to automatically turn on KWN whenever a sentence ends with a colon?

Reply | Quote

Replies

I can’t think of any good way to do that. (AutoText can’t change formatting, AutoFormat As You Type doesn’t seem flexible enough, and creating a global macro to monitor every keystroke to watch for this would be overkill.)

You could create a macro that toggles the Keep with Next property and assign it to a keyboard shortcut for easier access.

Reply | Quote

Thanks, Jefferson. The method you described is what I currently use. It’s fast and easy, but I was wondering if there was a macro that could allow me to be even lazier

Reply | Quote

This macro will loop through a document and assign KWN to each paragraph that ends with a colon:

    Dim oFind As Word.Find
    Set oFind = Selection.Find
    oFind.Text = ":^p"
    oFind.ClearFormatting
    Do While oFind.Execute = True
        Selection.ParagraphFormat.KeepWithNext = True
    Loop
    Set oFind = Nothing

Reply | Quote

Thanks a lot, Steve, for the macro that assigns Keep WIth Next to all sentences ending with a colon. It’s going to get a lot of use in the lengthy user manuals I edit. A real time-saver for sure!

Reply | Quote

You may know this already, but I should have noted that Selection.Find is “sticky” in the sense that it retains various settings from one use to the next. So if you run the macro I posted and your previous search was limited to bold text, the macro will only find paragraphs ending in colons where the font at that point is bold.

To avoid this, it’s good practice to “clear” Selection.Find before you use it. Just adding Selection.Find.ClearFormatting may be good enough for your purposes (and I’ll be editing my previous post to add that line).

But if you want to be more thorough, you may want to create a separate “SetSearchDefaults” macro along the following lines and call it at the start of any macro that uses Selection.Find:

    With Selection.Find
        .ClearFormatting
        .Replacement.ClearFormatting
        If .Format = True Then
            .Format = False
        End If
        If .Forward = False Then
            .Forward = True
        End If
        If .Wrap  wdFindStop Then
            .Wrap = wdFindStop
        End If
        If .MatchCase = True Then
            .MatchCase = False
        End If
        If .MatchWholeWord = True Then
            .MatchWholeWord = False
        End If
        If .MatchWildcards = True Then
            .MatchWildcards = False
        End If
        If .MatchSoundsLike = True Then
            .MatchSoundsLike = False
        End If
        If .MatchAllWordForms = True Then
            .MatchAllWordForms = False
        End If
    End With

Reply | Quote

I’m wondering why you bother with the If tests if you are going to set it to the opposite anyway?

Have you noticed a time lag in changing the settings that is not evident in the If statement? OR Are you only setting the sticky settings when they are not Nothing (the third Boolean possibility)?

Reply | Quote

I’m not completely consistent on this issue, but my general prejudice (especially in “utility” macros that are going to see a lot of use because they get called by lots of other macros) is to avoid having Word actually do anything that isn’t necessary.

As one example, and as you probably know, applying a style to a paragraph can result in a blow-out of manual formatting that applies to more than 50% of the paragraph. And as you probably also know, if you apply a style to a paragraph with VBA, Word will re-apply the style (and potentially blow out manual formatting) even if the paragraph is already that same style.

Now, in the case you’ve specifically questioned, the unnecessary “re-application” I’m avoiding involves the Selection.Find object, rather than the document itself, and I’m not aware of any unwanted “side effects” (like the manual re-formatting problem) that might result from unnecessary manipulation of the .Find object, so I’ll grant you that my approach may well be overkill in that case. Still, it can’t hurt, and I guess the general rule would still apply — that the less a macro actually does, the less chance there is of an error.

Reply | Quote

I *think* that Andrew meant the following (he’ll correct me if I’m wrong): instead of

If .Format = True Then
.Format = False
End If

you could have used

.Format = False

The end result will be the same, and one wonders whether the time won by not setting .Format to False if it wasn’t false already outweighs the time lost by the potentially unnecessary If statement.

Reply | Quote

I think I interpreted Andrew’s post the same way you did. If .Format is already False and I use the simpler approach, Word may “reset” .Format. (I don’t know that it does, but I know it resets a paragraph’s style when you apply a style to a paragraph that already has that same style.) I agree that the “end result” is the same, but in one case Word has left the .Find object untouched and in the other case Word has performed an operation on the object.

In the case of a style reset, performing the operation can lead to unwanted consequences. As I said in my earlier post, I don’t know that there’s really any possibility of unwanted consequences (or errors) when Word “resets” a property of the .Find object, so my If tests may well be overkill..

Reply | Quote

No, I don’t think resetting properties of the Find object can have any undesired consequences. So in this situation, I’d opt for the shorter version.

Reply | Quote

OK, thanks for taking the time to explain this, I can understand your reasoning now. Your methodology is more evolved than mine so you would tend to avoid more unforeseen events than I would typically encounter.

I would have to say that I nearly always take the shortest path when coding and only deal with the unforeseen problems which become evident during testing. If a problem hasn’t become evident in my limited testing then I have no qualms about letting others do the more detailed testing for me

Following your reasoning in the specific case which we are talking about, I would see your methodology being far more useful on the Replace settings rather than the Find settings. I remain unconvinced that your effort on the Find settings is warranted – but can see now the principle of why you are doing it. The only case where I (personally) would make a similar effort is where I wanted to leave the find settings in the same start state after my macro as they were prior to the macro running. Again, I tend to fall onto the laziness side for that too and don’t generally bother with that either.

Reply | Quote