Delete single newline between tables

I'm fighting with a document automation system and can't seem to get
what I want from it directly, and am trying to switch over to
attacking it from the post processing side. The closest I can get the
tool to produce to the desired output is a series of single row tables
with a single newline between them.

Can I write a macro to detect that pattern and delete the new line
(merging the single row tables into the complete table I want)?

Helmut
Thu Nov 22 10:02:01 PST 2007

Hi Dan,

hmm....

maybe something like that:

Sub JoinTables()
Dim rTmp1 As Range
Dim rTmp2 As Range
Dim oTabl As Table
For Each oTabl In ActiveDocument.Tables
Set rTmp1 = oTabl.Range.Paragraphs.Last.Next.Range
' rtmp1 is the paragraph following the table
If rTmp1.Text = Chr(13) Then
If Not rTmp1.End = ActiveDocument.Range.End Then
Set rTmp2 = rTmp1.Next.Paragraphs(1).Range
' there is a paragraph more
If rTmp2.Information(wdWithInTable) Then
rTmp1.Delete
End If
End If
End If
Next
End Sub

The code processes each table in the doc.
Checks whether the paragraph following the table is empty.
Checks whether there is a further table following,
and if so,
replaces the paragraph following the first table
with nothing.

Seems pretty complicated to me,
but if it hepls, its alright.


--

Gruß

Helmut Weber, MVP WordVBA

Vista Small Business, Office XP

Dan
Wed Nov 21 10:23:57 PST 2007

On Nov 22, 1:02 pm, Helmut Weber <red....@t-online.de> wrote:
> Seems pretty complicated to me,
> but if it hepls, its alright.

Thanks, that worked. I fully agree about it being a bigger hammer
approach, but the tool itself provides VBA for cleanup, so the user
experience will still be the same. Generate and run a single cleanup
macro.

gordon(dot)bentleymix(at)gmail(dot)com>
Wed Nov 21 13:22:19 PST 2007

Dan,

I faced a similar problem with a document assembly tool called ActiveDocs.
The tool requires a selection prior to performing certain operations.
However, due to a limitation in Word, selecting a row or rows within a table
isn't recognised as a 'selection'.

To get around this problem I use an approach similar to yours: break the
table into a series of smaller tables with a blank line in between, and then
select the line before the table along with the table itself. Word is quite
happy to advertise this as a 'selection'. Of course, this means I also get a
similar result in the final document - a series of small tables separated by
a blank line when what I really want is one big table.

My solution is a bit of post-production VBA as well, but with a twist on
what Helmut has provided. I use a custom style for the blank line before the
table, and then run the following to clean up the blank lines:

Sub JoinTables ( )
Dim myPara as Paragraph
For Each myPara in ActiveDocument.Paragraphs
If myPara.Style="MyStyle" Then myPara.Range.Delete
Next myPara
End Sub

This solution is possibly a bit simpler to implement than Helmut's, and the
only drawback is that it can be a bit slow evaluating every paragraph in the
Paragraphs collection of a large document - but I imagine no slower than
evaluating every table in a similar doc.

BTW, the style I use for "MyStyle" is called "1pt Line" and uses the
definition "Normal + Line spacing: Exactly 1pt", but you can name and define
it any way you like - just as long as it's only used for the line before a
table. (The only reason I use this definition is so the document doesn't look
too odd if the user happens to see it in the background while the document is
being assembled.)

--
Cheers!
The Kiwi Koder


"Dan Neely" wrote:

> I'm fighting with a document automation system and can't seem to get
> what I want from it directly, and am trying to switch over to
> attacking it from the post processing side. The closest I can get the
> tool to produce to the desired output is a series of single row tables
> with a single newline between them.
>
> Can I write a macro to detect that pattern and delete the new line
> (merging the single row tables into the complete table I want)?
>

Russ
Wed Nov 21 13:43:02 PST 2007

Helmut,
Do you have the correct date on your computer?
I'm seeing your messages posted today as being posted "tomorrow" in my
newsgroup reader client.

> Hi Dan,
>
> hmm....
>
> maybe something like that:
>
> Sub JoinTables()
> Dim rTmp1 As Range
> Dim rTmp2 As Range
> Dim oTabl As Table
> For Each oTabl In ActiveDocument.Tables
> Set rTmp1 = oTabl.Range.Paragraphs.Last.Next.Range
> ' rtmp1 is the paragraph following the table
> If rTmp1.Text = Chr(13) Then
> If Not rTmp1.End = ActiveDocument.Range.End Then
> Set rTmp2 = rTmp1.Next.Paragraphs(1).Range
> ' there is a paragraph more
> If rTmp2.Information(wdWithInTable) Then
> rTmp1.Delete
> End If
> End If
> End If
> Next
> End Sub
>
> The code processes each table in the doc.
> Checks whether the paragraph following the table is empty.
> Checks whether there is a further table following,
> and if so,
> replaces the paragraph following the first table
> with nothing.
>
> Seems pretty complicated to me,
> but if it hepls, its alright.
>
>
> --
>
> Gruß
>
> Helmut Weber, MVP WordVBA
>
> Vista Small Business, Office XP

