vbVerticalTab (Word97/SR2)

Topic

New Reply

From the Word97 SR2 help files:
vbVerticalTab Chr(11) Not useful in Microsoft Windows

It seems useful.

I thought we were going to use (supplied) identified onstants as a form of good coding practice.

It works.

I’m using it.

Can anyone think of a good reason not to use it?

Public Function TypeHeading(flds)
    Selection.HomeKey Unit:=wdStory
    Selection.TypeText (flds("saln") & " " & flds("given") & " " & flds("surn")) & vbVerticalTab
    If flds("title")  "" Then Selection.TypeText (flds("title")) & vbVerticalTab
    If flds("business")  "" Then Selection.TypeText (flds("business")) & vbVerticalTab
    If flds("address")  "" Then Selection.TypeText (flds("address")) & vbVerticalTab
    If flds("address2")  "" Then Selection.TypeText (flds("address2")) & vbVerticalTab
    Selection.TypeText (flds("city") & " " & flds("prov") & "  " & flds("postcode")) & vbCrLf
    Selection.TypeText "Dear " & (flds("saln") & " " & flds("surn")) & vbCrLf
End Function

Reply | Quote

Replies

I can’t think of a good reason to use it Chris. Is the vbCrLf broken on your computer?

Reply | Quote

> Is the vbCrLf broken on your computer?

No, it’s not, but as the help files show, the vbCrLf is a different creature from the vbTab.

It’s not a question of whether an individual can dream up a use for it, at all. 99% of the population are doing things I wouldn’t dream of doing anyway.

It’s a question of “Why not use an existing and documented constant?” if you do have a need for it.

My question remains.

Reply | Quote

If you can’t think of a use for it, that might explain the help file remark that it isn’t useful. At least, that’s always been my interpretation of it. Usefulness doesn’t have anything to do with the constant, it’s the vertical tab concept that is of questionable usefulness in Word.

Reply | Quote

Charlotte, you might want to go back and re-read my original post.

I have found a use for it, and a very good one too. The ascii(011) code is good for a soft-line break in Word – the programming equivalent of Shift-Enter.

There’s a very good use for it.

There’s no question about that.

Here’s the question, re-stated: Has anyone found any justification for the statement in the Help Files?

Reply | Quote

Perhaps because a line break is not a vertical tab?
(I have seen this constant used for a line break, but it confused the hell out of me)

Klaus

Reply | Quote

OK.

1) When I tap Shift-Enter do I get a soft-return?

2) Isn’t that an ASCII(011)?

3) Couldn’t I program that by Selection.TypeText CHR$(11)?

4) Isn’t that the same effect as Selection.TypeText vbTab?

If the answers to all 4 questions is/are “Yes”, then my question in the original post stands.

No-one is saying we HAVE to use vbTab (although my coding preference is to use existing labelled constants wherever possible), but why would one say “This labelled constant has no use”, when clearly it does?

Reply | Quote

Hi Chris,

Perhaps it’s a matter of taste, but I’d rather use ChrW(11) than a vbConstant that doesn’t do what it’s name implies.

In DOS, Chr(11) used to be a control character that inserted a vertical tab.
DOS isn’t there any more, and Word’s programmers decided to use Chr(11) as the code for a manual line break.

Perhaps the same programmers decide in the next version that the manual line break should be coded as ChrW(2028) (= Unicode for “Line Separator”), so I, too, would feel more comfortable with using a constant instead of Chr(11).

But since the name “vbVerticalTab” seems misleading, I’d hate to use it in my code.

Perhaps I’m in the dumps and you come up roses if MS’ programmers convert vbVerticalTab correctly in some future version, whereas my code will fail…

Klaus

Reply | Quote

> use Chr(11) as the code for a manual line break.

What’s more interesting, is that vbVerticalTab is the only labelled value of chr(11) in that help page.

Chr$(11) is a bona-fide requirement in programming. I would have named it vbSoftLineBreak or similar, and said it was useful as a soft line break, rather than naming it as a Vertical Tab and saying that that made it useless.

Reply | Quote

As I said, I miss constants for the line break and other special Word characters, too (Chr(1) = AutoShapes, Chr(2) = footnotes, …, Chr(30) = non-breaking hyphen, Chr(31) = optional hyphen).

These control characters certainly have a different meaning in other applications; it would have been the task of Word’s programmers to define wdConstants for them (and not the task of the VB developers who define the vbConstants).

I recently even came across a “phantom” character without an ASCII code: If you check the ranges of any field that has a .Result, you get 1 character for the opening field brace = Chr(19), then the range of field.Code, then one phantom character, then the range of field.Result, and finally the closing brace = Chr(21).

Since you may often want to import text files that may contain control characters Chr(0) – Chr(31), it would have been a nice move from MS if they would have moved all those special characters, except for paragraph marks and tabs, to some “private use” Unicode range. For the non-breaking hyphen and the manual line breaks, there even are regular Unicode characters available as far as I can see (non-breaking hyphen = U+2011).

BTW, you look a bit frayed around the edges today… is this what’s called “human artefacts”

Klaus

Reply | Quote

> not the task of the VB developers who define the vbConstants)

Enlightening point!

It’s labelled as a VB constant, but I’m wanting to use it as a Word constant. A subtle difference. It’s realistic (aaaaargh) to expect that the VB people wouldn’t know just how useful an ascii(011) can be.

Reply | Quote