Delete single newline between tables

[Dan Neely]

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)?

 

[Dan Neely]

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.

 

[NZ VBA Developer]

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]

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.

 

[Russ]

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

 

[Helmut Weber]

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...

 

[Helmut Weber]

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

 

[Helmut Weber]

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]

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

 

[Dan Neely]

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.

 

[NZ VBA Developer]

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!

 

[Dan Neely]

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.