--
Russ

drsmN0SPAMikleAThotmailD0Tcom.INVALID

Russ
Wed Nov 21 14:27:25 PST 2007

The Kiwi Koder,
For post processing speed you might try this:

Sub Remove_Interstitial()
Dim aRange As Word.Range

Set aRange = ActiveDocument.Content
With aRange.Find
.Style = ActiveDocument.Styles("MyStyle")
.Text = "^13"
.Replacement.Text = ""
.Format = True
.MatchWildcards = True
.Execute Replace:=wdReplaceAll
End With
End Sub

> Dan,
>
> I faced a similar problem with a document assembly tool called ActiveDocs.
> The tool requires a selection prior to performing certain operations.
> However, due to a limitation in Word, selecting a row or rows within a table
> isn't recognised as a 'selection'.
>
> To get around this problem I use an approach similar to yours: break the
> table into a series of smaller tables with a blank line in between, and then
> select the line before the table along with the table itself. Word is quite
> happy to advertise this as a 'selection'. Of course, this means I also get a
> similar result in the final document - a series of small tables separated by
> a blank line when what I really want is one big table.
>
> My solution is a bit of post-production VBA as well, but with a twist on
> what Helmut has provided. I use a custom style for the blank line before the
> table, and then run the following to clean up the blank lines:
>
> Sub JoinTables ( )
> Dim myPara as Paragraph
> For Each myPara in ActiveDocument.Paragraphs
> If myPara.Style="MyStyle" Then myPara.Range.Delete
> Next myPara
> End Sub
>
> This solution is possibly a bit simpler to implement than Helmut's, and the
> only drawback is that it can be a bit slow evaluating every paragraph in the
> Paragraphs collection of a large document - but I imagine no slower than
> evaluating every table in a similar doc.
>
> BTW, the style I use for "MyStyle" is called "1pt Line" and uses the
> definition "Normal + Line spacing: Exactly 1pt", but you can name and define
> it any way you like - just as long as it's only used for the line before a
> table. (The only reason I use this definition is so the document doesn't look
> too odd if the user happens to see it in the background while the document is
> being assembled.)

--
Russ

drsmN0SPAMikleAThotmailD0Tcom.INVALID

HelmutWeber
Thu Nov 22 00:23:03 PST 2007

Hi Russ,

the other post was made from home,
and I'm sure, I got the right date and time there
as well as here in the office.

It is now 09:18 November 22nd.

Though I've discovered recently
that several answers were posted
before the occording questions...

--
Greetings from Bavaria, Germany
Helmut Weber, MVP WordVBA
"red.sys" & chr(64) & "t-online.de"
Word 2002, Windows 2000 (german versions)

Helmut
Thu Nov 22 07:42:19 PST 2007

Hi Russ,

>the other post was made from home,
>and I'm sure, I got the right date and time there

that's the thing with being sure...

I had got the wrong date at home.

Thx

--

Greetings from Bavaria, Germany

Helmut Weber, MVP WordVBA

Vista Small Business, Office XP

Russ
Thu Nov 22 12:24:09 PST 2007

To tweak my subroutine even more, you may want to turn off screen updating,
so that word doesn't have juggle the graphics display while lines are
deleting and tables are merging.

Application.ScreenUpdating = False
...remove gaps and merge
Application.ScreenUpdating = True

