Selecting table column
Howard Kaikow
table is ALL in 1 row or all in 1 column.
No problem doing this for rows. However, when I select a column, even tho it
looks correct on the screen, the range is internally set to include nearly
the whole table.
So when I do an Inrange on what I thought was the column's range, the test
is almost always True, even when cells are selected in more than 1 column.
Am I missing a step?
Sub TestSelectColumn()
' Must have cells selected in a table
' Save original selection range
Set rngTest = Selection.Range
' if more than 1 row, use only 1st
rngTest.Rows(1).Select
' Selection.SelectRow
' save row range
Set rngRow = Selection.Range
' if more than 1 column, use only 1st
rngTest.Columns(1).Select
' Selection.SelectColumn
' save column range
Set rngColumn = Selection.Range
MsgBox rngTest.Start & ":" & rngTest.End & vbCr & _
rngRow.Start & ":" & rngRow.End & vbCr & _
rngColumn.Start & ":" & rngColumn.End
bolRow = False
bolColumn = False
If rngTest.InRange(rngRow) Then
' Selection is all in 1 row
bolRow = True
End If
If rngTest.InRange(rngColumn) Then
' selection is all in 1 column
bolColumn = True
End If
MsgBox bolRow & "," & bolColumn
rngRow.Select
rngColumn.Select
rngTest.Select 'Original selection
End
With Selection.Tables(1)
For lngRow = 1 To .Rows.Count
For lngColumn = 1 To .Columns.Count
MsgBox .Cell(lngRow, lngColumn).Range.Text
Next
Next
End With
End Sub
--
Please reply only to newsgroup.
Howard Kaikow
method of examining the relationship between the row/column numbers of he
first and last cell in the selection. It's crude but it works.
It just seems strange that the "clean" method of comparing the selected
range with the row and column ranges works for rows but not for columns.
Did I miss something below?
--
Please reply only to newsgroup.
Howard Kaikow wrote in message ...
Jonathan West
Have you tried checking the value of the ColumnSelect property?
Unfortunately this applies only to the Selection object, not to a Range
Regards
Jonathan West - Word MVP
MultiLinker - Automated generation of hyperlinks in Word
Conversion to PDF & HTML
http://www.multilinker.com
Word FAQs at http://www.multilinker.com/wordfaq
Please post any follow-up in the newsgroup. I do not reply to Word questions
by email
Howard Kaikow
If I do a
Selection.ColumnSelectMode = True
That does not put "COL" in the status bar. Instead, it turns on "EXT".
So this is one bug, not necessarily related to the problem I found.
You'd think that Word's built-in VBA SelectColumn would do whatever it
needed to do without the user having to worry about ColumnSelectMode, since
they are different critters.
I am (ab)using SR-2.
--
Please reply only to newsgroup.
Jonathan West <10077...@compuserve.com> wrote in message ...
Greg Safford
return a 1 iff the selection is all in one column. I know that a range in a
table acts as if it encompasses all cells from the cell containing the start
of the range to the cell containing the end of the range, but I thought
checking the selection object worked.
David Foster
<kai...@standards.com> wrote:
>I've been trying to write code that will determine whether a selection in a
>table is ALL in 1 row or all in 1 column.
Selection.Columns.Count
(although you always have to check for that wonderful "the user merged
some cells, I dare you to find the column" situtation.
As you've seen, the easiest workaround for this the whole table range
weirdness is to check the current status of the selection before you
stuff it away into range variables. Otherwise you have to resort to
checking the cells individually (or at least the first and last of
them).
I understand why this works for rows but not columns (Word is only
considering the beginning and end of the range variable), but of
course it makes for a fair mess.
Whenever stuff like this pops up, I often wonder how many of us have
had to independently figure out workarounds for this kind of stuff.
When O2000 comes out, I'm going to seriously consider some kind of
AutoFAQ system to document VBA. It doesn't look like there's going to
be any serious books around, and MS definitely isn't going to document
things like this.
BTW, 'For each var in MyRange.Cells' suffers from similar, but not
identical problems. Be wary of it if you're moving in that direction.
--
David Foster | "But I've been to the pointless forest,
dfo...@panix.com | and it isn't pointless at all."
finger for PGP key | -- Oblio, The Point
Howard Kaikow
merged/split cells.
THe clean solution would have been to compare the selection range with the
column range.
THe brute force fix is to get the row and column numbers for the first cell,
collapse the selection to the end, move left 1 cell, get the row and column
numbers for the last cell and compare the row and column numbers. In this
application, I have to get those numbers anyway, so it's no big deal.
Problems like this and the CTRL ALT L problem I recently described cause
much wasted people time.
The CTRL ALT L case is an outright bug for which the Microsoft
development/SQA team should get axed for not testing. Certain tests are so
simple, there's just no excuse.
Not being to select a column cleanly as one can do for a row is just a
design issue with Word, i.e., as "feature". THe problem is that Microsoft
refuses to provide useful documentation and we are led astray when we see a
"cleanly" selected column on the screen, yet we cannot accomplish the
obvious operations within a macro.
This also raises the question of just how much of this time should be billed
to as Client when one is doing a programming contract and one runs into such
bugs or undocumented features.
I agree with Dave that none of the currently published books more than
scratch the surface.
--
Please reply only to newsgroup.
David Foster wrote in message <3730dca5...@msnews.microsoft.com>...
Scott Matthewman
"Howard Kaikow" <kai...@standards.com> wrote:
> I did not use selection.columns.count for the reason Dave mentioned, i.e.,
> merged/split cells.
Don't know how relevant this is to your particular application, Howard, but
thought I'd pass it on anyway:
in a number of applications where there's an "easier" (and I use that term
advisedly) way to deal with a table if there are no merged fields, I check
the .Uniform property of the table first:
With tbl
If .Uniform Then
' do it the easy way
Else
' do it the hard-but-safe way
end if
End With
Hope this helps,
Scott
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Bill Coan
>Not being to select a column cleanly as one can do for a row is just a
>design issue with Word, i.e., as "feature". THe problem is that Microsoft
>refuses to provide useful documentation and we are led astray when we see
a
>"cleanly" selected column on the screen, yet we cannot accomplish the
>obvious operations within a macro.
Here's another facet of the same problem. If you select two cells in the
same row, Word assigns a selection type of wdSelectionColumn, as you'll see
by running the following code.
If Selection.Type = wdSelectionColumn Then
MsgBox "Selection type = wdSelectionColumn"
End If
--
Bill Coan
Microsoft Word MVP
Neenah, Wisconsin USA
http://www.wordmacros.com
David Foster
<kai...@standards.com> wrote:
>I did not use selection.columns.count for the reason Dave mentioned, i.e.,
>merged/split cells.
>THe clean solution would have been to compare the selection range with the
>column range.
Different problem altogether. Selection.columns.count will work in
the same situations that comparing the ranges will work. Apart from
the bugs surrounding table ranges, there's also just a lot of
weirdness due to the whole thing with merged cells.
Certain things are obvious bugs (like 'set rng = selection.range'
gives you two different ranges), while others are just naturally
complex. And there's a gray line between. I admittedly haven't
sorted the whole thing out.
>Problems like this and the CTRL ALT L problem I recently described cause
>much wasted people time.
>
>The CTRL ALT L case is an outright bug for which the Microsoft
>development/SQA team should get axed for not testing. Certain tests are so
>simple, there's just no excuse.
I avoided that thread mostly, but we'll just have to agree to disagree
here. I honestly don't see a bug there. The keystroke was redefined
at system level, presumably due to the keyboard configuration. Of
course the application shouldn't see it, IMO. It's just like the old
situation with all the program manager shortcuts.
>This also raises the question of just how much of this time should be billed
>to as Client when one is doing a programming contract and one runs into such
>bugs or undocumented features.
Hey, that's the easiest question I've seen on the newsgroup in weeks
:-)
--
David Foster | It has happened before, but there is
dfo...@panix.com | nothing to compare it to now.
finger for PGP key | -- "Gravity's Rainbow" Thomas Pynchon
Howard Kaikow
different numbers of columns in certain rows and .Uniform still reports
True.
--
Please reply only to newsgroup.
Scott Matthewman wrote in message <7gs835$stu$1...@nnrp1.deja.com>...
>In article <umK0M07l#GA.194@cppssbbsa03>,
> "Howard Kaikow" <kai...@standards.com> wrote:
>> I did not use selection.columns.count for the reason Dave mentioned,
i.e.,
>> merged/split cells.
>
Howard Kaikow
1 row and more than 1 column.
It returns wdSelectionRow only when I select an entire row.
I guess the only safe way is to grab the beginning and ending cells and
compare the row and column indices.
In this particular application, I have to address the individual cells
anyway.
One other possibility is to try using bookmarks, instead of ranges, but I
would expect the same problems.
--
Please reply only to newsgroup.
Bill Coan wrote in message ...