Replacning tabs with commas question

[Steve Johnson]

As a TurboBasic user, I wrote this below to replace tabs with commas as I was working with comma deliminated files. I can't seem to be able to do the same in PowerBasic for WIndows. Any help out there?

Thanks. Steve

OPEN filein$ FOR BINARY AS 6
OPEN fileout$ FOR BINARY AS 7


WHILE NOT EOF(6)
FOR I%=1 TO 1000
GET$#6,I%,x$
REPLACE CHR$(9) WITH "," IN x$
PUT$#7,x$
NEXT I%
WEND
CLOSE #6
CLOSE #7

[Mel Bishop]

REPLACE should work for your app but I don't understand the structure of your for/next loop.

As it reads, the first time through the loop, you would enter one byte. The second, two bytes, the third, 3 bytes, etc.

Try this:

OPEN filein$ FOR BINARY AS 6
OPEN fileout$ FOR BINARY AS 7

get$ #6,lof(6),x$
REPLACE CHR$(9) WITH "," IN x$
PUT$#7,x$

CLOSE #6
CLOSE #7

As long as your file is < 2gb, you shouldn't have any problems.

[Richard Angell]

Actually to be practical, the file size needs to be less than avaialble RAM to avoid paging. Otherwise Mel's code will do it pretty efficiently, but I think it might add an extra CRLF onto the end.

There is another way to write the REPLACE line tool:
REPLACE $TAB with "," IN x$ '$TAB is the PB equate for CHR$(9)

If the file(s) are really large, then there are other methods to do this with a bit more code using BINARY mode file I/O. But then we get into things like how the strings are stored now in the files and then look at GET #6,,x$ or GET #6,,ABS x$. x$ will need to be intialized to hold up to the maximum length string in the latter case.

[Mel Bishop]

>>...I think it might add an extra CRLF onto the end...

It might if you opened the file for OUTPUT, but not in BINARY mode. Binary mode is extremely raw. It will PUT$ whatever you specify. Nothing more, nothing less.

>>...x$ will need to be intialized...

Not necessairly. If it's a fixed length string, yes, I think. If it's just a variable to temporairly hold data, no.

Remember, you are dealing with POWERbasic and not turbo, visual or quick basic.

[Richard Angell]

The difference for dynamic length strings depends on whether they are in PB/VB packed string format or not. Using plain GET #N,,x$ assumes packed format and sizes x$ accordingly. However using GET #N,,ABS x$ requires a buffered length that will be CHR$(0) back filled for strings under the max buffer length (see the help for the discussion).

[Michael Mattias]

On the application side....

I think I'd deal with the new problems you could introduce by first replacing all comma with space, then replacing tab with comma.

[Michael Mattias]

>plain GET #N,,x$ assumes packed format and sizes x$ accordingly.

Um, no. At least not in that syntax, unless the file has been opened for RANDOM

First of all, the behavior of GET is dependent on the OPEN mode... it's different for BINARY and RANDOM.

The "length word, data" ("packed string") format rule applies only when the file is opened FOR RANDOM or when the file is opened for BINARY and the var is an an array ("Arr())") and that array is an array of dynamic strings.

The ABS clause only has meaning when the file is opened FOR RANDOM

When the file is opened for BINARY, GET will retrieve SIZEOF(var) (scalars), LEN(var) (dynamic strings) or SIZEOF(Element)*Numberof elements [scalars] bytes from the file at the filepointer position.

So in your syntax:
GET #N,,X$

If #N has been opened for BINARY it is the programmer's responsibility to "pre-size" X$ to the desired value

IF #N has been opened for RANDOM, then the compiler will return X$ based on the LEN= used in the OPEN, and will assume the data are stored "length word, data")

MCM

[Richard Angell]

Yes, you are right Michael. Should be RANDOM , not BINARY to use ABS.

[Richard Angell]

Also, note however that PUT does allow ABS in both modes, with the restrictions noted in that help.