> The Kiwi Koder,
> For post processing speed you might try this:
>
> Sub Remove_Interstitial()
> Dim aRange As Word.Range
>
> Set aRange = ActiveDocument.Content
> With aRange.Find
> .Style = ActiveDocument.Styles("MyStyle")
> .Text = "^13"
> .Replacement.Text = ""
> .Format = True
> .MatchWildcards = True
> .Execute Replace:=wdReplaceAll
> End With
> End Sub
>
>> Dan,
>>
>> I faced a similar problem with a document assembly tool called ActiveDocs.
>> The tool requires a selection prior to performing certain operations.
>> However, due to a limitation in Word, selecting a row or rows within a table
>> isn't recognised as a 'selection'.
>>
>> To get around this problem I use an approach similar to yours: break the
>> table into a series of smaller tables with a blank line in between, and then
>> select the line before the table along with the table itself. Word is quite
>> happy to advertise this as a 'selection'. Of course, this means I also get a
>> similar result in the final document - a series of small tables separated by
>> a blank line when what I really want is one big table.
>>
>> My solution is a bit of post-production VBA as well, but with a twist on
>> what Helmut has provided. I use a custom style for the blank line before the
>> table, and then run the following to clean up the blank lines:
>>
>> Sub JoinTables ( )
>> Dim myPara as Paragraph
>> For Each myPara in ActiveDocument.Paragraphs
>> If myPara.Style="MyStyle" Then myPara.Range.Delete
>> Next myPara
>> End Sub
>>
>> This solution is possibly a bit simpler to implement than Helmut's, and the
>> only drawback is that it can be a bit slow evaluating every paragraph in the
>> Paragraphs collection of a large document - but I imagine no slower than
>> evaluating every table in a similar doc.
>>
>> BTW, the style I use for "MyStyle" is called "1pt Line" and uses the
>> definition "Normal + Line spacing: Exactly 1pt", but you can name and define
>> it any way you like - just as long as it's only used for the line before a
>> table. (The only reason I use this definition is so the document doesn't look
>> too odd if the user happens to see it in the background while the document is
>> being assembled.)

--
Russ

drsmN0SPAMikleAThotmailD0Tcom.INVALID

Dan
Mon Nov 26 06:24:05 PST 2007

On Nov 22, 3:24 pm, Russ <drsN0SPAMmi...@hotmailD0Tcom.INVALID> wrote:
> To tweak my subroutine even more, you may want to turn off screen updating,
> so that word doesn't have juggle the graphics display while lines are
> deleting and tables are merging.

I don't like the magic formatting option. There's too much risk of it
getting broken by an end user inserting boilerplate into the template
being used by the generation tool, or fiddling with the formatting.

> Application.ScreenUpdating = False
> ...remove gaps and merge
> Application.ScreenUpdating = True

With Helmut's solution this didn't add any speed to the runtime.

gordon(dot)bentleymix(at)gmail(dot)com>
Tue Nov 27 15:06:01 PST 2007

Dan,

I'm afraid I don't understand. How can there be any risk of the users
modifying anything in the _template_ during the document creation process?
Surely this process is automated, and during this process the document
automation system has complete control over the content of the
document/template. And if not, the "magic formatting" solution cannot present
any more risk than the "blank line between tables" solution. If the users can
touch the template prior to the document being created from it, then wouldn't
they be able to do something to make a blank line between tables no longer
blank?

Not that it matters really. If you're happy with Helmut's (excellent and
obviously very usable) solution then run with it. I just thought I'd offer an
alternative that uses a bit less code - and therefore might be a bit easier
to understand and maintain (14 lines of code, 3 declared objects, 3 nested
'If' statements vs 4 lines of code, 1 declared object, 1 'If' statement). And
for really large documents, I'm sure that Russ's solution would be quicker
than either mine or Helmut's since using the Find method is undoubtedly more
efficient that cycling through the Paragraphs collection. (Plus it's just a
simple to understand and maintain - 1 declared object, no 'If' statements or
loops and an intuitively obvious 'With' statement.)

BTW, Russ: If I do run into a situation where performance becomes an issue,
I'll certainly keep your solution in mind. So far most of my docs have been
less than 20 pages, so speed hasn't become a problem. Thanks for the tip!

--
Cheers!
The Kiwi Koder

"Dan Neely" wrote:

>
> I don't like the magic formatting option. There's too much risk of it
> getting broken by an end user inserting boilerplate into the template
> being used by the generation tool, or fiddling with the formatting.

Dan
Wed Nov 28 06:07:23 PST 2007

On Nov 27, 6:06 pm, NZ VBA Developer
<gordon(dot)bentleymix(at)gmail(dot)com> wrote:
> Dan,
>
> I'm afraid I don't understand. How can there be any risk of the users
> modifying anything in the _template_ during the document creation process?
> Surely this process is automated, and during this process the document
> automation system has complete control over the content of the
> document/template. And if not, the "magic formatting" solution cannot present
> any more risk than the "blank line between tables" solution. If the users can
> touch the template prior to the document being created from it, then wouldn't
> they be able to do something to make a blank line between tables no longer
> blank?

The tables are automatically created by the generation tool along with
the newline between, there aren't multiples in the template to get
scrambled. There's no way to get rid of the newline itself, if there
was I wouldn't need to jump this hoop to begin with. But the style
assigned to the paragraph marker outside the single row in the
template is alterable by the user and vulnerable to being messed with.


At present the project specific boiler plate type material still needs
to be manually added to the template before it's ran. That might
change at some point in the future; but since it, unlike the contents
of the tables, is essentially static there's relatively little gain to
be had there.