Render tab character in string control

[PJM_Labview]

In most software a tab character (/t) is "visually equivalent" to several space characters (see tab list below in notepad).

Unfortunately in LabVIEW, a tab character is visually equivalent (in normal display mode) to 1 space character. I am proposing that this should be change to be n space character.

[tst]

Just to clarify - in most programs a tab is not represented as N spaces, but as a series of columns which are N spaces apart. A tab char brings the text to the next column, regardless of how far it is. This is useful for alignment.

[Manzolli]

Agree with tst. THe idea is good, but the behavior should be better discussed.

[Mr.Mike]

Sometimes a tab moves forward to the next column.  Sometimes it's just equivalent to n spaces.  It's different depending on the application.  For most programming environments it's equivalent to a number of spaces and you can make the editor replace tabs with spaces.  I think if we had a rich text control, we'd want to move forward to a the next column.  But if you have a plain string control, it'd just be spaces.  Or would that be too confusing?

If we're talking about columns, we need to figure out how far apart each column is.  If we're talking about spaces, we need to figure out how many spaces represent a tab.  For both we need to figure out if it's user-settable ("user" as in you guys, or "user" as in your customers) or just some fixed value in LabVIEW.

[PJM_Labview]

I may not have been clear in the description, but when I say n space I meant that the column width appear to be n space wide.

I agree with tst, this has to be represented as a column (and not n space).

It would be ok to have a setting for the column width (but I dont think that this is critical).

[Manzolli]

Originally it was 8 spaces. Some environment, like Visual Basic, which the standard is 4 spaces, it cam be configured. This works fine with fixed size fonts. For proportional fonts a fixed number of spaces is a mess. In this case a distance is determined and it's related to the margin. Check this article http://en.wikipedia.org/wiki/Tab_character#Tab_characters

[PJM_Labview]

---

For proportional fonts a fixed number of spaces is a mess.

---

Exactly. This is why the column / fixed distance is required.

[AristosQueue (NI)]

The times when it matters whether it is N spaces or "next column delimiter" is when the tab is embedded inside the string. At the beginning of the string, it can be defined either way and really doesn't matter. Inside the string, it's the difference between this:

My\tString                    My        String

MyOther\tString      >>>>>    MyOther        String

where the tab is 8 spaces and this:

My\tString                    My      String

MyOther\tString      >>>>>    MyOther String

where the tab is next column at 8 character intervals. Although this is most readily recognizable with the fixed width font, similar options apply when using a variable width font.

[Peter_FitzGerald]

A very good idea

It is generally agreed that TAB should cause the cursor to move to the beginning of the next "column",

For fixed width fonts the "column" width can be expressed as N characters

For proportional fonts the "column" width can be expressed as %  (of the Text.Size.Width)

This functionality could be implemented by adding 3 new string properties...

    TabEnabled (Boolean, default=false)

    TabWidth (Numeric)

    TabWidthUnit (Enum: Characters, % of Width)

[Peter_FitzGerald]

Improvement over my previous proposition...

It is generally agreed that TAB should cause the cursor to move to the beginning of the next "column",

For fixed width fonts the "column" width can be expressed as N characters or N pixels

For proportional fonts the "column" width can be expressed as N pixels

This functionality could be implemented by adding 3 new string properties...

    TabEnabled (Boolean, default=false)

    TabWidth (Numeric)

    TabWidthUnit (Enum: Characters, pixels, % of Text.Size.Width)

[Peter_FitzGerald]

Improvement over my previous proposition...

It is generally agreed that TAB should cause the cursor to move to the beginning of the next "column",

For fixed width fonts the "column" width can be expressed as N characters or N pixels

For proportional fonts the "column" width can be expressed as N pixels

This functionality could be implemented by adding 3 new string properties...

    TabEnabled (Boolean, default=false)

    TabWidth (Numeric)

    TabWidthUnit (Enum: Characters, pixels, % of Text.Size.Width)

[PalleM]

I would love to see this implemented, Peter_FitzGerald's solution would be nice.

For now, im using below code. As mentioned above, "number of spaces" should be 8 for the courier font