Tab confusion

[Michael Mattias]

Ultra-Edit has an option to "use spaces instead of tabs," but it leaves existing tabs alone when a file is opened. ("use" applies only to typing <TAB>)

In text mode, it displays the number of spaces specified by the user for each <TAB> character; but if you change to hex mode, it shows only 0x09, no extra 0x20 (space).

I'd guess this is pretty typical behavior for a general-purpose 'file editor' (which the PB IDE is not)

[Simon Morgan]

Cliff

I think you are using the term compiled program incorrectly. Your compiled program is an EXE or DLL that contains solid machine code and data, and contains neither spaces nor tabs, except in string data (i.e. the compiled image of strings you have in double quotes in your source code, or defined with CHR$(constant) or pre-defined string constants).

Your BAS file remains source code, and may well have characters you typed by pressing the TAB key converted into spaces when the file is saved. (But if you need a tab character in a literal string, don't use the tab key, use $TAB or CHR$(9).)

Any text file (including as BAS file) you read or write programmatically using your program will deal with tab and space characters exactly as Eric says.

[Gösta H. Lovgren-2]

It also does this to non-.BAS files, something to bear in mind when you are laboriously creating test data for that interface file....

Seems to me the IDE is fine for what it is designed to do - Write .Bas code for the compiler to build into an .exe. (Whether it's PB's or another designed for PB).

Building "test data", one should, I think, use an editor designed for that. For example, I just loaded a .bas file into NoteTab Pro (a text editor) and inserted a couple TABs into it, then looked at the result through a hex editor, and sure enough, there were TABS (Chr$(9)'s, not spaces.

Next I built a test file using PBWin:

Sub Tab_Test
Fnum = FreeFile
Open "c:\Temp\Tab_Test.bas" For Output As #Fnum
For ctr = 1 To 10
Print #fnum, Chr$(9) & "Testing Tabs" & Chr$(9)
Next ctr 
Close
End Sub

And sure enough, looking at it with the hex editor there were the Chr$(9)'s. (Note it wasn't all that laborious either. {grin})

Not to be snarky, but tools should not be faulted for not doing what they were not designed to do. It's nice when they do, but ...

[Cliff Nichols]

Hence my confusion....

What I optically see while coding, may NOT be what I would think it would be once compiled and parsing, or Mid, or string, or whatever I want to do with it....

I could come up with a "Nit-Pick" program to test, but thought I would ask first in case I am wasting time?

[Chris Holbrook]

The PB editor (IDE) converts tabs to spaces, as do most editors, when displaying a file.

The file is stored using spaces, not tabs, so the IDE is translating tabs to spaces either when TAB is entered or when the file is saved.

In fact if you insert TAB charcters into a .BAS file the editor handles them just as you would expect, then when the file is saved they are converted to 4 spaces each. It also does this to non-.BAS files, something to bear in mind when you are laboriously creating test data for that interface file....

Maybe there is some way of modifying this behaviour, but I haven't come across it.

[Eric Pearson]

A tab character is an ASCII-9, i.e. CHR$(9), regardless of the program that created the file. The number of spaces that the tab character represents is not saved in the file, at least not if it is a "plain" text file.

Any program that reads a tab-delimited file, may, if the programmer chooses, convert the tab character to any number of spaces. But that's strictly up to the program that reads (and usually displays) the file.

The PB compiler does not automatically convert Tab characters in any way.

The PB editor (IDE) converts tabs to spaces, as do most editors, when displaying a file.

Does that help?

-- Eric

[Cliff Nichols]

I have a situation where the keyword TAB is causing some confusion.

If I open a file (in this case lets say a Text file), and parse lines by Tabs

1. Does my compiled program parse by # of spaces?
2. Does my compiled program parse by some known value such as the character for TAB and just shows me the spaces in the correct format?
3. Would this vary depending on the program that wrote it? (I would think so)... for example, if I wrote it in PB, would it be the default 4 spaces? or my settings override of 5 spaces? or some guesstimation of whatever wrote it (Word, Ultra-Edit, Notepad, etc....) and knowing how they handle it????

Writing the file (in this case lets say my compiled PB program)

1. Does PB replace this TAB with the default? or my settings override?
2. Does PB replace this TAB with the ASCII character for TAB???
3. Would another program mis-Interpret this "TAB" because its looking for a different format?

Reason I ask, is I am looking at possibilities involving Parse, and Tab, and Fields, and Nulls, and other formatting/delimeters types of things, and would like to get it right the 1st time rather than waste time tracking down "Bugs" because I "ASSUMED" things worked one way and not comprehend it could work the other.