Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VBA statement to determine if current location is in a table? 1

Status
Not open for further replies.

Walipala

Technical User
Jan 5, 2007
21
US
I'm trying to write a macro in Word 2003 for determining if the cursor's current position is located within a table. Anyone know of a sure-fire "isTable=True" type statement in VBA?

Specifically, what I'm trying to do is navigate to the beginning of a document, then if the beginning of the doc is a table, delete the table and move on.

Below is the code I have so far. I would like to replace the "this is within a table" part with something that works. One thing to know about the table in question is that it has vertically merged rows (which is part of the reason I want to remove it.)

Sub CoverTableDelete()

Selection.HomeKey Unit:=wdStory
If [this is within a table] = True Then
Selection.Tables(1).Select
Selection.Tables(1).Delete
End If
...

End Sub
 
BTW: you do not need to select the table to delete it. In fact, doing so is a waste of resources.
Code:
Selection.HomeKey Unit:=wdStory
If Selection.Information(wdWithInTable) = True Then
    Selection.Tables(1).Delete
End If[/quote]

Gerry
[url=http://www3.telus.net/public/fumei/]My paintings and sculpture[/url]
 
Thanks Gerry. Actually I didn't really do that deliberately. I just recorded those macro steps via the keystrokes:

Alt-A --> D --> T

I guess when you do that it builds in the SELECT for you. Thanks for the tip though.
 
This is important. ALL code steps/instructions created by recording use Selection. Recorded macros never use Range objects. That is because recorded macros are, well recorded. They are the steps you take with the user interface.

Further, recorded macros often add a large amount of extra instructions that have nothing to do with what you actually want. It is not uncommon to be able to delete half of the code from recorded macros because

Recording macros is great for figuring out basics, and what is mostly going on, but to go deeper you need to look at the Object Model. There are things available - efficient use of Ranges for one - that can not be accessed by recording.

Here is an example. BOTH of these do exactly the same thing. They put the text "This is text in the footer of Section 1", into the footer of Section 1.

Recorded Macro
Code:
Sub FooterText()

' Macro recorded 1/8/2007 by Gerry
'
    If ActiveWindow.View.SplitSpecial <> wdPaneNone Then
        ActiveWindow.Panes(2).Close
    End If
    If ActiveWindow.ActivePane.View.Type = wdNormalView Or ActiveWindow. _
        ActivePane.View.Type = wdOutlineView Then
        ActiveWindow.ActivePane.View.Type = wdPrintView
    End If
    ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageHeader
    If Selection.HeaderFooter.IsHeader = True Then
        ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageFooter
    Else
        ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageHeader
    End If
    Selection.TypeText Text:="This is text in the footer of Section 1"
    ActiveWindow.ActivePane.View.SeekView = wdSeekMainDocument
End Sub

Versus Written Macro:
Code:
Sub Alternative()
ActiveDocument.Sections(1).Footers(wdHeaderFooterPrimary).Range.Text = _
    "This is text in the footer of Section 1"
End Sub

However, recording is certainly where we all start.

Gerry
My paintings and sculpture
 
Thanks again. Wow. You can sure cut out a lot of overhead if you know what you are doing and can just program how you want things to be, coding from the bottom up. I wish I was better at VBA. As a tech writer I guess I should be, but I've gotten away using macros only to do little tasks like applying keep-with-next to selected paragraphs, updating page headers, etc.

If I may ask a dumb question, did those 'if' and 'if-else' statements appear in the code as a result of the key strokes, or did you add that logic in later?
 
It is not a dumb question. You mean in the recorded macro code? I guess that is what you are asking. The answer is, yes the If..Else statements come from the actions taken (clicks and keystrokes). I recorded the macro precisely as follows.

1. Clicked Tools > Macro > Record New Macro
2. Changed the macro title to "FooterText"
3. Clicked OK.
4. Clicked View > Headerfooter
5. Clicked Switch between Header and Footer button
6. Typed "This is text in the footer of Section 1"
7. Clicked Close on the HeaderFooter toolbar
8. Clicked the Stop button on the macro recorder

The code in Sub FooterText() above is the result. I changed nothing, added nothing. This is actually my point. Recording macros records what you DO. Now what you DO may require certain states and conditions, and the code takes care of that. I will try to break this down in more detail. You start to record the macro....

You click View > Headerfooter.

To view headerfooters, you must be in PrintView, so VBA checks to see what view you are in, and makes sure you are in PrintView.
Code:
If ActiveWindow.View.SplitSpecial <> wdPaneNone Then
        ActiveWindow.Panes(2).Close
    End If
If ActiveWindow.ActivePane.View.Type = wdNormalView Or ActiveWindow. _
        ActivePane.View.Type = wdOutlineView Then
        [b]ActiveWindow.ActivePane.View.Type = wdPrintView[/b]
End If

It then makes the View the current header.
Code:
    ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageHeader
All of this is caused by clicking View > Headerfooter.

Clicking Switch from Header and Footer causes VBA to check if the View is Header (the .IsHeader), and if it is, switch to Footer.
Code:
If Selection.HeaderFooter.IsHeader = True Then
        ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageFooter
Else
        ActiveWindow.ActivePane.View.SeekView = wdSeekCurrentPageHeader
End If
Then typing the text:
Code:
Selection.TypeText Text:="This is text in the footer of Section 1"
and clicking the Close button:
Code:
    ActiveWindow.ActivePane.View.SeekView = wdSeekMainDocument

The code results from the actions taken, based on the logic built into the Object Model. Such as to View headers and footers you must be in PrintView.

The written code must, obviously, also use the appropriate logic of the Object Model. The difference is that the written macro uses a different object, to get the same result.

The recorded macro uses View - so the user interface is actioned so you can SEE the header, then change to footer, so you can type the text ("This is text in the footer of Section 1") into the footer. The recorded code results from the logic requirements of those steps.

The written macro uses the footer object itself and simply states its text IS "This is text in the footer of Section 1".

This may be a subtle difference, but recording macros creates code that (in this case) makes the footer text "xxxxxx". There is a step by step actioning to get there. Multiple steps are need to do that.

With the written code, there is ONE action, ONE Write operation. The footer text IS "This is text in the footer of Section 1".

Now some will say (with justification) that this matters little with the power and speed of current machines. This is true, and I admit I am an old fart from the time when every single I/O (read and write operations) counted.

Still, I believe that, as much as possible, we should try and write code that is clear, AND efficient.

Enough. I have gone on waaaaaay too much.

Gerry
My paintings and sculpture
 
Thanks for the thorough reply Gerry, and sorry for the late response. I'm trying to get in the habit of trimming the fat from these macros.
 
Thanks Gerry, your explanation was most illuminating. I understand better now.


Gavin
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top